Je suis développeur dans une équipe de 5 membres et je crois que notre projet est menacé de catastrophe. Je vais décrire pourquoi dans un instant, mais ma question est: comment dois-je me comporter?

La date limite est dans un mois et demi et je pense que quoi que nous fassions, ce projet échouera. Je pense que nous devrions juste terminer le projet et cesser de perdre notre temps, mais politiquement, je pense qu'il est impossible pour notre responsable de le faire.

Que dois-je faire dans ce cas? Devrais-je faire un effort supplémentaire ou devrais-je simplement y aller doucement? Et que devrais-je dire au gérant?

Les raisons de l'échec de ce projet:

• La date butoir approchant de nombreuses fonctionnalités indispensables ne sont pas terminées
• L'application est instable et très difficile à utiliser
• Le système est très compliqué, le code très difficile à comprendre, très difficile à modifier - Le modèle de données est trop basé sur une base de données relationnelle complexe (plus de 100 tables)
• Leadership peu clair; le gestionnaire répond à de nouvelles informations avec des changements majeurs
• Presque pas de tests automatisés ou de tests unitaires
• Dépend fortement des autres systèmes, mais pas encore de test d'intégration

En fait, nous avons en fait hérité de ce projet (avec le gâchis) il y a environ 1 à 2 mois d'une autre équipe de développeurs dirigée par le même responsable, qui y travaille depuis quelques mois.

Communiquez vos préoccupations de la manière la plus concise et la moins conflictuelle possible dans l’échelle de gestion. Résumez les risques, mais ne leur imposez pas votre conclusion.

La direction doit toujours avoir le choix de ce qu'il faut faire, mais votre travail consiste à évaluer et à communiquer la situation. Utilisez le courrier électronique afin de laisser une trace écrite lorsque les choses vont au sud.

Cela fait, continuez à travailler sur le projet de bonne foi.

N'oubliez pas que vous ne savez peut-être pas tout ce qu'il y a à savoir sur le projet, ses bailleurs de fonds et les décisions financières qui le sous-tendent. Les décisions de gestion qui vous paraissent stupides peuvent en réalité être basées sur un raisonnement intelligent qui ne vous est pas visible.

Conservez une trace écrite (par exemple, agenda, courriels sauvegardés, etc.). N'inclure que des faits et des observations objectives . Laissez toutes les conclusions à qui que ce soit (le cas échéant) lit ce que vous avez écrit.

En tant que développeur, si vous n'êtes pas perçu comme un obstacle au projet, il est probable que vous fassiez bien signe du doigt qui se produira sans doute. Votre responsable n'a peut-être pas autant de chance, mais ce n'est pas pertinent ici.

Juste sur des principes généraux, mettez à jour votre CV et assurez-vous de rencontrer de temps en temps d'autres développeurs extérieurs à votre entreprise. Si vous ne faites pas partie de groupes de développeurs locaux, rejoignez les groupes 2 ou 3. Il faut des années pour créer un réseau d'amis et de connaissances, mais à long terme, cela en vaut la peine. Assurez-vous de considérer cela comme une voie à double sens: si vous pouvez aider à combler une ouverture de votre entreprise avec quelqu'un de compétent, c'est aussi bien que quelqu'un qui vous aide à trouver un emploi.

Je vais vous recommander de prendre un peu de temps pour lire 2 livres.

Death March est le livre canonique qui décrit un style de gestion de projet pathologique très répandu dans le développement de logiciels. En raison de la compression du calendrier, de la lourdeur des fonctionnalités ou de la mauvaise gestion, de nombreux projets se retrouvent dans un état déplorable. il est utile de comprendre que vous n'êtes pas seul et que votre projet n'est pas la seule marche de la mort. L'auteur Edward Yourdon catégorise les projets sans issue en 4 quadrants, chacun ayant des stratégies d'adaptation différentes. Parfois, la seule stratégie d'adaptation consiste à s'en aller. Je pense que ce livre vous aidera à comprendre votre gamme d'options et à préciser ce que vous pouvez et ne pouvez pas faire.

Catastrophe Disentanglement est plus destiné aux responsables de projet. Son objectif est de déterminer comment trier un projet défaillant: qu'est-ce qui doit être coupé, qu'est-ce qui peut être réduit, et comment le présenter aux clients? La gestion de projets logiciels "conventionnels" nous introduit dans des projets en désordre, et nous n'échapperons pas à nos problèmes en utilisant la même pensée que celle qui nous a amenés à les entreprendre. Ce livre est un peu plus difficile à lire que Death March , mais un bonlivreà avoir dans votre bibliothèque.

3 stratégies simples et cyniques pour maintenir la carrière / santé mentale.

1. Observez le naufrage d'un train en gestation - descendez du train: l'échec de vos projets est mauvais pour le moral et, à moins que vous ne possédiez des compétences de gestion ascendante de ninja, cela aura un impact négatif sur votre carrière. Sautez maintenant si vous pouvez voir un atterrissage en douceur.

