Formando uma equipe de desenvolvimento de software enxuta

Algumas opniões e dicas sobre como ter uma equipe de desenvolvimento de software enxuta para sua Startup

Macgyver
Tableless
Published in
7 min readApr 17, 2017

--

Assim como nos seres humanos, o nascimento e a vida de uma Startup são únicos. Os desafios das startups se diferenciam em detrimento do setor de atuação, tipo, modelo, estágio, equipes e etc.

Não precisamos sair da camada superficial para enxergar que cada Startup tem sua jornada.

Sendo assim, as opiniões expressadas nesse texto não são a receita para o sucesso ou sobre como ter uma equipe de desenvolvimento matadora. No entanto, são padrões e dicas que aprendi e poderão ajudar você a preparar melhor a sua equipe de desenvolvimento.

Com a metodologia Lean Startup aprendemos que é possível fazer ciclos de entregas de MVPs para validar e pivotar seu produto (ou serviço) e ter um crescimento sustentável do seu negócio. Isso resulta em vários cases de startups que validam idéias em um dia e também fecham contrato sem sair do papel, entre outros. Os eventos de Startup Weekend estão cheios de exemplos práticos dessas técnicas.

Entretanto, eu observei um padrão: não importa o quão Lean você é como empreendedor, na maioria das startups, quanto mais ela cresce — do ponto de vista de negócio- mais aumenta a necessidade de ter um time de desenvolvedores.

Seja porque você ja avançou tudo o que podia com seus "hacks de negócio" ou porque o estado atual da sua equipe não supre a demanda. O surgimento de uma equipe de desenvolvedores é inevitável.

Mas, isso não significa que toda a sua cultura de startup irá pro ralo. Na verdade, você precisa ter uma mentalidade Lean não só apenas no desenvolvimento do produto, mas em todos os aspectos da sua startup.

Então, como formar um time de TI enxuto?

Vamos lá..

Tudo gira em torno dos “foras da curva”

Eu não queria falar sobre soft skills, pois esse assunto gira em torno de coisas abstratas e percepções. No entanto, acredito que todo boa equipe de startup é formada por pessoas fora da curva. Por isso, esse texto se inicia dedicado a eles.

Um "fora da curva" não quer dizer um desenvolvedor sênior de 14k/mês. Eis a minha definição pessoal de um fora da curva:

Fora da curva são pessoas que tem push, autonomia, querem aprender e fazer acontecer. São profissionais que veem cada desafio da sua Startup como uma nova oportunidade de aprendizado e evolução.

Programadores fora da curva são apaixonado pelo que fazem e estão sempre no ritmo de aprender cada vez mais. Eles conseguem ver as oportunidades da sua Startup como uma forma de evolução constante para ambos os lados – para o negócio e para eles – onde tudo é motivo para aprender e aplicar rápido.

Profissionais com esse perfil não se veem presos a plataformas ou tecnologias. Eles estão aqui para aprender e ultrapassar seus limites.

Outro ponto importante é que por serem fora da curva, esses profissionais conseguem ter uma visão mais crítica sobre o negócio, o que os fazem tomar boas decisões de forma rápida e eficiente.

Atualmente tenho a honra de trabalhar ao lado de diversas pessoas assim, e sei o valor que isso gera para o negócio como um todo.

Mas… não há muitos desses boiando por aí no mercado. Portanto, agarre-os assim que os encontrar.

E tome cuidado! Esse tipo de profissional não gosta de ser tratado como “funcionários robozinhos”. Entregue para esses profissionais um ambiente de aprendizado, deixe-os serem empreendedores internos e você terá uma excelente equipe.

Contrate profissionais com perfil T-shaped

Para você que ainda não sabe o que é um perfil T-shaped, eis aqui uma excelente definição que encontrei nesse post do Tableless:

As pessoas T-shaped são profissionais que conhecem diversos assuntos de forma bem geral, não chegando a ser um profundo especialista (a parte de cima do T), mas também são experts em um campo de conhecimento específico (a parte vertical do T).

Quando falamos de programador T-Shaped as skills horizontais podem até ser em diferentes áreas ou soft skills. Porém, vou abordar esse conceito focando apenas na área de desenvolvimento.

Na minha opinião, desenvolvedores em T são profissionais que tem domínio de uma tecnologia em específico, e um conhecimento geral ou intermediário em outras áreas do desenvolvimento. Não necessariamente sendo um full-stack motherfucker.

Um desenvolvedor Front-End web, por exemplo, é especialista no desenvolvimento do client-side e domina as últimas tecnologias e frameworks web. Entretanto, pode vir a ser alguém com skills horizontais para outras áreas do desenvolvimento web, como conhecimentos de PHP, por exemplo.

Então, minha proposta é: quando olhar para um profissional em busca das suas skills horizontais e verticais, procure o profissional onde a skill vertical preencha a necessidade corrente da sua Startup e as horizontais sejam aquelas que entregam valor para possíveis desafios técnicos diários.

