A prototipagem rápida pode ser uma ferramenta útil para nós, enquanto gestores de projetos digitais, ajudarmos os clientes que fazem a pergunta: ‘Mas isto vai funcionar?’ e ‘Como é que isto vai funcionar?’ Muitas vezes, a resposta simples, mas frustrante, é simplesmente: ‘Ainda não sabemos – mas podemos ajudá-lo a descobrir.’ Uma excelente forma de o descobrir, cada vez mais popular entre agências e clientes, é através da prototipagem rápida — investir pouco para tomar uma decisão informada sobre a viabilidade do produto antes de realizar grandes investimentos.
A nossa indústria move-se à velocidade da luz e, enquanto gestores de projetos digitais, temos de nos adaptar rapidamente a novas formas de trabalhar. Um exemplo atual disso é a prototipagem rápida. Há nove meses, nunca tinha trabalhado num projeto de prototipagem rápida e agora acabei de concluir o meu quarto projeto de prototipagem rápida para testar rapidamente a viabilidade de um produto. Por isso, se ainda não trabalhou num projeto de prototipagem rápida, não tenho dúvidas de que um está mesmo ao virar da esquina.
Esta publicação explica diferentes formas de explorar a viabilidade de um produto e fornecer-lhe-á alguns princípios orientadores para o ajudar a gerir com confiança projetos digitais ou analógicos em rápida evolução.
Mas primeiro, o que é a prototipagem rápida?
A prototipagem rápida refere-se ao processo aplicado à criação de uma prova de conceito ou de protótipos rápidos. Um protótipo é útil para testar a validade de um conceito. Permitir-lhe-á desenvolver mais funcionalidades, mais rapidamente, mas normalmente isso acontece à custa da qualidade e, por esse motivo, o produto será, na sua maioria, descartável.
Os protótipos existem em diferentes formas e dimensões
Embora existam várias formas de explorar a viabilidade de um produto, apresentamos três abordagens distintas:
- Prova de conceito – Uma prova de conceito é uma demonstração muito simples e descartável do produto, destinada a testar a ideia subjacente ao produto antes de o criar.
- Protótipo rápido – Um protótipo rápido é uma primeira versão simples do produto que pode ser testada com utilizadores reais para obter mais confiança no produto antes da sua construção completa.
- Produto mínimo viável (MVP) – Um MVP é a primeira versão do produto com qualidade de produção, desenvolvendo funcionalidades totalmente operacionais para os utilizadores.
A sua confiança no produto deve ser o principal fator de decisão para determinar qual a abordagem a seguir.
Quanto mais arriscada for a ideia = mais rapidamente deve avançar.
Algumas pessoas poderão dizer que, se uma ideia é arriscada, deve passar mais tempo a pensar nela antes de a desenvolver. De certa forma, têm razão. É possível validar uma necessidade quase sem construir nada. Existem inúmeros exemplos de testes de validação que vale a pena investigar.
No entanto, quando sabe que existe uma necessidade, a única forma de provar essa necessidade é construir algo, lançá-lo o mais rapidamente possível na sua forma mais rudimentar, obter feedback e iterar. Descobrimos inúmeras vezes que, quando se está a investigar uma ideia, o cliente acaba inevitavelmente por dizer “Eu compraria isso” e, depois, quando o produto é lançado, as vendas não aumentam.
“Eu compraria definitivamente isso” – 100 pessoas
Pessoas que o comprarão efetivamente = 10
Jeff Sheldon (@ugmonk) September 1, 2016
A prototipagem rápida reduz o risco em todas as ocasiões, encurtando o ciclo de feedback e garantindo que está a construir um produto que será vendido.
Como saber qual é a opção certa para si
| Estilo de prototipagem | Confiança | Quão fictício | Quão descartável |
|---|---|---|---|
| Prova de conceito | Baixa | Completamente | Completamente |
| Protótipo rápido | Média | Parcialmente | Parcialmente |
| Produto mínimo viável | Alta | Muito pouco/nenhum | Construído para durar |
Para construir coisas rapidamente, tem de estar aberto ao desenvolvimento de novos processos e formas de trabalhar.
Princípios orientadores para gerir projetos de prototipagem rápida
Trabalhar das formas descritas abaixo exige uma nova mentalidade. Recomendo começar o seu projeto com uma reunião interna de arranque para analisar estes princípios e explicar por que motivo são importantes. Isto ajudará a garantir que toda a equipa está alinhada desde o início, sabe o que se espera de cada elemento e está ciente de onde e por que motivo o projeto poderá ser diferente daquilo a que está habituada.
1. Esteja preparado para fazer menos
Provavelmente, isto significará menos planeamento inicial do que aquele a que está habituado e incluirá sentir-se confortável com:
- Critérios de aceitação inexistentes ou mínimos
- Sem subtarefas nas histórias
- Sem estimativas
O que perde num processo rígido, ganha em rapidez, confiança e comunicação. Aceite a falta de controlo.
Este princípio irá lembrar toda a equipa de que não há problema em abandonar processos conhecidos em prol de entregar software funcional mais cedo. É bom perguntar regularmente a si próprio e à equipa: «é esta a forma mais rápida de fazer x?».
2. Mostre, não diga
Como está a fazer menos planeamento inicial, irá falar e desenhar mais durante o desenvolvimento. Poderá querer prolongar as suas reuniões diárias para poder falar um pouco mais detalhadamente sobre a funcionalidade antes de a sua equipa começar a desenvolvê-la nesse dia. Como diz o ditado, uma imagem vale mais do que mil palavras. Por vezes, um esboço da página, um modelo de conteúdo ou um diagrama que mostre como o sistema será desenvolvido é suficiente para começar a construir e, depois, poderá iterar a partir daí.
Este princípio irá incutir confiança em si e no cliente; todos gostam de ver o progresso e mostrar o trabalho regularmente cria a oportunidade de obter feedback atempado, minimizando assim o desperdício.
3. Peça perdão, não autorização
Na maioria dos processos rigorosos de desenvolvimento de software, o consenso é fundamental. Quer que o proprietário do produto aprove formalmente os critérios de aceitação e, enquanto gestor de projeto, quer saber que a sua equipa compreendeu os requisitos antes de escrever uma linha de código.
Com protótipos rápidos, é importante que a sua equipa se sinta capacitada para simplesmente desenvolver a solução com base no melhor entendimento que tem naquele momento, mostrar o trabalho o mais rapidamente possível, obter feedback e iterar.
Obter consenso desde o início irá atrasar as coisas e raramente há desperdício de trabalho se a equipa mostrar aquilo em que está a trabalhar desde cedo e com frequência.
Este princípio é particularmente útil para os programadores, pois coloca sobre eles a responsabilidade de conceber inicialmente a arquitetura e desenvolver uma funcionalidade com pouca influência externa. Muitas vezes desenvolvemos demasiado e complicamos excessivamente as coisas porque nem sempre vemos a complexidade técnica envolvida nos nossos pedidos. Por isso, confiar nos programadores da equipa para decidirem qual é a implementação mais básica e começarem por desenvolvê-la é uma excelente forma de avançar.
Para que isto funcione, é essencial que os seus programadores tenham uma compreensão profunda do projeto, para que sejam capazes de tomar as decisões certas para o projeto e desenvolvam sempre apenas o suficiente .

