Por John Calistro, Tech Buddy no iDEXO e Community Manager iMasters
Uma das dúvidas que mais ouço quando falo com founders de startups que não são técnicos e/ou que não têm um CTO no time, é como conversar e ter o mínimo de controle sobre o que o desenvolvedor está fazendo – principalmente se este for freelancer ou uma consultoria/software house.
A seguir, uma lista com dicas que dou quando surge esta questão.
Tenha o controle do código fonte
Algo que me incomoda muito em relação a freelancer e até mesmo com algumas consultorias/software house é o fato de não disponibilizarem já no início do projeto o acesso ao código do cliente. Vejam a ênfase: o código é do cliente, pessoa que está pagando por ele.
Uma das melhores maneiras do founder ter o código em mãos desde o primeiro dia é ter uma conta aberta no GitHub e, no momento da contratação, cadastrar os desenvolvedores como colaboradores. Desta forma, alem de ter o código, ainda conseguirá checar quais as features estão sendo desenvolvidas, os commits e até mesmo verificar a qualidade do código por meio de consultoria independente.
Ter um consultor independente para verificar o código/entregas com alguma frequência
Aqui vale ter aquele(a) amigo(a) de confiança que por alguma razão não consegue ser o desenvolvedor da startup, mas que pode dar uma mão para verificar as entregas e até mesmo agir como um P.O./P.M./CTO honorário em reuniões com o time de desenvolvimento.
Caso não tenha esta pessoa disponível, um consultor independente pode ser contratado para verificação de código ou participação em reuniões com o time de desenvolvimento. Não existe um tempo pré-definido para estas checagens, mas é importante estar sempre de olho nas entregas e prazos.
Desenvolvedor não gosta de microgerenciamento (aliás, quem gosta?)
Se você precisa microgerenciar, significa que o desenvolvedor não é o certo para trabalhar em startup. Simples assim. No mundo ideal, você passa as regras de negócio e as demandas para o time de desenvolvimento e recebe, depois de um tempo (curto, de preferência), um código que funciona de acordo com o que imaginou. Isso normalmente se chama sprint. Já no mundo real, o tempo de desenvolvimento é sempre maior, e o parafuso que foi pedido acaba se transformando em uma meia. Por que isso acontece? Um erro comum é escrever várias páginas relatando o que é desejado e esperar que o time de desenvolvimento entenda tudo de primeira. Esqueça. A melhor forma para chegar ao resultado é envolver o time de desenvolvimento na concepção do produto. Assim, eles têm uma noção clara do que a solução está resolvendo e qual a entrega esperada para o usuário.
Envolva o time de desenvolvimento nas decisões de negócio
Eu sei que muitos founders pensam que serão copiados ou roubados pelos desenvolvedores. Aqui vai uma verdade que muitos não gostam de ouvir: não importa qual seja sua ideia, ela sempre pode ser replicada.
A parte boa é que uma ideia é somente uma ideia, e que mesmo que alguém tenha acesso ao código fonte completo da Netflix e copie toda a parte conhecida de negócios deles, garanto que o produto não se tornará uma Netflix. Por quê? Simples: o código fonte é somente uma parte da engrenagem, e mesmo que você copie a parte conhecida de negócios, existem muitas outras engrenagens que você provavelmente não terá acesso, como por exemplo as negociações com as distribuidoras de filmes, diretores, atores e etc. O mesmo vale para Uber, Airbnb e por ai vai.
Não tenha medo de envolver o time de desenvolvimento em outras áreas de negócios da startup. Com isso, eles entenderão melhor o negócio e saberão exatamente porque cada peça de código está sendo escrita e o que ela deve resolver.
Foto: Hack Capital