Quantas vezes você, como desenvolvedor já recebeu aquela solicitação que é caso de vida ou morte, super relevante e importante para o usuário? Quantas dessas vezes essa solicitação era complexa, tomava muito tempo para ser desenvolvida e no fim das contas nem era tão importante assim? Quantas dessas solicitações acabaram ficando esquecidas no sistema? Quantas delas eram realmente necessárias?
Quando o nosso cliente, usuário ou setores que dependem do setor de desenvolvimento, especialmente quando a empresa em que você está inserida é um modelo SaaS( Software como serviço, do inglês Software as a service), espera-se do time de desenvolvimento alta performance, inovação e principalmente resposta rápida. Resposta rápida na correção de erros, na solução de problemas, na entrega de novas funcionalidades e assim por diante.
Como a demanda, muitas vezes, é enorme, começam a ser usados os artifícios para acelerar uma funcionalidade ou uma solução de problema e é aí que entra o “caso de vida ou morte”. Os desenvolvedores se desdobram, usam toda sua capacidade para entregar a tal funcionalidade que vai resolver a vida do cara que solicitou ou vai solucionar um caso que é extremamente crítico. Tudo lindo, perfeito não é mesmo? Coisas muito importantes sendo resolvidas primeiro, certo? Errado. E põe errado nisso. Muitas vezes os desenvolvedores se empenham para criar uma solução que parece ser útil, prática, compreensível e necessária, mas no fim das contas não é. Quem atribui essas características é o usuário, são vários usuários. E se estes usuários fossem consultados antes de usar tempo, disposição e recursos? Quantos destes “casos de vida ou morte” perderiam completamente o sentido?
A diferença é que quando se descobre que não é tão prioritário assim ou que não é uma funcionalidade realmente útil antes de chegar na mão dos desenvolvedores, o tempo, a performance e a disposição dos desenvolvedores não são afetados ou pelo menos tem um impacto mínimo. Quando um time fica constantemente submetido a implementação de funcionalidades ou soluções “caso de vida ou morte” a prioridade acaba perdendo o sentido. Afinal de contas, se tudo é prioritário, nada é prioritário. Alguma coisa vai perder a força na fila de demandas. E se essa “alguma coisa” for aquela funcionalidade realmente importante? Fica a encargo do desenvolvedor decidir isso, mesmo que ele não tenha contato com o usuário que está dependendo desta funcionalidade para prosseguir no seu trabalho, mesmo que ele não compreenda por completo o quão util a funcionalidade é para os demais times da empresa.
Como impedir que esse tipo de ciclo vicioso seja criado? Comunicação. Simples, não é? Não a comunicação: “eu peço você faz”, mas sim a comunicação clara e transparente, com as prioridades reais em mente. O desenvolvedor tem sim a responsabilidade de compreender o que é necessário ser feito para entregar o que vai atender à alguma necessidade, em contrapartida, o solicitante tem a responsabilidade de ser claro e verdadeiro com o desenvolvedor expressando qual é a necessidade real e se a prioridade é de “vida ou morte” ou se é uma funcionalidade que pode esperar.