> ## Content Index > Fetch the complete content index at: https://productoversee.com/llms.txt > Use this file to discover other available public pages before exploring further. # Gerenciando fluxo, prioridade, valor e riscos - URL: https://productoversee.com/blog/gerenciando-fluxo-prioridade-valor-e-riscos/ - Published: 2023-03-20T10:45:50.000Z - Updated: 2023-03-20T10:45:50.000Z - Description: Levar uma organização que desenvolve produtos/serviços a outro patamar passa por adotar alguns padrões habilitadores. Primeiro por "a casa em ordem" com fluxo gerenciado e previsível. Depois ter conversas mais significativas sobre o que é prioridade e como avaliar valor (ou gerenciar riscos). - Author: Rodrigo Sperb - Tags: Ops, Processos e Métodos, #blog Outro dia eu escrevi o que eu chamei de uma historinha triste no meu perfil do LinkedIn, que era mais ou menos assim: > “Uma empresa tinha grandes ambições tecnológicas, e uma pitada a mais de camadas hierárquicas e uma estrutura organizacional complexa. O que é só um jargão para comprometimentos podem ser feitos à torto e à direito no altar das oportunidades de crescimento de carreira. > O corolário disto é pressão e expectativas irrealistas com respeito aos times de engenharia efetivamente fazendo o trabalho. Que por sua vez não apresentavam um processo maduro o suficiente para lidar com os riscos e não sabiam nada muito diferente de aceitar os (novos) desafios, absorver a pressão, e mais trabalho, e tentar o seu melhor para entregar o que foi prometido. > Mas o “seu melhor”, essencialmente, significava abrir mais e mais frentes de trabalho, aumentando o trabalho em progresso, o que é só um jargão para tentar o seu melhor fazendo o que há de pior”. A história era fictícia. E é triste por ser bem mais comum do que se imagina. Mas se você me conhece minimamente, deve saber que não sou alguém que simplesmente aceita e se conforma facilmente com qualquer coisa. Quer dizer, aceitar até tem que aceitar, é pré-requisito para ser pragmático lidar com a realidade como ela é. Mas como inconformado que sou, desde que me conheço por gente, sempre busquei formas que permitissem lidar com estes padrões disfuncionais no fluxo de trabalho como o descrito na historinha acima. Este artigo é uma pequena amostra daquilo que considero algumas das maiores descobertas profissionais, em termos de estratégias que são bastante universalmente aplicáveis, neste processo todo. E dado o contexto e a conjectura atual do mercado, acredito ser mais primordiais do que, via de regra, costumam ser. ## **Primeiro, uma condição: ponha a "casa" (ou fluxo de trabalho) em ordem** Qualquer fluxo de trabalho do conhecimento, como é a engenharia de software, precisa aceitar uma realidade sempre presente (ou no termo técnico, "ubíqua") fundamental que é a de há variabilidade intrínseca nos lotes de trabalho passando por seu fluxo (ou seja, existe a tendência de que cada item potencialmente seja diferente em alguma dimensão relevante, e portanto único em suas características) . Aliás, que existe um fluxo é outra realidade ubíqua (sempre presente), embora nem sempre ele seja visível e gerenciado de forma transparente, e que aí que justamente está a primeira condição para lidar com o trabalho de software de forma efetiva: torná-lo visível e ativamente gerenciado. Em poucas e mais simples palavras, a qualquer momento, qualquer demanda, de qualquer natureza relevante, de trabalho para um produto ou serviço devem ser transparentes e acessíveis a qualquer pessoa que interage com aquele fluxo. Perceba a sutileza de que a orientação do fluxo é sobre o produto ou serviço, e não necessariamente de um time. Embora este fluxo no nível de time também deve ser igualmente gerenciado, mas o mais relevante é o fluxo orientado ao produto ou serviço (em empresas maiores, isto pode significar o envolvimento de vários times, enquanto empresas menores, como uma startup, muitas vezes há uma relação 1:1 entre produto/serviço e um time específico, o que só simplifica um pouco as coisas). E é basicamente isto que quero dizer com ter a "casa" (ou o fluxo de trabalho) em ordem: > **Que haja um sistema de entrega visível e gerenciado, que é suficientemente estável, o que significa dizer que empiricamente se sabe qual é a capacidade de entrega num dado espaço de tempo, e isto impõe limites em quantas entregas fluem pelo sistema concomitantemente num certo momento (i.e., limite WIP), e com isto há evidências que os clientes (quem requer demandas) podem confiar na previsibilidade dos serviços de entrega daquela dado sistema.** Sem esta condição, é muito difícil gerenciar expectativas de uma forma que não seja bastante subjetiva, e a percepção de stakeholders (e lembre-se que no contexto da disfunção da historinha original, a panorama de stakeholders é complexo, o famoso "muitos *chefs* na cozinha") é a de só receber um "*push back*", sem muito embasamento. Arrisca virar até briga política dentro da organização. Agora, se há um sistema visível e gerenciado, em que os próprios stakeholders já entenderam as regras do jogo, muda o tom da conversa. E empurrar mais trabalho, quando já há muito fluindo, ou é uma possível questão de falta de integridade, no pior dos casos, ou uma questão de *tradeoffs* (e.g., para entrar esta nova demanda, qual sendo executada deve ser deixada de lado), ou pelo menos de se conversar com menos emocional envolvido. ## **Depois, conversas mais significativas, factuais e fundamentadas em** **tradeoffs** Na medida em que existam algumas regras claras para o jogo de interagir com o fluxo de trabalho de um produto ou serviço, e que os clientes (quem requer as demandas) saibam que uma vez iniciado existe uma perspectiva de entrega em prazo razoável (previsibilidade), a conversa tende a mudar e se orientar em duas dimensões: **prioridade** e **valor**. Não necessariamente mais simples, mas pelo menos mais objetiva, factual. Mas isto somente se entendermos mais precisamente o que queremos dizer com estes dois termos. Afinal, e começando pelo primeiro deles, existem algumas facetas do que **prioridade** pode implicar, dependendo do contexto: - Quando algo deveria ser finalizado. Ou seja, uma questão de ordem ou **sequência**. - Quando algo deve ser iniciado. Em outras palavras, o **planejamento** de algo a ser entregue. - O que deve preceder todo o demais e ser o próximo a ser iniciado, ou **seleção**. - Quando há conflito entre o que já está em progresso, como deve ser tratado, com a diferenciação de **classes de serviço** (pense no conceito de uma entrega é enviado com prioridade). Considero relevante ter esta precisão terminológica para que não haja confusão do que queremos dizer quando tratamos de **prioridade**. Quando combinada com **valor**, embora este mais ou menos possa permear decisões em qualquer daquelas facetas da **prioridade**, na maioria dos casos estaremos falando de **seleção**: o que deve preceder todo o demais e ser o próximo a ser iniciado. Agora, se tentamos ser precisos na linguagem quanto a **prioridade**, o que falar sobre **valor**? Será suficiente tratar de **valor** somente como algo com fim monetário? Tenho duas opções do que começar em seguida, uma espero que me renda R$500.000, a outra "só" R$50.000, mas de forma recorrente por ano. Só aí já baguncei um pouco o coreto adicionando uma dimensão temporal. Mas tem outras tantas dimensões que podem tornar a coisa toda ainda mais complicada. Como, por exemplo, qual o esforço que estimo que cada demanda requer? Ou quais são as incertezas técnicas de uma e da outra demanda? Como elas comparam em função destas e outras tantas dimensões possíveis que podem influenciar o processo de seleção? Por isso que, para mim, o melhor enquadramento de como tratar **valor** é considerá-lo uma função multidimensional de **riscos** a serem gerenciados. E como não sei exatamente qual fator é mais relevante e provável de ser um problema ou não, prefiro aceitar esta realidade e abraçar esta complexidade (ou seja, ao invés de tentar fazer algum tipo de média ponderada de todos os fatores considerados, mapeá-los e fazer uma análise mais holística e comparativa). No fim das contas, a definição de quais dimensões de riscos mapear é uma consideração contextual: deve estar alinhada aos riscos de negócios mais relevantes para a organização, ou o produto/serviço em função do seu posicionamento no mercado e onde ele se encontra no ciclo de vida. Alguns exemplos de fatores comumente encontrados são: - **Custo de oportunidade**: quanto pode render ou economizar? - **Urgência**: há uma temporalidade nesta opção, sendo que quanto mais tempo levo para entregar, potencialmente menor será a relevância? - **Riscos técnicos** (ou de execução): quanto conhecemos do que precisa ser executado tecnicamente? É algo novo ou que já fizemos anteriormente? - **Papel da funcionalidade ou opção**: Como esta funcionalidade ou opção é considerada do ponto de vista dos usuários? É um pré-requisito básico para competir ("*table stakes*") ou mais uma forma de diferenciação (ou até de encantar os usuários)? - **Impacto do atraso**: O que acontece se estivermos atrasados? Quais são as implicações? - **Alinhamento com a estratégia de negócio**: O quanto esta opção se alinha com a estratégia mais abrangente da empresa? Tal mapeamento permite levar o nível da discussão do que selecionar para começar em seguida a um patamar mais elevado, onde **prioridade** passar a ser contextual, tanto no sentido dos **riscos** mais relevantes para a organização, quanto no sentido temporal: qual é a nossa tolerância a riscos neste dado momento? Estamos procurando investir em opções mais arriscadas, e portanto com oportunidade mais agressiva (i.e., potencial de mais "dindim" no bolso), ou preferimos algo mais "café com leite", do dia a dia (e.g., de valor incremental). ## **O último "pulo do gato": tenha um portfólio balanceado** Se você conhece algo de investimento financeiro, talvez já reconheça esta dica: dilua o seu risco de investimento através do balanceamento do portfólio. Tenha a maior parte do seu suado dinheirinho em investimentos mais garantidos ou pelo menos de risco menor, mas também tenha uma pequena parte em investimentos mais agressivos, onde a possibilidade de ganho é grande, aceitando que pode perder aquela parte que foi investida (que não era muito). Tecnicamente, esta estratégia costuma ser chamada de [Barbell](https://en.wikipedia.org/wiki/Barbell%5Fstrategy?ref=productoversee.com). O mesmo pode ser aplicado em um fluxo de trabalho de entregas de um produto/serviço, ou mesmo de toda uma organização. E neste sentido, o mapeamento de risco descrito acima pode ser utilizado com um viés duplo orientado aos extremos: selecionado opções menos arriscadas na maior parte do tempo, mas de vez em quando optando por alguma(s) mais arriscada(s). Funcionando como uma espécie de **triagem**, cujo o propósito é permitir conversas mais robustas e significativas quanto o que é prioridade e como, em última análise, entregar valor de forma efetiva, com eficiência e eficácia. > **Em suma, é com o desenvolvimento desta disciplina de um fluxo de trabalho gerenciado e previsível, combinado com elevar o patamar de como fazer a triagem do que é começar e quando, e quais os riscos envolvidos, tudo de uma forma relevante ao contexto em questão, que se cria uma cultura de conversas mais significativas e menos emocionais (tal como o famoso "quem grita mais leva"). O que é o mesmo que dizer: elevar a maturidade organizacional.** ## **P.S.: contando o "santo"...** Embora, no fundo, muito do que descrevi seja bastante "senso comum", há um **método** por trás. A escolha de não deixar isto claro desde o princípio foi deliberada para que qualquer viés ou pré-conceito com relação ao mesmo pudesse "embaralhar" a sua percepção. Por isso segui o velho ditado: "contei o milagre sem contar o santo". Então encerro dando o devido crédito que o descrevi é um resumo do que, na minha visão, tem de mais relevante no método Kanban com relação a disciplina de gerenciamento de produto. Mas, sinceramente, isso nem é tão relevante (já que não devemos ser ortodoxos com modelos, frameworks e coisas assim, e sermos muito mais orientados a aplicar o que funciona no nosso contexto), senão só uma questão de integridade dar essa transparência a você que me dá o privilégio de ler meus alfarrábios aqui.