Quel est le moyen le plus productif de gérer les échecs liés au développement? [fermé]

Nous y avons tous été:

• Votre projet a échoué ou a été annulé.
• Le code sur lequel vous avez passé plusieurs jours à travailler a été rejeté par votre équipe.
• Le modèle de conception que vous avez présenté à l'équipe a créé le chaos.
• Tout le monde ignore vos idées.

Ma question est la suivante: quel est le moyen le plus productif pour un programmeur de gérer de telles défaillances liées au développement?

Votre projet a échoué.

Le développement logiciel est très sujet aux échecs de projet et, en fonction de sa gravité, il est préférable que ce soit géré par la direction.

De nombreux projets ont échoué et d’autres échoueront, alors prenez des notes! Découvrez pourquoi votre projet a échoué afin de ne pas commettre les mêmes erreurs la prochaine fois. Vous apprenez beaucoup plus de vos échecs que de vos succès.

Ce que vous avez passé des jours de codage a été rejeté par votre équipe.

Enregistrez votre travail (pour plus tard). Il y a deux possibilités: (a) C'est nul, et le fait que plusieurs personnes aient réagi de la même manière en est une indication (b) C'est vraiment un travail de génie, mais bien en avance sur ce que les gens sont habitués ou peuvent comprendre. Les gens n'aiment généralement pas ce qu'ils ne comprennent pas. Peut-être vaut-il mieux le montrer au moment opportun ou dans un endroit différent avec une "culture" différente

Personne n'écoute tes idées dans ton entreprise.

C'est probablement une mauvaise idée, OU la culture ne correspond pas à votre façon de penser. Soit vous vous déplacez dans un endroit qui correspond à votre culture, soit vous soumettez à une nouvelle évaluation critique de votre idée (de manière objective, sans votre propre parti pris) -> mon idée est-elle vraiment bonne? <- Tue ton ego

Le modèle de conception que vous avez introduit avec force dans votre équipe a créé un désordre.

Soyez honnête, vous avez fait de votre mieux, mais votre planification n'a pas abouti. Il peut être préférable de recommencer ou d'apprendre des erreurs commises dans la conception en équipe et d'aller de l'avant.

Ce ne sont pas des échecs, ce sont des expériences

Vous apprenez et grandissez de vos expériences en réfléchissant à la façon dont elles vous ont fait ressentir et si vous souhaitez davantage de ce sentiment.

Si c'est une mauvaise expérience (comme la liste que vous avez proposée), le mauvais sentiment qui vous accompagne est probablement quelque chose que vous voudrez éviter (en supposant que vous n'ayez pas une peau si épaisse que vous ne vous souciez pas de l'impact de vos actions).

Dans l’ensemble, ne vous impliquez pas trop dans la comparaison avec les autres, ils ont tout autant de difficulté à travailler à travers tout cela que vous-même .

• Restez calme - ne paniquez pas, cela ne fera rien de mieux
• Contrôle des dommages - sauvegarde de ce qui peut encore être sauvegardé
• Apprenez de vos erreurs - refaire le mauvais ne le fera probablement pas
• Considérez un nouveau départ - démarrez votre prochaine tentative sans un sac à dos de déceptions et de sentiments coupables
• Regardez les plus gros échecs - comparé au premier vol d'Ariane 5 , votre échec est négligeable
• Consultez un psychothérapeute si vous ne pouvez pas le gérer seul

Vous construisez quelque chose.

Pour moi (je pense que cela ne convient pas à tout le monde), construire quelque chose (bandes dessinées, dessins, petits jeux, etc.) revient à créer un peu de confiance en soi pour revenir à la lutte contre l'échec. Ce pourrait également être un bon moyen d’exprimer votre colère, votre amertume ou tout sentiment relatif à l’échec, mais de manière "constructive".

Cela fonctionne pour moi de toute façon.

Eh bien, vous avez demandé :) Un par un:

