Como saber se a entrega está completa mesmo?

Olá Gerentes de Projeto,

Esta discussão tem sido recorrente nos treinamentos e workshops que tenho trabalhado: Como saber se uma tarefa está realmente concluída? Como saber se terminei o escopo de um projeto? Como definir o “done”? A assinatura do cliente é suficiente? Como saber se a entrega está completa MESMO?

O mesmo cenário têm ocorrido na indústria, serviços e comércio, a dificuldade para definir quando um trabalho está pronto. Esses dias mesmo passei um “causo” trocando de apartamento, enquanto para a corretora o fato de eu ter escolhido o imóvel significava “done”, para a área administrativa receber minha documentação era “done”, cada um fazendo um excelente trabalho com seu umbigo e eu sem as chaves para mudar.

Isto ocorre geralmente por dois motivos: cada departamento enxerga somente sua “parte” ou pelos diferentes entendimentos em relação ao trabalho. Um entende que o trabalho está pronto quando o faturamento foi recebido, outro no pós-venda; um acredita que feito o serviço está terminado, outro entende que só termina após o período de garantia.

Como resolver esse impasse? Antes de responder, permitam-me mostrar algumas situações do mundo real no ambiente de projetos:

• João assumiu a tarefa de especificar um novo produto, na data final ele entregou um documento. Está concluído? Foi revisado? Tem aprovação da gerência? A área de engenharia avaliou a viabilidade? O cliente aceitou?
• Pedro trabalha numa empresa de software como desenvolvedor (programador). Ele terminou a interface de cadastro de vendas. Está concluído? Houve teste unitário? houve teste funcional? teste integrado? os bugs originários dos testes foram corrigidos? foram verificados? A interface foi disponibilizada para homologação? foi disponibilizada com sucesso em produção? todos os acessos foram garantidos? o cliente deu o aceite final?
• Carlos fez um projeto que ampliava a capacidade da rede (de computadores) do cliente, “virou” dois fins de semana para terminar o trabalho. Na data final do projeto, tudo pronto e funcional, um sucesso! Até que… o cliente informou que, no seu entendimento, o trabalho só estaria finalizado após duas semanas de monitoramento e suporte. E agora GP, tem orçamento para isso?

Todos estes são casos reais. Mas que característica comum poderia nos ajudar a definir se o trabalho “está pronto” ou não?

A resposta é: ESTADOS!

Nestas situações, o GP (ou a área de processos) precisa definir claramente que Estados existem, qual a sequência entre eles e quais os critérios para troca de Estado. Sim, isso é uma máquina de estados. Não é preciso ter profundas bases matemáticas e nem ferramentas sofisticadas, veja o exemplo de tabela postado na Wikipedia:

De uma forma gráfica, poderia-se fazer assim:

Também poderia ser usado um fluxo simples com os estados em sequência obrigatória:

Outra configuração bastante utilizada é o “ciclo”:

E ainda, para casos em que os estados são condicionais, uma espécie de Fluxograma usando Estados:

Obs: Existem notações para construção de Diagramas de Estados, para mais informações consulte a UML (Unified Modeling Language).

Após haver definido os estados para os pontos críticos do projeto, é hora de “divulgar” a máquina de estados a todos os envolvidos. Esta é a parte mais complicada, pois geralmente é difícil obter a concordância de todos e também é dificil que todos entendam o que o autor (da máquina de estados) quis dizer com cada um deles. Para evitar esse tipo de problema, recomendo que faça um “manual” especificando cada estado com: descrição, condições de troca e exemplos de aplicação. Recomendo ainda que envolva as pessoas na definição dos estados, isso garante o comprometimento com o que foi definido.

Se precisar de um software para apoiar o controle dos estados, indico o Mantis Bug Tracker. Ele é gratuito e tem suporte a vários idiomas e é bem customizável. Baixe aqui. Pronto, agora estamos aptos a reduzir a condição de dúvida sobre as entregas. Desejo sucesso a todos!

Eli Rodrigues