Conceito de Pronto ✔️

Algo unânime em todas as empresas por onde passei, onde tinha alguma espécie de liderança de equipes ou projetos, sempre foi tomar alguns momentos da atenção de todos para discutir sobre o conceito de pronto.

Para a maioria das pessoas, este conceito parece ser simples de entender e aplicar, parece até óbvio em muitos casos, mas ainda vemos muitos juniores, plenos e até mesmo sêniors que, talvez por desconhecimento ou costume, ainda precisam ser lembrados sobre a existência do conceito.

O conceito de pronto não possui fórmula ou uma teoria muito avançada. Trata-se, no geral, do entendimento comum da equipe sobre quando alguma demanda, tarefa ou processo está terminada.

Por exemplo, vamos utilizar o cenário de um analista de suporte técnico que recebe o contato do cliente informando uma inconsistência na extração de um relatório do sistema após ser editado o registro de produto.

O analista valida a inconsistência e documenta previamente o processo, versão, talvez base de dados, e encaminha a tarefa a um possível analista de requisitos que vá estudar o caso e documentar com mais detalhes antes de encaminhar ao desenvolvedor, que, por sua vez, irá pegar a tarefa e tratar, validar, publicar até que um analista de testes, caso exista, também valide, e assim por diante.

A questão aqui é: quando cada um pode chegar ao tech lead, PO, ou quem quer que seja o responsável pelo projeto e informar que está pronto?

O analista de suporte pode dizer que estava pronto logo após enviar a tarefa para o analista de requisitos. Este diria ter terminado após ter criado a tarefa e encaminhado para o backlog. O programador pode afirmar que terminou após rodar os testes automatizados e publicar a correção.

Quando, na verdade, o único ator nesse processo que foi diretamente impactado ainda está com o problema ao gerar o relatório após editar um registro de produto.

A questão do conceito de pronto, se definida assim pela empresa, é atribuir a todos os agentes do processo a responsabilidade de tratar aquele evento que impactou o cliente. O problema não estava corrigido após o suporte encaminhar a demanda para o analista de requisitos e também não estava corrigido após o programador publicar a correção. Esta questão só deixará de ser responsabilidade da equipe quando o cliente refizer o processo e o sistema se comportar conforme o esperado.

Isso levanta também questões sobre a responsabilidade sobre a tarefa, como, por exemplo, alguém que prolonga ou pausa uma tarefa por precisar que outra pessoa tome uma iniciativa ou que necessita de algum material ou auxílio. Claro que existem cenários específicos onde tarefas ficam pausadas por algum tempo por estarem atreladas a um processo maior, mas, a partir do momento que você está responsável pela tarefa, você deve buscar os materiais, habilidades, treinamento e demais recursos. Até mesmo é sua responsabilidade informar superiores ou a empresa quando não possui os recursos ou know-how para desenvolver a tarefa.

Em minhas próprias observações sobre os resultados dessas conversas com minhas equipes, pude perceber uma melhora considerável na busca pelo entendimento completo do processo por cada profissional, programadores entendendo onde exatamente aquela feature ou aquele método irão impactar o usuário final e tomando análises mais assertivas após este ponto de vista.