O guia completo para iniciantes no planejamento ágil de projetos

Falhar no planejamento é planejar para falhar. Esta citação do especialista em gerenciamento de tempo Alan Lakein resume perfeitamente a importância do planejamento no gerenciamento de projetos. Por mais que odiemos datas e escopos fixos no mundo ágil, é a vida cotidiana de muitas organizações, e não podemos simplesmente ignorar sua importância. 

Mesmo se sairmos do reino dos projetos de data fixa e escopo fixo e mergulharmos no mundo do desenvolvimento de produtos, o planejamento ainda é de importância crucial. A maioria dos clientes não compromete o orçamento com uma especificação aberta e exige uma data de entrega junto com a cotação. 

Assumindo tal realidade, uma pergunta natural a se fazer é: "Como criamos um plano de projeto ágil?". Esta é uma pergunta difícil, e a maioria dos materiais sobre o tópico cobre apenas a prática de desenvolvimento de software. Isso cria a impressão de que o ágil é adequado apenas para a indústria de software, mas nada poderia estar mais longe da verdade. 

O Planejamento Ágil NÃO é o Planejamento Scrum

Freqüentemente, você vai ler que o Agile Planning é igual ao Scrum Planning. No entanto, isso está longe de ser verdade. Scrum é uma estrutura prescritiva para o desenvolvimento de software que propõe uma forma concreta de planejar. É predominante no mundo do software, mas frequentemente é alvo de severas críticas.

Não entraremos em detalhes sobre por que o planejamento do Scrum é falho, pois preferimos falar sobre o pensamento ágil aplicado em vários setores e não apenas de software. É mais importante saber como aplicar técnicas e práticas genéricas no nível global da empresa, independentemente do tipo de negócio. Por enquanto, é apenas essencial saber que o Agile Planning não envolve necessariamente o framework Scrum.

Planejamento de Projeto Ágil VS Planejamento de Projeto Tradicional

No passado, os líderes empresariais gastavam muito tempo traçando planos detalhados de execução para os anos futuros. 

Por muito tempo, essa forma de planejamento funcionou perfeitamente. No entanto, à medida que os mercados se tornaram mais dinâmicos nas últimas décadas do século 20, os requisitos de negócios começaram a mudar com mais frequência, e uma forma nova e mais flexível de planejamento tornou-se necessária.

Essa necessidade tornou-se óbvia e um tanto crítica com o surgimento do trabalho do conhecimento. Enquanto apenas 50 anos atrás as pessoas trabalhavam principalmente em fábricas, hoje em dia o trabalho é feito em escritórios, onde as pessoas usam a cabeça mais do que as mãos. É um trabalho do conhecimento preciso onde um plano de projeto ágil é mais necessário. 

A principal diferença entre o planejamento ágil e a forma tradicional (também conhecida como cascata) é que a primeira é iterativa e adaptável às mudanças. Em contraste, o segundo é um processo de planejamento pesado de passo a passo. 

Devemos mencionar que ambas as abordagens têm suas virtudes. Quando você está construindo uma ponte ou um edifício, você deseja ter um plano muito detalhado e bem pensado. Aqui, aceitar os requisitos no final do processo com um plano de projeto ágil não é a abordagem mais adequada. Claro, isso pode acontecer, mas a implementação de mudanças pode ser cara. 

No entanto, no trabalho do conhecimento, a mudança é bem-vinda em qualquer fase do processo, mesmo no final. O objetivo é criar uma solução que satisfaça o cliente e tudo é permitido. Simplificando, no gerenciamento de projetos ágil, você estabelece planos detalhados apenas para intervalos de tempo mais curtos e pode facilmente fazer alterações quando necessário. 

Características do planejamento ágil de projetos 

Primeiro, vamos nos concentrar nos diferentes níveis em que você pode planejar. O "Agile Planning Onion" descreve melhor estes níveis: 

É fundamentalmente essencial entender a ideia de que o Agile Planning é aplicável a cada fatia da cebola. Você não faz o ágil apenas no nível da equipe (Dia, Iteração, Liberação). Você pode ter um serviço de gerenciamento de produto ágil, gerenciamento de portfólio ágil e estratégia ágil. Ser ágil em sua estratégia é o que define a agilidade do negócio em geral.

