Que faire en tant que développeur lorsque, pendant des années, leur équipe a manqué d'innovation produit, n'a pas utilisé les méthodologies de gestion de projet et a conservé de mauvaises pratiques de développement logiciel? [fermé]

Je souhaite savoir comment gérer un processus de développement logiciel actuel qui n'a pas été modifié depuis des années et qui finira par entraîner une défaillance du produit et de l'équipe. Oui, probablement la manière la plus simple de résoudre ce problème est de changer d'emploi, mais avec cette économie, c'est plus facile à dire qu'à faire. Cependant, si vous avez des exemples spécifiques et que vous avez vu ou été plusieurs fois dans la même situation et pensez que la meilleure solution pour résoudre ces problèmes est de quitter l'entreprise, veuillez soutenir votre réponse. Le fait est que cette question a vraiment une réponse, surtout si plusieurs experts sur le sujet finissent par indiquer que la meilleure route à suivre est la route A.

Je sais que des tonnes de développeurs ont été ou sont dans des situations similaires. C'est l'une des principales raisons pour lesquelles les entreprises passent de la première place sur leur marché à la dernière voire à la sortie du marché. Espérons que les réponses de cet article aideront d'autres développeurs confrontés à des obstacles similaires. Dans une petite ou une grande équipe de développement, cela se produit généralement:

• Certains développeurs semblent ne pas s'en soucier et décident de suivre le flux et préfèrent laisser le code avec beaucoup d'odeur de code tel qu'il est et le processus de développement tel quel,
• D'autres se lassent de ne pas changer et démissionnent et déménagent dans une autre entreprise,
• D'autres semblent avoir peur de parler et préfèrent rester silencieux,
• Parfois, très peu de développeurs ou un seul essaient de défendre l'amélioration du produit et disent à l'équipe combien il est important de suivre les meilleures pratiques de codage et les avantages de le faire pour les clients, les utilisateurs et l'équipe. Ces types de développeurs décident généralement de rester avec l'équipe pour des raisons telles que la société offre des avantages que très peu de sociétés de logiciels offrent, ou le produit a beaucoup de potentiel, etc.

Le produit de notre équipe n'est qu'une fraction de la source de revenus de la société car elle a un ensemble de produits (cette société n'est pas une société de logiciels / matériel; par conséquent, pas de litige constant en matière de brevets, du moins pour l'instant, ce qui crée des emplois instabilité). Ce que j'ai appris jusqu'à présent au cours de ces années grâce aux expériences d'autres développeurs et mon expérience est que pour vraiment connaître une équipe de développement, cela prend du temps, pas des jours, ni des semaines, mais quelques mois. Pendant le processus d'entrevue, si l'équipe veut vous embaucher ou a besoin de vous; ils font tout sonner bien et ils peuvent vous dire ce que vous voulez entendre. Cependant, la réalité est différente lorsque vous commencez à travailler dans cette équipe et commencez à creuser dans le code et à vous diriger vers le processus SDLC complet. C'est alors qu'en tant que développeur, vous commencez à voir la réalité du travail dans lequel vous vous êtes engagé. Cette réalité fait qu'il est difficile de vouloir passer d'une entreprise à une autre car il est difficile de savoir si l'entreprise dans laquelle vous déménagez sera meilleure ou pire. Oui, vous pouvez lire les avis sur Glassdoor, etc., mais combien de ces avis en ligne sont réels et ne proviennent pas des RH?

Quelle serait la meilleure façon de résoudre les problèmes décrits ci-dessous, étant donné que le gestionnaire, depuis le début, a toujours résisté au changement, et que les développeurs précédents font de même depuis des années?

