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.
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.
