Os requisitos são superestimados?

Por que não escrevo longas especificações.

Benny Reich Blocked Desbloquear Seguir Seguindo 28 de dezembro

De Cachoeira a Ágil

Na idade das trevas nós todos trabalhamos em cascata. Nós planejamos tudo com meses de antecedência. Tivemos que escrever requisitos detalhados com antecedência, revisá-los e planejar adequadamente. Resultou em reação lenta a mudanças e muitos requisitos obsoletos.

Com a mudança para o ágil e a preferência do software em funcionamento por meio de uma documentação abrangente (veja o manifesto ágil ), há menos demanda por especificações tão longas. No entanto, ainda acho que muitos gerentes de produto escrevem muito mais do que o necessário (e ainda ouço o termo PRD muitas vezes).

Eu gostaria de explicar porque eu acho que não é apenas um desperdício de tempo valioso, mas também porque na verdade isso resulta em um produto menor.

Seu tempo é valioso

Não há dúvida de que você precisa escrever requisitos que sejam claros para desenvolvedores e controle de qualidade. Mas você realmente precisa escrevê-los por tanto tempo?

Você está se certificando de escrever mais sobre o problema e a necessidade do cliente e como você quer medir o sucesso e menos sobre a solução em si?

Você realmente precisa entrar em cada caso de erro em vez de confiar na equipe de desenvolvimento para lidar com isso?

Cada minuto que você gasta para aperfeiçoar os detalhes de uma solução para um problema que você já sabe que precisa resolver, é um tempo que você não gasta tentando encontrar o próximo. É um tempo que não se passa no quadro geral, na estratégia ou na conversa com os clientes.

Gastar o mínimo possível para escrever os requisitos. Escrevê-los tão curto quanto você acha que seus desenvolvedores de pares e controle de qualidade precisaria compreendê-los. Eu até argumentaria que, se você sabe quem vai trabalhar na implementação, adapte-as a quão bem você acha que elas podem trabalhar especificamente com “buracos”.

Mais sobre isso em Faça-se "Redundante" e seu papel não é para escrever requisitos .

Criativos inteligentes

Em Como o Google funciona, Eric Schmidt e Jonathan Rosenberg denominaram “Criativos inteligentes” como funcionários da era da informação que estão focados na solução de problemas. Espero que você esteja trabalhando com essas pessoas (se sua equipe de desenvolvimento for terceirizada, o que eu escrevo abaixo pode não ser relevante e você pode precisar escrever requisitos mais longos e detalhados).

Para este tipo de desenvolvedores, se você está escrevendo muitos detalhes e fechando todos os buracos, você está realmente privando-os de sua criatividade. Os desenvolvedores querem pensar. Eles não querem apenas receber pedidos e implementá-los. Escrevendo muitos detalhes, você está realmente obtendo desenvolvedores menos motivados (e não me faça começar a falar sobre o fato de que a maioria deles não está lendo o que você escreve).

E você está perdendo outra coisa. Você está perdendo mais perspectivas sobre o mesmo problema e talvez algumas idéias inovadoras que você não pensou. Isso também é verdade para trabalhar com especialistas em UX. Deixe-lhes espaço suficiente para manobrar e expressar sua criatividade e pensamento.

Você pode argumentar que isso pode ser feito na fase de descoberta, na qual você pode envolver todo mundo, e então escrever as descobertas. A verdade é que, enquanto você definitivamente deveria envolver os desenvolvedores na fase de descoberta e obter sua opinião, eles normalmente não seriam envolvidos, bem como quando realmente trabalham no problema. Deixe algumas pontas soltas. Eles irão surpreendê-lo.

Escalonamento de Compromissos

Outro problema em investir muito na fase de definição é que você pode se apegar demais à solução. Isso torna mais difícil desistir das coisas quando você descobre que é a solução errada ou que o escopo que você tinha em mente é muito grande e você precisa fazer alguns cortes (veja também Sempre pensa em MVP ).

Esse comportamento é chamado de escalonamento de compromisso. É um padrão de comportamento humano em que um indivíduo ou grupo que enfrenta resultados cada vez mais negativos de alguma decisão, ação ou investimento, no entanto, continua o mesmo comportamento em vez de alterar o curso.

Resumo

Escrever especificações e requisitos deve ser uma tarefa mínima. Você deve escrever o mínimo possível sobre a solução e o máximo possível sobre o problema. Guarde apenas as coisas que você precisa para ter certeza de que a solução está respondendo à necessidade e não tenha contradições. Não escreva os detalhes que você acha que sua equipe de desenvolvimento pode entender por si mesmos e pode até encontrar melhores resultados.

Todo mundo ganha. Você ganha mais tempo para a estratégia ou apenas para trabalhar menos e a equipe de desenvolvimento fica mais motivada e investida na solução do problema e em novas ideias.

Menos é melhor que mais