Suite aux différentes formations sur TFS et Team Build que j'ai pu animer, je me suis retrouvé à beaucoup échanger sur la manière de réussir un projet. Je n'ai pas de recette miracle, je n'ai donc pas la prétention de dire ici comment faire. Je crois que l'on pourrait parler durant des heures sans trouver LA solution miracle. Pour faire court, il n'existe pas « UNE solution unique » qui marcherait pour tout le monde. Dire le contraire serait vraiment malhonnête.

A contrario, je me suis rendu compte que lorsqu'il s'agit de dire comment raté un projet, les choses sont plus faciles. Mes exemples faisant souvent rire "jaune", je me suis décider à en lister quelques-uns.

Parmi les critères d'échec retenus, il y a :

• Non-respect des délais et des coûts.
• Insatisfaction et/ou perte du client.
• Démotivation de l'équipe.

    

Je préviens donc que tout ce qui est dit ici est du troisième degrés (au moins). C'est un peu mon « cadeau humour » pour noël.

1. Rigidité cadavérique

La solution la plus simple pour amener son projet à un état de rigidité cadavérique consiste à :

• Ne pas répondre aux demande du client.
• Faire rédiger les compte rendus de réunion par des personnes qui n'étaient pas présentes lors de celles-ci.
• Rédiger des documents avec des grands vides sans description et avec pour seul contenu : « A faire ». Surtout, ne pas contacter le client pour savoir ce qu'il faut faire.

    

2. Toujours dire "Oui"

C'est bien connu, le client est roi. Et si le client n'est pas roi, c'est votre patron qui l'est. Donc :

• Ne jamais dire non aux demandes du client et/ou ne pas discuter ses décisions, même si votre équipe n'est pas en mesure de traiter la demande. Mieux vaut faire semblant d'avoir des difficultés à produire le résultat attendu pour ne pas y arriver à la fin. Travailler pour un client qui ne paiera jamais la facture, c'est mieux que de ne rien faire.
• Ne jamais demander plus d'informations quand le client exprime un besoin. Il vaut mieux lui dire « oui monsieur » que de lui dire clairement que l'on n'a pas bien compris. Cela fait plus pro et n'apporte rien au projet (100% d'échec garantis).
• Toujours accepter les projets que vous ne pourrez pas supporter dans le temps. Exemple : 1) en 2016, proposer à votre Client d'utiliser SilverLight 4 même si ce n'est déjà plus supporté par Microsoft. 2) en 2018 proposez la migration vers Silverlight 5. 3) En 2020, partez en courant, ou proposez un bon vieux site statique en ASP sur 2000 Server (surtout pas de l'ASP.net, votre client n'étant pas habituer à avoir une plateforme moderne)

3. "Les développeurs se démerderont"

• Toujours laisser son équipe dans le flou le plus total. Ce n'est que dans le flou que votre équipe vous prendra pour une lumière.
• Moins votre équipe en sait, plus elle arrivera à ne pas faire ce qui est attendu. En plus, même si le problème vient de vous, vous pourrez dire que c'est l'équipe qui ne sait pas travailler. Démoralisation garantie avec de probables démissions avant la fin du projet.

4. Rigidité administrative

• Plus vous serez axé sur votre organisation rigide, et moins vous vous adapterez aux besoins du client.
• Une bonne chaine de commandement vaut mieux qu'une équipe qui produit. Idéalement, il faut prendre un chef de projet (qui ne code pas) par développeur. Si vous avez deux développeurs, il faut donc deux chefs de projets. Dans ce cas, il faut donc un chef de chefs de projets. Si vous avez plusieurs projets en parallèle, prenez un chef de chefs de chefs de projets. (petit projet = gros effectifs = gros budget = rejet presque garantie de celui-ci). Si en plus, vous pouvez prendre un ou deux consultants qui ne produises rien, vous êtes au top. Trou budgétaire et contre productivité garantis.

5. Rien ne sert d'organiser ses échanges

• Maximiser le nombre de réunions sans ordres du jour ni objectifs. La perte de temps sera maximale. Les déplacements inutiles génèreront de la facturation inutile. Ceci réjouira à coup sûr votre client.
• Ne pas fournir de plan d'action en fin de réunion. Ce serait dommage qu'une réunion serve à quelque chose. Il serait même pire que tout d'en revenir avec du travail à faire.
• Ne pas poser de questions en réunion ou conf-call. Il serait dommageable pour le projet de revenir d'une réunion avec des réponses.

6. Documenter tout et surtout rien !

• Surtout documenter tout en utilisant un maximum d'acronymes. Mais surtout n'ajouter jamais de glossaires à vos documents. Il serait dommage que vos collègues aient une chance de comprendre.
• Un long document de spécification vous garantit que personne ne le lira. Tranquillité assurée. Vous pouvez passer au sabotage d'un autre projet. Personne ne vous contactera pour avoir plus d'informations sur celui-ci.
• Changez un mot dans une spécification technique de 600 pages. Publiez le document comme étant révisé et demandez à vos collègues d'adapter leur travail à cette évolution. Mais ne dites surtout pas quelle page a été corrigée.
• Les documents de spécifications sont tous les mêmes. Prenez toujours le même contenu type sans jamais le mettre à jour. Cela fait toujours plus pros d'avoir plein de contenu dans ces documents, même si il n'ont rien à voir avec le sujet (ex: expliquer ce qu'est AJAX pour une application WPF). Sérieux garantie au près du client et découragement assuré des collègues.
• Inventez des mots, des terminologies et méthodologies qui n'existent pas. Cela en jette et fait pro. Mon exemple préféré : le cycle en W. Il y a encore plus « à la mode », avec le « Cycle en V agile ». Voir Merise agile. Si vos interlocuteurs connaissent le métier, votre humiliation est garantie. Si le client répond avec les mêmes mots que vous, méfiez-vous !

    

7. Toujours être indispensable et indisponible

• Garder un maximum d'information pour vous. Moins les autres seront en mesure d'accomplir le projet seul, plus vous serez indispensable, et plus votre absence ralentira le projet.
• Toutes les communications doivent passer par vous, et rien que vous. Ainsi, la communication sera bien ralentie.
• Trouvez-vous une technique pour faire office de « contrôleur des travaux finis ». Vos collègues ne doivent pas être en mesure de s'autogérer ou de s'autocontrôler. Exemple : si vous avez une démarche qualité, ne communiquez pas les règles à respecter. Comme cela vous pourrez créer des tâches correctives à profusion. Démotivation de l'équipe garantie. L'utilité de votre poste ne fera aucun doute pour votre direction. Après cela, évitez tout de même de tourner le dos à vos collègues… on ne sait jamais.

Même si la liste est loin d'être complète je m'arrête là ;)