«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.