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!

Nick Malik, do Inside Architecture, chegou antes, e no último dia 11/jul publicou 4 razões para não acreditarmos que código é documentação suficiente para processos de negócio.

O excelente artigo do Nick não me isentará de voltar ao assunto. Acontece que eu quero ir um pouco além, tentando entender ou explicar o trauma que é a tal “documentação”. Enquanto trato de outras prioridades, fica a provocação:

“Software is the leaky abstraction. It makes poor documentation for a business process.“

Como já reclamei aqui em outras ocasiões, nossa área adora reinventar algumas coisas. Começar do zero, ao invés de melhorar algo que já existe. Assim nasceram as User Stories, peça fundamental da metodologia-religião popularmente conhecida como XP (eXtreme Programming). Segundo um de seus apóstolos, as User Stories são formadas por três elementos:

• Cartão: onde escrevemos as estórias ;
• Conversas: que nos levariam a entender e detalhar as estórias; e
• Confirmação: o ‘the end’, o fim da estória.

A motivação para tamanha invenção gira em torno da palavrinha ‘documentação’ (um dos pecados mortais, segundo aquela doutrina). Por isso outro apóstolo reforça: “os cartões representam os requisitos do cliente, mas não os documentam”. Vai na linha de um mestre-pacificador (mezzo tucano) que vive insistindo: “gente, modelagem não é documentação… modelagem não é documentação… isso é um mito”. Documentação parece um trauma incurável. Mas falarei mais sobre isso em outras oportunidades. A história aqui são as estórias.

No post anterior eu destaquei um probleminha com o processo adotado pela Anne: “Nós organizamos as cento e poucas estórias por processos de negócios…”. Vai na linha do problema reconhecido por aquele primeiro apóstolo (que escreveu um livro só sobre estórias) : “É difícil saber por onde começar”.

Se o trabalho começa por uma correta análise do negócio e seus processos, não devem existir dúvidas sobre o ponto de partida. Ao organizar os trabalhos de coleta e análise de requisitos a partir dos processos de negócio, não existe o trabalho de “organização de estórias”. Assim, não há justificativas para adoção do POREM (Post-it-Oriented Requirements Elicitation Method).

Ironias à parte, o fato é que as user stories, apesar de bem intencionadas, trazem mais problemas (inclusive alguns que não existiam antes) do que soluções. Sua granularidade e a doentia independência dificultam o gerenciamento; Tornam as atividades de priorização e planejamento das iterações bastante confusas. Ou seja, sua utilização em projetos médios e grandes deve ser um pesadelo .

Se começamos do começo, ou seja, pela análise do negócio e seus processos, é mais natural a adoção dos Casos de Uso como técnica para coleta, organização e análise de requisitos. Segundo seu criador , “um caso de uso é o nosso constructo para um processo de negócio”; ” descrevem o negócio e o seu ambiente”.

A adoção de casos de uso não significa, de maneira alguma, deixar de ser ágil. Aliás, se bem adotada, a técnica deve promover maior agilidade do que as estórias. As 6 qualidades das boas estórias também devem caracterizar os bons casos de uso :

• Independentes: até o limite onde a independência é desejável, ou seja, até o ponto em que ela não gere surpresas e omissões no projeto;
• Negociáveis: se o cliente e demais stakeholders não puderem negociar os casos de uso, o que sobra?
• Valiosos para Usuários e Clientes: óbvio? Nem tanto. Vide o tanto de caso de uso descrevendo CRUD’s e afins por aí.
• Estimáveis: ok, UCP‘s são frágeis. Tanto quanto todos os outros métodos conhecidos. Mas, independente do método, casos de uso são (ou deveriam ser) estimáveis.
• Pequenos: não tanto quanto uma história, mas o suficiente para representar uma unidade significativa para o negócio (seja ela uma tarefa, atividade ou processo). Se um caso de uso for grande ou de difícil leitura ele está errado – regrinha básica;
• Testáveis: wow. Outra regrinha: se não pode ser testado então não é um caso de uso. Deriva de outra regrinha que diz que : “Se um requisito não pode ser testado então ele não é um requisito”.

Resumo da ópera cômica: sejamos ecologicamente responsáveis: post-its e cartões são feitos de árvores; vamos parar com esse papo de ‘casa de ferreiro… espeto de bambu’ (bambu solta farpas); municiemos nossas equipes e stakeholders com informações consistentes, bem pensadas, analisadas e estruturadas…

… começando do começo: o Negócio.

Notas:

1. Não tenho (quase) nada contra XP e afins. Meu problema é só com os fundamentalistas mal educados e donos da verdade suprema. XP e afins foram úteis, representaram um avanço, chacoalharam o status quo. Ou seja, foram um mal necessário.
   
2. User Stories Applied: For Agile Software Development
   Mike Cohn. Addison-Wesley (2004).
   Obs: Mesmo autor do artigo sobre UCP referenciado acima.
3. Lembram-se daqueles livrinhos da Ediouro que sempre traziam uma discussão sobre “estória versus história”? Pois é, me lembrei deles na hora de traduzir stories.
4. The Power of Stories
   Rachel Davies. XP 2001.
5. Debunking Modeling Myths
   Scott W. Ambler. Software Development (Agosto/2001).
6. Deve ser (um pesadelo). Nunca testei e nunca terei coragem para tanto.
7. The Object Advantage – Business Process Reengineering with Object Technology
   Ivar Jacobson. Addison-Wesley (1995).
8. Requirements-Led Project Management
   Suzanne e James Robertson. Addison-Wesley (2005).