Um exemplo pratico: Você precisa de um desenvolvedor mobile. A skill vertical desse profissional seria, obviamente, desenvolvimento mobile. Ja nas horizontais ele poderia: ter conhecimento básico de Ruby para ajudar com algum bugfix simples na API; dominar o desenvolvimento Web para ajudar naquelas mudanças rápidas no front-end da aplicação; fazer as integrações com ferramentas de negócio (ex: RD Station, Zen desk, Facebook), agregar valor ao time com habilidades de liderança, entre outros.

O profissional em T é alguém que vai entregar muito valor para o negócio, tanto de uma forma muito específica como de uma forma mais generalista.

E como saber quais skills procurar? Ninguém melhor do que o próprio time atual de desenvolvimento para apontar quais as habilidades verticais e horizontais atendem melhor as necessidades do produto.

Um ultimo ponto muito importante: você precisa fomentar a evolução dessas habilidades extras da sua equipe. Em breve irei escrever um Post sobre isso, mas existem diversas formas de fazer isso, e vale a pena pesquisar.

Mantenha a equipe pequena para ser mais produtiva

Talvez não seja nenhuma novidade para você, mas equipes grandes são menos produtivas no sentido de velocidade de organização, aprendizagem e entrega.

Segundo Wagner e Hollenback (2009, p. 218) O tamanho reduzido do grupo é igual a: menos restrições físicas; menos distrações sociais; menos exigências de coordenação, menor mascaramento comportamental e menos difusão de responsabilidade.

E todos esses benefícios juntos geram outros N benefícios.

Vamos ver isso com um olhar mais simplista: Eu estudei a minha vida toda em escolas públicas; em salas de aulas lotadas com 40 alunos e um professor sendo o super-herói para lidar com todos os desafios de um grupo de adolescentes desse tamanho. E durante alguns anos, estudei meio período em outra escola onde cada professor ensinava apenas uma turma de 5 alunos por vez.

É claro, a diferença no aprendizado era enorme!

No grupo com 5 alunos conseguíamos aprender mais coisas em 1 dia do que estudávamos durante um mês no ensino da escola tradicional. E estou falando aqui de matérias relativamente complexas, como Neuro Ciências, Física e outras.

Agora, leve esse pensamento para a um equipe de desenvolvimento.

Uma equipe com 5 profissionais responsáveis pelo desenvolvimento do produto (programadores, designer e etc) terá todos esses ganhos essências para uma equipe enxuta, ocasionando em velocidade de organização, aprendizado e entregas muito a frente de outras equipes maiores (10+).

Como você ja deve saber, velocidade de organização, aprendizado e entrega é tudo o que uma equipe enxuta de desenvolvimento precisa.

De fato, toda startup vai ter uma equipe reduzida no início. Até mesmo devido ao investimento e/ou evolução do produto. Isso não é nenhuma novidade. Mas, imagine sua startup decolando e o crescimento do time sendo inevitável. Ainda nesse momento tente levar o pensamento de grupos menores adiante. Transforme sua equipe de desenvolvimento em pequenos times de desenvolvimento, como se estivesse componentizando a equipe total.

Não se prenda na metodologia X ou Y

É muito comum as pessoas se apegarem a metodologias ou ferramentas de gestão e interpreta-las como balas de prata.

Aplicar seus dogmas de gestão em uma equipe enxuta não é só imaturo como também letal para a produtividade do grupo.

Todos os ganhos de ter uma equipe menor citados acima irão gerar problemas em situações onde você tenta usar metodologias de gestão que complique as coisas ou acabem freando o time.

Aos invés disso, tenha como objetivo do time completar o ciclo: construir, medir e aprender, e em entregar sempre mais valor e menos códigos. Durante esse processo façam experimentos com metodologias diferentes e descubram juntos o modelo que melhor ajuda o time a ter fluidez e evoluir.

Conclusão

Ter membros fora da curva na equipe é, em todos os casos, o melhor cenário. Eles irão evoluir e ajudar os outros membros a evoluirem também.

Mantenha sua equipe pequena, ou formada por pequenas equipes. Isso irá trazer mais velocidade de organização, aprendizado e entrega do time.

Com uma equipe pequena de profissionais em T, você tem mais "poder" contra possíveis problemas externos e internos ou repentinos. Muitas das demandas "urgentes" poderão ser resolvidas por mais de uma pessoa. Quando houver dificuldades internas, seja com uso de ferramentas ou tecnologias, um membro poderá facilmente sanar as dúvidas do outro. Isso promove uma evolução constante de time.

Aproveite que sua equipe se movimenta rápido e é formada por pessoas multidisciplinares para aprenderem juntos o melhor modelo de gestão para o grupo, e no final do dia você terá uma equipe enxuta, que entrega valor para o negócio e para os próprios membros, num ciclo inevitável de evolução.

Muito obrigado pela leitura!

Se você gostou desse texto e acredita que ele acrescentou alguma coisa boa ao seu conhecimento, de um ❤. Isso me motiva a continuar escrevendo.

Você pode se interessar também por esses outros dois:

--

--