Que peut-on faire quand “donner l'exemple” ne fonctionne pas? [fermé]

Je travaille pour une grande entreprise (plus de 8 000 employés) depuis près de 2 ans et j'ai été embauché juste après avoir terminé mes études.

Tout le monde ici est confronté quotidiennement à un code hérité qui est souvent très mal conçu et bourré de bidouilles. Au début, je suis resté discret, en essayant de ne pas trop critiquer les choses. Mais la situation actuelle est devenue très difficile à vivre et personne ne semble vouloir améliorer / remplacer les outils que nous utilisons.

Pour être plus explicite, nous avons:

• Un outil de contrôle de source obsolète (Visual SourceSafe)
• Vieux makefiles qui ne supportent que la reconstruction complète
• .def fichiers qui doivent être gérés manuellement et séparément pour toutes les architectures existantes
• Fichiers d'en-têtes monolithiques et projets avec très peu de fichiers différents (mais chacun a environ 3000 lignes de code, ce qui prend parfois en charge des tâches très différentes)
• aucune utilisation des « nouvelles » installations de langues (et std::stringn'est pas nouvelle mais personne sauf moi l' utilise)

J'ai décidé, il y a quelques mois, d'agir, en concevant un nouvel environnement de compilation. Je pouvais obtenir des versions incrémentielles fiables, des temps de compilation plus rapides, des projets mieux structurés, la .defgénération automatique de fichiers. J'ai même créé un pont de / vers Git vers / à partir de Visual SourceSafe.

J'ai montré mes réalisations à plusieurs collègues et à notre patron, mais c'était comme si personne ne s'en souciait. Ils étaient tous du genre "Eh bien ... les gens ont l'habitude de le faire ainsi maintenant. Pourquoi changerions-nous les choses?"

Les changements que j'ai suggérés ont été conçus de manière à permettre une transition en douceur de l'ancien système au nouveau. Chaque amélioration peut être appliquée séparément et en toute sécurité.

J'ai même essayé d'impliquer certains de mes collègues dans les changements. Mais jusqu'à présent, pas de succès.

Avez-vous déjà fait face à une situation similaire? Que peut-on faire quand "donner l'exemple" ne fonctionne pas?

But pour la tête : "Diriger par l'exemple" devrait avoir une amélioration en tête, mais il devrait être ciblé sur les personnes non sur la technologie. Peut-être avez-vous investi trop de temps dans l'amélioration de la technologie, mais pas assez dans ce qui se passe dans leur tête. Pensez aux facteurs déterminants pour lesquels il existe une opposition à de nouvelles choses. Dans de nombreux cas, ils craignent simplement certains risques. Identifiez ces risques et trouvez des contre-arguments.

Prenez la viande fraîche : il est plus facile de gagner les employés qui veulent changer les choses. Vous les remarquez immédiatement quand vous les voyez.

Évitez la viande pourrie : certains ne comprendront jamais vos idées. Laissez-les de côté.

Devenez une masse critique : Trouvez des personnes qui comprennent vos idées. Gagner le par un. À un moment donné, si une masse critique est atteinte, de plus en plus de personnes suivront volontairement votre exemple.

Vocabulaire de gestion : les gestionnaires ne sont pas intéressés par de meilleures conceptions. Leur langue est l'argent et le temps. Précisez combien d'heures de travail sont perdues pour les bugs. Indiquez clairement que les clients insatisfaits qui rencontrent des bugs ne sont pas rentables. Montrez à quel point vous pouvez implémenter une nouvelle fonctionnalité plus rapidement. Vous devez choisir un autre vocabulaire pour les gestionnaires.

Tout est une question de processus : les meilleures technologies ne font pas de meilleurs programmeurs et programmes. Si vous avez de bons processus en cours d'exécution, même des technologies obsolètes donnent de bons résultats. Pensez aux efforts et au temps perdu. Peut-être que ce n'est pas la technologie, mais quelque chose dans les processus va terriblement mal. Dans la plupart des cas, c'est un manque de communication.

Trouver une nouvelle entreprise : Vous avez déjà beaucoup travaillé. Vous pouvez toujours essayer d'améliorer les choses, mais c'est également à vous de décider combien de temps vous voulez l'essayer et combien d'énergie vous voulez investir. N'oubliez pas que même si vous ne pouvez pas obtenir beaucoup d'amélioration, vous en apprendrez beaucoup sur vos efforts. À un moment donné, vous devez passer à autre chose.

