As Melhores e Piores Formas de Criar uma Especificação de Produto

Um dos maiores desafios que as equipas de desenvolvimento de produto enfrentam é simplesmente como decidir qual o produto a construir. No caso de equipes que trabalham a partir de uma especificação de produto, particularmente no desenvolvimento de hardware, os engenheiros normalmente não têm permissão para começar a trabalhar até que o produto seja concluído e aprovado. E dado que a maioria das linhas de tempo de desenvolvimento são incrivelmente curtas, muitas vezes não há tempo suficiente para considerar soluções alternativas uma vez que novas informações sejam vistas.

Uma maneira de olhar para este desafio é mostrada aqui. Você pode imaginar que o círculo é de todas as maneiras possíveis que a equipe poderia construir o produto. E esse pequeno ponto azul é a especificação para um produto em particular. Esta especificação de produto define exatamente em qual produto os desenvolvedores devem se concentrar e construir.

Neste post, vou primeiro descrever alguns dos métodos comuns usados para chegar a um acordo sobre uma especificação de produto. Depois vou explorar os problemas com esses métodos e como eles podem levar à construção de produtos a partir de uma especificação que não resolve realmente os problemas de seus clientes.

Devo dizer que minha perspectiva vem de 10 anos de experiência trabalhando na indústria de semicondutores analógicos e de sinais mistos, primeiro como engenheiro de aplicações e depois como definidor de produto. Agora, eu sou consultor aqui na Jama.

Worst Ways to Create a Product Specification:

Ask Your Customer What They Want You To Build

Uma maneira de começar é perguntar aos seus clientes o que eles precisam. Isto pode ser feito aguardando um pedido de cotação (RFQ) emitido pelo cliente, ou menos formalmente, através de reuniões e discussões. Normalmente o que você aprenderá com esta abordagem é que solução ou produto eles estão usando hoje e o que eles gostariam de ver mudado num futuro muito próximo. De certa forma, você está agindo como um contratante e seu cliente é responsável por todos os detalhes da especificação.

Dado que este cenário exige iteração em um produto existente, há uma grande probabilidade de você acabar com uma idéia muito específica que você definitivamente pode implementar.

No entanto, há vários problemas com esta abordagem:

• O que o seu cliente lhe está a dizer sobre a estratégia do produto que provavelmente também está a dizer à sua concorrência, e um objectivo chave do projecto é provavelmente tornar algo mais barato do que a solução existente. Você vai se encontrar em uma guerra de preços.
• O seu cliente já está a pensar num tipo de solução, baseado no que já tinha comprado antes, o que torna difícil sugerir qualquer coisa que possa satisfazer melhor as suas necessidades.
• O calendário é provavelmente extremamente agressivo, deixando poucas oportunidades para construir algo novo, ou permitindo a verdadeira inovação.
• O seu cliente pode não estar ciente de novas tecnologias, ou simplesmente não saber o que precisa.

Neste caso, você está confiando no seu cliente para traduzir seus requisitos internos em uma especificação para você, em vez de escrever requisitos para um produto que o mercado mais amplo precisa e vai comprar.

Como você desenvolve o produto, sua equipe inevitavelmente terá que fazer trade-offs por várias razões. A única maneira de ter certeza de que a melhor escolha é feita é rever as mudanças nas especificações do produto resultante com seu cliente. Se você não o fizer, então corre o risco de construir um produto que eles não aceitarão. Mas como a equipe de projeto estará sob extrema pressão para executar em um cronograma agressivo, há uma forte chance de que eles façam trocas de produtos sem todas as melhores informações. Isto aumenta ainda mais o risco de construir o produto errado.

Esta abordagem funciona na medida em que um produto é entregue. Se você está no negócio de entregar componentes de mercadorias, então isto é bom. Se você está procurando uma solução única que defenda a margem bruta, então esta não é a melhor abordagem.

PÓS-CONTRRETIDO: Como realizar uma melhor análise de impacto nas relações a montante e a jusante

2. Peça a um engenheiro que escreva a especificação completa

Outro cenário comum é aquele em que um engenheiro, ou algum outro membro da equipe voltado para o cliente, prevê uma solução baseada em conversas que teve com um ou alguns clientes. A equipe se reúne em torno desta idéia, e com um momentum interno os requisitos são rapidamente documentados e os esforços da equipe se voltam rapidamente para escrever as especificações do produto e desenvolver a solução.

