Sobre Relação entre Empreendedor e Devs (em pequenas empresas)

Submitted by kaleu on Tue, 05/12/2020 - 17:50

Minha experiência é sobre pequenas empresas. É sobre alavancar pequenos negócios com desenvolvimento de tecnologia.

O que quero com esse texto é ajudar que empreendedores e programadores construam uma relação de confiança para conseguirem inovar no melhor nível. Vou tentar.

Meu contexto é espaço da pequena empresa, quando um empreendedor, munido de algum recurso, uma visão e muita vontade busca profissionais de tecnologia para realizar algo.

Na outra sou o profissional de tecnologia, buscado por algumas empresas para realizar um sonho, um projeto. Foi no meu trabalho que alguns empreendedores investiram seus recursos. Tenho meu desafio de tentar entregar soluções que sempre são novas, em um cenário de tecnologia com muitas novidades todos os dias, criando algo também não sei se funcionará.

Essa relação, na minha experiência, é SEMPRE difícil. Não que seja ruim, muito pelo contrário, pode ser maravilhosa, o que quero dizer é que se bem realizada ela sempre será difícil por um motivo muito simples: é sempre um jogo de forças. Eu explico.

Um programador se torna programador (geralmente) porque gosta de tecnologia. Muito provavelmente isso envolve uma boa dose de prazer em aprender e conhecer novas tecnologias.O empreendedor geralmente está focado no dinheiro (alguns, na paixão), mas o elemento principal é o dinheiro que recebe quando entrega algo que outra pessoa precisa.

Quando se juntam para realizar um projeto, no início, geralmente é muito empolgante, mas com alguns poucos meses a tendência é que as dificuldades comecem a aparecer porque na maioria das situações, o desenvolvedor sente uma atração quase inevitável por explorar novas tecnologias, quando para a maioria dos problemas, vocẽ não precisa de nada muito inovador, só precisa usar o que já existe para resolver o problema. Mas empreendedor, entenda, há uma dificuldade adicional em software:

Um programador toma centenas (ou milhares) de pequenas decisões para cada código criado. Essa grande quantidade de decisões abre muito espaço para experimentar coisas diferentes, integrar outras tecnologias e no momento social atual, há sempre dezenas de formas e tecnologias para resolver um problema. Isso dispersa.

Vejo sempre uma grande alegria e entusiasmo em se definir o stack inicial de uma nova tecnologia, para um programador, é como um parque de diversões. Mas com o tempo, os brinquedos se tornam chatos e repetitivos, e um programador não gosta de ser repetitivo.

Uma tendência de solução é achar então que se você colocar um bom líder técnico mais ditatorial definindo o que deve ser feito e algumas pessoas programando, o problema se desfaz, mas isso não funciona porque se o programador perde o espaço de pesquisa e inovação, ele perde também a força de fazer o que a tecnologia faz de melhor, que é a própria inovação. Agir dessa forma é sufocar a inovação que pode surgir do que há de mais interessante nesse jogo de forças, o equilíbrio entre tecnologia e necessidades de negócio é que é fantástico.

Então, qual a solução?

Bem, na minha visão, quem tem a chave da situação é o empreendedor. Conheço muitos programadores de excelente nível que conseguem ter um bom discernimento para conduzir os líderes a um resultado equilibrado (mas não é seguro contar com essa habilidade nos devs, o foco da programação é masi técnico criativo do que este senso político, digamos assim).

A chave da solução está em o empreendedor ter PROFUNDA CLAREZA do que ele NÃO PRECISA e do que é o MAIS PRIORITÁRIO a cada instante.

Partimos de duas bases:

  • Se o empreendedor sufocar a força criativa, ele pode matar a inovação;
  • O programador é profundamente carregado de micro decisões.


A melhor forma de vencer estes desafios é a LIMITAÇÃO DE ESCOPO. Quando o empreendedor cria limites, isso elimina um número muito grande de decisões que os programadores precisariam tomar. Em um software para avaliação escolar, um empreendedor ambicioso pode querer que sua equipe projete um software que funciona do ensino infantil à uma faculdade. FERROU. São tantas variáveis a serem olhadas pela equipe, que a tendência do time será buscar uma sobrecarga de engenharia. Agora, se o empreendedor decide que seu primeiro ataque serão escolas de educação fundamental, ele criou um limite claro e a equipe pode lidar somente com as variáveis de uma escola de EF, o que já é muito, mas já é algum limite.

Depois disso, ele precisará PRIORIZAR qual recurso deve ser entregue primeiro, o que ainda é limitação de escopo, que terá que ser feita sempre a cada nova fase e dependendo do tamanho e maturidade da equipe com maior ou menor grau.

Mas limitar escopo é uma tarefa muito difícil para o empreendedor, porque ele está lidando com a incerteza, ele não sabe ainda exatamente o que dará certo ou não na solução. Mas por mais difícil que seja, alguém precisa tomar essa decisão difícil.

Alguns empreendedores que conheci, tendem a deixar uma visão "vaga" e "genérica" demais do que querem, justamente pela dificuldade da questão de decidir e definir. Ou, o que é pior, às vezes tem a visão clara, mas não a comunicam bem por medo de que ao limitar o produto, os programadores se sintam limitados ou cerceados.

Veja bem, o empreendedor não pode, não deve e não vai conseguir controlar a tecnologia escolhida nem o meio de organização do time. Isso não tem como funcionar, pelo mesmo motivo que um paciente não questiona os procedimentos de um médido, e uma empresa não micro gerencia seus advogados. Um programador é um profissional que estuda para fazer com que os computadores executem um trabalho. Você, empreendedor, não manja disso (e mesmo que seja da área, você provavelmente não tem tempo de estudar tecnologia se já é o empreendedor também).

