Por que você precisa de liderança técnica e o que acontece quando você não a tem.

Jack Finlay Blocked Unblock Seguir Seguindo 25 de dezembro

Reflexões e observações de um projeto que foi mal.

Pássaros voando, com um na frente. Foto por Ethan Weil em Unsplash

Às vezes os projetos podem ir muito, muito mal. Na maioria das vezes, existem vários motivos. A liderança técnica é uma das principais coisas que muitas vezes falta. Pode fazer ou quebrar um projeto. Isso é uma reflexão sobre os insights que eu obtive ao observar e ser incorporado em equipes de alto e baixo desempenho.

Ao explorar e refletir sobre um projeto que foi mal, pretendo transmitir as razões pelas quais a liderança técnica é o ponto-chave no sucesso de um projeto. Cada seção apresenta remédios para questões discutidas, cada uma trazida das minhas observações obtidas quando observo equipes de alto desempenho.

Experiência

O tempo é a única coisa que pode te ensinar algumas coisas. Infelizmente, a experiência estava gravemente deficiente nesta equipe de projeto.

Close-up de um relógio. Foto de noor Younis no Unsplash

Liderança Técnica

Este projeto não teve nenhum líder técnico ou desenvolvedores seniores. Isso deve ser o suficiente para lhe dizer a direção que esta indo.

A equipe era muito inexperiente. Para colocar isso em contexto, as pessoas que iniciaram o projeto eram estagiárias e eu ainda estava na universidade. Não havia ninguém por perto para nos guiar, para nos ensinar, para nos impedir de cair nas armadilhas que um desenvolvedor sênior conheceria e anteciparia. Não havia liderança de alguém que sabia o que estava fazendo. Isso permaneceu durante todo o meu tempo no projeto. Nós simplesmente não sabíamos o que estávamos fazendo completamente errado.

A Invasão Interna

Durante um verão em particular, o número de pessoas no projeto aumentou cinco vezes. O problema? Eles eram todos internos – pessoas no mesmo nível que o pessoal permanente ou inferior. Nós já estávamos com pouca habilidade. Durante esse período, a equipe permanente foi encarregada de gerenciar os internos. Eles foram divididos em equipes de três e cada um de nós era responsável por um time.

Esta foi provavelmente a parte mais difícil do projeto para mim. Eu tive experiência em liderar equipes de desenvolvedores durante meus cursos universitários. Nada me preparou para isso. Eu agora não era apenas responsável pelo meu próprio trabalho, mas também pelos estagiários. Eles eram ótimos, pessoas talentosas, mas para muitos essa foi sua primeira experiência em um ambiente de desenvolvimento comercial. Eu tive sorte, meu time foi ótimo. Eles tiveram um bom desempenho, mas o resultado foi o mesmo; Questões que mostram através da inexperiência, tanto deles como dos meus.

Ferramental

A coisa mais importante para qualquer artesão é suas ferramentas. Sem as ferramentas e ferramentas corretas, é muito difícil produzir um trabalho de qualidade. Uma boa equipe tem um líder que conhece suas ferramentas e pode tomar ótimas decisões para as necessidades de ferramentas do projeto.

Ferramentas dispostas ordenadamente. Foto de Cesar Carlevarino Aragon no Unsplash

Bancos de dados

Neste projeto, só tivemos acesso a um banco de dados compartilhado hospedado em uma das instâncias de máquina virtual de nuvem mais lentas que você poderia obter. Nós tínhamos várias pessoas trabalhando no mesmo banco de dados, todas alterando visualizações, descartando tabelas e, geralmente, mexendo com os dados ao mesmo tempo. Esta não é uma maneira ideal de trabalhar e certamente nos atrasou.

Não tínhamos como reproduzir o banco de dados localmente ou na nuvem sem executar uma operação de backup e restauração. Não havia como obter um banco de dados limpo no mesmo estado que gostaríamos de implantar em diferentes ambientes. O banco de dados só poderia ser criado como um clone do nosso servidor de banco de dados de desenvolvimento. Isso significa que tivemos a vida útil do lixo do projeto, incluindo usuários e dados de teste, em todos os nossos ambientes.

