O que os médicos me ensinaram sobre requisitos

Já levantei requisitos para marketplaces, plataformas de logística, produtos financeiros e fábricas. Achava que era bom nisso. Então comecei a passar tempo com médicos, primeiro em torno de um app de agendamento de clínica anos atrás, depois em torno de ferramentas de pesquisa, e aprendi que tudo o que eu sabia sobre requisitos tinha sido calibrado para gente cujo pior caso é um estorno.

Eles descrevem a exceção primeiro

Pergunte a um gerente de produto como uma funcionalidade funciona e ele descreve o caminho feliz. Pergunte a um médico como um processo funciona e ele descreve o caso em que deu errado. O paciente com dois prontuários. O resultado que chegou depois que a decisão já tinha sido tomada. A alergia que estava na evolução mas não no campo. Levei um tempo para entender que isso não é pessimismo. É treinamento. A medicina ensina que o caso normal se resolve sozinho e a exceção é onde alguém se machuca.

É exatamente assim que eu audito sistemas, e nunca tinha visto isso como técnica de levantamento de requisitos. Hoje abro toda sessão de descoberta com a mesma pergunta: me conta da última vez que isso deu errado.

Interrupção é o estado padrão

Todo fluxo que eu já tinha modelado assumia que o usuário começa uma tarefa e termina. Um médico começa uma tarefa, é chamado, volta quarenta minutos depois e precisa saber na hora onde estava e se algo mudou enquanto esteve fora. Um formulário que perde o estado ao recarregar é um incômodo num checkout de e-commerce. Numa enfermaria é uma questão de segurança. Requisitos de software clínico precisam especificar o que acontece quando a tarefa é abandonada no meio, não como caso de borda, mas como caso principal.

Hoje pergunto sobre interrupção em todo projeto, médico ou não, porque descobri que operadores de armazém e atendentes de suporte vivem do mesmo jeito. Os médicos só foram os primeiros a dizer em voz alta.

Eles não confiam no que não podem ver a origem

Mostre um número a um médico e a primeira pergunta é de onde veio. Não por desconfiar do software, mas porque já se queimaram com um valor copiado de um registro antigo, ou convertido de unidade duas vezes, ou lançado no paciente errado. Um requisito que eu nunca escrevia, e hoje escrevo em todo projeto, é que todo valor exibido precisa conseguir mostrar sua origem sob demanda. A fonte, o horário, a pessoa ou o processo. Isso é proveniência na interface, e custa quase nada se você projeta desde o início, e uma reescrita se não projeta.

Requisito vago é passivo, literalmente

Na maioria dos softwares, um requisito ambíguo vira um bug, depois um ticket, depois uma correção. Na medicina, um requisito ambíguo vira uma decisão que alguém tomou com a informação errada, e há um nome preso a essa decisão. Os médicos me ensinaram a resistir à vagueza com mais força do que eu jamais resisti com clientes de negócio. 'Mostrar os resultados relevantes' não é requisito. Relevante para quem, escolhido como, e o que acontece com os que foram filtrados?

O que levei de volta para todos os projetos

A mentalidade clínica me tornou um engenheiro melhor para trabalho não clínico. Comece pela falha, não pela funcionalidade. Assuma que o usuário vai ser interrompido. Faça cada número se explicar. Recuse ambiguidade mesmo quando é socialmente desconfortável. Meu pai passou quarenta anos em consultórios onde esses hábitos eram a diferença entre um dia bom e uma tragédia. Nunca tive a chance de aprendê-los com ele. Aprendi com pessoas que fazem o mesmo trabalho, e tento construir ferramentas que mereçam a confiança delas.