2. Si cela ne fonctionne pas, gardez la tête baissée: les gens vont commencer à chercher quelqu'un à blâmer - ne leur facilitez pas la tâche! Bien que l’intensification des préoccupations au sein de la chaîne de gestion puisse être la bonne chose à faire, elle est à la fois inefficace et risquée. Il est peu probable que votre propre responsable transmette vos préoccupations et le contourner ne vous fera pas seulement mal paraître à la fois, mais pourrait aussi vous considérer comme un "fauteur de troubles", c'est-à-dire le genre de personne à qui on peut reprocher de porter atteinte au projet, etc. Bien sûr, cela signifie également être professionnel, mis dans vos heures, mais pas héroïque.

3. Planifiez une sortie de secours à T + 1: donnez-vous quelques options et préparez dès maintenant le potentiel d'un transfert interne ou externe. Parle à des gens; il n'y a aucune raison d'attendre que les autres décident quoi faire de vous lorsque le financement du projet sera réduit ou de sombrer dans l'inévitable «ruée» des personnes qui migrent dans quelques mois.

Toutes mes excuses si cela semble trop cynique, mais si vous l'avez appelé correctement, il n'y a aucun avantage à subir le désagrément qui vous attend. Soyez professionnel, soyez optimiste mais soyez toujours réaliste.

Quel impact ce projet bientôt voué à l'échec aura-t-il sur votre carrière au sein de l'entreprise et au-delà? D'après mon expérience, le simple fait d'être associé à des projets réussis n'est pas un indicateur de votre excellence personnelle.

Les qualités que vous manifestez face à l'adversité et parfois ce qui semble être un échec, sont souvent remarquées par les supérieurs, plus que vous ne le pensez. Et je parle au-delà de votre gestionnaire immédiat.

J'ai personnellement vu mon supérieur hiérarchique immédiat se faire virer pour incompétence, puis je me suis retrouvé promu à son poste le jour même. Pas agréable, mais cela montrait que les gens me regardaient et aimaient ce que je faisais.

Souvent, le même chaos et la même désorganisation qu’un projet échoue, vous permettent de briller.

Regardez donc le projet de la manière suivante: quelle opportunité offre ce projet défaillant pour que la lumière brille sur toutes mes forces et mes meilleures qualités? Quelles leçons suis-je tirer de cette expérience, qui feront de moi un meilleur professionnel et une meilleure personne?

Essentiellement, la somme des expériences tirées des échecs est ce qui alimente le véritable succès.

Remarque: Thomas Owens a demandé ce qu'une personne peut faire dans un projet comme celui-ci. J'ai quelques suggestions générales que j'ai utilisées comme directives personnelles dans ces situations. Cela aidera-t-il un projet de détresse à réussir miraculeusement? Non, mais j’ai trouvé que cela m’avait aidé à garder une perspective correcte sur les choses et à réussir personnellement malgré la mauvaise situation.

1) Concentrez-vous sur l'excellence personnelle - efforcez-vous de rédiger un code de meilleure qualité et de respecter les normes de qualité et de fonctionnalité les plus strictes.

2) Concentrez-vous sur des métriques personnelles - combien de code écrivez-vous, qui génère des bogues ultérieurs? Réduisez ce ratio au plus bas possible. Quand on vous demande de fournir une estimation pour une tâche qui vous est confiée, êtes-vous généralement précis ou trouvez-vous que vous avez trop tamponné / sous-tamponné le plan de montage chronologique? Lorsqu’une tâche est effectivement assignée, fournissez-vous un bon niveau de feedback sur la progression du travail, y compris en donnant un préavis bien à l'avance des problèmes de calendrier de livraison?

3) Concentrez-vous sur les indicateurs de l'équipe - Voici quelques points qui me viennent à l'esprit: les autres membres de l'équipe sont-ils à la traîne en raison d'une dépendance à une tâche sur laquelle vous travaillez? Êtes-vous doué pour déléguer ou diviser votre tâche / sous-tâche à d’autres membres de l’équipe? Trouvez-vous difficile de communiquer avec un ou plusieurs membres de l'équipe? Tous les domaines sur lesquels je travaille sont régulièrement améliorés.

Dans une situation comme celle-ci, en tant qu'échelon le plus bas de l'échelle, vous ne pouvez faire que beaucoup pour aider le projet.

• Assurez-vous que votre travail est impeccable
• aider à identifier les plus gros problèmes
• Essayez de fournir des réponses, pas seulement des problèmes. On dirait que vous essayez de les réparer.

En dehors de cela, vous devez vraiment vous occuper du numéro 1.

• Tout documenter
• conservez tous les courriels et conversations de messagerie instantanée
• Essayez de trouver un moyen de sortir du projet si cela est possible

Les projets qui échouent peuvent être toxiques pour l'âme, causer la dépression, le travail excessif et une faible estime de soi.

Tout est relatif à la perspective.

J'ai travaillé sur des projets horribles alors que j'étais assis en face d'un autre gars qui souriait tous les jours. Oh, comme je voulais gifler ce sourire de son visage.

