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.

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.

O mundo do gerenciamento de projetos trabalha muito “do meio pra baixo” – do tático para o operacional, acusa Schmidt. O recente movimento do PMI na direção da Análise de Negócios e do Desenvolvimento de Requisitos mostra um pé ainda mais atolado na jaca. E quem pensa o todo? Quem cuida da porção estratégica que todo projeto deveria apresentar?

O LogFrame não é (apenas mais) uma ferramenta para planejamento estratégico. Como antecipado no título, ela mira o todo. Também não é um template a ser preenchido, para tristeza dos preguiçosos adoradores de templates. O LogFrame é um modelo que nos ajuda a enxergar e entender planejamento como um sistema de decisões. Ou seja, ele facilita o Pensamento Sistêmico. E talvez esteja nessas duas palavrinhas, Pensamento Sistêmico, a explicação para o fato dele não ser pop. Não deveria ser assim, mas esse tipo de pensamento assusta. E dá uma pre-gui-ça…

Chega de alfinetes. Afinal, o que é o LogFrame? Como, quando e onde ele pode ser utilizado? E qual é a sua relação com o Planejamento Interativo (ou Design Idealizado) de Ackoff? Respostas abaixo.

Quatro Questões Fundamentais

O LogFrame é uma ferramenta que suporta o planejamento e controle de iniciativas de qualquer natureza ou porte. Ele nos ajuda a responder quatro perguntas:

1. O que precisa ser feito e por quê?
2. Como o sucesso será medido?
3. Existem variáveis e condições fora de nosso controle? Quais?
4. Como o trabalho será executado e por quem?

As respostas são organizadas em uma matriz – em um Quadro Lógico² (LogFrame). Ao responder a primeira questão construímos a espinha dorsal do modelo.

Espinha Dorsal: Fins & Meios

Em Planejando Fins foram sugeridos um padrão de nomenclatura e uma hierarquia: Ideal, Objetivos e Metas³. As respostas para a primeira questão formam a primeira coluna da matriz, que além do Ideal e dos Objetivos (Fins) contempla Produtos e Atividades (Meios).A hierarquia força uma leitura lógica – uma relação causal (laços SE… ENTÃO): Se as atividades forem executadas, então obteremos o produto; Se o produto existe, então aumentamos as chances de alcançar os objetivos; E se alcançamos os objetivos, então nos aproximamos do Ideal. Parece simples e óbvio, por isso é tão legal. Mas não se deixe enganar pela aparente simplicidade. Sigamos.

Ideal e Objetivos nos explicam o por quê. Os Produtos mostram o que precisa ser feito. E as Atividades elucidam como será feito. Falaremos mais sobre as atividades em outro momento. Precisamos entender melhor o que foi chamado de Produto.No artigo anterior vimos que existem três tipos de gaps (diferenças entre o real e o Ideal) e seis formas de tratá-los (de ações até programas). Todas entram no que é chamado acima de Produto. O termo original usado por Schmidt é “outcome” (resultado, efeito). Algum relaxado poderia sugerir “entregável” (sic). Ficamos com Produtos, ok?

O que não pode ser medido…

… não pode ser gerenciado, disse o mestre. Ativistas da gestão zen, claro, discordam totalmente. Porque a ditadura das réguas, balanças, balancetes e métricas talvez tenha ido longe demais. Sorte nossa que propostas modernas (mezzo zen tb) têm a medição (contabilidade!) como um de seus pilares. Vide A Startup Enxuta, de Eric Ries (Leya, 2012), por exemplo. No LogFrame, a medição é tão importante que ocupa duas das quatro colunas.

Na primeira fixamos as métricas, as unidades de medida que nos mostrarão a evolução e o sucesso (ou fracasso) na realização de determinado produto, objetivo ou ideal. Schmidt fixa a tríade QQT (Quantidade, Qualidade e Tempo) como unidades padrão. Mas não descarta o uso de outras, como Clientes, Custos, aspectos Socioambientais etc. Importante mesmo é que elas funcionem como evidências, provas não sujeitas a interpretações subjetivas. Para tanto, as métricas devem ser válidas, verificáveis, delimitadas e independentes (entre cada linha – nível da matriz).

