Comment suggérer des changements en tant qu'employé récemment embauché? [fermé]

J'ai récemment été embauché dans une grande entreprise (des milliers de personnes, pour donner une idée de la taille). Ils ont dit qu'ils m'avaient embauché en raison de ma rigueur et de mon expérience malgré ma jeunesse (j'ai 25 ans) en tant que programmeur C / C ++.

Maintenant que je suis rentré, je peux voir que tout le système est vieux et utilise souvent des technologies obsolètes. Il n'y a pas de convention de nommage (fichiers, fonctions, variables, ...), ils n'utilisent pas le contrôle de version, n'utilisent pas d'exceptions ni de polymorphisme et il semble que presque tout le monde a perdu sa passion (certains d'entre eux n'ont que 30 ans )

J'aimerais suggérer quelques changements, mais je ne veux pas être "le nouveau qui veut tout changer simplement parce qu'il ne veut pas s'intégrer". J'ai essayé de "m'intégrer", mais en réalité, il me faut une semaine pour faire ce que je ferais un après-midi, à cause des outils médiocres que nous sommes obligés d'utiliser. Beaucoup de mes collègues ne regardent jamais les nouvelles "choses" et techniques que les gens utilisent de nos jours. C'est comme s'ils venaient d'abandonner. La situation est vraiment frustrante.

Avez-vous déjà été dans une situation similaire et, le cas échéant, quels conseils me donneriez-vous? Y a-t-il une manière subtile de changer les choses sans devenir ici le mouton noir ? Ou devrais-je simplement abandonner ma passion et mon énergie?

Je vous remercie.

Mises à jour

Suite à vos précieux conseils, j'ai pu suggérer des modifications et je suis maintenant responsable de l'équipe qui doit créer et déployer Subversion: D Merci à vous tous!

6 mois plus tard

J'ai arrêté et trouvé un environnement beaucoup plus intéressant, avec un salaire bien meilleur et des défis plus intéressants. Je n'y retournerais pour rien.

Je me trouvais dans une situation similaire dans ma société précédente, où je travaillais depuis 5 ans. Quand je suis arrivé en 2004, ils étaient:

• utilise toujours Microsoft Access pour ses bases de données (même les plus critiques)
• Utilisation de Visual Basic 6 ou Access / Excel VBA pour le développement
• faire appel à de nombreuses tierces parties au lieu d'utiliser des ressources de développement en interne (les chefs d'entreprise dirigeaient leurs propres projets de développement et 90% du temps, ils passaient des marchés sans passer par IT)
• haleter pas de contrôle de version.

Quand j'ai quitté l'année dernière, l'entreprise était:

• utilisant exclusivement .NET et C #
• avait banni tout développement Access
• utiliser SVN pour le contrôle de version
• avait 2 boîtiers SQL Server costauds et migrait les bases de données Access existantes vers SQL
• tout le développement est passé par les équipes internes et n’a lancé un appel d’offres que si les ressources étaient limitées

À l'époque, je n'avais que 21 ans et le deuxième plus jeune membre de l'équipe de développement avait 30 ans. Je n'ai pas tout fait moi-même. Le responsable informatique avait rejoint l'entreprise au même moment et souhaitait que tout le développement passe par l'informatique.

SVN était ma première réalisation. J'ai rencontré mon supérieur hiérarchique et mis en lumière quelques situations dans lesquelles du code avait été mis en œuvre ou modifié, ce qui posait problème, ainsi que l'absence de responsabilité - il ne pouvait blâmer personne, a commencé à écouter.

J'ai ensuite préparé une présentation pour l'équipe et expliqué le concept de contrôle de version. J'ai ensuite présenté quelques situations dans lesquelles SVN pourrait nous aider, développeurs. Les plus jeunes s’adonnent comme un canard à l’eau, les plus âgés moins, mais ils essaient et ne se plaignent pas de ceux qui l’utilisent.

Une autre réalisation majeure a été de mettre en place un système complet en interne: j'ai dirigé un projet qui a permis à l'entreprise d'économiser 120 000 £ par an en licences. J'ai passé environ deux mois de mon temps libre à écrire un nouveau système et à le présenter au responsable informatique pour lui expliquer les économies réalisées. Il m'a ensuite autorisé à le présenter à l'entreprise et m'a expliqué comment nous pouvions implémenter tout ce qui lui plaisait dans le système - ne plus être limité à des systèmes "prêts à l'emploi".

