segunda-feira, 14 de novembro de 2011

Como saber se a entrega está completa mesmo?



Liderança e Gestão de Projetos
Uma perspectiva prática da gestão de projetosComo saber se a entrega está completa mesmo? Posted on outubro 7, 2011 by EliRodrigues

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:



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 entedam 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.

Nenhum comentário:

Postar um comentário