Contextualizando melhor a questão de produtos versus projetos

De acordo com o Cambridge Dictionary^[1], se traduzirmos a definição da palavra "projeto", temos:

É um trabalho planejado ou uma atividade que é finalizada em um período que pretende atingir uma proposta particular.

Isso quer dizer que você pode fazer um projeto tanto para construir um prédio quanto um software. Para deixar mais tangível, geralmente um projeto tem três pontos cruciais:

• Escopo: O escopo é tudo o que o projeto contempla. É o que deveria ser entregue ao final do deadline;
• Deadline: O deadline é a data limite de finalização do projeto;
• Budget: O budget é o limite financeiro para a execução desse projeto.

Quando vamos fazer uma obra ou construir um novo modelo de carro, é importante nos atermos ao escopo definido, nos planejarmos para não estourarmos o deadline e, principalmente, manter o budget sob controle. Em projetos desse tipo, há um começo, um meio e um fim bem definidos. Você sabe quando um prédio fica pronto e também sabe quando um carro fica pronto. Mas, se levarmos isso para o mundo do software, a coisa fica mais complexa. Por quê?

Causalidade

Como seres humanos, nós acreditamos que as coisas sairão como planejamos, pois entendemos que podemos prever o que acontecerá no futuro com base em eventos que acontecem no presente ou que já aconteceram. E isso realmente faz sentido. A ciência funciona com base na causalidade como uma das regras para prever quais serão os próximos fenômenos, levando em consideração eventos e comportamentos passados da natureza. É assim que preveem tão corretamente quando o cometa Halley vai passar para dar um “Olá” ou qual será o próximo eclipse.

Em desenvolvimento de software, isso também pode ser real. As equipes escrevem e mudam seus códigos porque entendem bem o ambiente em que o software ficará hospedado e sabem a quais processos e mecanismos esse código será submetido. A causalidade nos diz claramente o que poderá acontecer futuramente com base em coisas que aconteceram antes. Você sabe que algo pode dar certo ou errado porque você já experimentou ou porque aprendeu com a experiência de outra pessoa.

Mas nem sempre podemos contar com a precisão da causalidade. Por exemplo: mesmo sabendo o histórico de rendimentos da bolsa, nós não conseguimos prever quando ou de quanto será a próxima onda de alta (ou quando virá um Coronavírus). Mesmo sabendo os possíveis eventos que podem ocasionar a alta, você não tem como saber quando esses eventos acontecerão. É quase imprevisível. Várias crises já foram previstas, mas ninguém pode provar que uma crise realmente acontecerá, até acontecer.

Se você tem um produto, você não consegue prever quantos usuários passarão a usá-lo a partir do momento de publicação. Embora você e o time de Research tenham feito testes com usuários reais, a amostra sempre será muito pequena para saber se as pessoas usarão seu produto como o planejado. Mesmo com base em métricas e experiências de outras empresas e times de produto, não conseguimos saber com exatidão o que poderá vir a acontecer.

Ambiente complexo

Ao construir um software (e, sim, seu produto é um pedaço de software), estamos atuando em um ambiente complexo. As pessoas usam as palavras complicado e complexo como se fossem a mesma coisa, mas não são.

Algo complicado pode ser difícil e demorado para se resolver, mas geralmente pode ser resolvido seguindo processos, regras, e entendendo as restrições. Embora alguns ambientes e projetos sejam complicados, você conhece todas as variáveis (e as que você não conhece são facilmente mapeadas) e a maioria dos problemas pode já ser conhecida por causa da sua experiência e da experiência do time. Por isso, podemos prevenir que muitos problemas aconteçam (ou, caso surjam, sejam facilmente resolvidos).

Mas, quando falamos de ambientes complexos, nós não conhecemos todas as variáveis envolvidas e inter-relacionadas, de forma que os resultados dessas interações são imprevisíveis. Isso quer dizer que você não consegue prever o futuro com assertividade. Nesse ambiente, é difícil colocar métodos que trabalham com definições sem margem de replanejamento.

