Scrum sempre manterá seu projeto sob controle?

Um CIO que responde às necessidades de 75 mil usuários diz que a
única coisa que pode ter é um sumário de condição do projeto (verde,
amarelo ou vermelho) e a única coisa de que está certo é da falta de
controle.

O departamento de gerenciamento responsável pelo sistema de
informação em uma grande companhia americana diz: “Continuamos quebrando
nossos projetos em partes cada vez menores para nos certificarmos que
as coisas serão feitas. E, no final de cada trimestre, nós recebemos uma
série de relatórios, mas eu não posso dizer o que realmente está sendo
feito. Como ter controle dos projetos?.”

E o CIO de uma empresa que está entre as 25 maiores da revista
Fortune: “Tenho 110 pessoas com o título de gerentes de projeto e não
acho que tenho algum gerenciamento de projetos. Como posso assumir o
controle dos projetos? Uma das tentativas mais comuns é quebrá-los em
pequenas e discretas partes. E cada fração vira então um projeto próprio
em um horizonte mensal, semestral ou anual”.

Em minha opinião, essa abordagem tende a criar gaps antinaturais
entre elementos interdependentes, mais ou menos da mesma forma que uma
plataforma de gelo que conecta dois pedaços de terra firme se torna uma
ameaça quando se descola.

Novas tecnologias foram criadas para gerenciar os micro-projetos ao
longo do caminho. O Scrum, reuniões diárias e metodologia ágil são
alguns exemplos. A maior vantagem do Scrum é o foco em alguns produtos
específicos.

Assim como qualquer metodologia, é fácil encontrar exemplos de
sucesso e de fracasso na comunidade Scrum. E esse não é um lugar para
debater os méritos de qualquer modelo. Mas existem duas desvantagens
significativas no modelo Scrum.

Primeiro, há o risco de investir muito tempo em sessões de Scrum. Um
bom alvo para comunicação é de 5% a 10% do tempo diário. Um projeto
sofre quando a comunicação se torna menos de 5% do tempo, e os
benefícios diminuem significativamente entre 9% e 10%.

As sessões de Scrum deveriam tomar 30 minutos, cerca de 6,25% do dia,
o que está de acordo com o modelo – até agora, tudo bem. Teoricamente,
isso deveria levar a revisões e relatórios de gerenciamento que são
necessários no mundo real.

Entretanto, é raro encontrar reuniões de time que durem menos de 30
minutos. É muito mais comum encontrar uma média diária de 48 minutos
(10%), se não mais, consistentemente consumidos. Contando o tempo de
coordenação, as revisões necessárias e relatório, a eficiência e
efetividade do time terá caído muito até se aproximar da zona
improdutiva.

Em segundo, implementações baseadas em Scrum são assunto para o mesmo
tipo de risco citado acima. Cada iceberg se torna um pequeno mundo,
flutuando livre e necessitando de ajustes táticos.

Esses ajustes táticos são geralmente resultado de mudanças de
trajetória porque um dos tomadores de decisão ficou sabendo de um novo
conceito; ou ocorreram mudanças econômicas e/ou políticas no meio tempo.
Freqüentes, eles mudam o conceito original do projeto.

Em TI, a grande maioria das atividades – excluindo operações e help
desk – deriva de projetos, esforço por unir uma equipe em torno de um
objetivo claro, orçamento e tempo bem ajustados. E, como mostrado nas
duas partes anteriores dessa série, a maioria dos projetos está fora de
controle.

Granularização – não uma palavra, mas um conceito vital – é a
terceira chave para o sucesso. Você precisa rastrear tudo a um nível de
detalhes mais profundo do que já fez alguma vez na vida. Em outras
palavras, sumarizar e relatar ao nível da tarefa e da sub-tarefa, e
assim por diante, até o nível das atividades e sub-atividades. Aqui está
uma sugestão para facilitar sua vida: controle a comunicação em um
nível granular.

Com muita freqüência, a pessoa responsável assume os relatórios, mas
que só alcança uma visão geral para cada atividade maior, o que gera
falta de rastreabilidade. Por exemplo, um time planeja uma função para
um período de dez semanas. Ao fim da primeira semana, o time reporta 10%
das horas despendidas e, obviamente, apenas 10% de tudo que foi feito. E
assim por diante, dando um falso senso de segurança para gerenciar e
começando a colocar um monstro no horizonte.

O medo geralmente é responsável por esse tipo de atitude. É, antes de
tudo, o medo de relatar uma escorregada a alguém que não compreenda que
em projetos, erros e escorregadas acontecem.

Outro motivo para essa falta de controle em todos os níveis é que
ninguém realmente sabe tudo o que precisa ser feito nos primeiros
estágios de um projeto, uma tarefa ou uma atividade. De acordo com o
Project Management Institite (PMI), assim que um projeto se desenrola,
há um entendimento crescente do que é necessário e como fazê-lo.

Seria sábio aplicar esse insight até o menor nível possível.
Reconheça que indivíduos e times não podem saber tudo enquanto planejam,
não importa em qual nível operam. Assim que o tempo passa, isso muda.
Essa é uma elaboração granular, que traz basicamente três benefícios.

Primeiro, qualquer desvio do plano original aparecerá rapidamente.
Assim, qualquer defasagem de performance aparecerá. Em segundo, o
projeto se manterá rastreável desde o início, requerimentos são
refinados e o projeto seguirá um mapa ainda mais específico. Se, e
quando, começar a parecer que o escopo original (em qualquer nível)
estava inadequado, o fundamento original estará lá para apoiar o desvio
necessário.

Terceiro, o processo vai rapidamente identificar
qualquer mudança de direção que não seja uma elaboração progressiva do
escopo original. É importante ter um plano de comunicação que contenha o
contanto de todos até o nível mais baixo. Além disso, é importante
acrescentar duas categorias ao quadro geral da equipe de projetos: o
backup e o suporte.

Backup: Pessoa que dar suporte à pessoa responsável
Responsável: Pessoa fazendo o trabalho
Respondente: Pessoa que recebe o crédito por fazer tudo acontecer ou cuja cabeça rolará caso o projeto não dê certo
Suporte: Departamentos, pessoas ou organizações imprescindíveis para o sucesso
Consultor: Pessoa(as) que precisam ser informadas que uma decisão/ação foi tomada

Cada
pessoa precisa ter uma outra de suporte que recebe, pelo menos, uma
visão geral do que foi feito durante 15 minutos ao final de cada semana.
Nesse tempo, a pessoa responsável faz um resumo do progresso, status,
documentos significantes, senhas, e assim por diante. Como resultado,
não há falta de conhecimento significativa no projeto. Existe sempre
alguém a quem recorrer em busca de informações específicas.

O
plano de comunicação deve identificar também todo o suporte que pessoas
ou a organização precisará para alcançar o sucesso. Por exemplo, quando
uma organização planeja instalar uma nova aplicação, além dos testes de
praxe, pode ser necessário um novo servidor, um upgrade no sistema
operacional e etc. Identificar essas pessoas e organizações no início do
projeto eliminará muito do pânico que ocorre no meio dos processos.

Quando
tomar os passos necessários para assegurar que os vazamentos foram
fechados, e que todos têm a mesma idéia, e garantir que as atividades
são rastreáveis em um nível muito pequeno, terá seus projetos sob
controle.

(*) John Troyer é Senior Technical Project Manager na GE Energy