Vous avez déjà dû vous parler plus ou moins complètement d'un projet?

Question

J'ai récemment eu un projet qui a failli échouer lamentablement. Pour moi, c'est un échec complet, mais d'une manière ou d'une autre, cela a échoué. Il y avait beaucoup de bonne volonté de tous les côtés et la responsabilité était partagée également. Mais maintenant que je mets les fichiers du projet en "stockage à froid", je me demande ce qui va se passer dans "le pire des cas". Vous êtes sur un bateau qui coule, la complexité explose parce qu'il y a un (pas si) minuscule trou dans la spécification, le client est totalement flippant, il ne peut tout simplement pas être fait période

Jamais eu à se parler complètement sur un projet à mi-chemin? Comment cela s'est-il passé?
Quelle a été votre réaction et qu'avez-vous fait (ou voulu faire) pour éviter de telles choses à l'avenir? Comme "A partir de maintenant c'est scrum ou buste", "Darn, je ne ferai plus jamais xyz", "hm, est-ce que ma couverture d'assurance" ou peut-être même "merde arrive, arrêtez de pleurnicher et de surmonter"?

Answer 1

Nous avions un projet où une exigence était un temps de réponse garanti. Après quelques mois de développement, nous n'avons pas pu tenir cette promesse. Et ce qui est pire, nous avons gardé le problème sous le capot trop longtemps. La présentation s'est déroulée comme suit: C'est le dernier jalon et d'ailleurs nous avons manqué ce truc de temps de réponse. Désastre complet. Je n'ai pas participé aux négociations suivantes, mais d'après tout ce que j'ai entendu, c'était moche. Il y avait des problèmes techniques et des défauts de conception qui devaient être résolus sans aucun doute. Mais à mon avis, les conséquences les plus cruciales ont été les suivantes: nous accordons beaucoup plus d'importance aux rapports de situation maintenant. Pas de manière micro-gestionnaire, mais au moins plus concis. Les problèmes doivent éclater beaucoup plus vite. Et les cycles de présentation internes et externes sont maintenant beaucoup plus courts qu'ils ne l'étaient à l'époque. Cela seul n'aurait pas résolu le problème bien sûr. Mais nous aurions pu mettre plus de ressources combinées à temps dans la question. Et le client n'aurait peut-être pas réagi aussi fort que lui. Je pense que vous ne pouvez pas obtenir la probabilité d'échec à zéro pour cent, alors oui "merde arrive, surmontez-le". Mais vous pouvez travailler pour l'obtenir aussi bas que possible. Et vous pouvez travailler sur ce que vous pourriez appeler l'ampleur de l'échec. Par conséquent: faire les contrôles de statut tôt, régler les problèmes tôt, ne pas laisser les fissures devenir des failles de la coque.

Answer 2

Je démissionne d'un projet à mi-chemin une fois, je ne peux pas dire que je fuyais des problèmes, c'était surtout qu'un autre projet m'intéressait mieux. Je suis allé voir mon patron, je lui ai expliqué comment je pouvais contribuer à l'autre projet alors que je n'étais pas très à l'aise avec mon projet actuel. Soyez honnête avec votre patron, c'est la meilleure façon de finir où vous serez vraiment heureux.

Une chose que j'ai fait beaucoup de temps est d'être forcé de passer à un projet à mi-chemin dans les ennuis. Travailler comme un fou à cause des erreurs des autres n'est pas la meilleure chose pour la motivation. Le pire, mieux vous êtes à enregistrer un projet comme celui-ci, le plus enclin vous être affecté à nouveau parce que vous êtes "si bon à cela".