Álvaro Ferro
Os fornecedores de projetos de desenvolvimento de sistemas de informação em Out-sourcing devem:
Este par é a minha mnemónica para rapidamente verificar um processo de gestão de projeto.
Uso-a também para avaliar os meus representantes políticos.
No blog de James Bach’s encontra-se ilustrado o exemplo de como duas formas de comunicação diferentes podem ser a diferença entre o sucesso e insucesso de uma validação da qualidade do produto.
Ambos os exemplos se referem aos mesmos factos e apresentam as mesmas conclusões, mas um deles perdeu a credibilidade para futuras contratações, não porque dissesse alguma coisa diferente do outro, mas porque se entreteve a insultar os desenvolvedores.
Sinónimo para trabalhador de esquerdite patronal.
As actividades de gestão de projectos são aos olhos de um gestor de projectos experimentado um conjunto de óbvios. Estes óbvios poderão ser confundidos com bom senso ou senso comum.
O bom senso e senso comum não fazem um bom gestor de projectos. Tanto o bom senso como o senso comum não passam de convenções restritas a grupos com a mesma origem, vivência em período comum e formação comum.
Mesmo garantindo a origem, esta não garante as convenções para além de um período curto. As religiões tentam controlar estes pontos tentando garantir a imutabilidade da doutrina, mas até estas são alteradas ao longo dos anos e para populações específicas.
As convenções de bom senso ou senso comum, sendo válidas para populações e períodos restrictos, não podem por isso e por si só garantir um bom seja o que fôr, pelo que também não garantirão um bom gestor de projectos.
Ando a estudar novamente a gestão de projecto, agora com especial atenção aos problemas da qualidade do produto.
Nas mãos tenho “Gestão do Risco e da Qualidade no Desenvolvimento de Software” de António Miguel e logo na página 11 encontro esta afirmação:
“A realidade da gestão de projectos é que um projecto raramente falha devido a problemas com um sistema de software PERT/CPM. No entanto, falham frequentemente por motivos não técnicos, como a falta de comprometimento por parte da gestão de topo, o inadequado envolvimento do cliente, gaffes políticas e incapacidade de comunicar ideias de forma eficaz.”
Acerca das dificuldades de comunicação com o cliente, já me queixei em Usabilidade em projecto de desenvolvimento sobre os problemas do cliente testar a satisfação com o uso do produto. O cliente não ficará muito satisfeito se o seu produto se mostrar ineficaz e ineficiente, mas mesmo tendo os dois anteriores, cedo descobrirá que a satisfação de uso do produto também conta para a avaliação do mesmo.
Este livro aponta mais para a frente e pretende introduzir também para a transição do produto do projecto para a administração e manutenção do produto como mais algo a ter em conta na execução do projecto.