Agilidade e alinhamento com desenvolvedores no processo de solução

Publicado por Lucas André de Alencar no dia dev

Já pensou em colocar seus/suas desenvolvedores/as para participar do processo de solução do seu produto ou serviço? Aqui na RD já tivemos essa experiência. Eu fui cobaia nesse experimento inclusive.

I have no idea what I'am doing

Nesse post quero compartilhar vários dos aprendizados desse experimento e mostrar o que você está perdendo enquanto seus devs estão apenas codando o seu produto.

Não tenha medo

Existem várias falsas verdades e receios que impedem que empresas incentivem seus/suas devs a participarem do processo de solução. Por exemplo: medo de desperdiçar dinheiro, já que o/a dev não está digitando na frente de uma tela preta no computador; medo de brainstormings infinitos; medo de devs tomando decisões erradas no meio do caminho, dentre outros.

Olhando para trás e observando o processo como um todo, meu primeiro conselho é: não tenha medo. Porque uma coisa é certa: o pior inimigo dentro de times de desenvolvimento é a falta de alinhamento e comunicação entre seus membros. Ao envolver mais os/as desenvolvedores/as na solução, menores serão os gaps de comunicação dentro do time.

Devs podem te ajudar SIM durante a solução

Ainda assim, você deve estar pensando: “mas como os/as devs me ajudarão durante o processo de solução, já que eles/as só sabem codar e reclamar do próprio código?” Uma coisa que percebemos durante nossa imersão no processo é que sempre existirão oportunidades no qual conhecimentos técnico de um/a dev ajudará o time a alcançar melhores resultados. Essas oportunidades vão desde necessidades de extração de dados para análise até estimativas de tempo de uma atividade.

No final do dia, devs adoram desafios e uma tarefa diferente é sempre bem vinda para nos tirar da zona de conforto. Por isso, não tenha medo de passar tarefas que não sejam programação para os/as desenvolvedores/as.

Durante o processo de solução, nós, devs, fizemos benchmarking de outros produtos do mercado e levantamos vários insights quantitativos e qualitativos que direcionaram as discussões de solução. Atividades pouco relacionadas com programação, mas que mesmo assim nos deixaram empolgados em fazê-las. Afinal, tínhamos certeza que no final essas contribuições impactariam positivamente a vida de nossos/as clientes.

Devs podem te ajudar sim!

Traga o seu brainstorm de casa

Contudo, ainda é possível que alguns brainstormings arrastem-se por mais tempo do que o necessário. Por isso, uma recomendação que temos para evitar discussões que levam horas e horas para se concluir é: traga o seu brainstorm de casa.

Inicie o desenho da solução com uma ideia vaga do direcionamento, baseado em análises que o time realizou. No entanto, evite trazer um desenho com todos os detalhes já definidos. Isso desestimulará a discussão e não dará espaço para a solução evoluir.

Consequentemente, a impressão do time é de que a reunião não serviu para nada, já que tudo estava definido antes mesmo dela começar. Por causa disso, é muito importante manter o equilíbrio entre direcionamento e detalhamento durante processos de brainstorming.

Uma vantagem evidente de envolver os/as devs nessas discussões foi quando percebemos que a solução final não era “viciada”, pois a diversidade de pensamentos durante o brainstorming trouxe questionamentos que um/a PM ou designer raramente teriam levantado caso estivessem desenhando sozinhos/as a solução.

Facilidade no (re)planejamento

Outro ganho colateral de envolver devs no processo de ideação é a melhor capacidade de antever desafios técnicos dentro do produto. Isso facilita o planejamento e as estimativas das tarefas no decorrer do desenvolvimento e simplifica o processo de priorização.

Devs podem antecipar problemas que só seriam identificados tarde demais. Essa capacidade evita retrabalhos e atrasos que normalmente acontecem por questões de desalinhamento no time.

Claro, sempre existirão erros no planejamento (nós erramos várias vezes!), mas como todos os membros do time estavam bem alinhados, o replanejamento também se tornou mais ágil e simples. Situações de corte de escopo ou mudança no direcionamento de uma tarefa, que normalmente são complexas, foram realizadas sem muita dificuldade.

Mais agilidade e menos entraves

Por fim, devs ficarão mais confortáveis para questionar decisões de design e sugerir mudanças durante o desenvolvimento. Na prática, o/a designer é bombardeado com dúvidas de devs sobre pontos específicos da solução: o que ajuda a enriquecê-la ainda mais.

A implicação direta disso é que os/as designers ou PMs não precisam necessariamente tomar todas as decisões de antemão. Como o/a dev participou do desenho da solução e trouxe inputs para o direcionamento dela, isso permite que pequenas decisões sejam tomadas pelo time durante o processo de desenvolvimento. Afinal, é muito comum surgirem dúvidas e barreiras durante o desenvolvimento, forçando algumas mudanças na solução que havia sido previamente proposta.

Por isso, empodere os/as devs a tomarem decisões durante o desenvolvimento e confie na visão deles/as (eles/as passaram pelo mesmo processo de ideação que você!). Esse empoderamento também os/as tornará mais motivados/as, pois eles/as se sentirão donos/as da solução que estão implementando - e não apenas como “peões” sem poder de decisão.

Além de trazer mais confiança, isso diminuirá a quantidade de questionamentos desnecessários durante o desenvolvimento. Os questionamentos que inevitavelmente surgirão serão extremamente relevantes, pois o/a dev entende os porquês das decisões que foram tomadas.

Não tenha medo

A mensagem final que deixo é: não tenha medo de experimentar. O meu envolvimento no processo de solução foi algo renovador e me proporcionou uma experiência muito interessante em minha carreira.

E não, você não vai perder dinheiro e nem tempo com esse experimento. Quanto mais devs entenderem sobre interface e usabilidade, melhor será a experiência dos seus clientes e o produto final.


Alguma vez já teve uma experiência parecida? Gostaria muito de ouvir como foi! Se quiser saber mais como desenvolvemos o nosso produto (RD Station), você pode encontrar mais informações nesse webinar ministrado pelo Bruno Ghisi.

Lucas André de Alencar

Lucas André de Alencar

Full Stack Developer

Comentários