Quels sont les signes avant-coureurs d'une catastrophe imminente à surveiller sur un projet? [fermé]

Avoir travaillé sur un projet ayant échoué est l’une des rares choses que la plupart des programmeurs ont en commun, quels que soient le langage utilisé, le secteur ou l’expérience.

Ces projets peuvent être d'excellentes expériences d'apprentissage, des désastres (ou les deux à la fois!), Et peuvent se produire pour une multitude de raisons:

• changement de direction de la haute direction
• équipe sous-qualifiée / sous-financée
• émergence d'un concurrent supérieur pendant le cycle de développement
• sur / sous gestion

Une fois que vous avez travaillé sur quelques projets de ce type, est-il possible de reconnaître à un stade précoce exactement quand un projet est voué à l'échec?

Pour moi, un gros signe est d'avoir une échéance externe stricte et rapide associée à un glissement des fonctionnalités . J'ai vu des projets bien planifiés et se dérouler dans les délais impartis qui se déroulaient dans des conditions horribles une fois que les demandes de fonctionnalités en retard ont commencé à arriver et ont été ajoutées au "produit livrable" final. Les auteurs de ces demandes ont reçu le surnom de Columbo , car ils quittaient rarement la salle sans demander "juste une dernière chose".

Quels sont les signes d’avertissement que vous recherchez qui déclenchent l’alarme d’un destin imminent dans votre tête?

Codage héroïque

Coder tard dans la nuit, travailler de longues heures et faire beaucoup d’heures supplémentaires sont un signe certain que quelque chose a mal tourné. De plus, mon expérience est que si vous voyez une personne travailler tard dans le projet, cela ne fera qu'empirer les choses. Il le fait peut-être juste pour obtenir son dernier long métrage, et il peut réussir. Cependant, le codage de cow-boys de ce type est presque toujours le résultat d'un échec de planification qui en causera inévitablement davantage. Donc, plus tôt dans le projet, vous le verrez, pire il finira par s'aggraver.

Quand les programmeurs commencent à gagner l'argument "Le code est horrible, il faut tout recommencer à zéro." sur toute application mature.

Vous pouvez penser que vous pouvez mieux le construire ou comprendre le problème de manière plus complète, mais ce n'est vraiment pas le cas. Oh, et tous ces patchs laids? Ce sont des solutions aux problèmes du monde réel que vous allez probablement réintroduire dans la réécriture.

De plus, un jour, vous allez devoir expliquer au chef de projet pourquoi, après 6 mois de travail, vos capacités représentent presque 85% de la capacité et 150% des problèmes rencontrés par l'application à ses débuts.

Un nouvel outil pour résoudre les problèmes.

Quand les gens commencent à planifier l’utilisation d’outils inconnus, cela ne me dérange pas, mais je garde l’œil sur eux. Quand ils commencent à planifier tous les avantages annoncés de ces outils dans le calendrier, je m'inquiète. Exemples amusants:

• Nous pouvons réduire le calendrier d'un mois car nous allons essayer d'utiliser un langage orienté objet (même si nous ne disposons que de c développeurs).
• Nous allons essayer cette nouvelle méthode Scrum qui résoudra tous nos problèmes de processus!
• Je sais que le projet est à mi-parcours, mais si on changeait les ORM en quelque chose de nouveau?

Les nouvelles technologies et les pratiques sont bonnes, mais vous n’obtenez presque jamais tous les avantages.

Pour moi, le plus gros problème, et que vous pouvez immédiatement identifier, est lorsque les entreprises considèrent les exigences écrites comme une perte de temps.

Donc en gros; Pas d'exigences écrites

C'est le baiser de la mort.

Déconnexion de la direction

Lorsque les responsables des délais, des fonctionnalités, de la dotation en personnel, etc., sont déconnectés des personnes chargées de l'exécution du projet. Cela peut mener à:

• Fonction rampante lorsque le client parle avec quelqu'un qui ne comprend pas le coût de la fonctionnalité
• Syndrome du mois de travail, lorsque de nouveaux développeurs sont projetés assez tard dans un projet pour être plus un obstacle qu'une aide
• Des délais irréalistes, créés par des personnes qui doivent faire face aux conséquences commerciales des décisions relatives aux délais mais pas aux conséquences de la mise en œuvre.
• Des produits qui ne résolvent pas le problème, lorsque la gestion au milieu entrave la communication entre clients.
• Mauvaise gestion des risques, où les problèmes potentiels ne sont pas communiqués suffisamment tôt entre les développeurs et la direction.

