Como preparar o briefing de uma aplicação à medida sem escrever uma especificação técnica.

Um resumo de desenvolvimento não precisa começar com um diagrama de banco de dados. Ele precisa explicar um trabalho que alguém deve ser capaz de completar e o resultado que sua empresa precisa dele.

O objetivo do primeiro resumo é tornar o projeto discutível. Você pode deixar as escolhas técnicas em aberto, sendo preciso sobre o trabalho que a aplicação deve apoiar.

Comece com um usuário e uma tarefa

"Construir um portal" nomeia um tipo de software. "Deixe um cliente aprovado enviar um pedido de serviço e ver o seu progresso" descreve um primeiro fluxo de trabalho útil.

Nomeie o usuário, a ação e o resultado. Em seguida, identifique quem lida com o outro lado do processo. Neste exemplo, um membro da equipe precisa rever o pedido e atualizar seu status. Isso significa que o resumo já contém duas funções diferentes e um registro compartilhado.

Evite começar com “um aplicativo para todos”. Usuários diferentes podem precisar de diferentes permissões, telas e informações. Decida qual papel mais importa na primeira versão.

Explique o que acontece hoje

Descreva os passos atuais em linguagem comum. Talvez uma informação de e- mail do cliente, um membro da equipe copia- a em uma planilha e outra pessoa envia uma atualização de progresso. Estado onde a confusão ou esforço repetido ocorre, sem assumir que o software irá resolver todos os problemas ao redor.

Um exemplo editado do formulário ou registro atual pode ser mais útil do que uma apresentação polida. Remova informações pessoais e detalhes confidenciais antes de compartilhá-lo.

Descrever uma viagem completa

Siga um registro representativo do início ao fim. O que começa? Quais informações são necessárias? Quem toma a próxima decisão? O que a marca como completa?

Inclua uma ou duas exceções importantes. Uma solicitação pode estar incompleta, um revisor pode rejeitá- la ou um usuário pode precisar corrigir um erro. Esses casos ajudam a distinguir uma aplicação de trabalho de uma demonstração do caminho ideal.

Você não precisa inventar cada evento raro nesta fase. Concentre-se nas exceções que impediriam o fluxo de trabalho principal de ser útil.

Nomeie os dados e dependências

Liste os registros importantes: usuários, pedidos, produtos, reservas, arquivos ou outro conjunto de informações. Explique de onde eles vêm e quem é responsável por mantê-los.

Para uma integração, nomeie o outro serviço e forneça sua documentação quando disponível. “Conecte-se ao nosso CRM” deixa grandes questões em aberto. O detalhe útil é qual registro deve mover-se, em que direção e depois de qual evento.

Identificar se os projetos, o conteúdo do produto, o acesso à conta ou as regras de negócios já estão disponíveis. Os materiais em falta não são automaticamente bloqueadores, mas precisam de um proprietário e de um lugar no plano.

Definir a primeira versão útil

Separar a entrega do núcleo de ideias posteriores. Um primeiro portal pode apoiar a criação de um pedido, revisá-lo e mostrar o status. Mensagens, relatórios avançados e um aplicativo móvel podem ser discussões posteriores em vez de requisitos não falados da primeira compilação.

Esta não é uma instrução para construir algo incompleto. O fluxo de trabalho escolhido deve funcionar do início ao fim. O limite é entre fluxos de trabalho completos, não entre uma tela atraente e a lógica que ainda precisa.

Escreva um exemplo de aceitação

Tente uma frase que alguém possa testar:

Um cliente aprovado pode enviar um pedido, ver o seu status após a assinatura e visualizar apenas os seus próprios pedidos. Um membro da equipe autorizado pode atualizar o status, e o cliente vê essa mudança.

Este é um requisito ilustrativo, não uma descrição de um projeto de cliente existente. Torna o comportamento esperado muito mais claro do que “um portal moderno e seguro”. O escopo eventual pode refinar as permissões e casos de borda.

Adicionar restrições práticas

Indique o momento desejado, seja uma preferência ou uma data externa fixa, e o intervalo de orçamento onde for conhecido. Nomeie a pessoa que pode aprovar decisões e explique como os designs ou feedback serão fornecidos.

Descreva as expectativas de lançamento e entrega também. Quem possuirá o hosting e contas? Será que outro desenvolvedor precisa receber o código? Essas perguntas afetam a entrega mesmo quando não aparecem em uma tela.

Um resumo que você pode usar

Queremos construir: a aplicação ou o fluxo de trabalho. Os principais utilizadores são: As pessoas e os papéis. Eles precisam: a tarefa principal e o resultado finalizado. Hoje isto acontece através de: o processo atual. A primeira versão deve incluir: O fluxo de trabalho completo essencial. Ele precisa se conectar a: Os sistemas e documentação conhecidos. Já temos: desenhos, conteúdos, contas ou dados de exemplo. Ainda indeciso: perguntas para resolver. Calendário, orçamento e decisão: As restrições práticas.

Use algumas frases claras para cada parte. O breve é um ponto de partida para definir o projeto, não um teste que você precisa passar antes de falar com um desenvolvedor.

Discuta uma aplicação web personalizada ou enviar o seu resumo.