Sistema: para entendermos que o TODO deve ser maior que a soma das partes; Para fazer com que as ferramentas conversem entre si. Como o JTBD troca ideias com um OKR? De que forma eles se relacionam com épicos e histórias? Como eles apoiam a organização e priorização do backlog? Precisamos de um mapa.

Mapa Rico

São duas as principais inspirações para a sugestão que segue. A primeira é o Pensamento Sistêmico. Mais especificamente, a Rich Picture proposta por Peter Checkland somada ao DSRP. A segunda fonte de inspiração é o livro User Story Mapping de Jeff Patton (O’Reilly, 2014). Vejamos.O diagrama é formado por três camadas: Bússola, Mapa e Roteiro.

Bússola: seja dia ou noite, faça chuva ou faça sol, ela sempre nos dá o norte. Em nosso caso, ela sempre lembra as motivações do produto. Motivações, no plural, porque buscamos criar valor para o cliente (expresso no JTBD) e para o negócio (VS – Value Stories). Um GPS sempre ajuda. Aqui ele atende pela sigla OKR (Objectives and Key-Results). Você informa para onde quer ir (JTBD + VS) e ele te guia, mostrando a sua distância em relação aos Resultados-Chave. O ‘O’ de objetivo é o elo entre as três ferramentas.  

Mapa: se estamos falando de um produto ou serviço que será comercializado, faz sentido que o mapa capture toda a jornada do cliente. Por isso temos um cabeçalho identificando o que ocorre Antes, no Início, Durante e Depois da compra ou contratação. A inspiração aqui é o Service Blueprint. Na primeira linha desenhamos as ações do cliente na forma de um fluxograma. Na linha inferior colocamos o trabalho interno – tudo o que precisa ser feito para que o cliente tenha aquela experiência. Se você registrou Atividades-Chave em um Business Model Canvas, por exemplo, é nessas duas linhas que elas serão desenhadas. Se você identificou Recursos-Chave no Canvas, faz sentido explicar quando e onde eles serão necessários. Daí a terceira linha do mapa. Jeff Patton é econômico nesta camada, mas não desmerece o seu valor. Tanto que a trata como o Backbone (espinha dorsal).

Roteiro: ou, para ser menos direto, Roadmap + Product Backlog. Porque um backlog orientado pelo negócio, pela experiência do cliente, faz muito mais sentido do que uma fila indiana. Quando alguém vê um item², entende não apenas o que ele é e deve fazer mas também o seu propósito. O contexto está dado: onde e quando aquela função ou atributo é necessário. A posição vertical dos itens indica prioridades. Quanto mais alto, maior a contribuição do épico/história para a realização dos resultados descritos no OKR. Mas não ficamos só nisso. Em cada item devemos registrar o seu valor³. E, oportunamente, também o seu custo. As linhas divisórias do roteiro são traçadas em outro momento, quando já temos razoável noção do que precisa ser feito. Podemos dizer que a primeira linha representa o MVP/MVS (Minimum Viable Product / Solution). O importante é que cada linha (cada versão do produto) se comprometa com resultados. Daí o lembrete ou detalhamento de OKRs no canto direito do diagrama.

O mapa é uma ferramenta que pode acomodar, como no exemplo acima, outras ferramentas. Não é uma colcha de retalhos. É um sistema. Ou, caso queira, é uma história que deve ser contada de forma colaborativa. E iterativa. O mapa evolui na medida em que navegamos entre os trabalhos de descoberta, exploração, desenvolvimento e entrega.No exemplo acima tivemos que colocar o roteiro no lado direito. A bússola (post-its no topo e anotações no canto) foi junto.

As informações (quem, o que, quanto, onde, quando) descobertas, o conhecimento (como) desenvolvido e a compreensão (por que) alcançada com o apoio das ferramentas citadas são essenciais para o desenvolvimento de um produto. O Mapa Rico pode ser a principal ferramenta de um PO. Mas, claro, não pode ser a única.

