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

66

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?

ConroyP
la source
Robert Glass a écrit "Universal Elixir et autres projets informatiques qui ont échoué". Publié en 1977, le livre était un recueil de chroniques qu'il avait écrites précédemment, chacune examinant un projet qui avait échoué, cherchant les raisons de l'échec. Le livre fait une excellente liste de signes avant-coureurs.
John R. Strohm
Deux articles - Pathologie de projet et Chaos Report (le surdimensionné) . Donnez à Death March une bonne lecture si vous recherchez un livre.

Réponses:

70

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.

Fishtoaster
la source
12
La seule excuse pour tirer la nuit blanche est de résoudre un problème spécifique lié à une échéance inflexible SPÉCIFIQUE. Peut-être que c'est juste moi, mais le code que j'écris à trois heures du matin quand je suis grognon et privé de sommeil a tendance à avoir l'air hideux sanglant vu à la lumière cruelle du jour.
BlairHippo le
5
Eh bien, l'autre excuse que ce soit un étudiant. Une mauvaise planification de projet est alors normale. :)
Fishtoaster le
20
Oh, le Christ. Université. Je me souviens assis devant mon terminal comme le soleil se levait, bousculant *« s et &» plus ou moins s au hasard devant les variables dans mon code C ++ dans l'espoir que la fichue chose commencera à travailler. Je ne manque pas une partie de l'université.
BlairHippo le
2
Plus tôt cette année, nous avions un projet comme celui-là: un gars travaillait régulièrement jusqu'à 2 heures du matin et je commençais à 4 heures du matin. Nous avons fait le travail, cependant, en dépit des délais ridicules qui nous ont été imposés (nous nous étions engagés à être complets dans les délais prévus par la loi). Nous sommes toujours en train de ranger et de refactoriser!
Chris Buckett
3
Je vais mettre mon karma en danger ici et souligner que le "codage héroïque" est un indicateur tardif. Les projets rencontrent des problèmes bien avant de passer à la phase de "codage héroïque". Il y a généralement beaucoup d'indicateurs de problèmes précoces, qui apparaissent bien avant que le codage ne commence réellement. Malheureusement, ils sont trop souvent ignorés. Robert Glass a beaucoup écrit sur ce sujet, dans "The Universal Elixir" et dans d'autres livres. Ignorez-le à vos risques et périls.
John R. Strohm
44

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.

JohnFx
la source
9
N'est-ce pas juste un résumé de la tristement célèbre réécriture de Netscape?
Jasarien
4
Je ne suis pas d'accord. Les réécritures présentent certains dangers (par exemple, le syndrome du second système), mais si vous en avez connaissance, une réécriture n’est pas plus dangereuse que tout autre projet «greenfield».
Nikie
4
Parfois, vous devez amputer et remplacer par quelque chose qui rendra l'application plus forte, meilleure et plus intelligente. Mais le mot clé est amputer, ne pas tuer ni ressusciter.
Erik Reppen
2
Cela peut être en grande partie vrai, mais pas strictement vrai. J'ai eu un tel projet il y a environ 9 mois et ce fut un succès. Il a passé plus de la moitié de son temps à concevoir des tests pour prouver qu'il était correct et que les anciens / nouveaux bogues n'avaient pas été introduits dans la nouvelle version, et ont découvert un tas de nouveaux bogues dans la version existante entre-temps. (Bien que, je suppose, cela rend cette réponse vraie comme un signe avertisseur )
Izkata
41

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.

Fishtoaster
la source
3
J'étais une fois sur un projet qui avait deux fourchettes à cause de deux interfaces - un gadget de bureau et de poche. Les estimations de temps reposaient sur l'idée que nous pouvions utiliser ces nouveaux éléments "EJB" pour réutiliser le code de couche modèle entre les deux. Malheureusement, la base de données était un tel nid de rats tellement horrible que toutes les données qui en ont été extraites devaient provenir de requêtes SQL soigneusement élaborées; remplir complètement les haricots aurait été un succès trop brutal. Quand il s'est avéré que (surprise!) La version de bureau avait besoin de plus de données que la version de l'ordinateur de poche, la chronologie est allée droit au diable.
BlairHippo le
2
"Merveilleux! Maintenant que nous avons récupéré le cadre de tests unitaires, nous pouvons commencer à réduire les délais à partir de cette phase d'assurance qualité trop longue!"
Arkaaito
hahaha. Excellent. +1 pour le nouvel outil va résoudre tous mes problèmes.
Rapidement maintenant
40

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.