Quatre semaines plus tard, mon système était mis à l'essai dans 10 sites et six mois plus tard, il était en ligne. Un an plus tard, ils ont annulé le contrat avec une tierce partie, en ont supprimé toutes les traces du réseau et sont venus nous voir pour améliorer considérablement notre système interne.

Mon conseil pour vous:

• si vous vous souciez de la compagnie, montrez-la. Si les autres n'aiment pas votre approche, laissez-la vous en parler - il s'agit de compromis
• Adaptez les suggestions à la personne à qui vous parlez - les gestionnaires aiment savoir comment ils peuvent a) économiser de l'argent, b) blâmer les gens avec précision quand tout va mal, mais les développeurs aiment savoir comment ils peuvent a) gagner du temps, b) rester en place pour eux-mêmes, par exemple
• si vous êtes passionné par le changement (ce qui semble être le cas), montrez votre enthousiasme aux gens et ne vous découragez pas lorsqu'ils sont moins enthousiastes
• Ne parlez pas de faire des changements. Fais les. Quand vous commencez à produire un travail fantastique en moins de temps que les gars plus expérimentés, les gens vont commencer à demander "pourquoi?"

Ils ont dit qu'ils m'avaient embauché en raison de ma rigueur et de mon expérience malgré ma jeunesse (j'ai 25 ans) en tant que programmeur C / C ++.

Plus probablement parce que vous êtes moins cher.

Avez-vous déjà été dans une situation similaire

Oui.

quels conseils me donneriez-vous

Laisser.

Y a-t-il une manière subtile de changer les choses sans devenir ici le mouton noir?

Il peut y avoir. Introduisez des changements et montrez comment ils améliorent les choses pour tout le monde. Après l'avoir fait un certain nombre de fois, vous pouvez obtenir l'appréciation de ceux qui ne sont pas perdus.

Ou devrais-je simplement abandonner ma passion et mon énergie?

En aucune façon. Tu es jeune et tu dois profiter des opportunités. Ne perdez pas des années "quelque part". Examinez ce poste et voyez s'il vous procurera une expérience précieuse pour faire avancer votre carrière. Si vous voyez des opportunités, explorez-les. S'il n'y en a pas et que c'est juste un "travail", sortez. La pratique montre que ceux qui ont perdu leur passion (ou ne l’ont jamais eu) ne peuvent pas la reprendre. Recherchez une équipe de passionnés et rejoignez-les.

Diriger par l'exemple . Petit à petit changement à la fois. Arrêtez un collègue et faites une démonstration pour eux. S'ils ne l'obtiennent pas, n'hésitez pas à réessayer une autre fois.

Cela prendra du temps. Il suffit de ne pas éloigner les gens de leur zone de confort trop rapidement.

Triste mais c'est pourquoi votre ici et ils ne sont pas.

Par exemple. Configurez le contrôle de version localement et montrez-leur comment il peut vous aider. Ensuite, donnez-leur des ressources (lecture simple) qui peuvent vous aider.

Une autre chose à propos des outils . Parfois, vous devez dépenser votre propre argent pour acheter de meilleurs outils. Je sais que ce n'est pas «chose faite», mais lorsque je discute avec d'autres métiers, je trouve que de nombreux «vrais» ingénieurs créent / achètent leurs propres outils pour mieux faire leur travail. Pour ma part, j'ai toujours fait cela, et je peux voir que je me sauve de l'atrophie des compétences.

Je suis un vieil homme (51 ans) et j'ai eu le même problème avec tous les emplois que j'ai jamais occupés. Peut-être que cela vient simplement d'être toujours le type le plus intelligent de la salle! :-) Sérieusement, quand vous savez comment le faire correctement et qu’ils ne le font pas, vous pensez souvent: "Hé, je vais montrer à tout le monde cette technique nouvelle et améliorée et ils seront tous impressionnés et voudront intervenir. à l'utiliser. " Mais dans la vraie vie, dans 90% des cas, vous montrez aux gens une meilleure façon de faire, et ils inventent une longue liste d'excuses pour expliquer pourquoi leur façon de faire est meilleure. Lorsque vous montrez que leurs raisons ne sont pas valables, ils vous présentent de nouvelles raisons, même plus claires. J'ai eu beaucoup de fois que je

Même si vous êtes vraiment un génie, vous devez accepter le fait que personne ne sait que vous êtes un génie avant de le prouver. Je pense à Kris, un de mes amis qui a commencé un nouvel emploi après 10 ans passés dans une entreprise. Peu de temps après son entrée en fonction, il était à une réunion au cours de laquelle ils discutaient d'un problème technique et il a commencé à proposer sa solution suggérée. Puis quelqu'un d'autre l'interrompit et dit: "Oui, merci. Bob, qu'en penses-tu?" Au début, il était agacé: il connaissait la bonne réponse, mais personne ne s'en souciait! Au lieu de cela, ils sont partis avec l'opinion de quelqu'un qui en savait beaucoup moins que lui. Mais ensuite, il a réalisé que, dans mon ancien travail, j'avais acquis une réputation de personne qui savait de quoi il parlait, alors quand j'ai parlé, les gens ont écouté. Ici, je n'ai pas encore de réputation, donc personne ne se soucie de ce que je pense.

Cela fait deux ans que je suis à mon poste actuel et ce n’est que depuis quelques mois que mon opinion commence à prendre tout son poids. Tu dois être patient.

D'un autre côté, les nouvelles personnes ont souvent des millions d'améliorations à suggérer, ce qui n'est vraiment pas pratique, car elles ne connaissent pas encore suffisamment l'organisation et ne savent donc pas pourquoi les choses se passent comme elles sont. Parfois, les gens continuent à faire la même chose pendant 20 ans parce que c'est comme ça que ça a toujours été fait et personne n'a jamais pensé à chercher une meilleure façon; mais parfois, les gens continuent à faire quelque chose de la même manière pendant 20 ans, car l'expérience montre que c'est un bon moyen de le faire et chaque fois qu'ils essaient quelque chose de différent, c'est un désastre. Alors ne soyez pas trop rapide pour conclure que tous ces gens sont des idiots. Découvrez pourquoi ils le font à l'ancienne avant de présenter votre nouvelle suggestion géniale. J'ai eu beaucoup de fois dans ma vie quand je

Trouvez des alliés qui veulent aussi améliorer l'entreprise.

Il y a quelque chose à dire pour sauver maintenant et les laisser pourrir. Toutefois, votre CV aura l’air superbe si vous parvenez à défendre avec succès le contrôle de version et d’autres améliorations.

Utilisez le test Joel lors de vos futures interviews. N'oubliez pas que vous interviewez également la société.

Mon premier conseil est d’essayer de ne pas trop changer trop tôt. D'abord, obtenez la réputation d'un bon développeur fiable, capable de faire avancer les choses. En ce moment, en tant que débutant, tout ce que vous suggérez est suspect; ils ne vous connaissent pas et ne vous respectent pas encore. Obtenez ce respect comme votre première étape. Ensuite, il est temps de commencer à introduire des changements.

Choisissez votre terre soigneusement. Commencez avec le contrôle de version, pas avec les nouvelles technologies. Parce que c'est vraiment le changement le plus important. Vous pouvez même le faire simplement avec votre code et vous assurer ensuite que lorsque vous devez revenir à une version précédente ou à un autre outil pour savoir ce qui a changé, vous laissez savoir aux gens à quel point il était facile de converser de manière informelle.

Utilisez vos connaissances les plus récentes pour être la personne qui brille, puis les gens commenceront à vous demander comment vous y prenez. Lorsque les ordinateurs sont arrivés sur le lieu de travail, j'ai travaillé pour une agence d'audit du gouvernement. Les seniors étaient tous très opposés à l’achat de leur propre ordinateur (car c’était du travail pour les secrétaires). Les juniors ont saisi tous les premiers ordinateurs et ont commencé à faire des choses qu'ils ne pouvaient pas faire avec Lotus 1-2-3 et Harvard Graphics et, tout à coup, les personnes plus âgées étaient intéressées parce qu'elles attiraient l'attention de très hauts responsables.

Changer de culture organisationnelle n'est pas un problème technique, c'est un problème politique. Faites des lectures sur la gestion de la politique de bureau. Vous allez avoir besoin d'un soutien politique de haut niveau.

J'ai rencontré une situation similaire dans mon travail actuel. J'ai été embauché dès la fin de mes études supérieures pour travailler dans une équipe composée en majorité d'ingénieurs ayant passé 15 ans ici. Faire des changements n’était pas facile (je continue de faire pression pour que certaines choses soient faites), mais c’est possible.

Par exemple, mon équipe maintenait, mettait à jour et utilisait un utilitaire de test DOS 16 bits. L'utilitaire était une douleur royale à mettre à jour, car l'application repoussait les limites de l'éditeur de liens 16 bits à un point tel que, si vous ajoutiez du code, vous deviez supprimer quelque chose d'autre pour qu'il s'adapte. Lorsqu'on leur a demandé pourquoi nous perdions tant de temps et d'énergie avec du code 16 bits, leur réponse a été "parce que nous devons l'exécuter sous DOS afin de pouvoir l'exécuter à partir d'un lecteur flash amorçable". J'ai essayé de les convaincre de porter l'utilitaire sous Linux 32 bits, mais la direction ne voulait pas investir le temps qu'il fallait pour le faire (nous avions déjà trop de travail à faire en l'état). Donc, je suis allé de l'avant et ai porté l'utilitaire dans mon temps d'indisponibilité (15 minutes ici et là au déjeuner, le week-end ou pendant que j'attendais un autre code pour compiler). Au cours de quelques mois, J'avais l'utilitaire complètement porté, amélioré avec toutes sortes de choses que l'application 16 bits d'origine ne pouvait pas gérer, et le démarrage à partir d'un lecteur flash Linux. Les gens ont remarqué quand j'ai commencé à l'utiliser et commentaient comment je pouvais faire les choses plus rapidement et comment mon utilitaire générait une meilleure sortie de débogage. Bientôt, la direction en a entendu parler. Une fois qu'ils ont constaté les avantages (et surtout que le travail était déjà fait), ils ne se sont plus opposés à cette idée.

