SPOILER ALERT – Para você que bateu o olho neste textão e achou TLTR (ou Too Long To Read), incluí uma tabela comparativa ao final, como resumo do blog post.

Divide et impera – Dividir para conquistar. César, Napoleão e outros grandes gestores provavelmente não construíam EAPs (Estrutura analítica do projeto) e nem montavam Story Maps com post-its para planejar a conquista de territórios bárbaros, mas já utilizavam o conceito que está por trás dessas técnicas: quebrar partes maiores de escopo em partes menores e mais gerenciáveis.

Vamos ser humildes e assumir: não dá para assoviar e chupar cana ao mesmo tempo. Embora eu mesmo nunca tenha tentado realizar essa proeza, penso que esse dito popular expressa bem a ideia de que nossa limitada mente humana não é muito boa na execução de várias tarefas simultâneas e muito menos no planejamento de vários assuntos ao mesmo tempo. Nosso cérebro pode até ser um processador super-poderoso, mas ainda assim tem apenas um único núcleo.

Pensar em estratégias de solução de problemas grandes e complexos é uma tarefa quase impossível, porque envolve atacar diversos aspectos desses problemas ao mesmo tempo. Por isso, dividir o escopo de um empreendimento em partes menores e mais gerenciáveis é a estratégia que vem obtendo o maior grau de sucesso na História, pois nos permite focar em uma coisa por vez, respeitando assim nosso limite humano de processamento.

Além de aliviar as coisas pro nosso cérebro, essa estratégia tem outras vantagens como prevenir o famoso scope creep, um dos maiores vilões na gestão de qualquer iniciativa, e facilitar o gerenciamento da execução, etapa em que o produto é construído. Não quero deixar este textão ainda maior então não vou me aprofundar nos aspectos da construção, mas tem uma coisa que eu tenho que destacar: uma estratégia eficiente de execução depende necessariamente da quebra desse escopo em pedaços menores. Como dizem os adeptos do método Kanban: o problema não é o Waterfall, é o tamanho do lote que é grande demais.

Para fazer a divisão descrita acima, o PMBoK apresenta a EAP – Estrutura analítica do projeto, do inglês WBS – Work Breakdown Structure. Você pode até ter desconfiado, mas não foi a galera da Sessão da Tarde que fez essa tradução. Talvez o melhor seria “Estrutura do projeto quebradinho”, mas o termo “analítico” é mais apreciado no erudito e rebuscado idioma Consultês Erudito, aquele que os consultores do passado usavam para dificultar a comunicação com o cliente e parecerem mais sábios do que realmente eram. Já nos projetos ágeis, a técnica mais comumente utilizada é o Story Mapping – Mapeamento de histórias. Felizmente ainda não inventaram uma tradução a là “Estrutura analítica das histórias”.

Apesar de ambas as técnicas serem baseadas no conceito de break down – que significa quebrar em pedaços menores, apesar de às vezes esse trabalho dar vontade de chorar –  sua aplicação e abrangência são diferentes. Essa diferença faz com que essas técnicas possam ser usadas de maneira complementar, com uma cobrindo os pontos fracos da outra. Logo, conhecer as nuances das duas ferramentas pode ajudar meus amigos PMPs a gerenciar melhor seus projetos, assim como  conhecer a EAP pode abrir a mente dos meus amigos agilistas para dimensões que nem sempre são consideradas em iniciativas ágeis. O intuito desse texto não é ensinar a usar uma técnica ou outra. É apenas compará-las e provocar os leitores a abrirem a mente e a se aventurarem na utilização de técnicas diferentes. Portanto, adotei a licença poética de simplificar alguns conceitos para facilitar a comparação, ok? Não precisa me xingar nos comentários.

