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

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

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

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

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

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

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

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

Autonomia X Alinhamento

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

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

Há Partituras

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

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

Os “Novos Modelos”

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

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

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

Notas

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

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

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

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

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

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

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

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

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

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

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

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

Autonomia X Alinhamento

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

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

Há Partituras

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

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

Os “Novos Modelos”

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

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

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

Notas

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

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

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

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

Com.ple.xi.da.de (s.f.)

Qualidade do que é complexo. (Michaelis)

Com.ple.xo adj. 1. que se compõe de elementos diversos relacionados entre si  s.m. 2. conjunto, aglomerado 3. psic. conjunto de sentimentos de forte valor emocional que se refletem na personalidade de uma pessoa ~ complexidade s.f. (Houaiss)

Neil Johnson mostra que dicionários em língua inglesa também confundem quando tentam explicar a complexidade¹. A definem como o  comportamento de um sistema complexo. Este, por sua vez, é descrito como sendo  um sistema cujo comportamento exibe complexidade. Santa recursividade escorregadia!Complexo vem do latim, plectere. Significa trança ou entrelaçar. Uma trama não muito regular, repleta de nós, é uma imagem recorrente quando ilustramos a complexidade. As explicações acima são suficientes? Não. É curioso, mas ainda não temos uma boa definição para a complexidade.  

Complexidade é um adjetivo e uma unidade de medida. Subjetiva e desconcertante medida. O que medimos? O grau de ordem ou desordem demonstrado por determinado sistema. Ou sua previsibilidade. Ou o número de conexões. Ou a diversidade de elementos. Cada modelo proposto enfatiza uma característica. Todos acertam. Mas todos estão incompletos.

O Cynefin² fixa duas dimensões: a existência ou força de um controle central e o grau de conectividade entre os componentes. Jurgen Appelo³ prefere falar de estrutura e comportamento, sendo que apenas este pode ser complexo.
(Mais sobre eles em futuros artigos)

Bola de Neve

A complexidade aumenta na medida em que mais pessoas e coisas são conectadas. Nossas redes sociais ainda acomodarão outros bilhões de pessoas. A Internet das Coisas (IoT) vem aí para interligar tudo quanto é tipo de objeto. Cada pessoa manterá ligações com centenas de coisas. Tempo verbal mal colocado…

Todo santo dia a rede ganha um sem número de novos nós. Nós pronome e nó substantivo. Entender a complexidade que só faz crescer não é luxo ou necessidade futura. É pra ontem!

Ciência

O estudo da complexidade é “a ciência das ciências”, uma disciplina guarda-chuva¹. Não é apenas interdisciplinar ou multidisciplinar. O salto pelos silos, caixas e vícios das ciências tradicionais exige uma postura meio indisciplinada mesmo.

E não importa muito que não tenhamos (ainda) uma boa definição e uma teoria abrangente da complexidade. Não é difícil identificar um sistema complexo, como veremos no próximo artigo. E para uma requerida postura prática e pragmática, é isso o que interessa. Por enquanto. Inté!

Notas

1. Simply Complexity – A Clear Guide to Complexity Theory
   Neil Johnson (OneWorld, 2009)
2. The New Dynamics of Strategy: Sense-Making in a Complex and Complicated World
   Cynthia F. Kurtz & David J. Snowden (IBM Journal of Research and Development – n. 3, 2003)
3. Management 3.0
   Jurgen Appelo (Addison-Wesley, 2011)
4. O título não vem da esfinge. Foi surrupiado de Clarice Lispector:
   “Decifra-me, mas não me conclua, eu posso te surpreender.“
5. Dandelion with Waterdrops 2
   Foto da tanakawho, que andava meio sumida daqui.

Todo evento muito longo – este durou cerca de oito horas, contando os intervalos – é cansativo. Se houvesse uma variação de formatos e maior participação da plateia talvez não fosse uma experiência tão extenuante. Confesso que abandonei o barco depois das 18h30 – depois de seis horas e meia de palestras. Algumas foram bem curtas, duraram cerca de cinco minutos. Outras, as melhores, tiveram cerca de vinte minutos de duração. A diversidade de temas ajudou a prender a atenção.

O que não significa que não tenha havido redundâncias. A ideia de que o gerenciamento tal qual é conhecido hoje está obsoleto foi recorrente. Começou com Jaap Peters, que foi lá na raiz: citou The Principles of Scientific Management de Frederick Taylor. Está neste trabalho uma colocação que de certa forma sintetiza TUDO o que se entende sobre negócios e gerenciamento (e a vida…) desde o início do século 20: “No passado, o homem foi o primeiro. No futuro, o sistema será o primeiro.”

Gerenciamento *1911 †1970 -Niels PflaegingQuando você vê uma ênfase doentia em planejamento e processos está assistindo a realização da profecia de Taylor. Planos e processos são arquitetados para que alguém seja dispensado de utilizar a única coisa que o diferencia de um ornitorrinco: o cérebro. Ok, o ornitorrinco é um bicho diferentão. Mas você entendeu meu ponto. O que há de nefasto e hoje facilmente condenável na proposição de Taylor¹ e contemporâneos é a separação entre o pensar e o fazer, como destacou Niels Pflaeging em sua fala. Aliás, o título da palestra de Niels é uma provocação por si só: O Gerenciamento é Dispensável.