_"Um sistema complexo é um sistema composto por partes interconectadas que, como um todo, exibem uma ou mais propriedades (comportamentos) não óbvios a partir das partes individuais." - Jurgen Appelo, 2010

Abaixo, seguem alguns exemplos de coisas que são complexas (ou seja, elas dependem da interação de várias partes responsáveis para que funcionem):

• Seu país ou cidade: o lugar em que você mora só funciona por causa da interação política entre governo, entidades, legisladores, organizações independentes e população. Todos têm interesses em comum, mas há divergências na forma com que as ações podem transformar esses interesses em realidade;
• Empresas: há interações entre as várias áreas das empresas, funcionários, clientes e fornecedores. Se a empresa não tem um objetivo claro, um direcionamento estratégico bem definido, surgem problemas que desviam as equipes do que realmente interessa;
• Mercados: mercados, principalmente os financeiros, são sistemas complexos em que vários fatores combinados definem a interação entre os participantes;
• Tráfegos: motoristas, regras de trânsito e localização fazem com que o tráfego se transforme em um ambiente complexo;
• Propagação de doenças: pessoas contaminadas, mutações, viagens de pessoas infectadas, tempo de incubação — todos são exemplos de fatores que fazem a propagação de doenças algo imprevisível e difícil de controlar.

Algo complexo é qualquer coisa que seja conectada intrinsecamente a outros elementos que, por suas vezes, trazem resultados imprevisíveis. Sistemas Adaptativos Complexos (SAC) são sistemas dinâmicos que sabem evoluir em ambientes de constante mudança.

Um projeto, assim como um produto, faz parte de um ambiente complexo. Não estou me referindo apenas à peça de software, mas a todo o ecossistema: empresas, clientes, usuários, stakeholders, times, ferramentas etc. Todas essas variáveis fazem com que a construção de um produto digital se encaixe na categoria de coisas complexas.

Um ponto importante é que não dá para comparar outros ambientes de projetos (em uma visão mais ampla da palavra) com o ambiente isolado de software. Em um ambiente onde o resultado do esforço é um pedaço de software, o nível técnico das pessoas faz muita diferença.

Nossas mentes preferem muito mais a causalidade à complexidade. Isso é óbvio: causalidade nos dá mais segurança. Saber que eventos futuros podem não ser totalmente desconhecidos e que podemos exercer pelo menos um pouco de controle sobre eles é bem mais tranquilizador do que os efeitos imprevisíveis e não gerenciáveis que a complexidade nos proporciona.

Contudo, embora exista um nível de previsibilidade e certeza em seu produto, as circunstâncias podem mudar e o ambiente se torna mais complexo, a ponto de você precisar lidar com situações que requerem uma variedade de decisões e respostas.

Meios para tentar entender a complexidade

Existem duas ferramentas que eu uso para entender melhor momentos de complexidade e que me permitem priorizar os problemas ou ter mais clareza sobre a situação. Ambas são usadas em diversas áreas de atuação, não são exclusivas do mundo da tecnologia. São elas: Diagrama de Stacey e Cynefin.

Em um ambiente complicado, você pode e deve controlar os eventos. Em um ambiente complexo, você não controla os eventos, mas você pode influenciar o ambiente a fim de que os efeitos estejam mais próximos do que o que você e seu time conhecem.

Diagrama de Stacey

O Diagrama de Stacey foi criado por Ralph Stacey, teórico organizacional e professor de Gestão na Hertfordshire Business School, para ajudar a guiar empresas, times e líderes a gerir melhor as decisões em sistemas complexos adaptativos. Ele se baseia em níveis de certeza e acordo perante um determinado problema.

Nesse diagrama, as zonas são explicadas assim:

• Perto de acordo (agreement), perto da certeza (certainty) significa que o grupo tem certeza do que precisa ser feito, quais são os entregáveis e como fará para chegar ao resultado esperado;
• Longe do acordo, perto da certeza significa que o grupo tem certeza de como vai alcançar as tarefas, mas não concorda que essas são as tarefas corretas para se fazer. Falta equilíbrio entre eficiência e eficácia;
• Perto do acordo, longe da certeza significa que todos concordam com os entregáveis, mas não têm certeza de como cumpri-los. Compartilhar missão e visão pode dar mais clareza para o time e parar os stakeholders pode funcionar;
• Longe do acordo, longe da certeza significa que você está na área de anarquia, ou caos. Nesse lugar, você tem um alto grau de incerteza sobre o que deve ser feito e como deve ser feito. Todos discordam ainda das ideias, métodos, tarefas, objetivos, visão e missão. Ter um tempo maior de investigação, negociação e entendimento dos processos é bom para descobrir novos fatos relevantes para tentar dar mais certeza de como atacar o problema.
• Zona de complexidade (entre complicado e anarquia/caos) é o lugar onde você encontrará a maioria dos problemas no que se refere a tecnologia e construção de produtos/serviços digitais. Mas as metodologias ágeis têm o objetivo de agir bem nesse local, para facilitar e transacionar os problemas para zonas mais confortáveis, além do pensamento de produtos digitais evolutivos, que diminui o risco e a mudanças de planos. Aqui você usa inovação, criatividade e organização para conseguir diminuir a incerteza e trazer mais acordo entre stakeholders, times, usuários e negócio.

Esse diagrama, como dito, não é usado apenas na área de tecnologia, mas em qualquer situação que lide com problemas complexos e que dependem de decisões rápidas do time, dos stakeholders e também de você, como responsável pelo Produto.

No capítulo sobre priorização de backlog (que eu julgo ser uma das mais importantes tarefas, exatamente porque é onde podemos controlar o impacto rápido para o negócio e entrega de valor para o usuário), o Diagrama de Stacey pode ajudar muito ao posicionar as funcionalidades e tarefas que poderão ser implementadas no produto nas zonas em que elas mais se encaixam. Dessa forma, você consegue ter uma visão mais clara de quais ideias, oportunidades e funcionalidades ainda precisam ser investigadas melhor ou que têm uma grande quantidade de dúvidas para responder.

Cynefin: o ambiente de software é complexo? Não é bem assim.

Por causa da imprevisibilidade que a complexidade traz para o ambiente de construção de software, nós não temos certeza de que os padrões desenvolvidos no passado funcionarão da mesma forma ou terão resultados similares no futuro. Mas eu tenho que dizer uma coisa: embora eu tenha dito aqui várias vezes que o ambiente de desenvolvimento de software é complexo, na verdade ele pode navegar por outros domínios além do complexo.

Para conseguir tomar decisões, priorizar problemas e seguir em frente com mais segurança, Dave Snowden (que foi diretor na IBM europeia) criou, em 1999, um framework chamado Cynefin. A palavra Cynefin é uma palavra galesa que se pronuncia “ku-nev-in”. Seu significado literal é habitat ou lugar, mas que significa alguma coisa similar a "algo que pertence a vários". Você é influenciado por várias coisas (religião, cultura, sociedade, ambiente etc.) que formam o que você é, porém você não pertence a apenas uma dessas coisas, mas a todas ao mesmo tempo; logo, são múltiplos os fatores que nos influenciam no ambiente, de forma que nunca vamos entendê-los completamente.

Esse framework foi usado em diversas situações interessantes. Por exemplo, a Agência de Projetos de Pesquisa Avançada de Defesa dos Estados Unidos da América usou esse framework para combater o terrorismo^[2].

O Cynefin é dividido em cinco domínios:

• Contexto claro: esse contexto é caracterizado pela estabilidade e o conhecimento claro de causa e efeito, os quais podem ser facilmente identificados. Aqui as respostas aos problemas são inquestionáveis, pois todos sabem exatamente o que pode ser feito e compartilham dos mesmos conhecimentos, além de entenderem completamente os resultados gerados;
• Contexto complicado: nesse contexto, não existe apenas uma decisão e a relação de causa e efeito não é tão óbvia para todos do grupo quanto no contexto claro. Aqui nós sabemos o que não sabemos. Nós entendemos exatamente como as causas e efeitos podem ser examinados e estudados. Embora possamos ter algumas respostas corretas, o todo ainda não está muito claro e não há tantas evidências diretas de correlações;
• Contexto complexo: nesse contexto, sabemos que existe pelo menos uma resposta correta, mas essa resposta não pode ser encontrada facilmente. Uma analogia muito usada aqui é a do carro e da floresta. Um carro é algo complicado, as partes formam o todo. Um bom mecânico consegue entender bem todas as partes para consertar um problema. Já na floresta existem comportamentos independentes de diversos fatores: clima, fauna, flora, geografia, rios etc. O todo é muito maior, causando e sofrendo mais impacto do que a soma das suas partes. Aqui nós não sabemos o que não sabemos.
• Contexto caótico: nesse contexto, é impossível encontrar a relação de causa e efeito, pois eles mudam sem aviso prévio e os padrões não são gerenciáveis. Aqui é o mundo das incógnitas. Nesse contexto, nós só conseguimos tentar estancar o sangramento. Em uma situação assim, nós devemos estabelecer um nível de organização e tentar entender os sintomas e efeitos colaterais para tratá-los, mas não vamos conseguir entender os motivos e quais os gatilhos que fizeram os eventos acontecerem.
• A/C: esse é o contexto onde ficamos a maior parte do tempo. A/C significa Aporético e/ou Confuso. Ficamos a maior parte do tempo aqui, pois precisamos classificar em qual domínio o nosso problema se encaixa. Para isso, fazemos análises, conversamos, discutimos, investigamos. Quando descobrimos em qual domínio estamos, começamos a fazer o processo Cynefin para movimentar o problema pelos domínios até chegar ao claro.

O lado direito do Cynefin inclui os lados complicado e claro. Esses são os dois lados ordenados. Já no lado esquerdo estão os domínios complexo e caótico, os lados desordenados.

O grande segredo do Cynefin é: como identificamos em qual desses domínios o problema se encaixa para que façamos a transição de um domínio para o outro? Há uma ordem de movimento aí: você não consegue sair do domínio caótico e ir direto para o claro. Você precisa começar a conhecer o problema para diminuir incertezas (o que é diferente de aumentar as certezas) e o resultado disso será movimentar o problema para o domínio complexo. Depois que uma crise acontece e você aprende com os efeitos positivos e negativos, é possível caminhar para o complicado, pois agora você entende o que não sabia anteriormente e, assim, pode treinar o time e iniciar a prevenção com novas soluções e decisões para evitar que problemas similares aconteçam, transportando esses problemas para o domínio claro.

Mas o perigo ainda não terminou: esse sucesso pode fazer com que o time e os líderes caiam em uma zona de conforto, onde a impressão é a de que não existe mais nada a se fazer e que todos aprenderam tudo o que poderia ser aprendido com os problemas anteriores e, por isso, podem respirar aliviados e partir para problemas menores. Quando chegamos a esse ponto, qualquer imprevisto que acontecer pode ser um motivo para sair do domínio claro e ir direto para o caótico.

Há momentos em que não vamos conseguir identificar em qual dos quadrantes estamos e, consequentemente, não saberemos reagir ao problema. Isso quer dizer que estamos no centro, onde se localiza o A/C. É aqui que estamos na maior parte do tempo. Contudo, o desenvolvimento de software vive na transição entre os domínios complexo e complicado. Você nunca vai conseguir saber exatamente o que precisa ser feito ou prever exatamente quais os resultados negativos de determinada tarefa. São muitas variáveis para tentar controlar e por isso o seu time vai viver se movimentando por esses dois domínios.

Conforme o tempo passa e o time adquire conhecimento ao trabalharem juntos em problemas difíceis, ao passarem mais tempo se conhecendo, adquirindo confiança um no outro, alguns dos problemas serão naturalmente movidos para o domínio claro. Geralmente, quando o(a) PM traz novas demandas para alcançar novos objetivos da empresa, faz o time transitar de novo entre complexo e complicado.