Como eu sou fã de Kanban e do algoritmo FIFO (first in, first out), comecemos pelo que veio antes. A EAP é apresentada como a ferramenta para detalhar o que um projeto deve entregar, e isso é muito importante. Hoje em dia, o termo “projeto” virou sinônimo de iniciativa, mas idealmente, esse projeto é uma iniciativa com início, meio e fim. Ou seja, pro PMBoK, não basta ser iniciativa, tem que ter a “terminativa” também. Esse conceito marca a gestão de projetos de forma tão importante que, parafraseando o professor Rodrigo Caixeta lá da ProjectLab: “É melhor um fim horroroso do que um horror sem fim“. Por isso, apesar de ter algum nível de flexibilidade e estar sujeito à mudanças ao longo do projeto, o escopo tem um limite, porque o projeto tem um limite.

Um dos motivadores da utilização de métodos ágeis é a volatilidade que o mercado imprime aos projetos. Esperar um marco tão raro quanto o fim do projeto para tomar decisões e reavaliar estratégias pode levar ao desperdício. Às vezes, quando um produto é entregue, já não faz mais sentido. Por isso, quando usamos ferramentas mais ágeis como o mapa de histórias, ou melhor, Story Mapping, o fim do projeto, ou o limite do escopo não é tão importante pois essa técnica tem uma visão mais abrangente, mais próxima do ciclo de vida de um produto (não quer dizer que não exista expectativa por prazo; depois cheque esse blogpost aqui). O ciclo de vida de um produto é afetado por diversos projetos com objetivo de evoluir esse produto. O mapa de histórias pode representar, entre outras coisas, o escopo do roadmap de evolução deste produto.

Numa abordagem híbrida da visão de roadmap, cada pequeno incremento na evolução do produto é realizado por uma iteração, que pode ser representada por um projeto (ou fase de um projeto), que por sua vez, pode ser representado por uma EAP, mais ou menos como demonstrado na figura abaixo:

Visualmente, a EAP é representada como um organograma, onde todo o escopo é “subordinado” ao projeto. Embora a EAP seja um artefato atemporal, isto é, sem relação com o cronograma do projeto e com a ordem em que devem acontecer as entregas, seus primeiros níveis não representam pacotes em si, mas sim divisões lógicas que buscam organizar a estratégia de entrega do escopo do projeto. Num segundo nível de divisão estão os grupos de pacotes (ou produtos). Os pacotes de entrega, ou seja, o escopo em si, são representados no último nível da EAP, mais ou menos assim:

Embora exista um certo preconceito contra o gerente de projetos “tradicional” e muita gente acredite que para o PMBoK seja função desse gerente elaborar a EAP sozinho, a verdade é que o processo de construção da EAP, a exemplo do Story Mapping, deve ser feita de forma iterativa e colaborativa com a equipe do projeto e das principais partes interessadas. A diferença é que o processo iterativo de planejamento descrito no PMBoK recomenda que a construção da EAP passeie por todas as áreas de conhecimento do projeto, ou seja, ao elaborar o cronograma, estratégia de gestão de riscos, gestão de pessoas, contratos e terceirização, gestão de partes interessadas, gestão de qualidade, gestão de comunicação, gestão de custos etc., dando visibilidade a outras dimensões do projeto, que técnicas mais light acabam ignorando.

A técnica de construção da EAP tem o objetivo final de gerar um baseline do escopo do projeto ou de parte dele. Ou seja, a partir da construção deste artefato, é gerado um compromisso para o projeto ou para uma fase do projeto.  Outra ideia falsa que é espalhada em conferências mundo afora, é a que os processos do PMBoK tornem necessário fazer um “waterfall” e construir todo a EAP detalhada do projeto de uma vez só. A EAP também pode ser elaborada iterativa e incrementalmente, por fase de projeto, onda, sprint etc., e permitir a descoberta gradual do escopo. No meu ponto de vista, a principal desvantagem da EAP em relação ao Story Mapping é que a obrigatoriedade de um compromisso com os pacotes da EAP não permite uma visão clara de priorização, dado que todos os pacotes tem a mesma importância. Como consequência da ausência dessa visão, o time do projeto pode ser direcionado a entregar tudo o que foi mapeado, mesmo que em dado momento do projeto esses pacotes não façam mais sentido.