Quem acha que essa ideia só faz sentido em organizações com maduros trabalhadores do conhecimento precisa urgentemente conhecer O Que Importa Agora, de Gary Hamel (Campus, 2012). Aliás, Hamel foi a cereja que faltou ao bolo do Stoos Connect.

Daniel Pink, autor de O Cérebro do Futuro (Campus, 2007) dentre outros, reforçou a mensagem sobre gerenciamento com outras palavras. Gerenciamento é uma tecnologia. Como toda tecnologia, ele ficou obsoleto. Seria urgente, portanto, um “recall” das organizações.

Possíveis executores deste “recall” foram convidados – via Skype – por Peter Vander Auwera. Ele apresentou um grupo chamado Corporate Rebels United. Vale a pena dar uma olhada no manifesto.

Rolaram palestras com temas mais específicos, como Vendas Nobres (não seria um oxímoro?), por Lisa Earle McLeod e Cultura Corporativa (três erros comuns que as empresas cometem) por Dawna Jones. Dawna fez uma colocação que merecia mais tempo e melhores explicações: “Podemos utilizar os mesmos princípios da natureza para guiar um sistema-negócio”. Quais princípios? Todos? Tá falando sério?

Jurgen Appelo, autor de Management 3.0, não surpreendeu. Entrando na terceira parte do evento, não choveu no molhado. Optou por um tema bem específico: motivação e remuneração. Jurgen oferece um necessário contraponto à ideia de que a motivação intrínseca (de um trabalhador) bastaria: “Todos temos contas para pagar no final do mês”. Grana é importante. Bônus são importantes. E podem funcionar sim como motivadores. Mas é preciso saber fazer. Jurgen propõe um mecanismo simples, transparente e com bastante potencial. “Merit Money“, um artigo sobre o tema, será disponibilizado em breve.

Perdi a apresentação do Steve Denning, mas ele publicou um generoso resumo aqui.

Em suma, foi um evento legal. Eu esperava algo mais interativo e variado – não uma sequência muito longa e cansativa de palestras. Como o “diagnóstico” (do estado atual das coisas) é bem conhecido e a concordância com ele é o que leva uma pessoa para um evento desse tipo, era de se esperar mais propostas, mais ideias novas. Mas valeu a pena – valeu uma tarde de sexta.

Para quem ficou curioso, creio que as palestras logo serão disponibilizadas via Youtube ou algo assim. Você pode ter notícias através do site do evento ou no grupo no LinkedIn.

Notas

1. Niels Pflaeging colocou que Taylor é herói e anti-herói do gerenciamento. No geral, Taylor tem sido apresentado como o grande culpado pelo estado atual das coisas no mundo dos negócios. É merecido? Por profecias como aquela citada neste artigo, poderia ser. Sinceramente, acho sua contribuição – seja para o bem ou para o mal – um tanto exagerada. Tamanho caos não pode ser produto do trabalho de apenas uma pessoa.

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 maneira⁴:

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órmula⁵?

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…

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í?

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.

O gerente é uma invenção da era industrial, um mal necessitado pelos verdadeiros donos de negócios que precisavam ganhar escala. Deveriam funcionar como clones parciais e especialistas do manda-chuvas. Um especialista em vendas, outro em finanças e assim por diante. Os gerentes ocupam a camada intermediária de uma organização, entre o topo e os peões. Na teoria, e quase só na teoria, eles defenderiam o ponto de vista tático. Ou seja, trabalhariam com um horizonte de médio prazo. Quem está acima deles enxergaria mais longe. Quem está na base cuida do dia a dia, provavelmente sob os auspícios e chicotes de um supervisor ou líder técnico – um outro nível de gerente que vive a mirar o andar de cima com desejos inconfessáveis.

A necessidade de uma organização hierárquica criou na marra uma separação que não fazia sentido no século 18 assim como parece não fazer no século 21. Cérebro e mãos foram apartados artificialmente. Tanto que Henry Ford vivia reclamando que “quando contratava duas mãos, o cérebro vinha junto”. À base de pirâmide não era permitido pensar. Seus ocupantes deveriam apertar porcas e deixar todo o trampo intelectual para quem estivesse acima. E assim a posição do cérebro – do gerente – mesmo que limitada, virou objeto de desejo de todos que tivessem um mínimo de ambição. Não era só o maior salário. Era sobretudo o status, o inequívoco sinal de ascensão social.

Muita demanda, ofertas teoricamente limitadas. Neste jogo político, assim como em governos com inflada base de apoio, inventam-se cadeiras e postos. E o meio da pirâmide inchou para todos os lados. Na linha do tempo estamos entre os anos 1950 e 1980 (lá fora) ou 2000 (aqui no Brasil). Pois é, tem duas ou três décadas que olhamos para este meio de campo e perguntamos: precisamos de tantos gerentes assim? Aqueles que já passaram da página três têm outra questão: precisamos mesmo de gerentes?

G de Gerente, G de Gargalo