Ainsi, quand il semble que la direction ne s'intéresse pas au projet, communique mal, n'écoute pas les clients, ou n'écoute pas l'équipe de développement, ne cherche pas à atteindre le but recherché.

1. Quand les principaux développeurs partent et que la direction s'en fiche

2. Lorsque les développeurs clés partent et qu'aucun des autres développeurs ne s'en soucie

Le numéro un est généralement révélateur des gestionnaires qui sont très déconnectés de la dynamique de l'équipe (qui est la "super star 10x", qui sont les bons programmeurs et comment ils interagissent les uns avec les autres, etc.).

Le numéro deux indique généralement un manque d'intérêt important de la part des développeurs restants.

La première fois que quelqu'un, généralement la direction dit "nous n'avons pas le temps de ..."

Habituellement, quelque chose que nous n’avons pas le temps de faire précéder, comme la documentation ou les révisions de code (qui détecte et corrige statistiquement plus de bogues que tout autre, y compris toutes les formes de test)

Laissez le client, le marketing ou la direction choisir une date, puis essayez de revenir en arrière selon un calendrier imaginaire

Lorsque la direction est trop faible pour dire "Non" à l'entreprise.

Cela conduit à des délais qui ne seront jamais respectés, ce qui conduit à un manque de confiance dans le service informatique, ce qui conduit les développeurs à créer des piratages (par exemple, une base de données d'accès fonctionnant sur une machine ... quelque part), ce qui conduit à un cauchemar pour le service informatique. système critique 'doit être migré, ce qui conduit à ...

Le premier mauvais signe auquel je puisse penser, c’est lorsque la direction n’est pas disposée à transmettre les mauvaises nouvelles à la chaîne ou au client, dans l’espoir que cela va disparaître - c’est-à-dire que la direction n’a pas l’idée de vouloir. Je ne peux pas penser à combien de fois, les développeurs ont prouvé qu'ils ne pouvaient pas respecter l'échéance des semaines, voire des mois, et pourtant personne ne veut en informer le client. J'ai rarement vu un client qui ne voulait pas imposer une échéance lorsqu'il existe une véritable raison de l'expliquer suffisamment à l'avance; J'ai souvent vu un client énervé quand on lui disait le jour-limite qu'il ne serait pas respecté et qu'il ne le serait pas non plus le lendemain, mais dans deux mois. J'ajouterais à juste titre qu’ils remettent en question vos processus - comment se fait-il que vous ne le sachiez pas plus tôt?

Un autre signe certain que l'échec est imminent est d'affecter de nouveaux développeurs à la partie la plus difficile et la plus critique du processus plutôt qu'aux personnes qui comprennent déjà le système actuel. Ensuite, ne les regardez pas attentivement pour voir s’ils travaillent vraiment correctement ou ont des questions (BIG BIG RED FLAG s’il n’ya pas de questions). Les nouveaux employés doivent être surveillés jusqu'à ce que vous sachiez qu'ils possèdent réellement les compétences qu'ils prétendaient avoir. Je peux encore me souvenir d’avoir passé un été pénible à refaire le travail (déjà dépassé la date limite) d’un nouvel employé qui a obtenu un élément essentiel d’un projet et a dit à tout le monde que tout allait bien pendant des mois, puis a quitté sans préavis une semaine après la date limite. et rien de ce qu'il a fait n'était utilisable.

Un autre signe certain d'échec est lorsque les développeurs travaillent sur des éléments qui dépendent d'autres tâches à effectuer en premier et que ces tâches ne sont pas terminées ou même démarrées. Si la direction ne peut pas obtenir le travail assigné dans le bon ordre, vous allez dans les tubes.

Bien sûr, le glissement des fonctionnalités sans repousser l’échéance à chaque fois est l’un des signes les plus courants de la situation. Vous ajoutez 20 heures de travail à mon assiette, la date limite est décalée de 20 heures. Sinon, le projet échouera, c'est garanti.

Un signe certain que j’ai vu dans ma carrière, c’est quand la direction commence à parler d’inviter plus d’organismes pour gagner du temps. En fait, je n'ai jamais vu plus de corps dans l'aide d'un projet.

Lorsque des responsables non techniques commencent à insister pour prendre des décisions techniques, ils ne sont en aucun cas qualifiés pour le faire. Grand, grand drapeau rouge!

Le signe le plus évident est un taux de roulement élevé du personnel. Lorsque tout le monde cherche un nouvel emploi, vous devriez probablement le faire aussi.

L'autre signe très évident est le manque de progrès. Si une année s'est écoulée et qu'il ne semble pas que vous soyez plus près de la cible, vous êtes condamné. Cela se produit surtout lorsque les exigences changent plus rapidement que vous ne pouvez les implémenter.

Membres de l'équipe s'ennuie.

Vous avez "90% terminé", la livraison aura lieu la semaine prochaine, mais vous pourrez continuer car il ne vous reste plus qu'à "tester".

• Tout le monde est épuisé physiquement et mentalement
• Les clients / utilisateurs sont clairement mécontents des échelles de temps ou de ce qu'ils voient
• Le beau design à l’origine se sent compromis
• Vous êtes résigné à l'expédition avec quelques bugs relativement importants que vous préféreriez résoudre mais que vous ne pourrez pas résoudre.
• Votre fierté réside dans l'acte d'expédition plutôt que dans ce que vous envoyez - plus proche d'une mentalité de survivant que de fierté professionnelle
• L'équipe a peur qu'il y ait certaines choses qui ne fonctionnent pas et ignore ces sections et espère que tout ira pour le mieux, car elles ont peur de ce qui pourrait s'y trouver.
• Tout le monde est convaincu qu'ils ont dépassé les attentes (et ils ont raison)
• Les gens montrent des signes d'épuisement professionnel (pessimisme général, désintérêt, colère)

(Cribbed de la dynamique du développement logiciel de Jim McCarthy ).

Cowboy coders, big egos et acceptation de la part de la direction

Si le projet prévoyait une seule itération de conception, de développement, de test et de déploiement - la cascade classique - pour un projet de plus d'un mois, je parcourrais un kilomètre et demi.

Vous n'avez pas besoin d'être totalement agile, mais la brièveté des cycles de développement vous permet de démontrer les progrès à tout le monde (client, direction et développeurs eux-mêmes) et de faire face aux nouvelles exigences lorsque l'inévitable se produit.

Les développeurs en cours d'exécution sauvage sur la gamme

Cela s'est produit lorsque vous vous êtes rendu compte que d'autres développeurs (ou, malheureusement, vous-même) ont développé un composant qui varie de manière significative par rapport à sa conception, et que cela n'est pas pris en compte avant les tests système / UAT. Je ne parle pas de bugs; Je parle de composants système importants dont certaines fonctionnalités sont manquantes ou dont la fonctionnalité n'a pas été demandée et qui ne passeront jamais à l'UAT sans une retouche importante Ce problème indique que:

• Votre système qualité est en panne. pourquoi le développeur concerné n’a-t-il pas abordé le problème lors de la phase de conception / mise en œuvre. Le code n'a-t-il pas été revu / inspecté? Pourquoi les tests unitaires et d'intégration ne l'ont-ils pas repris? Si vous n'avez pas mis en place de tests unitaires / d'intégration cohérents, vous êtes foutus.
• Votre chef de projet / responsable technique ne contrôle pas leur équipe de développement. S'ils ne peuvent pas amener les développeurs à fournir ce qui est requis, ils ne pourront jamais fournir une solution complète.

Lorsqu'un développeur clé d'un projet n'a pas enregistré de code depuis des semaines et qu'un jalon important se prépare.

C’était un travail de sous-traitance et les développeurs et PM les plus expérimentés ont décidé de s’associer pour tenter d’obtenir une réduction plus importante. L’autre développeur a donc pris trois semaines en otage du code critique. En fin de compte, nous avons congédié le premier ministre incompétent (qui passait six mois à mettre le projet sur un cap pour la ruine) et avons discuté avec le développeur.

Autrement dit, le reste du projet consistait en une marche de la mort masochiste, le gel des spécifications a été retardé, le client a reçu un ensemble de caractéristiques de concession pour compenser les terribles horaires du départ du PM, et la qualité du projet a été compromise tout autour à cause de cela.

Le Premier ministre a même eu le culot de s’envoler pour la CDR (Critical Design Review), mais seulement pour laisser tomber la réunion avec le client et lui faire perdre la tête. Quand il a demandé que ses frais de voyage soient payés dans le cadre du projet, on lui a poliment demandé de se faire sa propre idée.

Je peux facilement identifier au moins 5 des autres réponses trouvées ici qui ont affecté ce projet. En bref, j'ai appris beaucoup de dures leçons sur mon premier projet de codage sérieux.

Mon premier signe a été quand ils ont demandé combien d'heures supplémentaires nous nous engagerions pour les dix prochaines semaines et ont offert aux travailleurs salariés une prime pour le travail effectué en fonction du succès du projet et du respect des délais.

Autres signes importants que j'ai vus: La définition des exigences dépasse le calendrier prévu et la date de fin n'est pas déplacée. Nous étions en retard avant même de pouvoir commencer. Ils ont pris le temps de concevoir, nous avons donc commencé sans conception de base de données ni conception de site, mais nous espérions pouvoir livrer à temps, notamment en effectuant des importations dans des tableaux non conçus et créés.

Lorsque les éléments du chemin critique sont exécutés simultanément au lieu d’être dans l’ordre. (Si je dois utiliser l'outil X et que le programmeur A commence tout juste à le construire, cela va retarder ma tâche.)

Lorsque les gestionnaires commettent du code sur Thanksgiving.

Lorsque vous commencez à recevoir des courriers électroniques dont l'horodatage est supérieur à 23 heures et inférieur à 6 heures.

Quand chaque question sur la façon de gérer une certaine complexité rencontre la même réponse, "Ne vous inquiétez pas pour cela pour le moment."

Quand ils répondent encore à des exigences, le jour où vous irez à l’assurance-qualité ou que vous irez en direct.

Lorsque vous commencez à avoir des réunions quotidiennes qui prennent plusieurs heures pour discuter de votre manque de progrès. Oh, ce serait parce que je suis en réunion toute la journée. Réunion quotidienne de 5 minutes, amende, réunion quotidienne qui dure plus d'une heure, pas très bien.

Lorsque l'équipe de base de données et l'équipe d'application ne se parlent pas.

Lorsque le client ne peut pas fournir les informations promises à temps. Surtout lorsqu'il s'agit de fichiers d'importation de données et que vous avez besoin de ces données dans la base de données pour vérifier le fonctionnement du code.

Lorsque vous envisagez d'installer un feu de signalisation à l'extérieur du bureau d'un responsable, vous devez savoir s'il est prudent de l'approcher ce jour-là.

Je pense qu’il est généralement facile de repérer un projet en échec lorsque l’échéance approche. Comme vous l'avez dit, la combinaison de fonctionnalités avec une échéance définie est un moyen sûr de tuer un projet.

Cependant, la clé est de repérer d'avance un projet défaillant. Je pense que le seul véritable "signe de malheur" dans ce cas serait un manque complet de définition de "quand avons-nous terminé". Si nous ne le savons pas au décalage, nous sommes voués à l'échec, OMI.

J'ai participé à trois marches de la mort au cours des cinq dernières années. Voici quelques éléments qui ont contribué à mon intuition imminente.

• La société décide de confier à des développeurs débutants la conception et le développement de nouvelles fonctionnalités et assigne des développeurs plus coûteux à la résolution de leurs problèmes.
• La société sous-traite des composants logiciels critiques à des sociétés du tiers monde qui ne possèdent pas l'expertise requise dans le domaine.
• Les cycles temporels sont si rapprochés que la santé des populations se dégrade.
• Les pilules que votre équipe prend pour se droguer chaque soir, arrêter de travailler.
• Le client envoie les ordres de changement plus rapidement que vous ne pouvez les analyser.
• Vous êtes censé fournir plusieurs années de travail dans quelques semaines, mais la direction refuse de geler les fonctionnalités.
• Vos fournisseurs de matériel informatique ont clairement du mal à fournir un produit utilisable dans les délais impartis, et les décideurs de votre entreprise n’envisageront aucune solution de remplacement.
• Les prototypes dont les développeurs ont besoin pour avoir une chance de respecter le calendrier probablement irréaliste sont retirés et confiés aux meilleurs dirigeants pour qu'ils se sentent bien.
• Semaine 1: "Oh, merde, le code est bogué. Tout le monde a cessé de faire de nouvelles fonctionnalités et corrige des bugs." Semaine deux: "Oh, merde, nous n'allons pas respecter le calendrier des fonctionnalités. Tout le monde a arrêté de réparer les bugs et écrit de nouvelles fonctionnalités." Répétez indéfiniment.
• Le développement est effectué dans un pays et l'assurance qualité est effectuée dans un autre pays à l'autre bout du monde. Une communication aller-retour à propos d'un bogue nécessite toujours 24 heures et au moins une des personnes impliquées discute de problèmes techniques complexes. dans une langue qu'ils ne maîtrisent pas.

Pour moi, c’est lorsque les responsables de l’ensemble des fonctionnalités (gestionnaires, propriétaires de produits, clients, etc.) cessent de se préoccuper de leurs réponses ou semblent avoir un air désespéré. Les questions sur les fonctionnalités rencontrent de l'apathie et du découragement. Il est clair qu'ils ont perdu leur investissement ou leur confiance dans le projet.

Cela m'est arrivé lorsqu'un projet sur lequel je dirigeais avait le "changement de cœur de la direction". Je posais des questions sur la façon dont cela devrait fonctionner et tout à coup, personne n’a eu une véritable opinion.

Un peu plus tard, le projet a été annulé et tout le code magnifique que j'avais écrit a été abandonné.

Paul Vick a écrit un excellent article il y a plusieurs années sur les projets de trous noirs . Je pense que tous les conseils sont pertinents. (J'ai modifié la longueur des éléments et des résumés.)

• Des objectifs absurdement grandioses . Like "réinvente fondamentalement la façon dont les gens travaillent avec les ordinateurs".
• Délais complètement irréalistes . Habituellement, c'est parce qu'ils croient qu'ils peuvent réécrire le code base d'origine beaucoup, beaucoup moins de temps que prévu.
• Croyances irréalistes sur la compatibilité . C'est comme croire que vous pouvez réécrire et préserver toutes les petites bizarreries sans effort supplémentaire.
• Toujours "six mois" à partir d'échéance majeure qui semble ne jamais arriver . Ou, si cela arrive, un autre jalon est ajouté à la fin du projet pour compenser.
• Doit consommer d'énormes quantités de ressources . Habituellement, en aspirant le sang d'un ou de plusieurs produits établis.
• Impliquez-vous en utilisant une nouvelle technologie qui n'a pas encore fait ses preuves . En tant que tels, ils ont la possibilité de résoudre tous les problèmes d'évolutivité avec la nouvelle technologie.

Je traduis mentalement "Tout va bien. Nous n'avons rien à craindre." "Nous sommes tous foutus" à chaque fois que j'entends dire que la direction le dit. Vous entendez généralement les responsables le mentionner de manière fortuite lors de réunions sans lien entre eux ("Oh et au fait, tout va bien. Il n'y a aucune raison de s'inquiéter!"), Mais il est encore plus grave de faire convoquer une réunion à cette réunion.

Je n'ai pas encore entendu un responsable dire quelque chose dans ce sens et que cela ne soit pas un mensonge.

quelques points d'un projet mort auquel je faisais partie:

• La direction double l'équipe pour finir plus vite.
• les développeurs commencent à "enterrer" les bogues pour respecter les délais, et bien que ce soit évident, il est ignoré lors de la révision du code.

Lorsque la direction tire le projet dans différentes directions simultanément, le chariot reste immobile.

J'ai déjà été impliqué dans un projet géré par deux gars. Soit ils ne se parlaient pas ou chacun avait un ego à résoudre, mais ils ordonnaient notre travail dans une direction opposée toutes les semaines environ. Il n'a pas fallu longtemps pour réaliser qu'il n'y aurait jamais de résultat. Heureusement ma participation n'a duré que quelques mois.

Voir cet article succinct: When IT Projects Go Right .

L’absence de l’un quelconque des éléments énoncés dans l’article devrait faire sonner les sonnettes d’alarme:

Donc, assurez-vous que votre projet a tout ce qui suit, sinon vous devriez être inquiet:

(pour citer l'article ci-dessus :)

1. "La première est qu'ils reposent sur une vision claire de ce qui doit être réalisé."

2. "La deuxième caractéristique concerne le soutien et l'engagement des différentes parties impliquées dans l'entreprise, en particulier la direction."

3. "Troisièmement, il faut comprendre les problèmes à résoudre."

4. "La dernière caractéristique commune est que suffisamment de ressources et de compétences ont été mises à disposition."

Statistiquement, le démarrage d’un projet logiciel est un signe raisonnable de son échec, comme le font une majorité écrasante de ...