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.