Est-ce si difficile de se couler ? Voilà cinq méthodes efficaces.

Cet article vient d’ici

Il y a un nombre énorme de projets technologiques qui finissent mal. C’est une nouveauté pour personne. Que vous démarriez une compagnie qui vend un programme avec plein de travaux de programmation à venir, ou que vous possédiez une compagnie pas du tout technique qui loue des consultants ici et là afin de vous aider à intégrer des choses dans votre système, vous avez dû très certainement faire face à ce problème. Délais dépassés, budgets explosés, et échecs techniques sont si courants dans le monde informatique, en réalité, que c’est pas si choquant que ça, finalement, quand un gros projet a quelques années de retard et dépasse le budget prévu de plusieurs millions.

En 2003, par example, j’avais pris l’avion pour Los Angeles afin d’assister à une des conférences que Microsoft (NASDAQ:MSFT) organise occasionnellement pour les développeurs. Pendant l’événement, Microsoft a fait tout un tas d’annonces super excitantes au sujet de nouveautés hallucinantes sur le point de sortir pour la prochaine version de Windows. En revoyant mes notes, je vois qu’une des nouveautés vraiment importantes concernait quelque chose appelé WinFS. Je vous évite les détails ennuyeux, mais grossièrement WinFS proposait de combiner un système de fichiers du système d’exploitation (stocker des fichiers et des répertoires sur disque dur) avec des possibilités de base de données (ranger des enregistrements individuels de données pour une recherche et une récupération rapide) en un seul et unique gloubiboulga “fichier-base-de-données”.

C’était une entreprise on ne peut plus ambitieuse. WinFS était, en termes techniques, globalement la réorganisation du système de transport national pour donner la priorité aux bus volants. Oui, cela détruirait les compagnies aériennes, et oui, tous les garages auraient besoin de faire d’énormes travaux pour être élargis afin de pouvoir accueillir ces autobus nouvelle génération qui auraient des ailes, mais, hé, bon, c’est rien, ou le sortira en un an. Bon, au pire deux, allez, tope là !

Trois années se sont écoulées. Un manager à Microsoft, Quentin Clark pour ne pas le nommer, a écrit sur son blog que WinFS ne pouvait tout simplement pas être livré dans les temps, et qu’il était en train de retarder le lancement du dernier système d’exploitation de Microsoft. Donc, WinFS allait être retardé et livré, “peut-être”, en tant que fonctionnalité super originale dans une base de données à venir, validant par là le fait qu’il n’allait pas combiner base de données et système de fichiers, ce qui était la seule chose qui le rendait intéréssant. Donc, dites moi, comment pouvez-vous dire quand un de vos projets technologiques est destiné à être un autre WinFS ? Voici mes 5 premiers conseils qui vous assurent un échec sur un projet :

Erreur numéro 1 : débuter avec un équipe de développeurs médiocres.

Créer un programme, l’inventer et construire est une tâche difficile, et malheureusement plein de gens s’auto-proclamment développeurs et pourtant n’y arrivent pas du tout. Malgré le fait qu’une mauvaise équipe de programmeurs soit à mon sens la cause numéro 1 des échecs des programmes informatiques, vous ne pouvez pas le prédire en faisant une étude détaillée des CVs. Dans tous les domaines, en partant du programme, en passant par la logistique, jusqu’au service après vente pour le client, les gens sont beaucoup trop gentils entre eux pour parler du manque de compétence de l’un ou de l’autre, surtout s’ils travaillent côte à côte. Vous n’entendrez jamais personne dire “l’équipe n’était pas suffisamment perspicace, ou n’avait pas assez de talent pour sortir le produit.” Pouquoi blesser les gens ? C’est bien simple : si les personnes qui font partie d’un projet donné ne sont pas très bons dans ce qu’ils font, ils vont venir tous les jours au travail et malgré ça le programme ne sera pas fini. Et surtout, gardez bien en tête que cela ne sert à rien de lorgner du côté des compagnies off-shore prêtes à vous louer, ou vous trouver des personnes pour vous aider à avancer : dans la plupart des cas, je vous garantis qu’ils ne vont rien faire de plus que vous, et ne pourront pas empêcher le fait que vous embauchiez quelqu’un qui ne tient pas la route.

