Priorização, parte II: agora sim, frameworks
Generalizações de mais de cem estruturas de priorização, dos anos 1970 até a atualidade. E mais avisos: elas ajudam, mas não são algoritmos que tomam decisões por si próprias
No artigo anterior desta série, tratamos sobre como a priorização pode ser consequência ou sintoma de uma cultura organizacional voltada à entrega de funcionalidades (features) e ao foco demasiado no espaço da solução e não no espaço do problema (e das oportunidades).
Muito desse contexto é histórico na indústria de software e foi exacerbado mesmo com as práticas da Metodologia Ágil. O Product Owner (PO), um papel dessa metodologia, não raro se viu como “priorizador de backlogs” inchados que aceitavam tudo, principalmente decisões top-down sem propósito.
A chamada Gestão de Produtos moderna, que ganhou ênfase na última década, surgiu para fazer frente ao cenário acima. Ela é difundida por nomes como Marty Cagan, que prega seus conhecimentos por meio do Silicon Valley Product Group (SPVG), e Teresa Torres, da Product Talk, que aparecem em artigos recentes.
A busca é por ajustar a atenção entre discovery (descoberta) e delivery (entrega). Tipicamente, organizações voltadas ao desenvolvimento (programação) e à entrega de funcionalidades tendem a operar 80% (às vezes, 100%) no delivery, no espaço da solução, e só 20% no discovery, no espaço do problema.
O objetivo é dar mais importância ao discovery, a partir do entendimento de necessidades e desejos dos clientes/usuários, ou, então, equilibrar os dois lados da moeda: descoberta e entrega.
Pois bem. Essa é uma repetição necessária, antes de encararmos estruturas de priorização, como se elas fossem o Santo Graal para o excesso de demandas. Isso não quer dizer, porém, que todos os frameworks tenham de ser aposentados ou, como alguns pregam, que já “morreram” há tempos.
Dentro de um cultura de produto (e não de projeto), com visão clara do negócio, estratégias definidas e métricas/indicadores a serem alcançados, frameworks podem ser úteis para determinadas situações, tanto na descoberta como no desenvolvimento (principalmente neste) de produtos.
O importante é ter em mente que eles são artefatos que podem ajudar na tomada de decisões, mas que, como quase todas as ferramentas, têm suas limitações, podem ser utilizados de forma equivocada (principalmente se envolverem muitos stakeholders, as “partes interessadas” do produto) e não são algoritmos que automatizam decisões.
Neste segundo artigo da série, vamos fazer um sobrevôo sobre os frameworks existentes, fornecer uma visão abstraída/generalizante dos principais grupos deles, com os exemplos mais importantes em cada um — afinal, como dito, há mais de uma centena dessas estruturas já mapeadas.
Ao final, acrescentaremos mais considerações sobre o uso geral de frameworks, com base em opiniões de quem já pensou no assunto.
Contexto
Apenas para situarmos quem porventura desconhece ou conhece pouco do assunto, framework significa “estrutura”, do inglês. Frameworks de priorização, portanto, são estruturas para priorizar itens, que podem ser ideias, tarefas, projetos etc.
Por priorizar, entenda-se o ato de ordenar itens do mais para o menos importante, urgente, crítico ou qualquer outro critério que se estabeleça.
Boa parte dos frameworks costumam ser artefatos visuais, como tabelas, grades, matrizes ou listas. No entanto, há também fórmulas matemáticas, figuras (desenhos), normalmente para assinalar/colar itens sobre, ou, ainda, atividades, como jogos.
Os frameworks surgiram para lidar com risco e incerteza em projetos e tarefas, em sua maioria. Há os que visam explorar oportunidades também, mas os primeiros predominam.
Como há tarefas que envolvem esses riscos/oportunidades, as estruturas buscam elencar ou calcular quais devem ser feitas antes e quais podem ser deixadas para depois (ou serem descartadas).
O ponto fraco dos frameworks são os critérios por meio dos quais os itens são classificados. Como critérios são sempre subjetivos ou intersujetivos, podem gerar disputas, desentendimentos e impasses. Não há meios matemáticos para se chegar a decisões ótimas.
O que é urgente para o tech lead (líder dos desenvolvedores), como a correção de um bug, pode não ser para o gerente de marketing, que acha mais importante colocar em produção uma nova funcionalidade que atraia mais clientes.
O fato de priorizações serem feitas em times, entre grupos de stakeholders ou mesmo por uma única pessoa, mas afetando o trabalho e preferências de outras, é a raiz destas dificuldades.
Frameworks
Há muitos conteúdos que costumam destacar nomes e siglas como Impact vs. Effort (Impacto vs. Esforço), Kano Model, RICE, Story Mapping, entre vários outros, como estruturas de priorização populares.
De fato, são. A lista, porém, vai muito além dos 5, 7 ou 10 frameworks mais usados. Jordan Lamborn, um product manager, relacionou 136 frameworks de priorização, dos mais populares aos mais obscuros e bizarros.
(Fizemos uma revisão item por item e a soma deu 130 e não 136 frameworks. Se alguém quiser refazer a contagem, fique à vontade. O interessante é que a lista de Lamborn parece ser atualizada com frequência, o que ajuda. A última atualização, quando consultada, era de 17/09/2021).
Mas não nos empolguemos achando que entre 136 frameworks há alguma fórmula mágica para vários problemas. Se isso existisse, estaria sendo vendido, e caro. O interessante é olhar de modo mais realista e crítico.
Lamborn agrupa os frameworks em sete categorias (os números de estruturas por categorias estão entre parênteses):
Quadros/matrizes (32)
Pontuação (54; contamos 50 aqui)
Classificação sem pontuação (7)
Classificação qualitativa (13)
Mapas e telas (7)
Atividades/jogos (13)
Processos/fluxos de trabalho (10)
Sem desmerecer a tarefa dele, que, aliás, fez todo o trabalho sujo para nós, vamos simplificar e tratar tudo em apenas duas grandes categorias:
qualitativos: onde entram “Quadros/matrizes”, “Classificação sem pontuação”, “Classificação qualitativa” e muitos dos “Mapas e telas”;
quantitativos: onde entram “Pontuação” e exemplos de “Atividades/jogos”.
Isso fornecerá uma boa visão de como os frameworks são e se parecem ou derivam entre si, com exemplos populares que ilustram cada categoria nossa.
A intenção não é explicar o uso de cada um em detalhes (até porque isso demandaria longos exercícios, em alguns casos), mas fornecer um panorama generalista.
A quem quiser, é possível “treinar” o uso de muitos dos modelos disponíveis. Basta pegar uma lista de itens e tentar classificá-los de acordo com a estrutura escolhida.
Muitos frameworks são tão simples de usar como o ato de dizer se algo é “bom”, “médio” ou “ruim”.
Contudo, é na prática “para valer”, no trabalho em equipe, lidando com diversas preferências, diante de muitos itens (e itens com vários níveis de complexidade e criticidade), que os maiores e melhores aprendizados sobre frameworks de priorização ocorrem.
Qualitativos
Frameworks qualitativos, como o nome diz, usam qualidades (nomes, rótulos, classes etc.) e não quantidades (números, proporções etc.) para priorizar itens.
O simples ato de separar itens por, digamos, “bom”, “médio” e “ruim” (ou “A”, “B” e “C”), pode servir como um exemplo primitivo de priorização qualitativa.
Quanto à forma, frameworks qualitativos tendem a ser quadros, gráficos cartesianos aproximados, listas ou figuras.
Quadros têm quadrantes, que representam critérios, onde os itens são classificados. Listas são recipientes onde itens são dispostos (de forma ordenada ou não).
Gráficos cartesianos aproximados são gráficos com eixos x e y, mas sem uma escala quantitativa precisa. A classificação é aproximada, “visual”. Matrizes com quadrantes podem ser representadas sobre estes gráficos sem problema.
Figuras podem ser uma árvore, um barco ou “doces, vitaminas e analgésicos”, em que a lógica está em alguma analogia com a forma visual. Tendem a ser mais lúdicos.
Muitas dessas estruturas qualitativas parecem ter sido criadas mais para facilitar a visualização e intuição de conceitos abstratos e complexos do que para priorização propriamente dita.
É possível notar que várias se aplicam melhor ao espaço do problema do que ao espaço da solução, quando se tem apenas ideias vagas e incompletas e se está querendo intuir oportunidades e riscos.
Várias dessas estruturas também são usadas para enquadrar um produto ou uma organização (negócio) em um determinado momento de seu ciclo de vida.
Vamos ver um exemplo de cada tipo: quadros, gráficos cartesianos aproximados, listas e figuras.
Quadro: Impact vs. Effort
A matriz Impact vs. Effort (Impacto vs. Esforço) é um clássico e, por isso, um dos melhores exemplos de quadros.
Nasceu dentro do movimento Total Quality Management (Gestão da Qualidade Total), na indústria japonesa, nos anos 1980.
Muitas ferramentas e metodologias usadas até hoje em desenvolvimento e gestão de produtos de software, aliás, como kanban e conceitos como Six Sigma, lean manufacturing etc., nasceram no Japão nessa mesma época.
A matriz Impacto vs. Esforço é bastante simples. O que interessa são os quatro quadrantes, onde são dispostos os itens ou tarefas.
Itens que estão no quadrante ao alto e à esquerda (alto impacto e baixo esforço) têm prioridade sobre os demais. Itens que estão no quadrante abaixo e à direita (alto esforço e baixo impacto) podem ser descartados.
Por que usamos uma matriz tão simples como exemplo? Porque essa matriz gerou inúmeras derivações e porque fornece o formato para muitas outras matrizes com os mesmos princípios, mesmo que de origens diferentes.
As derivações são criadas substituindo-se os rótulos “impacto” e/ou “esforço” ou acrescentando-se outras dimensões de rótulos.
São exemplos as matrizes derivadas Valor vs. Viabilidade (que são apenas outros nomes para impacto e esforço), Risco vs. Retorno, PICK Chart (que coloca dificuldade em um eixo e retorno em outro), entre outras.
No mesmo formato, mesmo que sem relação com a Impacto vs. Esforço, estão outras matrizes populares.
A matriz de Eisenhower, que dispõe os itens por importância e urgência (e ilustra o post anterior desta série), é outro exemplo antigo e clássico.
Foi criada em homenagem ao presidente dos EUA Dwight D. Eisenhower e é recomendada para priorização de tarefas pessoais rotineiras.
A matriz de Stacey, um pouco diferente, é outra que adota o mesmo formato de quadrantes. É mais um modelo mental-visual para se pensar na complexidade entre acordo e falta de acordo (entre pessoas) e certeza e incerteza (do que se está tentando fazer).
Há muitas variações e adaptações da matriz de Stacey, como esta ou esta. (A estrutura, por acaso, ilustra outro artigo nosso: “Tentativa e erro em domínios simples e complexos”).
A matriz BCG, também tradicional, é outro caso similar. O nome vem do Boston Consulting Group, que a criou. Ela serve mais para analisar o sucesso de produtos no mercado, tentando aclarar suas oportunidades, mas também pode ser adaptada à classificação de itens.
O original brinca com os rótulos “pontos de interrogação” (produtos de alto crescimento e baixo alcance), “estrelas” (produtos de alto crescimento e alto alcance), “cachorros” (produtos de baixo crescimento e baixo alcance) e “vacas leiteiras” (produtos de baixo crescimento e alto alcance).
O ideal é transformar “pontos de interrogação” em “estrelas” (o melhor dos mundos), é claro. Mas manter um rebanho de “vacas leiteiras” (produtos maduros, que não têm mais para onde crescer, embora detenham grandes mercados) também é uma estratégia interessante. Quanto aos “cachorros”, fuja deles.
Várias estruturas que Lamborn cita podem ser tratadas como quadros: RVCE; Build, Partner, Buy; How, Now, Wow!; Priority Matrix (PMAT), Valor vs. Probabilidade vs. Esforço e Innovation Matrix, embora essas duas últimas possam ser enquadradas também em estruturas quantitativas.
Em resumo, há muitas estruturas que podem ser abstraídas, reduzidas, mapeadas para matrizes 2x2 e, em alguns casos, com mais dimensões.
A lógica é sempre a mesma. Há um quadrante que é o “excelente”, dois que são “medianos” (têm prós e contras inversos) e um que é ruim (só contras). Mesmo que não haja quadrantes, apenas escala aproximada nos eixos x e y, o princípio é o mesmo.
Trata-se, na maioria dos casos, de simplificações extremas da realidade, que podem ajudar a separar itens rapidamente, mas que também podem deixar aspectos importantes de fora e carregar subjetividade, precipitações, emoções e vieses em excesso, se não houver cuidados.
Gráficos cartesianos aproximados: Kano Model
Kano Model é uma estrutura criada por Noriaka Kano entre os anos 1970 e 1980. É muito citado entre estruturas de priorização, mas é mais uma metáfora para falar de produtos encantadores do que para classificar itens na prática.
O raciocínio de Kano é o seguinte:
há recursos básicos que demandam muito investimento (como esforço) e geram baixa satisfação dos clientes/usuários (basic expectations, expectativas básicas);
há recursos necessários e que geram uma satisfação muito correlacionada entre esforço e satisfação (satisfiers, satisfatores);
há recursos diferenciais, que nem sempre demandam tanto esforço, mas que geram grande satisfação dos clientes/usuários (delighters, encantadores).
A mensagem do modelo visual é, então, apostar nesses últimos recursos, os “encantadores”.
Na época em que foi criado, talvez fizesse mais sentido. Hoje, em que até enjoamos de tantos produtos sedutores e “viciantes” à disposição, pode parecer algo óbvio.
A dificuldade é saber ou definir quais são esses recursos encantadores. Como a maioria só se revela após testes ou em produção, o modelo serve mais para palpites e apostas do que para redução de incertezas.
Note-se que o modelo Kano é construído sobre um gráfico cartesiano, que tem o rótulo “investimento” no eixo x e “satisfação” no eixo y. Só que ele usa apenas estimativas intuitivas e visuais e não quantidades (poderia usar, mas isso exigiria uma boa dose de criatividade).
Estruturas em três ou quatro dimensões (entram aqui muitas derivações do Impacto vs. Esforço), como Value, Probability, Effort, Business Value, Effort, Risk e similares, com três dimensões, e Innovation Matrix, com quatro, também cabem nessa categoria.
Listas: MoSCoW
O framework MoSCoW — que não tem nada a ver com a capital da Rússia e é a sigla para “Must have, Should have, Could have e Won’t have” (“Deve ter, Deveria ter, Poderia ter, Não terá”) — é um dos exemplos mais conhecidos de priorização por listas. Apesar do nome, também é bastante simples.
É possível colocá-lo em quadrantes; a forma, na verdade, pouco importa. Porém, é mais comum aparecer em forma de listas, mesmo que apenas textuais, sem nenhum apelo visual.
Note-se que a ideia é muito parecida com a matriz Impacto vs. Esforço ou BCG. Os rótulos apenas soam mais “secos” e imperativos.
O princípio, novamente, é elencar o que é obrigatório (deve ter), separar o que é quase um “deve”, mas não tão importante (deveria), o que é opcional (poderia) e desconsiderar o desnecessário (não terá).
A dificuldade é lidar com essas nuances finas, principalmente entre “deve” e “deveria” e entre “deveria” e “poderia”.
Similares ao método MoSCoW, há outros. Filas simples (FIFO, de “first in, first out”, o primeiro item a entrar e o primeiro a sair) ou pilhas simples (LIFO, de “last in, first out”, o último a entrar e o primeiro a sair) são exemplos óbvios de listas.
Cabem aqui até grafos de árvore binária ou uma estrutura que é basicamente visual e um tanto bizarra, a Candy, Vitamin, Painkiller (Doces, Vitaminas, Analgésicos), uma metáfora para dizer que usuários precisam de analgésicos para mitigar suas dores com urgência, vitamos depois e doces por último (apesar de gerarem muita receita).
Figuras: Product Tree
Product Tree (Árvore do Produto) é um dos frameworks de priorização em forma de figura mais conhecidos.
É uma metáfora para criação e evolução de um produto. Também é uma espécie de atividade lúdica, um pouco brainstorming, para ser realizada com stakeholders.
Funciona assim:
raízes representam a infraestrutura em que o produto se sustenta;
tronco representa o core do produto, sua proposta principal;
ramificações representam funcionalidades ou serviços, podem crescer e se multiplicar ou serem podadas;
folhas representam novas ideias, recursos, oportunidades.
Também há quem adicione maçãs (possibilidades de retornos para o negócio) e sementes (sugestões ainda muito embrionárias) na dinâmica.
A árvore pode ser feita para visualizar a complexidade do produto ou para acompanhar sua evolução, em que mais ramos e folhas crescem ou são, eventualmente, podados.
Por que isso serve para priorização? Porque permite entender melhor o que são requisitos essenciais e não essenciais, o que tem de ser feito antes (raízes, troncos e ramos maiores) e que depende de galhos já existentes (ramos menores, folhas, frutos).
Um benefício é envolver times e stakeholders no “cultivo” da árvore, ou seja, do produto. Um malefício é a prática focar demais em outputs (saídas) e entrega de funcionalidades a partir da cabeça dos stakeholders e não outcomes (resultados) a partir de desejos e necessidades de clientes/usuários.
Outro exemplo de framework visual, que vale apenas comentar, é um chamado Boat, que surgiu no âmbito do Scrum, uma metodologia ágil.
É mais uma dinâmica, também lúdica e para envolvimento de stakeholders, mas sujeito, como muitos outros, a focar demais no espaço da solução e na entrega de funcionalidades a partir da cabeça de stakeholders.
A atividade consiste em desenhar um barco (metáfora para o produto) e pedir para os stakeholders listarem o que consideram que são âncoras (impedimentos) para que o barco avance.
Também podem ser sugeridas opções que podem impulsionar o barco (vento) ou ajudá-lo a aproveitar fatores impulsionadores (velas).
A matriz BCG (das “vacas leiteiras”) e o Candy, Vitamin, Painkiller (Doces, Vitaminas, Analgésicos) também poderiam ser listados aqui em figuras, pelas associações que provocam com as figuras que contém. Porém, o peso deles está mais em seus termos do que nos desenhos.
Por fim, vamos apenas mencionar User Story Mapping em figuras; porém, com ressalvas.
O framework não é destinado especificamente à priorização, mas sim à composição das etapas da jornada do usuário em um sistema ou serviço. De qualquer forma, ele ajuda a entender quais itens devem ser feitos antes de outros e normalmente compõe grandes grades visuais.
Quantitativos
Frameworks quantitativos usam quantidades (números, proporções etc.) para priorizar itens.
Embora listas numeradas possam ser exemplos e métodos de contagem simples (votação) entrem aqui, o que mais brilha nesta categoria são os frameworks que adotam alguma fórmula ou algoritmo matemático.
Em estruturas quantitativas, o apelo visual interessa bem menos; às vezes, é completamente desprezível. A busca é por um desejo de racionalização e por decisões automatizáveis.
Na prática, a maioria desses frameworks requer critérios quantificáveis (número, proporções, intervalos, pesos etc.) e uma fórmula para processá-los. Os resultados são pesos ponderados dos itens.
Assim como os frameworks qualitativos, os quantitativos podem ser altamente personalizáveis, com critérios e fórmulas específicas para cada produto, organização ou circunstância.
A desvantagem é que eles podem se tornar complexos de alimentar e gerir e, às vezes, consumir um bom tempo apenas para serem operados, já que times e/ou stakeholders terão de ser treinados no framework e atribuir diversos pesos aos itens para que os cálculos sejam precisos.
Vamos ver exemplos que usam fórmulas matemáticas e votação.
Fórmulas matemáticas: RICE
RICE é a sigla para “Reach, Impact, Confidence, Effort” (Alcance, Impacto, Confiança, Esforço).
É também a fórmula alimentada por estes critérios: RICE = (Reach × Impact × Confidence) ÷ Effort.
Os critérios devem ser usados da seguinte maneira:
Reach (Alcance): é a estimativa de usuários que uma determinada ideia ou solução pode alcançar em um determinado período de tempo; por exemplo, um mês.
Impact (Impacto): é uma pontuação que busca quantificar o impacto que a ideia ou solução terá nesses usuários. Na fórmula original, o impacto é uma escala de: 0,25 (mínimo), 0,5 (baixo), 1 (médio), 2 (alto), 3 (massivo).
Confidence (Confiança): é uma escala de confiança, em percentuais, de quem está propondo a avaliação: 100% é alta confiança; 80%, média; 50% baixa; qualquer coisa abaixo de 50% quer dizer que não há conhecimento aprofundado a respeito (derivações também adotam gradações de 100%, 75%, 50%, 25% e 0%).
Effort (Esforço): o comum é calcular o esforço por pessoas-semanas. Se o esforço de um item demandar 5 pessoas trabalhando durante cinco semanas, a pontuação de esforço é 25 (5 × 5) . Se exigir uma pessoa trabalhando por 5 semanas, a pontuação é 5.
A fórmula procura trazer racionalização ao processo. Esforço é o fator negativo pelo qual os demais fatores são divididos e, portanto, equilibrados. Contempla-se os usuários de duas maneiras: alcance e impacto. A crença de cada participante também é avaliada, por meio da confiança.
RICE foi apresentado em 2018 por Sean McBride, um ex-gestor de produto da Intercom, plataforma para relacionamento com clientes. Desde então, ganhou mais e mais adeptos em startups e empresas de tecnologia.
Há vários outros frameworks derivados, inspirados ou apenas parecidos com RICE. As derivações são:
ICE (Impact, Confidence, Ease ou Impacto, Confiança, Facilidade);
BRICE (o RICE com mais um critério na parte de multiplicação da fórmula, chamado BusinessImportance (algo como “importância para o negócio”), uma forma de levar em conta no cálculo um critério de interesse do negócio);
LICE (LeadQuality, Impact, Cost, Effort ou Qualidade do Lead, Impacto, Custo e Esforço);
DIE (Demand, Impact, Effort ou Demanda, Impacto, Esforço);
PIE (Potential, Importance, Ease ou Potencial, Importância e Facilidade).
Task Score, BUC, TIR, o esquisito BREAD (que usa regex no cálculo), o extenso Monster Prioritizarion e o “hindi” BACER são exemplos similares com fórmulas.
Quer algo mais complexo ou diferente? PXL é uma planilha com dez categorias para avaliar ideias a serem testadas ou não. Serve para UX, por exemplo. Ou tente entender o Analytic Hierarchy Process (AHP). Steve Johnson, um influenciador em produtos, tem métodos que chama de IDEA/E (anteriormente, VIDEO) e ASPIRE.
Na mesma linha, há o Weighted Scores e suas derivações. São tabelas de cálculo de fatores, que geram pontuações de priorização. Podem ser adaptadas ao gosto de quem for usá-las.
Dele, há a derivação WSJF (Weighted Shortest Job First ou algo como “trabalho mais curto ponderado primeiro”).
Esse apanhado demonstra o espírito dos frameworks baseados em fórmulas e cálculos. Com um pouco de criatividade, é possível ajustar qualquer um, por meio de novos critérios, à necessidade do momento. O gerenciamento e manutenção é que dão mais trabalho.
Também é possível criar novas fórmulas, tabelas ou mesmo algoritmos complexos para que a saída seja uma “nota” ponderada dos itens a serem priorizados. Tendo as notas, basta ordená-las da maior para a menor e trabalhar nas tarefas.
É curioso notar que muitos desses métodos nascem de pessoas com forte background em programação e engenharia, ou seja, com mentalidade mais exata. Nada mais natural, portanto, que tentassem colocar matemática na tentativa de eliminar subjetividade e confusão nas priorizações.
Ainda assim, não há matemática que consiga criar critérios, apenas calculá-los depois de estabelecidos. Os critérios continuam sendo criações, abstrações, algo da nossa imaginação, em todo caso.
Votação: Dot Voting
Incluímos um exemplo de votação em frameworks quantitativos mais para apresentar o formato.
Na prática, atribuir pesos no RICE ou em qualquer outro método não deixa de ser semelhante a votar. Você está declarando o que pensa e tentando influenciar a decisão coletiva.
Mesmo nos frameworks qualitativos, a votação também pode ser usada. É transversal a qualquer método. É uma forma de tomada de decisão em grupo.
Dot Voting nada mais é do que dispor os itens a serem priorizados em algum meio (tela, papel, parede etc.) e fazer com que membros da equipe ou stakeholders colem pontos (dots), como votos abertos. Os itens com mais pontos sobem na lista de prioridades.
A ideia pode ser incrementada e tornada complexa de diversas formas. O método pode ser somado a outros métodos, quantitativos ou qualitativos, para decisões mais democráticas.
Considerações
Como visto, há centenas de frameworks de priorização (ou que também se prestam a ela) disponíveis para uso. Alguns são mais populares; outros, mais específicos e, às vezes, até obscuros.
Todos são criações humanas, com limitações e sujeitos a falhas, para se tentar lidar com complexidade, dificuldade, risco e incerteza.
Derivações dos modelos existentes ou a criação de novos são possíveis em qualquer situação. Provavelmente, nesse instante, uma gama de times e profissionais em várias empresas esteja trabalhando em seus próprios frameworks ou pensando em um novo modelo que se adeque às suas circunstâncias.
Frameworks qualitativos têm uma barreira de uso menor e são mais intuitivos. Alguns servem para se pensar em produtos que ainda estão na fase de discovery (descoberta) ou que estão tentando encontrar mercado. Outros são mais inspiradores, metafóricos e imprecisos.
Frameworks quantitativos, por outro lado, tentam “matematizar” a priorização. Usam critérios como pesos, a serem processados por fórmulas, que geram pontuações ou índices a serem ranqueados. Alguns podem ser tornados bastante complexos e almejar uma precisão absurda.
Ambos os casos dependem de critérios, a serem criados e alimentados por humanos, com suas crenças, valores e subjetividade. O que pode ser importante para uma pessoa, pode não ser para outra. Frameworks tentam lidar com isso, ao mesmo tempo em que são impactados por tais preferências.
Além disso, cabe lembrar a mensagem ressaltada desde o texto anterior: muitos frameworks nasceram e nascem para lidar com o espaço da solução e para priorização de recursos, features, entregas.
Isso pode reforçar toda uma cultura e estratégia que dificultam a inovação, voltada à entrega de muitas funcionalidades (outputs), como se isso significasse produtividade do time de desenvolvimento, e não voltada a resultados (outcomes) do negócio e geração de valor aos clientes/usuários.
Frameworks também podem se tornar um fator de procrastinação a Product Managers (PMs), Product Owners (POs) e desenvolvedores. Às vezes, pode ser uma zona de conforto, um piloto automático, querer montar fórmulas complexas e administrá-las à risca, por meio longas reuniões, atividades, votações e discussões entre times e stakeholders.
É muito mais importante a PMs (e devs, designers etc.) dedicar todo esse tempo gasto com frameworks à descoberta de oportunidades, ouvir clientes e investigar o mercado, ao invés de se perder em miudeza de fórmulas, critérios complexos e artefatos visuais que mais embelezam a sala do que resolvem problemas.
É melhor ter uma ótima oportunidade/problema de clientes/usuários em mãos, o que facilitará o desenvolvimento de uma solução, do que perder tempo com imaginações sobre dezenas ou centenas de recursos possíveis que não irão mover indicadores do produto ou do negócio.
Para ir além, o próprio Jordan Lamborn escreveu sobre o aprendizado ao listar os 136 (ou 130, tanto faz) frameworks de priorização, ressaltando o seguinte:
“Eu recomendo pensar cuidadosamente sobre as necessidades de seus usuários, equipe e produto antes de selecionar qualquer método. [...]” — Jordan Lamborn.
À pergunta “Qual é a melhor estrutura para priorizar o que fazer a seguir?”, Andrea Saez responde, com toda a contextualização:
“Resposta curta: nenhum deles. Resposta longa: nenhum deles. [...]” — Andrea Saez.
Slava Shestopalov contribui sobre como reduzir a subjetividade e o preconceito na priorização. Para ele, as principais falhas dos métodos de priorização são:
não especialistas e especialistas têm o mesmo poder de voto;
as pessoas não decidem racionalmente por padrão (lembremos dos vieses cognitivos de Daniel Kahneman);
as unidades de medição estão abertas à interpretação.
Ou, como concluem usuários em um tópico no Reddit sobre estruturas de priorização:
“Depois de ler Inspired, de Marty Cagan, estou convencido de que ter um roteiro é o problema e não a solução. Agora estou mais interessado em encontrar estruturas de descoberta de produto e estrutura de descoberta de cliente. [...]” — AldericGracelyn.
“Todos os frameworks [...] são terríveis e presumem que você já fez a descoberta, então tentar implementá-los já é um passo na direção errada.” — whitew0lf.
A lição é, cada vez mais, focar em problemas/dores de clientes/usuários e as oportunidades neles contidas. Só isto já dá um direcionamento e tanto à solução a ser construída depois, sem brainstormings de “imaginação de recursos/features”.
Além disso, soluções são meios de gerar valor ao negócio e aos clientes/usuários. Não se trata de busca de perfeição, metodologias complexas, cerimônias ou rituais demorados (perda de tempo).
Estruturas de priorização podem apenas desviar o foco dos problemas que interessam (inclusive, problemas críticos do próprio negócio, como falta de estratégia, como dito no texto anterior). Entendendo e tratando esses problemas, frameworks se tornam o que realmente são, ferramentas, quem sabe dispensáveis.
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.