Assim como qualquer metodologia, é fácil encontrar exemplos de sucesso e de fracasso na comunidade.

Por: John Troyer

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. Frequentes, 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 subtarefa, 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 frequê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.

O quadro fica assim:

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 ideia, e garantir que as atividades são rastreáveis em um nível muito pequeno, terá seus projetos sob controle.

Fonte: ComputerWorld

Texto original:
http://computerworld.com.br/duas-grandes-desvantagens-do-scrum-e-o-que-fazer-para-supera-las