A síndrome do gerente master

Já faz muito tempo que desenvolvemos software sempre acompanhando todas as demandas emergentes que acontecem em qualquer negócio. A tecnologia passou a fazer parte do dia a dia das pessoas e toda essa evolução mostrou um grande crescimento dos projetos de desenvolvimento de software aumentando a preocupação com prazos, qualidade e integração entre todos os envolvidos que passaram a trabalhar juntos inclusive no mesmo código fonte.

Com o crescimento vieram também os problemas de como administrar toda essa nova demanda de atividades concorrentes e tão empíricas que mudam a cada linha de código. Daí surgiram os modelos de maturidade com objetivo de estabelecer um padrão para fabricação de software padronizado. Muitas dessas experiências vieram da própria engenharia civil e adaptações até chegar ao modelo que chamamos hoje de desenvolvimento em cascata (Waterfall).

A regra do desenvolvimento em cascata parece bem interessante no ‘papel’ onde cada pessoa no projeto faz uma parte como se estivesse montando um carro ou subindo uma parede em uma obra civil, sempre focando na desconfiança das pessoas, criando limitadores e em um erro brutal acreditando que desenvolvimento de software é fixo. Levando em consideração que em uma parede nós conseguimos visualizar se o projeto está andando, se está seguindo a planta, acreditou-se que o software com todos os seus estágios bem definidos seguiria a mesma linha.

Os problemas começaram a aparecer e interferir no resultado, como a perda de produtividade, dificuldade em entregar o projeto no prazo, perda de qualidade, insatisfação de todos os envolvidos, retrabalho, e, por incrível que pareça, até a criação de funcionalidades que jamais são utilizadas. Diversos estudos como os do Standish Group intitulados de  2004 Third Quarter Research Report, CHAOS Research Results apontam prejuízo nos projetos nos últimos 10 anos com apenas 30% de sucesso. Outro estudo ainda do Standish Group intitulado de Study Reported at XP2002 by Jim Johnson aponta outro número alarmante que é cerca de 64% das funcionalidades implementadas são raramente ou nunca utilizadas.

Em meados de 2001 um grupo de especialistas se reuniu justamente para discutir todos esses problemas que já atormentavam o desenvolvimento de software na época e como resultado publicaram o Manifesto Ágil com as melhores experiências que cada hum já aplicava em seus projetos dando início formalmente ao modelo ágil de desenvolvimento de software estabelecendo alguns princípios fundamentais:

1) Indivíduos e interação entre eles mais que processos e ferramentas.
2) Software em funcionamento mais que documentação abrangente.
3) Colaboração com o cliente mais que negociação de contratos.
4) Responder a mudanças mais que seguir um plano.

O manifesto ágil é a base dos principais frameworks e metodologias ágeis para desenvolvimento de software disponível no mercado. A cada leitura que faço sempre tenho uma grande reflexão tamanha é a importância das palavras reunidas e da cultura que impacta completamente em nosso dia a dia. Eu repito com frequência para as pessoas que estão próximas duas frases importantes “Nós somos um time” e “São pessoas que entregam projetos”, ambas inspiradas nesse manifesto que traz de volta o verdadeiro prazer em desenvolver software.

Estamos vivendo um novo estágio de maturidade nos projetos de desenvolvimento de software em todo o mundo e principalmente no Brasil com uma busca cada vez mais frequente por métodos ágeis com o objetivo de envolver mais as pessoas, proporcionando uma transparência, simplificando os processos envolvidos e explorando todo o potencial intelectual disponível buscando a realização de todos no projeto.

As tecnologias empregadas no desenvolvimento evoluíram muito, criando novas oportunidades e integrações jamais imaginadas, mas não implica que é fácil desenvolver software. É um trabalho totalmente empírico com mudanças a cada passo. Além que não adianta ter as melhores tecnologias do mundo se parte humana é tratada apenas como mais um recurso do projeto como um computador novo, por exemplo.

O SCRUM tem conquistado um grande número de adeptos no Brasil por proporcionar uma grande quebra de paradigmas no gerenciamento de projetos de software tradicional, proporcionando  uma nova experiência baseada em transparência, inspeção e adaptação amplamente aderente ao desenvolvimento de software com tamanhas mudanças e trabalho intelectual envolvido.

Com o SCRUM nós adotamos o modelo de autogestão, comprometimento e compartilhamento do conhecimento para que todas as pessoas envolvidas possam contribuir com sua a sua visão e experiências. Diferente do modelo tradicional, o SCRUM não tem um gerente de projeto e é um grande choque de paradigma para quem não conhece esse framework, porém não implica que o projeto não está sendo gerenciado. Ao contrário! Com todo o time comprometido e se auto gerenciando, nós ampliamos a gestão e responsabilidades, proporcionando aumento da produtividade, satisfação e comprometimento com o resultado.

Em cima dessa cultura é que temos três papeis no Scrum: Product Owner (PO), Scrum Master (SM) e Team. O PO é o responsável pelo negócio, o SCRUM Master pelo processo e o Team auto gerenciável pela transformação do valor de negócio em software empregável.

O principal problema hoje em uma implantação de SCRUM é justamente o compartilhamento da cultura ágil em toda a organização. Daí ser muito comum o surgimento do “Gerente Master” que na maioria dos casos é o antigo gerente de projeto que pegou alguns termos do SCRUM e está fazendo a sua implantação digamos personalizada divergindo completamente dos princípios. Na prática o Gerente Master tenta fazer as mesmas coisas que já faziam antes usando agora novas palavras.

No SCRUM não temos o papel do gerente de projeto como uma pessoa dedicada e sim compartilhado entre todos do Team. Esse conflito é clássico e só faz repetir os problemas que já citamos no inicio. Os principais benefícios de um projeto é fazer as pessoas trabalharem motivadas e integradas e vejo sem dúvida como um dos diferenciais conquistados em implantações de SCRUM sem Gerente Master é claro.

É comum me perguntarem o que fazer com o gerente, até por que pagam mais para ele e não para as pessoas que constroem o valor de negócio. É importante entender que estamos falando de uma estrutura hierárquica baseada no projeto sem relação com o cargo na empresa. Você pode alocar o gerente para qualquer ação na estrutura organizacional da empresa. Apenas ele não deve interferir no projeto de desenvolvimento como gerente.

Quando o antigo gerente tem a maturidade de entender que é mais importante ter o projeto entregue com qualidade, no prazo e com Te
am integrado e satisfeito, o fator ‘poder’ não fará importância para ele uma vez que vale mais o projeto entregue. Daí nesse contexto ele pode sim ser um líder do projeto com o papel de SCRUM Master ajudando o Team nos vários impedimentos que ocorrem no dia a dia respeitando a autonomia do mesmo.

Os ciclos de desenvolvimento no SCRUM são curtos e podem variar de 2 a 4 semanas conhecidos como  “Sprint”. Esse é mais um grande valor agregado uma vez que o cliente pode mudar a visão dele sempre que necessário e já entrar em implementação no próximo Sprint. Com isso do ponto de vista de gestão com entregas curtas teremos feedback rápidos da evolução do projeto.

Esteja aberto a quebrar os paradigmas tradicionais e vai descobrir o quanto terá de economia no projeto criando funcionalidades que realmente serão utilizadas pelos clientes, além de conquistar um grupo unido construindo software e superando todos os desafios que emergem no dia a dia de qualquer projeto.

Acabou de ler? Então convido você a participar nos comentários.

[],
Ramon Durães
Especialista em desenvolvimento de software
MVP, Visual Studio ALM
PSM, Professional Scrum Master
PSD, Professional Scrum Developer