Certaines personnes ne sont pas gênées par l'état actuel des choses sur un projet. Ils apprécient leur contribution, leurs tâches et travaillent dans le domaine qui les intéresse. Tandis que d’autres, réagissent fortement à l’état actuel des choses. Tout dépend de nos attentes perçues pour nos tâches quotidiennes.

Pendant que vous faites peut-être une partie du travail que vous aimez. Il y a clairement des éléments dans le projet actuel que vous n'aimez pas.

Vous devez identifier ces éléments problématiques et les résoudre.

• pression limite
• Contrôle de qualité
• professionnalisme
• orientation par la direction

Il existe de nombreuses équipes et sociétés qui ne considèrent pas les aspects de développement susmentionnés comme importants. Ce que j'ai trouvé, c'est qu'ils pensent souvent ce qui suit.

• La pression sur les délais est perçue comme un moyen de motiver les gens.
• La qualité coûte plus cher et limite les retours.
• Le professionnalisme s'applique à d'autres domaines de l'entreprise.
• Un responsable est un chronométreur et non une personne qui contribue au développement.

Ces problèmes ne sont pas les vôtres. C'est à eux et vous ne devriez pas gaspiller d'énergie pour leur comportement. Si vous n'êtes pas du genre à sourire et à aimer son travail même s'il se dirige vers une falaise, vous devriez alors penser à trouver une place pour les like mindeddéveloppeurs.

Vous serez beaucoup plus heureux.

Essayez d’être proactif pour trouver un nouveau moyen de réussir le projet. Réfléchissez à la manière dont vous pouvez proposer des alternatives. En ce moment, votre patron est probablement déçu par le fait que le projet est un échec. N'apprécierait-il pas que quelqu'un vienne avec des solutions plutôt que des problèmes?

Peut-être y a-t-il un moyen de scinder les fonctionnalités en livrables échelonnés? Il y a souvent des degrés de "must have", alors voyez si vous pouvez les hiérarchiser et les regrouper en étapes. Mieux vaut avoir un produit à la fin de la chronologie que rien. Ou envisagez de séparer l’équipe entre les personnes travaillant sur les nouvelles fonctionnalités et les autres sur la stabilité, de cette manière, vous pourrez montrer des progrès sur les deux fronts.

Si ces efforts aboutissent, vous aurez montré que vous êtes un membre de l'équipe capable de trouver le moyen de réussir. Sinon, vous aurez quand même démontré que vous n'abandonniez pas et travailliez à la recherche d'une solution.

Cela ressemble à la plupart des projets auxquels j'ai participé. Cela ne se terminera probablement pas aussi mal que vous le pensez, cependant:

1) Faites votre travail. Ne vous inquiétez pas du projet dans sa globalité tant que vous assumez vos responsabilités.

2) CYA. Si le projet échoue et que vous pensez que le responsable va commencer à blâmer tout le monde, assurez-vous de disposer de suffisamment de preuves pour prouver que vous avez tout mis en œuvre pour vous (voir le point 1).

3) Faites quelques suggestions d'améliorations polies . Ne faites pas sonner les cloches d'avertissement, ne soyez pas sombre, mais soyez poli et subtil.

Par exemple, si l’équipe n’écrit pas de tests unitaires efficaces (ou d’autres tests), écrivez quelques tests unitaires plus proches de ce que vous souhaitez voir et indiquez en quoi cela vous a aidé à résoudre un problème particulier ou à gagner du temps.

Quoi qu’il en soit si vous voulez avoir un impact sur le changement, concentrez-vous sur les étapes positives qui ont des résultats concrets. Ce projet peut ne jamais être gagnant, mais peut-être que l'équipe peut apprendre pour le prochain.

Aussi:

4) Le refactoring opportuniste est votre ami.

1. Travailler dur; mais pas au détriment de votre famille ou de votre santé.
2. Gardez une trace de toutes les décisions critiques de conception; surtout en ce qui concerne votre travail.
3. Gardez le contact et maintenez vos options ouvertes si la situation devient trop difficile ou si vous êtes victime d'un licenciement collectif.
4. Essayez de ne pas considérer votre projet comme un "projet échoué". Tout le monde aime les gens qui restent positifs et qui se battent fort face à l'adversité. Donc, aussi longtemps que possible, essayez d’être cette personne. Une attitude positive, du courage et de la détermination sont toujours bénéfiques pour le lieu de travail.
5. Si vous prévoyez l'échec d'un projet, vous prévoyez une réunion post-mortem. À la réunion post-mortem, tout le monde sera tenu de rendre des comptes. Soyez prêt à défendre tout votre code. [Remarque: en règle générale, vous devriez toujours écrire du code en clair pour pouvoir le défendre facilement plus tard.] Si vous avez un courrier électronique ou un document de conception qui a inspiré vos décisions, c'est encore mieux.
6. Lors de cette réunion post-mortem, essayez de rester positif; et présentez uniquement votre preuve de courrier électronique et de document de conception si votre jugement, vos efforts ou votre qualité de fabrication est remise en question.