Se os proponentes dos métodos ágeis adoram falar que gerentes não são mais necessários, não deve surpreender a ninguém o fato deles – os gerentes –  serem tão pouco receptivos à ideia. Com outras palavras, é isso que diz Jurgen Appelo em Management 3.0, publicado em 2011. Desconfio que também sejam eles, os gerentes, os responsáveis pelo bloqueio do principal requisito das iniciativas BPM: a organização por processos. Não por ação, mas por omissão. Afinal, como aceitar e trabalhar por um modelo que não dê uma atribuição minimamente respeitável para os gerentes? Como acatar uma sugestão que, em sua origem, significou a extinção de diversas cadeiras de gerentes?

Que sejam sabotadas, sutilmente, as propostas de mudanças nada sutis. E provemos nosso valor mergulhando, com todo o tempo e saúde de que dispomos, nas questões do dia a dia. Pagamos para ver quem sabe mais do que a gente. Queremos ver quem nos tira daqui.

Não espere que um gerente confesse o parágrafo anterior. E não caia na armadilha da generalização. Os gerentes não são ruins por natureza. Mas estão, neste ponto da história, defendendo sua sobrevivência. Nada mais natural. Nada mais humano.

Mas, e daí? Devemos aceitar que os gerentes, assim como várias outras invenções do século XX, devem ser riscados do mapa? Eles são de fato supérfluos nos tempos da economia do conhecimento e do autogerenciamento?

G de Gratificante

Peter Drucker, ao tratar a organização por processos, sugeriu que os departamentos funcionais seguiriam existindo. Não mais com responsabilidades sobre as funções executadas, mas como formadores e provedores de especialistas. Tom DeMarco e Thimoty Lister, em Peopleware, cruzaram caminho semelhante: “o centro de aprendizagem mais natural para a maioria das organizações reside naquela mal falada instituição, na camada intermediária. Isso bate com nossa observação de que as mais bem sucedidas organizações que aprendem possuem um forte time de gerenciamento”.

Os gerentes não cuidariam apenas de ensinar, mas principalmente de montar e manter um ambiente onde o aprendizado acontece. Será que basta? Claro que não, como demonstra Henry Mintzberg em Managing – Desvendando o Dia a Dia da Gestão (Bookman, 2010). Seu modelo de gestão, ilustrado ao lado, sugere a existência de três planos e duas atividades principais vinculadas a cada um deles: Plano das Informações (comunicar e controlar), Plano das Pessoas (liderar e fazer conexões) e o Plano das Ações (executar e negociar). Repare também que o modelo indica três zonas de atuação: dentro da unidade de negócio, com o resto da organização e fora da organização.

Não é curioso como Mintzberg parece ignorar ou desconsiderar as sugestões anteriores, de ensinar e prover um ambiente que estimule a aprendizagem? Me arrisco a sugerir a existência de um quarto plano, central, o Plano da Aprendizagem Organizacional. Que também teria duas atividades principais (promover e difundir) e três dimensões (a unidade, a organização e o lado de fora da organização). Creio que este quarto plano responderia as críticas apresentadas por Jurgen Appelo em seu livro (sobre a falta de preocupação, no modelo de Mintzberg, com o Desenvolvimento de Competências e a Melhoria Contínua).

Não se engane, o modelo seguiria errado. Assim como é equivocada (e simpática) a Martie – monstrinho que representa o modelo Management 3.0 sugerido por Appelo. Porque, como confessa seu próprio criador: “todos os modelos estão errados. Mas alguns são úteis”. O bom gerente desconfia disso. O excelente tem certeza, por isso estuda todos os modelos e tenta colocá-los em prática. Não apenas em busca de paz de espírito e disponibilidade para seus filhos, mas porque ele sabe que seu principal trabalho é fazer com que outras pessoas trabalhem e evoluam. Sua responsabilidade é imensa. Por isso o papel do gerente pode ser tão gratificante.

Nada disso fará com que seus filhinhos manifestem a vontade de ser gerentes quando crescerem. Não importa. Eles também nunca dizem que serão otorrinolaringologistas.

Na resposta onde prometi este artigo eu conclui que “TI já acabou”. E que já faz um tempão! Claro, não estou falando da Tecnologia da Informação de maneira geral, e sim dos departamentos de TI nas empresas que têm outros fins. Saca só esta breve cronologia de matérias de capa de algumas publicações tupiniquins:

• EXAME, 20/fev/2002: Tecnologia – Como Matar o Desperdício
• Info Corporate, Jul-Ago/2003: O CEO não manja de Tecnologia?
  Como convencê-lo de que TI é essencial para o negócio
• Info Corporate, Nov-Dez/2003: CIOs X Usuários: o que precisa mudar nessa histórica rixa
• EXAME, 4/fev/2004: Tecnologia da Informação – Dá para se livrar dela?
• Info Corporate, Set/2004: É o fim da TI como a conhecemos
  A área de tecnologia vai mudar para sobreviver. Como fica o CIO?
• Info Corporate, Mai/2005: A tecnologia perdeu poder?
  Só 20% dos CIOs brasileiros se reportam ao presidente. O que isso significa?

A Info Corporate não existe mais – e já foi tarde. A EXAME, quando fala de tecnologia, tem dois assuntos:  gadgets da moda e “bilionários” fenomenais, não necessariamente nesta ordem. Não devo ser o único que sente saudades dos artigos do Helio Gurovitz. Mas o que quero ilustrar é que… desistiram. Falar que TI não funciona – não entrega, deixou de ser novidade. Deixou de vender revistas, se é que um dia o fez. E, pelo visto, deixou de motivar soluções milagrosas. Faz tempo que não aparece uma sigla de três letras prometendo mais que político em período eleitoral, não?