* Your project failed.

Ce n'est pas nouveau. Nous avons tous échoué en privé et nous avons tous échoué devant nos pairs. Quiconque a fait des études primaires et secondaires en a fait l'expérience.

Si je ne peux pas faire d'erreurs et espérer un emploi stable, vous devriez envisager d'envoyer une note aux ressources humaines pour leur faire savoir que les êtres humains seront bannis de toute considération future.

Plusieurs échecs consécutifs signifient soit que vous avez des exigences et des spécifications déraisonnables, soit que vous ne tirez pas les leçons de vos erreurs. Dans les deux cas, une action immédiate s'impose.

Il est concevable que de nombreuses personnes choisissent quelque chose simplement pour obtenir un emploi, puis trouvent un moyen de satisfaire les exigences.

* What you have spent days coding was rejected by your team.

Cela arrive. Comme d'autres l'ont noté, sauvegardez-le. Refais-le. C'est pourquoi nous appelons cela le travail. Je pense que dans ce cas, vous n'avez probablement pas beaucoup impliqué l'équipe dans ce que vous faisiez.

Il se pourrait également que les exigences aient changé hier ou il y a une heure. Cela devrait être une exception, pas une norme, cependant. L'évaluation par les pairs est aussi brutale qu'utile. Si votre code est constamment rejeté comme "insuffisant" (ou quelque chose du genre), vous devriez passer plus de temps à cueillir les cerveaux et à faire participer les autres. Je pense que cette question est une erreur dans la plupart des environnements d’équipe, à moins que «l’équipe» ne soit tout simplement auto-descriptive.

* Nobody listens to your ideas in your company.

Encore une fois, cela nécessite un contexte. Combien de temps avez-vous été là? À quel point vos collègues pirates font-ils confiance en vos capacités? Avez-vous pensé que les idées générant plus de travail pour de nombreuses personnes pourraient inciter TOUT motif à le rejeter? Une fois, quelque chose a été rejeté parce que IPV6 n’était pas prêt, mais il utilisait une simple socket de domaine sur le périphérique de bouclage (exclusivement). La personne qui l'a coulé ne pouvait tout simplement plus prendre de travail.

Aussi, à quel point vous articulez-vous? Pouvez-vous faire des amis et influencer les gens?

* The design pattern you introduced with force in your team created a mess.

D'où pourquoi la force aurait dû être évitée. Etre capable de parler n'est pas une condition préalable pour pouvoir écouter. Pas d'autres commentaires.

Oh mon dieu, c'est beaucoup si vous vouliez vraiment tout ce qui vous est arrivé!

AVERTISSEMENT : dans beaucoup des points ci-dessous, vous pourriez avoir l’impression que je vous critique et que je tiens à vous rendre responsable des erreurs commises et non à prendre en compte des facteurs externes. Je ne. C'est juste que vous ne donnez pas beaucoup de détails, et je ne fournis que des listes de contrôle des actions à entreprendre pour vous assurer que les choses ne vont pas mal. Je sais que j'ai moi-même fait beaucoup d'erreurs (tout le monde le fait) et nous ne nous améliorons que si nous apprenons d'eux. Et pour apprendre d'eux, nous devons commencer par les considérer comme des erreurs et accepter la responsabilité de ce qui a mal tourné de notre côté. Enfer, accepter la responsabilité de ce qui a mal tourné dans les rôles des autres, vous pouvez aussi apprendre de cela.

Votre projet a échoué

Pas grand-chose à faire pour l'atténuer maintenant.

Cependant, vous pouvez faire beaucoup pour éviter que cela ne se reproduise à l'avenir. Je suggérerais d'essayer d'améliorer vos compétences en matière de gestion de projet et de temps.

Un des livres avec le meilleur rapport ((conseils valides) / pages) que j'ai lu sur le sujet, même s'il n'est peut-être pas le meilleur, c'est Radical Project Management de Rob Thomsett .