• Manque d'innovation produit depuis des années: Le produit a beaucoup de potentiel et apporte de bons revenus à l'entreprise, mais le produit semble avoir été fabriqué il y a 20 ans. Certains utilisateurs se sont plaints que le produit n'est ni convivial ni intuitif, et d'autres ont mentionné qu'ils sont habitués à des applications comme Gmail et sont frustrés lorsqu'ils utilisent le produit en raison de l'absence de fonctionnalités similaires. Le problème principal ici est que lorsque vous essayez en tant que développeur d'apporter des modifications au produit et commencez à déplacer les principaux éléments du produit à quelques pixels de distance (pour le rendre plus convivial ou intuitif), le gestionnaire panique et vous dit pour le remettre où il était. Si vous essayez d'ajouter une fonctionnalité qui améliorera la productivité des utilisateurs, le gestionnaire vous demande de la supprimer car "les utilisateurs sont habitués à faire le processus tel qu'il est, etc." Je pense que vous avez compris la résistance au changement, à l'amélioration et à l'innovation (le gestionnaire n'est pas ouvert au changement, même lorsque vous, en tant que développeur, fournissez de solides arguments en faveur des avantages). La société a quelques concurrents dans le domaine (les produits de quelques-uns d'entre eux sont bien plus compétitifs), mais d'une manière ou d'une autre, la société a maintenu les clients actuels pendant des années.

• Manque de coordination de la gestion de projet: En conséquence, certains projets sont livrés en retard, avec des bogues et certains clients se plaignent (les clients signalent également les bogues), ou le budget est utilisé trop rapidement avant de livrer le projet, etc. Je les ai fournis quelques conseils de coordination de projet et les idées sont maintenant utilisés régulièrement pour suivre l'avancement des projets et des tâches à effectuer.

• Mauvaises pratiques de développement de logiciels: l'odeur de code est visible sur la plupart, sinon tous les fichiers, pas de documentation, redondance de code, niveau frontal et principal mélangés sur le même fichier, outils de développement obsolètes, pas de véritable environnement de test ni d'outils de test (il suffit de copier-coller fichiers de l'environnement de développement à la production, puis testez manuellement que les choses semblent bonnes et libérez-les). La plupart des outils de développement que j'utilise pour le développement et les tests sont inconnus de l'équipe, car l'équipe n'utilise que 2 IDE pour le développement de code et le contrôle des sources n'est disponible que pour l'environnement de développement. D'autres développeurs ont essayé d'utiliser les derniers frameworks pour améliorer les problèmes actuels, mais le gestionnaire ne l'aime pas à cause de "que se passe-t-il si vous partez, alors qui va maintenir ce code?, Laissons-le tel qu'il est" Certains de ces développeurs ont déjà quitté et a déménagé dans une autre entreprise.

En résumé, je suis sûr que des situations similaires se produisent pour de nombreux développeurs dans d'autres entreprises, mais en raison de circonstances différentes, un développeur peut préférer rester dans l'équipe plutôt que d'aller dans une autre entreprise pour des raisons telles que (commodité du travail, flexibilité du travail, avantages sociaux ou juste parce qu'une meilleure opportunité n'est pas arrivée). Il n'y a pas d'entreprise parfaite à ma connaissance, mais comment, en tant que développeur, vous comporteriez-vous et aborderiez-vous toutes ces questions afin de garder les choses positives et, finalement, de promouvoir le changement pour l'amélioration du produit et l'amélioration du processus de développement logiciel (si vous en avez plusieurs)? ans d'expérience en développement ou juste quelques-uns)? Je sais que ce message est long, mais j'ai préféré donner des détails supplémentaires pour augmenter les chances d'obtenir des commentaires plus utiles.

Merci beaucoup pour tous vos commentaires et votre temps