Ce que j’ai trouvé le plus efficace, c’est la recommandation de Robert L. Read sur la façon de lutter contre la pression des horaires . Voici ce que Read écrit:

Pour lutter contre les contraintes de calendrier, il est essentiel de le transformer en une pression liée au délai de mise sur le marché. La façon de le faire pour donner une visibilité dans la relation entre la main-d'œuvre disponible et le produit. Produire une estimation honnête, détaillée et surtout compréhensible de tout le travail requis est la meilleure façon de procéder. Il présente l’avantage supplémentaire de permettre de prendre de bonnes décisions de gestion concernant les compromis possibles entre fonctionnalités.

L'idée clé que l'estimation doit préciser est que le travail est un fluide presque incompressible. Vous ne pouvez pas en emballer plus dans un intervalle de temps que vous ne pouvez en emballer plus dans un récipient au-delà de son volume. En un sens, un programmeur ne devrait jamais dire «non», mais plutôt dire «qu'abandonnerez-vous pour obtenir ce que vous voulez? La production d’estimations claires aura pour effet d’augmenter le respect des programmeurs. C'est comme ça que les autres professionnels se comportent. Le travail acharné des programmeurs sera visible. Fixer un calendrier irréaliste sera également douloureusement évident pour tout le monde. Les programmeurs ne peuvent pas être trompés. C'est irrespectueux et démoralisant de leur demander de faire quelque chose d'irréaliste.

Lorsque vous dites que le projet "est voué à l'échec", vous vous basez sur votre évaluation des tâches à effectuer et des efforts nécessaires pour chacune d'entre elles. Rendre cette évaluation explicite , compréhensible et détaillée . Séparez les tâches en leurs composants; Expliquez de manière aussi détaillée que possible comment le temps de développement sera utilisé.

Une fois que vous faites cela, vous avez une base solide pour discuter des problèmes avec la direction. Selon toute probabilité, une fois que vous aurez divisé votre évaluation en tâches spécifiques à accomplir, vous serez en mesure de démontrer que le travail prend plus de temps que vous n'en avez, peut-être même beaucoup plus.

Une fois que vous avez discuté de cet horaire détaillé avec votre responsable, soyez prêt à faire preuve de souplesse. Votre responsable peut vous dire: "La tâche X ne prendra pas un mois; elle prendra au plus une semaine" ou "La tâche Y est totalement inutile, coupez cela du programme." Vous pouvez certainement discuter de ces points, mais le plus important est de parvenir à un accord entre vous et votre responsable sur une version réaliste d'un programme. Ainsi, si vous ne disposez pas de temps suffisant pour effectuer des tests, par exemple, vous avez la directive explicite de ne pas tester, plutôt que de simplement manquer de temps "de manière inattendue". Et il est tout à fait possible que votre responsable soit légitimement disposé à couper explicitement certains coins pour pouvoir expédier à temps - il existe de nombreux cas où cela '

Le devis vous donne matière à débattre et à discuter. Cela vous met sur la même page; cela vous aide à avoir confiance que votre responsable a pris en compte vos préoccupations. Et cela vous amène au point où si votre responsable demande clairement l'impossible, cela sera parfaitement évident pour vous deux. Si le projet est bel et bien condamné, vous l’auriez indiqué clairement et il appartiendra à votre responsable de décider précisément comment il souhaite que vous passiez votre temps.

Puisque votre responsable sait qu'il échouera probablement, vous êtes mieux loti que la plupart des autres. J'envisagerais de travailler avec le responsable et de voir si certaines parties / fonctionnalités de l'application peuvent être exclues.

Trop souvent, nous pensons que chaque demande de client est un «tueur d’affaires» et faisons tout notre possible pour promettre la livraison. Jusqu'à ce que quelqu'un travaille avec le client et approfondisse, vous ne pourrez peut-être pas prendre ces décisions. Si vous ne le pouvez pas, essayez quand même de livrer ce qui vous semble le plus important. Parfois, il est plus facile de demander pardon que d’autorisation.

J'ai participé à trois projets qui ont clairement échoué. C’était assez douloureux, mais avec le recul, deux des trois n’ont pas eu de conséquences négatives sur ma carrière, et même le troisième n’a pas été la fin du monde.

Voici quelques observations dont je me souviens.

Les développeurs aux postes de niveau junior ("code par spécification", "correction du bogue", etc.) ne sont pas trop affectés, à moins qu'ils ne se relâchent en raison du moral bas de l'équipe. À des postes comme ceux-ci, une stratégie de survie judicieuse et parfois même réussie pourrait consister à faire de son mieux.

• ^{Par exemple, l’un des échecs que j’ai connus a été surmonté par la résolution simple et méthodique de plus de cent bugs connus qui (associés à une approche particulièrement intelligente de promotion de cette avancée par le responsable technique) ont finalement amené la direction à la décision de récupérer le projet et une nouvelle chance avec une nouvelle version, qui à son tour a fait un succès raisonnable.}