Entre os três níveis passíveis de medição (Ideal, Objetivos e Produtos), o mais importante é o segundo. Porque é aquele que indica com precisão que o sucesso foi alcançado. No nível inferior apenas aprendemos que um produto foi entregue. Quanto ao nível Ideal, bem, nunca estamos 100% satisfeitos, estamos?

Em outra coluna descrevemos como as métricas serão verificadas, ou seja, listamos todas as fontes que serão consultadas ou ferramentas (réguas, balanças, logs, balancetes) que serão utilizadas para efetuar medições e confirmar ou não a realização de produtos, objetivos e ideal. Para cada métrica na coluna anterior deve haver uma ou mais formas de verificação, sem exceção. Mesmo que se queira acreditar que o mais importante não pode ser medido. Pode, é só uma questão de boa vontade e criatividade.

Se… E… Então…

SE nossa organização fosse infalível E o mundo fosse perfeito ENTÃO não precisaríamos conversar sobre a quarta e última coluna do LogFrame. Felizmente, não é o caso. Por isso precisamos conversar sobre Suposições, Premissas e Riscos. Hora de responder a terceira questão fundamental: quais cacas ou situações podem nos impedir de realizar o que foi combinado?

Devemos elencar, em cada nível, condições que devem ser verdadeiras para que aquele produto/objetivo/ideal seja plenamente atendido. Mais fácil chamar isso de Premissa. Mais indicado gerenciar isso tudo como Riscos. Porque são variáveis que estão fora de nosso controle. Schmidt recomenda que essa quarta coluna seja vista como uma “membrana permeável” – o que passar dali pode afetar nosso empreendimento.Enfim, a “equação de implementação” traduzida pelo LogFrame está completa. Se as atividades forem executadas E tais premissas forem verdadeiras ENTÃO o produto será entregue; SE o produto for entregue E… assim por diante. Fazendo o zig-zag, de baixo para cima, esclarecemos como pretendemos alcançar nosso ideal.O miolo com métricas e verificações parece oferecer obstáculos para a leitura. É intencional: eterno lembrete para olhar no calendário, subir na balança, fechar o balanço e, sempre que possível, celebrar pequenas (e grandes) vitórias.É uma pena, mas ultrapassei de longe o educado limite de 700 palavras/artigo. Fiquei devendo uma série de respostas e pelo menos um bom exemplo. Não nego – te pago na terça. Inté!

Notas

1. Strategic Project Management Made Simple: Practical Tools for Leaders and Teams – Wiley, 2009.
2. Aline Fróes e Igor Couto me indicaram o livro acima. Estamos experimentando em conjunto o LogFrame. É deles a sugestão do termo “Quadro Lógico” para tropicalizar o nome da ferramenta. Como se não bastasse, me ajudaram neste artigo também. Nem sei como agradecê-los.
3. Não é fácil definir termos e traduções. E é algo crítico, porque compromete o entendimento das sugestões apresentadas. Ackoff coloca no nível mais alto o Ideal e no mais baixo a Meta (Goal). Schmidt mantém a nomenclatura original do LogFrame, que tem a Meta no topo da hierarquia. Fiquei com Ackoff. Aliás, Metas não apareceram no modelo acima. Mas podem aparecer em grandes projetos. Ficariam entre Objetivos e Produtos.
4. Por falar em Produtos… Igor sugeriu o termo Resultados. “Produto de uma atividade”; “Resultado de uma atividade”. Há um melhor? Por quê?
5. l? cong?ttur? d? Arl?cch?no . . (ƒrom s?lƒ to ?go cartography) é o nome da imagem de hoje. Por Jef Safi.

