La nouvelle de Red Hat concernant l'acquisition de l'opinion publique par IBM est partagée. Beaucoup s'inquiètent à juste titre de l'avenir des produits Red Hat ouverts; cependant, au moins Mark Little, vice-président du développement chez Red Hat, est optimiste quant à l'avenir .
Dans l'une des discussions, un programmeur d'entreprise expérimenté, Hank , qui a commencé à programmer sous Commodore 64, a partagé une histoire sur la façon dont l'entreprise dans laquelle il travaillait à l'époque avait connu des changements similaires. Cette histoire sera proche de tous ceux dont le projet a déjà été absorbé ou clôturé. La traduction est publiée avec la permission de l'auteur.Au cours de ma vie, j'ai subi plusieurs fusions. Au début, la plupart des employés sont choqués - car ils n'avaient aucune idée de ce qui se passait derrière eux. Puis vient l'incrédulité que les concurrents d'hier, département après département, deviennent leurs collègues.
Après cela vient la prise de conscience que maintenant vous faites un travail qui se duplique. Prend en charge deux moteurs de transaction, prend en charge deux serveurs de certification, prend en charge deux ...
Au cours des deux premiers mois, presque rien ne changera - puisque la fusion elle-même n'a pas encore été réalisée, et probablement tous les contrats n'ont pas encore été signés - mais cette pensée restera fermement dans votre tête et vous rappellera régulièrement des douleurs douloureuses.
Vient ensuite un sentiment d'incertitude. Supposons que vous travaillez sur un moteur de transaction et que vous êtes sûr qu'il est meilleur que l'analogue des anciens concurrents - mais ce produit sera-t-il développé davantage? Certains de vos collègues se sont détendus à l'ennui - il se trouve qu'ils travaillent sur un projet pour lequel il n'existe pas de «double». Mais vos managers vous convainquent: ne vous inquiétez pas, rien n'arrivera à votre produit.
Pendant ce temps, les seigneurs commencent à partir. Vous vous rassurez toujours: "Les seniors partent tout le temps". Oui, même si cela semble raisonnable, mais le fait demeure: beaucoup de seniors partent avec méfiance.
Environ six mois plus tard, de petites «émeutes» commencent à éclater. Le fait est que les gens veulent savoir exactement où ils se trouvent. Mais au final, peu de choses se produisent. De plus en plus de professionnels partent.
Un an plus tard, une commande vient de «leur» siège: nous migrerons vers leur plateforme. Mais nous n'avons pas à nous en préoccuper - leur plate-forme est bien meilleure, et les X, Y, Z, sur lesquels nous avons été tourmentés tout ce temps, ont déjà été fabriqués par eux.
Au cours de la prochaine année et demie après cet événement, vous écrirez ce que l'on pourrait appeler le code le plus ennuyeux de la Terre entière - un grand nombre de «connecteurs» qui devraient temporairement connecter les fonctionnalités de votre plateforme à l'une ou à l'autre. Tout cela repose "sur le vif", car toutes les API que vous devez utiliser sont internes, non documentées et pleines d'omissions. Vous devez donc visiter leur siège social pour discuter avec les développeurs du composant bridge. La première chose que vous remarquerez sera l'atmosphère régnante de la victoire. Oui, ils sont gagnants et vous êtes perdants. Votre produit sera éliminé et son développement se poursuivra.
Ici, vous rencontrerez également de nombreux visages familiers - ceux qui ont travaillé dans les départements RH et marketing de votre entreprise d'origine. Tous seront extrêmement intéressés à ce que vous transfériez les données des clients dès que possible. Vous verrez qu'ils maîtrisent les systèmes locaux, étudient de nouveaux outils pour eux-mêmes, planifient comment entrer en contact avec les clients, suivent un calendrier - et surveillent combien de clients ont déjà migré et combien reste à transférer.
Eh bien, un autre travail intéressant vous attend après vous. Le fait est que votre entreprise a utilisé le produit X pour stocker les données clients - cependant, ils y utilisent le produit Y. Veuillez donc écrire un outil pour exporter les données ... oh oui, et n'oubliez pas que pendant la première année, cela devrait être bidirectionnel - pour afin que X et Y soient synchronisés jusqu'à ce que la migration des données de tous les clients soit terminée.
Alors maintenant, pendant encore une année entière, vous travaillerez sur le prochain connecteur fragile, maintenant entre les deux API Web.
Bien sûr, ils mettront à jour leurs systèmes quand cela leur plaira - pour eux, tout se passe comme d'habitude dans l'entreprise, y compris la mise à jour des systèmes. Cependant, à chaque fois dans un tel cas, le connecteur se cassera et quelqu'un sera très en colère contre vous. Le processus de migration des données sera presque achevé dans environ trois ans. Ces mêmes RH et spécialistes du marketing qui ont été les plus heureux de vous aider dans la migration seront poliment invités à «sortir». L'étonnement et le refus de croire ce qui se passe sur leurs visages vous bouleversera, mais au moins vous pouvez toujours rester ici, car vous devez toujours soutenir le projet, qui est maintenant devenu un héritage (même s'il est technologiquement toujours en avance - malgré le fait qu'il soit directement au-dessus personne ne travaille avec lui depuis environ trois ans).
Au lieu de travailler sur de nouvelles fonctionnalités intéressantes, toute l'année prochaine vous corrigerez des bugs, qui de temps en temps seront invités à corriger le plus conservateur de vos clients. Vous regarderez vos collègues disparaître un par un. Certains d'entre eux seront transférés au siège pour travailler sur le projet gagnant - mais il n'y en aura pas autant que vous ne le pensez.
À la fin, le dernier client actif passera à un autre produit ou ira à un autre fournisseur, et votre projet passera à un mode de support hérité spécial. Il est toujours là, mais vit maintenant quelque part au fond des entrailles du quartier général sur un serveur lointain et lointain, qui se trouve dans un couloir à peine perceptible dans le placard caché des yeux des non-initiés. Le budget du projet est maintenant d'environ 16 heures par an - il est conçu exactement pour effectuer occasionnellement un scan CVE.
Enfin, cette étape s'achèvera. À ce stade, presque tout ce qui restait de l'entreprise d'origine disparaîtra tout simplement.