Priorização, parte I: o que interessa
Em uma série de dois textos, vamos (1) abordar como priorização pode ser consequência de questões maiores e (2) passar pelos muitos frameworks utilizados na tarefa
É quase um mantra dizer que priorização é uma das principais dores da Gestão de Produtos. Também acaba afetando o Design, o Desenvolvimento de Software e outras áreas de negócios. No macro, relaciona-se a escolhas que temos de fazer como sociedades, como organizações e como indivíduos.
Tem a ver com uma das dimensões mais fundamentais da vida, o tempo, ou, de forma ampla, com recursos, principalmente suas restrições. É passível de ser tratada economicamente e, no extremo — mais na imaginação do que no mundo real, diga-se de passagem —, por meio de otimização matemática.
Para ficar no âmbito de Product Management (embora possa interessar a designers também), priorização costuma ser rapidamente associada aos muitos frameworks criados ao longo de décadas para lidar com ordenação de itens por importância, urgência e outros critérios.
Há uma infinidade desses artefatos, como a Matriz de Eisenhower, e pode haver até disputas para se tentar saber qual é o melhor.
Mas vamos inverter o tratamento do assunto. Em uma série de dois textos, faremos:
neste primeiro artigo, uma abordagem mais conceitual sobre priorização, mostrando que a necessidade de fazê-la pode ser apenas consequência de questões maiores de cultura, estratégia e visão de negócio;
no próximo artigo, aí sim, vamos visitar os muitos frameworks e somar algumas considerações sobre eles.
Esperamos que essa forma ajude a fornecer um quadro mais completo sobre priorização. Queremos mostrar que ele vai além de apenas dar notas a itens ou ordená-los por critérios qualitativos (às vezes, bastante subjetivos e conflitantes).
Fique à vontade para ampliar o assunto nos comentários, para avaliar a abordagem e nos ajudar a melhorar a Newsletter. Se ainda não se inscreveu, inscreva-se e receba os textos por e-mail.
Conceito
Priorização é fácil de intuir, um pouco mais difícil de explicar e pode ser bastante complicada de executar.
Etimologicamente, o dicionário Merriam-Webster diz que “priorizar” é “listar ou classificar (projetos, metas etc.) em ordem de prioridade”.
Prioridade, por sua vez, tem mais de uma definição e pode ser resumida nas seguintes:
qualidade ou estado de ser anterior (priori, que quer dizer antes no tempo, precedência);
uma classificação preferencial;
algo dado ou merecendo atenção antes de alternativas concorrentes.
Para fins de senso comum, é normal usarmos priorizar e classificar como sinônimos. Para uma definição mais rigorosa, priorizar tem a ver com ordenar itens por importância, enquanto classificar significa agrupá-los por similaridades. Nota lateral, apenas.
Priorização pode ser perfeitamente matemática, o que significa “computável”. Dados determinados itens e critérios para ordená-los em ordem decrescente (do maior ao menor) de importância, tem-se o resultado.
A dificuldade está em uma palavrinha que aparece nas definições de prioridade, aí acima: “preferencial”, que deriva de preferências.
O que é preferência para uma pessoa, pode não ser para outra. O que um grupo prefere pode ser o oposto, aquilo que outro grupo abomina.
Ideias, tarefas, coisas não vêm com um número de ordenação mágico, divino ou o quer que seja carimbado, que nos permita ter uma medida objetiva de onde devem ficar em listas ou matrizes.
Precisamos combinar entre nós essa medida para poder “computar” o que é mais ou menos importante, em uma escala.
É aí que começam os conflitos e as dores-de-cabeça de Product Managers (e Product Owners), para não falar de governantes, comandantes militares, médicos de pronto-socorro e investidores, por exemplo.
Priorização também tem a ver com risco e com alocação de recursos para execução de itens.
Recursos escassos e/ou risco alto frente a uma determinada demanda: priorização mais difícil. Recursos abundantes e/ou risco baixo frente a uma demanda: priorização mais fácil.
Recursos infinitos… mas aí seria absurdo (para começar exigiria “tempos múltiplos paralelos”, mais ou menos como mundos possíveis), o que a Física, pelo menos a Newtoniana, não nos permite.
Inexistência de riscos também pode ser desconsiderada. Não há nada que valha a pena sem risco.
Fora de produtos de software
Priorização tem muito a ver com organizações e empresas, não no conceito de empresas modernas, mas na terminologia histórica de pessoas que se juntam para dar cabo a algo com interesses em comum ou similares.
Na prática, priorização é um dos fatores táticos que decorre da estratégia que nasce com qualquer organização ou empresa, isto é, com a maneira como essa organização age, compete ou colabora com outras.
Como o exército é uma das primeiras organizações a surgir na história, é natural que muito do que se fala hoje sobre estratégia e priorização em negócios já tenha sido pensado e tratado no âmbito militar tempos antes.
Uma pesquisa rápida sobre priorização e exército mostra que há algumas preocupações fundamentais sobre o que é importante no meio militar.
Exemplo: se é mais importante pensar no presente, e manter tropas de prontidão, ou se é mais importante pensar em ameaças futuras, e desenvolver pesquisa e inteligência. Seria mais ou menos como escolher entre “remediar ou prevenir”.
Em uma batalha, há diversas tomadas de decisão que requerem priorização. Não tendo os recursos necessários ou desejados (homens, armamentos, veículos), qual ação deve ser executada antes de outras?
O conceito se torna ainda mais interessante se há várias frentes de batalha ao mesmo tempo ou se, a exemplo dos Exércitos dos EUA, da Inglaterra ou da Rússia, há várias operações em andamento ao redor do planeta.
Um pouco mais recente em termos de história, a saúde é outro campo que requer priorização. Curiosamente, ela também tem um pé na guerra: quais feridos em batalha atender primeiro em hospitais de campanha?
Um ambiente em que a priorização é crucial, em saúde, é nos pronto-socorros hospitalares. Tanto que há muitas práticas e estudos em torno de triagem e classificação de risco, como o Protocolo de Manchester, que ordena pacientes por gravidade.
Transplantes de fígado são priorizados praticamente por meio de uma fórmula matemática, que leva em conta indicadores de saúde do paciente. O mais grave (maior risco de morrer) vai para o topo da lista.
Nem precisamos dizer que Engenharia, Administração, Gestão e campos que desenvolveram a Gestão de Projetos (Project Management) são áreas que lapidaram conceito e práticas de priorização.
Assim como entre militares, há aspectos que podem ser concorrentes ou concomitantes em um projeto. Construir uma casa, por exemplo.
Enquanto se faz o fundamento, já se pode montar as estruturas de ferros que sustentarão vigas e colunas. Mas o que priorizar? Vai depender do projeto, dos riscos e recursos disponíveis.
Se houver várias casas em construção, mas uma limitação de mão-de-obra, há uma necessidade clara de saber o que priorizar para dar eficiência à empreitada, por exemplo.
Dentro de produtos de software
A criação de produtos de software herdou (e ainda pratica, para acaloradas polêmicas, como veremos à frente) muito do que foi desenvolvido na Gestão de Projetos, incluindo a priorização.
Por décadas (e essa mentalidade ainda persiste em várias organizações), criar produtos de software era encarado como erguer uma casa ou montar um carro.
O processo era mais ou menos o seguinte. Negócios e marketing tinham a ideia de lançar um novo produto no mercado.
Analistas especificavam requisitos que o produto deveria ter, não raro por meio de um processo inteiramente mental e dedutivo, sem ouvir usuários.
Designers projetavam uma planta, maquete ou protótipo. Engenharia passava a maior parte do tempo com o restante da tarefa, construindo a coisa.
(Uma versão bem mais longa dessa história pode ser conferida em outro artigo nosso, “Uma história da Gestão de Produtos”).
Como o mercado de produtos de software foi criado, gerido e operado primordialmente por engenheiros de software, naturalmente havia atenção quase total às soluções nascidas da cabeça de analistas e engenheiros.
O espaço do problema, de que já falamos, merecia pouca ou nenhuma atenção.
O resultado é conhecido. Passavam-se meses, talvez anos, projetando e construindo um produto, tentando deixar tudo perfeito — como se software fosse a mesma coisa que erguer a casa —, e, no final, a entrega estourava o cronograma, custava mais caro que o planejado e, o pior, não servia para nada.
O produto não resolvia problemas reais, não tinha conexão com o que clientes necessitavam ou desejavam. Era difícil de operar (não era “intuitivo”) e ninguém ou pouquíssima gente iria pagar para usá-lo.
A Gestão de Produtos atual, que cresceu após a chegada dos smartphones e da Internet móvel, ganhou toda a importância que tem como resposta a esse cenário anterior.
Priorização em produtos de software também nasceu e cresceu naquele contexto. Muitas metodologias, frameworks e práticas surgiram dentro do espaço da solução, habitado pela engenharia.
A Gestão de Projetos delimitava o escopo do que deveria ser feito, determinava um cronograma para fazê-lo, calculava os recursos necessários (orçamento) e administrava o processo.
A Engenharia tinha de cumprir o projeto, ou seja, atender o escopo dentro do tempo e custo previstos. Para isso, precisava de formas de organizar o que tinha a fazer.
Métodos de priorização, em consequência, passaram a ser buscados como alguma “cura milagrosa” para evitar atrasos ou encarecimento do projeto (que, mesmo assim, continuavam ocorrendo).
Não é à toa que métodos bastante quantitativos e complexos surgiram. Alguns, certamente, davam mais trabalho de serem administrados do que determinadas tarefas do projeto.
Havia uma busca por precisão — por comando e controle, em resumo — em relação a cronogramas e orçamentos.
Talvez se acreditasse que haveria algum framework, ainda não descoberto, capaz de acabar de vez com o sofrimento de todos, gestores de projetos e engenheiros, que não raro acabavam se desentendendo e culpando uns aos outros por falhas na execução das tarefas.
Essa mentalidade não mudou com a popularização do Manifesto Ágil e a adoção de rotinas de desenvolvimento de software como o Scrum.
O Product Owner (PO), que nasce como um papel dentro do Scrum, nada mais é do que um grande priorizador de backlog.
É o responsável (ou coitado) por receber enxurradas de pitacos, sugestões, solicitações e reclamações e tentá-las organizá-las por grau de importância em uma fila de tarefas, normalmente para que engenheiros e desenvolvedores de software tenham “produtividade”.
Tudo isso está sempre no espaço da solução e é sobre construção, sobre o “espectro da engenharia”, que tem de se preocupar com certeza.
(Já falamos desse espectro ou mentalidade de engenharia, de solução e certeza em “Discovery é mais estado de espírito do que método”, “Problem space vs. solution space como analogia à dificuldade de converter negócio em tecnologia” e até em um artigo de nossa Newsletters sobre Dados e Tecnologia, “Um modelo mental para Data Science entre Análise e Engenharia”).
No fundo, tudo isso ainda é sobre atender cronogramas, orçamentos e o desejo por sequências lineares e previsíveis de etapas. Um waterfall de ciclos iterativos? Mentalidade de projeto e não de produto.
Ainda na mentalidade de projeto
Tudo bem que vai chegar o momento em que haverá ao menos algumas tarefas no espaço da solução a serem priorizadas, já que ficar só no discovery e na ideação não coloca produto na rua.
Podem ser débitos técnicos (bugs), podem ser ajustes em uma parte recém implementada do produto, podem ser explorações de oportunidades de baixo risco que vale por em produção para captar feedbacks dos clientes/usuários.
O que fazer primeiro?
É aqui que muitos gestores de produtos (e organizações, de forma mais ampla), caem na enrascada de buscar frameworks, desenvolver métodos, quando não verdadeiros rituais, sem atentar ao fundamental.
Não há priorização que dê conta de demandas em excesso e bagunçadas desde o princípio — o que só demonstra falta de estratégia e visão do negócio, como veremos na próxima parte do texto.
Problemas ou oportunidades explorados às pressas tendem a jogar muitos pontos de dúvidas para a definição de soluções.
Esses pontos de dúvidas, se não filtrados e tratados, irão acabar na lista a ser priorizada para o desenvolvimento da solução. Se passarem disso, restarão como débitos técnicos que terão de ser priorizados para tratamento futuro.
Querer atacar blocos de oportunidades ou problemas muito amplos, desenvolvendo soluções complexas, também é receita para o desastre.
É preciso um trabalho crítico, de filtragem e refinamento anterior. Isso permite implementar algo mínimo viável (pequeno e administrável), que será incrementado, continuamente, em pequenos passos.
O incentivo para que PMs digam mais “nãos” e usem de processos racionais para questionar a fundo a necessidade de soluções que nascem de cabeças de negócio, por exemplo, são formas de se tentar fazer isso.
Também não é uma tarefa fácil saber o que é o mínimo viável a ser implementado quando uma solução está ideada e definida. A experiência prática, o ambiente e as circunstâncias é que normalmente dirão.
O fato é que, a menos que se tenha tempo de folga ou recursos (pessoas, conhecimento etc.) de sobra, não adianta achar que haverá método, ferramenta ou magia que irá dar conta de demandas em excesso e complexas.
É aquela coisa: tomando um caso altruísta, podemos querer ajudar a levar cestas básicas a famílias necessitadas em uma determinada comunidade de uma cidade ou podemos querer resolver a fome no mundo.
Ambos, pelo menos em tese, são possíveis. O segundo, de um ponto de vista humanitário e ético, seria até mais importante e urgente que o primeiro, até porque já resolveria este por tabela.
Mas os recursos necessários para satisfazer uma condição e outra são gritantemente díspares.
Fazer esse ajuste constante de foco no que se está tentando tratar, com base em uma boa exploração do problema (necessidades ou desejos de clientes/usuários), ajudará a gerar tarefas mais enxutas, simples e, ao mesmo tempo, assertivas, que não queiram resolver a fome no mundo, por exemplo.
Se a pessoa ou o time começar a notar que está perdendo o sentido do que está fazendo, que está começando a querer encontrar framework que resolva backlog abarrotado, vale dar uma parada e reavaliar a jornada. Pode-se estar preso na build trap.
Na mentalidade de produto
Build trap é um termo popularizado por Melissa Peri, uma gerente de produtos experiente, autora do livro Escaping the Build Trap: How Effective Product Management Creates Real Value (em tradução livre: “Escapando da armadilha da construção: como o gerenciamento de produtos eficaz cria valor real”).
Em resumo, a tese de Peri é que as empresas e, por consequência, seus times, acabam focando demais em atender à sua programação e metas internas, em vez de pensar e explorar as necessidades e desejos dos clientes (serem user-centric ou customer-centric).
Isso levará à armadilha da construção (build-trap), a qual, em um nível micro, resultará nas dores de cabeça com priorização, complexidades e apego à entrega de funcionalidades (outputs) e não resultados (outcomes).
Marty Cagan, evangelista da gestão de produtos atual, como vimos em “Discovery é mais estado de espírito do que método”, é um dos que, obviamente, também trata sobre essa tendência danosa.
No artigo “Product Strategy - Focus”, de 2020, em que ele recomenda escolher algumas poucas “batalhas” de negócios que irão causar impacto, comenta:
“[...] muitas vezes os líderes da empresa precisam de uma verificação da realidade sobre este tópico [quantidade de demandas e falta de foco].
“O número absoluto de coisas que eles acreditam ser criticamente importantes e que precisam acontecer neste trimestre ou neste ano costumam ser muito numerosas — quero dizer literalmente. Em vez de 2 a 3 coisas realmente importantes, eles têm pelo menos 20 a 30.”
— Marty Cagan, 2020.
Teresa Torres, que também mencionamos no artigo sobre discovery, dentro da mentalidade de descoberta contínua que ela prega, recomenda priorizar oportunidades, não soluções (priorizar no espaço do problema).
Ela usa um case da Netflix para ilustrar como fazer isso e dá suas opiniões sobre a tradicional “priorização de backlog”:
“Eu me encolho toda vez que vejo equipes de produto usando uma planilha para classificar as ideias em seu backlog com base em alguma fórmula matemática inventada, geralmente consistindo em coisas como valor para o negócio, valor para o usuário e dificuldade técnica. [...]
“Priorizar soluções é um efeito colateral remanescente de estar focado na produção. Quando somos julgados pelo que entregamos, as principais decisões são focadas no que construir e quando. Mas quando somos julgados por quais resultados alcançamos, o que importa menos é quais soluções oferecemos e mais sobre quais problemas resolvemos para nossos clientes.”
— Teresa Torres, 2019.
(O debate que o artigo gerou, nos comentários, também é interessante. Mostra que há resistências e controvérsias a essa visão também, o que é saudável).
A comunidade Mind The Product aproveita o que Cagan e outros dizem para fazer um apanhado sobre priorização na mentalidade de produto.
O apanhado fala em pontos fundamentais como estratégia, métricas de sucesso, conhecer os clientes, dizer não e não pensar apenas em entregas.
Todos esses pontos podem ser abstraídos no que trataremos a seguir, sobre cultura, estratégia e visão como tópicos de alto nível para mitigar as dores da priorização tática.
Depende de cultura, estratégia e visão
“Gerar atividade não é um problema; na verdade, é fácil. O fato de ser fácil torna o problema real mais difícil de resolver. O problema é fazer as coisas certas — as coisas que importam, as coisas que terão um impacto, as coisas que uma empresa está tentando alcançar para garantir o sucesso.” — Stephen Bungay, citado por Marty Cagan.
Não tem jeito. Se não há cultura, estratégia e visão adequadas no âmbito do negócio, produto tende a se ver perdido entre priorizar backlogs extensos, complexos e sem sentido, focados em entrega de funcionalidades, normalmente apenas para não deixar desenvolvedores parados.
É um filme chamado “De volta para o Comando e Controle”, infelizmente tão repetido e enfadonho quanto os da sessão da tarde.
O caminho para evitar dores de cabeça com priorização começa com o entendimento do momento do negócio. Uma startup em estágio inicial, tentando validar um MVP, terá de focar em encontrar o product market fit. O resto será perda de tempo e de dinheiro, que nessa fase é mais do que crítico.
Para startups e empresas que já estejam operando em crescimento ou até na maturidade, com mais de um produto, times grandes, quando não aquisições e fusões de outros negócios (que adicionam um bocado de dificuldades a mais), o enquadramento muda.
O que importa é que ambas têm de se guiar por uma visão de alto nível e longo prazo, um norte (até um tanto inspiracional) para toda a existência do negócio, que possa ser desdobrado em estratégia e, estas, por sua vez, em táticas (onde estará a priorização de tarefas).
Por estratégia, entenda-se planos de médio prazo que visam sustentar e/ou fazer o negócio crescer, em resumo. Aqui entram indicadores e métricas, também de alto nível, como OKRs, North Star Metric, KPIs etc., que permitem saber se objetivos estratégicos estão sendo atingidos ou não.
Por táticas, entenda-se movimentos de curto prazo, como descobertas que conduzam a entregas, as quais ajudem a mudar as métricas, atender a estratégia e, no alto, satisfazer a visão.
Como product managers não decidem negócio, no entanto, como diz Diego Eis, pode parecer que mudar tudo isso seja missão impossível para PMs.
Um escrito do Medium, David Pereira, mostra que há o que se pode fazer, inclusive a partir de uma posição de Product Owner (PO).
O caso que ele relata é comum em várias empresas. Excesso de pedidos, sugestões e desejos de stakeholders internos, todos desalinhados com uma estratégia maior (inexistente), sobrecarregando um backlog sem sentido.
Solução (ou pelo menos o começo dela): chamar todos esses stakeholders para sentar à mesa e colocar às claras, comunicar direito ao ponto, o que está acontecendo, as dificuldades que isso gera e a necessidade de alinhamento em torno de um visão e estratégia comuns.
“Nas últimas semanas, recebi muitos pedidos conflitantes de todos vocês. Por exemplo, o financeiro deseja alterar as faturas enviadas aos nossos clientes, enquanto a logística deseja removê-las dos pacotes. Não podemos trabalhar assim. Precisamos ser uma equipe. Você conhece nossa maior dor atualmente? É muito caro adquirir clientes e nós os perdemos com muita facilidade. Minha pergunta, o que podemos fazer para mudar esse cenário? No final desta reunião, precisamos concordar em uma única direção a seguir.” — David Pereira, 2020.
Talvez não resolva o problema de imediato. Provavelmente, gerará algumas caras feias. Também não vai produzir uma cultura organizacional da noite para o dia, em que todos “viverão felizes para sempre”. O nome disso é conto de fadas.
O que David relata tem outro nome: trabalho, um trabalho árduo e essencial a ser feito, que depende de comunicação, de influenciar (ou pelo menos tentar) e de assumir à frente de uma mudança de cultura, mesmo que seja trabalho de formiguinha.
Do contrário, a corda tende a arrebentar do lado mais fraco, no tático, naquele backlog impriorizável e sem sentido e, é claro, em quem o gerencia.
Entender priorização nesse contexto mais amplo, perceber como ela pode se tornar apenas transposição de problemas organizacionais de níveis macro (falta de visão e estratégia) para o micro (tático), permite ver que nem sempre necessitamos de mais metodologias e frameworks, como se houvesse soluções "instrumentais", “ferramentais”, para tudo.
Pensar um pouco e enquadrar o horizonte mais amplo das tarefas, do produto, do time e, por fim, da organização, podem, inclusive, tornar a busca e adoção de mais ferramentas desnecessárias, complexidade a menos.
Essa é a mensagem antes de cairmos no “mantra” que se vê por aí de que priorização é uma das principais atividades da Gestão de Produtos e que tudo se resume à escolha e a conduta rígida em torno de um dos tantos frameworks criados.
No próximo artigo, com esse contexto (e alerta) em mente, aí sim, vamos fazer um passeio pelas dezenas de métodos desenvolvidos, falar de benefícios e riscos de cada um e somar mais algumas considerações pontuais sobre essas ferramentas e suas eventuais implicações.
Os comentários estão abertos para quem quiser contribuir com a discussão, estendê-la, fazer críticas ou sugestões ao texto ou à Newsletter como um todo. Até a próxima edição.
Artigo escrito por Rogério Kreidlow, jornalista, que gosta de observar a tecnologia em relação a temas amplos, como política, economia, história e filosofia.