La leçon que j'ai tirée de cette histoire est la suivante: si vous pensez pouvoir améliorer quelque chose, parlez-en à votre responsable. S'ils ne veulent pas dépenser les ressources, faites-le vous-même et montrez- leur que votre idée est valide et utile. Il est beaucoup plus facile de refuser une idée proposée par quelqu'un que quelque chose que vous voyez devant vous et qui a une valeur évidente.

Une fois que votre équipe / responsable mettra en œuvre votre idée et commencera à en voir les avantages, ils seront beaucoup plus susceptibles d’écouter vos idées à l’avenir. J’ai utilisé le "credo de rue" que j’ai gagné grâce à ma réécriture d’outil de test pour convaincre mon équipe que nous devions abandonner notre système de contrôle de version archaïque actuel (qui restera anonyme pour éviter toute gêne) et migrer vers Subversion. Je me suis porté volontaire pour diriger les efforts d'installation et de migration afin de veiller à ce que la direction l'approuve.

C'est une chose "une étape à la fois". Il y a probablement une tonne de choses que vous voudriez changer, mais choisissez quelque chose de petit (ish) pour commencer. Démontrez la qualité de vos idées de manière à ce que votre équipe et votre responsable ne puissent dire non. Tout comme votre compte stackoverflow, plus vous avez de bonnes idées, meilleure sera votre réputation et plus il sera facile pour vos idées d'être acceptées.