Vous ne précisez pas vraiment ce que votre projet a échoué, mais je supposerais une combinaison de ce qui a entraîné un déséquilibre dans le triangle coût / temps / qualité habituel . Le facteur le plus important à mes yeux est de diriger le projet et le développement tout en restant en contact avec vos acteurs techniques (développeurs et testeurs) mais également avec vos parties prenantes. Beaucoup trop de projets échouent parce qu'ils n'écoutent pas les sponsors ou les parties prenantes et ne les poussent pas à s'impliquer dans le processus.

S'ils ne sont pas impliqués, vous ne pouvez pas savoir ce qu'ils veulent. Si vous ne pouvez pas savoir ce qu'ils veulent, vous ne pouvez pas le livrer. Si vous ne le livrez pas, ils seront malheureux. C'est un échec. De plus, si vous n'impliquez pas vos parties prenantes, elles sont déconnectées de la réalité du génie logiciel, ce qui signifie qu'elles ne comprennent pas vos problèmes. S'ils sont souvent en contact avec vous, ils comprendront mieux ce dont vous avez à traiter. Ils seront plus en mesure de comprendre quand vous leur direz qu'une "petite" fonctionnalité [rire] prendra des mois. Ils peuvent avoir davantage confiance en votre planification, car ils ont contribué à sa construction. Un projet ne peut pas réussir avec juste "les spécifications au début, dev, les tests, la livraison à la fin". Ce n'est jamais le cas. Vous pourriez livrer ce qui était demandé dans les spécifications,

Le plus important est également de faire une rétrospective et de s’assurer qu’elle est sans ego et non un jeu de reproches. Identifiez simplement les problèmes.

Ce que vous avez passé des jours à coder a été rejeté par votre équipe

J'ai été dans cette situation. Encore une fois, vous ne pouvez rien faire pour atténuer cela, sauf:

• Gardez-le dans le SCM pour plus tard.
• Peut-être essayez-vous d'insérer progressivement des petits morceaux dans la base de code principale au lieu d'un refactoring énorme.

Mais il y a encore des choses que vous pouvez faire pour éviter ce genre de situation:

• Pourquoi est-ce arrivé? Quelle est la raison du rejet?
• La plupart du temps, lorsque cela se produit (et ce fut également le cas pour moi), cela signifie que le développeur est allé en solo ou en mode codage cow-boy et a produit des choses inédites. Un code qui ne provient pas d’exigences professionnelles peut être sophistiqué et "meilleur", mais constitue souvent une perte de temps et d’argent. De plus, cela coûtera encore plus cher si vous l’intégrez, car il devra être testé à nouveau. Pensez comme ceux qui vous distribuent de l'argent: vous devez également être efficace à ce niveau.
• La qualité du logiciel produit était-elle satisfaisante? At-il été conforme aux normes et conventions en vigueur dans votre entreprise?
• Avez-vous périodiquement (et fréquemment!) Signalé aux directeurs directs à ce sujet? Avez-vous eu des échanges occasionnels avec d'autres développeurs de l'équipe? Sinon, ils ne savent rien à ce sujet, il en coûtera énormément de temps pour les évaluer et les examiner maintenant. Il ne compte pas au même moment à la fin. C'est comme si vous essayiez toujours de remettre à plus tard le nettoyage de votre appartement locatif, puis d'essayer de le nettoyer uniquement lorsque vous déménagez: c'est un travail minable, c'est épuisant, c'est plus dur que si cela avait été fait régulièrement, et souvent cela ne sera pas fait droite.
• Avez-vous produit des tests? Tests unitaires? Tests d'intégration?
• Votre code a-t-il été enregistré régulièrement dans le SCM? Était-ce dans une autre branche? Avait-il besoin d'une autre branche ou aurait-il pu être fait dans le coffre? Différer du code valide est généralement un mauvais signe. Évidemment, parfois, vous êtes tenté de le faire, mais vous vous tirez une balle dans le pied.