O Story Mapping não traz a ideia do compromisso representado pela EAP de maneira tão forte. Essa flexibilidade tem origem no próprio manifesto ágil que foca em “responder à mudanças mais do que seguir um plano“. Isto é, mais do que uma ferramenta de levantamento de escopo, o Mapa de Histórias é uma ferramenta  para maximização do valor entregue por esse escopo. O ponto de comprometimento depende muito mais do método de trabalho adotado pela equipe; Por exemplo, pode ocorrer no “Replenishing” do Kanban ou no “Sprint Planning” do Scrum.

Existem diversas formas de representar um mapa de histórias. Uma das versões mais comuns apresenta pelo menos duas dimensões temporais. A primeira dimensão temporal é chamada de Backbone – espinha dorsal. Ela representa o fluxo de valor e fica logo ao topo do mapa. O fluxo de valor é lido da esquerda para a direita e é escrito na ordem em que acontecem as grandes atividades que o usuário poderia realizar. Esse fluxo é dividido para representar o passo a passo daquela grande atividade. Essa divisão é chamada de “esqueleto andante”. Para cada atividade, são mapeadas as histórias de usuário, essas sim representando “requisitos” ou “características” do produto.

Um dos princípios do Manifesto Ágil é a  Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. O mapa de histórias provoca a discussão sobre MVP – Minimum Viable Products, ou “Produtos Mínimos Viáveis”. Numa visão simplificada, esses produtos representam um agrupamento de histórias e features que visam entregar a menor quantidade de escopo possível para que seja realizado um lançamento (release) que traga valor para produto, do ponto de vista do cliente/usuário. Pelo lançamento “minimizado”, é possível testar se o produto entrega o valor esperado. Mais ainda, é possível obter o feedback do produto final e assim re-priorizar o escopo do projeto. Dessa maneira o Story Mapping direciona a eficiência (fazer menos) com a eficácia (fazer o que é preciso).

O Story Mapping foca no valor entregue para o usuário final, mas não considera por exemplo, a influência de outras partes interessadas da organização e seu impacto no processo de construção em si. Uma estrutura mais completa como a EAP garante que além do usuário final, será entregue valor a todos os envolvidos no projeto, gerenciando expectativas e outros aspectos políticos,  pois ela reconhece a existência de duas origens distintas de escopo: o Escopo do Produto e o Escopo do Projeto. Por exemplo, considere que seu projeto precisa entregar um Ovo para gerar valor para o cliente final. Tá, é um exemplo besta, mas é fácil de entender e simples de desenhar:

Um Story Mapping mapearia esse ovo. A EAP iria mais além: mapear o Ovo, mas também mapearia a necessidade de Construção da Galinha, o que pode ser um processo bem mais complexo que o Ovo em si. Note que frequentemente existe certa frustração por parte dos times de projetos ágeis, pois os aspectos da Galinha frequentemente limitam e bloqueiam a evolução da entregas do Ovo. Principalmente quando deparado com um projeto híbrido ou em escala organizacional é bastante comum que a equipe do projeto tenha que entregar coisas chatas e complexas como:

• Infra-estrutura e outros viabilizadores;
• Especificações técnicas padronizadas ou documentos de passagem (hand-off);
• Documentos obrigatórios de regulamentação como evidências de teste;
• Apresentações de relatórios de status, progresso ou previsões;
• Entregáveis de transição do produto/processo para operação;
• Itens de resposta a riscos;
• Itens de melhoria contínua do projeto;
• Participação em reuniões, comitês de controle etc.