Lembrado pelo amigo Igor Couto, mostro ao lado a explicação do Jurgen Appelo para o estado atual das coisas. Seu alvo é o desenvolvedor de software, mas o modelo serve como uma luva para explicar como e porque os departamentos de TI chegaram onde estão.

Perdão, mas vou resumir: falta de disciplina e de competência detonam a qualidade e a produtividade. Baixas qualidade e produtividade deixam clientes e usuários muito insatisfeitos, P’s da vida mesmo. O que aumenta a pressão que eles exercem sobre TI. Uma pressão que só faz erodir a motivação e, consequentemente¹, a produtividade.

Assim, de tanto não entregar ou entregar soluções de péssima qualidade, TI perdeu o direito de dizer NÃO. Onde deveria haver motivação há medo, puro medo. Ciclo montado, circos incendiados diariamente em organizações dos mais diversos portes e ramos de atividades.

Perdemos muito tempo correndo atrás de extintores e mangueiras. E, preciso dizer, a contratação de analistas de negócios foi só o uso de um extintor diferente. Ferramenta inútil em incêndios de grandes proporções.

O CLD (Diagrama de Ciclos Causais) do Jurgen sugere três soluções de amplo espectro: Educação e, a partir dela, Competência e Disciplina. Nunca foi segredo para ninguém que qualidade e produtividade dependem desses fatores. Acontece que Educação é investimento de longo prazo. Pronto, consegui colocar em uma frase com oito palavras três termos aparentemente incompatíveis com muitas organizações de TI: Educação, Investimento e Longo Prazo.

Se Tudo tem que Terminar Assim

Que pelo menos seja até o fim, diz a letra do Herbert². As letras do Gartner e do McKinsey, traduzidas na Info Corporate de setembro de 2004, não alimentavam nenhuma esperança:

• O departamento de informática como o conhecemos desaparecerá;
• Algumas áreas de TI, como infraestrutura, vão mesmo virar commodities e serão inevitavelmente terceirizadas;
• A TI deixará de ser uma área de suporte aos usuários para ser absorvida pelas próprias unidades de negócio;
• Não haverá mais espaço para o profissional eminentemente técnico. Quem quiser trilhar carreira técnica deverá trabalhar num fornecedor de tecnologia;
• Nesse cenário, o CIO tem dois caminhos a seguir: ou se torna um executivo de processos de negócios ou continua a gerenciar ativos de TI, tornando-se, assim, um ser em extinção.

Dramática lista, não? Dramática, um tanto equivocada e, como este artigo até aqui, pouco construtiva. Não sei se tenho respostas (construtivas), mas meu balaio tá repleto de palpites:

• A Nuvem não curará aplicações bugadas e mal integradas. Acima de uma inchada camada de commodities residem dados e sistemas que pedem, há tempos, por drásticas revisões. A mesma metralhadora do Gartner já havia sugerido, no final do século passado, uma interessante solução: aposente algo entre 3 e 5 sistemas legados por ano. O remédio pode ser amargo e caro, mas parece ser a única alternativa.
• Serviços de manutenção de hardware, impressão, suporte ao uso de equipamentos e outros que não lidem nem dependam de conhecimentos do negócio já deveriam estar terceirizados desde mil novecentos e pedrinha. A Nuvem, se bem utilizada, pode tirar outros pesos das costas de TI. Desde que tal movimento não comprometa ainda mais os níveis de serviços atuais.
• Cogitar que áreas de negócios assumam responsabilidades sobre a administração de TI é ingenuidade que ignora três fatores: i) as soluções que realmente interessam ao negócio suportam processos, não departamentos. A pulverização sugerida só faria aumentar o caos instalado, nada mais; ii) Pouquíssimas organizações possuem uma arquitetura de negócios que não dependa de um mínimo nível de integração e padronização; e iii) unidades de negócio têm suas responsabilidades bem determinadas. Não sei de nenhuma que faça sua própria contabilidade ou limpeza ou folha de pagamentos. Por que assumiriam a gestão de TI?
• Aquele papo de CIO virando “executivo de processos” era conversa para BOI dormir. Bad trip provocada pela onda BPM que então surgia, nada mais.

Pois é, TI acabou. Mas, como disse Voltaire em outro contexto, precisaremos (re)inventá-la. Exercício para a próxima semana: se você pudesse desenhar um departamento de TI do zero, como ele seria?

Notas

1. Descrever diagramas já é um atentado contra a inteligência. Escrever “consequentemente” na descrição de um CLD deve resultar em uns 100 anos de cadeia e solidão, mais ou menos. Perdão!
2. “Caleidoscópio”, composição de Herbert Vianna gravada pelos Paralamas numa época em que existiam o Rock Nacional e os departamentos de TI.

Arquitetura¹: concebida com o propósito primordial de organizar espaço para determinada finalidade e visando a determinada intenção.

Este artigo é uma modesta provocação. E uma tentativa de transcrever a palestra “Arquitetura do Negócio: Enxuta & Ágil” que apresentei no último Agile Vale. É que alguns assuntos pedem para ser espalhados. Se você se interessa por arquitetura corporativa, arquitetura de negócios, arquitetura de software, DDD, DSL, métodos ágeis e pensamento enxuto (lean), talvez encontre algo de útil no meio deste longo texto.

