Em artigo anterior onde apresentei uma perspectiva sobre os recentes layoffs massivos em tecnologia, arrisquei a queda de alguns “disjuntores” cabeça daqueles que pensam de forma dicotômica, binária, e que declaram a morte do gerenciamento de projeto em favor do gerenciamento orientado a produto.
Sugeri que poderia ser o foco de outro artigo, para que não tivesse que me estender naquele momento, com o porquê acho esta comparação desconsidera vários aspectos, sob vários prismas. Em última análise, tratando-se, portanto, de uma espécie de engodo.
Que fique claro — não se trata aqui de menosprezar a importância e o avanço que o gerenciamento orientado a produto trouxe. Mais do que relevante, ele é realmente uma forma de pensar e trabalhar muito mais alinhada ao contexto em que vivemos, exponencialmente mais quando falamos de produto digital, e os infinitos caminhos possíveis que este pode tomar.
Mas, na minha visão, é preciso recuperar ao menos parte do prestígio que o bom e velho gerenciamento de projeto já teve. Até porque ambas as disciplinas podem ser amplamente complementares, pois sequer precisam atuar no mesmo nível ou granularidade no processo de execução.
Aqui você pode estar se perguntando “mas então por que se fala tanto da necessidade de uma espécie de “virada de chave” da operação de projetos para produtos?”
Como costuma ser o caso, tudo começa com uma boa e louvável intenção. No caso, de se comprometer menos com um escopo definido e mais com o resultado (outcome) que o produto deve gerar. É a famosa discussão output vs outcome (que por extrapolação espero dissuadi-lo de que também se trata de uma discussão mais ou menos besta, desnecessária, ainda que o foco em outcome seja crucial no pensamento do produto).
Acredito que ninguém em sã consciência questiona esta abordagem e lógica. Seria um risco gigante de oportunidades (e em última análise, dinheiro) desperdiçadas não operar desta forma, não aproveitar as vantagens que o pensamento orientado a produto traz, ainda mais no contexto de produto digital.
Então o ponto não é sobre questionar a premissa fundamental de pensamento de produto e as metas orientadas a resultado, mas do risco de, como diz a expressão famosa no inglês, “se jogar o bebê com a água do banho” ao descartar a relevância da disciplina de gerenciamento de projeto sob o prisma correto e no contexto adequado. Em outras palavras, desconsiderar que pode não se tratar de um ou outro, mas de utilizar a disciplina de gerenciamento de projeto como algo complementar ao pensamento e gerenciamento orientado a produto.
Complementar na medida em que permite:
- Sistematicamente quebrar e gerenciar pacotes de trabalho desenhados nas etapas de Discovery, de modo que se reduza as incertezas para a parte do fluxo em que precisamos de eficiência (que é no Delivery);
- Ter acesso a uma série de práticas que podem auxiliar a execução de diversas atividades, em diferentes níveis de granularidade e contextos;
- E.g., (a) todo ciclo de produto pode ser concebido como uma espécie de projeto, no sentido de que terá um fim e que entregas em todo o ciclo necessitam ser gerenciadas; (b) alguns podem argumentar que o ciclo da própria empresa é como um projeto também; (c) e seguramente que em várias etapas ou atividades mesmo no fluxo de trabalho ligado a melhorias, ou novas entregas ligado ao produto há a necessidade de gerenciar a entrega de algo, um output.
Acredito que uma boa forma de conceber, ou pensar esta interação entre gerenciamento de projeto e produto, se pensarmos especificamente só no contexto da execução ligada a um produto específico, é a de um entrelace entre quando necessitamos abraçar a complexidade e quando necessitamos reduzi-la...
O pensamento orientado a produto é primordialmente o reconhecimento e a compreensão de que nem sempre as relações de causa e efeito são bem conhecidas de antemão, e que precisamos trabalhar probabilisticamente, e aceitar o mundo em sua complexidade e incertezas.
Muita confusão gera ansiedade e dificulta o progresso — por isso, em algum momento, é preciso convergir e reduzir o nível de incerteza, como o enfoque numa hipótese (ou ideia) específica, com o desenho de possível solução (ou entregável) que é eventualmente gerenciado e completado, tal qual um projeto.
Se você observar, e a título de exemplo, alguns frameworks bem conhecidos que ajudam a estruturar o processo de planejamento de produto (ou roadmap), trazem esta ideia embutida, e adotam padrões de gerenciamento de projeto no processo de quebra e movimento de entregáveis para a execução:
- A Árvore de Oportunidade (Opportunity Tree) da Teresa Torres fala de soluções e experimentos, como forma de tangibilizar os níveis de entregáveis associados a uma oportunidade mapeada;
- O GIST framework do Itamar Gilad tem nos dois últimos níveis do modelo, o “S” de Step- projects e “T” de tasks a mesma ideia de quebra e do que move como entregáveis para a execução, dado a seleção de uma ideia concebida como hipótese para alcançar uma meta (goal).
Ao compreender essas nuances que aprendi que o dia a dia é bem menos binário, dicotômico do que muitas discussões simplificadas que vemos por aí. E como eu defini pensamento de produto como primordialmente abraçar a complexidade e as incertezas, acredito que, enquanto pessoas de produto, precisamos viver esta realidade e sermos, e exercitarmos muito menos o “isto ou aquilo” e muito mais o “isto E aquilo”.
É válido para esta discussão de projeto vs produto, ou mesmo de output vs outcome, e tantas outras coisas (e sim, eu colocaria aqui muitas das discussões ligadas à agilidade, métodos e frameworks para o processo de entrega, e coisas do tipo). Já que muitas vezes as comparações não só são como comparar “maçã com banana”, mas também um desserviço ao confrontar duas coisas que podem ser largamente complementares.
O mais legal é que existe beleza nesta confusão toda...
Em sermos mais práticos e orientados ao resultado (ou seja, interessantemente adotando uma espécie de visão meta-produto), lançando mão de técnicas e ferramentas que sejam úteis e aplicáveis no contexto. Sempre lembrando é muito raro que a aplicabilidade de certas ferramentas seja completamente independente do contexto.