4. Incentive sempre a equipa a mostrar aquilo em que está a trabalhar (mesmo que seja feio)
Este processo é inspirado nos princípios de prototipagem dos Serviços Digitais do Governo.
Normalmente, só mostramos as funcionalidades aos clientes quando estão concluídas. Em projetos de prototipagem rápida, é importante mostrá-las assim que estiverem funcionais, para poder minimizar o desperdício, iterar e mudar de direção, se necessário.
Faça funcionar. Mostre a coisa.
Embeleze-a. Mostre a coisa.
Faça-a escalar. Mostre a coisa.
Este princípio liberta os membros da equipa da sensação de que só devem mostrar o trabalho depois de este ter sido revisto por um designer ou totalmente testado. Celebre o trabalho em curso.
5. Prefira processos físicos aos processos online
Nas palavras de Brett Harned, gerimos projetos com a nossa mente, não com as nossas ferramentas. Não tenha medo de abandonar as suas ferramentas de gestão de projetos. Visualize o trabalho, utilize um backlog físico, coloque esboços, fluxos de utilizador e personas na parede e reúna-se à volta dela. Consulte-a frequentemente e incentive as pessoas a assumirem a responsabilidade de mover os cartões e celebrar a implementação de novas funcionalidades. Se o seu cliente não estiver no mesmo local, fotografe tudo e partilhe no Slack, para que não fique de fora.
Experimentar um novo processo pode ser complicado; é provável que visualizar o trabalho suscite conversas que não aconteceriam se estivesse no Hangouts a olhar para um quadro digital. Rapidamente se tornará evidente se um cartão físico não tiver sido movido durante um dia ou se houver demasiado trabalho em curso. A utilização de processos físicos proporciona uma camada adicional de transparência pela qual, acredite em mim, quando tudo parece confuso, ficará eternamente grato.
6. Sejam excelentes uns com os outros
É natural sentir-se assoberbado quando está a tentar implementar um novo processo e uma nova forma de trabalhar, especialmente quando também é novo para si. Ainda assim, lidere com confiança e incentive a equipa quando estiver a ter dificuldades. Ouça atentamente as suas preocupações e esteja disposto a ajustar o processo à medida que avança. Certifique-se de que o processo não está a colocar pressão adicional sobre a sua equipa; a prototipagem rápida consiste em trabalhar de forma mais inteligente, não mais arduamente.
Dependendo das personalidades da sua equipa, alguns membros irão aceitar esta nova forma de trabalhar, enquanto outros poderão resistir-lhe. Todos aprendemos a ritmos diferentes e cada disciplina enfrentará desafios diferentes ao adaptar-se a uma nova forma de trabalhar. Enquanto gestor de projeto, mantenha-se consciente disso e procure criar um ambiente de apoio e segurança para a equipa – sentem-se juntos, bebam chá e verifiquem regularmente como está toda a gente.
7. Minimize as distrações
Por vezes, é difícil saber, enquanto gestor de projeto, onde pode fazer cedências num novo processo e onde deve manter-se firme. No que diz respeito à aceitação de novas alterações a meio de uma iteração, continue a resistir e a dizer que não. É importante que, quando uma iteração começa, a sua equipa não seja perturbada; proteger o tempo da equipa é a coisa mais valiosa que pode fazer.
Este princípio dá à equipa autonomia para recusar pedidos. É provável que esteja a trabalhar em iterações de uma semana e, com uma janela de tempo tão curta, não pode dar-se ao luxo de perder tempo. Obtenha o apoio do resto da empresa para que as pessoas se sintam à vontade para adiar reuniões internas ou responsabilidades adicionais, de modo a poderem concentrar-se durante esse período.
Como tirar partido da prototipagem rápida
Considerei esta nova abordagem ao trabalho extremamente gratificante; por vezes, pareceu caótica, desorganizada e fora de controlo. É difícil saber onde e até que ponto se deve desviar do processo atual, mas encorajo-o a experimentar, a falhar rapidamente e a ser transparente com a sua equipa relativamente ao que precisa dela.
Em algumas ocasiões, removemos uma parte essencial do processo e restabelecemo-la mais tarde, porque se tornou evidente que eu estava a ter dificuldades em gerir o projeto sem ela. Nestas fases do projeto, certifiquei-me de que conseguia explicar claramente ao resto da equipa as consequências da remoção desse processo. Enquanto equipa, discutiríamos se existia uma forma alternativa de obter essa informação; se não conseguíssemos encontrar uma solução melhor, restabeleceríamos o processo. É em momentos como este que colhemos os benefícios de construir um ambiente de apoio, baseado na confiança e no respeito mútuos. Em todos os momentos, aprendemos, iteramos e avançamos enquanto equipa.
Créditos a Chris Thorpe por estes princípios; tudo o que sei devo-lhe.