Décidément, commencez à utiliser les outils que vous souhaiteriez posséder localement (là où vous le pouvez - certaines entreprises semblent également contrôler ce que vous pouvez installer sur votre boîte avec un poing étrangement serré). Configurez votre système de contrôle de version préféré et commencez à l’utiliser. Dans tous les codes que vous touchez, effectuez de petites modifications qui rendent le code plus propre, en particulier lorsque vous écrivez un nouveau code. S'ils vous ont engagé pour votre rigueur et votre expérience, cela signifie qu'ils vous respectent déjà.

J'ai récemment lu Hiring Ren et Stimpy et j'ai découvert que l'exemple de Stimpy était un défi de taille. Si vous suivez son exemple, vous finirez par demander (gentiment) toutes sortes de points de vue à vos collègues, ce qui vous permettra de savoir qu'un développeur sans passion ne le fera pas. Vous passerez tout votre temps libre à trouver des moyens d'apporter des améliorations. Si l'entreprise considère que votre travail est précieux, vous deviendrez inestimable. S'ils ne le font pas, vous voudrez probablement être à la recherche d'un emploi.

Beaucoup de personnes ont répondu par des suggestions pour se concentrer sur une petite chose à la fois, et plusieurs ont suggéré le contrôle de version. Je vais aller un peu plus loin: créez des référentiels sur votre ordinateur de bureau et travaillez à partir de ces référentiels. Mettez-les à jour régulièrement à partir du référentiel principal utilisé par la société. Quand (pas si) il y a une crise parce que quelqu'un a endommagé le maître, dites-leur que vous pouvez couper une nouvelle copie de votre référentiel personnel.

