As notícias da Red Hat sobre a aquisição da opinião pública pela IBM são compartilhadas. Muitos estão preocupados com o futuro dos produtos abertos da Red Hat; no entanto, pelo menos Mark Little, vice-presidente de desenvolvimento da Red Hat, está otimista com o futuro .
Em uma das discussões, um experiente programador corporativo, Hank , que começou a programar no Commodore 64, compartilhou uma história sobre como a empresa em que estava trabalhando naquele momento experimentou mudanças semelhantes. Esta história será próxima de todos aqueles cujo projeto já foi absorvido ou encerrado. A tradução é publicada com permissão do autor.Durante minha vida, passei por várias fusões. A princípio, a maioria dos funcionários fica chocada - porque não tinha ideia do que estava acontecendo atrás deles. Depois vem a descrença de que os concorrentes de ontem, departamento após departamento, se tornam seus colegas.
Depois disso, percebe-se que agora você está realizando um trabalho que se duplica. Suporte dois mecanismos de transação, suporte a dois servidores de certificação, suporte a dois ...
Nos primeiros meses, quase nada mudará - já que a fusão ainda não foi realizada e, provavelmente, nem todos os contratos foram assinados -, mas esse pensamento ficará firme em sua cabeça e lembrará regularmente de dores doloridas.
Então vem um sentimento de incerteza. Suponha que você esteja trabalhando em um mecanismo de transações e tenha certeza de que é melhor do que o analógico de antigos concorrentes - mas esse produto será desenvolvido ainda mais? Alguns de seus colegas se comportam de maneira descontraída e irritante - aconteceu que eles estão trabalhando em um projeto para o qual não existe um "duplo". Mas seus gerentes o convencem: não se preocupe, nada acontecerá com seu produto.
Enquanto isso, os senhores começam a sair. Você ainda se tranquiliza: "Os idosos saem o tempo todo". Sim, mesmo que isso pareça razoável, mas o fato permanece: muitos idosos estão saindo desconfiados.
Cerca de seis meses depois, pequenos tumultos começam a entrar em erupção. O fato é que as pessoas querem saber exatamente onde estão. Mas, no final, pouco está acontecendo. Mais profissionais estão saindo.
Um ano depois, um pedido é enviado da sede "da sua": migraremos para sua plataforma. Mas não precisamos nos preocupar com isso - a plataforma deles é muito melhor e o X, Y, Z, sobre o qual fomos atormentados todo esse tempo, já foi criado por eles.
No próximo ano e meio após esse evento, você escreverá o que poderia ser chamado de código mais chato de toda a Terra - um grande número de “conectores” que devem conectar temporariamente a funcionalidade da sua plataforma a um ou outro. Tudo isso depende do problema, pois todas as APIs que você precisa usar são internas, não documentadas e cheias de omissões. Então você precisa visitar a sede deles para conversar com os desenvolvedores sobre o componente da ponte. A primeira coisa que você nota será a atmosfera reinante da vitória. Sim, eles são vencedores e vocês são perdedores. Seu produto será eliminado e seu desenvolvimento continuará.
Aqui você também encontrará muitos rostos conhecidos - aqueles que já trabalharam nos departamentos de RH e de marketing da sua empresa. Todos eles estarão extremamente interessados em transferir os dados do cliente o mais rápido possível. Você verá que eles estão dominando os sistemas locais, estudando novas ferramentas para si mesmos, planejando como entrar em contato com os clientes, seguindo um cronograma - e monitorando quantos clientes já migraram e quanto resta a ser transferido.
Bem, outro trabalho interessante espera por você depois de você. O fato é que sua empresa usou o produto X para armazenar dados do cliente - no entanto, eles usam o produto Y. Portanto, escreva uma ferramenta para exportar dados ... ah sim, e não esqueça que durante o primeiro ano deve ser bidirecional - por para que X e Y sejam sincronizados até que a migração de dados de todos os clientes seja concluída.
Então, por mais um ano inteiro, você estará trabalhando no próximo conector frágil, agora entre as duas APIs da web.
Obviamente, eles atualizarão seus sistemas quando lhes agradar - para eles, tudo no negócio acontece como de costume, incluindo a atualização dos sistemas. No entanto, sempre que nesse caso, o conector se quebra e alguém fica muito zangado com você. O processo de migração de dados estará quase concluído em cerca de três anos. Os mesmos RH e profissionais de marketing que tiveram o maior prazer em ajudá-lo com a migração serão educadamente convidados a "sair". O espanto e a recusa em acreditar no que está acontecendo em seus rostos vão incomodá-lo, mas pelo menos você ainda pode ficar aqui, porque ainda precisa apoiar o projeto, que agora se tornou legado (mesmo que tecnologicamente ainda esteja à frente - apesar do fato de estar diretamente acima). ninguém trabalha com ele há cerca de três anos).
Em vez de trabalhar em novos recursos interessantes, no próximo ano você corrigirá bugs, que de tempos em tempos serão solicitados a corrigir os mais conservadores de seus clientes. Você verá seus colegas desaparecerem um a um. Alguns deles serão transferidos para a sede para trabalhar no projeto vencedor - mas não haverá tantos deles quanto você possa imaginar.
No final, o último cliente ativo passará para outro produto ou passará para outro fornecedor, e seu projeto passará para um modo de suporte legado especial. Ele ainda está aqui, mas agora mora em algum lugar nas entranhas da sede em um servidor distante e distante, que fica em um corredor quase imperceptível no armário, escondido dos olhos dos não iniciados. O orçamento do projeto agora é de cerca de 16 horas por ano - ele foi projetado exatamente para realizar ocasionalmente o CVE-scan.
Finalmente, esta etapa chegará ao fim. Nesse ponto, quase tudo o que restou da empresa original simplesmente desaparecerá.