Les programmeurs occupant des postes plus importants et plus influents seraient mieux préparés à partager les conséquences négatives de l'échec d'un projet. Un architecte, un responsable technique et un développeur principal sont généralement censés avoir un impact suffisamment important pour être considérés comme responsables du succès ou de l'échec du projet.

À un poste de direction, on serait mieux préparé à gagner «indirectement» d'un échec en analysant ce qui n'allait pas et ce qui aurait pu être mieux fait.

Ces connaissances élémentaires, les leçons post-mortem, peuvent être inestimables si elles sont bien apprises. La carrière très réussie à des postes de responsabilité peut dépendre de la qualité de ces connaissances, comme expliqué dans cette réponse brillante de WP :

Le jugement ne vient pas du succès, mais des échecs. La plupart des entreprises veulent embaucher des personnes dont les échecs ont été payés par des entreprises précédentes ...

Sur une note plus pratique, on peut envisager l’approche «version suivante / mise à jour» comme solution possible à l’échec. Par coïncidence ou non (je pense que non ), mais les échecs qui n'ont pas nui à ma carrière ont suivi des scénarios très similaires: la libération a Nété un désastre total, la libération N+1était tolérable, les versions N+2et plus tard ont été un franc succès.

En marchant dans vos chaussures, je ferais très probablement quelques efforts pour préparer / promouvoir l'idée de "prochaine version". Créez (et communiquez !) Quelque chose comme une liste provisoire des problèmes connus que vous voudriez résoudre après la publication prévue. Préparer une feuille de route informelle et approximative pour la ou les prochaines versions.

Pensez à la manière dont vous pourriez communiquer ces idées à votre entourage, comment vous pourriez influencer la direction pour qu’elle envisage ce plan. Si le projet compte des personnes possédant de bonnes compétences en marketing, essayez de les impliquer dans l’amortissement des dommages liés à l’échec en résumant la publication à venir en termes plus lisses, telles que "accès anticipé", "version bêta", "aperçu du client", "publication préliminaire", etc. cette.

Pensez à un plan de secours au cas où des personnes plus élevées sembleraient sourdes à cette idée. Rappelez-vous l'histoire ci-dessus à propos de "la correction de plus de cent bugs connus"? il y a une chance pour que les choses changent, vraiment.

La direction peut sembler sourde aux idées de la prochaine publication maintenant, mais il y a une bonne occasion pour elles de reconsidérer face à de solides preuves convaincantes de la progression de la qualité du projet.

• ^{Il est fort probable qu'il y aura un délai assez long entre le gel du code pour la publication prévue et la décision de la direction de le supprimer complètement. Ce temps est votre chance: si vous concentrez vos efforts sur la résolution des problèmes connus et sur une "évangélisation" des progrès, cela pourrait faire la différence (comme cela m’a été fait une fois pour moi).}

Il y a déjà une foule de conseils pratiques (et autres) ici, mais pour moi les clés de ce mystère sont les deux éléments suivants (c'est moi qui souligne):

Le délai est de 1,5 mois

et

... nous avons en fait hérité de ce projet (avec le gâchis) il y a environ 1 à 2 mois d' une autre équipe de développement sous le même gestionnaire ...

Alors....

Bienvenue chez Team Patsy The Avengers

L’ancienne équipe avait mieux à faire que d’échouer. Et d'une manière ou d'une autre, le responsable a accepté. Changer d'équipes aussi rapprochées des délais n'est pas la meilleure solution en matière de gestion de projet, alors ... qu'est-ce qui se passe avec ça?

Correction: l’ancienne équipe a été remplacée, environ 3 mois avant la date limite.

-> Découvrez comment l'équipe de développement précédente a réussi à s'échapper et faites-le. <-

3 mois suffisent à peine pour se mettre au diapason sur un système de cette taille apparente, encore moins corriger son architecture, ajouter des tests et le terminer. Tu as besoin de plus de temps

Et si vous ne pouvez pas faire cela, à moins d'être absolument certain que le projet sera prolongé indéfiniment, ou aidé par des elfes magiques ou quelque chose du genre, vous ne voulez pas être le dernier homme restant à tenir le sac.

Dur? Oui. Mais si une mauvaise planification (au moins!) Par les équipes / responsables précédents n’est pas de votre faute, le «non-respect» sera le cas .

L'équipe précédente a été mise en liberté sous caution . L’équipe précédente a été frappée à bloc. Qu'est-ce que cela vous dit? Cela me dit que vous êtes l'équipe de redressement ... et que votre manager compte sur vos exploits pour sauver la situation.

Une équipe de 5 personnes et un mois et demi. La nouvelle équipe a le projet depuis seulement 1 à 2 mois, elle n’a donc même pas dépassé la courbe d’apprentissage . En prenant une approximation approximative de la taille de ce projet, il me semble qu’il n’ya aucune chance que la nouvelle équipe ait dépassé la courbe d’apprentissage, même si le projet n’avait aucun problème.

Donc, je pense (encore) que vous avez été victime de violence.

Si tel est le cas - et vous seul pouvez décider de ce qui est vrai ou de ce que vous voulez croire - vous ne devez à personne d'explication ni d'excuses pour vous être échappé de ce naufrage. Vous devez cependant rester discret à ce sujet.

Je doute sérieusement que le responsable ne sache pas que le projet est compromis, ce qui signifie que des explications douces ne vous attireront que de l'attention négative. À moins que votre responsable ne soit M. Rogers , votre avenir est en péril.

Mais souvenez - vous toujours : ne prenez pas les conseils de carrière d’étrangers sur Internet.

C'est une opportunité incroyable pour vous! Prenons un point de vue entrepreneurial à ce sujet.

En supposant que la direction veuille que ce projet aboutisse, vous êtes bien placé pour les aider. Cette réalisation est si importante parce que vous devez acquérir la conviction et la confiance que les signes d’avertissement que vous voyez vont effectivement conduire à l’échec de ce projet [1].

C'est votre chance de mettre en pratique des compétences importantes en pensée systématique et en communication interpersonnelle. Comprenez et visualisez les problèmes et les opportunités potentielles qui sont manqués afin que vous puissiez développer une stratégie pour les communiquer le plus clairement et le plus simplement possible.

Reconnaissez votre opportunité ici pour améliorer vos compétences.

[1] Annuler le projet serait en réalité un succès. Échec, ce serait dépenser bon après coup.

Que pouvez-vous faire

• Traitez cela dans vos propres termes d’excellence, c’est «leur» projet, mais aussi le vôtre, prenez-le en main même si vous savez que cela échouera. Pourquoi? parce que a) vous pourriez l’aider à échouer un peu moins, b) en cas de défi, c’est là que vous en apprendrez le plus c) vous devriez vous mesurer avec vos propres indicateurs d’excellence, faire de votre mieux ne risque pas de sauver le projet, pourrait encore être fier de toi

