LINK-V
LINK-V · Artigo

O que incluir num documento inicial para software à medida?

November 5, 2026

Comece por uma tarefa que a sua equipa precisa de concluir. Explique o que a desencadeia, quem trata dela, como seria um bom resultado e onde surgem dificuldades. Assim, terá algo concreto para discutir com um programador, mesmo antes de saber o que construir.


O que incluir num documento inicial para software à medida?

«Precisamos de um sistema de reservas melhor» é um ponto de partida perfeitamente razoável. A próxima pergunta útil é o que acontece quando alguém tenta fazer uma reserva.

Antes da primeira conversa com um programador, descreva uma tarefa desde o pedido inicial até ao resultado final. Inclua também a parte complicada. Pode explicá-la em linguagem corrente, mesmo sem saber ainda como o software deve ser construído.

Comece por uma tarefa que as pessoas fazem de facto

Imagine uma empresa de formação fictícia. Um cliente envia um email a pedir dois lugares num curso. A pessoa que coordena os cursos confirma a disponibilidade, responde ao cliente e regista a reserva. Se o curso estiver cheio, alguém tem de decidir o que oferecer em alternativa.

Isto basta para iniciar um documento útil. «Construir um portal com um painel de controlo» deixa muito mais por adivinhar: quem o utiliza, que tarefa precisa de concluir e quando uma reserva conta como feita.

O guia do Governo britânico para compreender um problema antes de criar um serviço recomenda analisar os utilizadores, o percurso completo e as limitações. O seu processo de desenvolvimento de serviços públicos é específico desse contexto. Para a nossa empresa de formação, a pergunta inicial é simples: o que é preciso para inscrever este cliente num curso?

Separe o trabalho atual da mudança pretendida

Peça a quem faz a tarefa que explique um exemplo recente, passo a passo. Anote o que observou. Depois descreva o que pretende que funcione de outra forma. Na nossa empresa fictícia, as notas poderiam ser estas:

O que acontece hoje

A pessoa que coordena consulta a folha de cálculo do curso, responde por email e regista no calendário uma reserva aceite. Neste exemplo, um lugar foi oferecido enquanto outra resposta ainda estava pendente.

O que queremos mudar

A pessoa que coordena deve conseguir ver os pedidos que ainda aguardam resposta e decidir se oferece um lugar. Ainda temos de acordar quando um lugar passa a estar ocupado.

A primeira parte descreve o trabalho atual. A segunda propõe uma mudança e deixa uma decisão por tomar à vista. Esta distinção importa quando as pessoas têm hábitos diferentes: uma pode reservar lugares enquanto espera uma resposta, outra pode deixá-los disponíveis. Registe as duas formas de trabalhar antes de pedir ao programador que transforme qualquer uma delas numa regra.

Indique o início, o fim e um caso complicado

Para o pedido de inscrição no curso, um esquema prático poderia ter estas notas:

  • Início: chega um email a pedir dois lugares num curso e numa data específicos.
  • Pessoas: a pessoa que coordena os cursos trata do pedido. A pessoa responsável pela formação decide as questões relativas às regras de reserva.
  • Informação: data do curso, lugares disponíveis, lugares pedidos e resposta do cliente. Hoje, estes dados estão numa caixa de email, numa folha de cálculo e num calendário.
  • Resultado final: a pessoa que coordena registou a reserva acordada, os lugares restantes refletem-na e o cliente recebeu a confirmação acordada.
  • Caso complicado: resta apenas um lugar quando o cliente pede dois. A pessoa que coordena precisa de manter o pedido em aberto enquanto oferece outra data.

Estas são notas propostas para o exemplo, não regras definidas para todas as empresas de formação. Pergunte o que significa «reserva acordada» na sua. Um lugar fica ocupado depois de ser oferecido, de o cliente aceitar ou de pagar? Uma pergunta registada pode ser resolvida em conjunto.

Junte um pequeno exemplo com registos inventados: o Curso A de 12 de maio tem um lugar disponível; o Pedido B solicita dois. Mostre o resultado esperado, incluindo quem toma a decisão. Assim, o programador pode perguntar sobre algo concreto.

Use nomes e registos inventados quando ajudarem a explicar o trabalho. Para exemplos reais, partilhe apenas o que está autorizado a partilhar, retire dados pessoais ou confidenciais desnecessários e acorde uma forma adequada de os fornecer.

Identifique requisitos, ideias e questões por resolver

Requisito: a pessoa que coordena deve conseguir ver os pedidos que ainda aguardam resposta. Explique porquê: caso contrário, alguém tem de procurar o trabalho pendente na caixa de email partilhada.

Ideia a discutir: os clientes poderiam escolher outra data de curso por si próprios. Mantenha-a como possibilidade até avaliar o trabalho necessário e quem beneficiaria dela.

Questão em aberto: quando deve um lugar ser reservado e quem o pode libertar? Indique a pessoa responsável pela formação como quem pode decidir, em vez de deixar o programador escolher essa regra de negócio sem discussão.

Inclua também os limites reais. Talvez seja necessário manter o calendário atual, só certas pessoas possam ver os dados dos clientes ou um curso específico tenha de estar disponível antes de uma data conhecida. Diga que limites são firmes e porquê. Se uma data ou um orçamento ainda forem uma preferência, indique-o.

Explique como reconhecerá um resultado útil

«Mais fácil de usar» precisa de um exemplo. Nesta empresa, a pessoa que coordena deve conseguir acompanhar um pedido até à resposta e encontrar todos os que ainda estão pendentes. Use a reserva normal e o caso em que resta um lugar para discutir o que o trabalho concluído deve demonstrar.

Pode ainda registar um problema atual que queira medir, como a frequência com que a equipa procura um pedido sem resposta em várias ferramentas. Diga o que observou e o que falta confirmar. Acorde qualquer objetivo depois de definir o ponto de comparação.

Mostre o documento a quem faz o trabalho antes de o enviar. Essas pessoas podem identificar uma etapa em falta ou explicar porque é que um aparente atalho causaria problemas. Deixe as questões por resolver no documento, com uma pessoa responsável por responder a cada uma.

Desenvolvemos software empresarial à medida. Se quiser falar connosco sobre um projeto, traga uma tarefa como esta: o que acontece agora, o que quer mudar, um exemplo e as questões que ainda tem. Podemos então discutir o âmbito e as condições comerciais em função do trabalho. O documento dá início à conversa; a investigação técnica e o desenho da solução ainda serão necessários.

Perguntas sobre a preparação do documento inicial

Preciso de uma especificação técnica antes de falar com um programador?

Pode começar por descrever a tarefa, as pessoas que a fazem, as ferramentas que utilizam e o resultado de que precisa. O desenho técnico pode vir depois da investigação. Se conhecer uma limitação técnica real, registe-a e explique porque importa.

E se diferentes pessoas fizerem a mesma tarefa de maneiras diferentes?

Descreva as versões que observou e pergunte às pessoas envolvidas porque diferem. Indique que diferenças são necessárias e quais ainda exigem uma decisão. Identifique quem a pode tomar.

Como descrevo algo que ainda não decidimos?

Escreva a pergunta, o que já sabe e quem pode ajudar a responder. Por exemplo: «Quando é que um lugar num curso passa a estar ocupado: ao ser oferecido, aceite ou pago?». Mantenha-a separada dos requisitos acordados.

LINK-V LINK-V