Após uma solução estar completa e pronta para entrar no mercado, algumas equipes validarão sua idéia com os clientes, mas como a equipe está apresentando uma solução – não explorando uma necessidade – a discussão tende a ser em torno de detalhes nas especificações do produto. Essas equipes não terão oportunidade de descobrir se a solução está resolvendo um problema.

Tipicamente, neste cenário, os requisitos do produto vêm diretamente da cabeça de um indivíduo e são então capturados em uma longa folha de especificações, e o resto da equipe transaciona usando a especificação documentada. Sempre que a equipe se depara com um conflito onde deve ser feita uma troca, o indivíduo autor dos requisitos tem que decidir as trocas corretas de forma independente, com pouca ou nenhuma informação nova. Além disso, se essa pessoa não pesquisou nem validou os requisitos, então a equipe construirá o produto errado.

Porque estas abordagens não levam ao sucesso

O que ambas as abordagens anteriores têm em comum é que o foco está em chegar a uma especificação do produto acabado o mais rápido possível. As equipas têm tanta pressa em começar a construir algo e cumprir o prazo do cliente, que não se certificam primeiro de que o algo é o algo certo.

Além disso, o conhecimento dos requisitos existe apenas com um indivíduo na equipa. Esse indivíduo ou é a pessoa que faz a interface com o cliente patrocinador, ou é a pessoa que surgiu com a ideia do produto. Em qualquer dos casos, falta ao resto da equipa qualquer contexto para a solução, o porquê de estarem a construir este produto, e por isso não podem fazer recomendações.

O resultado é muitas vezes os produtos serem mortos mais tarde do que deveriam, depois de muito tempo e dinheiro ter sido desperdiçado, ou as equipas criarem produtos que não são bem sucedidos ou produtos que competem em grande parte no preço. Nenhum deles é bom para o negócio.

PÓS-CONTROLO RELACIONADO: 8 Do’s and Don’ts for Writing Requirements

The Best Ways to Create a Product Specification:

A melhor maneira de criar produtos que os seus clientes vão comprar é ir lá fora e falar com o seu mercado alvo muito antes de começar a escrever a sua especificação. Primeiro, você precisa articular sua declaração de problema.

Uma declaração de problema de produto são algumas frases ou parágrafos que descrevem uma necessidade do mercado. Elas são escritas a partir da perspectiva da pessoa que tem o problema e isso é crítico – não diga nada sobre como realmente resolver o problema. O objetivo desta etapa da exploração é transmitir uma compreensão do problema e uma noção do valor associado à solução do mesmo.

Uma declaração de problema geralmente é composta de três partes:

1. A primeira é a persona, ou uma descrição de quem tem o problema. É útil descrever o persona em grandes detalhes separadamente e depois fazer referência a um determinado persona na declaração do problema para evitar repetir a mesma descrição do persona.
2. Próximo é uma descrição do problema. Quanto mais detalhes, melhor aqui. Você quer ter certeza de que a necessidade é muito clara. Além disso, dê um nome ao problema. Isso torna mais fácil para as equipes se referirem a ele durante o projeto.
3. Finalmente, escreva uma descrição de quantas vezes o problema ocorre. Se o problema acontece raramente e tem baixo impacto, então resolvê-lo é de baixo valor. Se o problema acontece com freqüência e tem alto impacto, então o valor de resolvê-lo será alto.

Você pode começar perguntando aos clientes que problemas eles têm que eles acham que você pode resolver, mas você tem que cavar mais fundo para chegar às declarações de problemas verdadeiramente valiosas ou pepitas de ouro. Essas pepitas de ouro geralmente vêm do desenvolvimento de um profundo entendimento do mercado e da junção de informações de uma ampla gama de fontes.

Se você fizer isso com sucesso, acabará identificando um problema que você pode resolver e pelo qual seu cliente pagará.

Durante o processo, tenha cuidado para não encontrar falsos positivos ou negativos. Ouvir demasiado as pessoas dentro da sua empresa ou apenas um pequeno número de clientes pode levá-lo a validar falsamente ou a abandonar um problema. Fale com o máximo de clientes que puder e recolha o máximo de dados possível.

Vamos voltar ao nosso diagrama de todos os produtos possíveis que podemos construir.