O mundo do gerenciamento de projetos trabalha muito “do meio pra baixo” – do tático para o operacional, acusa Schmidt. O recente movimento do PMI na direção da Análise de Negócios e do Desenvolvimento de Requisitos mostra um pé ainda mais atolado na jaca. E quem pensa o todo? Quem cuida da porção estratégica que todo projeto deveria apresentar?

O LogFrame não é (apenas mais) uma ferramenta para planejamento estratégico. Como antecipado no título, ela mira o todo. Também não é um template a ser preenchido, para tristeza dos preguiçosos adoradores de templates. O LogFrame é um modelo que nos ajuda a enxergar e entender planejamento como um sistema de decisões. Ou seja, ele facilita o Pensamento Sistêmico. E talvez esteja nessas duas palavrinhas, Pensamento Sistêmico, a explicação para o fato dele não ser pop. Não deveria ser assim, mas esse tipo de pensamento assusta. E dá uma pre-gui-ça…

Chega de alfinetes. Afinal, o que é o LogFrame? Como, quando e onde ele pode ser utilizado? E qual é a sua relação com o Planejamento Interativo (ou Design Idealizado) de Ackoff? Respostas abaixo.

Quatro Questões Fundamentais

O LogFrame é uma ferramenta que suporta o planejamento e controle de iniciativas de qualquer natureza ou porte. Ele nos ajuda a responder quatro perguntas:

1. O que precisa ser feito e por quê?
2. Como o sucesso será medido?
3. Existem variáveis e condições fora de nosso controle? Quais?
4. Como o trabalho será executado e por quem?

As respostas são organizadas em uma matriz – em um Quadro Lógico² (LogFrame). Ao responder a primeira questão construímos a espinha dorsal do modelo.

Espinha Dorsal: Fins & Meios

Em Planejando Fins foram sugeridos um padrão de nomenclatura e uma hierarquia: Ideal, Objetivos e Metas³. As respostas para a primeira questão formam a primeira coluna da matriz, que além do Ideal e dos Objetivos (Fins) contempla Produtos e Atividades (Meios).A hierarquia força uma leitura lógica – uma relação causal (laços SE… ENTÃO): Se as atividades forem executadas, então obteremos o produto; Se o produto existe, então aumentamos as chances de alcançar os objetivos; E se alcançamos os objetivos, então nos aproximamos do Ideal. Parece simples e óbvio, por isso é tão legal. Mas não se deixe enganar pela aparente simplicidade. Sigamos.

Ideal e Objetivos nos explicam o por quê. Os Produtos mostram o que precisa ser feito. E as Atividades elucidam como será feito. Falaremos mais sobre as atividades em outro momento. Precisamos entender melhor o que foi chamado de Produto.No artigo anterior vimos que existem três tipos de gaps (diferenças entre o real e o Ideal) e seis formas de tratá-los (de ações até programas). Todas entram no que é chamado acima de Produto. O termo original usado por Schmidt é “outcome” (resultado, efeito). Algum relaxado poderia sugerir “entregável” (sic). Ficamos com Produtos, ok?

O que não pode ser medido…

… não pode ser gerenciado, disse o mestre. Ativistas da gestão zen, claro, discordam totalmente. Porque a ditadura das réguas, balanças, balancetes e métricas talvez tenha ido longe demais. Sorte nossa que propostas modernas (mezzo zen tb) têm a medição (contabilidade!) como um de seus pilares. Vide A Startup Enxuta, de Eric Ries (Leya, 2012), por exemplo. No LogFrame, a medição é tão importante que ocupa duas das quatro colunas.

Na primeira fixamos as métricas, as unidades de medida que nos mostrarão a evolução e o sucesso (ou fracasso) na realização de determinado produto, objetivo ou ideal. Schmidt fixa a tríade QQT (Quantidade, Qualidade e Tempo) como unidades padrão. Mas não descarta o uso de outras, como Clientes, Custos, aspectos Socioambientais etc. Importante mesmo é que elas funcionem como evidências, provas não sujeitas a interpretações subjetivas. Para tanto, as métricas devem ser válidas, verificáveis, delimitadas e independentes (entre cada linha – nível da matriz).

