Comment dois-je me comporter en tant que développeur dans un projet voué à l'échec?
Je suis développeur au sein d'une équipe de 5 membres et je pense que notre projet se dirige vers un désastre. Je vais expliquer pourquoi dans un instant, mais ma question est: comment dois-je me comporter?
Le délai est fixé à 1,5 mois, et je pense que quoi que nous fassions, ce projet échouera. Je suis d'avis que nous devrions simplement mettre fin au projet et arrêter de perdre notre temps, mais politiquement, je pense qu'il est impossible pour notre manager de le faire.
Que dois-je faire dans ce cas? Dois-je faire des efforts supplémentaires, ou devrais-je simplement me détendre? Et que dois-je dire au manager?
Raisons de l'échec de ce projet:
- Alors que la date limite approche, 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 est très difficile à comprendre, très difficile à modifier - Le modèle de données est trop piloté par une base de données relationnelle complexe (plus de 100 tables)
- Leadership peu clair; le gestionnaire répond aux nouvelles informations avec des changements majeurs
- Presque aucun test automatisé ou test unitaire
- Dépend fortement d'autres systèmes, mais pas encore de tests d'intégration
En fait, nous avons en fait hérité de ce projet (avec le désordre) il y a environ 1-2 mois d'une autre équipe de développement sous le même manager, qui y travaille depuis quelques mois.
Communiquez vos préoccupations de la manière la plus concise et la moins conflictuelle possible sur 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'elle doit faire, mais c'est à vous d'évaluer et de communiquer la situation. Utilisez le courrier électronique, afin de laisser une trace papier lorsque les choses vont au sud.
Cela fait, continuez à travailler sur le projet de bonne foi.
Gardez à l'esprit que vous ne savez peut-être pas tout ce qu'il faut 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 semblent stupides pourraient en fait être basées sur un raisonnement intelligent qui ne vous est pas visible.
Gardez une trace papier (par exemple, journal intime, e-mails enregistrés, etc.). N'incluez que des faits et objectif observations. Laissez toutes les conclusions à quiconque (le cas échéant) lit ce que vous avez écrit.
En tant que développeur, si vous n'êtes pas considéré comme un obstacle au projet, vous vous en sortirez probablement du doigt qui se produira sans aucun doute. Votre manager n'est peut-être pas aussi chanceux, mais ce n'est pas pertinent ici.
Juste sur des principes généraux, mettez à jour votre CV et assurez-vous de rencontrer occasionnellement d'autres développeurs en dehors de votre entreprise. Si vous ne faites partie d'aucun groupe de développeurs local, rejoignez-en 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 la considérer comme une rue à double sens - si vous pouvez aider à combler une ouverture dans votre entreprise avec quelqu'un de compétent, c'est tout 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 répandu dans le développement de logiciels. En raison de la compression planifiée, du gonflement des fonctionnalités ou d'une mauvaise gestion, de nombreux projets se retrouvent dans un mauvais état; cela aide à comprendre que vous n'êtes pas seul et que votre projet n'est pas la seule marche de la mort. L'auteur Edward Yourdon classe 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'éloigner. Je pense que ce livre vous aidera à comprendre quelle est votre gamme d'options et à préciser ce que vous pouvez et ne pouvez pas faire.
Désenchevêtrement de catastrophe est plus écrit pour les chefs de projet. Il vise à déterminer comment trier un projet cassé: qu'est-ce qui doit être coupé, ce qui peut être réduit et comment le présenter aux clients? La gestion de projet de logiciel "conventionnel" nous met dans des projets désordonnés, et nous n'échapperons pas à nos problèmes en utilisant la même pensée qui nous a amenés en premier lieu. Ce livre est un peu plus difficile à lire que Death March , mais c'est un bon livre à avoir sur votre étagère.
3 stratégies simples et cyniques pour maintenir carrière/santé mentale.
Voyez une épave de train en train de se former - descendez du train: les projets qui échouent sont terribles pour le moral et à moins que vous n'ayez des compétences de gestion à la hausse, les ninjas auront un impact négatif sur votre carrière. Sautez maintenant si vous pouvez voir un atterrissage en douceur.
Si cela ne fonctionne pas, gardez la tête baissée: les gens vont commencer à chercher des personnes à blâmer - ne leur facilitez pas la vie! Bien que l'escalade des préoccupations dans 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 manager transmette vos préoccupations et le contourner vous rendra non seulement mauvais, mais pourrait vous qualifier de `` fauteur de troubles '', c'est-à-dire le genre de personne à qui l'on peut reprocher de saper le projet en premier lieu, etc. Bien sûr, cela signifie aussi être professionnel, mettre vos heures mais pas d'héroïsme.
Prévoyez une sortie de secours à T + 1: offrez-vous des options et préparez dès maintenant les bases d'un éventuel 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 se laisser submerger par 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 à souffrir du désagrément qui se présente à vous. Soyez professionnel, optimiste mais toujours réaliste.
Quel impact ce projet qui va bientôt échouer 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 propre excellence personnelle.
Les qualités que vous manifestez face à l'adversité et parfois ce qui semble être un échec certain, sont souvent remarquées par les plus hauts gradés, plus que vous ne le pensez. Et je parle au-delà de votre supérieur immédiat.
J'ai personnellement vu le licenciement de mon supérieur immédiat 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 qui accompagnent un projet qui échoue, vous offrent la possibilité de briller.
Alors regardez le projet de cette façon: quelle opportunité ce projet défaillant offre-t-il pour que la lumière brille sur toutes mes forces et mes meilleures qualités? Quelles leçons puis-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 vrai succès.
Remarque: Thomas Owens a demandé quelles choses spécifiques 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. Aidera-t-il un projet de détresse à réussir miraculeusement? Non - mais j'ai trouvé que cela m'a aidé à garder une bonne perspective des choses et à trouver un succès personnel malgré la mauvaise situation.
1) Concentrez-vous sur l'excellence personnelle - efforcez-vous d'écrire du code toujours meilleur, de répondre à des normes de qualité et de fonctionnalité toujours plus élevées.
2) Concentrez-vous sur les mesures personnelles - combien de code écrivez-vous, qui génère des bugs ultérieurs? Réduisez ce ratio à un niveau aussi bas que possible. Lorsqu'on vous demande de fournir une estimation pour une tâche qui vous est assignée, êtes-vous généralement précis ou trouvez-vous que vous avez trop/trop tamponné la chronologie? Lorsque vous êtes effectivement affecté à une tâche, fournissez-vous un bon niveau de rétroaction sur la progression du travail, y compris en prévenant à l'avance les problèmes de calendrier de livraison?
3) Concentrez-vous sur les mesures de l'équipe - Ce ne sont que des choses qui me viennent à l'esprit: les autres membres de l'équipe sont-ils en retard 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âches à 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 régulièrement pour m'améliorer.
Dans une situation comme celle-ci, en tant que dernier échelon de l'échelle, vous ne pouvez pas faire grand-chose pour aider le projet.
- Assurez-vous que votre travail est impeccable
- aider à identifier les principaux 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
- conserver tous les e-mails, conversations IM
- Essayez de trouver un moyen de sortir du projet si cela est possible
Les projets qui échouent peuvent être toxiques pour l'âme, provoquer une dépression, un surmenage et une faible estime de soi.
Tout est relatif à la perspective.
J'ai travaillé sur des projets horribles en m'asseyant en face d'un autre gars qui avait le sourire aux lèvres 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 avec dans le domaine de leurs intérêts. Alors que d'autres, ont une forte réaction négative à 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 des délais
- contrôle de qualité
- professionnalisme
- conseils de la direction
Il existe de nombreuses équipes et entreprises qui ne trouvent pas les aspects de développement ci-dessus importants. Ce que j'ai trouvé, c'est qu'ils pensent souvent ce qui suit.
- La pression des délais est perçue comme un moyen de motiver les gens.
- La qualité coûte plus cher et les retours sont limités.
- Le professionnalisme s'applique à d'autres domaines de l'entreprise.
- Un manager est un chronométreur et non une personne qui contribue au développement.
Ces problèmes ne sont pas les vôtres. C'est le leur, et vous ne devriez pas gaspiller d'énergie pour leur comportement. Si vous n'êtes pas de ceux qui sourient et apprécient son travail alors qu'il se dirige vers une falaise, alors vous devriez penser à trouver un lieu de like minded développeurs.
Vous serez beaucoup plus heureux.
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 tant du projet global tant que vous assumez vos responsabilités.
2) CYA. Si le projet échoue et que vous soupçonnez que le gestionnaire commencera à blâmer tout le monde sauf lui-même, assurez-vous d'avoir suffisamment de preuves que vous avez fait tout ce qui était exigé de vous (voir point 1).
3) Faire quelques poli suggestions d'amélioration. Ne faites pas sonner les cloches d'avertissement, ne soyez pas maussade et sombre, soyez simplement poli et subtil.
Par exemple, si l'équipe n'écrit pas de tests unitaires efficaces (ou de tests), écrivez quelques tests unitaires plus près de ce que vous aimeriez voir et indiquez de manière causale comment cela vous a aidé à résoudre un problème particulier ou vous a fait gagner du temps.
Quoi qu'il en soit, si vous voulez affecter le changement, concentrez-vous sur les étapes positives qui ont des résultats concrets. Ce projet peut ne jamais s'avérer gagnant, mais peut-être que l'équipe peut apprendre pour le prochain.
Aussi:
4) Le refactoring opportuniste est votre ami.
Essayez d'être proactif pour trouver une nouvelle façon de réussir le projet. Réfléchissez à la façon dont vous pouvez proposer des alternatives. En ce moment, votre patron est probablement en train de se faire tabasser parce 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 existe-t-il un moyen de diviser les fonctionnalités en livrables échelonnés? Il y a souvent des degrés de "must have", alors voyez si vous pouvez obtenir ces priorités et les regrouper en étapes. Mieux vaut avoir un produit à la fin de la chronologie que rien. Ou envisagez de diviser l'équipe entre les personnes travaillant sur de nouvelles fonctionnalités et d'autres travaillant sur la stabilité, de cette façon, vous pouvez montrer des progrès sur les deux fronts.
Si ces efforts réussissent, vous aurez montré que vous êtes un membre de l'équipe qui peut trouver un moyen de réussir, sinon, vous aurez toujours démontré que vous n'abandonnez pas et travaillerez pour trouver une solution.
- Travailler dur; mais pas au détriment de votre famille ou de votre santé.
- Gardez une trace de toutes les décisions de conception critiques; surtout en ce qui concerne votre travail.
- Gardez le réseautage et gardez vos options ouvertes si la situation devient trop difficile ou si vous êtes victime d'une mise à pied massive.
- Essayez pas de considérer votre projet comme un "projet ayant échoué". Tout le monde aime les gens qui restent positifs et se battent durement face à l'adversité. Donc, aussi longtemps que possible, essayez d'être que personne. Une perspective positive, du courage et de la détermination sont toujours bons pour le lieu de travail.
- Si vous prévoyez un projet qui a échoué, vous prévoyez une réunion post-mortem. Lors de la réunion post mortem, tout le monde devra rendre des comptes. Soyez prêt à défendre tout votre code. [Remarque: En règle générale, vous devez toujours écrire du code propre afin qu'il soit facile de le défendre plus tard.] Si vous avez un e-mail ou un document de conception qui a inspiré vos décisions, c'est encore mieux.
- Lors de cette réunion post mortem, essayez de rester positif; et niquement présentez votre e-mail et la preuve du document de conception si votre jugement, effort ou exécution est remis en question.
Ce que j'ai trouvé le plus efficace, c'est la recommandation de Robert L. Read sur comment lutter contre la pression des horaires . Voici ce que Read écrit:
La clé pour lutter contre la pression du calendrier est simplement de la transformer en pression de mise sur le marché. La façon de le faire pour donner une visibilité sur 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 impliqué est la meilleure façon de le faire. Il présente l'avantage supplémentaire de permettre de bonnes décisions de gestion concernant les compromis possibles entre les fonctionnalités.
L'aperçu clé que l'estimation doit rendre clair est que le travail est un fluide presque incompressible. Vous ne pouvez pas emballer plus dans une période de temps plus que vous ne pouvez emballer plus d'eau dans un récipient au-delà du volume de ce récipient. Dans un sens, un programmeur ne devrait jamais dire "non", mais plutôt dire "à quoi allez-vous renoncer pour obtenir ce que vous voulez?". L'effet de produire des estimations claires sera d'augmenter le respect des programmeurs. C'est ainsi que se comportent les autres professionnels. Le travail acharné des programmeurs sera visible. L'établissement d'un calendrier irréaliste sera également douloureusement évident pour tout le monde. Les programmeurs ne peuvent pas être trompés. Il 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", cela est basé sur votre évaluation des tâches à accomplir et de l'effort requis par chacune d'elles. Rendre cette évaluation explicite , compréhensible et détaillé . Séparez les tâches en leurs composants; expliquer le plus en détail possible le temps de développement.
Une fois que vous avez fait cela, vous disposez d'une base solide pour discuter des préoccupations avec la direction. Selon toute probabilité, une fois que vous aurez divisé votre évaluation en toutes les tâches spécifiques qui doivent être accomplies, vous serez en mesure de démontrer que le travail prend plus de temps que vous - peut-être beaucoup, beaucoup plus.
Une fois que vous discutez de ce calendrier détaillé avec votre responsable, préparez-vous à être flexible. Votre responsable pourrait dire "La tâche X ne prendra pas un mois; cela prendra au plus une semaine" ou "La tâche Y est totalement inutile, supprimez cela du calendrier". Vous pouvez certainement discuter de ces points, mais ce qui est beaucoup plus important est de parvenir à une entente entre vous et votre responsable sur certains version réaliste d'un calendrier. De cette façon, si on ne vous alloue pas de temps pour, disons, des tests, alors vous avez une directive explicite de ne pas tester, plutôt que de simplement manquer de temps "de manière inattendue". Et il est certainement possible que votre manager soit légitimement disposé à couper explicitement certains coins afin d'expédier à temps - il y a beaucoup de cas où c'est un appel parfaitement raisonnable!
L'estimation vous donne une substance concrète pour débattre et discuter. Cela vous met sur la même page; cela vous aide à être sûr que votre manager a pris en compte vos préoccupations. Et cela vous amène au point où si votre manager demande clairement l'impossible, cela sera parfaitement évident pour vous deux. Si le projet est bel et bien voué à l'échec, vous l'aurez précisé et il appartiendra à votre responsable de décider précisément comment il souhaite que vous passiez votre temps.
Il y a déjà des tas de conseils pratiques (et autrement) 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 fixé à 1,5 mois
et
... nous avons en fait hérité de ce projet (avec le désordre) il y a environ il y a 1-2 mois d'un autre équipe de développement sous le même manager ...
Donc....
Bienvenue à Team Patsy Les Vengeurs
L'équipe précédente avait mieux à faire ... qu'échouer. Et en quelque sorte, le manager a accepté cela. Changer d'équipe si près de l'échéance n'est pas la meilleure décision de gestion de projet, alors ... qu'est-ce qui se passe?
Correction: l'équipe précédente 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, c'est à peine assez de temps pour se mettre à niveau sur un système de cette taille apparente, encore moins corriger son architecture, ajouter des tests et le terminer. Vous avez besoin de plus de temps
Et si vous ne pouvez pas le faire, sauf si vous êtes absolument certain que le projet sera prolongé indéfiniment, ou aidé par des elfes magiques ou quelque chose, vous ne voulez pas être le dernier homme à gauche tenant le sac.
Dur? Oui. Mais même si une mauvaise planification (au moins!) De la part d'équipes/gestionnaires précédents n'est pas de votre faute, "échec de livraison" ce sera.
L'équipe précédente a renfloué . L'équipe précédente a été expulsée du trottoir. Qu'est-ce que cela vous dit? Cela me dit que vous êtes l'équipe de redressement ... et votre manager compte sur votre héroïque pour sauver la situation.
Une équipe de 5 personnes et il reste 1,5 mois. La nouvelle équipe n'a eu le projet que pendant 1-2 mois, donc la nouvelle équipe n'est même pas sur la courbe d'apprentissage . Prenant une estimation approximative de la taille de ce projet, il me semble que il n'y a aucun moyen que la nouvelle équipe ait été sur la courbe d'apprentissage même si le projet n'avait eu aucun problème.
Donc, je pense (encore) que vous avez été trompé.
Si tel est le cas - et que vous seul pouvez décider ce qui est vrai ou ce que vous voulez croire - vous ne devez à personne d'explications ou d'excuses pour vous être éloigné de cette épave de train. Vous devez cependant être discret à ce sujet.
Je doute sérieusement que le gestionnaire ne soit pas au courant que le projet est en danger, ce qui signifie que des explications douces ne vous apporteront qu'une attention négative. A moins que votre manager ne soit M. Rogers , votre avenir est en danger.
Mais souvenez-vous toujours : ne prenez pas les conseils de carrière d'étrangers sur Internet.
Étant donné que votre gestionnaire sait que cela échouera probablement, vous êtes mieux que la plupart des autres. J'envisagerais de travailler avec le gestionnaire et de voir s'il existe des parties/fonctionnalités de l'application qui peuvent être exclues.
Trop souvent, nous pensons que chaque demande du client est un "tueur d'affaire" et nous nous efforçons de 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 n'êtes pas en mesure de le faire, essayez toujours de livrer ce que vous pensez être le plus important. Parfois, il est plus facile de demander pardon que de permission.
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'était pas la fin du monde.
Voici quelques observations dont je me souviens.
Les développeurs à des postes juniors ("code par spécification", "corriger le bug", des trucs comme ça) ne sont pas beaucoup affectés, à moins qu'ils ne se relâchent en raison d'une baisse du moral de l'équipe. Dans des positions comme celles-ci, une stratégie de survie sensée et parfois réussie pourrait simplement faire de votre mieux.
- Par exemple, l'un des échecs que j'ai rencontrés a été surmonté par la correction simple et méthodique de plus d'une centaine de bogues connus qui (associés à une approche particulièrement intelligente de promotion de ces progrès par le responsable technique) ont finalement conduit la haute direction à décider de récupérer le projet et de donner il a encore une chance avec une nouvelle version, qui à son tour a fait un succès raisonnable.
Les programmeurs à des postes supérieurs ( influents ) seraient mieux préparés à partager les conséquences négatives de l'échec du projet. Un architecte, un responsable technique et un développeur senior sont généralement censés avoir un impact suffisamment important pour être considérés comme responsables de la réussite ou de l'échec du projet.
À un poste de niveau supérieur, il vaut mieux être prêt à tirer profit de l'échec "indirectement", en analysant ce qui a mal tourné et ce qui aurait pu être mieux fait.
Ces connaissances, les leçons post-mortem peuvent être inestimables si elles sont apprises correctement, la carrière très réussie à des postes supérieurs peut dépendre de la façon dont elles sont apprises, comme expliqué dans cette brillante réponse 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 considérer l'approche de la "prochaine version/mise à jour" comme un moyen possible de sortir de l'échec. Par coïncidence ou non (je pense que pas ), mais les deux échecs qui n'ont pas nui à ma carrière sont passés par des scénarios très similaires: release N était un désastre total, libération N+1 était tolérable, libère N+2 et plus tard ont été un succès.
En marchant dans vos chaussures, je mettrais très probablement un certain effort dans la préparation/promotion de l'idée de la "prochaine version". Faites (et communiquer !) Quelque chose comme une liste provisoire de problèmes connus que vous voudriez résoudre après version prévue. Rédiger une feuille de route informelle et approximative pour les prochaines versions.
Réfléchissez à la façon dont vous pourriez communiquer ces idées aux gens autour de vous, à la façon dont vous pourriez influencer la direction pour qu'elle réfléchisse à ce plan. Si le projet a quelqu'un avec de bonnes compétences en marketing, essayez de les impliquer dans l'amortissement des dommages dus à l'échec en regroupant la prochaine version en termes plus fluides, comme "accès anticipé", "bêta", "prévisualisation client", "version d'introduction", des trucs comme cette.
Pensez à un plan de sauvegarde au cas où des niveaux supérieurs sembleraient sourds à cette idée. Rappelez-vous l'histoire ci-dessus sur "la correction de plus de cent bogues connus"? il y a vraiment une chance que les choses changent.
La direction peut sembler sourde aux idées de la prochaine version, mais elle a de bonnes chances de reconsidérer face à des preuves convaincantes solides de la qualité du projet.
- Il est très probable qu'il s'écoulera un temps assez long entre le gel du code pour la sortie prévue et la décision de gestion de le supprimer complètement. Ce moment est votre chance: si vous concentrez vos efforts sur la résolution des problèmes connus et sur une "évangélisation" appropriée des progrès, cela pourrait faire une différence (comme cela m’a déjà été fait).
C'est une opportunité incroyable pour vous! Prenons un point de vue entrepreneurial à ce sujet.
En supposant que la direction souhaite que ce projet réussisse, vous êtes bien placé pour les aider à le faire. La raison pour laquelle cette réalisation est si importante est que vous devez développer la conviction et la confiance que les signes d'alerte que vous voyez vont en fait conduire à l'échec de ce projet [1].
C'est votre chance de pratiquer 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 aussi clairement et simplement que possible.
Reconnaissez ici votre opportunité d'améliorer vos compétences.
[1] L'annulation du projet serait en fait un succès. L'échec reviendrait à dépenser bien après mal.
Que pouvez-vous faire
Traitez cela dans vos propres termes d'excellence, c'est "leur" projet, mais aussi le vôtre, prenez-vous en main même si vous savez qu'il échouera. Pourquoi? parce que a) vous pourriez l'aider à échouer un peu moins, b) en période de défi, c'est là que vous apprenez le plus c) vous devriez vous mesurer via vos propres mesures d'excellence, faire de votre mieux pourrait ne pas sauver le projet, mais vous pourrait finir par ê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 soin (ne faites pas croire aux gens que vous voulez commencer une mutinerie ou quelque chose), cela peut vous aider non seulement vous mais d'autres aussi
Ignorer le problème ne va pas le faire disparaître, parler des moyens de le faire, contre toute attente, le faire passer, par exemple au moins obtenir des havres décents décents, ou le cas d'utilisation principal du "facteur wow" bien fait, pourrait faire échouer ce projet moins misérablement. Comment faire? eh bien, peu d'idées sur "quand aller devient difficile dur se met en marche" ou "des temps désespérés justifient des mesures désespérées" et d'autres clichés, par exemple: utilisation massive d'OSS, programmation extrême/méthodologies agiles, hackathons le week-end (volontaires uniquement, ne forçant pas les gens à week-ends de travail). C'est le moment où vous pouvez faire preuve de leadership (soigneusement si vous n'êtes pas dans une position de chef d'équipe/senior), mais vous pouvez profiter de cet avantage et devenir leur moqueur, faites simplement sentir aux gens qu'ils pourraient obtenir ce projet un peu moins d'échouer que tout le monde le sait. Vous pouvez montrer ici certaines compétences en leadership qui pourraient vous aider plus tard en cours de route, traiter le problème comme un défi.
Assurez-vous que votre direction le sait, mais très, très attentivement, s'ils le savent, ils apprécieront que vous leur disiez cela de manière non conflictuelle et calme, sinon, ils l'apprécieront encore plus, et se demandent pourquoi personne ne l'a dit avant. Vous devriez leur dire cela comme un service, sans aucun côté émotionnel, juste des faits simples et sans agenda. S'ils vous demandent ce que vous pensez qu'ils devraient faire (ce qui est un grand signe, mais rare), alors consultez 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 la mauvaise nouvelle. Pourquoi est-ce une bonne idée? eh bien, je vais citer le manifeste pour le développement de logiciels agiles, mais même sans lui, même les amoureux des chutes d'eau détestent les mauvaises surprises. Si le client sait à l'avance que ce projet est voué à l'échec, il sera mécontent, mais sera beaucoup plus heureux que vous lui disiez qu'il y a des problèmes avant qu'il ne lui saute au visage, que vous y soyez et que vous fassiez de votre mieux pour vous adapter 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'ils n'ont pas de livrable (ou ils le font mais c'est de qualité non utilisable). Le client l'appréciera car il pourra retarder l'embauche du personnel de test, des informaticiens offshore, modifier ses plans de formation internes, et tout simplement parce que vous avez été honnête avec eux.
avec le client, réfléchissez aux moyens de faire encore quelque chose avec le projet, le plus courant étant la descente des choses. par exemple, certaines fonctionnalités peuvent être trop difficiles à développer de la manière dont elles ont été conçues, et si le client accepte certaines 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 devez [~ # ~] pas [~ # ~] faire
Demandez à ajouter plus de personnes au projet (voir this )
Quittez/cherchez un autre emploi (du moins pas encore), c'est quelque chose que 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 le temps, à mieux concevoir, à mieux écrire le code et à mieux travailler avec vos pairs et la gestion. Cherchez un emploi après ces 2 mois si vous n'aimez pas travailler là-bas, pas pour toute autre raison.
Pleurnicher, se plaindre ou être négatif sur le projet, la gestion, la mauvaise conception dont vous avez hérité, les développeurs débutants que vous avez appris à vous mentir qu'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 gestion et devenez une cible en tant que fauteur de troubles, ils sont dans le même bateau, et ils savent peut-être des choses que vous ne savez pas, tout ce que vous pouvez faire est de les mettre à jour (mettez toujours à jour votre propre gestionnaire direct, ne la contournez jamais)
Blâmez les gens (ou vous-même), cela n'aide pas, jamais
Prenez-le trop au sérieux, à moins que ce ne soit du matériel médical, personne ne risque de mourir si vous manquez les délais, c'est un logiciel, nous manquons les délais pour vivre, détendez-vous.
C'est juste mes deux cents, YMMV
Trouvez les problèmes rencontrés par votre projet et essayez de quantifier clairement le plus objectivement 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 trouvait pas dans une "plage acceptable". Vous devrez donner quelques directives pour chaque métrique afin d'indiquer quelles valeurs sont "bonnes", "acceptables", "problématiques" ou "mauvaises". Définissez chaque critère à l'avance. Si possible, vous pouvez décrire ce qui serait le moins nécessaire à la réussite d'un projet et le comparer avec le 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 vous le souhaitez. Les mesures que je vous suggère de commencer par:
- Complexité cyclomatique
- Taille de votre code (ex: Nr de lignes par fonction/classe, nombre de fichiers, nombre de tables ...)
- Identifiez les modules trop volumineux
- Reproduction.
- Adhésion au style de code
- Taux de défauts
- par KLOC par module et ou sous-système (identifiez les parties problématiques de votre système)
- vous pourriez calculer combien par membre de l'équipe, mais je pense que vous devriez garder cela pour vous
- résolu vs trouvé
- temps nécessaire pour résoudre un bug (peut-être si cela est incliné, faites un graphique de cela)
- peut-être faire une estimation du temps nécessaire si cela continue au rythme actuel
- Planification
- Extrapoler le temps utilisé pour les fonctionnalités intégrées. Tenez compte de la complexité de la fonctionnalité. Cela n'a pas besoin d'être très précis. Ce que vous voulez transmettre avec cela serait dans le sens de "Les fonctionnalités A, B et C sont à peu près la même complexité que D, E et F. Avec les fonctionnalités ABC utilisées à 170% si le temps prévu. Si rien ne change, nous nous attendons à la même chose. du temps est nécessaire pour DEF "ou le long de la ligne de" La fonctionnalité moyenne prend X% de temps de plus que calculé. Nous n'avons aucune raison de supposer que le reste de la fonctionnalité est plus facile à construire, nous devons donc compenser cela dans la planification future Il est inutile d'avoir une planification si elle n'est pas réaliste.
- Essayez d'avoir un calendrier de diffusion 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 fin d'une version). Faites une planification pour chaque cycle et assurez-vous que les nouvelles fonctionnalités n'entrent que dans le cycle suivant (c'est-à-dire qu'elles ne peuvent jamais être ajoutées au cycle actuel).
- Couverture de test: expliquez les valeurs de couverture de test "normales" et montrez en quoi consiste 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)
- Basé sur le package
- Basé sur un sous-système (combien de chemins de communication existe-t-il?)
Vous devriez aller travailler et faire ce que vous feriez sur 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/chef de file, il n'est pas de votre responsabilité de décider qu'un programme doit être annulé ou non. Vous décidez de relâcher la même chose que vous prenez la décision d'annuler le projet. Cela ne fait pas partie de votre description de poste.
Cependant, 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 travail de la direction de déterminer comment atteindre les objectifs du projet. Plus de 50 heures de travail ne sont pas une option raisonnable, sauf si elles sont prêtes à payer des heures supplémentaires et que vous êtes prêt à suspendre votre vie de famille. Une fois de plus, il incombait à la direction d'élaborer un calendrier réalisable. Ils ne peuvent pas supposer qu'ils peuvent forcer les employés à ignorer leur vie familiale afin de respecter des horaires irréalistes.
En outre, alors que le calendrier peut indiquer 1 mois et demi restant. Ce n'est probablement pas la date de "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à injecté beaucoup d'argent dans le projet. Parfois, l'entreprise elle-même peut assumer des frais supplémentaires pour garantir un client satisfait. Tout cela est hors de votre contrôle. Faites votre travail au mieux de vos capacités. Cela donnera des options de gestion avec lesquelles travailler pourrait transformer un projet en catastrophe en une grande réussite. Je l'ai vu se produire plusieurs fois.
Il peut être un moyen facile de supposer qu'il s'agit d'un échec inévitable et absolu et d'abandonner le projet. En tant que consultant, je suis souvent invité à aider avec des projets qui sont à divers stades de dégénérescence, qui ont échoué ou qui échouent et une partie de ce pour quoi je suis payé est de relancer et de terminer de tels projets.
Ce que vous considérez comme un échec complet peut ne pas être perçu comme tel par tout le monde, selon 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 de chaque ligne de code testée. Je n'ai pas vu un seul projet qui ressemble à ça dans la rév 1. Dans le monde réel, expédier un projet signifie prendre des compromis, peut-être même manquer certaines fonctionnalités clés, mais le produit peut être livré et même s'il sera au mieux de qualité bêta , au moins, vous obtiendrez des commentaires sur les choses à corriger en premier. L'avantage est qu'il peut informer la direction que le logiciel n'est jamais terminé et plutôt que d'essayer de développer une certaine version 1.0 sous vide, il est préférable d'itérer et de répondre 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 des tests vous-même, si vous le devez (en particulier pour les dépendances externes) et utilisez votre connaissance de la système pour communiquer quelles fonctionnalités sont vraiment essentielles et indispensables et lesquelles peuvent attendre une semaine ou un mois. Faites entendre vos préoccupations et justifiez-les comme vous nous l'avez fait. Plutôt que de préparer le plan B, préparez-vous au fait que vous et d'autres pauvres âmes réparerez probablement tout ce code buggy et pas encore fait APRÈS que le produit a été expédié - comme indiqué ci-dessus, cela signifie écrire votre code de manière découplée modulaire - si vous pensez que le code de la couche de persistance est mauvais, j'espère que vous devriez pouvoir le remplacer complètement dans la prochaine révision. Enfin, ne désespérez pas - faire face à une telle situation fait partie de ce pour quoi vous êtes payé et c'est un processus d'apprentissage. Quel que soit le résultat de ce projet particulier, cela constituera une expérience précieuse à l'avenir.
Je ne peux que réitérer ce que les autres ont dit, mais je souligne avec insistance: Toujours s'efforcer d'obtenir votre meilleur travail et garder une trace écrite. pour l'ACY et pour des raisons techniques.
Toute chute à venir dépend du caractère personnel de la direction; mais permettez-moi de vous dire que l'enfer est du côté de la réception d'une gestion incompétente et menteuse. Mais le pire que vous laisserez avec votre respect (et celui de vos pairs) intact.
Gardez de bonnes notes sur les aspects techniques de votre marche de la mort. Lorsque vous obtenez la question inévitable de l'entretien avez-vous été sur un projet qui a échoué; pourquoi a-t-il échoué et qu'avez-vous fait pour essayer de l'empêcher? La gestion de Bonehead n'est pas une réponse - même si c'est la raison .