• Parlez à d’autres développeurs et voyez ce qu’ils pensent. Vous découvrirez probablement que beaucoup partagent la même frustration, si cela est fait avec précaution (ne faites pas croire aux gens que vous voulez déclencher une mutinerie ou quelque chose du genre), alors cela peut vous aider non seulement. d'autres aussi

• Ignorer le problème ne va pas le faire disparaître, discuter des moyens de le contrecarrer malgré tout, par exemple, obtenir au moins quelques objets douteux décents, ou le cas d'utilisation principal du "facteur de Wow" bien fait, pourrait faire en sorte que le projet échoue moins misérablement. Comment faire? Eh bien, rares sont les idées de "quand ça devient difficile" ou de "temps désespéré justifient des mesures désespérées" et autres clichés, par exemple: utilisation massive de logiciels libres, méthodes de programmation extrême / agile, hackathons de week-end (uniquement des volontaires, ne contraignant week-ends de travail). C’est le moment où vous pouvez faire preuve de leadership (avec précaution si vous n’êtes pas un chef d’équipe / un poste de direction) mais vous pouvez prendre cet avantage et devenir leur moqueur. Faites simplement en sorte que les gens sachent qu’ils pourraient obtenir ce projet un peu moins que l’échec. tout le monde sait que ce sera le cas.

• Assurez-vous que votre direction est au courant, mais très, très soigneusement, s’ils le savent, ils apprécieront que vous leur disiez cela d’une manière calme et non conflictuelle; s’ils ne le font pas, ils l’apprécieront encore plus et se demanderont pourquoi personne ne le leur dit. eux à ce sujet avant. Vous devriez leur dire ceci en tant que service, sans aucun côté émotionnel, seulement des faits clairs et sans ordre du jour. S'ils vous demandent ce qu'ils pensent devoir faire (ce qui est un bon signe, mais rare), voir la section suivante.

Ce que vous ne pouvez pas faire, mais votre direction devrait probablement

• Ils ne devraient pas ajouter plus de personnes au projet "pour aider" voir ceci

• Appelez immédiatement le client et dites-lui les mauvaises nouvelles. Pourquoi est-ce une bonne idée? Eh bien, je partirai en citant le manifeste pour le développement logiciel agile, mais même sans cela, même les amoureux de water fall détestent les mauvaises surprises. Si le client sait d'avance que ce projet est voué à l'échec, il sera malheureux, mais il sera beaucoup plus heureux que vous lui disiez qu'il y a des problèmes avant qu'il ne vous explose, et que vous y soyez et que vous fassiez de votre mieux pour vous accommoder. il. Le client peut faire beaucoup de choses, mais la plupart d’entre elles ne sont pas pires que de découvrir à la dernière minute qu’elles n’ont pas de livrable (ou qu’elles en ont, mais que leur qualité est inutilisable). Le client l'appréciera, car il pourra retarder le recrutement du personnel de test, du personnel informatique à l'étranger, modifier ses plans de formation internes et ce, tout simplement parce que vous avez été honnête avec lui.

