Como você sabe, em 2018, o Google realizou a maior reformulação da interface do seu serviço de e-mail Gmail. Como sempre, nem todos ficaram satisfeitos com isso - e desta vez há razões bastante objetivas para a insatisfação com o serviço. Por que o carregamento do Gmail demorou tanto tempo e ações como excluir ou arquivar uma conversa podem levar de 4 a 6 segundos?
Alguns dias atrás, um
usuário do Hacker News fez uma pergunta semelhante - e ele recebeu uma resposta de um funcionário anônimo do Google que observou a cultura de desenvolvimento dentro da empresa e seus colegas.
Segundo ele, tudo isso acontece devido ao fato de o Google não prever multas por tais "erros".
Dentro dos muros da empresa, eles incentivam ativamente lançamentos - lançamentos públicos de algo. E o fato de que os produtos podem conter apenas metade dos recursos necessários, não funcionando, funcionando apenas no Chrome e assim por diante - isso não incomoda ninguém, porque seus criadores não correm esse risco. Essa é a norma.
O significado de tal ação é apenas uma coisa - no avanço da carreira, porque sem grandes lançamentos além de um certo nível, você não poderá ir. Portanto, acabamos com centenas de aplicativos de bate-papo desnecessários, infinitas reformulações e reinicializações - caso contrário, os indivíduos não poderão ser promovidos.
Quando a gerência da empresa tentou resolver o problema, emitindo um documento interno que, em vez de lançamentos, motiva a obtenção de "desembarques" bem-sucedidos (
aterrissagem , lançamentos bem-sucedidos) - tudo o que os funcionários mudaram em sua vida é
s / launch / landing / g em sua análise de desempenho.
Tomemos, por exemplo, o Allo messenger. Foram necessários dois anos para desenvolvê-lo, após o que a empresa decidiu suspender o desenvolvimento e congelar o projeto. Acontece que as pessoas encarregadas do mensageiro não sofreram ao mesmo tempo - pelo contrário, algumas delas foram promovidas.
Infelizmente, aparentemente, os problemas prementes dos usuários da empresa hoje não estão muito interessados:
Você sabe quantos bugs você precisa corrigir para conseguir um aumento? Infinitamente muitos. Não importa quantos bugs você conserte - nunca trará "contribuição" suficiente para aumentar, nunca. Mas basta executar apenas uma reformulação - mesmo que seja praticamente inútil - e a promoção está no seu bolso.
Naturalmente, dentro dos muros da própria empresa, há pessoas que alertam sobre a possibilidade disso e reclamam, colocam erros de desempenho nos rastreadores - isso é tudo o que é ignorado; a maioria dos trabalhadores acaba desistindo e parando de escrever sobre bugs, porque a resposta típica é "você não é nosso público-alvo".
E todos sabemos sobre esses problemas! Todos nós! Alguns desistem quando se trata deles; outros simplesmente começam a "otimizar" para cima - em vez de otimizar na direção do que é bom para o usuário ou para a empresa.
Em seus pensamentos, o desenvolvedor não está sozinho. Graham Wheeler compartilhou uma
história de sua vida no Google, confirmando sua posição.
Uma vez no Google, recebi uma avaliação de desempenho negativa. Decidi que a melhor maneira de gastar meu tempo seria refatorar o código que consegui para elevar o grau de cobertura do teste de 0% a 80%, corrigindo muitos erros ao longo do caminho. Como resultado, recebi uma crítica ruim sobre a análise de desempenho, e o autor do govnokoda original recebeu um aumento.
Histórias sobre problemas de gerenciamento de desenvolvimento no Google aparecem
regularmente na Web. A reação do usuário também não demora. Os clientes corporativos que usam o Google Apps estão
migrando para o
FastMail , cujo principal princípio é o email e nada mais.
É assim que somos e recebemos coisas como o novo Gmail. Que, por um lado, recebeu uma reformulação no espírito do Design de materiais, um modo offline e muitas outras pequenas melhorias transferidas para ele a partir da Caixa de entrada do Google, que terá uma vida útil prolongada no próximo ano. Por outro lado, ele realiza 358 solicitações para carregamento completo e downloads de 6,3 MB. Para comparação, o modo "antigo" da Visualização HTML no Gmail é de apenas 14 solicitações e 25,3 KB, o que permitiu o carregamento em 2 segundos.
Obviamente, essa prática se aplica não apenas ao Google, mas também a muitas outras grandes empresas. Observamos o princípio bem conhecido
"Você consegue o que mede" em ação.
Uma
história semelhante
foi contada pelo desenvolvedor Steve , que trabalhou na Apple no MacOS X Snow Leopard. Na maioria das vezes, Steve se comprometeu a corrigir bugs em todas as principais estruturas de sistemas operacionais - e, como resultado do lançamento, ele foi recusado por uma promoção devido ao fato de sua presença "não ser crítica em nenhum dos projetos".
A ironia aqui é que essa versão do sistema operacional, baseada na idéia de gerenciamento da empresa, deveria ser um lançamento no qual tudo visava melhorar a estabilidade e o desempenho do sistema. No entanto, enquanto alguns deles esperavam trabalhar com estabilidade, outros "ativaram" novos recursos como um coletor de lixo para o Objective-C no lançamento, o que atrasou o trabalho de outros e tornou o Xcode impraticável por vários meses.
Mas o trabalho sobre os bugs não foi em vão para usuários comuns que se lembraram do excelente desempenho do Snow Leopard e do Lion que o seguiu - ao contrário do Chrome, que somente durante o tempo em que escrevi este post conseguiu congelar algumas vezes e causar guias de "travamento" com um rascunho.