?

Peço sua atenção para a definição de arquitetura acima. Particularmente para os termos espaço, finalidade e intenção. Quando arquitetamos algo, nós “organizamos um espaço para determinada finalidade visando a determinada intenção”. Preciso voltar também para um conceito que já apresentei aqui no {finito}, a Tríade Vitruviana. Ela fixa três critérios fundamentais para avaliação de uma arquitetura:

• Firmitas: a construção é estável, robusta e sustentável;
• Utilitas: a arquitetura é funcional; e
• Venustas: é bela.

A área de TI gosta de adotar termos de outras áreas de conhecimento. Seria legal se, além dos nomes, adotássemos também os conceitos básicos. Já tem um tempinho que acolhemos o termo “arquitetura”. Recentemente, passamos a falar bastante sobre Arquitetura Corporativa. Acho que indicamos que através dela “organizamos espaço para determinada finalidade e visando a determinada intenção”. Qual espaço?

TI organiza dois espaços, a saber: i) Arquitetura Tecnológica – hardware, infraestrutura de rede e software básico. Significa o que a organização possui; ii) Arquitetura de Informações – bases de dados e repositórios de informações não estruturadas. Indica o que a organização sabe. Esses espaços são organizados “para determinada finalidade”. Qual finalidade?

TI atende a ou oferece um sem número de finalidades, de funcionalidades. O faz através de sua Arquitetura de Sistemas, que representa todas as aplicações, ou seja, o que a organização faz. E faz esse tanto de coisa porque está “visando a determinada intenção”. Que intenção?

Chegamos naquela parte da tal Arquitetura Corporativa que justifica tudo, inclusive a própria existência de TI. É a Arquitetura do Negócio, aquela que explica a intenção – para quem e porque a organização faz (oferece sistemas), sabe (informações) e possui (aquele tanto de ferro e software básico). No longínquo mundo ideal, não deveria haver um único centavo gasto em qualquer das três camadas inferiores que não fosse rastreável até a arquitetura do negócio, comprovando um benefício real e mensurável. Sendo assim, é factível supor que tudo começa (e deveria terminar) aqui, na Arquitetura do Negócio. Do que ela consiste?

Todo e qualquer negócio, independente do porte ou ramo de atividade, é formado por quatro elementos básicos: Objetivos, Recursos, Processos e Regras. Mas estamos falando de Arquitetura do Negócio, o que nos leva novamente para a preocupação de “organizar espaço para determinada finalidade visando a determinada intenção”. O espaço que organizamos é a estrutura da empresa – as pessoas, instalações, móveis, veículos, enfim, todos os seus recursos². A finalidade é representada por todo o seu conjunto de processos, por toda a sua parte dinâmica. Finalmente, a intenção é o grupo de objetivos da organização. Colocando de outra maneira: organizamos os recursos (espaço) de uma empresa de forma que os permita executar ou viabilizar a execução de processos (finalidade) visando a alcançar determinados objetivos (intenção).

Ao representar a arquitetura de um negócio, mesmo sem querer, sempre utilizamos três visões ou combinações entre elas. A visão do negócio trata dos objetivos, da intenção. A visão da estrutura nos mostra os recursos, o espaço. E a visão dos processos nos dá a finalidade. As representações podem ser ultrasofisticadas ou de uma simplicidade risível. Não é minha intenção debatê-las aqui, agora. Mas, para fins ilustrativos, entenda que um organograma é parte da visão da estrutura, enquanto um fluxograma pode compor a visão dos processos. Balanced Scorecards ou simples listas de objetivos representam a visão do negócio. O que nos interessa neste ponto é a “organização do espaço para determinada finalidade visando a determinada intenção”. Hora de agitar o coreto.

Muito falamos sobre a dinâmica, a velocidade das mudanças, e a complexidade do atual mundo dos negócios. O que muda tanto? E o que é complexo? Será que tudo?

Jurgen Appelo, no livro “Management 3.0” e falando sobre a teoria da complexidade, sugere um modelo para estudos: o modelo da Estrutura-Comportamento³. Ele escreveu que nos equivocamos quando intercambiamos os termos “complexo” e “complicado”. E afirma que o que é complexo não é passível de simplificação. Me esforçarei para deixar o papo menos maluco (e menos abstrato).

Quando tratamos de uma estrutura, o que está em jogo é nossa habilidade para entendê-la. Portanto, uma estrutura pode ser simples ou complicada. Neste sentido um casamento, por exemplo, é uma estrutura simples. Ele envolve, na teoria e em seu início, apenas dois elementos. Por outro lado, uma empresa ou uma cidade possuem uma estrutura complicada – difícil de entender.

Em outra dimensão está o comportamento e o que é exigida é nossa capacidade de prevê-lo. Um relógio, por complicado que seja (em sua estrutura), tem comportamento bastante previsível. Dizemos que seu comportamento é ordenado. Diferente do casamento, que apesar da estrutura simples, pode resultar em comportamentos bastante complexos. Nesta dimensão temos ainda uma terceira “ordem de grandeza”, o caos. O trânsito de nossas grandes cidades, por exemplo, tem comportamento caótico – ele é praticamente imprevisível. E, só para fechar o exemplo, a estrutura destinada para esse mesmo trânsito não tem nada de simples. Ela é complicada. Uma estrutura é passível de simplificação. Já o comportamento, com certa dose de boa-fé, poderia ser linearizado (o que é complexo ou caótico poderia ser ordenado).