Cependant, ne mettez en aucun cas le code de la société sur une machine que vous possédez personnellement ou emportez chez vous . Parce qu'alors, vous constaterez peut-être que, plutôt que d'être un héros, vous êtes du mauvais côté du bureau de la part d'un avocat (au mieux) ou de l'application de la loi (au pire).

Venant d'un autre développeur junior ... avez-vous de grandes compétences relationnelles? Avez-vous un excellent sens de la retenue et une compréhension du moment opportun pour proposer une idée et comment le vendre au mieux? Même si vous le faites, vous risquez toujours d'être "ce type" pour avoir dit aux autres comment faire leur travail sans prouver votre valeur.

C’est ainsi que j’ai TOUJOURS bâti ma crédibilité en tant que développeur junior: j’identifie un gaspillage de kink / kludge / time. Ensuite, je le répare en l’automatisant (fichiers de commandes, scripts PowerShell, programme simple, nouveau logiciel gratuit, peu importe le week-end) sans déranger personne. Je m'assure que cela fait partie de mon auto-apprentissage technique continu afin que je puisse le considérer comme "un surcroît d'heures pour m'apprendre une nouvelle chose ET aider l'entreprise".

Si ma solution est particulièrement chouette, je la partage et dis: "Hé les gars, j'ai créé cet outil génial, il automatise XY et Z et effectue cette autre opération rapidement." Gardez votre nom dessus. Répéter. Problème de crédibilité résolu en quelques mois si vous êtes dans un pourcentage élevé d'interprètes de votre niveau, et les personnes au dessus de vous seront plus ouverts à vos suggestions si vous êtes prêt à expliquer pourquoi votre idée est bonne et comment elle peut résoudre leurs problèmes.

Récemment, j'ai pu proposer de nouvelles idées à la haute direction qui ont été acceptées, principalement parce que j'ai pris le temps d'expliquer mon raisonnement, d'écouter leurs réactions et d'avoir la crédibilité de mes travaux antérieurs.

ADDENDA: Si votre responsable remet en question votre comportement ... ne faites pas ce genre de chose à moins qu'il ne sente que votre performance reste au moins "top 25%", c'est-à-dire assurez-vous que votre patron est content de vous avant de commencer à essayer toutes sortes de choses de solutions intelligentes qui vous poussent plus haut dans ce top% ou il va penser que vous perdez du temps. Si vous lancez de nouveaux utilitaires et solutions tout en obtenant un retour positif sur les performances, mais il insiste toujours pour vous microgérer, vous risquez de rencontrer un problème qui dépasse le cadre de cette rubrique.

Se fondre dans

Comme vous l'avez dit, vous ne voulez pas être le mouton noir. Cependant, puisque vous (comme moi) souhaitez ajouter un changement utile:

Ajouter de la valeur en arrière-plan.

Configurez cronjobs pour vérifier le code des personnes dans svn / hg / git .. Créez vos propres outils, à votre propre rythme, qui peuvent manifestement améliorer les efforts de développement. En particulier, vous souhaitez apporter des améliorations à l'entreprise afin que vous puissiez montrer vos personnes âgées dans votre propre box. Et voici pourquoi:

facteur wow

