Construir grandes sistemas determinou um modelo de gestão de projetos baseado no planejamento, acompanhamento e controle de sua execução

Origem da gestão dos projetos

A partir da 2a Guerra Mundial e dos anos 50, a execução de grandes projetos militares trouxe a necessidade de uma melhor gestão das atividades, equipes e disciplinas diversas, presentes na construção de novos artefatos, obras ou produtos. Nos anos 60 a indústria automobilística também começou a aplicar novas técnicas na coordenação e sincronização dos trabalhos em projetos complexos a envolver diferentes áreas e engenharias.

Estouro de prazos e custos e funcionalidades deficientes eram problemas que começavam a se repetir, e com grande impacto nos resultados. Como resposta a esse quadro, organizações surgiram com o objetivo de desenvolver um corpo de conhecimentos e práticas para uma melhor gestão de projetos, que visa prover maiores garantias de previsibilidade desses resultados. Nessa época, se formaram organizações como o Project Management Institute (PMI) e o International Project Management Association (IPMA) com tal intuito. Mais tarde, em 1989 Prince2 evoluiu de uma metodologia de gestão de projetos de Tecnologia de Informação para uma organização orientada a prover um modelo de referência de gestão de projetos de qualquer natureza.

Gestão de projetos preditiva

A necessidade de se construir grandes sistemas e obras com maior previsibilidade determinou um modelo de gestão de projetos baseado no planejamento, acompanhamento e controle de sua execução. A partir de uma descrição detalhada dos planos, requisitos e cronograma de atividades, o gestor do projeto busca garantir de que o produto final atenderá os custos, funcionalidades, níveis de qualidade e prazos inicialmente desenhados.

Tal gestão orientada por um planejamento pormenorizado e seu estrito seguimento, que tem como base o conhecimento a priori dos requisitos e funcionalidades que a obra ou o sistema deve contemplar, é dita preditiva. É assim denominada por predizer em alto nível de detalhe o que será feito, quais datas serão perseguidas, qual sequência das atividades será executada e quais os custos e recursos necessários para sua consecução serão empregados. Também a qualidade é um objetivo que deve ser definido em tempo de planejamento.

O novo cenário de desenvolvimento de novos produtos

Nos anos 80, as empresas começam a perceber que os conceitos de custos reduzidos, alta qualidade e diferenciação, como modelo de posicionamento de marketing, não são mais suficientes para competir em um mercado de incertezas e de consumidores desejosos de novos produtos e de novas tecnologias. Em um cenário mercadológico submetido a evoluções rápidas e de forte inovação, velocidade e flexibilidade se tornam fatores críticos de sucesso.

Para se ter sucesso em tal cenário, o mais importante não é garantir a execução de um plano inicial. Construir um produto ou sistema que forneça valor inovador, no menor tempo possível e continuamente melhorado pela retroalimentação de seu uso são chaves para que empresas como Toyota, Honda, Canon, Nec, 3M e HP se destaquem em relação à concorrência.

Assim o modelo de gestão preditivo, já em sua maturidade, não atende mais os anseios da indústria no desenvolvimento de novos produtos. Um modelo adaptativo, com foco não na previsibilidade, mas sim na experimentação e inovação, com capacidade de entregar no menor tempo possível um produto ou serviço de grande valor em contínua evolução, passa a ser adotado por organizações que obtêm melhores resultados.

Scrum: uma jogada do Rugby

Em 1986, Hirotaka Takeuchi e Ikujiro Nonaka avaliam e relatam o desempenho dessas empresas de alto desempenho no lançamento de novos produtos e publicam um artigo na Harvard Business Review, “The New New Product Development Game”.

No artigo, os autores declaram que as empresas perceberam que a competição de mercado não era mais apenas ditada pelos conceitos de qualidade elevada, custos reduzidos e diferenciação. Uma nova abordagem na gestão do desenvolvimento de novos produtos é necessária, pois a abordagem tradicional sequencial ou “relay race” pode entrar em conflito com os objetivos de máxima velocidade e flexibilidade. No lugar desta, uma abordagem holística, como na figura de uma jogada do “Rugby”, onde um time tenta avançar como uma unidade, atende melhor os requisitos de competição das empresas no cenário mercadológico atual.