Agora, o empreendedor é o único que pode e deve controlar o produto, o negócio, que ele está criando. Ele precisa dominar as necessidades dos seus clientes, compreender o que para eles é ou não importante.

Eu já me frustrei algumas vezes porque tinha vontade de deixar algumas telas mais "elegantes", mas para o público do empreendedor parceiro meu na missão, já estava ótimo. Por que ele gastaria mais dinheiro comigo se já está bom para o cliente dele? Só se ele quisesse me agradar...mas bem, no meio profissional, eu diria que não é uma ideia muito esperta querer agradar alguém deixando ele fazer algo sem valor para o negócio.

O empreendedor precisa ser RIGOROSO (talvez duro, o que não significa abuso) com o que ele quer e atuar para ajudar o time a compreender os limites do que deve ser MUITO BEM FEITO e do que não exige tanto rigor,

Algumas features, são apenas testes do empreendedor e não merecem serem desenvolvidas para escalabilidade horizontal. Outras features, são tão importantes no core da solução que merecem toda atenção possível e um deslize pode atrapalhar muito o negócio.

E aqui é a parte que mais gosto dessa reflexão. Quando o empreendedor define claramente os LIMITES, os programadores podem concentrar toda a sua capacidade inovadora no que realmente importa, isso envolve usar uma tecnologia moderna, práticas modernas, o que for necessário, para o problema em si.

A forma de definir estes limites vai variar dependendo do estilo do empreendedor, mas a minha favorita é:

  • Datas claras de lançamento com apresentação pública do software.


Por exemplo: "Dia 15 de junho teremos um outdoor com a url do site do produto para os usuários fazerem teste grátis". Ou "Dia 10 de junho, 16 horas, teremos uma live com a patocinadora do projeto para apresentar uma versão parcial".

Um comprometimento público direciona a energia para o que realmente importa.

Um diálogo provável

O segredo aqui é que o compromisso deve ser acordado com a equipe, a equipe precisa conseguir concordar com a data e se comprometer com ela. Um exemplo de diálogo pode ser assim:

- [Empreendedor, bastante empolgado] Time, contratei uma divulgação em outdoor e no site de notícias da cidade com o lançamento do produto;
- [Programador, com olhar assustado] Que dia que vai ser?
- [Empreendedor, triunfante] 15 de junho.
- [Alguém do time, bem assustado] Vixi, não vai dar.
- [Empreendedor, azul] Quê? Como? Mas não tinhamos combinado isso no início do projeto?
- [Programador] Tinhamos falado desta data, mas já fazem três meses, não temos como ter algo pronto nesta data.
- [Empreendedor, furioso, mas contido] Estava contando com isso, já contratei a divulgação e nossos recursos estão no limite, se não começar a vender, será um problema.
[Equipe em silêncio]
- [Empreendedor, tentando olhar pra frente] Tem algo que podemos fazer para conseguirmos cumprir esta data?
[Equipe pensativa]
- [Empreendedor, buscando um caminho] O que falta ainda para termos uma versão completa?
- [Programador] Bem, falta a área administrativa para acompanhar os clientes cadastrados, o sistema de geração dos relatórios e o sistema de pagamento com cartão de crédito. Precisaríamos pelo menos de mais um mês.
- [Empreendedor, com olhar de ânimo ressurgindo] Hum... a área administrativa não sei se preciso nessa data, vocês conseguem me dar a informação do número de clientes de outra forma mais rápida?
- [Programaodor] Sim, posso pegar direto no banco de dados, se for uma vez por dia ou semana, é viável.
- [Empreendedor] Opa, então, sem precisar da área administrativa, é possível cumprir essa data?
- [Programador] Talvez, mas tem uma incerteza, o sistema de pagamento exige bastante cuidado.
- [Empreendedor] Bem, terminar o sistema de relatórios é viável?
- [Programador, bem confiante] Ah sim, com certeza, esta parte da tempo.
- [Empreendedor, olhar brilhando de novo] Ótimo, tenho um plano, vejam se é viável. Faremos o lançamento completo para um teste grátis de 30 dias. Assim, caso o pagamento demore mais alguns dias além desta data para entrar no ar, eu posso tentar algumas vendas diretas pela plataforma de pagamento. Vou organizar com a equipe de marketing para focarmos a campanha no teste grátis do produto nesta data e já preparar uma segunda campanha incentivando a compra para umas duas semanas depois. A área admin, podemos fazer depois, ao longo de julho. Podemos seguir dessa forma?
- [Programador] Sim, isso faz sentido, podemos.
- [Empreendedor] Ótimo, e, caso vocês vejam que é viável fazermos horas adicionais para o sistema de pagamento estar pronto até quinze de junho, sem corrermos o risco de vocês ficarem sems aúde, podemos negociar, falem comigo.

Conclusão

A mágica acontece quando o primeiro elogio é recebido de um cliente, o melhor elogio é sempre uma compra realizada.

Quando aquela solução, criada com a visão de negócios do empreendedor e capacidade técnico-criativa do programador se prova útil na vida de alguém, todos os elementos para uma belíssima relação de confiança estão firmados e é possível que daí para frente, o nível do diálogo evolua de forma natural e tende a durar enquanto se manter o respeito pela responsabilidade de cada profissional.

Então, finalizando, EMPREENDEDOR, seu papel é dar a direção, e dar a direção significa eescolhar UMA estrada por vez. O rumo pode mudar, mas é UM por vez.
PROGRAMADOR, você não precisa decidir tudo sozinho, já são muitas decisões, coloque suas dúvidas sobre o que é mais prioritário, e quando identificar o que é mais fundamental para o negócio, CRIE A MELHOR solução técnica que conseguir. No que não for tão crucial, tudo bem ser apenas pragmático e eficiente.

Que muitas tecnologias incríveis surjam.