Desta vez adicionamos linhas de intersecção que representam restrições. Se pensarmos nas declarações de problemas como linhas que cruzam o círculo, então uma boa declaração de problema fundamentada no entendimento do mercado irá delimitar uma área no círculo que representa todas as soluções aceitáveis. Qualquer coisa nesta área resolve o problema e seria aceitável para o cliente.

Vai notar que o tamanho desta área é muito maior do que os círculos de RFQ e de ideias de produtos anteriores. Isto porque estas declarações do problema e o contexto intencionalmente uniram a solução da forma mais solta possível para permitir que novas ideias se apresentem.

A ideia é dar à equipa de design a máxima flexibilidade na criação da solução mais inovadora possível dentro das restrições.

PÓS-CONTROLO RELACIONADO: Lista de verificação: Selecionando uma ferramenta de gerenciamento de requisitos

Como você chega a uma declaração de problema final?

Aqui estão as minhas recomendações:

1. Comece por atribuir a alguém para cada projecto a responsabilidade de ser a voz do cliente.
2. Próximo, tarefa essa pessoa com a identificação dos problemas de mercado exclusivamente baseada em informações recolhidas do mercado.
3. Certifique-se que esses problemas de mercado são documentados e partilhados num local a que toda a equipa tem acesso.
4. Enumerar uma justificação para cada declaração de problema de mercado que explique porque é um problema e como é importante resolver
5. Adicionar um marco no plano do projeto onde as declarações de problema devem ser revistas e aprovadas pela equipe junto com um caso de negócios.
6. Quando a equipe começa a desenvolver uma solução, periodicamente volta à lista de declarações de problemas para lembrar a todos qual é o alvo.
7. Para cada problema, capture uma lista das características do produto que irão resolver o problema.
8. Se algum problema não puder ser totalmente resolvido, revise novamente o caso comercial para garantir que o produto ainda seja viável.

From problem statement to specification

Agora que você tenha suas declarações de problema e a equipe tenha se familiarizado com elas, comece a desenvolver colaborativamente uma especificação do produto. Como todos na equipe compreendem o problema que está sendo resolvido, todos podem contribuir para a especificação.

Porque você fez o trabalho inicial de identificar o problema que está resolvendo, dentro das restrições identificadas, e sua equipe considerou várias maneiras de entregar a solução, você tem informações suficientes para escrever a especificação do produto.

Lançamento da especificação do produto em pequenos lotes

A melhor abordagem aqui é lançar pequenos pedaços da especificação para a equipe o mais cedo possível para obter feedback rápido. Isto ajudará a evitar a perda de tempo no caminho errado e tornará muito mais fácil para a equipe fornecer feedback de alta qualidade.

Não está convencido? Considere isto: O que acontece se você receber uma folha de especificações de 200 páginas para revisar? Você provavelmente olhará para as primeiras páginas e depois escumará o resto.

Agora, o que acontece se você receber um documento de uma página? Provavelmente você revisa tudo. Duzentos documentos de uma página resultarão num feedback muito melhor do que um único documento de 200 páginas.

Referir à Declaração de Problemas para garantir que você está no caminho certo

Também, enquanto você desenvolve a especificação, verifique novamente para ter certeza de que o produto ainda é uma solução válida para o problema. É fácil ficar preso ao trade-off inerente ao desenvolvimento de um produto e esquecer de verificar e ver se você ainda está no alvo.

Esta abordagem também gerencia as expectativas de seus interessados. Como o processo é controlado, há uma estrutura e transparência que impede que qualquer pessoa tome decisões superiores. Em qualquer ponto do projeto, você será capaz de explicar exatamente que valor seu produto oferece e porque ele precisa ter as características que a equipe especificou.

Designing Products to Market Needs is Critical to Success

Eu reconheço que em alguns setores esta é uma grande mudança de como os produtos foram projetados e construídos. Mas à medida que os mercados se tornam mais competitivos, e os produtos se tornam cada vez mais complexos, apenas fornecer mais uma iteração de algo que você construiu antes não vai mantê-lo no negócio por muito tempo.

Para saber mais sobre como escrever requisitos de uma maneira que todos os interessados tenham um claro entendimento das necessidades de desenvolvimento, baixe nosso eBook, Melhores Práticas para Escrever Requisitos.

LER O EBOOOK