Personne n'écoute vos idées dans votre entreprise

Eh bien, il y a 2 options ici, et nous allons examiner les deux:

• Vos idées étaient mauvaises.
• Vos idées étaient bonnes.

Commençons par supposer qu'elles sont mauvaises (encore une fois, réfléchir et accepter votre idée était tout simplement mauvais, cela pourrait être difficile, je le sais). Que faites-vous pour changer cela?

• Pourquoi avez-vous eu l'idée? Quelle est la raison ? Y a-t-il un besoin réel de ce que votre idée tente d'apporter à la table?
• Comment avez-vous eu cette idée? L'avez-vous fait vous-même? Avez-vous partagé? Idée de génie? Plan? Prototype? (Faites-les dans le bon ordre. Si le processus échoue, abandonnez l’idée, ne continuez pas. Ou du moins pas sur votre horaire de travail.)

Les idées ne sont que des idées. Si vous ne les proposez que comme des idées et qu’elles sont rejetées, je ne vois pas pourquoi vous vous sentiriez mal à ce sujet. Si, toutefois, vous agissez sans avis à personne et ALORS, vous ne soumettez que vos idées et elles sont rejetées, de toute évidence, je ressens la frustration du temps perdu. Et vos gestionnaires font pour!

En supposant que vos idées étaient bonnes:

• Votre présentation était-elle bonne?
• Votre façon de faire la présentation était-elle bonne? (Je suis développeur, je sais de quoi je parle: nous sommes des PITA grincheux, arrogants et pédant qui ont toujours raison et avec qui il est difficile de travailler avec à cause de notre ego démesuré ).
• Avez-vous un plan pour le mettre en œuvre? Avez-vous pensé au coût et au temps? Avez-vous pensé aux avantages pour les utilisateurs / clients? Avez-vous pensé à l'impact sur les ventes? Avez-vous pensé que le fait de travailler sur cette idée pourrait avoir un impact sur d'autres projets et priorités? Vous allez me dire: "Pourquoi devrais-je faire tout cela, c'est le travail de mon responsable et des équipes de marketing ou de vente ?!" Sauf que maintenant, vous essayez de faire une partie de leur travail.

Le modèle de conception que vous avez introduit avec force dans votre équipe a créé un désordre

• Pourquoi avez-vous introduit le motif?
• Si cela a créé un désordre, alors probablement:
  • n'était pas le bon modèle,
  • n'a pas été mis en œuvre correctement,
  • n'était pas intégré à droite.
• Comment l'avez-vous présenté? Comment définissez-vous exactement l'état "mess"?
  • code moins lisible?
  • moins maintenable?
  • les constructions sont brisées?
  • Il y a différents types de "bazar". Le fait de savoir en quoi consiste le gâchis peut aider à savoir quelle est l’échec et si c’est la faute du modèle de conception.

De plus, je suis un peu surpris par l'approche elle-même. Vous avez réellement dû faire pression pour qu'un modèle de conception soit introduit? Cela semble plutôt étrange. Un modèle existe déjà ou vous avez besoin de refactoriser une partie de votre solution en fonction du modèle. Vous ne le poussez pas comme vous le feriez pour l'adoption d'un framework ou d'une technologie (comme des personnes poussées très fort pour avoir du XML partout, et maintenant comme si elles poussaient pour pouvoir écrire HTML5 sur leur couverture de produit en grosses lettres lumineuses).

Pourquoi as-tu dû pousser? Pourquoi y avait-il de la résistance? C'était peut-être justifié.

Avez-vous été en mesure de fournir des exemples indiquant que ce modèle particulier contribuerait à améliorer votre base de code de manière significative (par exemple, en le faisant correspondre à un exemple de Refactoring en Modèles ).

