it-swarm-fr.com

Quels sont les signes d'avertissement de Doom imminent pour faire attention à un projet?

Après avoir travaillé sur un projet défaillant est l'une des rares choses que la plupart des programmeurs ont en commun, peu importe la langue utilisée, l'industrie ou l'expérience.

Ces projets peuvent être d'excellentes expériences d'apprentissage, des catastrophes écrasantes à l'âme (ou les deux!), Et peuvent se produire pour une multitude de raisons:

  • changement de coeur de la direction supérieure
  • équipe sous-qualifiée/sous-garantie
  • émergence de concurrent supérieur pendant le cycle de développement
  • sur/sous gestion

Une fois que vous avez travaillé sur deux projets de ce type, est-il possible de reconnaître rapidement exactement quand un projet est condamné pour échouer?

Pour moi, un gros signe est d'une externe dure et rapide Date limite combinée à la fluage de fonctionnalité. J'ai vu des projets bien planifiés et que la procédure à droite sur l'annexe disparaît horriblement sur le Rails Une fois que les demandes de fonctionnalité tardif commenaient à rouler et à être ajoutées à la finale "livrable". Les proposants de ces demandes a gagné le surnom de Columbo , en raison de la sortie rarement de la pièce sans demander "juste une dernière chose".

Quels sont les panneaux d'avertissement que vous recherchez sur les cloches d'alarme du destin imminent dans votre tête?

66
ConroyP

Codage héroïque

Codage tard dans la nuit, travaillant de longues heures et les nombreuses heures supplémentaires sont un signe certain que quelque chose s'est mal passé. De plus, mon expérience est que si vous voyez quelqu'un qui travaille tard dans le projet, cela ne s'aggrave que jamais. Il pourrait le faire juste pour obtenir sa seule fonctionnalité à l'horaire et il pourrait réussir; Cependant, le codage cow-boy comme celui-ci est presque toujours le résultat d'une défaillance de la planification qui en causera inévitablement plus bientôt. Donc, le plus tôt dans le projet que vous le voyez, le pire que cela finira par devenir.

70
Fishtoaster

Lorsque les programmeurs commencent à gagner l'argument ", le code est horrible, nous devons commencer à partir de zéro." sur toute application mature.

Vous pouvez penser que vous pouvez mieux le construire ou comprendre le problème plus pleinement, mais vous ne le faites vraiment pas. Oh, et tous ces patchs laids? Ils sont corrects aux problèmes du monde réel que vous allez probablement réintroduire dans la réécriture.

De plus, un jour, vous devrez expliquer au gestionnaire de projet pourquoi, après 6 mois de travail, vous avez presque 85% de la capacité et 150% des bugs que l'application a eu lorsque vous avez commencé.

44
JohnFx

Pour moi, le plus gros problème, et vous pouvez repérer immédiatement, est lorsque l'entreprise considère les exigences écrites comme perte de temps.

Donc en gros; pas d'exigences écrites

C'est le baiser de la mort.

41
John MacIntyre

Un nouvel outil en tant que résolveur de problèmes.

Quand les gens commencent à envisager d'utiliser des outils inconnus, cela ne me dérange pas, mais je garde mes yeux dessus. Quand ils commencent à planifier toutes les avantages annoncés de ces outils dans le calendrier, je m'inquiète. Exemples amusants:

  • Nous pouvons raser un mois de la planification car nous allons essayer d'utiliser une langue orientée objet (même si tout ce que nous avons sont des développeurs C).
  • Nous allons essayer cette nouvelle chose Scrum - qui va réparer tous nos problèmes de processus!
  • Je sais que c'est à mi-chemin du projet, mais si nous avons changé d'ormes sur quelque chose de nouveau?

Les nouvelles technologies et pratiques sont excellentes, mais vous n'obtenez presque jamais tous les avantages de la porte.

41
Fishtoaster

Déconnexion de la direction

