Muitas pessoas pensam sobre problemas que as inquietam antes de dormir ou ao acordar. Eu não sou exceção. Hoje de manhã, um pensamento surgiu na minha cabeça. do Habr:
Um colega no chat compartilhou uma história:
Eu tive um cliente incrível no ano retrasado, foi quando eu ainda enfrentava uma ‘crise’.
O cliente tem duas equipes em seu grupo de desenvolvedores, cada uma cuidando de uma parte do produto (de forma simplificada, o back-office e a storefront, ou seja, o software que lida com o processamento de pedidos e o software que lida com a execução dos pedidos), integrando-se ocasionalmente.
A equipe de back-office realmente caiu na lama: seis meses de erros constantes, os proprietários ameaçam demitir todos, contrataram um consultor, e depois contrataram um outro (eu). A equipe de storefront, por outro lado, estava funcionando bem e continuou funcionando bem; foi a equipe de back-office, que antes também estava funcionando bem, que começou a errar. As equipes trabalham em escritórios diferentes e acabaram se acostumando a hibernar.A razão: o store e o back são um único sistema, que possui várias dependências; as equipes, em diferentes escritórios, não se comunicavam. Os proprietários sempre ‘observam’ a storefront, então lá têm novas funcionalidades, ideias e controle. Havia um menino que fazia tudo, uma combinação de BA, designer e ‘traga-nos um café’. Esse menino, de forma discreta para sua equipe, realizava uma série de pequenas tarefas como ‘avisar a segunda equipe sobre o deploy’, ‘atualizar a documentação’ e outras rotinas, inclusive ‘inserir no JIRA números de versões e componentes’. Mas o menino não escrevia código e, em determinado momento, os proprietários decidiram otimizar sua equipe demitindo-o. Para a equipe de storefront nada mudou; eles simplesmente não atualizavam ou inseriam a documentação, enquanto a equipe de back-office se viu em uma situação em que as releases da storefront quebravam algo para eles, e isso se tornava um problema deles, e se as releases quebravam algo para a storefront, novamente isso era um problema deles, porque a storefront estava à vista dos proprietários 🙂
O que me chamou a atenção neste comentário e o que encontrarei quem procura no título — abaixo.
Eu trabalho no desenvolvimento de aplicações web há cerca de 20 anos, então front/back não são apenas palavras para mim. São coisas que estão fortemente interligadas. Por exemplo, não consigo imaginar uma situação em que o front seja desenvolvido completamente (ou em grande parte) desconectado do back. Ambas as partes operam com os mesmos dados e executam operações muito semelhantes. Eu tenho uma noção de qual é o volume de informações que circula entre os desenvolvedores de ambas as equipes para alinhar o desenvolvimento, e quanto tempo e com que frequência essas interações precisam ocorrer. As equipes não podem deixar de se comunicar, mesmo estando em diferentes fusos horários. Especialmente quando se tem JIRA disponível.
Sei que avisar os desenvolvedores do backend sobre a implantação do frontend é inútil. Uma nova versão do frontend não pode quebrar nada no backend, mas o contrário pode acontecer. São os desenvolvedores do frontend que têm interesse em informar os desenvolvedores do backend que precisam de uma funcionalidade nova ou alterada. O frontend depende das implantações do backend, e não o contrário.
O que o menino que "traga-nos café" não pode ser BA (se por BA entendemos "analista de negócios"), e um BA não pode ser "menino, traga-nos café". E definitivamente, "inserir números de versão e componentes na JIRA" sem discutir com as equipes de desenvolvimento nem o "menino", nem o BA pode. É como colocar a carroça na frente do cavalo.
Uma vez que o "menino" foi demitido, essas funções, de "traga café" até "insira na JIRA", deveriam ser redistribuídas entre os outros membros das equipes. Em um grupo consolidado, os fluxos de informação e papéis estão fixados; se o executor de um ou mais papéis saiu de cena, então os outros membros do grupo continuam precisando das informações habituais dos papéis que foram assumidos. Eles simplesmente não podem deixar de notar que a informação necessária para o trabalho deixou de chegar até eles. É como um viciado em drogas não notar que as drogas deixaram de ser fornecidas. E assim como um viciado procura e encontra outros canais, os membros do grupo vão tentar encontrar as fontes das informações de que precisam "naquela" outra parte e novos executores dos antigos papéis. E eles certamente encontrarão. No mínimo, alguém que, em sua opinião, deve fornecer as informações necessárias.
Mesmo que se considere que os canais de informação habituais falharam, e que aquele que deve não acha que deve, os desenvolvedores de backend sob ameaça de demissão não ficarão escondendo por seis meses as razões para seus próprios fracassos do proprietário, sabendo que os erros se devem à falta de informações necessárias. Os proprietários não ficarão "parados" por seis meses, vendo que antes a informação necessária "estava no controle", e agora ninguém a insere lá. E o primeiro consultor dificilmente foi tão incompetente a ponto de não conversar com os desenvolvedores de backend e não identificar a fonte do problema - a falta de coordenação entre as equipes. Essa é a verdadeira razão das dificuldades descritas, e não a demissão do "garoto".
A banal falta de comunicação entre os desenvolvedores é uma causa típica de inúmeros problemas no desenvolvimento e não só. Não é necessário ser um consultor excepcional para identificá-la. Basta ser simplesmente razoável.
Eu considero que toda essa história foi inventada e bem apresentada. Bem, não é completamente inventada - todos os elementos são tirados da vida (front, back, desenvolvimento, garoto, café, "controle", ...). Mas eles estão combinados de tal forma que uma estrutura assim não ocorre na vida real. Separadamente, você pode encontrar tudo isso no mundo ao redor, mas nessa combinação - não. Eu já expliquei por que.
No entanto, está apresentado de maneira muito plausível. É interessante de ler e há um envolvimento pessoal. Compaixão pelo "garoto-de-todas-as-arte", mecanismo pequeno e não reconhecido de uma grande máquina (isso sou eu!). Indulgência pelos desenvolvedores, tão inteligentes e experientes, mas que não conseguem enxergar além do próprio nariz (eles estão ao meu redor!). Uma leve zombaria sobre os proprietários, os tiozinhos ricos que, com suas próprias mãos, se causaram "problemas" e não entendem as razões (é como se fosse a minha gestão!). Desdém pelo primeiro "consultor", que não conseguiu encontrar uma fonte tão simples de problemas (ah, apareceu recentemente um assim de óculos, andando com uma aparência inteligente), e uma união entusiástica com o "verdadeiro" consultor, que foi o único a conseguir avaliar o verdadeiro papel do garoto-de-todas-as-arte (ou seja, eu!).
Você sente uma satisfação interna após ler este comentário? Na verdade, nosso papel como pequenas engrenagens em um grande mecanismo não é tão pequeno assim! Maravilhosamente expresso, mesmo que não seja verdade. Mas que gosto agradável deixa.
Não sei quem é o colega e em qual chat ele compartilhou essa revelação com o colega e por que o colega mkrentovskiy decidiu publicá-lo sob o artigo "" de um destacado autor do Habr ‘a (que, aliás, está em primeiro lugar no ranking do Habr no momento!), mas eu reconheço que o colega mkrentovskiy fez isso com bastante sucesso. A mensagem do comentário e o estilo de apresentação coincidem tanto com a mensagem e o estilo de outras publicações nmivan‘a, que se pode pensar que o consultor de crise do comentário e o protagonista de muitas publicações nmivan‘a — são a mesma pessoa.
Li bastante sobre as publicações de Ivan Belokamencev, quando o autor começou sua atividade no Habr (em 2017). Algumas até com prazer (, ). Ele tem uma boa escrita e uma apresentação interessante do material. Suas histórias são muito parecidas com histórias da vida real, mas têm praticamente zero possibilidade de realmente acontecerem, . Veja só essa história no comentário.
Para ser sincero, pessoalmente não considero que as publicações de Ivan tenham melhorado o Habr. Mas sua classificação e de outros habitantes do Habr dizem o contrário:
Não entendo sua reclamação. O Habr já faz tempo que desceu ladeira abaixo, mas o autor traz um pouco de brilho e anima os leitores ) trazendo o recurso das profundezas.
Sim, o Habr não é uma instituição de caridade, o Habr é um projeto comercial. O Habr é um espelho que reflete nossos desejos. Não os meus desejos pessoais e não os desejos de cada visitante individual, mas a soma de todos os nossos desejos — "a média no hospital". E Ivan Belokamencev sente melhor que todos o que precisamos como um todo, e nos oferece isso.
Talvez eu não tivesse escrito este artigo se não tivesse começado a assistir à série "".
"Nós Perdemos Deus" (c)
Isso é da série. E isso é sobre nós.
Deixamos de nos interessar pela realidade criada pelo Criador.
Por Deus, pela Natureza, pelo Grande Big Bang — como preferir. A realidade existe. Ao nosso redor e independentemente de nós.
Vivemos nela de acordo com as leis da natureza (Desígnio Divino). Conhecemos as leis (Desígnio) e aprendemos a usar a realidade em que vivemos para viver ainda melhor. Testamos nossas suposições na prática, descartando as incorretas e mantendo as relevantes. Interagimos com a realidade e a mudamos.
E tivemos muito sucesso nisso.
Há muitas pessoas no planeta. Um número imenso. Com a atual produtividade do trabalho, não precisamos mais apenas sobreviver — uma minoria pode garantir a maioria com tudo o que é necessário. A maioria, portanto, precisa ocupar-se de algo. Historicamente, o excesso de recursos destinado à criatividade ia para os mais talentosos (ou para os mais persistentes, que também é um tipo de talento). Hoje, há tantos recursos livres que todos os que têm alguma habilidade conseguem seu quinhão, independentemente do nível. Compare quantos filmes são lançados anualmente em todo o mundo e quantos deles são bons de se assistir. Quantos livros são escritos e quais deles são realmente legíveis. A quantidade de informações que inundam a internet e o que disso é realmente útil.
Por que a profissão de técnico de TI é tão popular? Porque na TI é possível gastar uma infinidade de recursos e ninguém pisca (lembre-se pelo menos do problema do ano 2000). Afinal, na TI, você pode passar anos desenvolvendo aplicativos que já estarão obsoletos antes de serem lançados, pode tentar integrar componentes incompatíveis e fazê-los funcionar, pode inventar suas próprias bicicletas repetidamente ou pode simplesmente se dedicar ao suporte de programas em Fortran, que está em desuso há mais de 20 anos. Na TI, você pode passar a vida inteira e não fazer nada de útil. E o mais importante — ninguém notará isso! Nem mesmo você.
Poucos de nós conseguirão deixar uma marca na indústria de TI. E deixar uma boa memória será ainda mais difícil para uma quantidade ainda menor de pessoas. Os resultados do nosso trabalho desvalorizarão nos próximos 10 a 20 anos, na melhor das hipóteses, ou talvez até antes. E definitivamente em nossa vida (se vivermos até a aposentadoria). Não poderemos mostrar aos nossos netos os sistemas de computador sobre os quais seu avô trabalhou na juventude. As pessoas simplesmente esquecerão seus nomes. No início da minha carreira, eu levantava estações de correio sob "". Faltam-me 20 anos para a reforma e 10 anos para os netos, mas já agora a maioria de vocês nunca ouviu falar do "software de email de destaque dos anos 90" ("pacote de software de email mais popular do meio dos anos 1990").
Talvez na realidade tenhamos pouca consciência da futilidade do nosso fardo de TI, mas no subconsciente buscamos escapar para onde nos sentimos confortáveis. Para mundos fictícios, onde o uso de Scrum e Agile invariavelmente resulta em produtos que dominam o mundo com sua utilidade por décadas. Onde não somos apenas pequenos engrenagens de grandes mecanismos, mas engrenagens sem as quais os grandes mecanismos falham. Onde nossa vida não se desenrola em uma execução sem sentido de ações rotineiras, mas é cheia de criatividade e criação, cujos resultados nos orgulham.
Fugimos para esses belos mundos, inventados por alguém, da nossa própria insignificância na realidade. Procuramos consolo neles.
Buscamos consolo, inclusive, no Habr. E Ivan nos oferece isso aqui.
Fonte: habr.com