Seu papel é tentar sempre diminuir as incertezas e mapear os resultados e processos o máximo possível, para que o time transite, no máximo, entre os domínios complicado e claro. É por isso que um trabalho muito bem feito no upstream, ou seja, na fase de Discovery, é essencial para que a execução seja simplificada.

Evolução: a diferença básica entre produtos digitais e projetos

De acordo com o Project Management Institute^[3] (PMI), a definição de projetos é:

Projetos são temporários por que é definido um período de começo e de fim, com limitações de escopos e recursos.

Vamos encurtar a história: um gestor de projeto tem como objetivo gerenciar a entrega para que ela seja feita a tempo, dentro do budget e com o escopo combinado. De certa forma, o GP/PMO não precisa se preocupar se o projeto vai, de fato, resolver o problema do usuário, porque, no início do projeto, alguém ou um grupo de pessoas já elencou todos os objetivos que seriam cumpridos e decidiu que o projeto, feito nesse determinado escopo, alcançaria esses objetivos. Logo, a pessoa gestora deveria apenas seguir o plano e entregar na data e dentro do budget.

Muitas vezes o pós-projeto não é planejado e geralmente a equipe que desenvolveu não é a mesma que manterá o projeto posteriormente.

Um produto digital, diferente de um projeto, leva mais em consideração a evolução do produto como meio de solução para uma necessidade ou um problema do usuário do que a contemplação de um início, meio e fim, simplesmente porque não há fim. Um time de Produtos Digitais nunca vai parar de construir e melhorar o produto, seja do ponto de vista técnico ou de negócio. Pelo contrário, ele vai se adaptar, evoluir e se modificar de acordo com as mudanças de mercado, o comportamento dos usuários e o posicionamento do negócio.

As regras de gestão de projeto NUNCA devem ser aplicadas na sua totalidade em um ambiente de desenvolvimento de serviços digitais. Por causa do fator de evolução dos serviços digitais, a gestão é forçada a ser mais maleável, levando mais em consideração o pensamento evolutivo e adaptável do que um pensamento de mudanças bruscas.

Existem alguns pontos de atenção que mudam drasticamente a forma com que gerimos um produto/serviço contínuo em vez de um projeto com começo, meio e fim. A seguir, coloco o que eu julgo serem os pilares que marcam as diferenças entre os dois mundos:

• Começamos a ter um pensamento mais amplo voltado a serviço digital em vez de produto digital;
• Criar um produto/serviço baseado no pensamento de plataforma;
• Usar o efeito de rede para amplificar o valor do produto/serviço;
• Decisões guiadas por dados e métricas de engajamento e retenção do usuário;
• Foco para entrega de valor, e não deadline ou quantidade de tarefas.

Em um produto/serviço digital, o fator de evolução muda a forma com que lidamos com os resultados, com o planejamento e, principalmente, com a organização do time.

Então, durante o processo de construção de um produto digital, nós entregamos valor para usuários reais de forma contínua, o que diminui o loop de feedback. Isso tira qualquer tipo de necessidade de planos de longo prazo, exatamente porque você descobre rápido novas informações e novos comportamentos dos usuários. Essa maneira de pensar também traz mais valor para o negócio, pois conseguimos agir e mudar de direção com mais facilidade e agilidade.

Obviamente existem similaridades: por exemplo, em projeto, nós temos um roadmap de entregas baseado em deadline; em serviços digitais, usamos um roadmap baseado em entregas de valor para o usuário e para o negócio. Enquanto a sequência em um roadmap de projeto é feita para chegarmos ao final sem grandes problemas ou mudanças no plano, o roadmap de um serviço/produto digital é planejado levando em consideração a entrega de valor e o cumprimento de metas/KPIs. Entendeu a diferença? Enquanto as entregas de um miram a completude do projeto, a do outro é o alcance de objetivos.

Há um capítulo inteiro sobre Continuous Discovery e Evolução Contínua que aborda com mais detalhes essa característica, que diferencia drasticamente cultura de produtos e de projetos.