La citation de Martin Fowler est pertinente: "Vous pouvez changer votre organisation ou changer votre organisation." Étant donné que vous avez apparemment décidé de changer votre organisation (l'améliorer) au lieu de changer votre organisation (travailler pour une autre organisation), voici quelques suggestions.

Premièrement, une grande partie de votre plan d'action dépend des détails sur les structures de pouvoir et la politique au travail. Existe-t-il un ou plusieurs responsables du développement logiciel? S'il y en a plusieurs, y en a-t-il qui ne sont pas opposés au changement? Combien y a-t-il de développeurs de logiciels? Les développeurs sont-ils intéressés à changer? Si tel est le cas, vous devez pouvoir apporter des modifications même sans l'approbation de la direction. (Comme Fowler le suggère dans Refactoring , vous n'aurez peut-être même pas à en parler à la direction. Vous êtes probablement engagé pour développer le logiciel du mieux que vous pouvez, donc s'il y a une meilleure façon de le faire, alors faites-le.)

Deuxièmement, gardez à l'esprit que la direction peut avoir de bonnes raisons pour ce qu'elle fait. Vous êtes développeur de logiciels; votre travail consiste à développer de bons logiciels et à connaître les bonnes techniques pour le faire. Le travail de la direction consiste à comprendre les problèmes généraux et les considérations commerciales qui peuvent être au-delà de votre compétence. Même si vous avez raison et qu'ils se trompent sur les considérations commerciales (vos préoccupations concernant le manque d'innovation, les retards de livraison, les plaintes des clients, etc.), comprendre d'où vient la direction vous aidera à communiquer dans leurs termes, à atténuer leurs préoccupations, etc.

Troisièmement (et connexes), assurez-vous de pouvoir parler la langue des affaires. Une entreprise n'est (à juste titre) pas directement concernée par les bonnes pratiques de développement de logiciels; une entreprise est soucieuse de répondre aux besoins des clients et de réaliser des bénéfices. (Et de nombreuses entreprises feront évidemment le minimum de services nécessaires pour réaliser un profit.) Vous serez plus efficace pour promouvoir le changement si vous pouvez expliquer comment les mauvaises pratiques de développement de logiciels et le manque d'innovation nuiront au profit de l'entreprise ou à long terme santé.

Quatrièmement, changer une culture d'entreprise de la position d'un employé de base est extrêmement difficile. James Shore (un consultant agile et auteur) a écrit un journal de changement décrivant ses propres efforts pour y parvenir. Je recommande fortement de lire le tout. Quelques points pertinents:

• N'essayez pas de tout changer d'un coup. Trouvez les plus gros points douloureux et commencez par là. Obtenez tout le monde à bord en les aidant à voir comment vos changements répondent à ces points faibles.
• Comprenez les perspectives des autres. Shore parle de la façon dont les changements qu'il préconisait du point de vue du développement logiciel ont été résistés par le chef de projet parce qu'il (Shore) n'a pas envisagé comment les changements affecteraient le chef de projet.
• Finalement, vous aurez besoin d' une assistance plus élevée, même si vous êtes vous-même à l'origine de la plupart des changements. Shore parle de son champion ("quelqu'un avec qui je travaille qui a plus d'influence que moi et pense généralement dans le même sens que moi").

La réponse courte évidente est de quitter l'entreprise. D'autres sont déjà partis et votre manager est un obstacle actif au progrès. Si vous restez dans cette position, vous vous décomposerez lentement (à la fois en termes de moral et de compétences). Trouver un nouvel emploi n'est pas toujours facile, mais dans ce cas, c'est nécessaire.

Juste au cas où vous choisiriez de ne pas quitter l'entreprise (la première ligne de votre question le disait):

Votre manager a-t-il un patron? Si oui, comment ce patron voit-il le produit? Pouvez-vous (oserais-je même le dire?) Passer par-dessus la tête de votre manager et approcher son patron? Ne le harcelez pas avec des détails techniques, exprimez simplement votre intérêt et votre enthousiasme à grandir au sein de l'entreprise. Présentez des idées tangibles pour des améliorations qui affecteraient de manière mesurable le résultat net. Vous pourriez être promu sous l'obstacle.

Soyez averti cependant - alors que certaines roues grinçantes sont graissées, d'autres sont remplacées. Vous FEREZ que votre manager vous déteste fortement. Il va en entendre parler, et il va dire des choses méchantes sur vous à son patron. Faites preuve de prudence, mais n'oubliez pas - aucun risque, aucune récompense.

Le pire qui puisse arriver est que vous cherchiez un nouvel emploi, ce que vous devriez faire de toute façon.

