Voici donc la première série de recommandations annoncées ici.

Ces 12 points sont destinées aux informaticiens et ne sont bien évidemment pas des règles absolues. Chacun peut les adapter, les améliorer, les ignorer ou les compléter.

12 recommandations aux chefs de projets et développeurs Web pour maintenir de bonnes relations avec les équipes marketing.

1. N’oubliez jamais que vous travaillez dans la même entreprise, sur le même projet et que votre objectif est donc commun : la réussite du projet.
   Les conflits entre services sont stériles et improductifs. Une collaboration étroite et une bonne entente ne peuvent aboutir qu’à la réussite du projet.
2. Pensez toujours à l’utilisateur final.
   Les formations informatiques ont parfois un défaut : elles se concentrent totalement sur l’aspect technique et oublient souvent l’aspect ergonomique. Lorsque vous codez, gardez toujours un regard objectif, imaginez comment vous réagiriez si vous ne connaissiez rien en informatique et qu’on vous installe à un clavier face à votre site. Vous ne développez pas le site pour vous mais pour des utilisateurs, des clients.
3. Participez à la rédaction du cahier des charges fonctionnel.
   Même si les équipes marketing y sont parfois opposées, insistez pour participer aux réunions importantes pour pouvoir y apporter, si nécessaire, un avis technique et ainsi, souvent, faire gagner du temps sur certaines prises de décisions.
4. N’hésitez pas à faire des suggestions.
   Ce n’est pas parce que vous êtes un informaticien que vous ne devez pas avoir des idées ! Encore une fois, regardez le projet avec un regard neutre et servez vous de vos compétences techniques pour suggérer des idées qui pourront apporter un plus au site. Mais attention : ne soyez pas frustré ou vexé si toutes vos idées ne sont pas retenues.
5. Ne planifiez rien tant qu’on ne vous a pas remis un cahier des charges fonctionnel complet.
   Le cahier des charges fonctionnel est trop souvent négligé. Simples captures d’écran, simple schéma, feuilles volantes… Soyez intraitable sur ce sujet. Le cahier des charges fonctionnel est la base de tout votre travail. C’est lui qui permettra la rédaction du cahier des charges technique. C’est lui qui vous permettra de concevoir le planning. Un cahier des charges fonctionnel bâclé ou incomplet peut faire prendre des semaines ou des mois de retard au projet et contribuer aux mauvaises relations entre services. Et c’est sur l’informatique que sera portée la responsabilité vu que vous aurez accepté de prendre en charge un dossier incomplet.
6. Signalez toujours les incohérences fonctionnelles dès que vous les constatez.
   Au fur et à mesure que vous codez certaines fonctionnalités vous pouvez constater qu’il y a un problème, soit logique, soit ergonomique. N’attendez pas d’avoir fini de coder cette partie pour en parler : vous éviterez ainsi de perdre du temps à recoder des parties que vous venez de coder.
7. Parlez un langage que les non-informaticiens comprennent et ne faites pas semblant de ne pas comprendre lorsqu’on s’adresse à vous en termes non-informatiques.
   Tout le monde n’est pas obligé de connaître la terminologie informatique. Mettez vous au niveau de vos interlocuteurs, parlez un langage que le commun des mortels peut comprendre. Ce sera bénéfique pour votre image dans les autres services et évitera des problèmes liés à des incompréhensions sémantiques.
8. Sachez dire non… mais argumentez.
   Trop d’informaticiens se replient derrière des “non, ça n’est techniquement pas possible” ou “non, on n’aura pas le temps”, … Le “ça n’est techniquement pas possible” est de moins en moins crédible. Nous savons tous que les choses pas possibles en informatique se font de plus en plus rare.
   Le pire non que vous pourriez formuler est un “non, ça n’est pas une priorité”. Ce n’est pas à vous de dire ce qui est une priorité ou pas au niveau marketing, communication ou stratégie. Ce n’est pas votre rôle. Donc, dites non, mais uniquement si c’est justifié.
9. Sachez dire oui… mais pour la prochaine version.
   A l’inverse de ceux qui disent systématiquement non, il y a ceux qui disent toujours oui. Et ça n’est pas mieux. A force de dire oui à tout, vous finissez par surcharger votre planning et par ne plus pouvoir tenir les délais. Concertez-vous avec les demandeurs, gérez les demandes par priorités et attribuez-les aux versions adéquates.
10. Prévoyez toujours dans vos planning une marge pour les modifications imprévues mais indispensables.
    Même lorsque les cahiers des charges sont parfaits, il y aura forcément une part d’imprévisible. Le marketing peut par exemple réaliser en cours de développement qu’une fonctionnalité “vitale”, oubliée dans le projet initial, doit être codée car le principal concurrent vient de la mettre en ligne et dans ce cas, la stratégie commerciale sera la priorité et vous devrez accepter ces imprévus.
11. Tenez à jour les plannings et les états d’avancement.
    Plus vos interlocuteurs auront une visibilité réaliste et concrète sur l’avancement du projet, plus ils vous laisseront tranquille et auront confiance en vous.
12. N’oubliez pas que le code n’est pas une fin mais un moyen.
    L’utilisateur final ne verra jamais le code (sauf si vous avez mal assuré au niveau de la gestion des erreurs). Votre code n’a qu’un objectif : rendre concret un projet. Soyez humble !

Quoi de plus agréable que de s’investir dans un projet sur lequel les équipes travaillent en symbiose.

A vous de montrer à vos collègues que vous n’êtes pas un “codeur autiste” mais un humain accessible et ouvert.

A suivre bientôt la troisième et dernière partie : les recommandations pour les marketeurs.

Inscrivez-vous au RSS des commentaires ou laissez un trackback