Neste artigo pretendemos desfazer a confusão que existe entre produtos, projetos e times, as três grandes peças da gestão de portfólio de produtos corporativos. Essas peças são representantes das ideias, planos de movimento e das unidades que executam todo o processo. Esse artigo é apenas o começo de uma nova série aqui no blog: “Governança de Produtos Corporativos do Séc XXI”, então continue acompanhando a gente para ter acesso a esse conteúdo e aprender mais sobre o assunto! Boa leitura!
Os Produtos
Neste contexto, o produto é a representação das ideias de um grupo de pessoas que possuem como objetivo criar ou alterar uma ou mais capacidades de negócio da organização. O formato mais comum de exibição destas idéias é o story map, que é uma representação visual que ajuda na agilidade da tomada de decisão de baixo, médio e alto nível.
Story Map
Fonte: elaborada pelo autor.
Um produto, diferente de um projeto, não tem um fim programado, já que evoluções e correções seguem acontecendo durante todo o seu ciclo de vida. Ele poderá ser desligado, mas normalmente este não é um objetivo desejado e planejado. Possui uma estrutura bem clara, normalmente composta por módulos, épicos e histórias que criam uma base, servindo também como um canal de comunicação eficiente entre as pessoas da organização.
Com o passar do tempo, conforme novas ideias vão surgindo e novas capacidades são adicionadas, este mapa vai aumentando, e será necessário cadenciar uma limpeza, mantendo apenas o que está planejado para ser feito e o histórico mais recente. Ferramentas eletrônicas podem fazer e manter as consolidações.
Como é um banco organizado de ideias, e ideia parada não gera lucro e nem contribui para a sociedade, os produtos precisam de alguns artefatos que auxiliem na transformação das ideias em capacidades concretas. Usamos os projetos para planejar esta execução.
Os Projetos
Este é o grande foco deste artigo e patinho feio de boa parte dos agilistas a ponto de inspirar a hashtag “#NoProjects” que também deu origem a um livro. O mal uso dos projetos pela gestão tradicional criou um verdadeiro trauma na maioria dos gestores atuais a ponto de algumas pessoas simplesmente não poderem mais ouvir a palavra “projeto” e criar alguns apelidos, como “iniciativas”.
Apesar deste uso inapropriado, as iniciativas possuem um significado mais adequado em algumas empresas que as usam como agrupadoras de projetos, geralmente com um objetivo maior, semelhantes aos programas do PMI. Estas empresas usam programas para mapear e planejar um fluxo contínuo e de longo prazo de atividades, enquanto usam as iniciativas para o curto e médio prazos, com algum prazo estabelecido. Não vemos problemas neste tipo de uso.
Na prática, pouco me importa se você chama de coxinha de galinha ou de projeto, o importante é que tenhamos alguma ideia sobre o que sabemos, naquele exato momento, sobre escopo e prazos.
Realidades e Planos
O motivador fundamental desse sentimento aos projetos parece estar, como apuramos, no mau uso destes artefatos pela gestão tradicional, quando tratavam com rigidez tanto o escopo quanto o prazo, engessando projeções que deveriam se adaptar ao que acontece no mundo real. Devemos adaptar os planos à realidade (a) e não a realidade ao plano (b).
Exemplos claros de (b) são as horas extras, adicionar pessoas ao time (Brooks), pressão no lead time e no throughput, mentiras, “gorduras” nas estimativas, etc. Todas as medidas, que tentam encaixar a realidade na “caixinha” do plano que foi concebido meses atrás, são frágeis e todas têm consequências graves e, em muitos casos, até mesmo mortais, para a organização.
Já os exemplos de (a) são mais simples, mas poderosos e robustos: alteração no prazo e/ou alteração no escopo. Não adianta chorar. O seu plano inicial estava errado e, não se surpreenda, era pra ser assim. Se você se comprometeu, e comprometeu a saúde da sua organização, acreditando fielmente na concretização de projeções desenvolvidas em ambiente de alta incerteza, sua gestão é frágil e ineficiente. Tanto a alta quanto a média gestão.
Se a pressão vem do cliente, temos um acordo que foi costurado de forma frágil para o prestador de serviço, indicando a falta de conhecimento de algumas premissas durante a negociação, como: em projetos com data fixa, o escopo precisará ser de alto nível e flexível; ou em projetos de escopo fixo, a data precisará ser flexível.
De novo, devido ao alto nível de incerteza no início, durante a contratação, o segundo caso, escopo rígido e data flexível é o menos comum, inclusive nas empresas mais tradicionais, já que novas descobertas acontecem no processo, mesmo que a crença dominante seja que a empresa tenha excelentes e experientes planejadores. O escopo cresce. A mudança de escopo acontecerá. Change requests são comuns.
Acordos que não seguem essa premissa são acordos ganha-perde, e para minimizar este impacto os fornecedores usam de subterfúgios, como gorduras em cima de prazos e profissionais inexperientes atuando como se fossem experientes são exemplos. É claro, se não fizerem isso, simplesmente quebram.
A consequência deste tipo de atitude é um contrato caro e cheio de desperdícios. E com a gestão do fornecedor gastando a maior parte do seu esforço tentando fechar a equação, criando não uma, mas diversas bolas de neve rolando montanha abaixo.
Olhando por esse ângulo, na verdade o que temos aqui são acordos perde-perde.
Nossa premissa básica é de que no início do processo o nível da incerteza é alto e é pra ser assim, porque um sistema só anda no cone da incerteza com execução. Quanto mais executamos de um projeto e quanto mais projetos fizermos de um determinado produto, mais conhecimentos teremos daquele produto e de todo ecossistema.
Com o passar do tempo, saberemos ainda mais como ele se comporta no seu ambiente final e, principalmente, de como a estrutura atual (times e infra) atuam juntas neste produto. A gestão das dependências e da expectativa do cliente se torna mais confortável com o passar das semanas.
Como vimos, estes projetos também podem fazer parte de uma estrutura, em que programas seriam um conjunto de projetos que visam um objetivo maior, que pode ser do produto ou de um conjunto de produtos (estratégia da organização).
Todo programa tem no seu interior projetos que estão competindo por recursos. Assim também, todo projeto tem em seu interior demandas que estão competindo por recursos.
Dificilmente você terá, em um ambiente profissional, uma demanda “isolada”, que não tenha ou gere dependências e competidores. Desta forma, uma boa gestão se preocupa com uma visão de alto nível de planejamento e controle, e não apenas com a gestão de curto prazo (imediatista) ou demandas individuais.
Tamanho dos Projetos
Sugerimos que os projetos tenham entre 2 e 6 meses de tamanho, sendo que a decisão do tamanho está em como a dinâmica dos times, que executarão esses projetos, funciona. Não usamos projetos muito pequenos porque queremos que seja possível aprender e queremos fazer ajustes no planejamento dentro do mesmo artefato, ainda em execução. Testar hipóteses de gestão e kaizens. Não usamos projetos muito grandes porque queremos a capacidade de fazer um novo planejamento, reconfigurar, também baseado no que aprendemos com o passado.
Projetos que estão iniciando, usam dados de outros projetos do mesmo produto ou do time e, caso estes dados também não existam, usamos estimativa inicial. Quanto mais distante estivermos das execuções dentro do escopo do produto, mais incerteza teremos. Mas isso não é problema, porque teremos revisões, cadenciadas e disciplinadas, de ajuste do plano original.
Este processo potencializa o aprendizado, o planejamento, o controle e a execução que leva a organização à um estado de amadurecimento natural do conhecimento sobre o produto. Não ter estes lotes maiores de planejamento trava o nosso aprendizado sobre o sistema, principalmente quanto às datas, portanto, quanto à previsibilidade.
Vamos fazer uma simulação rápida.
Simulação:
Estamos no dia 23/03/2020 e o resultado do dia será o planejamento e a configuração do Projeto Voyager. Ao fazer o story map do produto, destacando o escopo mais importante para o curto prazo, rodamos a simulação de monte carlo que nos sugeriu a data de 30/06/2020 com 80% de confiança. Agora temos o escopo pra começar e uma data alvo inicial.
O Voyager é o segundo projeto do Produto Apolo e, como estamos em uma organização que aprende, sabemos que neste produto a variação de data pode ser de até 30% do planejamento inicial. Estes dados são consolidados e informados à todos os envolvidos no projeto, sejam externos ou internos, numa reunião inicial chamada de Kick off do Projeto. Muitos no mercado já conhecem esta prática.
Após 15 dias o time de gestão se reúne e faz uma nova projeção, agora com novos dados, sobre o fim do projeto e as simulações agora apontam para o dia 30/07/2020, um mês depois.
Mas este projeto é de data fixa? Então a gestão começa a cortar escopo usando as pessoas e ferramentas necessárias para concluir essa importante tarefa. Se o corte de escopo aconteceu sem maiores problemas, a cadência da revisão continua a mesma, mas se o corte aumentou o risco do projeto, a frequência deverá ser aumentada, com um intervalo menor entre os encontros.
Na próxima revisão, a simulação resulta em 15/05/2020, permitindo que mais itens entrem no escopo.
Toda mudança no mundo real resulta em mudanças no plano. Essa é a lei. Você precisa fazer a melhor escolha para cada momento. Algumas vezes você vai precisar cortar escopo, outras vezes empurrar ou puxar o prazo. O ponto principal aqui é o processo decisório baseado em dados gerando resultados melhores e mais robustos.
A efetividade desta reunião, gerando informações relevantes usando pouco tempo, permite que ela seja executada com a frequência compatível com o perfil de risco do projeto, isto é, projetos mais arriscados possuem revisões mais frequentes.
O ponto principal aqui é: se não existisse aquele lote inicial de planejamento, não teríamos base para derivar novas informações e aprendizado. Prazo flexível não significa prazo nenhum, assim como escopo flexível também não significa escopo nenhum.
Concluímos aqui que, nesta estrutura, os projetos são os planos para colocar as ideias do produto em movimento, ajudando a transformar abstrato em concreto.
Os Times
Sejam “squads” ou apenas “times” mesmo, aqui temos as unidades de execução dos projetos. Se o projeto é o plano para colocar as ideias em movimento, os times colocam o plano em execução, refinando, executando, testando e retroalimentando com as novas ideias, geradas no com o seu trabalho. Existem algumas maneiras de organizar os times, mas não é o foco deste artigo.
Nosso objetivo aqui foi concluir que temos três verticais bem distintas quando estamos falando de organização e gestão de portfólio de projetos de software: produto, projeto e time. O produto é a estrutura de ideias, o projeto é o planejamento destas ideias e o time executa e os resultados do seu trabalho ajudam a retroalimentar o planejamento e o banco de ideias.
O que acha de entender melhor como esta estrutura se encaixa na Governança de Produtos Corporativos do Séc XXI?
Acesse agora o site da Taller, entre em contato e conheça uma das consultorias mais eficazes em potencializar times e maximizar entregas!
Curtiu o conteúdo e quer ampliar ainda mais seu conhecimento?
Então aproveita e confira outros conteúdos que o Celso Martins também produziu:
Blog Post: Equilíbrio do Portfólio – Como lidar com a manutenção? →