On dirait qu'il est temps pour vous d'en apprendre davantage sur les vaches à lait. Allez ici et ici . Et jetez un œil à la matrice des actions de croissance . Le GSM fournit des informations supplémentaires sur les raisons pour lesquelles la vache à lait est un bon état.

Investopedia (deuxième lien) a probablement la meilleure citation dans ce cas.

1. Une vache à lait nécessite peu de capital d'investissement et fournit de façon continue des flux de trésorerie positifs, qui peuvent être affectés à d'autres divisions de la société. Ces générateurs de trésorerie peuvent également utiliser leur argent pour racheter des actions sur le marché ou verser des dividendes aux actionnaires.

Comme vous l'avez noté, il y a des avantages à être sur un projet de vache à lait.

• C'est stable
• Un degré modeste de nouveaux développements est garanti
• Il y a toujours un travail de correction de bugs à résoudre.

Et comme vous l'avez également noté, ces projets présentent certains inconvénients.

• Il est stable et la base de code ne tourne pas beaucoup
• Les nouvelles technologies sont généralement ignorées (trop coûteuses à installer)
• Et les choses deviennent ... périmées.

J'ai déjà travaillé sur un projet où j'avais de nombreuses plaintes similaires à celles que vous avez soulevées. Je me souviens distinctement avoir partagé mes préoccupations concernant la base de code avec mon patron à l'époque. Sa perspicacité n'était pas particulièrement éclairante, donc je ne la partagerai pas. Mais j'ai bloqué le projet et à vrai dire, c'était l'un des meilleurs projets que j'ai vus. Non, ce n'était pas flashy. Oui, nous avons manqué les délais. Oui, j'ai accumulé quelques marches de la mort à partir de là. Non, la technologie du code n'était pas si innovante que cela, mais nous avons généré des solutions incroyables.

Le problème était moi. Je n'avais pas assez de recul pour comprendre ce dont une base de code a réellement besoin pour survivre. Je n'avais pas l'expérience pour voir où l'innovation se produisait vraiment. Je ne comprenais pas les fondamentaux du marché qui dictaient le niveau de financement approprié pour ce projet de vache à lait.

Je vous encourage à voir cela comme une opportunité d'apprentissage pour mieux comprendre comment fonctionne l'entreprise et comment vous pouvez améliorer vos compétences en adaptant un produit aux besoins de l'entreprise. Bien que le travail ne soit pas tape-à-l'œil, le potentiel d'apprentissage est élevé et ces compétences vous tiendront bien plus tard dans votre carrière. La majorité du développement au niveau de l'entreprise tourne autour de toutes les contraintes que vous venez de mentionner. Le code pue; les choses ont été giflées pour contenir des délais qui s'étaient déjà écoulés; de nombreux développeurs résistent au changement.

À un moment donné, vous continuerez à quitter le projet. Les leçons que vous pouvez emporter avec vous peuvent être de véritables leçons de carrière.

Votre manager résiste probablement au changement car il ne voit aucune valeur (commerciale) qui change les pratiques. L'entreprise ne voit aucun problème réel car tout ce qui est demandé à l'équipe de développement est finalement fait et les plaintes des clients ne parviennent pas aux personnes qui se soucient et / ou peuvent faire quelque chose pour assurer un meilleur résultat. Soit cela, soit l'entreprise a fini par accepter que la situation actuelle était inévitable.

Si vous voulez changer les pratiques de développement, vous devez leur montrer que la situation actuelle n'est pas inévitable. Et la seule façon dont vous allez être entendu est de construire une analyse de rentabilisation montrant comment la situation actuelle fait grimper le coût du produit et freine le potentiel de revenus dans un autre état de la situation.

Pour construire cette analyse de rentabilisation, vous devez parler au chef de produit de ce logiciel. Le chef de produit est la personne qui décide de la priorité des articles à développer en fonction de la valeur commerciale qu'ils représentent. Le chef de produit est (devrait être) celui qui peut voir les avantages et la valeur commerciale de pouvoir construire plus rapidement de meilleurs logiciels.(Et j'espère que ce n'est pas le même que celui en charge de l'équipe de développement.)