Avez-vous déjà arrêté de considérer que vous pourriez avoir tort?

Donc, vous lisez des dessins de modèles et de modèles à l’école et vous êtes privé de ce qui semble être des pratiques relativement désuètes où vous travaillez. Il ne fait aucun doute que ce sont de meilleures idées et que les nouveaux projets devraient commencer avec cela à l’esprit, mais il semble que vous vous trouviez à un tout autre niveau.

Rassembler les développeurs, c'est comme essayer de rassembler les chats, ils ont un esprit qui leur est propre et une façon préférée de faire les choses, qu'ils soient corrects ou non. J'ai assez de mal à appliquer les meilleures pratiques et à gérer une équipe de 2 développeurs, mais vous travaillez pour une entreprise qui en compte 8 000.

C'est un nombre incroyablement énorme. Même un simple changement de processus selon lequel tous les développeurs doivent planifier des réunions et que le calendrier public ne soit pas au bureau devient une politique extrêmement complexe et difficile à mettre en œuvre de manière globale. La direction aurait également besoin de beaucoup d'efforts pour s'assurer que la politique est acceptée et adoptée à tous les niveaux.

Vous ne le penserez peut-être pas, mais quelque chose d'aussi simple que de passer de fichiers d'en-tête monolithiques à plusieurs, ou de déplacer le contrôle de version de SourceSafe vers Git nécessite un effort et un investissement énormes de la part de toutes les personnes concernées. Il faudrait:

• Soutien important de la direction

• Acceptation à l'échelle de l'entreprise

• Investissement des heures de réunion pour tous les développeurs afin de les informer des nouvelles initiatives (Les réunions coûtent des heures de travail, les heures de travail coûtent de l'argent)

• La formation doit être planifiée et mise en place pour que même les développeurs les plus stupides sachent ce qu’ils font.

• Même en supposant une heure de formation, à travers 8 000 développeurs x 50 € / heure = 400 000 € de coût de formation. C’est plus que ce que mon équipe de développement logiciel reçoit au cours d’une année entière au titre du budget, des logiciels et du matériel. C'est un investissement exceptionnel que vous proposez.

Mais vous dites: "Pensez à tout le temps que vous pourriez gagner en augmentant votre productivité." À juste titre, mais un investissement important représente un risque important, alors je ferais mieux de vous assurer que vous avez raison à ce sujet avant de le signer. Si aucun des cadres supérieurs ne vous soutient, je ne peux pas justifier la dépense. En fin de compte, nous pourrions être inefficaces, mais nous sommes cohérents et avec 8 000 développeurs dans l’entreprise, la cohérence est le plus important.

Pour ce faire, vous devez vous connecter avec plusieurs responsables et trouver le moyen de mesurer avec précision et objectivité le temps perdu par les développeurs. Ce temps équivaut à des dollars et seuls les dollars et la politique vous aideront à gagner cette bataille.

Ce que vous avez décrit ne me semble pas "donner l'exemple", cela ressemble à une proposition que vous avez faite et qui a été rejetée. Pour montrer l' exemple, vous devez montrer aux gens que votre chemin est meilleur. Parmi les problèmes que vous avez énumérés, je vois trois que vous pouvez commencer à utiliser vos propres modifications.

Vieux makefiles qui ne supportent que la reconstruction complète.

Créez vos propres fichiers makefile localement et montrez à quel point vous êtes en mesure de travailler avec eux plus efficacement.

Fichiers d'en-têtes monolithiques et projets avec très peu de fichiers différents (mais chacun a environ 3000 lignes de code, ce qui prend parfois en charge des tâches très différentes)

Soit séparez les existants lorsque vous les touchez (sans rompre la construction), soit introduisez des fichiers d’en-tête plus petits lorsque vous écrivez un nouveau code. Lorsque les gens commenceront à travailler avec eux, ils se rendront compte qu'ils n'ont pas besoin de duplication.

pas d'utilisation des "nouvelles" installations de langage (enfin std :: string n'est pas nouveau mais personne d'autre que moi ne l'utilise)