Coreto devidamente agitado? E o que esse papo sobre complexidade tem a ver com arquitetura? Tudo!

A “estrutura” do papo acima é o espaço que organizamos. Voltando para a arquitetura do negócio, trata-se exatamente da visão da estrutura, de todos os recursos utilizados por uma organização. E a dimensão do comportamento representa a finalidade da arquitetura, as ações que ali devem ocorrer. No domínio (!) do negócio, refere-se à visão dos processos.

Um negócio, qualquer negócio, é um Sistema Adaptativo Complexo. O modelo proposto por Appelo nos ajuda a estudá-lo. Sistemas de informação são igualmente adaptativos e complexos. O modelo “Estrutura – Comportamento” nos ajudaria a arquitetá-los? No mínimo, como tentarei mostrar abaixo, justificaria uma “nova” maneira de pensar.

Quando falamos, geralmente reclamando, sobre a dinâmica dos negócios, devemos entender que o grande volume de mudanças ocorre na dimensão comportamental, ou seja, nos processos. Posso apelar para Pareto? Então vamos fixar que 80% das “mudanças organizacionais” (sic) referem-se às alterações na forma de trabalhar, nos processos de negócios. O restante significa, de fato, alteração na estrutura (demissões, remanejamentos, fusões & aquisições etc).

Acima eu escrevi que também vivemos reclamando da complexidade dos negócios. Novamente o modelo proposto pelo Appelo nos ajuda a separar o joio (estrutura, no máximo complicada) do trigo (processos, de fato complexos ou até mesmo caóticos). Fiquei com vontade de usar outra metáfora.

Ao desenhar sua casa, você separou generoso espaço (!) para montar seu sonhado home office (finalidade!). Mobiliou-o com tudo de bom e do melhor e ficou realmente mais produtivo (intenção!) naquela zona (no bom sentido) de conforto (no melhor sentido possível). Mas eis que vem a notícia de um filhinho não planejado e lá se vai o querido escritório de volta para a garagem. Aquele generoso espaço ganhará nova finalidade. Ele mudou? A menos que você tenha derrubado paredes e redimensionado outros cômodos, você não mexeu no espaço – na estrutura da casa. Foi só a finalidade daquele espaço que mudou.

Uma estrutura, mesmo quando mal e porcamente concebida, é mais estável que o comportamento. Ou, colocando de outra forma, a estrutura é menos instável que os processos. Então, por que será que nossos sistemas de informação raramente refletem essa separação? Até que ponto nossa indisciplinada mistura de forma (espaço) e funcionalidade (finalidade) é responsável pelos altíssimos custos de manutenção e pela dificuldade de adaptação dos sistemas ditos “legados”? Prometo parar por aqui com as questões retóricas. O que vem a seguir é uma proposta para pensar arquitetura de sistemas de uma maneira diferente.

Arquitetura Enxuta & Ágil

Se não ficou claro, apesar (ou exatamente por causa) de minha verborragia, nosso objetivo é fazer com que um sistema reflita e respeite a separação entre estrutura e comportamento. Vamos diferenciar o que o sistema é do que o sistema faz.

Já tem um tempinho que utilizamos classes para representar coisas do mundo real. Apesar de chamarmos isso de “Orientação a Objetos”, o fato é que nossa programação é mesmo orientada a classes. Não importa. Aprendemos nas escolas da vida que um objeto deveria encapsular sua estrutura (atributos) e comportamento (métodos). Temos outro probleminha aqui. Se desejamos representar elementos da estrutura do negócio, então deveríamos esquecer todo esse papo de encapsular comportamento. Essas classes e respectivos objetos que definem o que o sistema é devem ser ignorantes em relação a tudo o que se refira a ação. Quando muito, sabem um CRUDzinho básico. O cliente Mané, por exemplo, não sabe o que é comprar livro ou colocar livro no carrinho de compras. O Mané não sabe nada! Mas pode aprender!!

Todas as ações, serviços ou funcionalidades, compõem o que o sistema faz. No diagrama ao lado, todas essas interAÇÕES são representadas por papéis (roles). Existem dois tipos: aqueles que sabem o que fazer (methodful roles) e aqueles que só fingem que sabem (methodless roles). A distinção entre os papéis que sabem (methodful) daqueles que fingem saber (methodless) é muito importante. Os últimos funcionam apenas como interfaces. E nós esperamos que as interfaces sofram bem menos alterações do que os métodos propriamente ditos. Novamente a intenção é separar nitidamente aquilo que muda com mais frequência daquilo que pouco se altera no decorrer do tempo. Mas, afinal de contas, do que tratam esses papéis? Simples, são eles que sabem comprar livro ou colocar livro no carrinho de compras, por exemplo.

Pronto! Agora temos atores (classes e objetos dispostos no lado esquerdo do diagrama) e papéis. Falta dar-lhes um roteiro.