O mindset ágil também influencia muito

Metodologias ágeis e os valores do mindset ágil podem ser aplicados tanto no desenvolvimento de um projeto quanto na construção de um produto digital. Até aí, tudo bem. Mas o papel do mindset ágil em um contexto de projeto serve para aumentar a performance de entregas do time, ou seja, para fazer o time entregar mais tarefas, mais rápido. Já no contexto evolutivo de serviços digitais, o mindset ágil será focado para potencializar e adiantar a entrega de valor para o usuário.

São duas formas muito diferentes de trabalhar: uma procura aumentar volume de entrega; a outra, qualidade e resolução de necessidades do usuário. Gerenciar um projeto com o objetivo de entregar valor para o usuário é estranho, porque o usuário só terá contato com o projeto quando ele estiver completo. Já em produtos digitais, a ideia é entregar pequenos pedaços que já trazem valor para o produto, que resolvem um problema para o usuário ou trazem valor para o negócio.

Em um projeto, é muito melhor organizar as tarefas para dar aos stakeholders uma percepção de completude do projeto. Já em um serviço digital, com mindset contínuo, as entregas devem ser organizadas de acordo com o seu impacto de valor no usuário.

Na construção de projetos, a priorização é importante para adiantar a progressão de entrega. A priorização deve levar em consideração requisitos técnicos e, também, expectativas dos stakeholders. É muito comum alguém começar pela tarefa mais difícil e que leva mais tempo. Isso faz com que os stakeholders fiquem muito tempo sem perceber uma progressão, e aí a gestão de expectativa fica mais difícil. É importante atacar coisas pequenas, que geralmente são menos complexas e mostram, de alguma forma, uma progressão rápida de completude.

Já a priorização de tarefas de produtos digitais deve levar em consideração o impacto para o negócio e solução para problemas do usuário. Isso quer dizer que tarefas que são pequenas, mas que trazem grande impacto, podem ser priorizadas antes. Contudo, nem sempre o maior impacto vem de tarefas pequenas. Nesse ponto, é importante que o time consiga, assim como em projetos, gerenciar as expectativas dos líderes e também dos usuários (dependendo do cenário).

Devo lembrar aqui (sem muitos detalhes) alguns princípios importantes e essenciais vistos no pensamento Lean:

• Eliminar o desperdício;
• Amplificar o aprendizado;
• Decidir o mais tarde possível;
• Entregar o mais rápido possível;
• Empoderar o time;
• Construir integridade;
• Enxergar o todo.

Mais à frente, no capítulo 9, Agile para Product Managers, falarei mais profundamente sobre métodos ágeis, explicando qual a minha opinião sobre o papel do PM nesse cenário.

Concluindo

Presencio todos os dias gestores tentando aplicar as regras de projeto na construção de produtos digitais. Na maioria das vezes, eles fracassam miseravelmente. Em vez de mudarem a maneira de pensar, eles culpam a complexidade dos grandes projetos e, claro, o time, por errar estimativas e por não manter um ritmo de alta performance. Esse tipo de gestor mal consegue perceber que o problema é que ele está tentando jogar o jogo com as regras trocadas.

Na minha experiência, planejar grandes projetos ou grandes entregas quase sempre dá errado.

Tenha sempre em mente: pequenas entregas de valor, monitoramento das mudanças de comportamento do usuário e ponteiros de negócios. Esses pontos são essenciais e diferenciam a construção de produtos digitais da gestão de projetos tradicional.

1. https://dictionary.cambridge.org/dictionary/english-portuguese/project ↩︎
2. BOONE, Mary E.; SNOWDEN, David J. A Leader’s Framework for Decision Making. Harvard Business Review , 2007. Disponível em: https://hbr.org/2007/11/a-leaders-framework-for-decision-making . Acesso em 22 set. 2022. ↩︎
3. WHAT is Project Management? Project Management Institute , c2022. Disponível em: https://www.pmi.org/about/learn-about-pmi/what-is-project-management . Acesso em 22 set. 2022 ↩︎