PAULO FERNANDO VASCONCELLOS NOGUEIRA

Blog

  • O Problema do Cliente

    O Problema do Cliente

    Hoje o problema não é nosso. Mas a gente quer que seja. Pretendemos desenhar um produto ou serviço que melhore a vida de um cliente. Por onde devemos começar? Quais ferramentas podem nos ajudar? Quais hábitos e mal entendidos colocam em risco a nossa empreitada?Ideias não faltam. Estamos cheios de hipóteses. Mas elas não são um bom ponto de partida para o desenho de um novo produto ou serviço. Por estranho que pareça, é preciso dizer: antes da solução deve haver um problema. A formulação de boas hipóteses requer o entendimento e a definição do problema. Necessidades, tendências e ofertas concorrentes são estopins tradicionais. O mundo está cheio de exemplos de como essas fontes de inspiração podem ser frágeis e traiçoeiras. Microsoft Zune, os óculos do Google, Segway e a Antarctica Sub Zero não me deixam mentir sozinho. Lá se vão vinte e cinco anos desde que a Teoria JTBD (Jobs to be Done – Trabalhos a Executar) foi apresentada¹. Parece que agora ela pegou. Em que ela é diferente dos estopins tradicionais? No olhar de fora para dentro. Na preocupação com o entendimento de um contexto, causas e motivações. Entender o porquê, num primeiro momento, é mais importante do que elucidar quem e o quê. JTBD não são inventados. Nós os descobrimos. Nesta sequência de artigos mal acoplados eu tenho insistido na palavra descoberta. Na conversa anterior eu mostrei como a ferramenta enxuta 5 Porquês, devidamente amparada em modelos sistêmicos, nos ajuda a descobrir a verdadeira raiz de um problema. JTBD é uma teoria e ferramenta mais específica. Mas parte do mesmo princípio: precisamos descobrir – esclarecer, revelar uma situação.

    Lavar roupa em casa.
    Tornar menos desagradável a espera no consultório médico.
    Ir do endereço A para o endereço B com conforto, rapidez e sem gastar muito.
    Comunicar o estado de um projeto respeitando o tempo e a inteligência de todos os envolvidos.
    Afastar a filha do smartphone por duas horas consecutivas.

    Ao apreciar um JTBD devemos considerar três dimensões:

    • Funcional: qual é, de fato, o trabalho a ser feito. Aqui sempre temos um verbo – uma ação devidamente contextualizada.
    • Emocional: como a pessoa espera se sentir ao executar aquele trabalho. Ou ao se ver livre dele.
    • Social: como a pessoa quer aparecer. Não leve em conta apenas as questões narcisísticas. Mas não as ignore.

    Completamos o quadro ao listar as principais coisas que o cliente quer e aquilo que ele não quer (receber, sentir, arcar) ao executar aquele trabalho. Essas informações podem ser capturadas na forma de um Mapa de Expectativas. Uma ferramenta que permite que o negócio também descubra o que ele quer e não quer quando fornece determinada solução.Essas fotografias nos ajudam a entender por que um cliente contrata determinada solução e demite outra(s). Repare nesse jeito de pensar: o cliente não compra produtos ou serviços, ele contrata soluções para se livrar de problemas. Nem sempre essas decisões estão relacionadas com aspectos funcionais. Aliás, dependendo do JTBD, a dimensão funcional pode ser a menos importante.

    Isso basta? JTBD é uma varinha mágica que nos leva para o mundo da solução perfeita? Longe disso. Agora é que o trabalho de análise começa a ficar divertido.

    O Mapa de Transformações

    JTBD bem capturados nos mostram o que precisa ser feito. No mapa ao lado eles aparecem no eixo vertical. A dimensão horizontal nos permite brincar com o como: COMO o trabalho será realizado, contratado, precificado, distribuído e suportado. Enfim, neste eixo nós começamos a cogitar alternativas de solução. Vamos conhecer melhor o mapa. Sua origem é um diagrama apresentado no livro Dual Transformation, de Scott Anthony, Clark Gilbert e Mark Johnson (HBR, 2017). Na falta de um nome, o batizei Mapa de Transformações. Ele é composto por quatro áreas.

    A primeira, no canto inferior esquerdo, representa o Core Business – no caso de uma empresa já existente, está aqui o JTBD que ela atende. A segunda área é representada pela seta ADJACÊNCIAS. Ela acomoda outros JTBD. Repare: todos eles compartilham o modus operandi, ou seja, o COMO. Pense na Amazon vendendo livros, brinquedos ou roupas. O JTBD muda. O COMO é praticamente o mesmo.

    A terceira área do mapa é chamada de Transformação A (seta horizontal). Aqui brincamos de reinventar o hoje. Formulamos hipóteses sobre como criar, entregar, precificar, cobrar e suportar determinada solução para um JTBD. A Netflix mudou dos átomos (DVDs) para os bits (streaming). O JTBD é o mesmo: curtir filmes e séries no conforto de nossas casas. A forma de realizá-lo ficou radicalmente diferente.

    Na quarta e última área do mapa somos convidados a criar o amanhã. É a seta diagonal, a Transformação B. Nela contemplamos novos JTBD e novos modelos de operação, comercialização e suporte. Sua intenção é nítida: resolver o que Clayton Christensen chamou de O Dilema da Inovação (MBooks, 2011). Quem fica bitolado, se iludindo com melhorias incrementais numa zona confortável (Transformação A), pode ser surpreendido por um sanguinário e impiedoso cisne negro. A Transformação B, combinada ao jeito Ágil de pensar, come cisnes negros no café da manhã². A Amazon Web Services é um bom exemplo desse tipo de transformação.

    Conclusão

    Essa combinação de três ferramentas (JTBD, Mapa de Expectativas e Mapa de Transformações) nos ajuda a dar os primeiros passos no sentido de descobrir um problema. O Mapa de Transformações facilita a descoberta e classificação de hipóteses. E nos joga na cara a importância de tratar simultaneamente o hoje e o amanhã. Pense em como essa classificação pode ser útil na elaboração de um portfólio e de roadmaps de produtos, por exemplo.

    Quando comecei esta série falei que deveríamos compreender e diferenciar o VALOR PARA O CLIENTE, o VALOR PARA O TIME e o VALOR PARA O NEGÓCIO. Scott Anthony, em outro trabalho (The First Mile – HBR, 2014), fala da tríade da primeira milha. São três perguntas que precisamos responder:

    1. Há um Trabalho a Executar? A quem ele interessa?
    2. A gente dá conta de criar uma solução viável? Esse trabalho nos motiva?
    3. Essa solução cria valor para o nosso negócio? Quanto?

    O próximo artigo, a terceira parte de nosso Checkup Ágil, vai tratar do segundo ponto acima e explicar o que chamo de VALOR PARA O TIME. Na sequência, eu acho que devo sintetizar as ideias apresentadas nesses nove artigos em um modelo.

    Notas

    1. Anthony  Ulwick é o pai e explorador da criança. Clayton Christensen a popularizou através de seus artigos e livros. Do primeiro há este livro gratuito e um Canvas JTBD. Pois é, mais um canvas…
      Do Christensen eu sugiro a leitura de Muito Além da Sorte (Bookman, 2017), que trata só da Teoria JTBD e suas aplicações.
    2. É muito legal ver como o Movimento Ágil é percebido em situações muito distantes do desenvolvimento de software. Em The Social Labs Revolution (Berrett-Koehler, 2014) Zaid Hassan escreve que “O Ágil come cisnes negros no café da manhã”. Ele mostra como o Scrum ajuda ONGs e similares a resolver problemas realmente complexos, como desnutrição, doenças e analfabetismo em regiões paupérrimas ao redor do mundo. São exemplos que ajudam a rebater alguns mal entendidos que pipocam aqui e ali no mundo Ágil. Mais que isso: mostram como o Movimento ficou grande e maduro por causa e apesar da gente de TI.
    3. Apple of StickyNotes é o título da imagem acima. Compartilhada por StephenMitchell no flickr
  • Se Apaixone pelo Problema

    Se Apaixone pelo Problema

    Nos dois artigos anteriores (1 | 2) tentei mostrar a necessidade de uma maior preocupação com o Domínio do Problema. Eles se concentraram no porquê. O texto de hoje ilustra como podemos nos apaixonar por problemas. A correta definição de um problema é parte do problema¹. Não é uma definição simples. Porque as diversas partes interessadas não enxergam o mesmo problema. Ou não o veem da mesma maneira. Talvez algumas nem reconheçam o problema. Isso pode ser consequência de uma organização meio biruta – sem noção do que quer. Porque o ambiente é cada vez mais incerto e dinâmico. O mais provável é que seja uma mistura disso tudo.

    É certo que o jeito Ágil de pensar – com iterações curtas e feedback rápido – nos ajuda a compreender e delimitar melhor o problema enquanto desenvolvemos e entregamos a solução. Mas qual é o marco zero? Qual deve ser o nosso ponto de partida? Se a gente soubesse o quanto esse primeiro passo influencia o desenho da solução seríamos um tanto mais cuidadosos.

    Qual é o problema? Por que é um problema? Quem é afetado por ele? O que está envolvido? O que pode acontecer se a gente não resolver o problema?

    Desenvolver o sistema X ou o app Y; Aumentar o market share; Reduzir os custos do processo Z; Melhorar a nossa imagem; Aumentar o faturamento em tantos milhões. Nada disso é problema.

    Todas as frases acima sinalizam possíveis soluções. Mas dizem muito pouco ou nada sobre o problema. Foi por isso que o pessoal da Toyota inventou o 5 Porquês. Porque geralmente precisamos de cinco enxadadas para alcançar a raiz do problema.

    Tratar a ferramenta 5 Porquês como guia para uma entrevista 1:1 é um desperdício e tanto. Porque ela só prova todo o seu potencial quando é combinada com outras ferramentas em uma Investigação Sistêmica². Este processo de descoberta deve envolver o maior número possível de interessados, interesseiros e encrenqueiros. Todos juntos no mesmo lugar. As respostas para cada porquê se desdobram em potenciais componentes do verdadeiro problema.

    É um engano relativamente comum entender o Pensamento Sistêmico como uma forma de “ver o todo”. Ver o todo é só uma PARTE desse jeito de pensar. Se vemos só essa parte, perdemos o TODO do Pensamento Sistêmico.
    (A recursividade é intencional. Na dúvida, releia o parágrafo).

    Uma Rica Fotografia

    Orientados pela ferramenta 5 Porquês podemos desenvolver uma Rica Fotografia (Rich Picture, no original em inglês). Esse modelo vem de uma das diversas propostas do Pensamento Sistêmico, a Soft Systems Methodology (SSM), de Peter Checkland. A fotografia é rica porque apresenta o contexto em toda a sua riqueza de diversidade, estrutura, relacionamentos e pontos de vista. DSRP: Distinções | Sistemas | Relacionamentos | Perspectivas. São as quatro regras que, em conjunto, nos ajudam a enxergar e compreender o mundo como ele realmente funciona. Ou seja, nos ajudam a pensar sistemicamente.

    Devemos evitar a definição prévia do tipo de fotografia que queremos. Processos ou cadeias de valor não são indicados porque restringem, logo de partida, a forma como vemos o problema. Além disso, passa da hora da gente entender que esse jeito linear de criação de valor não é onipresente, muito pelo contrário. Enfim, a Fotografia Rica deve nascer sem moldura, grades ou guias. As fronteiras e a lógica do modelo devem emergir. Partimos do problema como apresentado na primeira vez – mesmo que seja um simples “precisamos de um app” – e perguntamos: Por que precisamos de um app?

    As discussões em torno das respostas nos permitem identificar as partes envolvidas e as relações entre elas. A classificação dos relacionamentos – forte, fraco, direto, indireto, entrada, saída, colaborativo, conflituoso, rápido, devagar etc – enriquece a fotografia. Parte da fotografia pode ser capturada na forma de um Mapa Causal (CLD – Causal Loop Diagram). Assim o modelo fica com um jeito de filme – ganha dinâmica.

    Como essa fotografia é produto de um processo colaborativo, é de se esperar que ela capture diversos pontos de vista. Condenamos o processo e o ambiente se alguma perspectiva for favorecida ou ignorada. Se uma pessoa chave não puder participar, adie o encontro. Aliás, a falta de agenda pode ser um sinal de que o problema não é assim tão relevante. Pelo menos, não para aquela pessoa.

    Um subproduto desejável da elaboração da Rica Fotografia é uma igualmente rica análise dos stakeholders (ou partes interessadas). Em uma única reunião somos apresentados não apenas às pessoas envolvidas (holders) mas também ao seu grau de envolvimento, aos seus pontos de vista e interesses (stakes). Isso é de suma importância em qualquer iniciativa porque, como ensinou Gerald Weinberg em The Secrets of Consulting (McGraw-Hill, 1985), “a despeito do que o cliente possa lhe dizer, sempre existe um problema. Não importa o que pareça a princípio, o problema é sempre com as pessoas”.

    A bola chega redonda para DeMarco e Lister, que em Peopleware (Makron Books, 1990) emendam: “os principais problemas de nosso trabalho não são de natureza tecnológica mas sim sociológica”.

    Conclusão

    Vale a pena repetir sempre: não é o modelo; não se trata do entregável (sic). É o processo de elaboração que nos interessa. São as conversas que importam. É a criação de uma visão compartilhada do problema o que buscamos. Isso, por si só, fará você se apaixonar pelo problema? Talvez não. A sugestão aqui apresentada deve te deixar mais íntimo do problema. E problemas, assim como as pessoas, podem nos decepcionar quando desnudados. O que fazer com essa desilusão é outra conversa.

    Que não será a próxima. Se hoje apresentei uma sugestão para tratar de um problema interno e específico, no próximo artigo eu pretendo falar sobre problemas externos e gerais – problemas que nos motivam a criar produtos ou serviços. Desconfio que eles sejam um tanto mais atraentes. Veremos.

    Notas

    1. Gerald Weinberg? Russell Ackoff? Tantos já falaram sobre isso que fica difícil decidir a quem creditar aquela frase.
    2. Como eu queria que a gente tivesse adotado em português um termo bastante comum entre os pensadores sistêmicos: Inquiry – investigação, pesquisa. É bem melhor que análise, descoberta e exploração. Porque explica melhor o trabalho que realizamos.
    3. Heart-it foi compartilhada por The ReflexMan no flickr.
  • Dentro do Buraco

    Dentro do Buraco

    “Não morda o meu dedo, olhe para onde estou apontando.“
    – Warren McCulloch

    “Para o observador casual, definições do problema podem parecer desperdício. É tempo gasto longe do teclado e a educação ocidental nos ensina que estamos enrolando ou sendo improdutivos quando estamos ‘só conversando’. Mas o Lean é cheio de paradoxos como esse.”

    “Muito do Lean é baseado no Pensamento Sistêmico e uma definição de problema bem colocada pode levar o time para além de suas preocupações com a solução – para uma compreensão mais ampla do contexto.”

    “O Lean nos pede para reduzir tensões e inconsistências no sistema. A definição do problema articula um objetivo consistente. São comuns os projetos que sofrem porque seus participantes não estão resolvendo o mesmo problema. Uma definição de problema bem escrita oferece uma visão consistente de direção. Como tal, ela pode ser uma poderosa ferramenta para o time e para a gestão.”

    “Uma boa definição do problema pode funcionar como um catalisador para a auto-organização.”

    “Em uma verdadeira organização Ágil aqueles que são responsáveis pela solução do problema participam da definição do problema. Essa definição deve ajudar a canalizar a energia da organização na direção correta.”

    Lean Architecture | James Coplien e Gertrud Bjørnvig
    Wiley, 2010 – Págs. 68~74

    Eu sabia que não estava sendo original quando escrevi que Histórias – de Valor ou de Usuários – são catalisadoras. Só não lembrava a origem.“Antes de iniciar um sprint de criação-de-valor-para-o-cliente precisamos de um backlog inicial do produto. E para gerar esse backlog nós precisamos da visão do produto. Muitas organizações também acham útil a criação de um roadmap preliminar, definindo uma série de releases incrementais. Chamo as atividades que criam esses artefatos de envisioning ou product-level planning.”

    “O envisioning não deve ser confundido com um pesado e cerimonioso processo de planejamento. No Scrum, nós não acreditamos que podemos (ou devemos) conhecer todos os detalhes de um produto antes de começarmos. Entretanto, nós entendemos que o financiamento de um produto não pode começar sem uma visão; sem um entendimento adequado acerca dos clientes, das features e da solução em alto nível; nem sem uma ideia de quanto o produto vai custar.”

    “Não gastamos muito tempo ou esforço no envisioning porque queremos rapidamente passar do estágio do achismo – quando a gente pensa que conhece as necessidades dos clientes – para as etapas de feedback rápido – para os sprints de criação de valor.”

    Essential Scrum | Kenneth Rubin
    Addison-Wesley, 2013 – Pág. 287

    “O primeiro passo no Scrum é a elaboração da Visão do Produto pelo Product Owner.”

    Scaling Lean & Agile Development | Craig Larman e Bas Vodde
    Cap. 12 – Scrum Primer, por Pete Deemer & Gabrielle Benefield
    Addison-Wesley, 2009 – Pág. 311

    1. Uma VISÃO projeta um futuro onde determinado problema deixa de existir. Uma VISÃO assume o entendimento prévio desse problema.
    2. Ignorar a definição do problema e tratar o envisioning como o “estágio do achismo” (guessing, no original) é frágil e perigoso.
    3. Entender que a elaboração da VISÃO é responsabilidade exclusiva de um PO é detonar, logo de cara, uma boa oportunidade de formar um time de verdade.

    “A diretriz fundamental de qualquer sistema verdadeiramente enxuto consiste em estabelecer e entregar valor definido pelo cliente”.

    “ não devemos gastar esforços ou recursos antes de termos um profundo entendimento do valor definido pelo cliente.”

    Sistema Toyota de Desenvolvimento de Produto | James Morgan e Jeffrey Liker
    Bookman, 2008 – Págs. 45~46

    “A característica organizacional definidora do modelo do Spotify é o conceito de squads com ‘baixo acoplamento e alto alinhamento’. A tese central aqui é que ‘alinhamento permite autonomia – e quanto maior o alinhamento, mais autonomia é possível dar’. É por isso que a empresa passa tanto tempo alinhando todos com objetivos e metas antes de iniciar um trabalho.”

    Tempo Talento Energia | Michael Mankins e Eric Garton
    figurati, 2017 – Pág. 163

    1. A distância que separa a Toyota do Spotify é a mesma que separa o Japão da Suécia. Mas uma coisa elas parecem ter em comum: tempo pra pensar.
    2. Não é curioso que esse tempo para pensar não seja considerado trabalho? Repare na frase destacada no último parágrafo acima. Coplien e Bjørnvig, citados lá no início, já haviam alertado para essa característica bem ocidental de não relacionar esse tipo de conversa com trabalho.

    “Quando você dispara qualquer coisa nova, há forças te puxando para todas as direções. Há coisas que você pode fazer, coisas que você gostaria de fazer e coisas que você precisa fazer. Comece pelo que precisa ser feito. Comece pelo epicentro.”

    Rework | Jason Fried & David Hansson
    Crown Business, 2010 – Pág. 72

    “Tome uma grande decisão sobre sua Visão de forma antecipada e todas as futuras pequenas decisões se tornarão bem mais fáceis.”

    Getting Real | 37signals
    37signals, 2006 – Pág. 43

    “Todo o trabalho com requisitos é precedido por algum tipo de processo de iniciação: alguém tem uma ideia de que algo deve ser desenhado e construído.”

    “Se não formos cuidadosos, a ideia inicial vai colocar todo o processo em um caminho improdutivo do qual nunca vamos nos recuperar. Se os participantes não começarem pensando em conjunto, vamos perdê-los antes de ganhá-los.”

    “Como podemos sintetizar a grande variedade de pontos de partida potenciais em uma plataforma única e sólida para a exploração de requisitos? Uma solução possível é entender cada projeto como uma tentativa de resolver algum problema e então reduzir cada ponto inicial a uma forma comum de descrição do problema.

    “Um problema pode ser definido como: A diferença entre as coisas conforme são percebidas e as coisas conforme são desejadas.”

    Exploring Requirements: Quality Before Design | Donald Gause e Gerald Weinberg
    Dorset House, 1989 – Pág. 49

    “A palavra problema sempre significa algo ruim, como em ‘Houston, temos um problema’ Mas as inovações bem sucedidas sempre envolvem mais atenção ao problema do que às soluções. Einstein um dia disse, “Se eu tiver 20 dias para resolver um problema, gastarei 19 para defini-lo”.

    The Myths of Innovation | Scott Berkun
    O’Reilly, 2007 – Pág. 127

     

    “O problema não é o problema. O problema é a sua atitude em relação ao problema.”

    – Capitão Jack Sparrow

    1. Pois é, terceirizei a argumentação. Parti dos originais e a tradução é livre, provavelmente enviesada e eventualmente desastrada. Por  favor, não morda o meu dedo.
    2. Se você não entendeu minha motivação, por favor, veja o artigo anterior.
    3. Se tem o que acrescentar, por favor, comente!
    4. Aquela foto bem sacada de dentro do buraco é da Alexandra Brovco.
  • O Buraco Comum

    O Buraco Comum

    Não importa se é um bug ou característica programada. O fato é que os métodos e frameworks mais populares – particularmente Scrum e Kanban – tropeçam no mesmo buraco. Apesar de suas imensas diferenças, essas propostas são omissas ou relapsas no mesmo ponto. No distante 1986 Fred Brooks nos alertou¹:

    “A correta definição do que precisa ser feito é a etapa mais difícil do desenvolvimento de sistemas. Nenhuma outra compromete tanto um projeto quando mal executada. E nenhuma é mais difícil de ser corrigida.”

    O que fizemos de lá para cá?

    • Distorcemos todos os currículos relacionados com a formação de engenheiros e analistas de sistemas. Enfatizamos o domínio da solução – programação e mais programação – em detrimento do domínio do problema.
    • Mas a Academia, apressada, estava apenas seguindo o mercado. Um mercado que inventou, em meados dos anos 1990, um tal de analista-programador. Isso tem reflexos negativos até hoje. Basta ver a reincidência de um álibi fajuto: “o cliente/usuário nunca sabe o que quer”. Quem aprendeu a perguntar? Quanta ajuda o cliente/usuário tem merecido?
    • De repente, ganhamos Agilidade. Com muitas propostas que parecem ser “do desenvolvedor, pelo desenvolvedor, para o desenvolvedor”. A coisa só piorou.
    • E tocou o fundo do poço quando alguém acreditou que um Business Model Canvas –  uma cortina feita de papel sulfite – seria capaz de esconder aquele imenso buraco.
    • Oras, e se o buraco for apenas uma hipótese? Vamos todos fingir que o buraco não existe; Ou é parte da decoração; Ou é só a opinião de alguém.
    • Por fim, se o tal Upstream Kanban pretende, ainda que parcialmente, tratar do domínio do problema, então ele não pode começar se apresentando como um “processo de triagem”. Que vai da síntese para a análise? Fixando CONWIPs?!?²

    A Acusação Comum

    Um efeito esquisito do movimento Ágil, que contradiz sua intenção de ser Sistêmico, é a percepção generalizada de que tudo o que não é construção é desperdício. James Coplien e Gertrud Bjørnvig reclamam disso em Lean Architecture (Wiley, 2010). Peter Morville, falando de Arquitetura de Informações, relata o mesmo problema (Intertwingled, 2014). E o que dizer da Análise de Negócios? Que ela deu um tiro no pé quando publicou uma Extensão Ágil. Confessou uma culpa que não deveria ter. Pau que nasce torto…

    A acusação ficou chique e mereceu até sigla: BDUF (Big Design Up Front). É importante destacar que a acusação não é vazia. É preciso lembrar o contexto que motivou o Manifesto Ágil. Era comum, naquele tempo, um mal conhecido como Analysis Paralysis. A burocracia emperrava pacas. Projetos entregavam bulhufas.

    A diferença entre o remédio e o veneno é o tamanho da dose. Erramos a mão e criamos outro mal, a Agile Death Spiral. Sprints sem fim ou fins. Pivots mil. Um desastrado foco na eficiência que ignora o primordial: ao fazer a coisa errada do jeito certo, só estamos acelerando rumo ao desastre.

    Entre a cascata congelada no tempo e o pós-moderno ciclone da morte deve haver um caminho.

    Equilíbrio

    A sugestão do Yin-Yang é de Peter Morville, no livro já citado. A imagem combina bem com a matriz apresentada no artigo anterior. Que esteja subentendida a necessidade de iterações. O ícone também informa que há construção nos momentos iniciais. E que não é proibido rever o problema e repensar os planos nos momentos seguintes.Esse equilíbrio bem zen seria perfeito se o alerta do Brooks não continuasse verdadeiro: aquela primeira metade (escura) é a mais crítica para o sucesso de um projeto ou produto. Mas ela não existe no Scrum, por exemplo³. O que nos levou a entender que bastaria puxar para o domínio do problema o mesmo esquema utilizado no domínio da solução. Vêm daí os sprints 0, -1 etc. Essas iterações podem ser úteis para a realização de spikes (experimentos), configuração do ambiente e coisas do tipo. Mas não têm nada a ver com o domínio do problema. O que é conhecido como grooming também não.

    Sprints com duração fixa de uma, duas ou quatro semanas fazem muito sentido nos trabalhos de DESENVOLVIMENTO e ENTREGA. Mas viram camisas de força nos trabalhos de DESCOBERTA e EXPLORAÇÃO. Nesses momentos, é comum a necessidade de cinco ou dez iterações em uma única semana. Marty Cagan, em Inspired (Wiley, 2017) fala em até vinte iterações. Jake Knapp, em Sprint (Intrínseca, 2016), nos mostra um ciclo completo acontecendo em uma semana. Enfim, a variedade aqui é grande. E necessária.

    O Design Thinking nos oferece ampla variedade de métodos e ferramentas para o Domínio do Problema. Não foi por outro motivo que Jonny Schneider, da Thoughtworks, propôs a seguinte combinação:

    • Design Thinking: para explorar o problema
    • Lean: para construir a coisa certa
    • Agile: para construir do jeito certo

    Legal. Mas o Manifesto Ágil não fala em eficácia logo no seu primeiro princípio? As propostas Lean não parecem preocupadas com eficiência? O Design Thinking não tem o que contribuir para o domínio da solução? A ideia do Schneider é promissora. A mensagem “Lean E Agile” ao invés do OU é correta. Mas a divisão de responsabilidades proposta acima não faz o menor sentido. 

    Acho que nós precisamos de outro enfoque, mais amplo e inclusivo. Precisamos de um modelo que incorpore, sem puxadinhos, uma legítima preocupação com o domínio do problema. Que faça a gente “se apaixonar pelo problema, não pela solução“.  Bom tema para o próximo artigo.

    Notas

    1. No artigo No Silver Bullet, transformado em capítulo da edição comemorativa de The Mythical Man-Month (Addison-Wesley, 1995). Este trabalho, lançado originalmente em 1975 (!), acaba de ganhar nova edição em pt-br: O Mítico Homem-Mês (Alta Books, 2018). Parafraseando Brooks: “a longevidade desse livro atesta que a gente continua caindo nos mesmos buracos…”
    2. São algumas sugestões apresentadas por Patrick Steyart em Essential Upstream Kanban.
    3. Que fique claro: não se trata de um bug do Scrum. A omissão é intencional. E só vira um problema se a gente a ignorar. Ou, pior ainda, se a gente esticar o Scrum para cobrir o buraco.
    4. “Se apaixone pelo problema, não pela solução” é uma das dicas de Marty Cagan em Inspired (Wiley, 2017).
    5. hole in the wall é o título da óbvia imagem de hoje.
  • Checkup Ágil – Parte II

    Checkup Ágil – Parte II

    Como nós criamos e entregamos valor? Na primeira parte deste checkup nós conversamos sobre eficácia. Agora o tema é eficiência: criar e entregar valor do jeito certo. Como trabalhamos? Nosso método realmente ajuda? Calma, não é mais uma comparação entre Scrum e Kanban. Até porque ambos tropeçam no mesmo lugar.A essência de nossos trabalhos é criar valor eliminando problemas. Nossos projetos, produtos e serviços são desenvolvidos para isso. A visão curta – imediatista, mecanicista e reducionista – nos leva a resolver problemas. Quase sempre isso redunda em paliativos e efeitos não previstos nem desejados. Ou seja, em mais problemas. Isso pode até ser um meio de vida: receitas recorrentes, como não? Pode ser um sonho para quem vende horas. E um caro e merecido pesadelo para quem as compra. Mas isso não pode ser a intenção de quem se propõe verdadeiramente Ágil.

    Entre todos os grandes pensadores sistêmicos, Ackoff foi o mais incisivo¹: devemos dissolver problemas. Devemos redesenhar o sistema de forma a evitar reincidências e efeitos negativos. O Pensamento Sistêmico nos dá essa visão privilegiada: de longo alcance, inclusiva e obrigatoriamente atenta à dinâmica das relações entre todos e tudo o que está envolvido em dada situação.

    O mundo Ágil, através de livros e propostas, gosta de apontar o Pensamento Sistêmico como uma de suas bases. É uma pena que, quase sempre, tal referência se limite a um capítulo ou nem isso². Pior ainda é quando o Pensamento Sistêmico é interpretado através de uma visão curta. Vira mera etiqueta que tenta dar ares de coesão e coerência para ideias frouxas. Nesses casos é sempre bom relembrar a Lei de Durden.

    Retomando: como criamos e entregamos valor? Como trabalhamos? Estamos de fato dissolvendo problemas? Ou simplesmente criando outros?

    Método

    O Design Thinking, também derivado do Pensamento Sistêmico, foi feliz ao escolher um losango como representação de um jeito de pensar e eliminar problemas. E muito desastrado quando resolveu trocá-lo por um squiggle. Sigamos com o losango. Na primeira metade temos a compreensão. Na outra, criação. Na primeira metade criamos opções. Na outra, tomamos decisões. Convenhamos, isso é tão antigo quanto andar para a frente. O que o mundo do design nos deu foi uma imagem e termos sofisticados: movimento divergente, movimento convergente. No fundo isso é, sempre foi e sempre será uma sequência de ANÁLISE e SÍNTESE. Necessariamente nessa ordem³.O losango perde sua utilidade quando nos deparamos com dois problemas. Primeiro: esse pensamento é linear. Os problemas que justificam os nossos salários e lucros não são eliminados assim. Eles pedem por iterações porque, como humanos, a chance de acertarmos na primeira tentativa é quase nula. Uma imagem bem melhor é a do semi círculo ornamentado por uma seta que aponta para o início e diz: vamos experimentar, aprender e tentar de novo. E de novo…

    O segundo problema é a necessidade de uma segunda dimensão. Um eixo que nos permita separar o que é CONCRETO do que é ABSTRATO. Dados, fatos, pessoas e soluções são coisas concretas. Ideias, hipóteses, opções, oportunidades e experimentos são abstrações. Acabamos de ganhar mais uma matriz 2×2.Quase todos os frameworks e métodos propostos nas últimas décadas apresentam, em seus próprios termos, a visão acima. O que não se encaixa ali é o jeitão antigo – linear, mecanicista e reducionista – de fazer as coisas. Até o ciclo PDCA (Plan-Do-Check-Act), por exemplo, não combina. Apesar de suas origens sistêmicas e, como tal, ser iterativo. OODA (Observe-Orient-Decide-Act), por sua vez, se encaixa perfeitamente. Se uso outros nomes é para aproximar o modelo de nosso contexto. OODA foi sugerido por um piloto de caças.

    Talvez alguém queira apontar a coincidência dos quadrantes acima com aqueles do Cynefin: Descoberta é Caótica, Exploração é Complexa, Desenvolvimento é Complicado e a Entrega é Simples. A coincidência é feliz. Aliás, esse caminho seria feliz… se não fosse equivocado. Se o problema que pretendemos resolver é complexo, ele não deixa de sê-lo só porque se encontra em outro momento (quadrante) daquele ciclo.

    No próximo artigo nós vamos esticar esse papo. E ver como Scrum, Kanban e derivados compartilham problemas semelhantes. Agora é hora de uma segunda rodada de nosso autoexame.

    Autoexame

    Como a sua organização CRIA e ENTREGA valor?

    • O trabalho executado no lado esquerdo do diagrama acima obedece ao mesmo ritmo e às mesmas restrições daquele que é executado no lado direito? As Sprints têm a mesma duração nesses dois hemisférios?
      Obs.: aos adeptos do Kanban deixo minha desconfiança de que o que chamo de lados esquerdo e direito são, respectivamente, o que vocês tratam como upstream e downstream Kanban. Mas vem coisa nova por aí, um tal Discovery Kanban. O nome não é mera coincidência. A necessidade, tardia, parece óbvia.
    • Você usa sprints 0, -1 e afins para tentar entender o problema?
    • Como são iniciados os seus projetos? Com Histórias de Usuários? Com hipóteses? Com planos?
    • Todas as hipóteses se tornam experimentos?

    Qualquer SIM não é bom sinal.

    Notas

    1. Dois trabalhos sintetizam bem as propostas de Russell Ackoff: Ackoff’s Best (Wiley, 1999) e, para os apressados, Differences that Make a Difference (Triarchy Press, 2010).
    2. Craig Larman e Bas Vodde vão um pouco além de um capítulo em Scaling Lean & Agile Development (Addison-Wesley, 2009) e Large-Scale Scrum – More with LeSS (Addison-Wesley, 2017). O mesmo pode ser dito sobre Managing the Design Factory (Free Press, 1997) e The Principles of Product Development Flow (Celeritas, 2009) ambos de Donald Reinertsen. No entanto, para perceber a aplicação do Pensamento Sistêmico como um todo e no todo (e como é estranho escrever isso) vale a pena ler The Journey to Enterprise Agility: Systems Thinking and Organizational Legacy (Springer, 2017) de Daryl Kulak e Hong Li.
    3. Aquela frase não seria necessária caso eu não tivesse me deparado com Essential Upstream Kanban, de Patrick Steyart. O cara tá falando que a síntese antecede a análise?!?
    4. 4 Windows, compartilhada por gmahender no flickr, ilustra este artigo.
  • Histórias de Valor e Outros Contos

    Histórias de Valor e Outros Contos

    Bons produtos e projetos não começam com hipóteses. Sua pedra fundamental é o correto entendimento dos objetivos – do valor que devem gerar. Histórias de Valor ajudam a descobrir e descrever essas informações. Elas dão sentido ao roteiro de trabalho (roadmap e backlogs) e facilitam a contagem das realizações e de outras histórias.As Histórias de Valor, como vimos no artigo anterior, usam o formato clássico das Histórias de Usuários:

    Como <organização> precisamos <criar algo> para <realizar tais objetivos>

    Como finito eu preciso retomar as conversas com a comunidade Ágil para viabilizar algumas turmas da oficina FDP³.

    Histórias de Valor tapam um buraco meio desconcertante dos métodos ágeis. Nessas propostas utilizamos dois catalisadores de informações nas interações com clientes e usuários: Histórias de Usuários e Épicos. Recentemente começamos a falar sobre Job Stories. Suas diferenças estão fora do escopo deste artigo¹. O que essas ferramentas não explicam é a motivação para aquele projeto ou produto. Afinal, mirando o todo, qual e quanto valor pretendemos gerar?

    Você pode dizer que estamos reinventando rodas. Afinal, já temos ferramentas com esse fim: Business Cases, Project Charters, Documentos de Visão e por aí vai. O grande problema é que esses documentos são de outra era. Repare, são documentos. Por simpáticos que sejam, trazem consigo a pesada bagagem do mundo cascata. É o mesmo problema do termo requisito, por exemplo. Agregar o sobrenome “Ágil” não anula seu histórico. Quando o Scrum chegou com novos nomes – Product Owner, ScrumMaster, Sprints – foi exatamente para evitar qualquer mínimo vínculo com os métodos e modelos que pretendíamos abandonar.

    História de Valor não é um documento. É um catalisador. Repito o termo. É importante explicá-lo. Catalisador, segundo nosso dicionário, é “o que estimula ou dinamiza”. Histórias, em métodos ágeis, têm essa finalidade. São o exato oposto dos documentos. Estes servem para encerrar discussões. Histórias estimulam discussões. São dinâmicas. Se prometemos receber mudanças de braços abertos, é importante que nossas ferramentas incentivem e facilitem isso.

    Mapa e Bússola

    Joi Ito e Jeff Howe, no excelente Whiplash², colocam que nesses novos tempos a bússola é mais importante que os mapas. O mapa é um plano. A bússola, direção. O Manifesto Ágil, em outras palavras, afirma o mesmo desde 2001: “Responder a mudanças mais do que seguir um plano”. Mas as nossas respostas não podem variar como uma biruta. Qual é a nossa bússola? As motivações expressas em cada História de Valor.

    Não dispensamos os mapas. Eles seguem importantes. Mas não fazem muito sentido sem a bússola. Jeff Patton presta um serviço ímpar em User Story Mapping (O’Reilly, 2014). Ele repete, sempre que necessário, que um bom mapa de histórias é orientado por resultados. O único defeito do livro é não definir uma forma para a representação desses resultados. Histórias de Valor servem para isso. Com a vantagem de respeitar o padrão utilizado em todo o mapa.

    Na Prática

    A primeira coisa é não confundir Histórias de Valor com Épicos. Estes são histórias aguardando detalhamento e a inevitável quebra em mais histórias. Épicos podem representar módulos de um sistema ou funções extensas. Histórias de Valor, por outro lado, representam o negócio. Ou, melhor dizendo, um resultado esperado pelo negócio. Se esse resultado depende de uma ou mais funcionalidades – de uma ou mais histórias de usuários ou épicos – não interessa. Aliás, uma história de usuário pode colaborar em diversas Histórias de Valor. Mas ela só pode pertencer a um épico.

    Histórias de Valor são o ponto de partida de qualquer produto ou projeto. Pegamos a bússola, descobrimos a direção e só então desenhamos um mapa (ou roteiro – roadmaps, Mapas de Histórias e backlogs). Por óbvio que isso soe, quantas vezes você testemunhou um projeto sendo iniciado a partir de Histórias de Usuários? Essa carroça bem adiante dos bois, infelizmente, é um mal recorrente. E causa principal de nossos problemas.

    Histórias de Valor não são atômicas. Elas podem ser quebradas de forma a representar uma hierarquia de objetivos e metas. É normal que um projeto tenha algo entre cinco e dez Histórias de Valor. Essa organização facilita a elaboração de um Mapa de Histórias. Mais que isso: facilita o monitoramento dos resultados obtidos. E também pode ser registrada na forma de OKRs ou LogFrames. Pense na possibilidade: o Mapa de Histórias é o detalhamento de um ou mais OKRs. Cada entrada no OKR é uma História de Valor.

    Hipóteses, de novo…

    No artigo anterior critiquei a definição de Valor para o Negócio apresentada por Mark Schwartz em The Art of Business Value (IT Revolution Press, 2016). Ele escreveu que o Valor para o Negócio é “uma hipótese formulada pela liderança sobre a melhor maneira de realizar os grandes objetivos da organização”. A História de Valor nos livra dessa armadilha. O que escrevemos na frente do para não é uma hipótese. É um objetivo claro e devidamente quantificado³. É o Valor para o Negócio. A hipótese existe, mas está em outro lugar: na descrição do que nós precisamos.

    Essas confusões entre o QUE e o COMO e a perigosa mania de tratar tudo como hipótese vão merecer mais conversas. No próximo artigo, a segunda parte de nosso Checkup Ágil, volto a puxar o assunto.

    Notas

    1. Neste artigo do Fabrício Teixeira há uma bela comparação entre User Stories e Job Stories.
    2. Em pt-br esse livro mereceu o terrível título “Disrupção e Inovação” (Alta Books, 2017). Por isso temo pela qualidade da tradução. Falo um pouco mais sobre ele neste artigo.
    3. O exemplo com a FDP³ não representa um bom uso da História de Valor porque não se compromete com números. “Algumas turmas” é ambíguo demais para ser aceito em qualquer contexto ou projeto. O exemplo é interesseiro – vendi meu peixe sem meias palavras.
    4. A foto utilizada neste artigo foi compartilhada por Martin P. Szymczak no flickr.
  • Checkup Ágil

    Checkup Ágil

    Como um médico sádico vou perguntar onde dói e dar repetidas cutucadas ali. Não me leve a mal. Se você está no início de uma Transformação Ágil ou brigando com seus fins e meios, é bom saber o quão saudáveis estão você, seu time e sua organização. Como estão os seus sinais vitais? Aliás, você sabe quais são eles?

    Valor

    O Manifesto Ágil diz que a “nossa principal prioridade é satisfazer o cliente através da entrega adiantada e contínua de software de valor”. Fica por nossa conta descobrir o que significa software de valor. E entender que existem mais valores em jogo: há o VALOR PARA O CLIENTE, claro, mas não podemos ignorar o VALOR PARA O NEGÓCIO e o possível VALOR PARA O TIME. Mais que isso, é crucial entender as relações entre esses valores.

    Apesar das diversas e desastradas manifestações ao contrário¹, VALOR é o nosso mais importante sinal vital. Mas, como vimos, não há um valor único. Muito menos um entendimento compartilhado sobre o que ele significa. Vamos por partes.

    Valor é a medida da importância de algo. Até que ponto aquilo que vale para o seu negócio (departamento ou time) é valorizado pelo seu cliente (ou usuário)? Convenhamos, há poucas chances de acordo ou coincidência. Por isso não devemos confundir VALOR PARA O NEGÓCIO com o VALOR PARA O CLIENTE e/ou USUÁRIO. Cada um puxará a sardinha para o seu lado. Todos repletos de razão.

    O que significa VALOR PARA O NEGÓCIO? Mark Schwartz, em The Art of Business Value (IT Revolution Press, 2016), escreve que o valor para o negócio é “uma hipótese formulada pela liderança sobre a melhor maneira de realizar os grandes objetivos da organização”. Hipótese? Está aqui um terrível legado da moda Lean Startup: parece que tudo virou hipótese. O que tem valor para você é apenas uma hipótese? Duvido. Mas, como comprova o livro do Schwartz, quanto mais pessoas envolvemos, mais esse papo sobre valor fica variado, estranho e difícil.

    Donald Reinertsen (em Managing the Design Factory – Free Press, 1997) tem uma navalha para cortar toda essa variedade: “somos apenas filósofos enquanto não começamos a usar números”. Então, vamos aos números!

    Números

    Como você mede e apresenta o VALOR PARA O NEGÓCIO? Quais números fazem mais sentido? ROI (Retorno sobre o Investimento) e NPV (Valor Presente Líquido), por exemplo, são proxies que se sustentam em previsões. Nós humanos não somos muito bons nisso, em fazer previsões. Segundo Schwartz, “ROI e NPV são o waterfall do mundo financeiro”. Ainda mais importante: o cálculo de ambos, ROI e NPV, exige um numerador que é a representação do valor. Oras, então por que não nos contentamos com ele?

    O uso do Custo do Atraso (CoD – Cost of Delay) é defendido por Reinertsen e Schwartz. Mas ele também depende de uma definição prévia do Valor. Se não sabemos quanto vale, como podemos afirmar ou ao menos prever o custo de seu atraso? Estamos andando em círculos?

    ROI, NPV, CoD e afins representam hipóteses. Carregam incertezas e podem, dependendo do nível de sofisticação, dificultar a comunicação entre os envolvidos em determinada iniciativa. Não pretendemos filosofar. Mas que valor tem uma sequência de cálculos que poucos entendem? É sempre bom relembrar o décimo princípio do Manifesto Ágil: “Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.” Conseguimos exprimir o VALOR PARA O NEGÓCIO de forma simples e direta?

    Histórias de Valor

    Como a Natureba S/A
    nós precisamos de um app que permita que as nossas consultoras registrem e transmitam pedidos em tempo real
    para encurtar o ciclo de vendas em 50% e cortar algo entre R$15M e R$25M dos custos anuais de processamento de pedidos.Como a Webchuteira LTDA
    nós precisamos de um programa de fidelidade vinculado aos sistemas sócio-torcedor dos grandes clubes nacionais
    para aumentar o nosso market share em 40% e o faturamento em, pelo menos, R$100M no próximo ano.Não é curioso que essa proposta simples, derivada do formato clássico das User Stories, seja tão pouco conhecida? Aliás, por favor, não se apegue ao formato. O importante aqui é o que essas histórias nos contam. Conversaremos mais sobre isso no próximo artigo. Porque agora é um bom momento para um autoexame.

    Autoexame

    Você e seu time sabem quanto VALOR estão criando e entregando?

    Se sim:

    • Esse entendimento é compartilhado por todas as pessoas envolvidas?
    • A sequência do roteiro (roadmap e backlogs) reflete nitidamente essa preocupação com a entrega antecipada e contínua de valor?

    Se não:

    • O que diabos está orientando as milhares de decisões que vocês tomam todo santo dia?

    Notas & Esculachos

    1. D’ A Startup Enxuta, de Eric Ries (Leya, 2012), ganhamos essa perigosa e triste mania de achar que tudo é hipótese.
    2. De Jeff Sutherland, cocriador do Scrum, herdamos o peso da promessa do título de seu último livro: A Arte de Fazer o Dobro do Trabalho na Metade do Tempo. O sonho dos tayloristas deveria ser o pesadelo dos agilistas. Afinal, estes se comprometeram com outra arte, a de “maximizar a quantidade de trabalho que não precisou ser feito”.
    3. No Kanban, de David Anderson (Blue Hole, 2010), aprendemos uma “Receita de Sucesso” que só permite conversar sobre VALOR no penúltimo passo de um total de seis. Orientado por uma mentalidade que não tem muito a ver com o trabalho criativo, o último passo da tal receita ainda pede que “ataquemos as fontes de variabilidade”. Não surpreende que o mesmo autor ressuscite agora uma conversa sobre Modelos de Maturidade. O Kurt Cobain vem junto? No carro preto do Ford? Nevermind…
    4. Stickynotes, de Martijn Veening, ilustra este artigo.
  • A Lei de Durden

    A Lei de Durden

    Nós detestamos leis. Mas, quando é caso, falamos que elas estão em falta. Em outras tantas vezes, reclamamos do excesso. Ou dos autores. Que moral tem um legislativo lotado de foras da lei? Até gostaríamos que leis escritas por homens nos dessem um mínimo de tranquilidade. É triste descobrir que elas são frágeis como cascas de ovos. “Escrito em pedra”. Balela. Pedras rolam e perdem a memória. O mundo gira, muda e torna as leis dos homens obsoletas. Ainda bem. Quem gostaria de viver no mundo do “olho por olho, dente por dente”? Melhor não perguntar.

    Porque 33,33% da população mundial gosta da certeza e crê numa estabilidade. É o exato oposto do terço que sempre quer mudar alguma coisa. Esses dois lados brigam por fatias do ? restante. Aquele que, como Humpty Dumpty, adora um muro e vive de quebrar a cara por causa de sua indecisão. Ou por causa de suas decisões. Quem sabe?

    Feitas as contas, não é de se estranhar que apenas 0,01% da humanidade fique com os louros e dólares. E, consequentemente, com as leis dos homens.

    Ah, doce vingança: nem todo o ouro do mundo é capaz de fazer de um trilhardário um imortal. Nenhuma grana corrompe a segunda lei da termodinâmica. E o pedágio da lei da gravidade é caro e dura pouco. Em outras palavras: as leis da natureza são mais confiáveis. Elas valem aqui em Varginha, em New York, Hong Kong e nos novos confins do multiverso. Elas não distinguem o pobre do rico, a mortadela da coxinha. Para elas são indiferentes as cores, crenças e raças. Convém respeitá-las.

    No último artigo eu citei três leis naturais¹ com nomes de homens. Isso confunde.

    A Lei de Ashby diz que só a variedade absorve variedade. Quanto mais diversos os nossos interesses, maiores as nossas chances de sobreviver e prosperar na complexidade. Nosso corpo complexo agradece a variedade dos pratos que comemos. Um time uniforme será bem sucedido num “hello world” e olhe lá.

    A Lei do Conway diz que nossos produtos são nossos espelhos. Somos relaxados, egoístas, desorganizados ou mal estruturados? O produto é prova incontestável. Somos entrosados, equilibrados e bem motivados? O produto brilha. Os clientes agradecem. Oras, é só uma releitura da Regra de Ouro.

    A Lei de Brooks diz que em briga de marido e mulher não se mete a colher. Na verdade, ela fala que colocar mais gente em um projeto problemático é como tentar apagar um incêndio com gasolina. É a mesma coisa, o mesmo princípio. Mais gente, mais ruído, mais confusão.

    Ter o próprio nome numa lei vale quase um Nobel. Isso deve explicar algumas falcatruas. Como pegar “o que não me destrói me fortalece (ou engorda)” e transformar na verborragia de Antifragile. Ok, jogo jogado. Azar do Nietzsche. Assim como foram azarados Occam, Hanlon e Caetano: só batizaram navalhas.

    Mas triste, triste mesmo, é aquele que não pode clamar uma descoberta por não existir. É o caso de Tyler Durden² – uma ficção dentro de uma ficção. Se ele, assim como Vital³, pudesse escrever uma constituição, ela começaria assim: “Uma pena enfiada em sua bunda não faz de você uma galinha”.  A Lei de Durden. Clara como aquela que diz que “para bom entendedor, um pingo é letra.”

    Notas

    1. Confesso, abusei do termo natural. Com boas intenções.
    2. Personagem de Clube da Luta, livro de Chuck Palahniuk (1996) e filme de David Fincher (1999).
    3. Personagem de Dos Margaritas, música dos Paralamas do Sucesso lançada no ótimo e subestimado disco Severino (1994). Vital já havia surgido com uma moto em outro sucesso.
    4. A imagem de hoje, fight club, foi compartilhada por Brent humanartistvendingm no flickr.
    5. Mais leis, navalhas, princípios e teoremas podem ser vistos em Lex Animata – Uma Constituição não Promulgada.
  • Quem Escreve a Partitura?

    Quem Escreve a Partitura?

    Uma conversa sobre organização, times, alinhamento, autonomia e a nossa eterna busca pela batida perfeita.Estou me atualizando com os “novos modelos” :)))
    O cara do     Spotify explicando a cultura da empresa. Autonomy. Squads são equipes multifuncionais que funcionam em modo ágil. Aí ele agrupa os squads em tribes. E as tribes são alinhadas à infraestrutura, aplicações de suporte e de negócio. Hahaha. E você, num squad, se une aos seus pares de outros squads por capabilities. Hahaha. Incrível.
    Aí ele descreve o     squad como uma banda de jazz, onde cada um é autônomo no seu instrumento. Mas esqueceu de mencionar a partitura!!!!! Quem escreve a partitura nesse mundo novo??

    O desabafo veio do outro lado do mundo, de Hong Kong. Foi feito por um colega de longa data. Ele puxou o papo porque lembrou de nossos embates filosóficos de uns dezessete anos atrás. É fácil ficar confuso com alguns novos modelos. Aliás, como disse Tom Peters, “quem não está confuso não está prestando atenção”.

    Também me atualizando em relação ao novos modelos, há poucos dias me deparei com a Teoria da Promessa. WTF?, de Tim O’Reilly, me levou para o trabalho de Mark Burgess, Thinking in Promises (O’Reilly, 2015). Criador da tal teoria, Burgess a apresenta como “uma linguagem para descrever e discutir o comportamento cooperativo entre diferentes agentes ou atores”. Se esses agentes ou atores são homens ou máquinas (algoritmos), não faz diferença. Aliás, esta seria a força da proposta: um único modelo a guiar as pessoas e tudo o que elas constroem.

    A teoria explicaria o funcionamento e a eficiência da Amazon, por exemplo¹. Um agente só pode prometer algo que está 100% sob seu controle. Cada agente é uma caixa preta – não importa como ele mantém ou cumpre a promessa. O que interessa é o que foi prometido. Se prometo e cumpro, mereço confiança. Se todos os agentes fazem o mesmo, temos um perfeito ambiente colaborativo.

    Burgess alerta que não está propondo um manifesto nem uma agenda filosófica ou política. Mas é difícil não associar a proposta ao liberalismo. Como não pensar assim ao perceber que o modelo é 100% bottom-up, uma declaração da autonomia incondicional de um agente? O autor é claro: ninguém pode fazer promessas em nome de outro(s). Um componente Java não pode prometer a disponibilidade do banco de dados. Um gerente não pode prometer a eficácia do designer nem a pontualidade do projeto. Cada agente só se compromete com aquilo que está totalmente em seu domínio. Convenhamos, a teoria é simpática. E a prática?

    Como isso funcionaria numa cultura como a brasileira, onde cada vez mais brasileiros detestam (ou, amenizando, desconfiam dos) outros brasileiros? Parafraseando O’Reilly, para cada Webgoal ou Nubank temos milhares de empresas que se caracterizam pela absoluta falta de confiança N:N – de todos para todos, na horizontal, de cima para baixo, de dentro para fora e vice-versa.

    Meu colega está distante de nossas mazelas e aguarda uma resposta: afinal, quem escreve a partitura?

    Burgess diz que “organizações são redes de promessas”. O que orienta a elaboração das promessas? Há uma partitura? Ela é uma promessa? De quem?

    O autor fala sobre um conjunto de agentes, um Super Agente que faz promessas coletivas. Um Super Agente é “um fantasma e, como tal, não possui um canal de comunicação”. Nesse ponto interrompi a leitura².

    Autonomia X Alinhamento

    O debate, que deve ter começado quando éramos apenas caçadores-coletores, é bom e merece a nossa atenção. Ele recebe outros nomes, como Centralização X Descentralização, Hierarquia X Holarquia (ou Holacracia) etc. O problema nunca esteve nos fatores. Está no operador – no OU.

    Faz sentido que a gente busque autonomia E alinhamento. O melhor exemplo é o nosso corpo. Nossos subsistemas são autônomos. Não há ninguém microgerenciando o coração ou o esôfago. Nosso cérebro-CEO não fica ditando ao pulmão: inspira, expira, inspira, expira… Mas, em sã consciência, estamos no controle. Todos temos uma partitura, ainda que mal escrita. Apesar (por causa!) da autonomia, nossos subsistemas funcionam alinhados. Ou, como escreveu Jurgen Appelo³, “sistemas complexos sobrevivem e prosperam porque o controle é distribuído”.O gráfico ao lado tenta ilustrar o desafio. Num extremo, aquelas empresas que seriam modelos. No outro, o famigerado Dilbert e sua organização sem pé nem cabeça. Quantas empresas passaram por reestruturações que ora puxavam a corda na vertical, ora afrouxavam a corda horizontal; Quebravam a cara e começavam tudo de novo, numa interminável e improdutiva valsa?

    Há Partituras

    Na Amazon, por exemplo, a construção de um novo serviço (ou microserviço ou funcionalidade) só é autorizada depois de uma Rich Discussion Up Front. Essa discussão se dá em torno de uma documentação elaborada pelo proponente do novo serviço. Essa proposta geralmente é composta por um Press-Release, FAQ, Protótipos e, quando necessário, até um manual do usuário.

    Quem escreveu a partitura-documentação? Um time autônomo. O que garante o alinhamento? Aquela tal rica discussão prévia. Se aquela proposta (promessa) não fizer sentido para a organização, ela não recebe luz verde. Quem participa das discussões? No caso da Amazon, dependendo da proposta, até o próprio Bezos. Foi assim, por exemplo, que nasceu a AWS. É como no nosso corpo: quando o caso – ameaça ou oportunidade – é realmente sério, ele merece a alocação do cérebro-CEO.

    Os “Novos Modelos”

    Não são poucos os que, como meu colega, demonstram ceticismo em relação aos novos modelos. Desconfio que seja porque 1) O que se proclama novo, muitas vezes, não é tão novo assim. A ideia de escrever um manual antes de qualquer coisa, por exemplo, pode ser rastreada até The Mythical Man-Month que Fred Brooks publicou em 1975! Squads, chapters, tribes, guilds?! Apelidos pós-modernos e uma certa complicação para ideias que estão por aí há tempo. Capítulos e guildas, por exemplo, são releituras das velhas Comunidades de Prática; 2) Muitas empresas não precisam, não podem ou simplesmente não querem ser como Amazon, Spotify, Uber ou afins. Nem todo mundo precisa ou quer ostentar um chifre.

    Por fim, um parágrafo que insistiu em permanecer: A montagem de times deveria respeitar apenas três leis: a de Ashby e a de Conway sempre, e a de Brooks toda vez que um projeto atrasar. As outras, até a “regra das duas pizzas”, podem ser ignoradas dependendo do contexto e das intenções.

    Meu colega é exigente. Desconfio que ele não se dará por satisfeito. Nem você. Que o papo prossiga. Inté!

    Notas

    1. WTF? What’s the Future and Why It’s Up to Us – Tim O’Reilly (HarperBusiness, 2017).
    2. Que ainda vou retomar. Não posso desconsiderar toda a proposta só porque não concordo com uma afirmação. Mas preciso deixar claro o seguinte: no meu entendimento, um super agente – seja ele um time, unidade, serviço, filial etc – é, necessariamente, um Sistema Aberto. Como tal, é claro que ele tem não apenas um mas vários canais de comunicação. Posso não entender como ele funciona – é uma caixa preta – mas sei me comunicar com ele, colocar meus pedidos e requisitos, chamar suas APIs, entender e negociar suas promessas. Não sei se entendi errado. Mas aquele “fantasma” me assustou.
    3. #Workout – Happy Melly Express, 2014
    4. “Online” Sheet (Tweet) Music é o criativo achado de John Dyer que ilustra este artigo.

    Gostou da conversa? Ela é esticada e enriquecida na oficina Design de Negócios Viáveis.

    A próxima edição acontece em São Paulo no próximo dia 2/2.

    Posso fazer alguma coisa para viabilizar a sua participação? Fale comigo!

  • Quem Escreve a Partitura?

    Quem Escreve a Partitura?

    Uma conversa sobre organização, times, alinhamento, autonomia e a nossa eterna busca pela batida perfeita.Estou me atualizando com os “novos modelos” :)))
    O cara do     Spotify explicando a cultura da empresa. Autonomy. Squads são equipes multifuncionais que funcionam em modo ágil. Aí ele agrupa os squads em tribes. E as tribes são alinhadas à infraestrutura, aplicações de suporte e de negócio. Hahaha. E você, num squad, se une aos seus pares de outros squads por capabilities. Hahaha. Incrível.
    Aí ele descreve o     squad como uma banda de jazz, onde cada um é autônomo no seu instrumento. Mas esqueceu de mencionar a partitura!!!!! Quem escreve a partitura nesse mundo novo??

    O desabafo veio do outro lado do mundo, de Hong Kong. Foi feito por um colega de longa data. Ele puxou o papo porque lembrou de nossos embates filosóficos de uns dezessete anos atrás. É fácil ficar confuso com alguns novos modelos. Aliás, como disse Tom Peters, “quem não está confuso não está prestando atenção”.

    Também me atualizando em relação ao novos modelos, há poucos dias me deparei com a Teoria da Promessa. WTF?, de Tim O’Reilly, me levou para o trabalho de Mark Burgess, Thinking in Promises (O’Reilly, 2015). Criador da tal teoria, Burgess a apresenta como “uma linguagem para descrever e discutir o comportamento cooperativo entre diferentes agentes ou atores”. Se esses agentes ou atores são homens ou máquinas (algoritmos), não faz diferença. Aliás, esta seria a força da proposta: um único modelo a guiar as pessoas e tudo o que elas constroem.

    A teoria explicaria o funcionamento e a eficiência da Amazon, por exemplo¹. Um agente só pode prometer algo que está 100% sob seu controle. Cada agente é uma caixa preta – não importa como ele mantém ou cumpre a promessa. O que interessa é o que foi prometido. Se prometo e cumpro, mereço confiança. Se todos os agentes fazem o mesmo, temos um perfeito ambiente colaborativo.

    Burgess alerta que não está propondo um manifesto nem uma agenda filosófica ou política. Mas é difícil não associar a proposta ao liberalismo. Como não pensar assim ao perceber que o modelo é 100% bottom-up, uma declaração da autonomia incondicional de um agente? O autor é claro: ninguém pode fazer promessas em nome de outro(s). Um componente Java não pode prometer a disponibilidade do banco de dados. Um gerente não pode prometer a eficácia do designer nem a pontualidade do projeto. Cada agente só se compromete com aquilo que está totalmente em seu domínio. Convenhamos, a teoria é simpática. E a prática?

    Como isso funcionaria numa cultura como a brasileira, onde cada vez mais brasileiros detestam (ou, amenizando, desconfiam dos) outros brasileiros? Parafraseando O’Reilly, para cada Webgoal ou Nubank temos milhares de empresas que se caracterizam pela absoluta falta de confiança N:N – de todos para todos, na horizontal, de cima para baixo, de dentro para fora e vice-versa.

    Meu colega está distante de nossas mazelas e aguarda uma resposta: afinal, quem escreve a partitura?

    Burgess diz que “organizações são redes de promessas”. O que orienta a elaboração das promessas? Há uma partitura? Ela é uma promessa? De quem?

    O autor fala sobre um conjunto de agentes, um Super Agente que faz promessas coletivas. Um Super Agente é “um fantasma e, como tal, não possui um canal de comunicação”. Nesse ponto interrompi a leitura².

    Autonomia X Alinhamento

    O debate, que deve ter começado quando éramos apenas caçadores-coletores, é bom e merece a nossa atenção. Ele recebe outros nomes, como Centralização X Descentralização, Hierarquia X Holarquia (ou Holacracia) etc. O problema nunca esteve nos fatores. Está no operador – no OU.

    Faz sentido que a gente busque autonomia E alinhamento. O melhor exemplo é o nosso corpo. Nossos subsistemas são autônomos. Não há ninguém microgerenciando o coração ou o esôfago. Nosso cérebro-CEO não fica ditando ao pulmão: inspira, expira, inspira, expira… Mas, em sã consciência, estamos no controle. Todos temos uma partitura, ainda que mal escrita. Apesar (por causa!) da autonomia, nossos subsistemas funcionam alinhados. Ou, como escreveu Jurgen Appelo³, “sistemas complexos sobrevivem e prosperam porque o controle é distribuído”.O gráfico ao lado tenta ilustrar o desafio. Num extremo, aquelas empresas que seriam modelos. No outro, o famigerado Dilbert e sua organização sem pé nem cabeça. Quantas empresas passaram por reestruturações que ora puxavam a corda na vertical, ora afrouxavam a corda horizontal; Quebravam a cara e começavam tudo de novo, numa interminável e improdutiva valsa?

    Há Partituras

    Na Amazon, por exemplo, a construção de um novo serviço (ou microserviço ou funcionalidade) só é autorizada depois de uma Rich Discussion Up Front. Essa discussão se dá em torno de uma documentação elaborada pelo proponente do novo serviço. Essa proposta geralmente é composta por um Press-Release, FAQ, Protótipos e, quando necessário, até um manual do usuário.

    Quem escreveu a partitura-documentação? Um time autônomo. O que garante o alinhamento? Aquela tal rica discussão prévia. Se aquela proposta (promessa) não fizer sentido para a organização, ela não recebe luz verde. Quem participa das discussões? No caso da Amazon, dependendo da proposta, até o próprio Bezos. Foi assim, por exemplo, que nasceu a AWS. É como no nosso corpo: quando o caso – ameaça ou oportunidade – é realmente sério, ele merece a alocação do cérebro-CEO.

    Os “Novos Modelos”

    Não são poucos os que, como meu colega, demonstram ceticismo em relação aos novos modelos. Desconfio que seja porque 1) O que se proclama novo, muitas vezes, não é tão novo assim. A ideia de escrever um manual antes de qualquer coisa, por exemplo, pode ser rastreada até The Mythical Man-Month que Fred Brooks publicou em 1975! Squads, chapters, tribes, guilds?! Apelidos pós-modernos e uma certa complicação para ideias que estão por aí há tempo. Capítulos e guildas, por exemplo, são releituras das velhas Comunidades de Prática; 2) Muitas empresas não precisam, não podem ou simplesmente não querem ser como Amazon, Spotify, Uber ou afins. Nem todo mundo precisa ou quer ostentar um chifre.

    Por fim, um parágrafo que insistiu em permanecer: A montagem de times deveria respeitar apenas três leis: a de Ashby e a de Conway sempre, e a de Brooks toda vez que um projeto atrasar. As outras, até a “regra das duas pizzas”, podem ser ignoradas dependendo do contexto e das intenções.

    Meu colega é exigente. Desconfio que ele não se dará por satisfeito. Nem você. Que o papo prossiga. Inté!

    Notas

    1. WTF? What’s the Future and Why It’s Up to Us – Tim O’Reilly (HarperBusiness, 2017).
    2. Que ainda vou retomar. Não posso desconsiderar toda a proposta só porque não concordo com uma afirmação. Mas preciso deixar claro o seguinte: no meu entendimento, um super agente – seja ele um time, unidade, serviço, filial etc – é, necessariamente, um Sistema Aberto. Como tal, é claro que ele tem não apenas um mas vários canais de comunicação. Posso não entender como ele funciona – é uma caixa preta – mas sei me comunicar com ele, colocar meus pedidos e requisitos, chamar suas APIs, entender e negociar suas promessas. Não sei se entendi errado. Mas aquele “fantasma” me assustou.
    3. #Workout – Happy Melly Express, 2014
    4. “Online” Sheet (Tweet) Music é o criativo achado de John Dyer que ilustra este artigo.

    Gostou da conversa? Ela é esticada e enriquecida na oficina Design de Negócios Viáveis.

    A próxima edição acontece em São Paulo no próximo dia 2/2.

    Posso fazer alguma coisa para viabilizar a sua participação? Fale comigo!