Como melhorar o relacionamento entre o founder não técnico e o desenvolvedor
Uma das dúvidas que mais ouço quando converso 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/softhouse.
A seguir uma lista com dicas que realmente dou quando surge esta questão.
Tenha o controle do código fonte
Algo que me incomoda muito com relação a freelancer e até mesmo com algumas consultorias/softhouses é o fato de não disponibilizarem já no primeiro dia 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 é antes mesmo de contratar o desenvolvedor ou a consultoria/softhouse é ter uma conta aberta no GitHub e no dia da contratação cadastrar os desenvolvedores como colaboradores nesta conta. Desta forma, alem de ter o código sempre em mãos, ainda conseguirá checar quais as features estão sendo desenvolvidas, quantos commits estão sendo feitos 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 verificiar 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 (quem gosta?)
Se você precisa microgerenciar, significa que o desenvolvedor nã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 você imaginou. Isso normalmente se chama sprint.
No mundo real, o tempo de desenvolvimento é sempre maior, e o parafuso que foi pedido acaba se transformando em uma meia. Porque isso acontece?
Um erro comum é escrever várias páginas descrevendo o que é desejado e esperar que o time de desenvolvimento entenda tudo de primeira. A melhor forma é envolver o time de desenvolvimento na concepção do produto, de maneira que eles tenham 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 podem ser copiados ou roubados pelos desenvolvedores, que suas idéias podem ser replicadas. Aqui vai uma verdade que muitos não gostam de ouvir: não importa qual seja tua idéia, ela sempre pode ser replicada.
A parte boa é que uma idéia é somente uma idéia, 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 que? 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 e atores, onde vale o network criado com anos de confiança, as amizades, recomendações, 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 por que cada peça de código está sendo escrita e o que ela deve resolver.
Estas dicas foram válidas para você? Deixe um comentário com temas que gostaria que fossem aboradados mais a fundo em próximos posts.