Nós não pudemos e não recriamos o banco de dados em nossas máquinas locais. Isso significa que não tivemos a capacidade de depurar localmente ou executar dados de teste sem poluir o banco de dados de desenvolvimento compartilhado. Houve algumas vezes que tivemos que reverter para um backup do banco de dados da noite anterior, porque alguém o havia destruído com um script ruim. Isso nos atrasou muito e espalhou a dor entre toda a equipe do projeto.

As migrações e atualizações de banco de dados eram todas manuais e isso significava que teríamos que gastar tempo executando todas elas em cada banco de dados.

A solução agora óbvia aqui é permitir que os desenvolvedores tenham uma instância local do banco de dados instalada em suas máquinas. Outra solução para esse tipo de problema é usar uma ferramenta para migrações que as torne automáticas. Isso dá aos desenvolvedores a liberdade de recriar os bancos de dados à vontade e colocar os dados que quiserem testar.

atuação

Os desenvolvedores precisam e esperam alto desempenho de suas máquinas locais e dos servidores nos quais o sistema é testado. Quando os desenvolvedores recebem ferramentas lentas, eles se movem mais lentamente e demoram mais para produzir resultados.

Neste projeto em particular, tive sorte em alguns aspectos. Recebi uma das máquinas mais rápidas da época para me desenvolver. Este certamente não foi o caso de alguns dos outros desenvolvedores. Outros receberam as máquinas mais lentas que já vi. Essas coisas já existiam há provavelmente dez anos antes que essas pobres almas pudessem usá-las. Os teclados estavam desgastados por anos de uso, e os botões do trackpad tinham marcas enormes de ter usado a camada superior de plástico.

Os servidores em que estávamos testando eram as mesmas instâncias de máquinas virtuais em nuvem lentas e de baixo nível nas quais os bancos de dados eram implantados. Isso fez do sistema um dos sites mais lentos que já vi. O teste foi lento e árduo.

Resolver esses problemas é fácil. Dê aos seus desenvolvedores os equipamentos e recursos de que precisam. Não se segure no provisionamento de recursos adequados, isso só vai atrasar seu time.

Fonte de controle

O controle de origem foi uma bagunça total neste projeto. Usamos um sistema de controle de fonte grande popular nas empresas, mas o software não era o problema. Não havia uma estratégia para como usávamos: os ramos eram retirados dos galhos ad nauseam; equipes tiveram problemas de fusão porque todos decidiram trabalhar no mesmo ramo; havia apenas conflitos por toda parte. Tudo isso leva a horas de resoluções de conflitos de fusão esgotantes. Frequentemente nós quebramos o trabalho de outra pessoa inadvertidamente por causa de fusões ruins e, às vezes, até perdemos o trabalho.

Para que o controle de origem seja eficaz, você precisa ter uma estratégia e instruir sua equipe sobre como realmente usá-la.

Integração e Implantação

Devo avisá-lo, o seguinte é muito perturbador.

Este projeto não tinha absolutamente nenhum sentido de princípios ou soluções CI / CD em qualquer lugar perto dele. Implantações envolvidas copiando os recursos da pasta de criação e colando-os no servidor via Área de Trabalho Remota.

Se você já fez isso antes, conhece minha dor. Eu posso ouvir você gritando agora.

Para os não iniciados: este método depende da área de transferência do seu computador. Se você copiar qualquer outra coisa para a sua área de transferência enquanto isso estiver em andamento, ela eliminará o upload. Qualquer outra pessoa na equipe também poderia se conectar ao servidor, matando o upload. Às vezes as coisas também acabam sendo corrompidas quando você as transfere dessa maneira ??.

A solução para essas implantações problemáticas é usar uma solução apropriada de CI / CD. Isso permite integrar código rapidamente e implantar automaticamente, sempre que necessário.

Garantia da Qualidade

O controle de qualidade é uma das coisas mais importantes quando se trata de desenvolvimento de software. Uma boa equipe de QA pode identificar as coisas antes que as partes interessadas o façam. Eles também são muito mais tolerantes.

Pipetar depositando um líquido roxo em um béquer. Foto por Louis Reed em Unsplash

Peer reviews