Note complètement hors sujet, mais c'est ce à quoi je pensais pour la première fois en lisant le titre de la question, car je pensais qu'elle faisait référence à des échecs logiciels ... J'avais un logiciel qui implémentait une classe BlackHole pour gérer un type très spécial d'exceptions dans l'un des Composants. Cela peut sembler (et est vraiment) un hack visiblement étrange et sale, mais le nom lui-même était si superbe que nous l’avons tous apprécié pour un moyen plutôt cool de gérer un échec! :)

Étape 1: C'est bon de se mettre en colère!

Tout d'abord, il est compréhensible d'être contrarié ou en colère lorsque l'on rencontre un échec. S'ils donnent des conseils à une personne se trouvant dans une telle situation, elle ne voudra probablement pas entendre "Laisse-toi aller et passe à autre chose" ou "Pense-y simplement comme une opportunité d'apprentissage".

En fait, je pense qu’il peut être sain et productif de se fâcher et d’évacuer ses frustrations, à condition de le faire en privé ou avec un ami. Les gens ont différentes façons de le faire, mais je pense que l’un des moyens les plus productifs est d’écrire une fausse lettre fâchée (Important! N’envoyez pas cette lettre à qui que ce soit ). Expliquez vos sentiments, en expliquant par exemple pourquoi vous estimez que tout ce qui s'est passé était injustifié.

Étape 2: Prenez le temps de vous calmer.

Assurez-vous de bien exprimer tout ce que vous ressentez et, après avoir dissipé votre colère, prenez simplement le temps de vous calmer. Peut-être n'avez-vous besoin que de quelques minutes, voire de quelques heures.

Étape 3: Passez en revue ce qui s'est passé à l'étape 1

J'espère que vous pourrez alors penser plus objectivement à la situation. Si vous avez écrit une lettre, lisez-la vous-même. Si vous vous êtes confié à quelqu'un, essayez de vous rappeler ce que vous avez dit. Si vous vous imaginez crier après quelqu'un, alors examinez-le mentalement.

J'écris souvent une lettre quand je suis en colère, puis après m'être calmée, je m'efforcerai de l'affiner pour communiquer plus clairement ce que j'essayais de dire jusqu'à ce que je sois convaincu que quelqu'un le lirait comprendrait ce que j'étais. se sentir à l'époque.

Le but est d'essayer objectivement de déterminer quels étaient vos arguments. Ont-ils eu un sens? Ils ont peut-être besoin de précisions ou de détails supplémentaires. Sont-ils non fondés? Si vous deviez vous mettre objectivement à la place de quelqu'un d'autre, comprendriez-vous ce que vous avez dit? Seriez-vous d'accord avec ces points? Vous pouvez utiliser cette opportunité pour vous évaluer. Qu'est-ce que vous avez bien fait? Quelles sont les choses que vous auriez pu mieux faire?

Étape 4: décider d'un plan d'action

Peut-on faire quelque chose pour remédier à la situation ou au moins l’améliorer? Prenez un moment pour déterminer s'il est réaliste de faire quelque chose pour corriger ou améliorer la situation. Souvent, il n'y en a pas, mais parfois il y en a.

Si vous êtes en faute pour quelque chose, cela pourrait être aussi simple que des excuses officielles à quelqu'un, expliquant clairement ce qui n'allait pas, ce que vous avez fait, pourquoi vous l'avez fait et ce que vous allez faire pour le réparer ou l'empêcher de se produire l'avenir.

Ensuite, réfléchissez à ce que vous pouvez faire pour améliorer l’avenir. Que pouvez-vous faire pour éviter que la même chose ne se reproduise? Décidez ce que vous voulez réaliser et utilisez ce que vous avez appris à l'étape 3 pour créer votre propre plan.

Si tout échoue, essayez de redémarrer:

        try
        {
            // ...
        }
        catch (OhNoes111Exception)
        {
            // reboot fixes everything!
            System.Diagnostics.Process.Start("ShutDown", "/r");
        }