PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Donald Reinertsen

  • 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.
  • 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.
  • ferramentas, FERRAMENTAS

    ferramentas, FERRAMENTAS

    Nossa era da ansiedade é, em grande parte, o resultado de tentarmos fazer o trabalho de hoje com as ferramentas de ontem – com os conceitos de ontem.
    – Marshall McLuhan

    Que tal começar com uma autoanálise? Pense em quantas ferramentas você conheceu nos últimos tempos. Quantas você experimentou? Quais foram incorporadas ao seu dia a dia? Considere tanto aquelas que só demandam papel e caneta quanto os brilhantes apps que inundam seu smartphone. Quais o tornaram um profissional melhor, mais produtivo e eficaz?

    Há muita conversa sobre ferramentas e respectivos guias de seleção e uso, os métodos. Que parte desse papo se concretiza? Quantos trabalhos se tornaram mais eficazes, rápidos e até prazerosos por causa de novas ferramentas? Temo que poucos, muito poucos.

    Participando de reuniões variadas em empresas idem, o que mais vejo é o puro improviso. Não há ordem nem um mínimo sistema dando sentido aos debates. De vez em quando alguém rabisca algumas ideias. Mas a solução do problema em questão, se acontece, é fruto de muito trabalho (e retrabalho) ou do acaso. Quem está ali conhece uma série de ferramentas. Talvez até desconfie que algumas seriam úteis naquele momento. Mas, por algum motivo, abre mão de aplicá-las. Qual motivo? Ou melhor, quais motivos?

    Hábitos, Vícios e Preconceitos

    Velhos hábitos e vícios são duros de matar. Desaprender é mais difícil do que aprender. Se pretendemos aplicar novos conceitos e ferramentas, antes de mais nada, precisamos abrir espaço para eles. Não é algo que ocorre do dia para a noite. Por nítidas que sejam as vantagens de uma nova técnica, o conforto do que é conhecido parece maior. E exerce uma atração irresistível. Na pressa, também comum, optamos pelo caminho que dominamos. Fazendo vista grossa para o fato dele ser o caminho mais longo e, não raro, mais acidentado.

    Outro motivo é confessado em algumas fichas de avaliação de meus treinamentos: “isso não vai funcionar na minha empresa”; “isso não é compatível com a cultura de minha empresa”; “minha empresa não está pronta para isso”; e por aí vai. Não há nem a chance ou curiosidade de experimentar um novo jeito de pensar e trabalhar. Porque regras nunca escritas seriam intransponíveis. Quem, em sã consciência, impediria ganhos de produtividade? Como pode uma ferramenta não testada ser incompatível por natureza? Tente imaginar uma carpintaria incompatível com um martelo, por exemplo. Coisa estranha.

    Assim como são estranhos alguns preconceitos. Adjetivos como “metódico” e “sistemático” são mais frequentes em tom pejorativo. Raramente aparecem como um elogio. O que é metódico e sistemático é invariavelmente chato e indesejado? De onde vem isso? Não é dos dicionários, que relacionam os termos com o perfil de alguém “que procede com método” ou “que segue ou observa um sistema”. Ou seja, são predicados de quem pensa o próprio trabalho. São características necessárias se pretendemos vencer as barreiras colocadas nos dois parágrafos anteriores.

    Voltemos ao McLuhan, citado lá em cima. Até quando insistiremos em ferramentas e conceitos de ontem? O que falta para que você faça um upgrade em seus ativos – no seu cinto de utilidades?

    Transição

    A entrevista de Jeffrey Immelt, presidente do conselho de administração da GE, para a EXAME (edição 1145 de 13/09/17) pode surpreender. A GE de Jack Welch serviu como modelo para muita gente. A cultura de controle e ferramentas como o Seis Sigma já foram coisas invejadas. Aquela GE não existe mais. Nas palavras de Immelt:

    “O Seis Sigma elimina a experimentação. O FastWorks (método ágil e enxuto desenvolvido pela GE) gira em torno da experimentação. O Seis Sigma visa eliminar falhas. No FastWorks, as falhas são endêmicas. Empresas burocráticas perdem rapidez.”

    Immelt não está fazendo nada mais do que seguir um conselho do próprio Jack Welch: “Mude antes de ser obrigado a fazê-lo”. A transição não é pequena. Uma nova cultura está nascendo. E, com ela, novos conjuntos de ferramentas.

    Para Pensar e Agir

    Donald Reinertsen, em Managing the Design Factory (Free Press, 1997), classifica as ferramentas em dois grupos¹:

    • Ferramentas para Pensar: nos ajudam a delimitar, relacionar, estruturar e avaliar determinado problema ou situação. Pensamento Sistêmico, Teoria da Informação, Teoria das Filas, Pensamento Lean e Pensamento Visual são alguns exemplos
    • Ferramentas para Agir: apoiam a execução de determinado trabalho. Diagramas de Efeitos e de Processos, cerimônias, canvases e quadros mil entram nessa categoria. 

    Trabalhos recentes – alguns livros de Design Thinking e o famoso Gamestorming (Alta Books, 2014), por exemplo – desfilam dezenas de ferramentas para agir sem o alicerce de uma teoria unificadora. Isso, por si só, não é um problema. Boas ferramentas provam o seu valor de forma pontual, sem dependências ou requisitos. No entanto, um bom profissional não vive desprovido de métodos e conceitos – sem Ferramentas para Pensar.

    Temos aqui outra tendência difícil de explicar e justificar: o desprezo pelas teorias. Entender o contexto que levou à criação de uma ferramenta – conhecer o seu porquê – é condição para sua aplicação eficaz. Não é por acaso que vemos tantos debates estéreis sobre métodos e ferramentas por aí: falta educação. Para detonar o preconceito (contra teorias e teóricos), Kurt Lewin tem uma boa provocação: “Não há nada mais prático do que uma boa teoria”.

    Assim como não há nada mais eficaz do que boas ferramentas se a nossa intenção é ganhar produtividade. Jurgen Appelo, autor de Management 3.0 (Addison-Wesley, 2011), faz uma aposta ainda maior: boas ferramentas podem nos ajudar a mudar ou implantar culturas. Essa é a proposta de seu novo projeto, Agility Scales².

    Plano de Ação

    Um plano para a reciclagem contínua de seu cinto de utilidades:

    1. Seja teimoso: experimente a ferramenta em três ou mais situações diferentes. Não desanime nem fale mal de uma coisa que você mal conhece. É possível e esperado que sua produtividade caia nas primeiras tentativas. Afinal, você está aprendendo. Lembre-se de como aprendeu a nadar ou andar de bicicleta. Tombos, água e sapos engolidos fazem parte do processo.
    2. Seja desobediente: afinal, a cultura de sua empresa não está escrita em pedra. Teste a ferramenta. Se você for bem sucedido, a empresa ganhou. Mostre os dados, fatos e ganhos. Se ainda assim você for proibido de usar a ferramenta, talvez seja hora de amarrar seu burrinho em outro lugar. Se você for mal sucedido, não desconsidere o que acabou de aprender. Pelo contrário, compartilhe!
    3. Seja aberto: e não perca tempo em debates bobinhos sobre ferramentas e métodos. Lembre-se sempre de que a quantidade de ferramentas dominadas é tão importante quanto a qualidade delas. É lógico que você terá as suas preferências. Por isso mesmo saberá quando um contexto não for favorável a elas. Você não quer queimar o filme de seus xodós, quer?
    4. Seja humilde: e não perca nunca a mentalidade de iniciante e a disposição para aprender. Immelt, na entrevista citada, diz que a resiliência (seu principal aprendizado) só se tornou possível quando ficou mais humilde. 
    5. Invista: As ferramentas formam parte considerável de seus ativos (tema do artigo anterior). Ativo largado é ativo depreciado. Faz quanto tempo que você não aprende e de fato aplica uma ferramenta nova? Se quiser alguma ajuda, consulte minha agenda acima, considere o investimento e volte ao passo #1.

    Notas

    1. Craig Larman e Bas Vodde pegaram carona nessa categorização. E chegaram a estruturar livros assim: Scaling Lean & Agile Development – Thinking and Organizational Tools for Large-Scale Scrum e Practices for Scaling Lean & Agile Development (Addison-Wesley, 2009 e 2010, respectivamente).
    2. Cito este projeto com uma ponta de orgulho e outra de inveja. Há semelhanças com o flit, ideia que apresentei há pouco mais de um ano. A grande diferença talvez esteja na minha ênfase nos Trabalhos a Executar (JTBD – Jobs to be Done) e em Ferramentas para Pensar, particularmente no Pensamento Sistêmico. Não tenho dúvidas de que o Agility Scales vingará. Daí a inveja. E gás novo para insistir nesse papo.
    3. Tool board, de Dean Wiles, ilusta este artigo.
  • +Requisitos +Informação

    +Requisitos +Informação

    Segue o papo sobre Requisitos e Conversas. Depois dos exemplos da semana passada, hora de um pouco mais de teoria básica. Os temas de hoje são Informação, Comunicação, ruído e a relevância disso tudo para o trabalho com requisitos.

    Em tempos de big data pra cá e muito ruído e contação de histórias vazias pra lá, é sempre bom relembrar o básico, (porque talvez ele já não seja assim tão) óbvio e intuitivo. Do começo: o que é informação? Difícil ser mais direto e eficaz que Bateson: “informação é a diferença que faz diferença“. A fórmula ao lado¹ nos diz a mesma coisa, de um jeito diferente.

    Na prática: o previsível, o corriqueiro, o redundante e o repetitivo não nos ensinam (informam) nada ou praticamente nada. (Esta frase  parece querer confirmar o que ensina.) E o valor daquilo que pouco informa é irrisório ou nulo. Particularmente em projetos, porque informação é sua principal matéria-prima.

    Choque de realidade: talvez você já tenha visto por aí um catatau com dezenas ou centenas de páginas chamado “especificação funcional” (sic) ou algo parecido. Aplique a fórmula ou regrinha acima para ter uma rápida noção do valor, da quantidade de informação de verdade que aquele documento carrega. Lembre-se das redundâncias, ambiguidades, contradições e encheção de linguiça ali persistida. Agora considere quanto aquele entregável (sic 10x) custou: as horas gastas em entrevistas, reuniões, revisões do documento etc. O quão economicamente útil é um documento assim?

    Vale dizer, o problema nem é necessariamente o formato. Tem muito quadro kanban por aí que mal vale uma nota de três reais, apesar da sua belezura e pseudo-modernidade. Antes da forma, deveríamos nos preocupar com o conteúdo.

    + Comunicação

    O Houaiss nos ensina que comunicação é a “transmissão de uma mensagem”. A crença na eficácia desta comunicação de uma via tem causado sérios problemas. Até no frio relacionamento entre computadores há a preocupação com a recepção – com a garantia da entrega de uma mensagem. Na comunicação entre pessoas a questão é um tanto mais complexa.

    Existem diversos modelos² que ilustram todo o processo de comunicação entre pessoas. Vou apelar para um básico³:

    • Transmitida: a informação foi enviada;
    • Recebida: a pessoa na outra ponta recebeu a informação;
    • Entendida: o receptor entendeu a mensagem. Se não, é provável que o processo se reinicie com a transmissão da informação de forma diferente. Este ciclo pode se repetir diversas vezes, até que haja o entendimento;
    • Aceita: o receptor concorda com o que foi informado. Se o ciclo anterior era para compreensão, agora pode existir um ciclo de negociação. Que também pode requerer um reinício – um retorno ao primeiro estado;
    • Convertida em Ação: o receptor faz algo a respeito da informação que recebeu, entendeu e aceitou.

    Em nosso dia a dia, em todo tipo de comunicação, o processo pode ser interrompido em qualquer ponto acima. Você pode, por exemplo, entender o que está escrito aqui e não aceitar e consequentemente não fazer nada a respeito. No trabalho com requisitos é importante que o analista busque o quinto estado – a conversão em ação – de toda informação de fato relevante para o projeto.

    Quando trabalhamos em projetos, particularmente com requisitos, deveríamos ver comunicação da seguinte maneira4:

    Comunicação = Informação * Relacionamentos * Feedback

    A informação vale por si só, por ser “a diferença que faz diferença”. Mas sua simples transmissão não tem valor nenhum. A fórmula acima sugere que a comunicação vai de fato ocorrer se existir um bom relacionamento entre os interlocutores. Mas não basta. Mesmo no mais harmonioso dos ambientes, a comunicação exige mecanismos de feedback que garantam que a mensagem transmitida seja recebida, entendida, aceita e, de alguma maneira, convertida em ação.

    O alcance da definição acima ultrapassa e muito o escopo desta série. Tentarei mostrar apenas a relevância daquela fórmula nos trabalhos de desenvolvimento e análise de requisitos.

    Para tanto, que tal outra fórmula5?

    Resposta = Informação + Confirmação + Ruído

    A confirmação verbal do entendimento é a melhor depois da telepatia. -Jurgen AppeloA confirmação é o tal mecanismo de feedback da fórmula anterior. Precisamos dela, mas nem sempre a conseguimos na primeira resposta. Independentemente da qualidade da pergunta. Por isso consideramos que uma resposta sem confirmação está incompleta. E formulamos a questão seguinte com o único propósito de obtê-la.

    Entre informações e confirmações, invariavelmente recebemos ruídos. Merece este nome – ruído –  aquela palavra, gesto, olhar, sussurro ou tic nervoso que não conseguimos decifrar em um primeiro momento. Pode não ser nada. Mas pode ser uma informação ou mesmo uma confirmação carente de atenção. Decifrar ruídos no sentido de obter boas respostas e excelentes requisitos é uma das artes (secretas?) dos bons analistas.

    Esta série ainda merecerá um ou mais capítulos específicos sobre conversas, perguntas , respostas e ruídos. O básico do básico sobre informação e comunicação foi colocado. No próximo artigo conversaremos especificamente sobre informações em requisitos. Te espero lá.

     

    Notas

    1. Surrupiada do fundamental Managing the Design Factory, de Donald Reinertsen (Free Press, 1997). Ainda devo a entrada deste em nossa biblioteca.
    2. Um dos modelos de comunicação mais referenciados foi criado por Virginia Satir e publicado em The Satir Model: Family Therapy and Beyond (Science and Behaviour Books, 1991). Você entendeu bem: terapia de família! Gerald Weinberg utiliza o Modelo Satir em diversos livros.
    3. Scott Berkun também cita o Modelo Satir em A Arte do Gerenciamento de Projetos (Bookman, 2008). É dele o modelo básico utilizado neste artigo.
    4. Esta fórmula veio de Management 3.0, livro de Jurgen Appelo bastante citado por aqui e em outros lugares.
    5. A última fórmula foi retirada de Redefinindo a Análise e o Projeto de Sistemas, de Gerald Weinberg (McGraw-Hill, 1990) – um livro que todo analista de negócios deveria conhecer. Para não ter o mesmo destino dos analistas de sistemas…

     

  • Pensando Negócios – Referências

    Pensando Negócios – Referências

    A série que se encerra aqui mal arranhou os temas arquitetura de negócios, pensamento sistêmico, complexidade etc. Se este trabalho tem algum valor, ele está exatamente na combinação desses temas. Iniciativa ainda rara, particularmente em terras tupiniquins. Ainda…

    As ideias compiladas neste trabalho vêm de um grande número de cabeças. Recomendo abaixo apenas as obras fundamentais. Porque acredito que quem gostou dos temas da série e pretende aprofundar seus estudos quer: i) dar passos seguros neste novo e traiçoeiro terreno; ii) ter contato com os exemplos que não consegui construir;  e iii) ser provocado a pensar e construir seus próprios modelos e exemplos.

    Thinking in Systems

    Donella Meadows, assim como Russell Ackoff e Jay Forrester, dedicou toda a sua vida ao estudo (e ensino) de sistemas complexos. Ficou famosa ao publicar, em 1972, o livro The Limits to Growth. Há quarenta anos ela já demonstrava a preocupação com a sustentabilidade de nosso planeta. E apresentava sua tese utilizando lentes de sistemas.

    Thinking in Systems: A Primer é um livro póstumo, publicado em 2008 pela Chelsea Green Publishing. Donella trabalhava neste livro desde o início da década de 1990. Era um projeto xodó, concebido para sintetizar mais de três décadas de experiência com sistemas complexos em uma linguagem acessível.

    Texto básico e fundamental para o entendimento de sistemas. Donella ilustra dezenas de exemplos (um “Zoológico de Sistemas”) através de diagramas de estoque e fluxo. E nos ensina a lidar com sistemas relacionando cinco dicas principais:

    1. Observe o comportamento do sistema;
    2. Aprenda a sua história;
    3. Dirija seu pensamento para a dinâmica,
      não para a análise estática;
    4. Não se limite a entender o que está errado.
      Descubra como chegamos até aqui; e
    5. Busque o por quê: por que o sistema se comporta assim?

    Se o pensamento sistêmico é novo para ti, então este livro é o ponto de partida ideal.

    Systems Thinking – Managing Chaos and Complexity

    Jamshid Gharajedaghi foi aluno e parceiro de Russell Ackoff. Seu livro, publicado em 2011 pela Elsevier/Morgan Kaufmann, é um dos primeiros a combinar pensamento sistêmico e arquitetura de negócios. Na capa é prometida “uma plataforma para o desenho da arquitetura de negócios”.

    Jamshid começa praticamente do zero, revendo conceitos básicos sobre sistemas. Não é didático como Donella, mas entrega o que promete. O livro é organizado em quatro partes:

    1. Filosofia de Sistemas: O Nome do Diabo
    2. Teoria de Sistemas: A Natureza da Besta
    3. Metodologia de Sistemas: A Lógica da Insanidade
    4. Prática de Sistemas: Os Poucos Corajosos

    Títulos fortes e irônicos. O texto é mais sisudo, mas não deixa de ser claro. Não concordei com todas as sugestões apresentadas, mas elas me fizeram pensar. Surrupiei descaradamente de Jamshid sua visão das cinco dimensões de um sistema sociocultural.

    Se sua intenção é aprender a desenhar ou redesenhar negócios sob a ótica de sistemas, este é o livro. E não apenas porque ainda é o único a propor tal combinação.

    O Que Importa Agora

    Gary Hamel não utiliza a linguagem de sistemas. Mas a compreensão da complexidade que nos cerca e as sugestões apresentadas neste livro não são apenas compatíveis com as ideias apresentadas acima. São complementos mais que necessários. Gary é um dos principais pensadores do mundo dos negócios e da administração do século 21.

    O Que Importa Agora (Elsevier/Campus, 2012) dedica cinco capítulos para cada item que importa agora. São eles:

    1. Valores
    2. Inovação
    3. Adaptabilidade
    4. Paixão
    5. Ideologia

    Hamel confessa desconhecer uma única empresa que seja exemplar em todos os critérios listados. Mas conta histórias reais que ilustram de forma bastante objetiva os bons e os  maus exemplos. Os sopapos nos gananciosos de Wall Street e em mercadores de modas gerenciais são particularmente saborosos.

    Por falar em sabor, Gary escreve no prefácio que seu livro é “apenas um tira-gosto num pé-sujo”. Pode até ser, mas é daquele tipo de tira-gosto que merece cada centavo.

    Ao término do livro, Hamel dispara 25 tiros à lua elaborados por um grupo chamado MiX – Management Innovation Exchange. Fonte perene de boas ideias para tempos bicudos.

    Outras Fontes

    Quantas vezes mais vou surrupiar e citar Management 3.0, de Jurgen Appelo? Até a chegada da versão 4.0, você diria. Não se deixe enganar por esse tipo de numeração. E não superestime nossa capacidade de evolução. Acho que não estaremos mais aqui – eu com certeza não estarei – quando as ideias sugeridas neste livro virarem arroz com feijão. Sou um otimista incurável, por isso acho que levaremos só meio século para desfazer as cagadas cometidas durante todo o século passado. Um bom resumo das propostas de Jurgen pode ser visto nesta apresentação.

    Appelo é cofundador de um grupo que, a exemplo do MiX citado acima, se propõe a debater (questionar!) liderança e gerenciamento de uma maneira geral. É o Stoos Network, que tem um satélite em formação na cidade de São Paulo. Interessados naqueeeele clube que sugeri em maio passado devem gostar desta iniciativa.

    Seria uma imensa injustiça não citar Managing the Design Factory, de Donald Reinertsen (Free Press, 1997). Afinal, são dele diversos guias apresentados nesta série. Só não vou detalhar mais a obra porque ela merecerá uma entrada específica na biblioteca {finito}.

    Chopps

    Parte de minha meia dúzia de leitores fez contato off-blog durante a elaboração da série. Para tirar dúvidas, debater sugestões ou simplesmente jogar conversa fora. Um papo em especial merece registro. Teve o carioca Igor Couto como interlocutor e durou pouco mais de duas horas. Aconteceu logo após a publicação da quinta parte, aquela sobre cultura.

    Igor (que pelo silêncio não deve ter curtido o tabuleiro), queria uma ajuda para “visualizar” as dimensões culturais. Guiamos a conversa da mesma forma que sugeri na série: trabalhando exclusivamente com uma das cinco dimensões (pra lembrar: riqueza, conhecimento, poder, valores e beleza). Escolhemos conhecimento para começar. No meu ponto de vista, a mais visível (ou visualizável). 

    O carioca me ajudou muito quando pediu para ver um processo de desenvolvimento (de software) sob o prisma sugerido. Eu disse: Scrum! Veja como o Scrum tem resposta para os três tipos de aprendizado (geração e disseminação de conhecimento) sugeridos na parte V: Ele nos leva a aprender a aprender (através das retrospectivas) e também a aprender a fazer (através das revisões e encontros diários). E a experiência do trabalho conjunto ensinam time e indivíduos a ser. As duas primeiras respostas são intencionais – ativa e explicitamente almejadas pelo método – enquanto a última é efeito do uso (correto e prolongado) daquele  framework.

    Agora, uma provocação: quantas vezes você se deparou com um processo de negócio  equipado de forma a intencionalmente promover a geração e disseminação de conhecimento?

    Lógico que a conversa com o Igor foi muito mais extensa. Lá pelo final sugeri que ele visse as dimensões soft como se fossem o ESB (Enterprise Service Bus) da arquitetura de negócios. Como o Igor, entre outras coisas, é um arquiteto de software, a analogia caiu como um chope gelado goela abaixo em um fim de tarde no Rio 40°.

    Espero que este resumo o ajude também. E, principalmente, que o incentive a puxar conversa. Vai um chopps aí?

     

  • Universos Paralelos: O Samba e o Bebop

    Universos Paralelos: O Samba e o Bebop

    É muito pouco provável que alguém do Universo Samba (Negócios) perca dois minutos de sono ou dois fios de cabelo por causa deste artigo proveniente do Universo Bebop (TI). As interfaces fraquinhas e o pouco interesse que um nutre pelo outro – apesar da mútua dependência – tendem a deixar tudo (caduco) como está. Como sou metido a besta e me sobrou um tempinho, vou jogar dois gravetos verdes nessa acanhada fogueira.

    Não entendeu nada, né? Eu explico. O artigo em questão compila uma série de reclamações que Steve Denning, autor de The Leader’s Guide to Radical Management (Jossey-Bass, 2010), publicou na revista Forbes. Denning reclama de um certo conservadorismo por parte dos “gerentes” e da “tendência muito antiga de se ignorar ideias novas e ousadas”. Condena, no atacado, a relutância ou desconhecimento dos “gerentes” do que seria o movimento Agile.

    Me surpreendi com uma das conclusões de Denning. A de que os “grandes avanços na área de gestão” obtidos através de métodos ágeis não pegaram no mundo dos negócios porque não foram pessoas ou acadêmicos “de negócio” que os criaram. Foram os nerds, segundo suas próprias palavras. Em outro trecho, uma derrapada comprometedora:

    “O mundo gerencial continua em estado de negação sobre as descobertas dos métodos ágeis. Você pode explorar as páginas da Harvard Business Review e dificilmente encontrará quaisquer referências, mesmo que indiretas, para as soluções que a filosofia ágil oferece aos problemas gerenciais da atualidade.”

    De onde Denning acha que brotaram 80% das ideias que compilamos e etiquetamos como agile, lean etc? Será que ele se lembra que o Scrum, por exemplo, é inspirado em um artigo da mesma Harvard Business Review de janeiro de 1996? E o que dizer dos artigos e do trabalho de Donald Reinertsen, autor de Managing the Design Factory¹ (The Free Press)? Ele aparece na mesma InfoQ e está na edição atual (maio/2012) da edição brasileira da HBR, com o artigo Seis Mitos do Desenvolvimento de Produtos. Qual é o problema? O fato de vários autores (de negócios) não revenderem a marca Agile, apesar de a influenciarem e serem influenciados por ela?

    Eu só boto Bebop no meu Samba…

    … quando Tio Sam tocar um tamborim”². Esta citação apareceu em um papo que rolou com o amigo Leandro Mendonça. Ele trabalha em outro universo: Publicidade. E tem como uma de suas diversões favoritas ver como a patota de TI reinventa a roda, registra patente e bebemora o feito. O artigo em questão, além de comprovar este ciclo, não contribui em nada para uma mudança da situação. Pelo contrário, parece fechar portas. Veja, por exemplo, as “dez objeções perenes da gestão” apresentadas:

    1. “O Agile é apenas para estrelas – Ao ser confrontado com a escolha entre o alto desempenho e a mediocridade, a gerência tradicional escolhe a segunda”.
      pv: Existe mesmo algum gerente que, em sã consciência, faz opção pela mediocridade?
    2. “O Agile não se enquadra em nossa cultura organizacional – No mercado dos dias atuais, ou as empresas mudam sua cultura ou morrem. A cultura das empresas deve ser ágil”.
      pv: Não sei de nada, mas desconfio de muitas coisas³. Desconfio, por exemplo, que mudanças impostas, arbitrárias (“deve ser ágil”), são mais efêmeras que bolas de sabão.
    3. “O Agile apenas funciona para projetos pequenos – Já existem soluções óbvias para se lidar com projetos grandes…
      pv: Impressionante como “óbvio” constantemente se parece com álibi (“não tenho uma boa resposta”) ou falta de respeito (“você é burro e não perderei meu tempo contigo”).
    4. “O Agile requer que as equipes estejam no mesmo lugar – … pode-se usar tecnologias para manter a comunicação aberta e contínua”.
      pv: Nenhum gerente sabe disso. Mal sabem que já inventaram o telégrafo!
    5. “O Agile é fraco em processos gerenciais – A não ser que você escolha uma metodologia ágil que já atenda a todos os processos necessários, é importante juntá-la com outra que supra os processos não cobertos”.
      pv: Difícil imaginar resposta pior. Ou o Agile deixou de questionar os “processos necessários e não cobertos”?
    6. “O sistema de recompensas individuais de nossa empresa não se encaixa no Agile – É o sistema de recompensas que está errado, não o Agile. Mude o sistema”.
      pv:  Mude o sistema e tente explicar para o Zé, que rende quatro vezes mais que o João, porque ambos passarão a receber a mesmíssima recompensa. Em Management 3.0, Jurgen Appelo nos explica que “não há nada inerentemente errado com sistemas de recompensas individuais. Eles só se tornam um problema nas mãos de ingênuos que desconhecem seus riscos”.
    7. “O Agile é algo passageiro – Não se trata de uma solução para todos os problemas… O Agile é a solução para um problema particular, ou seja, a reaproximação de uma execução disciplinada com a criatividade e a inovação”.
      pv: A questão, ou, usando os termos do artigo original, a “objeção perene” era outra. Agile é passageiro? Nada, em nenhum dos dois universos, que passe dos onze anos de vida pode ser classificado como “passageiro”. Ele veio para ficar? Meu caro, além da beleza da Catherine Deneuve, da estupidez humana e das embalagens de plástico, o que mais veio para ficar?
    8. “Há ideias melhores que o Agile – Em vez de entrar nessa briga, prefira buscar os aspectos comuns entre estes movimentos e junte forças para obter um resultado mais efetivo”.
      pv: Santa saída estratégica pela direta, Batman! Sempre existirão ideias melhores que outras, dependendo do contexto. Como Agile também se apresenta como “cultura” e “filosofia”, talvez valha a pena “entrar na briga” ao invés de fugir ao primeiro desafio apresentado.
    9. “Nada de novo aqui – Todos os componentes individuais do Agile já existem há algum tempo. O que é novo é juntar todos estes elementos de uma maneira coerente e integrada”.
      pv: Acho que fui mais corajoso ao afirmar anteriormente que 80% dos componentes do Agile já existiam. O que a resposta acima omitiu foi a origem desses componentes. Não estaria neste reconhecimento uma boa arma para vencer as “objeções perenes” dos gerentes?
    10. “Não é uma comparação justa? – Introduzir Agile (de verdade) significa expor todos os truques encobertos que os gerentes, em hierarquias tradicionais, utilizam sobre seus subordinados para manter o poder”.
      pv: E assim Agile vira o sol que vai revelar todos os segredos dos gerentes e, de quebra, dar uma desinfetada no ambiente. Talvez esteja aqui, nesta ingênua acusação, a principal razão pela qual ainda temos muitos gerentes relutantes em relação ao Agile. Caramba, eles foram apontados como os inimigos desde o início. Appelo de novo: “Acredito que o desenvolvimento Agile negligenciou a importância da gestão. Se os gerentes não sabem o que fazer e o que esperar de uma organização Agile, como esperar que eles se envolvam na transição para o desenvolvimento Agile? Qual é a mensagem aqui? Se é apenas ‘não precisamos de gerentes’, então não surpreende o fato de estarmos conversando sobre ‘objeções perenes’”.

    Não estou isentando os gerentes de nada. Quem sou eu para isentar alguém de qualquer coisa? Existem sim os gerentes relutantes e ignorantes e muitos deles seguirão existindo, não importa o que façamos ou quanto gritemos. Mas passou da hora da gente, dos que acreditam na proposta Agile, assimilarmos um velhíssimo dito chinês, aquele que ensina: “quando apontar o dedo para alguém, repare para onde apontam três dedos”. É de quem vende uma ideia, de quem propõe uma mudança, o ônus da prova. Show me the money!, dizem os caras de negócios. Enquanto não provarmos nossas teses com fatos, números e valores, estaremos apenas e simplesmente (simploriamente?) filosofando.

    Os caras não colocarão bebop no samba deles enquanto não pegarmos nos tamborins, mora?

     

    Notas

    1. São raros os trabalhos do mundo Agile que souberam equilibrar, como Reinertsen neste livro, as preocupações com Organização, Processos e Produto (Arquitetura do). Uma honrosa exceção é Agile Project Management, de Jim Highsmith. Reparem como nossos papos andam monotemáticos: processo, processo, processo… Scrum, Kanban, baranga-dã… Outra diferença fundamental do trabalho de Reinertsen, já demonstrada anteriormente em Desenvolvendo Produtos na Metade do Tempo (Futura, 1997), é a preocupação com a Economia – com a grana que o produto pode gerar e com os custos que o projeto deve suportar.
    2. Foi Jackson do Pandeiro quem escreveu “Chiclete com Banana” e desafiou Tio Sam a pegar um tamborim. Foram Leandro Mendonça e Pedro Braga que me deram esse presente. Ou será que surrupiei a ideia indevidamente?
    3. Foi Guimarães Rosa quem originalmente disse não saber de nada mas desconfiar de muita coisa.
    4. Tamborim, a imagem utilizada, é de Schröedinger’s Cat.