John MacIntyre
la source
3
Ou pire, des exigences écrites que personne ne lit. En fait, je suis allé sur des projets où des exigences importantes ont été écrites et jamais montrées aux programmeurs.
JohnFx
1
@Adolf Garlic - Les exigences écrites ne vous garantiront pas le respect des délais et du budget, mais vous ne pourrez jamais répondre aux attentes si les attentes ne sont pas communiquées, si toutes les zones grises ne sont pas définies et changent constamment (vos idées mentales changeront ).
John MacIntyre le
5
Un jour, un analyste commercial m'a dit que mes besoins n'étaient pas nécessaires. Quel est le travail d'un analyste commercial à nouveau? Oh oui pour écrire les exigences! Nous aurions des exigences telles que faire ce travail comme hkjk.com.
HLGEM
1
Si vous développez un produit personnalisé pour un client unique, bien sûr. Mais si vous écrivez la prochaine version de Powerpoint ou la prochaine version d’un système logiciel interne, je ne vois pas l’intérêt. Vous en apprendrez toujours plus sur les exigences lors du développement (par exemple, certaines exigences ne sont pas utiles et d'autres ne sont pas réalisables). Je préférerais utiliser ces connaissances et modifier les exigences lors du développement plutôt que de publier un produit de qualité inférieure.
Nikie
1
@nikie - Je ne dis pas que les exigences doivent être statiques et ne jamais changer. Je dis que vous devriez l'écrire pour éviter les erreurs de communication et empêcher que les idées changent chez les gens avec le temps. Si les exigences doivent changer, changez-les, mais gardez les exigences actuelles écrites. Cela a-t-il du sens?
John MacIntyre
33

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é.

Fishtoaster
la source
+1 pour votre premier article. J'ai été client dans le scénario que vous avez mentionné et c'est mauvais pour tout le monde (personne ne veut une facture inattendue et personne ne veut se disputer pour la payer).
fearoffours
+1 amen. Je suis allé là-bas, ça ne me dérange pas d'être dans cette position.
Evan Plaice
+1 pour le fait que je vis avec toutes ces balles (sauf peut-être la 4ème).
AShelly
Très bonne réponse. Même si vous n’avez pas pris la peine d’élaborer, et que vous avez simplement mis «Management Disconnect», votre réponse aurait valu un +10.
Jim G.
25
  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.

MrDatabase
la source
24

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)

Mawg
la source
8
Vous avez une référence pour ça? ce serait génial d'utiliser des munitions ...
Alex Feinman
1
Appelez ça "la première loi de Mawg sur la gestion de logiciel"
Mawg, le
1
@ Alex Feinman: IIRC Code Complete contient de nombreuses références à des statistiques comme celles-ci.
Nikie
21

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

Mawg
la source
Merci. Rappelez-vous, vous pouvez l'avoir rapidement, pas cher ou en travaillant ... choisissez n'importe lequel
Mawg
21

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 à ...

Adolf ail
la source
Rien n’empire plus l’étendue de la portée que les «caractéristiques de la concession», car le Premier ministre a tout gâché lorsqu’il a défini les dates jalons.
Evan Plaice
21

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.

HLGEM
la source
Oui, les nouvelles s'améliorent à mesure que les choses avancent :)
Hans Westerbeek Le
18

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.

Walter
la source
6
Auparavant, un responsable avait voulu faire appel à un codeur web frontal pour un projet (la bonne décision), mais parce que quelqu'un d'autre sur le projet était devenu malade de longue durée, le contrat du nouvel homme lui avait valu un succès qu'il n'avait pas le droit de faire. tomber malade.
Jon Hopkins
1
@Jon - C'est triste ... drôle, mais très triste!
Walter
16

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!