Continuez à introduire de nouvelles fonctionnalités linguistiques chaque fois que vous touchez un ancien code ou introduisez un nouveau code. Assurez-vous de simplifier les choses. Ne vous découragez pas de celui-ci. La plupart d'entre nous sont paresseux. Si nous voyons qu'une nouvelle fonctionnalité de langage facilite les choses, nous l'adopterons.

Après quelques mois, si d'autres développeurs commencent à adopter vos améliorations, vous pourrez à nouveau contacter votre patron à propos de changements plus radicaux, tels que la mise à niveau de votre système de contrôle de source. Vous devez toutefois vous assurer que les autres développeurs voient les avantages, sinon ils ne passeront jamais. Une façon de le faire serait de suggérer d’essayer Git sur un petit projet auquel peu de développeurs sont actifs. De cette façon, vous pouvez en faire une évaluation, et non une transition à grande échelle vers un système inconnu.

Enfin, si après plusieurs mois d’essais, personne ne semble vouloir améliorer la façon dont les choses se passent dans votre entreprise, vous devez vraiment vous demander si c’est un bon choix pour vous.

En plus de Lionel Barret (avec lequel je suis plutôt d'accord), considérons également la possible motivation à la résistance.

• Évaluer le coût du processus réel
• Évaluez le coût du processus car il sera comme le vôtre

Mais aussi:

• Evaluer le coût du changement en terme de
  • Argent à dépenser pour configurer le nouvel environnement pour quiconque
  • Temps à consacrer à apprendre à tout le monde à s'habituer au nouveau mode (cela peut être facile pour vous, mais pas si facile pour des personnes qui ne sont pas au courant de ce que vous faites)
  • Temps nécessaire pour gérer le changement de manière non perturbatrice.

J'ai un suspect: combien y a-t-il dans votre entreprise de personnes comme vous en termes d'âge et de culture (hommes "école" et "type d'école")? Combien de personnes comme vous devraient être embauchées au cours des deux ou trois prochaines années et combien vont prendre leur retraite ou changer de rôle au sein de l'organisation?

Mon suspect est que vous n’êtes pas assez fort pour changer la société. Dans cette situation, la société va vous changer ou vous "expulser" (dans le sens où cela deviendra votre propre désir de partir), si vous ne pouvez pas attendre plus de temps.

Mais peut-être que la société évalue que les coûts supplémentaires que je vous ai décrits peuvent être économisés, permettant ainsi au processus de changement de se produire spontanément en attendant le remplacement naturel des personnes. Vous êtes juste au début d'un processus que vous ne pouvez pas voir car il n'y a rien (encore) derrière vous.

À ce stade, je ne peux ajouter qu'une référence à l'article de Joel Obtention du résultat final lorsque vous n'êtes qu'un grunt . Les sections comprennent:

Stratégie 1 Il suffit de le faire

Stratégie 2 Exploiter la puissance du marketing viral

Stratégie 3 Créer une poche d'excellence

Stratégie 4 Neutraliser les Bozos

Stratégie 5 Évitez les interruptions

Stratégie 6 Devenir inestimable

Je résumerais l'article comme suit: "Le changement doit commencer par vous."

Malheureusement, les gens se retrouvent coincés dans une ornière et développent la mentalité selon laquelle «cela fonctionne, tout le monde l'utilise bien, pourquoi le changer» et cela devient exaspérant.

Vous vous y êtes pris correctement, non seulement en vous plaignant, mais en développant une solution viable comme solution de remplacement, il ne vous reste plus qu'à souscrire à la proposition.

Montrez votre responsable hiérarchique direct (ou votre responsable technique). S'ils ne sont pas intéressés, avez-vous quelqu'un en charge du contrôle du changement ou de l'innovation?

Mais potentiellement, vos idées et votre travail pourraient être ignorés et la situation restera telle quelle.

Vous devez exposer votre cas de manière à obtenir votre patron de votre côté. BTW, ce type de changement est proposé par un directeur technique ou un chef de projet, vous devrez donc vous engager pour le projet. (En guise d'alternative, vous pouvez proposer un audit technique, un étranger dira probablement la même chose que vous mais aura plus de poids.)

Jusqu'à présent, il ne voit pas la nécessité de changer, il semble que les produits cosmétiques changent: coûteuse sans avantages évidents sauf pour satisfaire la fantaisie d'un développeur. Deux choses lui importent: le flux d’argent et une équipe stable. La technologie est une boîte noire, si cela fonctionne, c'est suffisant.

Tout d’abord, vous devez prouver que la configuration actuelle lui coûte de l’argent. Quel est le coût / heure d'un développeur et combien d'heures de compilation plus rapide le sauveraient? Faire le calcul. En outre, rédigez des articles ou des témoignages sur les risques du pipeline de codes actuel et montrez-lui des chiffres inquiétants: "à cause des pratiques de codage SourceSafe / Bad, notre société a perdu XXXK $".

Deuxièmement, votre patron peut être coincé avec de vieux codeurs grincheux qui ne veulent pas changer leurs habitudes. Si le premier point est établi, vous devez également proposer une solution à ce problème. Combien êtes-vous ? Il pourrait être intéressant de souligner qu'il sera difficile de remplacer quelqu'un car le pipeline de codage actuel est bizantine. Vous devez proposer un plan pour mettre à jour l'équipe. Apprenez-leur la meilleure pratique de l'industrie et vérifiez qu'ils respectent les nouvelles règles.

Enfin, vous devez proposer un plan pour modifier la base de code, divisée en petits projets, avec jalons et affectation des ressources. En fait, vous vous vendez en tant que chef de projet et les modifications sont obligatoires pour disposer d'un pipeline de code solide.

Travaillez-vous dans une organisation qui croit que bien faire les choses, que l’efficacité et l’innovation mènent au succès et à la rentabilité; ou que la recherche du revenu et le maintien des ventes sont les prémices du succès?

Les entreprises qui se comportent comme vous le décrivez sont bien implantées sur le plan technologique. Sur un marché concurrentiel, ils ne pourraient pas concurrencer une entreprise centrée sur les individus et l'innovation.

Si vous êtes la personne que vous dites être, travaillez dans un endroit qui honore et récompense votre esprit. Après des années d’installation, vous finirez par accepter la même philosophie que celle adoptée par vos supérieurs. Allez travailler ailleurs (probablement une organisation plus petite) qui valorise le travail acharné, l'inspiration, la créativité et le progrès.

Si vous ne prenez pas de risque et que vous le faites rapidement, vous finirez par vous installer et vous ne pourrez plus continuer à nourrir votre curiosité et votre créativité car elles sont philosophiquement opposées dans votre groupe de pairs actuel.

L'excellence est une attitude et une vision du monde.

Sachez simplement que cette expérience vous a permis de savoir ce qu’il faut éviter, gardez un œil sur la complaisance et le protectionnisme afin de pouvoir le détecter rapidement.

Lors de votre prochain entretien, posez des questions telles que "Quels genres d’innovations proviennent de vos employés", "Quels sont les changements apportés par la créativité individuelle?", "Quels talents individuels puis-je apporter à cette équipe?", "Quels sont les facteurs de succès de votre organisation ? "," Comment votre organisation adopte-t-elle continuellement l'innovation technologique? "... Les réponses à de telles questions sont extrêmement révélatrices. De nombreuses organisations n'ont pas de vision, ou celles qui ont créé cette vision ont disparu, et l'organisation est dirigée par des comptables. Si vous interviewez le directeur de la technologie, demandez-lui s'il considère l'organisation comme une entreprise de technologie.

Si vous n'aimez pas l'environnement dans lequel vous travaillez, vous vous rendez un mauvais service. Vous devez être entouré de personnes ayant des intérêts et des objectifs similaires à ceux de votre profession. Je sais que parfois c'est plus facile à dire qu'à faire, mais le sentiment de regarder plusieurs années en arrière et de se sentir perdu vous fait perdre du temps, c'est pire que la peur de prendre un risque.

Au lieu de cela, si vous souhaitez développer un système ou un environnement utilisant une technologie et / ou des méthodologies spécifiques, je vous suggère de rechercher un projet en dehors du travail auquel vous pouvez contribuer. À tout le moins, la variété de travail sur les deux systèmes répondra au besoin de quelque chose de différent pendant que vous trouvez votre position.

Il me semble que vous êtes un poisson hors de l'eau. Allez trouver votre corps d'océan et nagez!