Comment gérer les projets de programmation qui échouent?

Il n'est pas rare que des projets échouent.

En tant que programmeur, comment gérez-vous les projets qui échouent?

Quelques définitions de l'échec:

• Manque le délai.
• Le code et la fonctionnalité ne font pas ce qu'ils sont censés faire.
• Le logiciel devient un vapor-ware ou un nombre infini de phases, essentiellement non livrables.

Ou peut-être avez-vous votre propre définition de l'échec.

Commencez-vous à pointer du doigt? Vous blâmez-vous, les exigences, la technologie, la gestion, le client, etc.? Faites-vous une séance de leçons apprises en équipe?

Vous devez faire les leçons apprises pour tous les projets, échoué ou réussi. Il y a beaucoup à apprendre d'un bon projet.

Les vrais projets qui ont échoué ont été très rares pour moi. En plus de comprendre ce qui s'est passé, je fais la chose «demander pourquoi 5 fois» pour essayer de trouver des causes sous-jacentes. Il y a aussi la question de savoir pourquoi je n'ai pas remarqué ce qui se passait et que je fais quelque chose ou au moins que je m'en aille.

Je pense que la première position de chacun est de tout blâmer - le client, la technologie, le problème commercial abordé, la méthodologie, les membres de l'équipe, la langue, la plate-forme, même la façon dont nous prenons notre café le matin. La bonne chose à propos d'une rétrospective (même si cela ne se produit que dans votre propre tête) est la possibilité de se réconcilier avec certains ou tous ces facteurs et de réaliser qu'ils n'étaient pas le problème.

Dans mon seul véritable échec des 30+ dernières années, le projet était en attente depuis des années à notre arrivée. Nous avons réglé les exigences. L'un provenait de la direction et des centaines d'utilisateurs finaux. Nous avons écrit du code, beaucoup de code, certains brillants. Il y avait des tests et des tests d'acceptation et des changements et des arguments et des demandes de changement et du travail non rémunéré et du travail rémunéré et des boulons de dernière minute et de l'humour surréaliste et des escalades vers les vice-présidents et tout cela. Finalement, tout cela s'est arrêté. La raison de l'échec était que l'exigence de gestion unique était inacceptable pour les utilisateurs finaux. Et peu importe combien de choses ils ont réussi, ils ne pouvaient pas passer au-delà de celui-là et n'accepteraient jamais le système. Mais la direction n'en aurait pas autrement. Donc c'était ça et bien que nous ayons eu beaucoup d'argent, c'était finalement

Je travaille toujours dans cette technologie, j'utilise toujours ces processus et je travaille toujours avec les mêmes personnes. Je ferais même un autre projet pour ce client. Mais lorsque les utilisateurs finaux disent qu'ils n'aiment pas quelque chose que leur propre gestion a injecté dans les exigences, je me souviendrai qu'écrire un bon code qui fonctionne ne vous protège pas d'un projet qui a échoué. Et je vais y faire quelque chose, pas un an ou deux plus tard.

Éloignez-vous, salope pendant quelques jours à une semaine pendant que j'évite de faire des choses importantes, puis essayez de comprendre ce qui s'est mal passé et comment ne pas le laisser se reproduire.

Il y a un grand livre sur le sujet appelé la marche de la mort: http://www.amazon.com/Death-March-2nd-Edward-Yourdon/dp/013143635X

Je vous suggère fortement de le lire. Vous pouvez reconnaître votre ou vos projets dans de nombreuses descriptions.

Il n'y a pas de réponse unique car cela dépend fortement de nombreuses composantes complexes de votre organisation, y compris la politique ...

J'ai blâmé tout le monde sauf moi ... haha, je plaisante. Je pense que j'écris un doc "Mea Culpa", avec toutes les choses "que j'ai faites" mal. peut-être n'aide pas à ce projet, mais est un bon moyen de ne pas répéter les mêmes erreurs