Como saber se a entrega está completa mesmo?

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

Publicado por: Eli Rodrigues

There are 3 comments for this article
  1. Giovani Faria at 16:11

    Os projetos são baseados em expectativas. Entretanto, saber exatamente quais são elas, e mais especificamente, deixar tudo ‘preto no branco’ é que se torna o desafio.

    Oi Eli, você, com muita propriedade, descreveu esses ‘causos’ e situações que mostram bem um problema do dia a dia de projeto.

    Embora o trabalho de gerenciar projetos envolva várias rotinas, cada projeto é único (para dizer o mínimo, pela existência de um cliente diferente). Então, é imperativo ter isso em mente para evitar Premissas erradas (ou que valiam para aquele outro projeto muito semelhante a este)

    Resumindo é preciso atenção e detalhamento para garantir que todos estão ‘falando o mesmo idioma’ e que um vai entregar aquilo que o outro espera receber.

    Ótima leitura!!

  2. Silvana Oliveira de Sá at 17:57

    Gostei!! Muiltissimo util!

  3. Pingback: 9 Erros que o Scrum ajuda a resolver « Gestão de Projetos