Toujours dans la foulée de mes apprentissage à Mesh 2008, voici un résumé de la présentation de Reginald Braithwaite intitulée “Building and Managing Great Software Teams“, à laquelle j’ai assisté avec grand intérêt. C’est que, malgré que je sois une personne plutôt du côté technique et créatif, je veille aussi à la gestion de projets de développement web. Bien honnêtement, je me reprochais déjà quelques aspects où je sentais une lacune dans mon rôle, que Redg est venu confirmé. Il a énoncé ses conseils pour les projets informatiques, mais je trouve qu’ils s’appliquent aussi à des projets de développement technologique de façon plus générale.
Pourquoi travailler avec une équipe de développement?
Ou plutôt, “sur quel projet est-ce que ça vaut la peine de travailler?” Souvent, ce ne sont pas les projets qui manquent mais plutôt les ressources. Alors, comment décider des priorités? Quelle est la question ouverte la plus importante dans votre domaine? Êtes-vous en train de travailler dessus? (la réponse devrait être oui!) Qu’est-ce qui fera véritablement la différence entre le succès et l’échec d’un projet? Ce sont autant de question qu’on doit continuellement se poser pour garder le cap.
Comment travailler?
- Focus – Attention d’étendre trop mince les ressources, incluant votre attention pour superviser des projets. Il faut se garder la tête hors de l’eau afin de pouvoir travailler sur ce qui est important mais pas urgent. Si on ne fait que des urgences, on finit par passer à côté de pleins d’éléments importants mais non urgents. À long terme, ce n’est pas viable.
- S’attarder à ce qui compte – Un citation d’Einstein que j’aime bien:
Everything that can be counted does not necessarily count; everything that counts cannot necessarily be counted.
Ça s’applique tellement bien à une équipe de créatifs. Un diagramme de Gantt aide à voir clair, mais ne donne aucun indicatif du morale des troupes, pourtant très important pour la qualité du travail. Il ne faut pas mesurer pour mesurer. Souvent, les processus n’ajoutent pas de valeur. Il faut trouver le juste milieu entre ordre et chaos pour demeurer agile. Je donnais l’analogie de la navette spatiale dans un article précédent, qui prend une quantité énorme de carburant pour mettre en orbite du carburant. Il faut absolument éviter ça et garder les structures légères.
- Être réaliste — Un entrepreneur en construction m’a dit qu’il préférait prendre une maison de moins qu’une maison de trop dans son année. Je suis 100% d’accord avec cette idée. Quand on fonctionne toujours à plein régime, la moindre jambette cause un embouteillage à tous les aspects du projet. Il faut apprendre à être réaliste et à ne pas se mettre de pression inutilement avec des échéanciers irréalistes. Vous connaissez le red-shift en astronomie? Dans le développement technologique, c’est plutôt le rose-shift qui survient: À mesure que les estimés passent d’un échelon à l’autre vers la direction, ils deviennent de plus en plus roses. Le programmeur disait 2 à 4 semaines de travail, le gestionnaire dit à son superviseur 2-3 semaines, qui dit au patron maximum deux semaines. Ça crée des fausses attentes, des échéanciers défoncés et du stress inutile. Il faut aussi se rappeler qu’un humain est très mauvais pour prévoir… un imprévu.
- Communication – Comme n’importe quelle système dynamique auquel on veut donner une direction, il faut avoir du feedback à haute fréquence. On peut alors s’ajuster rapidement avant d’être trop loin dans la mauvaise direction. Idéalement, les gens devraient se parler tous les jours. De la même manière, ça prend une bonne bande-passante dans la communication. On doit être 100% attentif pour bien saisir les messages, rien de mieux qu’être face à face. Braithwaite suggère aussi de travailler en paires, que c’est habituellement une bonne formule.
- Régler les problèmes — Attention que les exceptions ne deviennent des habitudes. Comme le dit le proverbe, la meilleure façon de devenir fou, c’est de continuer à faire la même chose en s’imaginant qu’on va avoir un résultat différent. Et les demandes qui changent en cours de route? Il n’avait pas de solution miracle là-dessus…
Avec qui travailler?
Son exemple était le suivant: si tu veux engager un jongleur, qu’est-ce que tu vas lui demander? De jongler! Tu ne lui demanderas pas que quelqu’un te dise qu’il sait jongler. Rien de mieux donc selon lui que de tester un programmeur avec un mandat ponctuel ou en lui demandant de réviser une partie de votre code pour voir ses aptitudes. Comme les projets pleuvent et que les bonnes ressources sont rares, il faut montrer l’importance accordée à leur travail avant et après l’embauche. De la même manière, il invite à outsourcer ou automatiser toute tâche redondante pour garder le monde stimulé. Et à propos des divas, il estime que tout le monde dans l’équipe doit suer, y compris les superstars. Regardez n’importe quelle équipe sportive gagnante pour valider cette affirmation.
Finalement, en tant que gestionnaire, il ne faut pas oublier qu’on ne code rien, qu’on n’intègre rien et qu’on ne design rien. On n’est pas là pour le comment mais plutôt pour le pourquoi et pour la philosophie à adopter. On ne fait que connecter les bons éléments et animer leur motivation, puis ce sont eux qui créent.
