7 conseils pour collaborer avec un programmeur SAS

Vous devez travaillez avec programmeur SAS et souhaitez connaître quelques petits trucs qui faciliteront cette collaboration. Cet article est fait pour vous. Les exemples traiteront principalement de la pharmaceutique mais peuvent être aisément généralisés.

1. Répondez rapidement à leurs questions

Maintenez le flux d’information : Lorsqu’un programmeur pose une question, il a souvent besoin de la réponse immédiatement pour pouvoir continuer à avancer dans son travail. Vous avez à peu prêt une marge d’une demi-journée pour réponse. Si vous répondez dans les 5 minutes c’est encore mieux. Faute de réponse, il sera obligé d’arrêter de travailler sur le projet. Le temps de réimmersion dans un projet est long et pesant pour un programmeur. En effet, le programmeur oublie très rapidement ce qu’il a fait et pourquoi même si il documente ces programmes. Imposez lui ces contraintes et il sera encore moins enclin à reprendre le processus et c’est vous qui risquez de voir vos dates butoires passer aux oubliettes.

2. Coupez vos réponses

Ecrire un mail par problématique vous donnera plus de chance d’en voir une partie de traitées rapidement. Si vous envoyez un bloc, cela effrayera le programmeur. Il aura tendance à traiter les réponses simples et rapide en premier. Faites partie de ses priorités.

3. Soyer précis dans vos demandes

Apportez votre expertise sur les données : Bien sûr, vous ne connaissez pas tous les surprises dans les données qui seront visibles une fois seulement le travail du programmeur en partie accomplie. Néanmoins, vous êtes le spécialiste sur ces données. Vous savez quand des valeurs sont aberrantes, comment les variables doivent être définies.

4. Garder un document de référence commun

Encouragez le programmeur à rédiger un document résumant les choix qu’il fait lors de l’écriture de ses programmes. Dans le cas de la rédaction d’une macro, il est obligé d’écrire divers documents :

• un document technique (specification)
• un manuel utilisateur (user manual)
• un récapitulatif des tests effectués (test plan)
• un diagramme décrivant le processus du programme (flowchart).

A tord, il rédige souvent ce type de document après avoir fini la partie programmation. Incitez-le à commencer la rédaction dès le début et à poursuivre les mises à jour au fur-et-à mesure.

Reste que dans le cas de la programmation lié au transfert de données ou à la création de tables statistiques aucun document n’est souvent demandé. Les Statistical Analysis Plan (SAP) pour les tables statistiques ne sont pas encore généralisées. Il est très pratique d’avoir un document sur lequel le programmeur listera les choix fais, les points en suspend demandant clarification de votre part, etc.

5. Informez-le des délais à respecter et vos attentes

Informez-lui de l’agenda de l’étude, des décisions majeures : Tenez compte du fait que le programmeur n’est impliqué que sporadiquement dans une étude clinique. Il sera consulté seulement à une certaine période du processus. Il n’aura quasiment pas d’information sur l’étude à part le protocole. Il n’aura pas été invité aux réunions pour présenter les enjeux de l’études, pour écouter les discussions sur les spécificités des patients et n’est en général pas tenu au courant des résultats de l’études à part un : les résultats sont positifs ou pas. De plus, il remplacera parfois un autre programmeur en cours de projet ou sera remplacé par un autre.

6. Expliquez les enjeux du projet

Faites-lui partager vos motivations et les enjeux que représentent l’étude sur laquelle vous l’impliquez. Le programmeur doit travailler sur plusieurs études et projets à la fois. Il n’a pas donc les moyens de se motiver pour chaque particularité d’une étude.

7. Ne modifiez pas le travail effectué par le programmeur

Si vous ne vous sentez pas à l’aise avec la programmation sous SAS, ne commencez pas à ajouter des programmes qui affecteront les travaux de votre programmeur. Respectez le rôle de chacun.