Fazendo Mais com Menos
Algumas dicas para obter grandes resultados com times pequenos de engenharia
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
Tecnologia é uma área de ritmo acelerado, especialmente em empresas em estágio inicial onde cada hora e cada dia contam. O runway diminui, enquanto a expectativa de entregar resultados aumenta.
O cenário típico é assim: um time pequeno tentando entregar múltiplas funcionalidades bem a tempo de cumprir uma data de lançamento para os clientes. Uma empresa tentando superar expectativas e entregar mais do que se achava possível.
Como superar seus concorrentes maiores com um time pequeno?
Precisamos apenas ser mais rápidos
Precisamos apenas ser mais rápidos
Startups geralmente têm um forte viés para a ação. Um grupo pequeno de pessoas motivadas, pouca burocracia e uma direção clara. Fazer as coisas rápido é muito mais fácil do que em uma grande organização, e esse é um ótimo começo. No entanto, não é tudo.
Com isso em mente, aqui estão algumas lições que aprendi trabalhando por vários anos em times pequenos com grandes planos. Embora sejam ideias que podem ser aplicadas a times de qualquer tamanho, elas se tornam mais essenciais quanto menor o time.
Tecnologia (muito) simples, infraestrutura (muito) simples
Provavelmente nem precisa ser dito, mas manter a tecnologia simples é algo muito bom quando você pode contar seu time nos dedos das mãos.
Não pense em menos infraestrutura, pense em nenhuma infraestrutura. Não adicione novas linguagens de programação ao seu stack tecnológico a menos que seja estritamente necessário. Deprecie tecnologia antiga assim que puder. Estique aquele monolito o máximo que conseguir, a menos que haja grandes benefícios em fazer diferente.
Existem muitas soluções por aí baseadas em reduzir os custos de infraestrutura ao mínimo. Use-as, e compre em vez de construir, a menos que faça parte da sua vantagem estratégica.
Generalistas >> Especialistas
Quando você tem um time pequeno, ter um especialista geralmente significa ter apenas uma pessoa com uma habilidade específica no seu time. Embora isso possa ser uma vantagem, também é um risco.
Se você mantiver seu stack tecnológico simples, poderá encontrar mais facilmente pessoas que conseguem trabalhar em toda a sua extensão. Mais sobreposição significará mais produtividade sempre. Embora as pessoas tenham diferentes níveis de conforto em diferentes partes do stack, abraçe a ideia de engenheiros em formato T. Isso tornará o desenvolvimento muito mais simples.
Construa menos, construa iterativamente
Embora construir coisas rápido seja uma grande habilidade, não construir o que não é necessário é ainda melhor. Prioridades mudam diariamente e o que era urgente ontem não é tão urgente hoje.
Quando se trata de engenharia, a maior vantagem que sua empresa pode ter é: menos código. Isso significa mais flexibilidade e menos complexidade daqui para frente, e automaticamente aumenta a qualidade. É pensamento comum buscar qualidade com mais automação, mas pouco se pensa em alcançar qualidade sem adicionar complexidade ao seu código.
E nesse sentido, abordar o trabalho de forma iterativa é a melhor solução que encontrei. Quanto mais você constrói iterações lançáveis do seu produto a cada dia, menor a chance de decisões de produto guiadas por custo afundado acontecerem.
Pense no seu time inteiro
Embora capacidade e habilidades de engenharia sejam essenciais para a entrega rápida de produto, a produtividade de engenharia não depende apenas dos engenheiros. Uma cadência de negócios estável e produtiva, aliada à colaboração, resulta em um fluxo contínuo de ideias de produto, design, análise e entrega.
Sem um time completo, gargalos e trabalho de baixa qualidade podem ocorrer em qualquer ponto. Software de baixa qualidade pode ser entregue quando há pressão e capacidade de engenharia insuficiente OU quando requisitos de baixa qualidade são criados sem estratégia de produto intencional suficiente.
Além disso, quando se trata de corrigir erros, simplesmente sai mais barato corrigir menos código do que mais código. Você não quer pagar esse preço.
Sempre invista em encontrar problemas cedo no ciclo.
Limite a análise, mas não a elimine
Gestão de produto é algo que facilmente fica de lado quando o time é pequeno. É difícil justificar Design Sprints quando seu projeto inteiro leva uma semana, ou práticas de teste AB quando você não tem usuários suficientes para alcançar conclusões estatisticamente significativas.
Embora a situação acima crie uma vontade de jogar os braços para cima e dizer “vamos simplesmente construir isso”, você pode utilizar técnicas de produto mais simples para receber feedback de produto.
Você pode aumentar o quanto entende do comportamento do usuário e realizar testes de interface em um dia. Você pode conduzir versões reduzidas de workshops de design em poucas horas. Investir no seu processo de produto de uma forma que o torne eficiente, mas que ainda permita a quantidade certa de reflexão e colaboração no time, vale a pena. Seu negócio será bem recompensado pelo código que você não acaba escrevendo.
Em resumo, times pequenos funcionam. Tenha um grupo pequeno de pessoas executando um processo enxuto do conceito ao resultado. Você ficará impressionado com o quanto consegue entregar.