Si vous pouvez dire "Hey Alice, vous savez comment Bob vient de casser le build? Je peux annuler son édition, et le build fonctionne à nouveau". Et quand votre senior dira holy shit, peut-être que vous y passerez suffisamment de passion pour qu’ils adoptent ou, du moins, encouragent vos nouvelles pratiques.

Voici mon conseil.

J'étais dans une situation similaire, je devrais d'abord dire, mon entreprise est assez petite avec 6 développeurs. Je suis le genre de programmeur qui aime utiliser les nouvelles technologies, les nouveaux outils et tout ce qui facilitera mon travail et produira un logiciel de meilleure qualité. .

À mes débuts, nous utilisions Visual Studio 2005, alors que VS2008 n’était plus disponible depuis longtemps, mais il n’était pas facile de demander à mon patron de mettre la mise à niveau à la place de la mise à niveau. un "ce serait bien si nous pouvions faire cela", mais avant de le présenter à mon patron, je m'assurerais que les autres développeurs seraient bons sur l'idée, car ce sont eux qui l'utilisent et qui ont un groupe de personnes dans faveur ressemblerait moins à une décision d’une seule personne.

Je pense que, au lieu de simplement présenter l'idée à votre patron, évoquez peut-être lentement tous les changements possibles, car si vous proposez des idées qui vont améliorer la société, cela signifie également que vous vous souciez de votre travail et de votre planification. faire une maison là-bas.

Cela dépendra également de l’environnement de travail dans lequel vous vous trouvez et de la personnalité de votre patron, s’ils sont décontractés et vous traitent comme un membre de la famille et vous conseillent, puis suggérez-le, mais s’ils vous traitent comme un numéro, je ferais très attention à la vous vous en approchez.

Cela pourrait être une opportunité unique: changer le mode de fonctionnement d'une entreprise à 25 ans. S'ils résistent bien et font preuve d'animosité tout le temps, ce n'est pas l'endroit pour vous.

N'oubliez pas que votre entretien était un processus à double sens. Vous auriez pu sentir à quel point ils étaient archaïques et résistants au changement.

Ps, j'ai aussi 25 ans et je sais ce que vous ressentez. Vous êtes probablement beaucoup plus désireux d'apprendre et d'essayer de nouvelles choses que vos collègues. Quoi qu'il en soit, je dois revenir à ce travail .NET4 que je vous présente;)

Lire Faire les choses quand on n'est qu'un grunt par Joel Spolsky.

... Parfois, vous n'avez pas le pouvoir de créer des changements dans votre organisation par le biais d'une décision exécutive. Évidemment, si vous êtes juste un grogneur au bas du totem, vous ne pouvez pas ordonner aux gens de créer des calendriers ou des bases de données de bogues. Et en fait, même si vous êtes un responsable, vous avez probablement découvert que la gestion des développeurs ressemble beaucoup à la gestion de chats, mais pas aussi amusante. Dire simplement "fais-le ainsi" ne le fait pas.

Cela peut être frustrant lorsque vous travaillez dans une organisation dont le résultat est faible sur The Joel Test . Quelle que soit la qualité de votre code, vos collègues écrivent un code si mauvais que vous êtes gêné d'être associé au projet. Ou encore, la direction prend de mauvaises décisions quant au code à écrire. Vous devez donc gaspiller votre talent pour déboguer la version AS / 400 d'un jeu de planification de la retraite destiné aux enfants.

... faire face à une mauvaise équipe peut être exaspérant. Mais il existe des stratégies pour améliorer votre équipe à partir du bas, et j'aimerais en partager quelques-unes ...

Travailler avec la direction; ne "va pas voyous". Travaillez dans le cadre du processus et mettez les choses dans des termes que les gens comprendront, par exemple, "la mise en œuvre de svn nous prendra de la place sur un serveur, deux jours pour sa configuration, et nous devrons le sauvegarder, mais nous gagnerons x, y, z , ce qui peut nous faire économiser beaucoup d’argent. "

Quitter. Il y a beaucoup d'emplois là-bas. Ce n'est pas à vous de réparer une entreprise quelconque qui vous a embauché. Ils aiment ce qu'ils sont, sinon ils embaucheraient un nouveau CTO ou quelque chose du genre.