Como já declaramos, mas não explicamos, o planejamento ágil é iterativo. Isso significa que você desenvolve e ajusta seu plano várias vezes, conforme achar necessário. O objetivo é investir tempo no planejamento no melhor momento possível e adaptar-se facilmente às mudanças caso ocorram durante a fase de execução. 

Independentemente do nível em que você opera, seu plano de projeto ágil terá características semelhantes. Vamos explorá-los sem uma ordem específica. 

• O objetivo aos olhos de um cliente (valor) 
• Falta de detalhes sempre que puder ser evitada (comprometa-se o mais tarde possível) 
• Entregas frequentes (lote pequeno) 
• Intervalos de datas em vez de estimativas de datas únicas (probabilísticas vs. determinísticas) 
• Foco no trabalho e não no trabalhador (sem cessionários em particular, a equipe é responsável) 
• Sem fases separadas para Garantia de Qualidade (qualidade é embutida) 
• Planos de duas camadas (cronogramas para iniciativas, tarefas sem datas de início / término) 
• Orientado por dados (com base em dados históricos e simulações de Monte Carlo) 

O objetivo aos olhos de um cliente (valor) 

Um plano ágil deve considerar exatamente o que o cliente deseja. Se precisarmos emprestar um termo do dicionário Lean, usaremos a palavra valor. Em outras palavras, nosso plano deve ser claro sobre como e quando vamos entregar valor ao cliente.

Nesse sentido, quanto mais o plano estiver focado nos resultados, melhor. Se você está acostumado a colocar atividades dentro do plano, pense novamente. É crucial saber o que as pessoas fazem ou que valor elas produziram? 

Falta de detalhes sempre que puder ser evitada (comprometa-se o mais tarde possível)

Imagine que você está se preparando para uma expedição a uma alta montanha que não foi explorada antes. Você terá uma estimativa aproximada da duração da expedição para preparar comida e água suficientes. No entanto, você não saberá se existe um local adequado para acampar e nem onde esse local pode ser. 
 
Muitos projetos no campo do trabalho do conhecimento são bastante semelhantes à expedição descrita. Você sabe muito sobre o projeto com antecedência, mas não o suficiente para se comprometer com cada parte dele. No entanto, muitos gerentes insistem em ter um plano rigoroso e detalhado para cada entrega do projeto. Curiosamente, estamos descarregando o compromisso até o último momento responsável na vida real, mas não o fazemos em nosso plano de projeto. 

Entregas frequentes e ciclos de feedback rápidos (lote pequeno)

Um plano ágil deve acomodar entregas frequentes e tornar explícita a coleta de feedback. De fato, o feedback obtido deve ser refletido na próxima versão do plano, o que aumentaria a probabilidade de encerramento bem-sucedido do projeto.

Projetos são grandes lotes de trabalho por definição. No entanto, não há obrigação de entregá-los todos de uma vez. A maioria dos clientes gostaria de ter uma prévia dos resultados para garantir que o projeto não se desvie muito do que eles esperam.

Suponha que a equipe do projeto entendeu mal os requisitos e começou a trabalhar em algo completamente diferente do que você imaginou como cliente. Você prefere dar feedback cedo ou esperar até o prazo final do projeto? É mais do que natural dar feedback no início do ciclo e evitar o desperdício de tempo e recursos preciosos. 

Intervalos de datas em vez de estimativas de datas únicas (probabilísticas vs. determinísticas) 

Quando os clientes perguntam sobre a duração do projeto, eles geralmente esperam uma data fixa. Mas você ficaria surpreso com a quantidade de clientes que aprovariam se você fornecesse um intervalo de datas em vez de uma única data. 

Como se costuma dizer, é melhor estar quase certo do que estar precisamente errado. E é isso que encorajamos todos a fazer - use intervalos de datas com base em dados históricos e métodos de previsão para criar um cronograma de projeto ágil para o seu plano. 

Foco no trabalho e não no trabalhador (a equipe é a dona)