• avec le client, réfléchissez aux moyens de continuer à utiliser le projet, le plus courant étant le décapage. Par exemple, il se peut que certaines fonctionnalités soient trop difficiles à développer, et si le client accepte de petites modifications et simplifications, certaines fonctionnalités deviendront plus simples.

• Mettre à jour leur propre direction, cela les aidera également à garder leur emploi ...

Ce que vous ne devriez pas faire

• Demander d'ajouter plus de personnes au projet (voir ceci )

• Quittez / cherchez un autre emploi (du moins pas encore), c’est quelque chose dont vous pouvez apprendre et ce qui fera de vous un jour un meilleur développeur ou un meilleur gestionnaire. Vous apprendrez à mieux apprécier beaucoup de choses, à mieux gérer votre temps, à concevoir, à écrire du code, à travailler avec des pairs et à la direction. Cherchez un emploi après ces 2 mois si vous n'aimez pas y travailler, pas pour une autre raison.

• Whine, se plaindre ou être négatif à propos du projet, de la direction, du mauvais design dont vous avez hérité, des développeurs débutants que vous devez conseiller, il vous faut 3 heures pour leur expliquer de faire quelque chose qui vous prend 1 heure, soyez positif autant que vous pouvez.

• Critiquez la direction et devenez une cible en tant que fauteur de troubles, ils sont dans le même bateau et savent peut-être des choses que vous ne connaissez pas. Tout ce que vous pouvez faire est de les mettre à jour (mettez toujours votre propre responsable directement à jour, ne la contournez jamais).

• Blâmez les gens (ou vous-même), ça n'aide pas, jamais

• Prenez le trop au sérieux, à moins que ce ne soit du matériel médical, personne ne mourra si vous manquez les délais, c'est un logiciel, nous manquons les délais pour gagner notre vie, détendez-vous.

C'est juste mes deux cents, YMMV

Trouvez les problèmes rencontrés par votre projet et essayez de les quantifier clairement aussi objectivement que possible. Avec chaque "métrique" que vous quantifiez, assurez-vous de définir pourquoi vous pensez que cette métrique est importante. Vous souhaitez donner à votre responsable un aperçu des conséquences si une certaine mesure ne se situait pas dans les "limites acceptables". Vous devrez donner des indications pour chaque métrique afin d'indiquer les valeurs "Bon", "Acceptable", "Problématique" ou "Mauvais". Définissez chaque critère à l’avance. Si possible, vous pouvez décrire ce qui serait minimalement nécessaire à la réussite d'un projet et le comparer au projet actuel.

• La qualité du code statique peut être quantifiée par de nombreux outils d'analyse statique. Vous pouvez garder cela aussi simple ou détaillé que bon vous semble. Les métriques avec lesquelles je vous suggère de commencer:
  • Complexité Cyclomatique
  • Taille de votre code (nombre de lignes par fonction / classe, nombre de fichiers, nombre de tables, etc.)
  • Identifiez les modules trop volumineux
  • Reproduction.
  • Respect du style de code
• Taux de défaut
  • par KLOC par module et / ou sous-système (identifiez les parties problématiques de votre système)
  • vous pouvez calculer combien par membre de l'équipe, mais je pense que vous devriez garder cela pour vous
  • résolu vs trouvé
  • le temps nécessaire pour résoudre un bug (peut-être si cela incline faire un graphique de cela)
  • peut-être faire une estimation de combien de temps est nécessaire si cela continue au rythme actuel
