Olá Habr!
Hoje, queremos falar sobre como nossa equipe de produtos aborda a preparação de requisitos funcionais para desenvolvedores ao criar novos produtos e recursos.
No estágio de desenvolvimento, muitas surpresas podem surgir, especialmente se a tarefa não estiver claramente descrita. Diferentes membros da equipe podem entender o desenvolvimento e o funcionamento do mesmo recurso de maneiras diferentes, de modo que os gerentes de produto são responsáveis por criar um produto desde o desenvolvimento do conceito até a versão final. E uma parte importante desse processo é a preparação de requisitos funcionais.
A questão de descrever tarefas para desenvolvedores que já abordamos no artigo
Como os gerentes aprendem a definir tarefas para desenvolvedores , mas falamos mais sobre questões administrativas e hoje falaremos mais sobre questões técnicas. Este é um componente extremamente importante em qualquer empresa cujas vendas sejam realizadas pela Internet. Cada empresa que está se desenvolvendo ativamente no ambiente da Internet se transforma em um negócio de software. Mas, apesar disso, as competências no campo do gerenciamento de requisitos tendem a crescer muito lentamente.
Como resultado, muitas vezes vemos a mesma imagem: tarefas de diferentes departamentos entram constantemente no departamento de desenvolvimento, os requisitos nessas tarefas são descritos vagamente e, assim que algo é colocado em ação, ele retorna imediatamente para revisão (porque o diretor não descreveu completamente o que eu queria e o desenvolvedor fez o que quisesse). O resultado é óbvio: prazos imprevisíveis para tarefas que podem levar meses, uma equipe desmotivada, tensões dentro da equipe, clientes insatisfeitos, ficando para trás dos concorrentes e assim por diante.
Com este artigo, queremos dar uma receita simples que estabelecerá as bases para a solução desses problemas. Pode ser recomendado com segurança para estudo (além disso, para ação) para todos aqueles que definem tarefas.
Empresas diferentes têm abordagens diferentes para escrever requisitos funcionais, mas no
Retail Rocket decidimos por essa opção e até agora não temos arrependimentos.
Requisitos funcionais: o que é e por que são necessários
Primeiro, vamos ver o que são requisitos funcionais.
Requisitos funcionais - esta é a declaração do problema para o desenvolvedor. Tudo o que não é indicado nos requisitos é feito a critério do desenvolvedor, que muitas vezes diverge da apresentação do gerente de produto sobre o resultado esperado. Portanto, os requisitos devem conter respostas para todas as perguntas possíveis na tarefa.
Os requisitos funcionais geralmente consistem em:
- História do usuário - mostra o que você espera da equipe de desenvolvimento
- Casos de uso - mostrar cenários de uso
- Wireframes - uma ferramenta de visualização para sua ideia
Hoje vamos nos concentrar na história do usuário e nos casos de uso.
História do usuário
A história do usuário descreve o que o usuário faz em uma determinada função para obter o resultado e o que o desenvolvedor precisa fazer para dar vida a essa tarefa.
Normalmente, um modelo é usado:
Como <Nome da função>, eu quero <Finalidade, Ação>, para que <Resultado esperado> faça <O que o desenvolvedor deve fazer>Existem vários exemplos da aplicação desta metodologia. Por exemplo, é assim que
funciona no Trello:
No Retail Rocket, criamos histórias de usuário no Google Docs usando tabelas. Isso ajuda a simplificar o processo de comunicação entre equipes diferentes, pois todos podem deixar comentários e dar feedback.
Por exemplo, é assim que a tarefa de rastreamento do NPS para uma loja online se parece:
Graças a essa visualização da interação, a tarefa do usuário passa suave e logicamente para os desenvolvedores. Depois, chega a vez dos casos de uso.
Casos de uso
Os casos de uso descrevem o comportamento do usuário passo a passo ao interagir com um produto desenvolvido.
A tarefa do usuário é o que o usuário faz para atingir objetivos de curto prazo.
Se o usuário resolver o problema na página desenvolvida de várias maneiras, cada solução deverá ter seu próprio caso de uso escrito. Por exemplo, se o acesso à funcionalidade afetada estiver localizado em várias páginas, você precisará escrever um caso de uso separado para cada maneira que o usuário alternar para a funcional.
Vejamos um exemplo do nosso recurso lançado recentemente -
Galeria de imagens e fontes para mala direta.
O objetivo do usuário é armazenar imagens em nossa plataforma e usá-las para criar campanhas de email.
Tarefas do usuário:
- Carregar imagens
- Incorporar imagens em um modelo de carta
- Excluir imagens
Para cada tarefa, você precisa escrever seu próprio caso de uso - uma descrição de como o usuário interage com a interface.
Exemplos de casos de uso:Upload de imagem:
- O comerciante do email entra em sua conta pessoal do foguete de varejo
- Email Marketer Abre a Seção Galeria
- O profissional de marketing por e-mail envia imagens por meio de arrastar e soltar ou clicando no botão "Selecionar arquivos"
- As imagens são carregadas
- Usuário vê notificação de upload bem-sucedido de imagens
Excluir imagens:
- Usuário clica na imagem
- Imagem se destaca
- A seleção pode ser removida clicando na área fora da imagem selecionada.
- O usuário clica no ícone de três pontos
- Um menu de contexto é exibido.
- O usuário seleciona o link "Excluir arquivo". Se várias imagens foram selecionadas, todas serão excluídas.
- A imagem é excluída
Todos os cenários de uso são pintados da mesma maneira, o que fornece ao desenvolvimento uma compreensão clara da aparência da interação do usuário com o produto ou recursos e o que precisa ser feito para isso.
Por que os requisitos funcionais são tão importantes
Usando esse formato de requisitos funcionais, você fornece à equipe de desenvolvimento instruções claras. Além disso, você pode mostrar como a interface fica do lado do cliente e como resolve suas tarefas. Essa abordagem ajuda a apresentar sua ideia e evitar mal-entendidos na equipe.
Normalmente, a formulação do problema para os desenvolvedores oferece muitas perguntas, cujas respostas dependem da complexidade e do momento da implementação. Para esclarecer os detalhes, eles precisam dedicar tempo à comunicação, e não ao trabalho direto - criando recursos interessantes e melhorando o produto. E mesmo no processo de comunicação, todas as sutilezas nem sempre são esclarecidas se o diretor da tarefa responder apenas às perguntas que surgem, mas o usuário não segue o caminho.
Veja o exemplo da nossa galeria. Se o gerente de produto tivesse a tarefa de criar uma galeria, em um ponto sobre exclusão de arquivo, os desenvolvedores teriam que esclarecer:
- Preciso excluir o arquivo?
- Será uma exclusão manual ou os arquivos mais antigos serão excluídos automaticamente quando novos arquivos forem baixados, se o limite de armazenamento for excedido?
- é a remoção da lista de arquivos ou você precisa abrir o arquivo?
- o arquivo é excluído permanentemente ou existe uma cesta de arquivos onde eles são armazenados por algum tempo? se você precisar de uma cesta, quantos arquivos estão armazenados nela?
- deve haver exclusão de arquivo em lote ou apenas um pode ser excluído?
- o arquivo é excluído usando um ícone separado (como é esse ícone?) ou por meio de um item de menu (como será chamado? onde está localizado na lista de ações?)
- etc.
E, afinal, esse é apenas um dos pontos da tarefa, e já existem muitas perguntas. E descobrir cada um deles exige tempo e esforço de ambos os lados.
Os requisitos funcionais ajudam o gerente de produto a refletir e a formular claramente todos os cenários de interação do usuário a partir de interfaces da tarefa.
Quanto mais precisamente a tarefa é colocada e quanto mais detalhes os desenvolvedores tiverem antes de iniciar o trabalho, mais eficiente será o trabalho. Não se perde tempo com uma comunicação longa e, às vezes, sem sentido. Nesse caso, todas as partes se beneficiam: os desenvolvedores entendem claramente o que e como fazer, e o provedor de tarefas realiza o trabalho exatamente da maneira em que ele o imaginou.
E como você aborda a formulação de tarefas para desenvolvedores?
Diretor de produto Gulfiya Kurmangaleeva