Erreur numéro 2 : posez un jalon par semaine.

Imaginons que vous refassiez votre cuisine. Que le type que vous avez engagé pour faire le travail a déjà fait plein de cuisines avant la vôtre, et peut estimer le coût du projet sans vous sortir les choses dans le détail. Tout ça c’est bien beau, mais il faut avoir conscience que les développeurs de programmes construisent systématiquement des choses qu’ils n’ont jamais construites auparavant. Si c’était le cas, il n’auraient qu’à vous vendre une copie sur un CD de leur programme. Des estimations à la louche sont impossibles. Ils ont un besoin impératif d’avoir un plan détaillé avant qu’ils commencent à écrire du code. Que vous soyiez le client, ou le chef de projet de l’équipe, votre boulot est de vous assurer qu’il y a un plan détaillé. Quand vous demandez à un développeur de donner une estimation à un plan, presque tous vous répondront en faisant un planning grossier, qui découpe les processus en semaines de travail. Ca pourrait sembler raisonnable, mais ça ne l’est pas. Si vous laissez une équipe faire un tel planning, avec des estimations grossières par gros paquets, (par gros paquets j’entends quelque chose qui prend plus de deux jours de développement), vous pouvez être pratiquement certain qu’ils ne prennent pas en compte chaque petit détail qui aura besoin d’être implémenté, et ce sont ces détails qui vont ajouter un énorme délai au projet.

Erreur numéro 3 : négocier la fin du projet.

Quoi de pire que d’accepter une planification dont l’échelle est si grossière qu’on parle, sur un projet informatique, en semaines ? Une chose : demander que l’équipe s’engage à terminer son travail beaucoup plus tôt que les estimations. Avec mon expérience, je vous certifice que la plupart des developeurs sont optimistes et vont vous suivre en s’engageant dans des négociations du genre “découper-tout-ça-autrement”. Vous serez super content, vous aurez un très zoli projet, sur lequel tout le monde s’est mis d’accord, et vous n’allez absolument jamais y coller.

Pensez à cela en ces termes : la mère du veau vêle entre le 15 et 16ème mois. Vous pourriez demander à cette mère de s’engager à 15 mois maximum et elle pourrait tout à fait dire “No problem !” Ou vous pourriez dire, “Quinze mois ? Vous êtes folle ? Il nous faut ça pour dans huit mois !” Bien sûr, beugler comme ça ne peut pas accélérer les choses, et même si vous réussissez à faire accepter ce délai à la maman, je vais vous confier un petit secret : elle ne vêlera jamais au huitième mois. Vous pouvez avoir un planning qui dit onze mois, mais vous aurez votre bébé en 15 mois, parce que dans tous les cas c’est le temps qu’il faut pour faire un veau. Seize mois, parfois.

Erreur numéro 4 : diviser les tâches équitablement.

Voilà une superbe façon de torpiller votre projet. Faites une liste de tous les travaux à faire, et, en milieu de projet, redistribuez-les à des personnes différentes afin de tout équilibrer. Si Marie a trop de travail, donnez quelques unes de ses tâches à John. Ca a l’air tout à fait logique, donc personne ne vous contredira.

Je vous promet qu’à moyen ou long terme, cela va inévitablement causer des problèmes. C’est parce que lorsqu’un développeur doit en remplacer un autre, on peut raisonnablement penser qu’il va avoir une efficacité d’un dizième par rapport à son prédécésseur. John va passer des heures entières à essayer de comprendre toutes les choses que Marie connaît déjà sur le bout des doigts dans son propre code. Et John ne résoudra jamais aussi rapidement les problèmes dans le code de Marie que Marie elle-même parce que notre Marie sait où sont cachées toutes les petites astuces et trappes à éviter.

Erreur numéro 5 : travailler jusqu’à minuit.

