Question

J'ai récemment quitté un grand hôpital universitaire pour un établissement beaucoup plus petit en raison de l'augmentation de salaire et du dynamisme de sa carrière. Bien sûr, ces deux choses seraient généralement quelque chose d’excitant et un grand accomplissement (surtout pour quelqu'un de mon âge), mais je me suis retrouvé en train de faire la moue à l’intérieur alors que je me rendais au travail tous les matins, et voici pourquoi. Le nouveau groupe auquel j'ai adhéré est terriblement en retard en ce qui concerne les pratiques de codage, les technologies les plus récentes (oui, ils utilisent toujours le format classique .ASP) et les logiciels, ce qui me laisse derrière moi avec VS2008, .NET 3.5 et SQL Server. / BIDS 2008 pour utiliser les anciennes reliques SQL 2000 / VS 6.0.

Au début, ce n’était pas si mal, j’imaginais que toutes les entreprises n’étaient pas à la pointe de la technologie et n’attendaient que la bonne étincelle pour les envoyer dans le sens du changement et de l’amélioration - non, j'ai commencé à suggérer (à un professionnel). et de manière non condescendante) de nouveaux outils et des avantages qu’ils auraient pour notre entreprise, tant du côté client que du client, mais ils (comme dans l’équipe dont je fais partie) me regardaient comme si j’étais un étranger et m’ont donné pourquoi nous aurions besoin de ce matériel, même après que j’ai plaidé ma cause.

Cela m’a amené à penser que j’allais peut-être différemment et espérais que des développeurs / ingénieurs plus expérimentés partageraient leurs expériences plus jeunes et plus jeunes. Je sais que les temps ont changé, mais j'estime que cela serait néanmoins utile et que tout conseil serait très apprécié!

Merci à tous!

Était-ce utile?

La solution

Il est inutile d’adopter de nouvelles technologies si elles ne résolvent pas les problèmes actuels d’une manière plus simple et plus efficace que les technologies précédentes. (Y compris la courbe d'apprentissage.).

Il se peut que votre université dispose d’une énorme quantité de code hérité, qui repose sur ces anciennes technologies. Passer à une date ultérieure peut être un processus extrêmement coûteux et fastidieux qu'il est assez difficile de justifier.

Pour introduire de nouvelles technologies, l’architecture doit être modifiée progressivement, comme si l’université dans son ensemble décidait de migrer vers SharePoint ou autre, ou dans un nouveau projet permettant de démontrer les avantages des nouvelles technologies, et laissez les développeurs existants avoir le temps de les comprendre.

Ce qu'il faut garder à l'esprit avec tout cela, c'est que la plupart des gens n'aiment pas le changement et qu'en changeant la technologie existante, vous allez marcher sur les pieds des gens. Par exemple, les experts de systèmes ou technologies particuliers.

Autres conseils

Tout d’abord, comprenez que suggérer des changements majeurs lorsque vous êtes nouveau est presque toujours une mauvaise idée. Vous leur demandez d’abord de vous respecter par le biais de la performance, puis vous proposez des changements. Ensuite, vous pouvez également comprendre le coût pour l’entreprise d’apporter ces changements, raison pour laquelle ils ne l’ont pas encore fait.

S'ils vous ont dit qu'ils utilisaient ces outils avant de vous y rendre, vous devez accepter le fait que l'environnement dans lequel vous choisissez de vivre et de travailler pendant un certain temps avant de soulever à nouveau le sujet. S'ils vous ont dit qu'ils vous voulaient parce que vous avez les compétences qui leur manquent pour aller de l'avant, alors la personne à qui vous devez parler est le responsable du recrutement, pas l'équipe. Notez que cela ne créera pas d'amis pour vous dans l'équipe.

Ma principale suggestion est de commencer à lire un peu sur la politique de bureau. Construisez des alliances avant de réessayer. Il se peut que d’autres personnes souhaitent également travailler avec des éléments plus récents. Peut-être que le dba n'aime pas non plus être coincé avec des compétences de dix ans.

En ce qui concerne le passage de SQL Server 2000 à 2008, vous pouvez souligner que 2000 ne sera plus pris en charge et que, lorsque SQL Server 2010 est disponible, il n’existe plus de chemin de mise à niveau direct. C’est ce qui nous a finalement permis de commencer la mise à niveau vers 2008. Il est préférable de convertir avant cela. Recherchez sur le site Web de Microsoft les détails exacts de ce qui se passe quand.

Franchement, vous n'avez pas de chance. S'ils ne voient pas le besoin d'apprendre, ils ne le feront jamais seuls. Vous allez devoir travailler pour obtenir les nouveaux éléments demandés au bureau et probablement trouver un moyen de payer une formation pour eux. Ou convaincre leurs patrons de les licencier.

Dans de nombreux environnements non technologiques, les gens s’installent dans l’ornière et continuent à utiliser les mêmes outils, même s’ils sont périmés. Vu cent fois.

Il y a beaucoup de variables inconnues ici, tellement qu'il est difficile de donner des conseils. J'aimerais savoir:

  1. gérez-vous cette équipe, ou simplement un codeur?
  2. Votre responsable du recrutement vous a-t-il confié une mission spécifique consistant à faire évoluer l'équipe vers de nouvelles technologies?
  3. Quelle est l'attitude de la haute direction en ce qui concerne la mise à niveau des technologies utilisées?

Si vous êtes responsable de cette équipe, c'est à vous de définir l'ordre du jour, de susciter l'enthousiasme de chacun pour la nouvelle direction et, éventuellement, de renvoyer quelqu'un pour montrer aux autres que vous êtes un homme d'affaire (de préférence celui qui gémit le plus fort ou traîne les pieds le plus évidemment).

Si vous êtes juste un singe de code, ou si la haute direction n’a pas de problème avec la façon dont les choses fonctionnent maintenant, commencez à envoyer votre CV, car vous n'êtes pas en mesure de changer quoi que ce soit. Et la prochaine fois que vous occuperez un emploi, demandez des précisions sur les technologies qu’ils utilisent.

Cela se produit tout le temps.

Vous auriez dû demander quels outils ils utilisaient et comment ils fonctionnaient avant d’accepter de les rejoindre. Je voudrais également signaler quelque chose comme "Si je découvre que tu as inventé ça pour m'obliger à m'inscrire, je ne resterai pas longtemps.".

Vous allez trouver des personnes qui résistent fortement au changement et vous devez connaître les raisons pour lesquelles les gens refusent le changement afin d'essayer de le changer.

Tout d’abord, les utilisateurs évitent généralement les risques (à quelques exceptions près: les utilisateurs précoces). Autrement dit, les gens évitent les risques et tout changement est un risque.

Deuxièmement, dans votre situation, les gens ont tendance à craindre le changement. Regardez cela comme ceci: un développeur de votre équipe va penser "si nous passons à la technologie xxx, comment cela affectera-t-il ma carrière?" Comment cela affectera-t-il mes chances d'obtenir une promotion ou même d'être viré? Ils ne connaissent pas la nouvelle technologie, ne veulent pas devenir obsolètes ou perdre leur statut d’experts ou quoi que ce soit de la manière habituelle.

Enfin, il est difficile d’apprendre et de comprendre tout ce qui est nouveau, en particulier lorsque vous travaillez dans le vieil appareil depuis longtemps. Cela prend du temps et vous fait sentir comme si vous étiez un idiot. Dans les équipes les plus anciennes (et je parle littéralement de personnes plus âgées), cela augmente également la peur d'être remplacé par un jeune qui connaît déjà la technologie.

Si vous souhaitez vaincre la résistance, vous devez régler tous les problèmes.

Premièrement, la chose devra être progressive. Une étape à la fois, un produit à la fois. N'essayez pas de changer le processus complet pour toute l'entreprise. Au lieu de cela, proposez un projet de moindre envergure et appliquez-lui la nouvelle technologie. Présent est comme une opportunité et un test. Si cela n’est pas utile, nous ne l’utiliserons plus, mais essayons, le risque sera minime.

Ensuite rassurez les gens. Assurez-vous que tout le monde se sent apprécié et que l'entreprise ou vous-même faites davantage confiance aux longues années d'expérience dans le domaine qu'avec une technologie donnée. Écoutez les gens, respectez leurs opinions et faites-leur sentir que vous vous souciez de ce qu'ils pensent. Bien sûr, cela ne devrait pas être un acte, vous devriez vraiment ressentir cela. Les grandes équipes se font confiance.

D'autre part, gérer le changement. Les jalons doivent être plus larges, vous devez prendre en compte le changement. Vous devez faire en sorte que l’équipe comprenne que vous comprenez que le changement est difficile et que le processus est long. Que personne ne soit jugé si la nouvelle chose prend plus de temps que l'ancienne, que des échecs sont à prévoir et que personne ne sera renvoyé à cause de cela.

En fin de compte, si vous voulez du changement, vous devez rassurer les gens et leur faire comprendre que le changement n’est qu’un test. Si cela fonctionne, il convient à tout le monde, sinon, c’est OK. Bien entendu, l'entreprise doit également comprendre cela. Pour les gestionnaires, cela signifie leur présenter un rapport risque / bénéfice clair, énoncer la vérité et leur dire POURQUOI un changement s'impose.

Lorsque vous parlez à la direction, n'oubliez pas de garder à l'esprit que la concurrence est toujours présente. Vous devez évoluer ou plus correctement être en constante évolution. Même si le produit est le même en termes de fonctionnalité et le plus triste qui puisse paraître, d’un point de vue marketing, vous dites que vous utilisez la dernière technologie xxx avec la technique de développement de lates yyy est une excellente solution. Les clients ne sont pas stupides, mais ils ne sont pas non plus familiarisés avec l’informatique et sont donc facilement impressionnés par les mots fuzz, de sorte que la concurrence peut les voler sans vraiment avoir un meilleur produit, juste un "plus récent". un.

Encore une chose: vous aurez peut-être intérêt à leur parler de la " Who déplacé mon fromage? histoire " qui tourne autour du changement et de la façon dont le marché évolue autour du changement.

Le changement est une chose fondamentale dans la vie de chacun, tant personnel que professionnel, et doit toujours être pris en compte. Chaque fois que quelqu'un dit: "Changer maintenant, c'est trop risqué". ou "nous ne pouvons pas nous permettre de changer" il faut vraiment penser que c’est grave… l’image est-elle vue à long terme ou tout ce que nous parlons d’un scénario à court terme? Parce que si c’est le dernier cas, nous serons prêts à le savoir, mais foutus à long terme ... quelque chose comme donner toujours un prêt à tout le monde pour acheter une maison parce que les maisons augmentent TOUJOURS leur valeur ... ou le font-elles?. ..

S'agit-il uniquement des outils périmés? Ou le code qu'ils produisent est-il inférieur? Si c'est le code, votre meilleur choix est la révision du code de groupe. S'il ne s'agit que d'outils, créez simplement des articles et / ou des documents répertoriant les fonctionnalités qui leur manquent et indiquez les avantages pour le groupe.

Si l’équipe est coincée dans le passé, vous ne pourrez peut-être rien faire de plus. Certains développeurs ne voient pas les avantages des technologies / méthodes plus récentes (et dans certains cas, ils pourraient avoir raison) ou ont peur du changement. Je dirais que vous apprendrez tout ce que vous pouvez en apprendre - vous pouvez acquérir beaucoup de compétences interpersonnelles, de gestion de projet, politiques et autres. Consacrez une partie de votre temps à suivre la technologie actuelle et gardez l'oeil ouvert pour avoir la chance de passer à autre chose. Pour l'instant, apprendre ce qui peut. De nombreux développeurs se concentrent sur la technologie et passent à côté des compétences importantes dont ils auront réellement besoin plus tard dans leur carrière.

Nous avons tous des biais sur notre plate-forme et sur la technologie. Lorsqu'une nouvelle personne se joint à une équipe, elle veut tout changer, mais l'équipe essaie souvent de rejeter le changement, même si les motivations sont les mêmes. bien.

Malheureusement, le " Vous utilisez Java? Ick! Nous devons porter tout cela en C # immédiatement! & Quot; Les types ont rendu les gens sceptiques à juste titre sur le nouveau type suggérant beaucoup de nouvelles choses.

Une suggestion que je pourrais faire en suggérant un nouveau processus ou une nouvelle technologie est de le définir en fonction d’un problème réel auquel ils sont confrontés. La technologie n'est pas la solution, c'est la réponse. Trouvez le problème, puis proposez peut-être d’enseigner un savoir-faire technologique en mettant l’accent sur les aspects qui résonneront avec l’équipe à la lumière de leurs points douloureux. Démontrez la valeur et laissez-les se déplacer par eux-mêmes plutôt que d'adopter une approche de vente.

Comment avez-vous présenté votre cas? Professionnel et non condescendant, c'est bien, mais ce n'est que le début.

Lorsque vous essayez de persuader quelqu'un de changer, insistez sur ce qu'il peut en retirer. Déterminez ce qu'ils veulent et montrez-leur comment la nouvelle technologie peut aider.

La direction veut plus de travail et des économies de dollars. Les gestionnaires se moquent de vouloir des choses plus récentes et meilleures. Essayez de trouver des cas et des études montrant que le fait d’utiliser les dernières informations en date économise X% en argent et en travail. Recherchez ou créez de bonnes estimations de ce que cela va coûter (non seulement en outils, mais en formation, en pistes de développement double, etc.). Rappelez-vous que les vieux trucs resteront là et que vous devez avoir un plan pour en rendre compte.

Il faut que vos collègues sachent à quel point c'est bon pour eux et qu'ils ne vont pas en souffrir. Ils ont beaucoup investi dans cela. Ils savent ce qu'ils font et ils connaissent la base de code. Passez à un système plus récent, et ils ne sauront pas ce qu'ils font, ils ne connaîtront pas la base de code, ils seront incompétents au début et auront peut-être peur de devenir des consommables. C’est beaucoup demander à une personne moyenne et peut-être trop à demander à certaines personnes (comme le gars qui est à trois ans de la retraite).

Découvrez ce qui ne leur plaît pas dans le système actuel et montrez-leur comment le nouveau logiciel peut vous aider. Discutez de la formation et expliquez au moins à quel point il sera facile de convertir. Si vous pouvez leur montrer comment faire ce qu'ils font habituellement dans le nouveau système, sans vous soucier de tirer parti des nouvelles fonctionnalités, cela vous aidera beaucoup. Insistez sur le fait que leur connaissance ne se limite pas à la base de code, mais également à l’entreprise et à ses exigences.

Et ne vous attendez pas à vider les documents hérités. Vous ne pourrez introduire que de nouveaux outils lors du démarrage d'un projet. S'il est incompatible avec les systèmes existants, il ne fonctionnera tout simplement pas.

C'est difficile, bien sûr, et vous feriez mieux de rester quelques années et d'aller dans un magasin plus moderne.

Comme mentionné précédemment, oubliez les projets hérités s'ils fonctionnent correctement. Vous ne pourrez persuader personne de les réécrire. Une meilleure solution pourrait être d’attendre l’arrivée d’un nouveau projet et de suggérer l’utilisation de nouveaux outils. Expliquez comment ces nouveaux outils vont améliorer l'efficacité ou autre chose, mais ne discutez pas avec le fait que vous ne devriez les utiliser que parce qu'ils sont nouveaux. Cela pourrait être plus facile avec un petit projet que la direction jugera moins important.

Une fois qu'un projet est en marche, vous avez gagné la moitié de la bataille et pouvez l'utiliser comme exemple des avantages des nouvelles technologies pour la gestion.

Bonne chance quand même.

Lorsque le nouveau membre arrive et commence à prêcher - même de manière tout à fait légitime, positive et utile - à propos de nouveaux outils, il peut souvent créer une relation "vous-même contre eux". atmosphère.

Cela ne devrait pas être ainsi, mais en admettant que ces nouveaux outils étonnants leur feront économiser beaucoup de travail, c'est en quelque sorte un aveu implicite qu'ils ont perdu beaucoup de temps. Même si cela leur convient sur le plan personnel (mis à part les contraintes extérieures, la plupart des gens veulent juste faire du bon travail!), Ils se méfieront de la façon dont cela pourrait ressembler à leurs supérieurs si le "nouveau type" en sait beaucoup plus qu'eux.

Idée: amenez-les à participer à certains événements de développeurs locaux avec vous. Alors, c’est plutôt comme si vous découvriez ensemble de nouvelles choses excitantes et moins comme un "mes outils sont meilleurs que les vôtres". chose.

Avant tout, vous devez mettre de la graisse dans les coudes et des projets de manière à renforcer votre crédibilité sur votre nouveau lieu de travail.

De plus, j’ai toujours pensé que SQL Server 2000 est fantastique. SQL 2K5 et 2K8 sont de belles mises à jour, mais 2000 est vraiment solide. ce n'est pas comme s'ils fonctionnaient sous Access.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top