Pode até ser que esses itens estejam relacionados à alguma das histórias mapeadas quando se utiliza a técnica de Story Mapping, mas constantemente eles são independentes dessa entregas e acabam negligenciadas pelos líderes de projetos ágeis, até mesmo quando estão dentro do alcance da própria equipe. Por exemplo: Vamos supor que você está usando uma abordagem Ágil e faz uma retrô com a galera do seu time e levanta um monte de planos de ação para serem implementados. Tecnicamente, esses planos passam a fazer parte do escopo do seu projeto, só que não fazem parte do seu Story Mapping, pois não têm relação nenhuma com o produto final. Se você usar a “filosofia” da EAP, dará visibilidade para esse novo escopo, para poder gerenciar sua implementação. Você pode , por exemplo, criar “cards” no seu board para acompanhar os planos de ação que foram levantados. Se você usa Scrum, pode ter uma ideia de quantas melhorias consegue implementar por  Sprint. Se você usa Kanban, poderá até mesmo medir o “lead time” de implementação desses planos pra ter uma ideia de qual seria a cadência ideal para realização de retrospectivas.

Sabemos que uma vez definido o escopo, seja ele para o projeto, para uma fase do projeto, para uma iteração, sprint, para um release, ou mesmo numa abordagem de fluxo puxado, no momento imediatamente anterior ao comprometimento com o início construção do produto, é necessário um nível de detalhamento maior do que essas técnicas apresentadas acima oferecem. Ah! Em tempo, se você conhece alguém que acha que em Ágil não existe documentação, recomende ao estimado coleguinha a leitura atenta da declaração do manifesto “produto funcionando mais do que documentação“.

A EAP, por exemplo, é complementada pelo “dicionário da EAP”, que descreve detalhadamente cada um dos pacotes de entrega e seus requisitos. No Story Mapping  comumente se utiliza a técnica de “Histórias de Usuário”. Mais uma vez, essas técnicas não são excludentes. É valiosíssimo por exemplo, descrever os requisitos dos pacotes da EAP usando o padrão de histórias de usuário.

Uma outra similaridade entre as técnicas está no fato de que, ao final do planejamento, seja usando EAP ou Mapa de Histórias, a equipe de projetos terminará no nível “nuclear” de tarefas. Tarefas são indivisíveis, e são elas que determinam qual é de fato o trabalho necessário para que o escopo seja produzido. Definidas as tarefas, podemos parar de quebrar o escopo.

Como gestor de projeto agnóstico, gostaria apenas de deixar um alerta: independentemente da técnica utilizada, a tendência em escrever contratos, ou detalhamento exagerado dos requisitos de forma textual, pode resultar em falhas de interpretação. Esse é o tipo do excesso sobre o qual o manifesto ágil se refere. Se você não entender que o grande valor do mapeamento está na colaboração, discussão e alinhamento, não importa se usa a abordagem dita tradicional ou ágil, poderá cair nessa armadilha.

Outro ponto de atenção é que a EAP é uma abordagem suficiente genérica para qualquer tipo de problema. Embora eu acredite e tenha acompanhado sua utilização para outros tipos de iniciativa, o mapa de histórias é amplamente difundido e testado em software. É muito provável que seja aplicável para qualquer tipo de trabalho do conhecimento, ou seja, aquele que não produz entregáveis materiais físicos. Esse “talvez” está sendo amplamente discutido e testado atualmente.

Por fim, ambas as abordagens devem ser encaradas como ferramentas. Um bom gestor de projetos deve construir seu portfólio de ferramentas independente de vieses conceituais a apego a uma abordagem ou outra. Dessa forma, poderá adaptar a gestão de sua iniciativa ao contexto em que ela está inserida.

Esse blog post  faz parte da série Agile para PMPs, PMBoK para agilistas, na qual comparo as principais técnicas de gestão das abordagens tradicional e Ágil para que os gestores de projetos possam tirar proveito de uma abordagem híbrida e agnóstica. E você, que ferramentas e técnicas tem usado na gestão do escopo de seus projetos?

Abaixo, segue a tabela resumo comparativa das principais características discutidas nesse texto: