Un de mes gags favoris de la comédie Monty Python est un sketch qui revient souvent… « et maintenant quelque chose de complètement différent… » :
Et maintenant quelque chose de complètement différent… un homme qui a trois fesses (en anglais seulement).
ou
Et maintenant quelque chose de complètement différent… un homme en robe de soirée, assis dans une cage au zoo (en anglais seulement).
J’adore ce type d’humour puisqu’il est complètement tordu et dépourvu de logique. Ça stimule mon imagination et ça me remplit de bonheur.
Un des concepts complètement différents et qui revient souvent sur le tapis au sein de CAPTURE est le concept que les gens veulent entendre des histoires d’interventions dans la sphère de santé publique qui n’ont pas fonctionné. L’idée étant que nous apprenons souvent mieux de nos erreurs que de nos réussites, ce avec quoi je suis tout à fait d’accord. Apprendre de nos erreurs est une activité fondamentalement humaine (pensez à la façon dont nous apprenons à marcher et à parler). Admettre nos erreurs à nos investisseurs et à nos pairs n’est cependant pas une chose qui vient naturellement.
Dans l’esprit de Monty Python, je souhaite faire quelque chose de complètement différent : vous faire part d’une assez grosse « erreur » (appelons plutôt ça une occasion d’apprentissage) qui a été commise au cours du développement de la plateforme CAPTURE.
J’aimerais tout d’abord mettre la situation en contexte, puisque, comme on le dit si bien, le contexte c’est primordial. En janvier 2010, CAPTURE en était à la fin de sa première année d’un cycle de financement de trois ans et avait fait des progrès minimes dans l’élaboration de sa plate-forme d’évaluation en ligne. Nous avions procédé à un grand nombre de consultations, qui nous ont été très utiles, mais nous n’avions pas encore écrit une seule ligne de code. De plus, nous venions tout juste de « décruter » (pour ne pas dire « mettre à la porte ») notre premier développeur Web et d’en engager un nouveau. Nous étions également assis sur un surplus d’argent non dépensé puisque, comme c’est le cas de la plupart des jeunes entreprises, nous n’avions pas été en mesure d’accroître nos dépenses au rythme que nous avions envisagé (une autre leçon tirée de nos erreurs!).
Étant donné le contexte, il nous semblait parfaitement logique d’embaucher une entreprise de développement Web qui nous aiderait à faire avancer le projet. Nous avions cru que notre développeur Web et moi-même serions en mesure de diriger les développeurs externes qui, au bout du compte, mettraient au point un produit que nous pourrions modifier selon nos besoins ultérieurs.
Cela s’est révélé être un mini-désastre. Nous avons mis plus d’un mois à faire comprendre nos concepts aux développeurs et malgré tout, nous étions incertains qu’ils aient vraiment compris. Pour être honnêtes, nos concepts ont évolué au fur et à mesure que le projet avançait et que de nouvelles idées faisaient surface. Cette situation était évidemment frustrante pour les développeurs puisqu’ils avaient l’impression de programmer sur du sable mouvant. D’autre part, nous avions intentionnellement évité de préparer un document de définition des exigences opérationnelles (en anglais seulement) puisque nous savions que nous trouverions le moyen de faire les choses au fur et à mesure. Le seul problème c’est que nous avons dû faire face à l’inévitable question : « comment saurons-nous quand nous aurons terminé? ». Après coup, ces problèmes semblent flagrants et tout à fait prévisibles, mais sur le coup, l’équipe de développeurs externes et celle de CAPTURE ont toutes deux accepté l’arrangement, comme des développeurs aguerris qui savaient où ils s’en allaient.
En fin de compte, qu’avons-nous appris de notre petit « projet pilote »? Tout d’abord, nous avons appris que nous ne pouvions pas élaborer une application novatrice comme CAPTURE à l’aide de développeurs externes seulement. Nous avons embauché deux employés additionnels et nous faisons désormais tout le travail à l’interne, car nous savons que les sables mouvants ne disparaîtront pas de sitôt et que nous devrons être en mesure de faire face au changement. Nous avons également adopté un processus appelé le « Agile development » (en anglais seulement) qui réduit les retards entre la conception d’une idée et la collecte de rétroaction de la part des utilisateurs. Nous nous sommes également rendu compte que des définitions d’exigences opérationnelles sont précieuses, tant qu’on n’essaie pas de concevoir le système entier d’un seul trait. Définir les fonctionnalités qui feront partie du cycle de développement du mois à venir semble être un niveau de planification officielle qui convient à notre équipe.
D’un point de vue de mesure du rendement, CAPTURE ne s’en sort pas très bien : nous avons passé six mois à bâtir un système qui ne s’est jamais rendu à l’étape de la production. Cependant, d’un point de vue de l’apprentissage, ces six mois ont été incroyablement précieux puisque nous en avons appris énormément sur ce qui fonctionne et ce qui ne fonctionne pas dans notre situation. Nous avons testé un modèle d’externalisation que nous avons par la suite rejeté. Nous avons testé des techniques de codage et des cadres Web, que nous avons par la suite écartés. Nous avons fait des expériences selon un modèle de documentation minimale dans notre processus de conception initiale qui a par la suite été mis au rencart. Ces leçons ont contribué directement à l’élaboration de l’équipe de développement productive et bien rodée que nous sommes devenus. On doit parfois concevoir un système « bon à jeter » pour améliorer notre pratique. Le truc est d’essayer d’accepter ces situations et d’aller de l’avant en en tirant parti.