L'analyse de rentabilisation doit examiner quels sont les effets sur les revenus des entreprises de:

• Fonctionnalités qui ne sont pas (encore) implémentées et qui généreraient plus de clients ou retiendraient plus de clients si elles avaient été implémentées.
• Des fonctionnalités insuffisamment implémentées qui génèrent l'insatisfaction des clients et conduisent à l'attrition des clients.

L'analyse de rentabilisation doit également montrer comment les pratiques de développement actuelles affectent la vitesse et le coût de développement des fonctionnalités indispensables:

• Combien de temps il faut pour effectuer les modifications les plus simples.
• Combien de bogues sont introduits suite au développement de nouvelles fonctionnalités, à la fois dans la nouvelle fonctionnalité et aux dommages collatéraux dans d'autres fonctionnalités.
• Combien de temps est consacré à la correction de ces bogues qui ne peuvent pas être consacrés à l'implémentation de nouvelles fonctionnalités.
• Combien d'appels d'assistance sont générés en raison de ces bogues et combien le personnel d'assistance doit dépenser pour ces appels.

Et bien sûr, il doit montrer comment l'adoption de meilleures pratiques de développement va affecter ces chiffres.

Vous êtes probablement confronté au besoin d'une réécriture (majeure) des parties (majeures) du logiciel. Même si vous ne le faites pas, alors comment survivre à une réécriture de fond en comble sans perdre votre santé mentale est une lecture incontournable de la façon d'aborder ce type de projets.

Remarque finale: si le chef de produit n'est pas intéressé par tout cela, vous êtes perdu: sautez le bateau.

Je pense que c'est un problème vraiment difficile sans solution directe. Voici quelques idées sur ce que vous pourriez essayer de faire:

Peur du changement Au sujet de changer les choses pour le mieux, je comprends pourquoi les craintes des gestionnaires changent. Les gens sont habitués aux choses d'une certaine manière et si vous les changez, les utilisateurs se révolteront (peut-être). Le changement est une chose effrayante et nécessite généralement beaucoup de réflexion et d'étude avant d'être fait. Ce dont vous avez besoin, ce sont des données pour montrer que c'est mieux et que les utilisateurs le veulent. En parlant de gmail, vous pourriez envisager de faire quelque chose comme "Google Labs" où vous pourriez activer / désactiver de nouvelles fonctionnalités afin que les utilisateurs puissent les essayer. Ensuite, connectez une collecte de données autour de cela pour vous aider à sauvegarder vos modifications.

Changer le processus de développement logiciel Encore une fois, le changement est difficile, les gens ne changent pas simplement parce que vous dites qu'il existe une meilleure façon. Je pense que dans ce scénario, ma meilleure recommandation est de donner l'exemple. Faites les choses comme vous le souhaitez et montrez aux gens à quel point c'est mieux. De plus, et c'est la clé, vous devez trouver les autres personnes qui partagent vos pensées. Si vous pouvez embarquer quelques personnes, cela aidera grandement votre cause. Une fois que vous pouvez montrer des résultats, vous pouvez contacter la direction pour élargir ces changements. Je trouve qu'un effort descendant et à la base aide vraiment à apporter des changements.

Du côté des outils également, les entreprises craignent de les mettre à jour / les modifier car elles coûtent cher et les résultats des nouveaux outils ne sont pas toujours mesurables. Ma recommandation ici est de créer vos propres outils. Si vous créez le vôtre, vous gagnerez du temps et ferez un meilleur travail. Espérons que les gens commenceront à le remarquer et voudront ensuite les utiliser également.

Changer la gestion C'est difficile et je ne sais pas comment le faire, à part être quelqu'un qui produit des résultats et fait apprécier son opinion. Une fois que votre opinion est appréciée, les gens peuvent commencer à écouter ou non.

N'oubliez pas que le changement est difficile et prend du temps. Accrochez-vous et commencez petit et accumulez.