Muitas vezes erros não são reportados, pela cultura de medo presente. Já estive em ambientes onde a resposta era “deixa a pessoa que usa o software reportar primeiro, não vamos corrigir antes“. Essa foi a resposta sobre um defeito encontrado em testes internos. Pelo menos foi permitido registrar como um defeito conhecido. 

Depois ao longo do tempo de experiência, isso foi ressignificado, e aprendi que existem problemas que tem prioridade em relação a problemas menores. Talvez a melhor forma de resposta seria “vamos registrar e priorizar junto com as diversas falhas menores que temos já registradas”. Ainda assim a resposta não reflete o problema, mas a consequência. 

Estamos discutindo como priorizar quais problemas queremos resolver, mas como fazemos para priorizar a prevenção ao desenvolver novas funcionalidades? 

Antes, começa na cultura de não aceitar o estado atual. 

A cultura de falar a respeito de problemas na experiência de uso é um grande problema. Muitas pessoas se acostumam com o problema. Por vezes, deixam de achar estranho e consideram tudo certo precisar fazer algo extra… já se acostumaram, virou agenda no calendário, virou alarme no celular. 

Isso é um grande problema. Quando questionei sobre trabalho repetido, a resposta sempre era “que não era um problema fazer esse procedimento extra“. E para quem está iniciando no uso do sistema? A resposta era mais desesperadora… elas ensinavam estes detalhes de operação, como uma parte de dicas para o dia a dia em relação ao melhor uso do sistema. 

Quer mais pavor nesta história ainda? 

Quando questiono porque um item não era resolvido, quando tentava saber com quem tinham falado a respeito do problema, a resposta era que entendiam que todo mundo já sabia daquele problema, pois afinal de contas ele era velho. O sistema era assim. 
Era óbvio que tinha que ser arrumado. Só faltou comunicar e reforçar com quem tinha a capacidade de priorizar o assunto. 😦

Workarounds deveriam ter data de validade.

Eu resolvi este problema em alguns cenários usando a forma existente para documentar. Por favor, podemos criar um repositório com todas estas “dicas” que passamos internamente e para clientes? 

E a partir disso inicia um trabalho de priorização para entender que itens precisam ganhar atenção. Quando você acha que o problema está resolvido, ele só aumenta. Você vai descobrir que alguns destes itens de contorno podem ser feitos somente por algumas pessoas. E sabe aquelas horas extras que são reportadas, que você acha que era em virtude de atuação em algum incidente ou ação preventiva? Era para isso, mas também para poder executar algum procedimento para clientes ou colegas na parte da noite, como parte da solução de contorno. 

Agora existiam mais problemas. Além do sistema falho, existe dependência de pessoas dentro da equipe e um custo até então invisível. Pelo menos esse não é mais. 🙂

Autonomação (jidoka). 

Automação com a mente humana, esse é o pensar da autonomação. Queremos o apoio humano pela capacidade de consciência do presente e do que ele precisa fazer naquele momento. Agora, em inúmeras oportunidades, e incluindo atividades repetitivas, devemos garantir que o sistema é capaz de resolver e evitar que a pessoa cause algum problema. 

Quando algum problema acontece e temos a percepção de falha humana, não responsabilize a pessoa. O sistema deixou a pessoa entrar por aquele caminho. Se existe uma porta que não pode ser aberta por perigo de choque (perigo de morte), uma placa na porta não é suficiente. Garanta que a porta possui chave, e que esta chave só é acessível por pessoas que podem abrir esta porta. Ainda, garanta que quem abrir a porta está usando o que precisar de equipamentos para poder se prevenir e cuidar da sua própria vida. 

Retomar o estado do sistema como resultado de uma falha. 

Já fiquei orgulhoso de ter mostrado para pessoas a mensagem de erro depois de detectar uma falha que aconteceu. Não deveria. O grande problema era como fazer a pessoa poder seguir no caminho dela, no que ela queria fazer com o sistema. Como você avisa quem precisa avisar para que a pessoa consiga fazer o que ela precisa fazer? 

Quando algum problema acontece, recupere o sistema no estado que ele estava antes da pessoa realizar a ação que não poderia ter evitado. Mas aí eu vou além. Qual o motivo de deixar um botão ativado para a pessoa executar uma ação que ela não pode executar naquele momento? 

Nem toda falha é do software, mas sempre é do sistema. 

Por vezes o software mostra um problema, mas o problema mesmo é por causa de alguma dependência deste software. Independente deste caminho, a falha é do sistema. Você deveria conseguir sempre expandir problemas que acontecem para a jornada em questão. Alguém não conseguiu fazer um trabalho. Isso é a pior coisa que pode acontecer. Quando você interrompe a vida de uma pessoa, você pode estar impedindo algo grandioso de acontecer. Isso serve até para uma caneta que termina a tinta e não tinha jeito visual de ver isso acontecendo. Uma grande ideia deixou de ser registrada naquele momento por algo que era evitável. 

Sabe o que mais era evitável? Você sabe. 

Quais são os poka yokes da sua vida? 

Como você organiza a sua vida para garantir que possui apoios e alertas que evitam falhas de acontecerem? Como você faz para não perder um compromisso? Como você garante que não fica sem algum alimento que considera essencial? Como você garante que o papel higiênico não vai faltar? Como você garante estruturas de prevenção para desenvolver software e trabalhar em equipe? 

Esse é o jogo. 

— Daniel Wildt

Como você sabe o jeito certo de abrir ou fechar uma porta? Esse texto começa por uma reflexão escutando The Design of Everyday Things, de Don Norman e pensando na minha relação com o registro e resolução de falhas em software.

Você pode apoiar minha jornada de conteúdo através do projeto A Filosofia da Tranquilidade! Perguntas e reflexões para trilharmos nossos caminhos, com tranquilidade!