Peraí Paulo: ou seu exemplo não é lá essas coisas ou então o papo é bem furado mesmo. Afinal, comprar livro ou colocar livro no carrinho de compras não são ações extremamente simples?

Ações ordenadas ou bastante previsíveis, você quis dizer, certo? Vamos lá: imagine que nosso querido Mané, apresentado ali em cima, seja um cliente preferencial. Como tal, ele tem direito a descontos em todas as compras. Quando ele vê um livro, já sabe seu preço normal e o desconto que merecerá. Ao mesmo tempo, a loja já sabe que o Mané prefere pagar com cartão de crédito. O que significa, além de outras coisas, um prazo menor de entrega. Já o cliente (objeto) José é bem diferente: mal se identificou (a loja ainda não sabe nada sobre suas preferências) e está prestes a fazer sua primeira compra. Os ROTEIROS que Mané e José seguirão são consideravelmente diferentes. Apesar de ambos apenas desejarem comprar o último best-seller da Bruna Surfistinha.

Ok, o exemplo continua meia-boca. Mas espero que você tenha entendido o fundamental: interAÇÕES bem distintas acontecerão em ambos os casos. Os atores José e Mané desempenharão papéis diferentes.

Primeiro ponto, aquele que ficou aberto seis parágrafos acima: como Mané e José “aprenderão” a comprar livro ou colocar livro no carrinho de compras? Primeira “mágica”: aquele conhecimento (comprar ou colocar) será INJETADO nos dois clientes (objetos). O termo injetado é muito bom. Lembra-se como Neo, no filme Matrix, aprendeu a lutar kung-fu? Pois é, o conhecimento foi injetado na nuca! É mais ou menos o que estamos fazendo aqui, ensinando (em tempo de execução!) um elemento da estrutura a executar determinada ação.

Não disponho de tempo, espaço e nem competência para entrar em detalhes técnicos desta sugestão. Só me cabe dizer, por enquanto, que tal “mágica” é possível tanto em linguagens OO mais antigas (como C++) quanto em modernosos dialetos mais dinâmicos (como Ruby). Já já te falo onde encontrar exemplos de código, se isso te interessa.

De interesse mais geral deve ser nosso segundo ponto, gritado quatro parágrafos acima: o ROTEIRO. Agora ele merecerá outro nome, um pouquinho mais técnico: Caso de Uso. Estranho como algumas pessoas perdem o sentido da palavra “caso”. Gosto de provocá-las usando um termo caipirão, “causo”. Um “causo” é uma história curta, enxuta. Para nós, é uma história de interAÇÕES, sobre o USO de alguma coisa, sobre FUNÇÕES executadas. Portanto, nosso roteiro (ou script) é redigido na forma de uma especificação de caso de uso. E, em tempo de execução, este mesmo roteiro se transforma em um objeto. Objeto que tem um nome bem especial: CONTEXTO. Mané e José, nossos honoráveis clientes (objetos), desempenharão alguns papéis diferentes e outros semelhantes dependendo do Contexto.

Tempo para uma breve releitura. Você ainda está aqui? Puxa, muito obrigado. Vamos lá:

Mané e José mudarão muito pouco no decorrer do tempo. Alguns de seus atributos, como endereço ou telefone, podem ser alterados. Sua idade, com certeza, mudará a cada ano. Mas isso não significará nenhum tipo de mudança em sua forma. Já os papéis, as interações ou processos de negócios, podem sofrer mudanças com grande frequência. A porção mais volúvel de um negócio, suas regras, estariam praticamente todas concentradas nos papéis com real conhecimento (methodful roles). Assim, ao contrário do que vemos em grande parte dos sistemas de hoje (ou seria de ontem?), as mudanças ficam concentradas em um só lugar. Elas não gerarão impactos em um sem número de classes e outros elementos. Neste desenho, podemos agregar novas funcionalidades sem gerar praticamente nenhum impacto nos elementos já constituídos. Um novo cenário em um caso de uso é só isso, um novo roteiro – que costura e direciona como os atores desempenharão seus papéis em um novo contexto.

Hora de dar nome e crédito à proposta apresentada acima. DCI, de Data, Context and Interaction, é o nome da criança. Criança mesmo, que mal tem cinco anos de vida. A primeira parte, Data (Dados), representa a estrutura (o espaço). Já as Interações representam as finalidades, a arquitetura funcional. E o Contexto, por fim, junta tudo. Este paradigma foi sugerido por Trygve Reenskaug, sujeito que tem em seu currículo outro padrão arquitetônico, amplamente conhecido e aceito: o MVC (Model-View-Controller). Já havia apresentado o tema aqui, quando comentei o livro “Lean Architecture“, de James Coplien e Gertrud Bjørnvig. Para você que quer ver e experimentar um pouco de código, creio que este livro seja o melhor ponto de partida.

UMA Arquitetura