Isso vem da mesma perspectiva do exemplo de comprometimento tardio. Se você designar pessoas para as tarefas muito cedo, estará se arriscando a fazer a coisa errada na hora errada. Do ponto de vista de que nos preocupamos com o fluxo de trabalho e não necessariamente utilizando todos os trabalhadores a 100%, não há problema em deixar a equipe se auto-organizar em torno do projeto.

É certamente verdade que você tem especialistas na equipe, o que cria muitas dependências, especialmente em empresas maiores. A resposta natural de um treinador ágil seria eliminar as dependências, mas essa é uma resposta desligada do mundo real. Você não pode simplesmente remover todas as dependências sem criar uma tonelada de problemas em outras partes da organização. 

A abordagem razoável é gerenciar dependências provenientes da visão holística de sua organização e fluxos de valor. Se o fluxo de valor para o cliente for bloqueado por causa da equipe X, é aí que você deve se concentrar, mesmo que isso signifique que a equipe Y não terá nada em que trabalhar.

 Isso é um pouco radical e requer uma mudança de paradigma, mas é um conceito fundamental no planejamento de projetos Lean e Ágil. É desnecessário dizer que, em tais situações, seu plano deve refletir o foco na resolução de bloqueios / problemas com menos foco na utilização do funcionário. 

Nenhuma fase separada para Garantia de Qualidade (Contruir com qualidade) 

A Toyota se tornou a maior fabricante de automóveis em menos de 50 anos, começando como uma pequena empresa familiar. Um dos princípios que eles usaram foi "Construir com qualidade", o que significa que nenhum tempo deve ser gasto consertando o produto após ele ter saído da linha de produção.

Seria melhor se você se esforçasse pelo mesmo nível de qualidade durante a fase de execução do projeto e, por qualquer meio, tentasse evitar uma fase final de "Garantia de Qualidade". Se você tem uma grande fase final de garantia de qualidade, provavelmente ignorou o aspecto da qualidade ao longo do ciclo de vida do projeto e, quando você entra na fase de qualidade, as coisas começam a ficar feias.

Claro, é melhor ter uma verificação de qualidade final em vez de enviar um produto com defeito, mas isso deve ser uma exceção e não a norma. 

Planos de duas camadas (planeje apenas as iniciativas e não as tarefas)

Esta é uma das características essenciais de um plano ágil eficaz. Se você tiver um plano de alto nível de todas as principais entregas (iniciativas), é fácil dividi-las em tarefas e, em seguida, passá-las para as equipes de execução reais.

Embora possa parecer trivial, representa uma diferença substancial em comparação com os planos de gráfico de Gantt tradicionais. Quando você divide uma iniciativa (entrega do projeto) em suas tarefas abrangentes, recomendamos que nenhuma data de início e término seja determinada para as tarefas, a menos que seja necessário.

Por exemplo, uma tarefa que representa a criação de cartazes para um concerto seria inútil após o concerto, por isso deve ter um prazo vinculado a ela. No entanto, na maioria das vezes, as tarefas não têm um prazo real.

Ao ignorar as datas de início / término de todas as tarefas individuais, você permite que suas equipes obtenham novos trabalhos quando tiverem capacidade e não quando você pensou que deveriam ter. A palavra PUXAR aqui é usada propositalmente, pois ilustra o princípio PUXAR que conhecemos tão bem da Toyota.

O fato de você colocar datas de início e término para a iniciativa, mas omitir as datas de suas tarefas filhas, separa o planejamento da execução. Desta forma, você mantém o plano de projeto ágil em termos de tempo e comprometimento, mas permite que suas equipes tomem a decisão ideal, pois são as que mais se aproximam dos detalhes técnicos da obra.

Decisões baseadas em dados (use seus dados históricos para planejar o futuro)

Se você usar o método Kanban para executar as tarefas diárias em suas equipes, é fácil empregar métodos estatísticos para previsões baseadas em dados. Um desses métodos amplamente utilizado no mundo ágil são as chamadas simulações de Monte Carlo.