Lorsque les personnes responsables des délais, des caractéristiques, de la dotation en personnel, etc. se sont déconnectées des personnes responsables de la livraison du projet. Cela peut mener à:

  • Fonction de fluage lorsque le client parle avec quelqu'un qui ne comprend pas le coût de la fonctionnalité
  • Syndrome du mois de l'homme, où de nouveaux développeurs sont jetés dans un projet suffisamment en retard pour être plus d'une hublot qu'une aide
  • Délais irréalistes, créés par des personnes qui doivent faire face aux conséquences d'affaires des décisions de délais mais pas les conséquences de la mise en œuvre.
  • Les produits qui ne résolvent pas le problème, lorsque la communication du client-Dev est gênée par la direction au milieu.
  • Une mauvaise gestion des risques, où les problèmes potentiels ne sont pas communiqués suffisamment tôt entre Devs et gestion.

Donc, quand il semble que la direction est indifférente au projet, elle communique mal, n'écoute pas les clients ou n'écoute pas l'équipe DEV, couru pour les collines.

33
Fishtoaster
  1. lorsque les principaux développeurs quittent et la gestion ne s'en soucie pas

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

Le numéro un est généralement indicatif des gestionnaires qui sont sévèrement hors de contact avec la dynamique de l'équipe (qui est la "Super Star de 10x", qui sont les programmeurs décents et comment ils interagissent entre eux etc.).

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

25
MrDatabase

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

Généralement précédant quelque chose que nous n'avons pas le temps de ne pas, comme la documentation ou les commentaires de code (qui trouvent et corrigent statistiquement plus de bugs que autre chose, y compris toutes les formes de test)

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

Cela conduit à des délais qui ne seront jamais rencontrés, ce qui conduit à un manque de confiance dans le service informatique qui conduit à des développeurs qui créent des hacks (c'est-à-dire l'accès à la DB fonctionnant sur la machine de quelqu'un ... quelque part) qui conduit à un cauchemar pour cela quand le ' Système critique 'doit être migré qui mène à ...

21
adolf garlic

Laissez le client, le marketing ou la gestion choisissez une date, puis essayez de travailler à l'envers à un calendrier imaginaire

Un signe certain que j'ai vu dans ma carrière, c'est lorsque la direction commence à parler d'avoir plus de corps pour faire du temps dans le calendrier. Je n'ai jamais vu plus de corps sur un projet d'aide.

18
Walter

Lorsque les responsables non techniques commencent à prendre des décisions techniques qu'elles ne sont nullement qualifiées. Big, gros drapeau rouge!

17
GrandmasterB

Le signe le plus évident est un chiffre d'affaires élevé du personnel. Lorsque tout le monde recherche un nouvel emploi, vous devriez probablement aussi.

L'autre signe très évident est le manque de progrès. Si une année est passée, et cela ne semble pas que vous n'êtes plus plus proche de la cible, vous êtes condamné. Cela se produit surtout lorsque les exigences changent plus vite que vous ne pouvez les implémenter.

16
user281377

Membres de l'équipe ennuyée.

13
Ashalynd

Vous êtes "90% fait", la livraison est la semaine prochaine, mais ça va parce que tout ce que vous avez laissé est "Test".

12
Scott Whitlock

Cow-boys coders, gros egos et leur acceptation de gestion

  • Tout le monde est épuisé physiquement et mentalement
  • Les clients/utilisateurs sont clairement mécontents sur les délais ou ce qu'ils voient
  • Le design à l'origine se sent maintenant compromis
  • Vous êtes résigné à l'expédition avec des bugs relativement significatifs que vous préférez réparer, mais ne pourrez pas pouvoir être capable de
  • Vous restant la fierté est dans l'acte d'expédition plutôt que de ce que vous expédiez - plus près d'une mentalité de survivants que la fierté professionnelle
  • L'équipe a effrayé qu'il y ait certaines choses qui ne fonctionnent pas et ignorent ces sections et espérant le mieux parce qu'elles ont peur de ce qui pourrait être là-bas
  • Tout le monde est convaincu qu'ils sont passés au-delà (et qu'ils ont raison)
  • Les gens montrent des signes d'épuisement physique (pessimisme général, désintérêt, colère)

