Envie unidades menores de software e limite o tamanho de suas filiais de host local

Na última década, liderando o HackerNoon , trabalhei com muitos desenvolvedores de software talentosos e, no início de sua gestão, geralmente acabo dizendo a mesma coisa: envie unidades menores de software e limite o tamanho de suas filiais de host locais. Por que? Aqui estão os dois principais motivos e um grande, mas:

1. Os usuários colhem mais benefícios - e dão feedback - do seu trabalho enquanto você continua trabalhando para concluir o projeto.

Se você tem um projeto que vale 6 meses de trabalho e não entra no ar por 6 meses, são 5 meses e 30 dias em que os usuários não colhem nenhum benefício com seu trabalho. Somente quando estiver ao vivo o resto da Internet poderá ter a chance de se beneficiar do que você envia. E mesmo assim, é justamente aí que começa a enorme batalha pela adoção. Se você enviasse parte do projeto toda semana, os usuários começariam a ganhar valor ao longo do ciclo de vida do projeto.

Dane Lyons , meu ex-colega, certa vez me disse: “devemos continuar adicionando unidades atômicas de valor e fazer quantos lançamentos forem necessários. Poderíamos facilmente ter 10 lançamentos em [funcionalidade] antes de estarmos satisfeitos com isso e prontos para seguir em frente.”

Como CEO, muitas vezes julgo os novos contratados pelo tempo que levam para se tornarem colaboradores lucrativos. Nas vendas, isso é mais direto. As vendas superaram a remuneração? É claro que há outras coisas a serem consideradas, como custos marginais de marketing, infraestrutura, etc., mas seja qual for a divisão, é mais difícil medir como um desenvolvedor de software impacta os resultados financeiros do que um vendedor. Se você está assumindo uma nova função como desenvolvedor de software, recomendo tentar reunir singles com sucesso antes de partir para home runs.

No jogo de desenvolvimento de software, não existem regras universais sobre qual é a pontuação. Claro que algumas pessoas atribuem sistemas de pontos e outras definem KPIs, mas no final das contas, são as pessoas que usam seu produto que determinam se e como você está criando valor ou não. Ao enviar mais cedo, você receberá feedback mais cedo. As pessoas que usam o seu software deixarão mais claro como construir e não construir a próxima unidade atômica do projeto.

2. Quanto mais sua filial se desvia da realidade de produção, mais difícil será para os colegas de equipe contribuir com seu projeto e levar adiante os projetos adjacentes.

As externalidades de não enviar a versão mais atualizada podem ser mais difíceis de ver no início. Tudo está conectado. Em um produto como o HackerNoon, por exemplo, a página de perfil e a página de história não existem no vácuo; eles existem como páginas conectadas dentro de um produto. Se ocorrerem alterações no funcionamento de uma página, isso afetará o funcionamento de todas as páginas conectadas a ela.

Se sua filial local for muito grande, outras alterações que acontecem nas páginas ou funções conectadas a ela muitas vezes não funcionarão quando sua filial obesa finalmente entrar em produção. Isso quebra as coisas. Isso cria bugs. Isso força a necessidade de refazer o trabalho. Isso cria em seus colegas de equipe o desejo de não trabalhar com você. Isso pode até criar uma experiência de produto pior do que aquela que você já tinha, antes de todo o trabalho que você colocou em sua filial local.

Ao fazer pequenas alterações com mais regularidade, você capacita outras pessoas a contribuir. Eles acham que o que enviam também funcionará porque vocês dois já concordam qual é a linha de base da produção. Incremental é o seu melhor amigo. Ele conecta você à realidade. Se as mudanças incrementais estão afetando negativamente o produto, o que faz você pensar que mudanças maiores na mesma direção afetarão positivamente a experiência do produto?

E o velho mas é: não tenha medo de projetos ousados que podem se tornar ramos grandes demais porque você é um idiota ruim que é capaz de fazer a diferença na forma como essa porra de coisa funciona para as pessoas.

Alguns projetos simplesmente precisam ser grandes filiais. Por exemplo, coisas com dependências enormes, como novos bancos de dados, podem estar tão arraigadas no uso existente que é melhor voltar no tempo e abordar o projeto como um lançamento anual local 2.0. E outras tecnologias inovadoras, como ChatGPT, demoraram tanto para serem construídas que simplesmente não faria sentido adotar o lançamento de uma versão UX destreinada, incompleta e de merda da nova tecnologia. Faça grandes oscilações. Quando você tem a pista. Quando você tem a equipe a bordo. Mas não se exalte. Na maioria das vezes, o desenvolvimento de software não é uma reinvenção da roda. É simplesmente enviar a próxima unidade atômica.