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! :)