Ao analisar a forma de desenvolvimento de novos produtos de empresas como Fuji-Xerox, Canon, Honda, Nec, 3M e Hewlett-Packard, que lançavam produtos de qualidade, em muito menor tempo e ajustadas às demandas dos clientes, Takeuchi e Nonaka identificaram seis características comuns aos projetos nessas organizações, a seguir descritas

1. Instabilidade interna: a equipe é desafiada com a definição dos objetivos, através de uma visão ampla dos requisitos do novo produto.
2. Times de projeto auto-organizados: a gestão fornece a direção do projeto, mas não o organiza. Para tanto, as equipes devem possuir autonomia, autossuperação e autofertilização.
3. Fases de desenvolvimento sobrepostas: as fases de desenvolvimento não são mais pautadas pelas especializações das atividades e acontecem simultaneamente.
4. Multi-aprendizagem: por enfatizar a experimentação e o conhecimento a partir de diversas fontes de informação e pela multidisciplinaridade dos membros da equipe, a aprendizagem acontece nos múltiplos níveis da organização como em suas múltiplas funcionalidades.
5. Controle sutil: a gestão do projeto exerce um controle em pontos definidos para que o ambiente de instabilidade, ambiguidade e tensão não se torne caótico. A criatividade e a espontaneidade são privilegiadas.
6. Transferência organizacional do conhecimento: a transferência do conhecimento pela multi-aprendizagem, através de um processo de “osmose”, entre os membros da equipe, promove também essa transferência ao longo da organização à medida que as pessoas participam de diferentes projetos.

Para representar esse cenário de projetos, por analogia com as equipes de Rugby, os autores cunharam o novo modelo de desenvolvimento de novos produtos, por eles identificado, como Scrum, que é uma jogada de reposição da bola ao jogo de Rugby após uma interrupção.

O cenário de desenvolvimento de software

Desde os anos 60 que se fala na “crise do software” como referência à dificuldade ou incapacidade da área de software acompanhar o ritmo de ganhos de escala que a área de hardware obtém. Já naqueles anos se percebia o desenvolvimento de software como uma atividade complexa e sofisticada, para não dizer caótica.

A aplicação da gestão de projetos no desenvolvimento de software recebeu forte atenção da comunidade nos anos 80 e se definiram os seus objetivos. A conclusão com êxito desses projetos foi caracterizada como o software entregue no prazo planejado, no orçamento planejado e a satisfazer as necessidades previstas do cliente. Desde 1994, The Standish Group, uma organização criada para coletar e compilar informações reais de projetos de Tecnologia da Informação ao redor do mundo, principalmente o quanto esses projetos são concluídos com êxito, publica periodicamente o resultado de suas pesquisas em um relatório denominado Chaos Report.

Os resultados apontados pelo Chaos Report não são nada alentadores e confirmam a “crise do software”: somente 1 em cada 3 projetos é concluído no prazo e nos orçamentos previstos e com as funcionalidades desejadas. Quase 70% dos projetos de software pesquisados foram caracterizados como problemáticos, sendo que um terço destes fracassaram.

Para aumentar ainda mais esse quadro desfavorável, The Standish Group reporta que em média dois terços das funcionalidades implementadas em um sistema depois de pronto são raramente ou até mesmo nunca utilizadas. Ao ir um pouco mais além, esse organismo destaca o gerenciamento inadequado dos requisitos do sistema como ponto chave na causa da geração desses números. A dificuldade ou incapacidade de se levantar e especificar adequadamente os requisitos, e de se manter tais especificações estáveis ao longo do projeto, é o que tem pautado historicamente os projetos de software e sua imprevisibilidade.

Métodos ágeis e Scrum

Apesar dos esforços da indústria de software em promover a gestão preditiva de projetos e adotar modelos de produção baseados em processo como fórmula para enfrentar a “crise do software”, os indicadores negativos do Chaos Report não sofreram variação significativa. Os esforços de organismos como o PMI na publicação de um corpo de conhecimentos em gestão de projetos (PMBOK), ou mesmo o Software Engineering Institute na publicação de um modelo para melhoria e avaliação de processos de software (CMMI ou Capability Maturity Model Integration), não redundaram em melhores números relatados pelo The Standish Group nem em uma mudança sensível nas experiências vivenciadas pelos clientes e usuários como um todo.

