Protótipos em papel

Como a prototipação deixou minha equipe mais ágil para desenvolver software

Qual desenvolvedor de software não teve problemas ao tentar entender o que o cliente quer e então desenvolver um software que gere valor. Nesse post vou mostrar como a prototipação de baixa fidelidade deixou minha equipe mais ágil e ajudou a gerar uma linguagem compartilhada entre a minha equipe e as demais áreas da organização.

 

O dilema da comunicação

Depois de 7 anos trabalhando com desenvolvimento de software, eu afirmo que há uma grande dificuldade por parte dos desenvolvedores entenderem as necessidades do cliente e transformar isso em um produtos que os clientes querem, ou poderia dizer também que há uma grande dificuldade dos clientes expressarem suas necessidades. Mas prefiro puxar essa questão para quem oferece uma solução para um problema, no meu contexto de trabalho os desenvolvedores.

Isso acontece ao meu ver pelos modelos de comunicação e ferramentas que são adotadas. Para empresas que praticam processos em cascata, que possuem processos bem rígidos isso se amplifica exponencialmente.

Eu já gastei muitas horas em reuniões que duravam horas e então se resumiam em documentos de requisitos de software que por fim ninguém lê, ou quando lê não entende, ou ainda entende algo diferente do que a pessoa que escreveu queria que fosse entendido. E no fim de tudo vem aquela frase: “Não é bem isso que eu tinha imaginado!” .

 

“Não perca tempo desenvolvendo longos documentos de requisitos de software que ninguém vai ler”

 

Mesmo que o cliente entendesse o documento e estivesse de acordo, muitas dúvidas em relação ao produto que seria criado surgia, dos mais variados tipos. Desde aparência até detalhes da lógica do sistema. Isso porque ler sobre um software não é o mesmo que usar um ou ver um funcionando.

 

Da documentação para a prototipação

Frequentemente eu ficava frustrado e me perguntando em como melhorar o nosso processo de desenvolvimento fazendo com que as expectativas dos clientes fossem completamente satisfeitas.  Já usamos práticas ágeis para desenvolver, mas essa questão de requisitos e necessidades ainda me assombrava com longas documentações e outras coisas que são de uma cultura difícil de mudar em organizações já estabelecidas.

Depois de pesquisar em vários lugares e métodos, me identifiquei muito com a forma que Eric Ries no livro Lean Startup e TIm Brown no Design Thiking conduzem a solução de problemas e criação de produtos e serviços. E então tomei uma decisão mais radical ( dada a minha realidade é claro). Abandonar toda e qualquer documentação de necessidades e requisitos de software e provocar o entendimento do cliente através da prototipação.

 

“A prototipação é a atividade de construir modelos de estudo, rápidos e simples com o objetivo de explorar alternativas da sua ideia e dar forma a sua proposta de valor.”

 

Conforme a explicação acima e também no post que escrevi sobre o Value Proposition Design, há três tipos de protótipos, os de baixa, média e alta fidelidade.

Resolvi adotar os protótipos de baixa fidelidade para captar a ideias dos clientes e criar uma linguagem comum entre a equipe de desenvolvedores e as áreas de negócio da empresa.

 

Nada mais que papel e caneta

 

A forma que encontrei para melhorar o entendimento entre as áreas de negócio e desenvolvedores foi desenhar o sistema de forma bem simples com papel e caneta. Simples não ? Pois é, e o resultado foi fantástico.

Em resumo agora nós fazemos um brainstorm com os envolvidos no processo e desse encontro alguém da equipe de desenvolvimento desenha de fato em um papel cada tela do sistema e apresenta como vai ser o funcionamento do sistema e todos se reúnem novamente para alinhas as expectativas e prazos. Foi a primeira vez que vi um entendimento claro entre o que se esperava e o que foi entregue.

Listo abaixo os benefícios que a minha equipe obteve ao começar a usar a prototipação em papel dos sistemas:

 

  • É rápido e de baixo custo
  • Eliminou as dúvidas de como seria a interface do software
  • Por desenhar em papel, focamos no processo macro e omitimos os detalhes, isso ajuda a focar no que realmente importa ao invés de se preocupar com a cor de um botão por exemplo.
  • Para a própria equipe de desenvolvimento fica mais claro a quantidade de esforço para desenvolver, já que mesmo de forma grosseira conseguimos ver todo o software.
  • O desenvolvedor já vai refletindo antes de programar como será o software de forma mais tangível
  • No caso da equipe ter entendido errado alguma coisa, o próprio cliente pode pegar a caneta e alterar no papel ou mesmo desenhar como imaginou.
  • Outro fator importante é que ninguém gosta de ficar escrevendo longas documentações que por sinal são muito chatas.

 

Abaixo segue um exemplo para mostrar o quanto é simples:

Prototipação de software em papel

Exemplo de software protipado com papel e caneta

Até mesmo os executivos da empresa que estão mais acostumados com documentações e coisas mais formais gostaram da nova abordagem e acharam mais clara e tangível. Já estamos fazendo dessa forma a 8 meses em diversos projetos e realmente ajudou a criar uma linguagem compartilhada entre desenvolvedores e área de negócios.

Claro que existem diversas ferramentas para prototipação muito eficientes, mas eu quis focar na seguinte pergunta: Qual a maneira mais rápida e que exige o menor esforço possível para que eu mostre ao clientes como será o software a ser desenvolvido ? E convenhamos, acredito que nenhuma ferramenta vai ser mais rápida que papel e caneta.

O único ponto que quero ressaltar é que na minha equipe temos o desenvolvimento de um ERP, ou seja um produto com pouca variação de interface e detalhes visuais expressivos, seguimos um guia de estilo. Para o design de sites ou aplicativos com um forte apelo visual, a prototipação em papel também ajuda, mas depois é necessário evoluir o protótipo para algo de média ou alta fidelidade que seriam ferramentas mais sofisticadas.

Para encerrar, digitalizamos os papéis desenhados e anexamos de forma bem simples em nosso software de gerenciamento dos projetos.

Aqui eu só quis dar uma compartilhada em como deixar de documentar sistemas em longos textos para prototipá-los melhorou o processo de desenvolvimento da minha equipe. Mas deixo abaixo duas ótimas referências de leitura que encontrei e que possuem outras referências:

 

Referências:

Lean UX – Jeff Gothelf with Josh Seiden

http://dextra.com.br/prototipacao-e-sua-importancia-no-desenvolvimento-de-software/

http://thiagonasc.com/desenvolvimento-web/a-importancia-dos-prototipos-no-desenvolvimento-de-sistemas

 

E você como captura os requisitos para desenvolver um software ?