Entre os três níveis passíveis de medição (Ideal, Objetivos e Produtos), o mais importante é o segundo. Porque é aquele que indica com precisão que o sucesso foi alcançado. No nível inferior apenas aprendemos que um produto foi entregue. Quanto ao nível Ideal, bem, nunca estamos 100% satisfeitos, estamos?

Em outra coluna descrevemos como as métricas serão verificadas, ou seja, listamos todas as fontes que serão consultadas ou ferramentas (réguas, balanças, logs, balancetes) que serão utilizadas para efetuar medições e confirmar ou não a realização de produtos, objetivos e ideal. Para cada métrica na coluna anterior deve haver uma ou mais formas de verificação, sem exceção. Mesmo que se queira acreditar que o mais importante não pode ser medido. Pode, é só uma questão de boa vontade e criatividade.

Se… E… Então…

SE nossa organização fosse infalível E o mundo fosse perfeito ENTÃO não precisaríamos conversar sobre a quarta e última coluna do LogFrame. Felizmente, não é o caso. Por isso precisamos conversar sobre Suposições, Premissas e Riscos. Hora de responder a terceira questão fundamental: quais cacas ou situações podem nos impedir de realizar o que foi combinado?

Devemos elencar, em cada nível, condições que devem ser verdadeiras para que aquele produto/objetivo/ideal seja plenamente atendido. Mais fácil chamar isso de Premissa. Mais indicado gerenciar isso tudo como Riscos. Porque são variáveis que estão fora de nosso controle. Schmidt recomenda que essa quarta coluna seja vista como uma “membrana permeável” – o que passar dali pode afetar nosso empreendimento.Enfim, a “equação de implementação” traduzida pelo LogFrame está completa. Se as atividades forem executadas E tais premissas forem verdadeiras ENTÃO o produto será entregue; SE o produto for entregue E… assim por diante. Fazendo o zig-zag, de baixo para cima, esclarecemos como pretendemos alcançar nosso ideal.O miolo com métricas e verificações parece oferecer obstáculos para a leitura. É intencional: eterno lembrete para olhar no calendário, subir na balança, fechar o balanço e, sempre que possível, celebrar pequenas (e grandes) vitórias.É uma pena, mas ultrapassei de longe o educado limite de 700 palavras/artigo. Fiquei devendo uma série de respostas e pelo menos um bom exemplo. Não nego – te pago na terça. Inté!

Notas

1. Strategic Project Management Made Simple: Practical Tools for Leaders and Teams – Wiley, 2009.
2. Aline Fróes e Igor Couto me indicaram o livro acima. Estamos experimentando em conjunto o LogFrame. É deles a sugestão do termo “Quadro Lógico” para tropicalizar o nome da ferramenta. Como se não bastasse, me ajudaram neste artigo também. Nem sei como agradecê-los.
3. Não é fácil definir termos e traduções. E é algo crítico, porque compromete o entendimento das sugestões apresentadas. Ackoff coloca no nível mais alto o Ideal e no mais baixo a Meta (Goal). Schmidt mantém a nomenclatura original do LogFrame, que tem a Meta no topo da hierarquia. Fiquei com Ackoff. Aliás, Metas não apareceram no modelo acima. Mas podem aparecer em grandes projetos. Ficariam entre Objetivos e Produtos.
4. Por falar em Produtos… Igor sugeriu o termo Resultados. “Produto de uma atividade”; “Resultado de uma atividade”. Há um melhor? Por quê?
5. l? cong?ttur? d? Arl?cch?no . . (ƒrom s?lƒ to ?go cartography) é o nome da imagem de hoje. Por Jef Safi.