Grand maître b
la source
16

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.

utilisateur281377
la source
1
Les taux de roulement les plus élevés que j'ai vus concernaient deux projets. L’un était un projet stable qui continuait, et l’autre était un projet voué à l’échec dans une banque. Je n'ai jamais été aussi heureux d'être au chômage que ces deux-là.
David Thornley
13

Membres de l'équipe s'ennuie.

Ashalynd
la source
11

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

Scott Whitlock
la source
2
Cela semble très drôle maintenant que vous le dites. Arrivé à moi si. Ce n'était pas drôle à cette époque.
+1000 arrive où je travaille tout le temps T_T
Songo
1
Il est amusant de constater que chaque programme dispose de tests comme dernière étape, comme si les tests ne trouvaient aucun bogue. Si non, pourquoi s'embêter avec les tests?
JohnFx
Ne vous inquiétez pas, "le client le testera pour nous" :-(
Mawg
10
  • 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 ).

Jon Hopkins
la source
+1 pour "Vous restez fier, c’est dans le fait d’expédier plutôt que dans ce que vous envoyez". C'est tellement tellement vrai (même si je n'ai vu cela que dans mes gestionnaires. Nous, les développeurs, savions ce qui se passait ... les pieds en avant)
10

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

Mawg
la source
Qu'est-ce qu'un codeur cow-boy?
La magie créative
Wikipedia est votre ami fr.wikipedia.org/wiki/Cowboy_coding
Mawg
Je ne savais pas que c'est un terme, merci! Welp, je retourne à mon rancho ...
Creative Magic le
9

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.

ChrisF
la source
6
Il n'y a rien de mal avec une cascade quand elle est utilisée correctement. Malheureusement, il n'est jamais utilisé correctement :)
Adolf ail
@adolf - Je pensais à un seul passage à travers la cascade. Plusieurs mini-cascades sont probablement acceptables.
ChrisF
imo, Agile est juste une série de cascades. Très peu de
gens
@ mawg - mon propos concernait le fait qu'une seule longue itération soit mauvaise alors qu'une série d'itérations courtes (quelle que soit leur gestion) est préférable.
ChrisF
1
Cela me rappelle un projet de développement d’objets électroniques où aucun prototype n’était programmé dans… Un signe certain d’un désastre imminent.
Rapidement maintenant
9

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.
MagicAndi
la source
8

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.

Evan Plaice
la source
8

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à.

HLGEM
la source
2
Le premier paragraphe de votre paragraphe est que, si la direction le fait, les délais sont probablement déjà condamnés et les bonus inaccessibles.
David Thornley
1
@ David Thornley, ouais c'est tout à fait ça.
HLGEM
6

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.

Jaco Pretorius
la source
1
aka "définition de fait", comme convenu par l'informatique et le business
adolf garlic
6

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.
Bob Murphy
la source
Je vous donnerais un million pour ce dernier point.
HLGEM
5

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é.

Vaccano
la source
5

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.
Chris Smith
la source
4

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.

Jason Baker
la source
Lolx! Tellement vrai; la réunion "vous avez peut-être entendu des rumeurs (...)".
Mawg
4

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.
OKAN
la source
3

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.


la source
LOL, j’ai travaillé dans une étude sur la main-d’œuvre comme celle-là, bien que ce soit encore pire, car les deux responsables tentaient tous deux d’avoir une liaison avec la même femme. Si Bill a dit oui, alors Bob a dit non et vice-versa, le pire projet sur lequel j'ai jamais travaillé. J'ai prié pour être réaffecté.
HLGEM
3

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."

therobyouknow
la source
Excellent article! J'aime l'approche "quand les choses vont bien".
user8865
3

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

Nitsan Wakart
la source
1
Je pense que c'est une statistique de démarrage, pas nécessairement une statistique de projet logiciel général.
Erik Reppen
2
Voici une référence au hasard sur Google qui semble suggérer qu'elle n'est pas limitée aux start-ups. Voir également l'excellent développement rapide de M. McConnel pour plus de détails sur le sujet.
Nitsan Wakart