(Crossbed de Jim McCarthy Dynamique du développement logiciel ).

10
Jon Hopkins

Développeurs exécutant sauvage sur la plage

Cela s'est passé lorsque vous réalisez que d'autres développeurs (ou, malheureusement, vous avez développé un composant qui varie considérablement de la conception, et que cela n'est pas ramassé jusqu'à ce que des tests système/UAT. Je ne parle pas des bugs; Je parle d'importants composants du système des éléments manquants ou ne sont pas montables pour la fonctionnalité et ne vont jamais passer à l'UAT sans retravail significatif. Ce problème indique que:

  • Votre système de qualité est cassé; Pourquoi le développeur n'a-t-il pas concerné l'élaboration de la question de la phase de conception/de mise en œuvre? Le code n'est-il pas par examinée/inspecté? Pourquoi l'unité et l'intégration ont-elles des tests de l'unité et de ne pas choisir ce sujet? Si vous n'avez pas une sorte de test d'unité/d'intégration cohérente en place, vous êtes vissé.
  • Votre chef de projet/responsable technique ne contrôlait pas leur équipe de développement. S'ils ne peuvent pas obtenir les développeurs de livrer ce qui est requis, ils ne seront jamais en mesure de fournir une solution complète.
9
MagicAndi

Lorsqu'un développeur clé sur un projet n'a pas été enregistré dans aucun code pendant des semaines et qu'un jalon grave apparaît.

C'était un travail contractant et le développeur plus senior et PM sur l'emploi a décidé qu'ils voulaient faire équipe pour tenter d'obtenir une réduction plus importante afin que l'autre développeur détenait 3 semaines d'otage de code critique. Dans La fin, nous avons tiré l'incompétent PM (qui passait 6 mois à mettre le projet sur un cours de ruine) et a parlé des choses avec le développeur.

Il suffit de dire que le reste du projet était une mars de la mort masochiste, le gel des spécifications a été retardé, le client a reçu une série de fonctionnalités de concession pour compenser la terrible planification du PM laissé le projet et la qualité du projet a souffert tout autour à cause de cela.

Le PM a même eu le nerf de voler pour le CDR (revue de conception critique) uniquement pour saisir la rencontre avec le client et lancer un Hissy Fit. Lorsqu'il a demandé que ses dépenses de voyage soient payées sous Le projet qu'il a été dit poliment d'aller forniquer avec lui-même.

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

8
Evan Plaice

Mon premier signe sur un était quand ils ont demandé combien d'heures supplémentaires chacun de nous engagerions à dix pour les prochaines semaines et les salariés ont offert une prime pour les heures supplémentaires de travail dudit basé sur le succès du projet et respecter les délais.

D'autres signes majeurs que j'ai vu: Exigences défintion passe au-dessus horaire et la date de fin ne se déplace pas. Nous étions en retard avant même de commencer. Ils ont pris le temps loin de la conception, nous avons donc commencé sans la conception de base de données et pas de conception de site, mais devrait livrer à temps, entre autres, faire les importations aux tables ne sont pas conçus et créé.

Lorsque des éléments sur le chemin critique sont faites simultanément au lieu de l'ordre. (Si je suis obligé d'utiliser l'outil X et programmeur A est juste de commencer à construire, il va retarder ma tâche.)

Lorsque les gestionnaires commettent code sur l'Action de grâces.

Lorsque vous commencez à recevoir des courriels qui ont un timbre datetime plus tard à 11 heures et avant 6 heures.

Lorsque toutes les questions sur la façon de gérer une certaine complexité est satisfaite avec la même réponse: " Ne vous inquiétez pas encore. "

Quand ils font encore des exigences change le jour betore vous allez à l'assurance qualité ou allez vivre.

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 à des réunions toute la journée. 5 minutes par jour de fin de réunion, réunion quotidienne qui va plus d'une heure, pas bien.

Lorsque l'équipe de base de données et l'équipe de aplication ne parlent pas les uns aux autres.

Lorsque le client ne peut pas fournir les informations promises à temps. Surtout quand ce sont des fichiers d'importation de données et vous avez besoin que les données dans la base de données afin de vérifier pour voir comment le code fonctionne.

Lorsque l'on considère l'installation d'un feu stop à l'extérieur vous de laisser le bureau à un responsable de savoir s'il est sûr de l'approcher ce jour-là.

8
HLGEM

Je pense qu'il est généralement facile de repérer un projet défaillant lorsque la date limite approche. Comme vous l'avez dit, le fluage de fonctionnalité associé à une date limite de serrage est un moyen sûr de tuer un projet.

La clé est toutefois de repérer un projet défaillant à l'avance. Je pense que le seul vrai "signe de malheur" dans ce cas serait un manque total de définition de "quand sommes-nous terminés". À moins que nous sachions cela au décalage, nous sommes condamnés à l'échec imo.

6
Jaco Pretorius

Paul Vick a écrit un excellent post Il y a plusieurs années à propos de Projets de trou noir . Je pense que tous les conseils sont pertinents. (J'ai édité les articles et les résumés de la longueur.)

  • Objectifs absurdly grandiose . Comme "" reimagine fondamentalement la façon dont les gens travaillent avec des ordinateurs ".
  • Délais complètement irréalistes . En général, c'est parce qu'ils croient qu'ils peuvent réécrire la base de base originale dans beaucoup moins de temps qu'autrement n'a pris à l'origine.
  • croyances irréalistes sur la compatibilité . Comme croire que vous pouvez réécrire et préserver toutes les petites bizarreries sans effort supplémentaire.
  • toujours "six mois" de la date limite importante qui ne semble jamais arriver . Ou, si cela arrive, une autre étape est ajoutée à la fin du projet pour compenser.
  • doit consommer d'énormes quantités de ressources . Habituellement, en suçant la pierre de saut d'un ou plusieurs produits établis.
  • implique d'utiliser une nouvelle technologie qui n'a pas encore été prouvée . En tant que tel, ils risquent de rincer tous les problèmes d'évolutivité avec la nouvelle technologie.
5
Chris Smith

Pour moi, c'est lorsque ceux qui sont responsables de l'ensemble des fonctionnalités (gestionnaires de AKA, propriétaires de produits, clients ...) arrêtent de soigner ou semblent avoir un air sans espoir sur leurs réponses. Les questions sur les fonctionnalités se rencontrent d'apathie et de découragement. Il est clair qu'ils ont perdu des investissements ou une confiance dans le projet.

Cela s'est produit pour moi lorsqu'un projet que j'étais sur le "changement de la direction de la direction du cœur" l'a frappé. Je posais des questions sur la façon dont il devrait fonctionner et tout à coup, personne n'avait eu une opinion réelle.

Un peu de temps que le projet a été annulé et que tout le beau code que j'avais écrit a été supprimé.

5
Vaccano

quelques points d'un projet mort que je faisais partie de:

  • La direction double l'équipe pour finir plus rapidement.
  • les développeurs commencent à "enterrer" des bugs pour respecter les délais et bien que son évident, son être ignoré pendant la révision du code.
4
OKAN

Je traduit mentalement "tout va bien. Nous n'avons rien à craindre." Pour "nous sommes tous vissés" chaque fois que j'entends la gestion informatique le dire. Vous entendez généralement que les gestionnaires le jettent accidentellement dans des réunions non liées ("Oh et d'autre part, tout va bien. Il n'y a aucune raison de s'inquiéter!"), Mais c'est un drapeau rouge encore plus grand pour avoir une réunion expressément appelée à dire que.

Je n'ai pas encore entendu un manager dire quelque chose dans ces lignes et l'avoir non s'avère être un mensonge.

4
Jason Baker

Voir cet article succinct: Quand les projets informatiques vont à droite .

L'absence de l'un des éléments indiqués dans l'article doit définir des cloches d'alarme sonner:

Assurez-vous donc que votre projet dispose de tout ce qui suit, sinon vous devriez être concerné:

(Pour citer l'article ci-dessus :)

  1. "Le premier est qu'ils sont basés sur une vision claire de ce qui doit être atteint."

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

  3. "Troisièmement, c'est une compréhension des problèmes à aborder."

  4. "La dernière caractéristique commune est que des ressources et des compétences suffisantes ont été disponibles."

3
therobyouknow

Lorsque la direction tire le projet dans différentes directions simultanément et que la voiture reste toujours.

J'étais autrefois impliqué dans un projet géré par deux gars. Soit ils ne se sont pas parlés ou chacun a un peu d'ego à résoudre, mais ils commandaient notre travail dans une direction opposée environ chaque semaine environ. N'a pas pris longtemps pour se rendre compte qu'il n'y a jamais de résultat. Volontiers ma participation n'a duré que quelques mois.

3
user8685

Statistiquement un projet de logiciel Démarrage est un signe juste que cela échouera, comme une majorité écrasante d'entre eux ...

3
Nitsan Wakart

Le dernier projet professionnel que j'ai travaillé a échoué. Une des raisons pour lesquelles je pense que cela a échoué est une combinaison de toutes les autres réponses (notamment aucune spécification écrite). Mais je pense que la cause principale est un manque de prise de décision.

J'étais un développeur principal et je demanderais à mon directeur comment il voulait que certaines fonctionnalités travaillent. Sa réponse étant "Nous devons collecter plus d'informations de clients potentiels". J'ai donc travaillé sur une zone différente du projet. Il est finalement arrivé là où je réécrivais les composants pour être plus propres, car tous les autres domaines du projet s'appuient sur des décisions inconsidérées. Près de la fin, j'ai commencé à prendre des décisions moi-même. Je me suis licencié à cause du projet étant détruit environ un mois après avoir commencé à prendre des décisions.

Je vais résumer quelques éléments à faire attention à:

  1. Aucune spécification écrite
  2. Aucune décision n'a été faite, ou s'ils avaient été faits, ils n'étaient que "nous allons le faire de cette façon et la répertorie plus tard la bonne façon"
  3. Plusieurs échéances manquées
  4. Équipe inexpérimentée ou silencieuse (ce projet était la première fois que j'ai utilisé .net, et pourtant j'étais un développeur principal!)
  5. Devoir travailler dans des zones déjà complètes car d'autres zones ont besoin de décisions prises avant que le travail puisse commencer. (Bien sûr, je parle de refactoring pendant des semaines juste pour rester occupé)
  6. L'idée qu'un nouvel outil va raser les mois de temps de développement
2
Earlz

Après avoir travaillé sur un projet défaillant est l'une des rares choses que la plupart des programmeurs ont en commun, peu importe la langue utilisée, l'industrie ou l'expérience.

Bon, c'est un soulagement!

Je pense que ne pas avoir quotidiennement, tile La supervision de la gestion est la clé pour repérer le fluage. Je crois que si vous avez la bonne information, si vous obtenez votre DevS pour saisir les bonnes informations, vous pouvez repérer le glissement assez rapidement. Ce que vous faites avec cela après cela - eh bien c'est plus politique et moins de développement ...

2
Tom Morgan

Il y a beaucoup de symptômes (brûlures, heures supplémentaires, frustration, silence ...) mais vous savez finalement que cela se produit lorsque les dates de libération commencent à glisser et que vous n'êtes plus en mesure de livrer le produit aussi souvent que vous êtes censé.

1
Martin Wickman

Eh bien, la meilleure façon de répondre à cela est avec un exemple:

Bob commence un projet en proposant une idée de génie. Il commence par créer un plan pour le projet logiciel qui commence par des étapes spécifiques à remplir. Cependant, les étapes ne conduisent pas au résultat final, mais ne font qu'une partie de la voie.

En fin de compte, le projet échoue parce que les plans étaient incomplets. Ce n'est pas tellement absolu de planification tel qu'il est une planification insuffisante.

0
Nathan Osman

Des projets qui sont en quelque sorte prêts à la production, mais les caractéristiques sont ajoutées.

Long temps de développement sans engagement clair pour la libération.

0
dukeofgaming