• Planification
  • Extrapoler le temps utilisé pour les fonctionnalités construites. Prendre en compte la complexité de la fonctionnalité. Cela n'a pas besoin d'être très précis. Ce que vous voulez exprimer avec cela serait comme suit: "Les entités A, B et C ont à peu près la même complexité que D, E et F. Avec les fonctionnalités ABC, utilisez 170% si le temps planifié est défini. Si rien ne change, nous attendons la même chose le temps est nécessaire pour DEF "ou le long de la ligne" La fonctionnalité moyenne prend X% plus de temps que prévu. Nous n'avons aucune raison de supposer que le reste des fonctionnalités est plus facile à créer; nous devrions donc en tenir compte dans la planification future. Il est inutile d’avoir une planification si elle n’est pas réaliste.
  • Essayez d'avoir un calendrier de publication mensuel ou de préférence encore plus court. Si seulement interne. Cela pourrait vous aider à extrapoler le temps dont vous avez besoin pour le projet. Cela pourrait également vous éviter de prendre des engagements irréalistes (si vous ne vous engagez pas dans de nouveaux travaux avant la sortie d'une version). Planifiez chaque cycle et assurez-vous que les nouvelles fonctionnalités entrent uniquement dans le cycle suivant (c.-à-d. Qu'elles ne peuvent jamais être ajoutées au cycle en cours).
• Couverture de test: expliquez les valeurs de couverture de test "normales" et montrez quelle est votre couverture actuelle
• Documentation: combien de% est réellement documenté? A quel point est ce bien?
• Modularité:
  • Basé sur la classe (couplage et cohésion)
  • Paquet basé
  • Basé sur le sous-système (combien y a-t-il de chemins de communication?)

Vous devriez aller au travail et faire ce que vous feriez dans n'importe quel projet, qu'il réussisse ou non. Vous êtes payé pour effectuer votre travail. Faites-le au mieux de vos capacités. En supposant que vous n’êtes pas le chef de projet / responsable de projet, ce n’est pas à vous de décider si un programme doit être annulé ou non. Vous décidez de relâcher est le même que vous prenez la décision d'annuler le projet. Cela ne fait pas partie de votre description de travail.

Toutefois, dans l’ensemble, cela ne signifie pas que vous devriez travailler 50, 60 heures ou plus par semaine pour essayer de respecter le calendrier. Encore une fois, c’est le rôle de la direction de déterminer comment atteindre les objectifs du projet. Une semaine de travail de plus de 50 heures n’est pas une option raisonnable à moins qu’ils ne soient disposés à payer des heures supplémentaires et à mettre leur vie de famille en suspens. Une fois de plus, il appartenait à la direction d’élaborer un calendrier réalisable. Ils ne peuvent pas supposer qu'ils peuvent forcer les employés à ignorer leur vie de famille afin de respecter des plannings irréalistes.

En outre, bien que le calendrier puisse indiquer un mois et demi restant. Ce n'est probablement pas la date "Drop Dead". Certains clients peuvent prendre ce que vous avez à cette date, même si ce n'est pas tout. Certains clients peuvent trouver un financement supplémentaire, car ils ont déjà investi beaucoup d’argent dans le projet. Parfois, la société elle-même peut assumer les coûts supplémentaires pour assurer la satisfaction du client. Tout cela est hors de votre contrôle. Faites votre travail au mieux de vos capacités. Cela offrira des options de gestion qui pourraient transformer un projet catastrophe en une belle réussite. Je l'ai vu arriver plusieurs fois.

Je ne peux que réitérer ce que d’autres ont dit, mais je tiens à souligner que vous devez toujours vous efforcer de faire votre meilleur travail et garder une trace écrite. tant pour la CYA que pour des raisons techniques.

Toute chute sur votre passage dépend du caractère personnel de la direction; mais laissez-moi vous dire que c'est l'enfer d'être le destinataire d'une gestion mensongère incompétente. Mais au pire, vous partirez avec le respect de vous-même (et de vos pairs) intact.

Conservez de bonnes notes sur les aspects techniques de votre Death March. Lorsque vous avez eu la question inévitable de l’entrevue, avez-vous participé à un projet qui a échoué? pourquoi at-il échoué et qu'avez-vous fait pour essayer de l’empêcher? La gestion des têtes osseuses n’est pas une réponse - même si c’est la raison.

Il peut être facile de supposer qu’il s’agit d’un échec inévitable et total et d’abandonner le projet. En tant que consultant, je suis souvent invité à participer à des projets qui sont à divers stades de dégénérescence, échouant ou échouant, et une partie de mon salaire est la relance et la réalisation de tels projets.

Ce que vous considérez comme un échec complet peut ne pas être perçu comme tel par tout le monde, en fonction de la perspective. Dans un monde idéal, chaque fonctionnalité serait complète, codée avec élégance et indépendamment des autres systèmes et chaque ligne de code testée. Je n'ai jamais vu un seul projet qui ressemble à cela dans la version 1. Dans le monde réel, expédier un projet implique de prendre des compromis, voire de manquer certaines fonctionnalités clés, mais le produit peut être livré et même s'il sera de qualité bêta au mieux. , au moins, vous obtiendrez des commentaires sur les points à résoudre en premier L'avantage de ceci est que cela peut informer la direction que le logiciel n'est jamais fait et que plutôt que d'essayer de développer une certaine v 1.0 dans le vide, il est préférable d'itérer et de réagir aux changements de manière agile. Enfin pour vous en tant que développeur dans cette position, Je pense que l’essentiel est de développer le meilleur code possible dans ces conditions - documentez-le, écrivez vous-même des tests, si nécessaire (en particulier pour les dépendances externes) et utilisez votre connaissance du système pour communiquer les fonctionnalités qui sont réellement essentielles et essentielles. -avoir et lesquels peuvent attendre une semaine ou un mois. Faites-vous entendre sur vos préoccupations et justifiez-les comme vous nous l'avez fait. Plutôt que de vous préparer pour le plan B, préparez-vous au fait que vous et d'autres pauvres âmes réparerez probablement tout ce buggy et tout le code non terminé APRÈS la livraison du produit - comme indiqué ci-dessus, cela signifie que vous devez écrire votre code de manière modulaire et découplée - si vous pensez que le code de la couche de persistance est mauvais, vous devriez pouvoir le remplacer complètement lors de la prochaine révision. Enfin, ne désespérez pas - le traitement de cette situation fait partie de ce que vous ' être payé et c’est un processus d’apprentissage. Quels que soient les résultats de ce projet, cela comptera comme une expérience précieuse dans le futur.