A comunidade de software começou a questionar se a causa dos problemas não era tanto por uma má aplicação das práticas, senão por uma aplicação de uma prática inapropriada. Talvez a tentativa de se garantir a previsibilidade dos resultados ao longo dos projetos, como buscavam as metodologias formais, quando os requisitos por sua vez são em essência mutáveis e instáveis, seja a base para o insucesso.

Pelos meados dos anos 90, diversos críticos a esses modelos formais de desenvolvimento de software passaram a colocar em xeque o paradigma da gestão preditiva de projetos. Perceberam que o desenvolvimento de software é melhor caracterizado pelos projetos de desenvolvimento de novos produtos da indústria em geral, do que com uma linha fabril de produção em que os insumos de entrada e o processo de produção são bem conhecidos e de fácil repetição. Perceberam que um modelo adaptativo, com foco não na previsibilidade, mas sim na experimentação e inovação, com capacidade de entregar no menor tempo possível um produto ou serviço de grande valor, seria mais efetivo.

Nessa época, foram propostas várias metodologias “leves” de desenvolvimento de software, com destaque para Scrum, Crystal Clear, Extreme Programming, Feature Driven Development e Dynamic System Development Method (DSDM), entre outras. 

Em 2001, os principais mentores dessas metodologias se reuniram e publicaram o Manifesto Ágil, no qual são apresentados os principais valores que devem nortear os projetos que usam tais modelos. A partir de então, tais metodologias passaram a ser referenciadas como métodos ágeis.

Em particular, o Scrum como método ágil de desenvolvimento de software foi apresentado oficialmente em 1995, durante um congresso, por Jeff Sutherland e Ken Schwaber, ao incorporar a abordagem holística de Hirotaka Takeuchi and Ikujiro Nonaka e aproveitar o termo cunhado em seu famoso artigo (ver acima a seção “Scrum: uma jogada do Rugby” ). Outros conceitos da indústria como Toyota Way, Lean Manufacturing, Six Sigma e 5S foram também aproveitados nos métodos ágeis.

O seu uso tem sido desde então amplamente adotado por diversas organizações de desenvolvimento de software, para diferentes projetos, pequenos e grandes, a trazer ganhos consideráveis não só de produtividade e qualidade, conforme relatos consolidados pela indústria relacionada a Scrum. Redução de custos, visibilidade, aceleração do “time-to-market”, redução de riscos e maior habilidade em gerenciar mudanças são alguns dos benefícios relatados por empresas que adotaram Scrum em seus projetos. Embaladas por esses ganhos diversas outras áreas de projeto que não o desenvolvimento de software, como saúde, marketing e agências de comunicação, estão a olhar com muita atenção a aplicação dos conceitos do Scrum em seu dia-a-dia de trabalho.

Standish Group 2018 Chaos Report

É possível também perceber o amadurecimento dos métodos ágeis através do Chaos Report do Standish Group, realizado anualmente desde 1994. Atualmente, projetos ágeis tem uma taxa de sucesso 60% maior que os não-ágeis e chama a atenção um dado contra intuitivo: projetos ágeis de grande porte sucedem duas vezes mais que os não ágeis.

The results for all projects show that agile projects enjoy a 60% greater chance of success than non-agile projects. Looking deeper, we find that “waterfall” projects are three times more likely to fail than agile projects.

When we break “agile versus non-agile” by size, we find some really interesting data. Large agile projects succeed at twice the rate of non-agile projects, and fail half as often. “Medium-agile” projects do not fare that much better (31% versus only 19% for non-agile projects). Only in the small category does non-agile come close to agile. Therefore, we conclude that size trumps agile methodology — but in combination, they can be deadly.

— Standish Group CHAOS Report Series, Decision Latency Theory

Logo, percebe-se que os métodos ágeis não são uma moda, muito menos passageira. Abraçar a mudança é uma necessidade em quase todas as áreas de negócio da atualidade. Agora, talvez mais do que nunca!

Não ser ágil, até recentemente, significava apenas ser menos competitivo, em 2021 pode significar não ser viável!