As simulações de Monte Carlo tomam como entrada dados históricos (rendimento e tempo de ciclo). Então, com a ajuda de algoritmos matemáticos, simule milhares de resultados possíveis para o seu projeto. Depois de avaliar todos os resultados possíveis, a simulação de Monte Carlo fornece informações sobre as datas potenciais de conclusão do projeto com alguma probabilidade associada à previsão.

Por exemplo, uma simulação de Monte Carlo pode prever uma probabilidade de 85% de que seu projeto será concluído em 2 de julho. Como alternativa, a previsão pode dizer que há uma probabilidade de 95% de que você entregará 200 tarefas ou mais dentro do seu prazo. Isso dá uma boa indicação sobre o status do projeto e é inteiramente baseado em estatísticas, o que pode evitar o trabalho de estimar todas as tarefas uma por uma. 

Ferramentas como Kanbanize combinam essa ideia com a anterior (planos de duas camadas) para criar um sistema de previsão contínua que informa aos gerentes o status real de todos os projetos e suas entregas. Plataforma de software do Businessmap estende esse tipo de previsão contínua para o nível do portfólio, pois é fácil ver uma previsão em tempo real de todos os projetos no portfólio. Tudo o que você precisa fazer é executar as tarefas diárias em um conjunto de quadros Kanban da equipe e conectá-los aos projetos pais. 

Exemplo de plano de projeto ágil

Como já discutimos as características do planejamento ágil, vamos ver um exemplo prático de construção de um plano ágil e como o fazemos no Businessmap. 

Definindo as principais entregas ou lançamentos do projeto

Digamos que temos que planejar a criação de um novo site. Como o escopo para isso é muito grande, a primeira coisa que faríamos é definir diferentes partes funcionais (entregas) que serão continuamente liberadas para o mercado.

Aqui, devemos observar que não planejamos as entregas em detalhes. Um plano de projeto ágil deixa isso para o "último momento responsável" e o inclui progressivamente ao longo do projeto. Isso nos poupará o tempo desperdiçado com planejamento desnecessário e nos ajudará a manter a agilidade para quaisquer mudanças emergentes. 

Para construir um roteiro para a execução das entregas, você pode usar um cronograma de projeto ágil. No Businessmap, por exemplo, usamos uma linha do tempo Kanban (como visto a seguir) para fazer isso. Você pode então inserir uma ou mais entregas a serem executadas em paralelo ou visualizar uma sequência quando algumas delas dependerem umas das outras. 

Quebras em tarefas 

Assim que tivermos as principais partes funcionais do projeto visualizadas em uma visão semelhante a um roteiro, nosso próximo passo seria dividi-las em tarefas individuais. À medida que elaboramos nossos planos ágeis progressivamente, começaremos com as entregas mais críticas neste ponto.

Para visualizar as tarefas e seu fluxo até a conclusão, você pode usar um quadro Kanban dedicado. No Businessmap, conectamos a linha do tempo do ágil contendo o roadmap do projeto e o quadro Kanban, conforme visto a seguir.

Isso dá uma visão incomparável de todo o andamento do projeto, do conceito à fruição. Como resultado, podemos ver quais entregas estão em andamento, seu status e quem está trabalhando em quê em um determinado momento. Essa configuração também nos permite colaborar uns com os outros quando as tarefas ficam travadas no processo e resolver os problemas mais rapidamente. 

Por meio do conceito de planejamento "just in time", podemos manter a agilidade para quaisquer mudanças de última hora, requisitos emergentes ou mudança de prioridades. Isso nos permite satisfazer melhor as necessidades do cliente com a entrega de nossos projetos. 

In Summary

O planejamento ágil é uma maneira nova e flexível de organizar projetos futuros e se ajustar às mudanças de requisitos sem gerar desperdício. Estas são as características mais importantes de um bom plano ágil: 

• Objetivo do ponto de vista de um cliente 
• Falta de detalhes sempre que pode ser evitada 
• Entregas frequentes 
• Intervalos de datas em vez de estimativas de datas únicas 
• Foco no trabalho e não no trabalhador 
• Nenhuma fase separada para garantia de qualidade 
• Planos de duas camadas 
• Baseado em dados