Notas

1. E isso justifica, em partes, o intervalo de dois meses desde o último artigo. As sugestões aqui apresentadas foram testadas em uma turma da oficina FDP e com três times do Ateliê de Software, uma empresa que é 100% Ágil há dez anos. Agradeço ao pessoal do Ateliê pela oportunidade e acolhida. E ao Will pela foto.
2. O diagrama indica quatro formatos possíveis para itens: Épicos, US – User Stories, JS – Job Stories e UC – Use Cases. Poderia ter citado protótipos também. Não são variações do mesmo tema. Cada formato captura informações e perspectivas diferentes. Vale sempre lembrar: só a variedade absorve variedade. E existe coisa mais variada do que desejos, necessidades, restrições e caprichos de clientes e usuários?
3. Se você pretende utilizar um conjunto da sequência de Fibonacci ou escalas mais simples não importa. Importante é que isso seja pensado e negociado. E que a régua definida para o Valor seja a mesma utilizada na aferição dos custos. 
4. Rectilinear, de Stuart Caie, ilustra este artigo.

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.

Se pretendemos estudar, criar e impulsionar negócios, precisamos de vários modelos. Não de um amontoado de diagramas, jogos e canvases, mas de ferramentas que, em conjunto, nos ajudem a contar histórias.

Este é o objetivo desta videoaula: apresentar uma caixa de ferramentas fundamentais para o desenho de negócios – peças para boas histórias.[videoembed url=”https://youtu.be/M05FktlYJVE”]

Observações

• A aula foi transmitida ao vivo, via Youtube, no dia 19/9/2017.
• Existem pequenas falhas no vídeo. Peço desculpas por isso.

A sua organização é viável? Como ela estará quando a crise passar? O que lhe diz isso? A contabilidade? Um canvas? Sério?

Este vídeo mostra um jeito diferente de olhar, desenhar e diagnosticar negócios. Veja como um modelo bem pensado pode trazer novas questões, perspectivas e possibilidades.[videoembed url=”https://youtu.be/Bz3dwRu9Kyk”]

Observações

• A aula foi transmitida ao vivo no dia 26/7/2017.
• Existem algumas pequenas falhas no vídeo. Peço desculpas por isso.

• Atual: o que realizamos hoje
• Capacidade: o que a gente poderia realizar
• Potencial: o que a gente deveria realizar

Lembre-se, podemos medir qualquer coisa. O que você ou sua empresa produz? O artigo anterior falou de pamonhas. Mas poderia ser o número de clientes atendidos, linhas de código programadas (argh!), palavras escritas, pedidos colocados – enfim, qualquer coisa. Qualquer coisa que mereça ser medida, claro.

Cada medição sugere um momento: presente, curto prazo e indeterminado. Cada uma requer um plano diferente.

Hoje

Nossas operações e processos do dia a dia são algoritmos¹. Nosso plano para o cotidiano merece o nome Programação. Conhecemos nossa capacidade instalada – sabemos o máximo que podemos produzir. Se não somos levianos, também temos uma boa noção do mínimo esperado. Pronto, temos uma faixa programada.

É um conceito comum. Nossos corpos, por exemplo, trabalham com limites fisiológicos: temperatura, pressão arterial, batimentos cardíacos. Nossos negócios também operam dentro de limites “fisiológicos”: fluxo de caixa, lucratividade, crescimento, market share etc.

Gerenciar, nesse nível, significa prestar atenção nas oscilações gritantes – aquelas que escapam dos limites programados. Anualmente? Mensalmente? Não gente – todo dia, a cada minuto (se o seu negócio assim demandar).

Amanhã

Mesmo cientes de que nenhum sistema (máquinas, nós ou negócios, por exemplo) consegue operar continuamente acima de 75% de sua capacidade, é nossa obrigação, enquanto gestores, buscar o máximo de produtividade. Como vimos no artigo anterior, um atalho comum é o corte da capacidade (custos). Solução nefasta, muitas vezes inevitável. “Fazer mais com menos” é o mantra vigente.

Falamos aqui de outro tipo de plano. Realocamos recursos, redesenhamos processos e revisamos políticas a fim de aproveitar melhor a capacidade instalada – ou seja, para aumentar a produtividade. Novamente, é um trabalho diário – constante. Quem não pode melhorar?

Depois de Amanhã

Subtítulo não literal. Este é o nível que chamei de indeterminado. Preciso explicar. Apesar da profusão de horizontes pré-fixados (trimestre, ano, biênio etc), não seria coerente nem correto delimitar algo aqui. Cada pessoa ou negócio tem tempo e ritmo diferentes. Alguns planos são de longuíssimo prazo (SpaceX, pré-sal, Hyperloop). Outros, o exato oposto. Independente do caso, há um plano.

Se os dois anteriores olham para dentro, este mira lá fora. Coleta e analisa dados, estuda tendências, ouve reclamações, críticas e sugestões. E desse big conhecimento, planeja novas capacidades.

Outra analogia com o corpo humano é possível. Enquanto o plano “Amanhã” fecha, o plano “Depois de Amanhã” abre. Como bem percebeu Patrick Hoverstadt², esse movimento lembra a respiração. Um está tentando aproveitar ao máximo a capacidade instalada. O outro está mudando e melhorando a capacidade instalada. Uma empresa sem esse processo diário não está respirando. Se está, é por aparelhos.

Soou dramático porque é dramático. Uma empresa é um organismo vivo. Como tal, ela muda todo dia. Assim como seu corpo muda a cada instante. Pois é: “melhoria contínua”, “organização que aprende” e termos afins não representam diferenciais nem vantagens competitivas. São condições sine qua non de sobrevivência – de viabilidade.

No entanto, cada organismo tem um metabolismo diferente. O mesmo vale para negócios. Alguns, por necessidade, são mais rápidos. Outros, por definição, são mais lentos. Muitos, por desespero, estão apressados tentando tirar o atraso.

OKR

OKR – Objectives and Key Results, é uma ferramenta de planejamento que nasceu na Intel e ganhou fama depois das derivações adotadas por Google, LinkedIn e outras. Sua simplicidade é desconcertante.

Fixamos um grande objetivo. Ele, obrigatoriamente, é qualitativo. Por exemplo: “ser uma marca respeitada”; “ser uma organização reconhecida pela sua responsabilidade social”. Um objetivo deve ser conciso e inspirador; Melhor que os meus exemplos, por favor.

Depois, para cada objetivo, amarramos de dois a cinco Resultados-Chave. Eles são quantitativos e indicam o quão próximos ou distantes estamos de atingir aquele objetivo.

O jeitão – a estrutura da ferramenta é simples. Seu manuseio, nem tanto. E uma das dificuldades recorrentes está na própria definição dos objetivos e resultados, sua granularidade e escopo.

O viciante ciclo contábil leva autores e praticantes e elaborar OKRs trimestrais e anuais³. Insisto: esse tipo de restrição não faz sentido. Que a contabilidade siga seu ciclo – até porque ele é determinado por lei. Nossos planos, cada um deles, devem ter sua cadência e calendário próprios.

OKR Sistêmico (ou Cibernético)

Lembra-se do papo da última semana, quando eu escrevi que ferramentas sistêmicas, quando bem combinadas, podem enriquecer outras ferramentas? Pois bem, se o Balancete Cibernético permite gerenciar o meu trabalho ou negócio em tempo real, por que não utilizar sua estrutura para planejar? Cada unidade (Atual, Capacidade e Potencial) vira um Resultado Chave do OKR. Imagine o belo e sucinto dashboard que isso dá.

E se eu quiser ir mais longe, brincando com o Porquê, os Quês e Comos de todo bom plano? Transformo o OKR em um LogFrame (Logical Framework). Quer saber como? Te conto mais tarde (qua, 26/7 – 19h30), na aula aberta Imagens da Organização. Até lá!

Notas

1. Não é mera coincidência que essa divisão de um negócio em três camadas apareça em tantos trabalhos distintos. Roger Martin, em Design de Negócios (Campus, 2010), apresenta o Funil do Conhecimento. E relaciona o nível operacional com Algoritmos. Fui com ele.
2. Em The Fractal Organization: Creating sustainable organizations with the Viable System Model (Wiley, 2009).
3. Paul Niven e Ben Lamorte em Objectives and Key Results (Wiley, 2016) e Christina Wodtke em Radical Focus (Boxes & Arrows, 2016), por exemplo.
4. flikr1316 é a imagem de hoje, novamente por Kelbv.

• Atual: o que realizamos hoje
• Capacidade: o que a gente poderia realizar
• Potencial: o que a gente deveria realizar

Lembre-se, podemos medir qualquer coisa. O que você ou sua empresa produz? O artigo anterior falou de pamonhas. Mas poderia ser o número de clientes atendidos, linhas de código programadas (argh!), palavras escritas, pedidos colocados – enfim, qualquer coisa. Qualquer coisa que mereça ser medida, claro.

Cada medição sugere um momento: presente, curto prazo e indeterminado. Cada uma requer um plano diferente.

Hoje

Nossas operações e processos do dia a dia são algoritmos¹. Nosso plano para o cotidiano merece o nome Programação. Conhecemos nossa capacidade instalada – sabemos o máximo que podemos produzir. Se não somos levianos, também temos uma boa noção do mínimo esperado. Pronto, temos uma faixa programada.

É um conceito comum. Nossos corpos, por exemplo, trabalham com limites fisiológicos: temperatura, pressão arterial, batimentos cardíacos. Nossos negócios também operam dentro de limites “fisiológicos”: fluxo de caixa, lucratividade, crescimento, market share etc.

Gerenciar, nesse nível, significa prestar atenção nas oscilações gritantes – aquelas que escapam dos limites programados. Anualmente? Mensalmente? Não gente – todo dia, a cada minuto (se o seu negócio assim demandar).

Amanhã

Mesmo cientes de que nenhum sistema (máquinas, nós ou negócios, por exemplo) consegue operar continuamente acima de 75% de sua capacidade, é nossa obrigação, enquanto gestores, buscar o máximo de produtividade. Como vimos no artigo anterior, um atalho comum é o corte da capacidade (custos). Solução nefasta, muitas vezes inevitável. “Fazer mais com menos” é o mantra vigente.

Falamos aqui de outro tipo de plano. Realocamos recursos, redesenhamos processos e revisamos políticas a fim de aproveitar melhor a capacidade instalada – ou seja, para aumentar a produtividade. Novamente, é um trabalho diário – constante. Quem não pode melhorar?

Depois de Amanhã

Subtítulo não literal. Este é o nível que chamei de indeterminado. Preciso explicar. Apesar da profusão de horizontes pré-fixados (trimestre, ano, biênio etc), não seria coerente nem correto delimitar algo aqui. Cada pessoa ou negócio tem tempo e ritmo diferentes. Alguns planos são de longuíssimo prazo (SpaceX, pré-sal, Hyperloop). Outros, o exato oposto. Independente do caso, há um plano.

Se os dois anteriores olham para dentro, este mira lá fora. Coleta e analisa dados, estuda tendências, ouve reclamações, críticas e sugestões. E desse big conhecimento, planeja novas capacidades.

Outra analogia com o corpo humano é possível. Enquanto o plano “Amanhã” fecha, o plano “Depois de Amanhã” abre. Como bem percebeu Patrick Hoverstadt², esse movimento lembra a respiração. Um está tentando aproveitar ao máximo a capacidade instalada. O outro está mudando e melhorando a capacidade instalada. Uma empresa sem esse processo diário não está respirando. Se está, é por aparelhos.

Soou dramático porque é dramático. Uma empresa é um organismo vivo. Como tal, ela muda todo dia. Assim como seu corpo muda a cada instante. Pois é: “melhoria contínua”, “organização que aprende” e termos afins não representam diferenciais nem vantagens competitivas. São condições sine qua non de sobrevivência – de viabilidade.

No entanto, cada organismo tem um metabolismo diferente. O mesmo vale para negócios. Alguns, por necessidade, são mais rápidos. Outros, por definição, são mais lentos. Muitos, por desespero, estão apressados tentando tirar o atraso.

OKR

OKR – Objectives and Key Results, é uma ferramenta de planejamento que nasceu na Intel e ganhou fama depois das derivações adotadas por Google, LinkedIn e outras. Sua simplicidade é desconcertante.

Fixamos um grande objetivo. Ele, obrigatoriamente, é qualitativo. Por exemplo: “ser uma marca respeitada”; “ser uma organização reconhecida pela sua responsabilidade social”. Um objetivo deve ser conciso e inspirador; Melhor que os meus exemplos, por favor.

Depois, para cada objetivo, amarramos de dois a cinco Resultados-Chave. Eles são quantitativos e indicam o quão próximos ou distantes estamos de atingir aquele objetivo.

O jeitão – a estrutura da ferramenta é simples. Seu manuseio, nem tanto. E uma das dificuldades recorrentes está na própria definição dos objetivos e resultados, sua granularidade e escopo.

O viciante ciclo contábil leva autores e praticantes e elaborar OKRs trimestrais e anuais³. Insisto: esse tipo de restrição não faz sentido. Que a contabilidade siga seu ciclo – até porque ele é determinado por lei. Nossos planos, cada um deles, devem ter sua cadência e calendário próprios.

OKR Sistêmico (ou Cibernético)

Lembra-se do papo da última semana, quando eu escrevi que ferramentas sistêmicas, quando bem combinadas, podem enriquecer outras ferramentas? Pois bem, se o Balancete Cibernético permite gerenciar o meu trabalho ou negócio em tempo real, por que não utilizar sua estrutura para planejar? Cada unidade (Atual, Capacidade e Potencial) vira um Resultado Chave do OKR. Imagine o belo e sucinto dashboard que isso dá.

E se eu quiser ir mais longe, brincando com o Porquê, os Quês e Comos de todo bom plano? Transformo o OKR em um LogFrame (Logical Framework). Quer saber como? Te conto mais tarde (qua, 26/7 – 19h30), na aula aberta Imagens da Organização. Até lá!

Notas

1. Não é mera coincidência que essa divisão de um negócio em três camadas apareça em tantos trabalhos distintos. Roger Martin, em Design de Negócios (Campus, 2010), apresenta o Funil do Conhecimento. E relaciona o nível operacional com Algoritmos. Fui com ele.
2. Em The Fractal Organization: Creating sustainable organizations with the Viable System Model (Wiley, 2009).
3. Paul Niven e Ben Lamorte em Objectives and Key Results (Wiley, 2016) e Christina Wodtke em Radical Focus (Boxes & Arrows, 2016), por exemplo.
4. flikr1316 é a imagem de hoje, novamente por Kelbv.

Mas, cuidado: “Quando sugerimos que há uma fronteira entre estratégia e táticas, estamos dispensando as pessoas de usar a cuca.” – Peter Morville, em Intertwingled (2014).

O planejamento das atividades pode ser suportado pelo LogFrame como sugerido no quadro abaixo:O gráfico Gantt deve ter causado arrepios em alguns. É importante dizer que a imagem acima representa apenas uma das diversas opções que temos. Ela é detalhista ao quebrar atividades e tarefas. Pretende ser mais completa ao relacionar as pessoas envolvidas e o papel que cada uma terá. E abre espaço até para um orçamento por atividade/tarefa! Demasiadas minúcias em tempos de não-planejamento (aka XGH)?

O fato é que o LogFrame é bastante flexível. Não atenderia aquele maluco que quer relacionar centenas de atividades a fim de (micro)gerenciá-las. O outro extremo – aquele que acha que não precisa pensar nem dizer como um produto será construído – também não verá utilidade na ferramenta. Todos entre os dois pólos podem se beneficiar do uso do LogFrame. Por quê?

1. Ganham uma Visão do Todo, com uma relação clara e simples entre Fins e Meios;
2. Aumentam o grau de comprometimento ao dar sentido para todo o trabalho a ser executado;
3. Simplificam o processo de planejamento; e
4. Facilitam a implementação e o controle de mudanças e projetos.

LogFrame X Design Idealizado¹

A lista acima foi elaborada por Russell Ackoff para ilustrar os “efeitos do Design Idealizado”. Ao utilizar o LogFrame para suportar o processo tentamos potencializar os efeitos. Como colocado anteriormente nesta série, processo e ferramenta nasceram em berços diferentes. Mas compartilham bases comuns, dentre elas o Pensamento Sistêmico. Não é coincidência o fato deles se completarem.

LogFrame X Scrum

O Scrum parte de uma visão pré-estabelecida. Quem trabalha com ele acaba “inventando” um jeito de construir a Visão. Vêm daí os incríveis sprints 0, -1 e sabe-se lá onde isso vai parar. Ainda é uma experiência, mas parece que LogFrame e Scrum também nasceram um para o outro.Ideal e objetivos fundamentam a Visão de um projeto. Da lista de Produtos derivamos os mapas (roadmaps) e backlogs. A partir da lista de atividades podemos planejar os Sprints. Atenção: não estamos criando mais um artefato. Estamos apenas reforçando o significado original de algumas peças do Scrum. Rastrear a mais singela tarefa até o grande Ideal, passando por produtos e objetivos, é característica inerente ao Scrum. Se o LogFrame e o Design Idealizado apenas forçarem tal lembrança já justificam o seu uso.

LogFrame X OKR

No artigo anterior coloquei que o LogFrame não é pop². O mesmo não pode ser dito de seus possíveis filhotes, particularmente o OKR³ (Objectives and Key Results). Inventado  nos anos 1970 na Intel, a sigla ganhou corações e mentes depois de ser responsabilizada por fazer o LinkedIn valer US$ 20 bilhões, por exemplo. Seria o framework gerencial padrão de empresas do Vale do Silício, dentre elas Google, Zynga e outras.

Um apressado poderia dizer que o OKR é o LogFrame sem pé (atividades) nem cabeça (ideal). Com menos pressa ele entenderia que os objetivos do OKR derivam de declarações de “missão e visão” e que, a partir dos resultados chave esperados (e medidos tal e qual no LogFrame), os responsáveis montam seu plano de… atividades. Podemos concluir que LogFrame e OKR são a mesma coisa? Não, por uma pequena mas significativa diferença.

No OKR você fixa objetivos e resultados trimestrais e anuais. Você começa a jogar com previsões – a brincar com o fogo do monstro do tempo. Tudo o que a gente quer evitar quando adota o Design Idealizado e seu co-irmão LogFrame.O prometido exemplo fica para a próxima semana, ok? Inté!

Notas

1. Passa da hora de decidir por um dos dois nomes do “processo do Ackoff”. Em alguns artigos optei por Processo Interativo. Neste comecei a achar que Design Idealizado é melhor. Design é mais pop, não?
2. E por falar em tornar as coisas pop (como se isso fosse importante). Alguém sugeriu que LogCanvas seria promissor. Blergh!
3. Marc Benioff, do SalesForce.com, também “inventou” um método de planejamento e alinhamento. Atende pelo nome de V2MOM. Talvez por isso não seja tão pop…
4. Pop é o pato que enfeita todos os últimos episódios. Hoje ele está entre o ócio e a negação do ócio (negócio): l? cong?ttur? d? Arl?cch?no . . (?n-b?tw??n ot?um?n?got?um) Imagem de Jef Safi.