As revisões por pares consistiam em membros da equipe sentados juntos, passando pelo trabalho que haviam feito. Isso muitas vezes não envolvia olhar para o código, tanto foi perdido na forma de desempenho e duplicação de código. A segunda questão era que éramos todos juniores ou estagiários. Ainda não sabíamos o que faz um bom código ou temos a capacidade de detectar antipadrões e erros comuns.

Os desenvolvedores seniores conhecem muitos dos problemas que podem surgir no código e identificaram um grande número de erros que cometemos. Eles são um recurso valioso, especialmente em avaliações por pares.

Teste em vitrine

Não tínhamos equipe de controle de qualidade. O teste muitas vezes não foi feito corretamente pelos desenvolvedores. O resultado? Os testes foram geralmente concluídos pela primeira vez nas vitrines. Isso resultou em vitrines que se arrastaram por horas enquanto nos sentávamos lá e registramos cada bug que nossas partes interessadas encontrariam.

Você precisa de uma equipe de testes para detectar problemas corretamente e validar suas tarefas. Os desenvolvedores são notórios por não testar adequadamente.

Qualidade do Código

A qualidade do código que você coloca é um dos maiores fatores no sucesso de um projeto.

Imagem de close-up do código JavaScript. Foto de Markus Spiske no Unsplash

Cultura copiar e colar

Nós tínhamos uma cultura de copiar e colar. Sempre que não sabíamos como fazer as coisas, simplesmente procurávamos no Stack Overflow. Isso levou a um monte de código que era composto principalmente de coisas que poderíamos copiar da internet. Essa cultura de copiar e colar nos leva a produzir código muitas vezes inadequado, código que foi retirado do contexto, não totalmente legível ou até mesmo compreendido adequadamente pela pessoa que o copiou.

Há muitas coisas diferentes que você poderia dizer sobre isso. Isso é comum em muitos projetos e ambientes, mas realmente não deveria ser. Os desenvolvedores precisam entender o código que estão copiando e torná-lo seu. Plagiar as coisas não compensa na academia, e também não paga em software.

Código Espaguete

Nossa baixa compreensão da arquitetura de software nos levou a produzir algum código que era uma bagunça total. Código espaguete é uma descrição gentil.

Grande parte do código que foi escrito foi passado em torno de muitos desenvolvedores, que adicionaram seu próprio talento a ele. Havia uma mistura de idéias e nenhum estilo coeso ou senso de convenções. Era como um par de óculos sujos, cobertos de impressões digitais. Toda vez que alguém tocava, deixava uma marca que dificultava a obtenção de uma imagem clara. Agora, é justo dizer que o código definitivamente será tocado por muitas pessoas diferentes ao longo dos anos, mas é aí que o cuidado deve ser tomado para se certificar de que tudo ainda é coerente.

Não tínhamos estrutura de injeção de dependência em vigor e não utilizamos nenhum padrão de design comum. Isso levou a um monte de código ruim que só começou a apodrecer assim que foi cortado. Princípios SÓLIDOS eram algo de que havíamos ouvido falar, mas nunca colocados em prática.

A clareza de código é tão importante quanto fazer as coisas funcionarem corretamente e as duas geralmente andam de mãos dadas. O código claro, consistente e coerente cria uma solução melhor e mais fácil de manter.

Conclusão

Muitas das questões que enfrentamos se resumem à falta de experiência. Nós não sabíamos como configurar um projeto corretamente. Não sabíamos como configurar nossos ambientes corretamente. Nós não tínhamos as ferramentas que precisávamos. Não houve supervisão técnica. Nós não tínhamos o conhecimento que precisávamos … Havia simplesmente ingenuidade descontrolada correndo em abundância.

Tendo experiência no campo da engenharia de software, um bom líder técnico nunca teria colocado o projeto nesse tipo de confusão. Eles teriam previsto os problemas que enfrentamos e os afastaram antes que eles chegassem.

Os projetos precisam desse conhecimento que um desenvolvedor sênior pode trazer para a mesa. Eu posso ver que a direção do projeto foi completamente diferente, se alguém nos colocasse no caminho certo.

Este projeto não foi uma má notícia. Conheci muitas pessoas excelentes com as quais formei grandes laços, selados por essas provações e tribulações. Muitas dessas pessoas com quem ainda converso regularmente. Havia muitas pessoas talentosas nesse projeto, mas a falta de liderança técnica impedia seu verdadeiro e real potencial.