Imaginons qu’un projet doit prendre six mois à raison de 40 heures par semaines, pour être terminé. Si vous disiez à tout le monde de travailler 60 heures par semaine, vous pourriez finir le développement en quatre mois. L’équipe de programmation devrait même avoir envie de réussir ce challenge parce qu’ainsi ils auront la sensation d’être de vrais héros. (“Incroyable, cette équipe de mamans qui vont vêler en 4 mois, ils sont là même le week-end !”). Ca devrait fonctionner, non ? Devinez quoi. Il y a des centaines de livres qui établissent un fait qu’on ne peut plus nier : travailler plus d’heures n’aide en rien à sortir quelque chose plus vite. Edward Yourdon, directeur d’une bonne équipe de développeurs, et écrivain, a donné un petit nom à ce genre de projet : “marche funèbre.”

Le développement d’un programme demande un gros effort intellectuel. Même les meilleurs programmeurs peuvent rarement soutenir un niveau d’effort qui atteint quelques heures par jour. Derrière tout ça, ils ont besoin de se changer les idées, car c’est une façon d’aider le cerveau à se reposer, c’est pourquoi on a toujours l’impression qu’ils sont en train de se ballader sur Internet ou en train de jouer à des jeux quand on jette un coup d’oeil à ce qu’ils font

Les forcer à passer plus d’heures devant leur ordinateur ne va jamais se traduire par plus de production, ou si c’est le cas, ce sera de la mauvaise production. Quand leurs cerveaux sont complètement frits, les développeurs créent plus de problèmes qu’ils n’en réparent, en écrivant du mauvais code ou en créant des bogues à n’en plus finir. Et si vous bannissez Internet et les jeux multijoueurs pour les forcer à garder la tête dans le guidon et à écrire du code après les heures où, normalement on se couche, eh bien, il vont très certainement démissionner. Faire une “marche funèbre” n’est pas la seule manière de faire exploser les délais, le budget ou les deux. Mais c’est une manière certaine d’y arriver.

Si ce sont toutes les choses à éviter, comment peut-on s’assurer qu’on projet va dans le bon sens ? En premier lieu, vous avez intérêt à embaucher des superstars. A Fog Creek, on lis en moyenne 400 CVs avant une embauche en CDI, parce qu’un bon développeur peut être dix fois plus productif qu’un développeur normal.

Deuxièmement, demandez une découpe très précise des tâches à faire à chaque developeur. Oui, c’est difficile pour un développeur de prédire le temps qu’il faut pour une nouvelle application. C’est pour cela qu’il faut qu’ils fassent vraiment de bons plans, bien fiables, avant chaque début de projet.

Une fois que vous avez le planning entre les mains, n’essayez pas de réduire la durée. Si le projet ne peut pas être achevé dans une durée que vous estimez raisonnable, la solution est de négocier un planning qui vous convient mieux, mais ne pas toucher à la durée totale. Ou bien éventuellement d’annuler quelques évolutions. Ou, enfin, de mettre de côté certaines options qui ne sont pas forcément nécéssaires.

Pendant le projet vous allez être tenté parfois de réassigner le travail en pensant que cela ira plus vite. Dans ce cas faites très attention. De nouveaux développeurs mettent toujours du temps avant de trouver leur vitesse de croisière et d’arriver, s’ils y arrivent, à la vitesse de leur prédécésseur. C’est bien entendu positif de faire tourner les développeurs sur différents types de travaux, ainsi de cette façon personne n’est irremplacable, mais je le fais très précautionneusement et je réserve dans ce cadre trois semaines complètes sur le planning pour le développeur qui arrive et qui prend la nouvelle place, et une semaine de plus pour celui qui s’en va car il va devoir apprendre le code à son remplacant.

Finalement, encouragez votre équipe à travailler au maximum 40 heures par semaine. Non non, je ne blague pas. Sérieusement. A part de manière vraiment occasionnelle, où nous avons des impératifs vitaux, l’équipe de Fog Creek travaille 8 heures par jour au maximum. Dans notre monde qui devient de plus en plus technologique, il est vital de considérer un gros projet comme un marathon et non pas comme un sprint.