Essa declaração não apenas inspirou os empreendedores a lançar incontáveis startups, mas também mostrou às organizações empresariais maiores que era hora de abraçar um cenário baseado em tecnologia. Em um artigo para o The Atlantic, James Somers escreveu: “Mais e mais,…
Marc Andreessen declarou em um artigo do Wall Street Journal de 2011 que o software está comendo o mundo . Essa declaração não apenas inspirou os empreendedores a lançar incontáveis startups, mas também mostrou às organizações empresariais maiores que era hora de abraçar um cenário baseado em tecnologia. Em um artigo para o The Atlantic , James Somers escreveu: “Mais e mais sistemas críticos que antes eram controlados mecanicamente, ou por pessoas, estão passando a depender de código”.
Nesse mesmo artigo, Leo também destacou um incidente em que uma plataforma de software causou uma indisponibilidade generalizada do 911. A causa foi uma linha de código legado em que os programadores definiram um limite para como o número total de chamadas que o sistema iria processar – e em abril de 2014, o contador excedeu esse número.
Isso cria um novo desafio para os gerentes de engenharia. Conforme as empresas continuam a aumentar suas equipes de engenharia , o que isso significa para o gerenciamento de projetos de base de código , especialmente à medida que ele se torna mais complexo a cada ano? Aqui estão algumas sugestões para ajudar a manter sua base de código sob controle.
Dê aos novos contratados bastante tempo para se ajustarem
Os desenvolvedores desejam fazer um trabalho significativo o mais rápido possível. Freqüentemente, essa ânsia é uma qualidade que os gerentes de engenharia procuram durante o processo de contratação. Mas depois de encontrar e contratar esses programadores, um dos segredos para o gerenciamento de projetos de base de código é dar aos programadores mais novos tempo para embarcar adequadamente.
Jon Chan, um desenvolvedor, escreveu uma extensa postagem no blog sobre suas primeiras seis semanas na empresa . Em suas primeiras duas semanas, ele aprendeu a pilha de tecnologia da equipe . Em sua terceira e quarta semanas, Chan dissecou como o grupo organizou sua base de código. “Eu me sentia muito confortável com as tecnologias em sua forma ‘platônica’, mas ainda não entendia como tudo estava organizado na base de código e configuração reais de devs”, escreveu ele. “Aprender C # e .NET foi apenas o começo. Descobrir como foi feito para tornar Avance Network o que é … é uma aventura completamente diferente.”
Como muitos de seus colegas, Dan era um desenvolvedor talentoso antes de se juntar à equipe. Mas isso mostra que mesmo os programadores mais talentosos precisarão de tempo para se aclimatarem com sua base de código . Se você apressar esse processo, eles podem ser adicionados à sua base de código de rápido crescimento, mas de maneiras que afetam negativamente seus produtos.
Divida sua equipe de engenharia em funções especializadas
Adam Pisoni conversou recentemente com a First Round Review para discutir como ele ajudou a fazer o Yammer crescer de uma equipe de cinco para uma empresa de 500 funcionários. Quando o grupo era menor, ele e seus programadores trabalharam juntos na base de código. Mas à medida que eles começaram a crescer, o mesmo aconteceu com a base de código – e não de uma forma positiva.
A solução para melhorar o gerenciamento do projeto de base de código acabou sendo razoavelmente direta. O Yammer decidiu dividir sua equipe de engenharia em funções menores, o que permitiu à empresa distribuir o trabalho com mais eficiência. “A forma como nos organizamos mudou a forma de nossa tecnologia”, disse Pisoni à revista.
Pisoni também diz que quando ele era um contribuidor individual, não havia ênfase no processo e nada se assemelhava ao controle de versão. Hoje, ele diz que isso seria uma loucura absoluta. “Agora sabemos que a única maneira de ter um grande grupo de engenheiros trabalhando juntos é ter uma metodologia de desenvolvimento”, continua ele. “Mas ainda assim, poucas empresas carecem de uma metodologia organizacional que ajude sua empresa a operar com eficácia sem exigir que você gerencie manualmente tudo o que acontece.”
Você já viu casos em que os próprios desenvolvedores podem se tornar barreiras à inovação?
Sim, mas geralmente é o resultado de linhas de comunicação pouco claras em toda a empresa. Por exemplo, imagine que seus desenvolvedores desejam um novo data center há anos e finalmente o aprovaram. Se eles sugerirem uma nova solução dois anos depois, temem ser examinados por sua recomendação anterior. No final das contas, eles se tornam avessos à inovação.
O que a liderança pode fazer nos casos em que a inovação emperra?
Meu conselho seria fomentar a inovação em cada departamento. Dê a cada equipe um projeto de inovação para melhorar seus próprios processos e tarefas.
Vimos alguns exemplos em que os projetos mais avançados são terceirizados para departamentos de “inovação” dedicados, que normalmente são liderados por executivos de nível C. O problema é que esses departamentos não têm poder de decisão. Além disso, o que poderia ser mais desanimador do que dizer ao seu departamento de engenharia que apenas alguns desenvolvedores selecionados poderão fazer algo nesse departamento de inovação?
Existe uma diferença na cultura de inovação entre a Alemanha e o resto do mundo?
Sim, mas não acho que seja uma coisa ruim. Acho que para nós, faz sentido nos ater a algumas virtudes alemãs, mesmo em uma indústria em evolução como a tecnologia regulatória. Isso significa que não transformamos o fracasso em nosso plano de reserva. Sou totalmente a favor de projetos exploratórios, mas cabe às equipes fazerem suas pesquisas para que possamos entender e minimizar os riscos, ao mesmo tempo que nos sentimos confiantes de que a solução provavelmente funcionará.
