Muitas pessoas pensam nos problemas que as preocupam antes de ir para a cama ou ao acordar. Eu não sou uma exceção. Esta manhã um apareceu na minha cabeça de Habr:
Um colega compartilhou uma história em um bate-papo:
No ano retrasado tive um cliente incrível, isso foi quando eu estava lidando com uma pura “crise”.
O cliente possui duas equipes no grupo de desenvolvimento, cada uma lidando com sua parte do produto (condicionalmente, o back office e o front office, ou seja, software que trabalha na formação de pedidos e software que trabalha na execução de pedidos), ocasionalmente integrando-se entre si.
A equipe de back office entrou em declínio total: seis meses de problemas contínuos, os proprietários ameaçam demitir todo mundo, contrataram um consultor, depois do consultor contrataram mais do que outro (eu). Além disso, a segunda equipe (storfront) funcionou normalmente e continuou trabalhando normalmente, foi a equipe de back-office, que antes também trabalhava normalmente, que começou a bagunçar. As equipes ficam em escritórios diferentes e estão acostumadas a irritar umas às outras.Motivo: store e back são um sistema, tem muitas dependências, equipes em escritórios diferentes não se comunicam. Os proprietários “olham” para a lateral o tempo todo, então eles têm novos recursos, ideias e controle ali. Ela era um garoto faz-tudo, uma combinação de bacharel, designer e “traga-nos café”. Esse garoto, despercebido por sua equipe, estava realizando uma série de pequenas tarefas como “avisar a segunda equipe sobre a implantação”, “atualizar a documentação”, etc. rotina, até “inserir todos os tipos de números de versão e componentes no ticket”. Mas o menino não escreveu nenhum código e, a certa altura, os proprietários decidiram otimizá-lo e demiti-lo. Para a equipe da loja nada mudou, apenas não fizeram ou atualizaram os docks, e a equipe de backoffice se viu em uma situação onde os releases da loja quebram alguma coisa para eles, e isso é problema deles, e se os releases deles quebram alguma coisa para a loja, isso é novamente problema deles, porque a loja está à vista dos proprietários :)
O que me chamou a atenção com esse comentário e o que o buscador encontrará no título – abaixo do corte.
Desenvolvo aplicações web há 20 anos, então frente/verso não são apenas palavras para mim. Estas são coisas intimamente relacionadas. Por exemplo, não consigo imaginar uma situação em que a frente se desenvolva em completo (ou muito forte) isolamento da parte traseira. Ambos os lados operam com os mesmos dados e realizam operações muito semelhantes. Posso imaginar quanta informação é transferida entre os desenvolvedores de ambas as equipes para coordenar o desenvolvimento e por quanto tempo e com que frequência essas aprovações precisam ser feitas. As equipes não podem deixar de se comunicar de perto, mesmo que estejam em fusos horários diferentes. Especialmente se você tiver JIRA.
Eu sei que é inútil alertar os desenvolvedores sobre a implantação da frente. A nova versão da frente não pode quebrar nada nas costas, pelo contrário, sim. São os desenvolvedores front-end que estão interessados em notificar os desenvolvedores back-end de que precisam de funcionalidades novas ou alteradas. A frente depende das implantações traseiras, e não vice-versa.
Que garoto quem"traga-nos café", não pode haver um BA (se por BA queremos dizer "analista de negócios"), e um BA não pode ser "garoto, traga-nos café". E certamente, "adicione todos os tipos de números de versão e componentes"Nem o "menino" nem o BA conseguem fazer isso sem discutir com as equipes de desenvolvimento. É como a carroça na frente dos bois.
Já que o “menino” foi demitido, então essas funções, de “traga café"e antes"colocar gordura", deveria ter sido redistribuído entre outros membros da equipe. Em um grupo estabelecido, os fluxos de informações e funções são fixos; se o executor de uma ou mais funções deixou o palco, então o restante dos membros do grupo ainda precisa receber familiares informações de papéis familiares. Eles simplesmente não conseguem deixar de perceber que as informações necessárias para o trabalho pararam de chegar até eles. É como se um viciado em drogas não pudesse deixar de notar o fato de que o fornecimento de drogas parou. E assim como um viciado em drogas procura e encontra outros canais, então os membros do grupo tentarão encontrar fontes de informações de que precisam no “outro” lado e novos intérpretes de funções antigas. E com certeza encontrarão, pelo menos, alguém que, em sua opinião, deveria dar lhes as informações necessárias.
Mesmo se assumirmos que os canais habituais de informação foram fechados, e quem deveria, não acha que deveria, então os desenvolvedores traseiros, sob ameaça de demissão, não esconderão do proprietário as razões de suas próprias falhas para seis meses, sabendo que seus problemas se devem à falta das informações necessárias. Os proprietários não serão “estúpidos” durante seis meses, visto que antes precisavam da informação.”estava coberto de gordura", e agora ninguém está adicionando lá. E o primeiro consultor dificilmente foi tão pouco profissional a ponto de não conversar com os desenvolvedores back-end e não chegar à origem do problema - a falta de coordenação entre as equipes. Este é o motivo dos transtornos descritos, e não a demissão do “menino”.
A falta banal de comunicação entre os desenvolvedores é uma causa típica de muitos problemas de desenvolvimento e muito mais. Você não precisa ser um grande consultor para encontrá-lo. Basta ser razoável.
Acho que toda essa história é bem pensada e lindamente contada. Bem, não totalmente inventado - todos os elementos são tirados da vida (frente, costas, desenvolvimento, menino, café, "gordura", ...). Mas eles estão conectados de tal forma que tal design não ocorre na vida. Separadamente, tudo isso pode ser encontrado no mundo que nos rodeia, mas em tal combinação - não. Escrevi acima porque .
No entanto, é apresentado de forma muito plausível. É lido com interesse e há envolvimento pessoal. Simpatia por "garoto útil", o pequeno mecanismo pouco apreciado da grande máquina (é sobre mim!). Condescendência para com os desenvolvedores que são tão inteligentes e experientes, mas não conseguem ver além de seus próprios narizes (eles estão ao meu redor!). Uma leve zombaria dos donos, os ricos que se fizeram “bo-bo” com as próprias mãos e não entendem os motivos (Bem, a cara da minha liderança!). Desdém pelo primeiro “consultor” que não conseguiu encontrar uma fonte tão simples de problemas (sim, recentemente esse cara entrou de óculos e andou por aí parecendo inteligente), e uma união entusiástica com um consultor “de verdade”, que era o único que conseguia apreciar o verdadeiro papel de um menino faz-tudo (esse sou eu!).
Você sente satisfação interior depois de ler este comentário? Nosso papel como pequenas engrenagens de um grande mecanismo não é tão pequeno! Maravilhosamente declarado, mesmo que não seja verdade. Mas que sabor agradável.
Não sei que tipo de colega e em que chat compartilhei essa revelação com meu colega e por que colega mkrentovsky Decidi publicá-lo no artigo ""excelente autor habr 'a (que, aliás, está em primeiro lugar no ranking do Habr no momento!), mas admito que meu colega mkrentovsky fez isso extremamente bem. A mensagem do comentário e o estilo de apresentação são tão consistentes com a mensagem e o estilo de outras publicações nmivan'bem, o que você acha que um consultor de crise dos comentários e GG de muitas publicações nmivan'a é a mesma pessoa.
Li muitas publicações de Ivan Belokamentsev quando o autor iniciou suas atividades no Habré (em 2017). Alguns até gostam (, ). Ele tem um bom estilo e uma apresentação interessante do material. Suas histórias são muito parecidas com histórias da vida real, mas têm quase nenhuma chance de realmente acontecer, em . É assim com esta história no comentário.
Para falar a verdade, pessoalmente não creio que Habr tenha melhorado com as publicações de Ivan. Mas sua classificação e outros habitantes de Habr dizem o contrário:
Eu não entendo sua choradeira. Habr já caiu há muito tempo, mas o autor dá uma pequena faísca e melhora o humor dos leitores) ao tirar o recurso do abismo.
Sim, Habr não é uma instituição de caridade, Habr é um projeto comercial. Habr é um espelho que reflete nossos desejos. Não os meus desejos pessoais e não os desejos de cada visitante individual, mas a totalidade de todos os nossos desejos – a “média para o hospital”. E Ivan Belokamentsev sente melhor do que ninguém o que todos nós precisamos coletivamente e nos dá isso.
Talvez eu não tivesse escrito este artigo se não tivesse começado a assistir a série"".
"Perdemos Deus"(s)
Isso é da série. E isso é sobre nós.
Não estamos mais cativados pela realidade criada pelo Criador.
Deus, a Natureza, o Big Bang - tanto faz. A realidade está aí. Ao nosso redor e independentemente de nós.
Vivemos nele de acordo com as leis da natureza (o Plano de Deus). Aprendemos as leis (Plano) e aprendemos a usar a realidade em que vivemos para viver ainda melhor. Testaremos nossos palpites com a prática, descartando os incorretos e deixando os relevantes. Interagimos com a realidade e a mudamos.
E temos tido muito sucesso nisso.
Existem muitas pessoas no planeta. Muitos. Com a actual produtividade do trabalho, já não precisamos de sobreviver – a minoria pode fornecer à maioria tudo o que necessita. A maioria das pessoas precisa se manter ocupada com alguma coisa. Historicamente, o excesso de recursos destinados à criatividade ia para os mais talentosos (ou para os mais disruptivos, o que também é talento). Agora existem tantos recursos gratuitos que qualquer pessoa com algum talento pode obtê-los, independentemente do seu nível. Compare quantos filmes são lançados por ano em todo o mundo e quantos deles você pode assistir. Quantos livros foram escritos e quais deles podem ser lidos. Quanta informação é despejada na Internet e o que dela é utilizável.
Por que a profissão de TI é tão popular? Sim, porque você pode despejar um abismo de recursos em TI e ninguém piscará (basta lembrar o problema do ano 2000). Afinal, em TI você pode passar anos desenvolvendo aplicativos que se tornarão obsoletos antes mesmo de serem lançados, você pode tentar integrar componentes incompatíveis e ainda fazê-los funcionar, você pode reinventar suas próprias rodas repetidamente, ou você pode agora mesmo começar a apoiar programas em Fortran, que está coberto de musgo há mais de 20 anos. Você pode passar a vida inteira em TI e não fazer nada de útil. E o mais importante, ninguém vai notar! Até você mesmo.
Poucos de nós conseguiremos deixar uma marca no setor de TI. E ainda menos pessoas conseguirão deixar uma boa memória. Os resultados do nosso trabalho irão depreciar-se nos próximos 10-20 anos, na melhor das hipóteses, ou mesmo antes. E certamente durante a nossa vida (se atingirmos a idade da reforma). Não poderemos mostrar aos nossos netos os sistemas informáticos em que o avô deles trabalhou na juventude. As pessoas simplesmente esquecerão seus nomes. No início da minha carreira criei estações postais sob "". Faltam 20 anos para me aposentar e 10 anos para ter netos, mas a maioria de vocês já não ouviu nada sobre o "excelente aplicativo de e-mail de meados dos anos 90" ("principal pacote de software de e-mail de meados da década de 1990").
Talvez na realidade tenhamos pouca consciência da futilidade da nossa carga de TI, mas no subconsciente esforçamo-nos por escapar para onde nos sentimos confortáveis. Em mundos fictícios onde o uso de Scrum e Agile inevitavelmente leva ao surgimento de produtos que conquistam o mundo com sua utilidade há décadas. Onde não somos simples pequenas engrenagens de grandes mecanismos, mas engrenagens sem as quais os grandes mecanismos quebram. Onde a nossa vida não se dá na execução sem sentido de ações rotineiras, mas é repleta de criatividade e criação, de cujos resultados podemos nos orgulhar.
Nós escapamos para esses mundos lindos e fictícios de nossa própria inutilidade no mundo real. Nós olhamos para eles em busca de consolo.
Procuramos consolo, inclusive em Habré. E Ivan dá para nós aqui.
Fonte: habr.com