Muito provavelmente é pura burrice de minha parte, mas quando vejo (de soslaio) altos papos sobre DDD (Domain-Driven Design), DSL’s (Domain-Specific Language) e afins, enxergo pouco ou nenhum NEGÓCIO. Eu sei, os conceitos são amplos demais e não pretendem apenas tratar de sistemas para negócios. Mas eu desconfio que um pouquinho de proximidade não faria mal nenhum, muito pelo contrário. Por isso o DCI, particularmente da forma como foi trabalhado por Coplien e Bjørnvig, me chamou tanto a atenção. Percebi ali uma nítida preocupação com o domínio, a complexidade e a dinâmica dos negócios. Mais que isso, vi naquela proposta uma extensão lógica e natural – o que tentei demonstrar aqui. Arquitetura do negócio e de sistemas podem ser vistas como UMA única arquitetura. É certo que estou sendo tendencioso e otimista demais. Se DCI demorar tanto quanto o MVC para “pegar”, com certeza não estarei por aqui para ver o resultado. O MVC é de 1978!

Mas eu sou um incurável otimista. Ao testemunhar como ideias “agile” e “lean” se espalham, fico na esperança de ver mais conversas práticas e pragmáticas ganharem espaço nas agendas de todos os envolvidos com sistemas de informação. Preciso achar espaço para registrar uma preocupação. Será aqui mesmo: não basta ser “ágil” pra caramba e entregar na metade do tempo aquele maravilhoso produto, realizando um pseudo e imediatista valor. Teu ROI (sic), prezada(o) leitora, derretará mais rápido que bolsa de valores em tempos de crise se:

1. Teu rebento, aquele produto, exigir mudanças estruturais toda vez que o negócio evoluir;
2. O tempo tornar seu produto ilegível e incompreensível para os olhos de outrem;
3. Seu produto pedir por duas ou três iterações toda vez que um novo cenário ou papel for necessário.

É curioso e divertido acompanhar como a combinação dos termos “agile” e “lean” tem evoluído. Enquanto algumas dicotomias caem por terra, surgem novos confrontos e contradições. Coplien e Bjørnvig não hesitaram ao colocar várias lenhas nesta estimulante fogueira. Por exemplo:

• Pensar antes não significa FAZER antes. E se você é realmente “lean”, você PENSA antes de fazer;
• Pensar arquitetura != BDUF (Big Design Up Front).
• Esse papo de postergar uma decisão para o último momento (responsável) é perigoso. Porque é difícil descobrir que momento é esse. Mais lógico é decidir na hora em que a decisão é realmente necessária e pronto.
• Lean é baseado em “uma cultura de parar ou desacelerar de forma a obter qualidade no primeiro momento e maior produtividade no longo prazo.” (Jeffrey Liker, em “The Toyota Way” – McGraw-Hill, 2004);
• Pensar “lean” é ver o todo – daí minha preocupação que acabou tornando este artigo um recorde pessoal (2.730 palavras até aqui!). Tentei mostrar como Arquitetura do Negócio e Arquitetura de Sistemas compartilham fundamentos (Espaço, Finalidade) e, principalmente, Intenção;
• Pensar “lean” é ser sustentável – é ter sincera preocupação com o amanhã, com a evolução de um sistema que responde sem ressalvas nem soluços à dinâmica do negócio;
  
• E ser “ágil”, nos ensina o Manifesto, é “responder a mudanças” (além de outras coisas, claro);
  
• “TDD (Test-Driven Development) pode deteriorar a arquitetura”; e
• Como sou um chato incorrigível, vou citar até uma lenha aparentemente menor: o que é mais fácil administrar e entregar, 300 e tantas histórias (User Stories) ou 20 e tantos casos de uso?

?

Céus, quase três mil palavras e você ainda está aqui? Espero que de fato aproveite alguma coisa no meio de tanta prosa. Sabe o que é pior? A sensação de mal ter explorado todas as possibilidades do tema. Pior ainda? Aceitar o fato de que minha contribuição não irá muito além disso aqui. Não vou codificar exemplos e é pouco provável que eu participe, mesmo que como observador, do desenho de uma arquitetura conforme sugerida por Reenskaug, Coplien e Bjørnvig. Resta te pedir que me avise sempre que perceber qualquer coisa parecida passando por perto, ok? Tks!

Observações:

1. Trecho da definição de arquitetura proposta por Lúcio Costa e surrupiada da Wikipédia.
2. Não é lá muito “ágil” esse negócio de chamar pessoas de recursos. É feio, eu admito. Mas, por favor, entenda que no frio da teoria uma pessoa pode ser sim um RECURSO utilizado por uma empresa para determinada finalidade e visando a determinada intenção. O que deveria de fato importar é que a empresa não trate uma pessoa da mesma maneira como trata uma mesa ou um carro enguiçado. Mas tem gente que gosta de briga e não será um recurso nunca! Nem no melhor sentido da palavra.
3. Por uma questão de brevidade (haha!) me limitei a citar o modelo Estrutura-Comportamento proposto por Jurgen Appelo. Saiba que ele compara sua sugestão com dois modelos um pouco mais conhecidos, o Cynefin proposto por David Snowden e o modelo da Concordância & Certeza (Agreement & Certainty) proposto por Ralph Stacey. Jurgen insiste para que recebamos todas essas propostas sempre com um pé atrás: “todas estão erradas… mas algumas são úteis”.
4. “Spil-skitse-tegning” é o cartoon que aparece lá no longínquo topo do artigo. Pra variar, é do HikingArtist.
5. Ah sim, caso interesse, está aqui a apresentação utilizada no Agile Vale 2011. Como alertei a amiga Simone, ela deve ser ininteligível se não acompanhada da prosocopeia acima.