“A correta definição do que precisa ser feito é a etapa mais difícil do desenvolvimento de sistemas. Nenhuma outra compromete tanto um projeto quando mal executada. E nenhuma é mais difícil de ser corrigida.”

O que fizemos de lá para cá?

• Distorcemos todos os currículos relacionados com a formação de engenheiros e analistas de sistemas. Enfatizamos o domínio da solução – programação e mais programação – em detrimento do domínio do problema.
• Mas a Academia, apressada, estava apenas seguindo o mercado. Um mercado que inventou, em meados dos anos 1990, um tal de analista-programador. Isso tem reflexos negativos até hoje. Basta ver a reincidência de um álibi fajuto: “o cliente/usuário nunca sabe o que quer”. Quem aprendeu a perguntar? Quanta ajuda o cliente/usuário tem merecido?
• De repente, ganhamos Agilidade. Com muitas propostas que parecem ser “do desenvolvedor, pelo desenvolvedor, para o desenvolvedor”. A coisa só piorou.
• E tocou o fundo do poço quando alguém acreditou que um Business Model Canvas –  uma cortina feita de papel sulfite – seria capaz de esconder aquele imenso buraco.
• Oras, e se o buraco for apenas uma hipótese? Vamos todos fingir que o buraco não existe; Ou é parte da decoração; Ou é só a opinião de alguém.
• Por fim, se o tal Upstream Kanban pretende, ainda que parcialmente, tratar do domínio do problema, então ele não pode começar se apresentando como um “processo de triagem”. Que vai da síntese para a análise? Fixando CONWIPs?!?²

A Acusação Comum

Um efeito esquisito do movimento Ágil, que contradiz sua intenção de ser Sistêmico, é a percepção generalizada de que tudo o que não é construção é desperdício. James Coplien e Gertrud Bjørnvig reclamam disso em Lean Architecture (Wiley, 2010). Peter Morville, falando de Arquitetura de Informações, relata o mesmo problema (Intertwingled, 2014). E o que dizer da Análise de Negócios? Que ela deu um tiro no pé quando publicou uma Extensão Ágil. Confessou uma culpa que não deveria ter. Pau que nasce torto…

A acusação ficou chique e mereceu até sigla: BDUF (Big Design Up Front). É importante destacar que a acusação não é vazia. É preciso lembrar o contexto que motivou o Manifesto Ágil. Era comum, naquele tempo, um mal conhecido como Analysis Paralysis. A burocracia emperrava pacas. Projetos entregavam bulhufas.

A diferença entre o remédio e o veneno é o tamanho da dose. Erramos a mão e criamos outro mal, a Agile Death Spiral. Sprints sem fim ou fins. Pivots mil. Um desastrado foco na eficiência que ignora o primordial: ao fazer a coisa errada do jeito certo, só estamos acelerando rumo ao desastre.

Entre a cascata congelada no tempo e o pós-moderno ciclone da morte deve haver um caminho.

Equilíbrio

A sugestão do Yin-Yang é de Peter Morville, no livro já citado. A imagem combina bem com a matriz apresentada no artigo anterior. Que esteja subentendida a necessidade de iterações. O ícone também informa que há construção nos momentos iniciais. E que não é proibido rever o problema e repensar os planos nos momentos seguintes.Esse equilíbrio bem zen seria perfeito se o alerta do Brooks não continuasse verdadeiro: aquela primeira metade (escura) é a mais crítica para o sucesso de um projeto ou produto. Mas ela não existe no Scrum, por exemplo³. O que nos levou a entender que bastaria puxar para o domínio do problema o mesmo esquema utilizado no domínio da solução. Vêm daí os sprints 0, -1 etc. Essas iterações podem ser úteis para a realização de spikes (experimentos), configuração do ambiente e coisas do tipo. Mas não têm nada a ver com o domínio do problema. O que é conhecido como grooming também não.

Sprints com duração fixa de uma, duas ou quatro semanas fazem muito sentido nos trabalhos de DESENVOLVIMENTO e ENTREGA. Mas viram camisas de força nos trabalhos de DESCOBERTA e EXPLORAÇÃO. Nesses momentos, é comum a necessidade de cinco ou dez iterações em uma única semana. Marty Cagan, em Inspired (Wiley, 2017) fala em até vinte iterações. Jake Knapp, em Sprint (Intrínseca, 2016), nos mostra um ciclo completo acontecendo em uma semana. Enfim, a variedade aqui é grande. E necessária.

O Design Thinking nos oferece ampla variedade de métodos e ferramentas para o Domínio do Problema. Não foi por outro motivo que Jonny Schneider, da Thoughtworks, propôs a seguinte combinação:

• Design Thinking: para explorar o problema
• Lean: para construir a coisa certa
• Agile: para construir do jeito certo

Legal. Mas o Manifesto Ágil não fala em eficácia logo no seu primeiro princípio? As propostas Lean não parecem preocupadas com eficiência? O Design Thinking não tem o que contribuir para o domínio da solução? A ideia do Schneider é promissora. A mensagem “Lean E Agile” ao invés do OU é correta. Mas a divisão de responsabilidades proposta acima não faz o menor sentido. 

Acho que nós precisamos de outro enfoque, mais amplo e inclusivo. Precisamos de um modelo que incorpore, sem puxadinhos, uma legítima preocupação com o domínio do problema. Que faça a gente “se apaixonar pelo problema, não pela solução“.  Bom tema para o próximo artigo.

Notas

1. No artigo No Silver Bullet, transformado em capítulo da edição comemorativa de The Mythical Man-Month (Addison-Wesley, 1995). Este trabalho, lançado originalmente em 1975 (!), acaba de ganhar nova edição em pt-br: O Mítico Homem-Mês (Alta Books, 2018). Parafraseando Brooks: “a longevidade desse livro atesta que a gente continua caindo nos mesmos buracos…”
2. São algumas sugestões apresentadas por Patrick Steyart em Essential Upstream Kanban.
3. Que fique claro: não se trata de um bug do Scrum. A omissão é intencional. E só vira um problema se a gente a ignorar. Ou, pior ainda, se a gente esticar o Scrum para cobrir o buraco.
4. “Se apaixone pelo problema, não pela solução” é uma das dicas de Marty Cagan em Inspired (Wiley, 2017).
5. hole in the wall é o título da óbvia imagem de hoje.

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!

Era uma vez…

No segundo semestre de 2006 eu estava mais perdido que político safado em tempos de delações premiadas. Prestes a completar o primeiro ano de carreira solo, ainda não tinha um conjunto bem definido de ofertas. “Consultoria” é um balaio que aceita qualquer coisa e, pelo visto, qualquer um. Eu precisava de um abridor de latas e portas. Num belo dia, em um grupo de discussão, alguém¹ escreveu que “analistas de negócios não agregavam porcaria nenhuma para o projeto”. Era tudo o que eu precisava.

Em junho de 2007 apresentei, em São Paulo, a primeira edição do FAN. Um palestrão com sete horas de duração disfarçado de oficina. Agradou. Abriu portas. E o que aprendi nos últimos dez anos é muito mais do que havia colecionado nos vinte anos anteriores. Nessa década, quase tudo no programa mudou. Exceto um princípio e dois pilares.

Que ? Como

O princípio que quebra gelos é uma citação de Fred Brooks²: “A correta definição sobre o que precisa ser feito é a etapa mais difícil da construção de um sistema. Nenhuma outra compromete tanto um projeto quando mal executada. E nenhuma é mais difícil de ser corrigida.”

Rabisco dois círculos. O primeiro representa o QUE, o outro o COMO. O primeiro é o Domínio do Problema, território dos analistas de negócios. O segundo, Domínio da Solução, grande área dos analistas de sistemas e desenvolvedores. Coisa boba – simples – que na pré-história do FAN foi espinafrada por alguns. Hoje me divirto quando vejo papos modernos sobre “duas trilhas, design e desenvolvimento”, “User Stories devem ser separadas entre QUE e COMO” e por aí vai.

Dois Pilares

Os dois pilares do FAN são duas disciplinas: Modelagem de Negócios e Engenharia de Requisitos. Infelizmente, repito até hoje que a primeira é a mais mal tratada que conheço. Maltratada porque merece poucos estudos, livros, artigos etc. A área avançou, fora do domínio de TI, nos trabalhos de gente como Dan Roam, Alexander Osterwalder, Dave Gray, Sunni Brown e David Sibbet, dentre outros. Mas é pouco e muito pobre em termos de base teórica. Faltam consistência, coesão e ambição. Mas é muito mais do que é oferecido pelo pessoal de TI.  Todas as turmas do FAN pós-palestrão foram convidadas a modelar à mão. Porque só modelando e abstraindo podemos entender, explicar, domar ou pelo menos dançar³ com esses sistemas complexos chamados “negócios”.

A Engenharia de Requisitos, por sua vez, é rica em livros, artigos, palestras e… tropeços.
Pare e pense um pouquinho no termo “Requisito Não-Funcional”. Pense como um leigo.
Horrível, não? E você vai elicitá-lo (sic), eliciá-lo ou coletá-lo? Por que insistimos em verbos e substantivos tão desastrados? E o que dizer da interpretação de REQUISITO como sendo um “entregável” (sic) ou uma “representação utilizável de uma necessidade”? Puxa, nosso dicionário diz apenas que requisito “é uma condição necessária para alcançar determinado fim”. Para que complicar?

Compreender fins e meios; Conhecer e se comprometer com as pessoas envolvidas; Ajudá-las a resolver problemas. É disso que trata a Análise de Negócios. Não é pouca coisa.

Fracassos Retumbantes

Por muitos anos tive que responder a seguinte questão: “e o seu livro, já saiu?” A primeira apostila do FAN era um ensaio de quase 100 páginas que tinha jeito de livro. Ingênuo, prometi a sua publicação dezenas de vezes. E elaborei planos mil, até uma gráfica on-demand. Pivotei (sic), sem vergonha nem piedade. Não era hora, não era o assunto. Não era negócio.

Assim como não foram bons negócios diversos derivados do FAN: FAN4Scrum, FDP (Formação de Donos de Produtos), Scrum para Negócios, FAN +Ágil… Experimentos que nunca mereceram mais de quatro edições. Do ponto de vista financeiro, foram mesmo belos tombos. Usando outras perspectivas – aprendizagem e viagens – não tenho do que reclamar.

Uma Tentativa de Assassinato

Há pouco mais de dois anos tentei matar o FAN. Por diversas razões, achei que passava de hora de dar um fim honroso para o programa. Cheguei a procurar um concorrente e propor um debate que se encerraria de forma dramática – com sangue! Ele não topou, eu desisti da ideia e o FAN ganhou roupa e propósito novos.

Tirei do esperançoso flit o conceito de trabalhos a executar e redesenhei o FAN como um conjunto de oito trabalhos essenciais. A vaquinha leiteira virou ponta de lança de um ambicioso projeto: ajudar a formar sete bilhões de pensadores sistêmicos.

Planos

Reli alguns posts antigos deste finito. No início do FAN eu publicava rendicontis (prestações de contas). Acho que transparência ajudou o produto. Por outro lado, os planos e promessas não realizados ainda me deixam sem jeito. Além disso, está na moda dizer que “planejar” é trabalho inútil. O pós-moderno “deixa a vida lhe levar”. Não caio nessa. Aliás, acho que ninguém cai. Por curta que seja a viagem, você antevê a rota.

Pedestre na contramão não atrapalha quase ninguém. Por isso meu terceiro lançamento deste ano vai cuidar da disciplina que, como disse acima, é muito mal tratada: a Modelagem de Negócios. Na próxima terça-feira (27/6) lançarei formalmente o produto, numa aula aberta e gratuita: Imagens da Organização.

E o FAN? Oras, segue vivo e em frente. Com uma edição comemorativa – no formato clássico – acontecendo em São Paulo nos dias 30/6 e 1/7.

Agradecimentos

Se eu colocar um nome aqui cometerei injustiças mil. Na edição comemorativa, mesmo com quórum mínimo, alcançarei a marca de cinco mil participantes. Cada um, de um jeito ou de outro, ajudou o FAN a chegar até aqui. Para todos, sem exceção, o meu muito obrigado.

Notas

1. O santo em questão um dia me pediu que eu parasse de contar essa história. Porque sua frase estava fora de contexto. Escondo o santo, mas não o milagre. Dentro ou fora do contexto, o fato é que aquela frase me trouxe até aqui.
2. A colocação original do Brooks aparece no artigo “No Silver Bullet”, de 1986. Este artigo e outros aparecem na edição comemorativa de 25 anos do livro O Mítico Homem-Mês (Campus, 2009).
3. Donella Meadows é quem trata com mais delicadeza um tema duro e difícil, o Pensamento Sistêmico. Se não por outro motivo, a simples sugestão para aprendermos a “dançar com sistemas” é um convite e tanto para conhecer sua obra póstuma Thinking in Systems – A Primer (Chelsea Green Publishing, 2008).
4. 10, fotografia de Leo Reynolds, ilustra este artigo.

Era uma vez…

No segundo semestre de 2006 eu estava mais perdido que político safado em tempos de delações premiadas. Prestes a completar o primeiro ano de carreira solo, ainda não tinha um conjunto bem definido de ofertas. “Consultoria” é um balaio que aceita qualquer coisa e, pelo visto, qualquer um. Eu precisava de um abridor de latas e portas. Num belo dia, em um grupo de discussão, alguém¹ escreveu que “analistas de negócios não agregavam porcaria nenhuma para o projeto”. Era tudo o que eu precisava.

Em junho de 2007 apresentei, em São Paulo, a primeira edição do FAN. Um palestrão com sete horas de duração disfarçado de oficina. Agradou. Abriu portas. E o que aprendi nos últimos dez anos é muito mais do que havia colecionado nos vinte anos anteriores. Nessa década, quase tudo no programa mudou. Exceto um princípio e dois pilares.

Que ? Como

O princípio que quebra gelos é uma citação de Fred Brooks²: “A correta definição sobre o que precisa ser feito é a etapa mais difícil da construção de um sistema. Nenhuma outra compromete tanto um projeto quando mal executada. E nenhuma é mais difícil de ser corrigida.”

Rabisco dois círculos. O primeiro representa o QUE, o outro o COMO. O primeiro é o Domínio do Problema, território dos analistas de negócios. O segundo, Domínio da Solução, grande área dos analistas de sistemas e desenvolvedores. Coisa boba – simples – que na pré-história do FAN foi espinafrada por alguns. Hoje me divirto quando vejo papos modernos sobre “duas trilhas, design e desenvolvimento”, “User Stories devem ser separadas entre QUE e COMO” e por aí vai.

Dois Pilares

Os dois pilares do FAN são duas disciplinas: Modelagem de Negócios e Engenharia de Requisitos. Infelizmente, repito até hoje que a primeira é a mais mal tratada que conheço. Maltratada porque merece poucos estudos, livros, artigos etc. A área avançou, fora do domínio de TI, nos trabalhos de gente como Dan Roam, Alexander Osterwalder, Dave Gray, Sunni Brown e David Sibbet, dentre outros. Mas é pouco e muito pobre em termos de base teórica. Faltam consistência, coesão e ambição. Mas é muito mais do que é oferecido pelo pessoal de TI.  Todas as turmas do FAN pós-palestrão foram convidadas a modelar à mão. Porque só modelando e abstraindo podemos entender, explicar, domar ou pelo menos dançar³ com esses sistemas complexos chamados “negócios”.

A Engenharia de Requisitos, por sua vez, é rica em livros, artigos, palestras e… tropeços.
Pare e pense um pouquinho no termo “Requisito Não-Funcional”. Pense como um leigo.
Horrível, não? E você vai elicitá-lo (sic), eliciá-lo ou coletá-lo? Por que insistimos em verbos e substantivos tão desastrados? E o que dizer da interpretação de REQUISITO como sendo um “entregável” (sic) ou uma “representação utilizável de uma necessidade”? Puxa, nosso dicionário diz apenas que requisito “é uma condição necessária para alcançar determinado fim”. Para que complicar?

Compreender fins e meios; Conhecer e se comprometer com as pessoas envolvidas; Ajudá-las a resolver problemas. É disso que trata a Análise de Negócios. Não é pouca coisa.

Fracassos Retumbantes

Por muitos anos tive que responder a seguinte questão: “e o seu livro, já saiu?” A primeira apostila do FAN era um ensaio de quase 100 páginas que tinha jeito de livro. Ingênuo, prometi a sua publicação dezenas de vezes. E elaborei planos mil, até uma gráfica on-demand. Pivotei (sic), sem vergonha nem piedade. Não era hora, não era o assunto. Não era negócio.

Assim como não foram bons negócios diversos derivados do FAN: FAN4Scrum, FDP (Formação de Donos de Produtos), Scrum para Negócios, FAN +Ágil… Experimentos que nunca mereceram mais de quatro edições. Do ponto de vista financeiro, foram mesmo belos tombos. Usando outras perspectivas – aprendizagem e viagens – não tenho do que reclamar.

Uma Tentativa de Assassinato

Há pouco mais de dois anos tentei matar o FAN. Por diversas razões, achei que passava de hora de dar um fim honroso para o programa. Cheguei a procurar um concorrente e propor um debate que se encerraria de forma dramática – com sangue! Ele não topou, eu desisti da ideia e o FAN ganhou roupa e propósito novos.

Tirei do esperançoso flit o conceito de trabalhos a executar e redesenhei o FAN como um conjunto de oito trabalhos essenciais. A vaquinha leiteira virou ponta de lança de um ambicioso projeto: ajudar a formar sete bilhões de pensadores sistêmicos.

Planos

Reli alguns posts antigos deste finito. No início do FAN eu publicava rendicontis (prestações de contas). Acho que transparência ajudou o produto. Por outro lado, os planos e promessas não realizados ainda me deixam sem jeito. Além disso, está na moda dizer que “planejar” é trabalho inútil. O pós-moderno “deixa a vida lhe levar”. Não caio nessa. Aliás, acho que ninguém cai. Por curta que seja a viagem, você antevê a rota.

Pedestre na contramão não atrapalha quase ninguém. Por isso meu terceiro lançamento deste ano vai cuidar da disciplina que, como disse acima, é muito mal tratada: a Modelagem de Negócios. Na próxima terça-feira (27/6) lançarei formalmente o produto, numa aula aberta e gratuita: Imagens da Organização.

E o FAN? Oras, segue vivo e em frente. Com uma edição comemorativa – no formato clássico – acontecendo em São Paulo nos dias 30/6 e 1/7.

Agradecimentos

Se eu colocar um nome aqui cometerei injustiças mil. Na edição comemorativa, mesmo com quórum mínimo, alcançarei a marca de cinco mil participantes. Cada um, de um jeito ou de outro, ajudou o FAN a chegar até aqui. Para todos, sem exceção, o meu muito obrigado.

Notas

1. O santo em questão um dia me pediu que eu parasse de contar essa história. Porque sua frase estava fora de contexto. Escondo o santo, mas não o milagre. Dentro ou fora do contexto, o fato é que aquela frase me trouxe até aqui.
2. A colocação original do Brooks aparece no artigo “No Silver Bullet”, de 1986. Este artigo e outros aparecem na edição comemorativa de 25 anos do livro O Mítico Homem-Mês (Campus, 2009).
3. Donella Meadows é quem trata com mais delicadeza um tema duro e difícil, o Pensamento Sistêmico. Se não por outro motivo, a simples sugestão para aprendermos a “dançar com sistemas” é um convite e tanto para conhecer sua obra póstuma Thinking in Systems – A Primer (Chelsea Green Publishing, 2008).
4. 10, fotografia de Leo Reynolds, ilustra este artigo.

?

Naquela época algumas pessoas diziam que o bafafá sobre Análise de Negócios não passava de uma moda. Sempre admiti que a disciplina vivia seu momento, algo semelhante ao que havia acontecido com o Gerenciamento de Projetos a partir da segunda metade da década de 1990. E completava: “antes tarde do que nunca”. Porque já tinha muito tempo que diversas fontes, ao analisar as razões de tantos fracassos em projetos de TI, apontavam o mau entendimento de um problema e questões de comunicação entre times técnicos e de negócio como algumas das principais causas de tanto insucesso.

Surrupiei e uso desde então uma colocação que Fred Brooks fez em seu artigo “No Silver Bullet” (publicado originalmente em 1987 e disponível como capítulo adicional do livro “O Mítico Homem-Mês“, Campus – 2009):

“A precisa definição sobre o que precisa ser feito é a parte mais difícil da construção de um software. Nenhuma outra compromete tanto um projeto quando mal executada. E nenhuma é mais difícil de ser corrigida.“

A Análise de Negócios, por definição, ataca exclusivamente¹ a “parte mais difícil da construção de um software”. Por isso eu dizia e repito: “antes tarde do que nunca”. Que a disciplina tenha vindo para ficar. Ou, melhor dizendo, que a “moda” (assim, entre aspas) tenha vindo para ficar. Porque a disciplina está conosco há um tempão.

O problema é que sua presença não era percebida como sendo uma disciplina, um único corpo de conhecimentos. No RUP, por exemplo, surgia em dois lugares: Modelagem de Negócios e Requisitos. Em outras propostas e métodos dava sua cara sob o disfarce de “<verbo> Requisitos” (Levantamento (sic) de Requisitos, Coleta (10x sic) de Requisitos, Gerenciamento de Requisitos  etc). Esta ligação direta, Análise de Negócios -> Requisitos, é tão comum e pouco questionada que contamina não só a forma como muitas empresas interpretam e usam a disciplina, marca também os mais graves enganos do BABoK.

Por incrível que possa parecer, muitas empresas (algumas bem grandinhas) entendem que o analista de negócios é aquele cara que senta na frente de um usuário e anota tudo o que ele pedir. Não são analistas de negócios, são “tiradores de pedidos”. É fácil identificar empresas com tal grau de miopia: basta pegar a média de idade e de tempo de casa de seus analistas. Em outras (poucas) organizações tive a surpresa e felicidade de encontrar analistas com mais de 20 anos de casa². É nítida a mensagem que elas passam: “essas pessoas conhecem como pouquíssimas a organização, por isso elas têm melhores condições de analisar nosso negócio”.

A atenção exclusiva ao incêndio nosso de cada dia – às operações insanas tocadas por times pequenos tentando segurar diversos sistemas bichados – anula qualquer benefício que a Análise de Negócios pode trazer.

Como em toda “moda”, há aqueles que compram sem saber o que estão comprando. Nem sabem se precisam daquilo. “Como o vizinho da grama mais verde está usando analistas de negócios, então eu também quero”. Não são poucos os profissionais que me procuram reclamando que foram contratados como AN’s mas que só fazem o trabalho de analistas de sistemas ou de suporte. Na realidade, como já chorei por aqui, a atenção exclusiva ao “incêndio nosso de cada dia” – às operações insanas tocadas por times pequenos tentando segurar diversos sistemas bichados – anula qualquer benefício que a Análise de Negócios poderia trazer. Cheguei a pensar no seguinte título: “Parem de Contratar Analistas de Negócios!“. Mas acho que soaria alarmista demais… e incompleto. Quem dera o problema fosse “só” esse.

A alta rotatividade de profissionais – tema que tenho debatido no GRAFFiTi (1,2) – é particularmente nociva quando atinge analistas de negócios. Sei de empresas que perderam mais da metade de seu time de AN’s em menos de dois anos. Desenvolver as habilidades técnicas de um AN é relativamente rápido e barato. O mesmo não pode ser dito sobre o Conhecimento do Negócio. Dependendo das experiências anteriores do analista – se já atuou naquele ramo de atividades, por exemplo – pode ser demorada e custosa a aquisição deste conhecimento. É difícil justificar a adoção de uma política de retenção específica para AN’s. Mas as empresas precisam entender que cada AN perdido (ou demitido) pode ser um desperdício que não se recupera em 12 meses.

O que mais me angustia é a sensação de que boa parte dos participantes de meus treinamentos não poderá utilizar ou praticar muito do que aprendeu (ou que eu espero que ele tenha aprendido). Por quê? Porque a Análise de Negócios é apenas uma peça do complexo quebra-cabeças chamado “Desenvolvimento de Sistemas”. Como desenvolver requisitos de maneira iterativa e incremental se a empresa ainda está casada (através de muito papel passado) com o modelo Waterfall? Por isso algumas de minhas sugestões sempre são recebidas da mesma maneira: “meu ‘chefe’ (sic) deveria estar aqui ouvindo isso”. AN’s trabalhando em duplas? AN’s dedicados a apenas um ou no máximo dois projetos? Esquece…

As empresas vivem aturdidas e um tanto perdidas. Significa dizer que seus objetivos nem sempre ou quase nunca são conhecidos (ou entendidos). Jogue na mesma cumbuca departamentos de TI que, de tanto não entregar, desaprenderam a dizer “não” ou perderam o direito de dizê-lo. Pronto: está criado o ambiente maluco de gente que acredita (na marra) que é possível atender e entregar 20 ou 10 projetos simultâneos.

Mais triste é saber que a Boa Análise de Negócios, se bem aplicada, ajudaria a reduzir essa sensação de não saber o que fazer. Ajudaria tanto a área de TI quanto a organização como um todo. Acontece que são raríssimas as organizações que percebem a disciplina desta forma. As outras, mesmo que percebessem, agora veriam uma área repleta de “tiradores de pedidos” com rostos assustados.

?

Não queria abrir a temporada de artigos em tom tão pessimista. Mas eu entendo que é minha obrigação publicar esse tipo de alerta. Espero já ter esgotado as principais notícias ruins acima. Porque sei que também é minha obrigação tentar dar algumas dicas que ajudem as organizações a combater o mau uso da Análise de Negócios. Ou, colocando de forma mais positiva, tentarei mostrar como é o bom uso da Análise de Negócios. Inté!

Observações:

1. Antes que atirem pedras: eu escrevi acima que a “análise de negócios, por definição, ataca exclusivamente ‘a parte mais difícil da construção de um software'”. Claro que estou falando da Análise de Negócios aplicada *exclusivamente* em projetos de software.
2. Por favor, entenda que não estou defendendo que todo AN deve ter 10 ou 20 anos “de casa”. Apenas ilustrei um caso extremo e bastante específico. Por outro lado reforço sim que uma empresa que leve a sério a Análise de Negócios deve ter um bom número de analistas com considerável experiência naquela organização ou mercado. O que chamo de “considerável experiência”? No próximo artigo a gente conversa sobre isso.
3. A imagem utilizada, “4“, foi liberada por rosmary com licença Creative Commons (by).

Seguem os convites:

Se você quiser entender um pouquinho mais a importância do cara, veja a série de artigos que publiquei aqui no finito em 2006. Se gostar, não deixe de comprar o livro. Se comprar o livro, lembre-se de uma provocação do Brooks:

Eles falam que o livro é a Bíblia da Engenharia de Software… é por isso que todo mundo o lê mas ninguém o usa!

A gente se vê num dos dois eventos acima. Inté!

Berkun escreve de forma aberta. Há tempos ele escreveu em seu blog qual seria o tema do livro e passou a documentar a evolução. Usou o blog como fonte de pesquisas e para validação de seus achados. O novo livro é pequeno (192 págs) e o tema um tanto espinhoso. O melhor livro sobre inovação e criatividade que conheço é “Criatividade e Grupos Criativos”, de Domenico de Masi. Pelas breves descrições do novo Berkun já disponíveis, dá para perceber algumas coincidências:

• Why all innovation is a collaborative process
• How innovation depends on persuasion
• Why problems are more important than solutions
• How the good innovation is the enemy of the great
• Why the biggest challenge is knowing when it’s good enough

Sairá um “De De Masi a Berkun”? hehe.. Não creio. Não só porque o título seria horrível, mas porque tenho outras prioridades. Logo elas aparecerão por aqui. Mas, com certeza, o novo Berkun deve dar o empurrão definitivo para que eu encerre aquela série sobre o “Gerenciamento do Trabalho Criativo“.

Mas fica a tentação: De Masi, em “Criativade”, conta toda a história da humanidade e pára em meados do século XX. Berkun conta a história das inovações olhando tudo o que veio depois, TI, software etc. Deve ser um belo complemento.

.

O reuso de ativos de software é uma daquelas várias promessas da área de TI que parecem gerar mais decepções do que resultados concretos. Antes da onda SOA, as propostas que colocaram a reusabilidade como uma de suas maiores vantagens foram a Orientação a Objetos (OO) e o Desenvolvimento Baseado em Componentes (CBD – Component-Based Development). Ambas as propostas tinham o reuso como uma conseqüência natural. Ou seja, não se preocuparam em fazer do reuso uma prática sistemática, planejada. Autores como Grady Booch transferiam para os programadores a responsabilidade de reutilizar ativos de software: “durante a implementação, procure agressivamente por partes que possam ser reutilizadas” . Hoje é dito que “oportunidades para o reuso são como os bugs, quanto antes elas forem encontradas melhor” .

O reuso não planejado, chamado por Steve McConnell de “reuso oportunista”, careceria de “alguma sorte” para a sua realização . Sendo casual, ele dependeria muito da equipe do projeto e do conhecimento que esse time tem sobre os ativos existentes e projetos anteriores da organização. Hoje pode-se afirmar que os benefícios gerados pelo reuso de ativos de software não podem ser plenamente realizados se dependerem exclusivamente da casualidade – o encontro de coincidências entre dois ou mais projetos – e do conhecimento de uma equipe de projeto.

O reuso sistemático ou planejado de ativos de software significa :

• Compreensão de como o reuso contribui para a realização dos objetivos do negócio como um todo;
• Definição de estratégias técnicas e gerenciais para que se alcance o máximo valor com o reuso;
• Integração do reuso em todo o processo de software e também no programa de melhoria do processo;
• Garantia de que toda a equipe possui as competências e motivação necessárias;
• Estabelecimento do adequado suporte organizacional, técnico e orçamentário; e
• Uso de métricas apropriadas para controle da performance do reuso.

Ao contrário do que se imaginava, o reuso depende muito pouco de tecnologia. Pesquisa realizada com 71 organizações de desenvolvimento mediu o impacto de uma série de fatores na adoção do reuso e concluiu que, das 6 dimensões medidas, a tecnologia é a menos relevante. No reuso sistemático, os fatores mais críticos para o sucesso seriam :

• Planejamento e Melhoria Contínua do Processo;
• Existência de um Processo Formalizado;
• Apoio da Alta Gerência;
• Similaridade entre Projetos; e
• Arquitetura Comum.

Posteriormente esta série de artigos tratará de cada uma das dimensões apresentadas na lista acima. Neste ponto o importante é a constatação de que “a introdução do reuso sistemático é muito mais do que uma mudança tecnológica: ele deve ser compreendido e gerenciado como um grande conjunto de mudanças no processo de software” . As três primeiras dimensões apresentadas acima, do tipo organizacional, aparecem apenas quando o processo de reuso é sistemático e formalizado perante toda a organização.

É importante lembrar que, como foi colocado no primeiro artigo da série, dois dos principais modelos para melhoria dos processos de software, o CMMI e o MPS.br, não contemplam o reuso. Apesar de indicarem que se trata de um nítido sinal de maturidade do processo de uma organização . Algumas propostas sugerem a adaptação dos grupos de reuso da ISO/IEC 15504-5 para as áreas de processo do CMMI . Há ainda a possibilidade do MPS.br incorporar processos de reuso em versão a ser liberada no primeiro semestre de 2007. Organizações interessadas em adotar o reuso sistemático poderiam optar por incorporá-lo ao seu programa de Melhoria de Processos de Software (MPS) ou tratá-lo como uma iniciativa independente.

No entanto, na implementação de uma SOA, o reuso está no núcleo dos trabalhos. O reuso sistemático não é mais uma opção, mas uma condição crítica para o sucesso de uma iniciativa dessa natureza. Pode-se dizer então que a introdução de uma SOA forçará a adoção de práticas sistemáticas de reutilização de ativos de software. Organizações poderão aproveitar a oportunidade e tornar o reuso um componente fixo de seu programa MPS.

Alto Custo

Edward Yourdon sugeriu uma regra que dizia que um “ativo reutilizável exigirá o dobro do esforço requerido por um ativo comum” . Fred Brooks estima que deve ser “o triplo” do número sugerido por Yourdon . Steve McConnell reconhece que o reuso planejado não é uma prática de curto prazo. “Um programa de reuso pode demorar 2 anos para começar a gerar componentes realmente reutilizáveis”. Mas cita que os ganhos de produtividade podem fazer com que a organização passe a realizar 35 pontos de função (PF) / pessoa / mês, contra uma média nacional que seria de 5 PF / pessoa / mês *.

Os autores de “Practical Software Reuse” colocam o tema de outra forma: “todos os custos com software são sempre considerados um overhead“. “Por isso”, eles continuam, “as avaliações do retorno sobre os investimentos (ROI) em iniciativas de melhorias (seja reuso ou um programa MPS) raramente estão disponíveis e raramente são críveis”. No entanto, “independente da forma como o contabilizemos, reuso é um investimento. E todo investimento envolve incertezas, riscos e ‘chutes'” .

Por tudo isso parece que, sem o envolvimento e o apoio da alta gerência, torna-se quase impossível a implantação de práticas sistemáticas de reuso. E, com certeza, está aqui uma das grandes razões para o fato do reuso nunca ter entregue um mínimo das promessas realizadas nas últimas décadas.

===

Referências:

1. Object Solutions
   Grady Booch
   Addison-Wesley (1996).
2. Practical Software Reuse
   Michel Ezran, Maurizio Moricio e Colin Tully
   Springer (2002).
3. Rapid Development
   Steve McConnell
   Microsoft Press (1996).
4. Strategies for Software Reuse:
   A Principal Component Analysis of Reuse Practices
   (PDF – Requer registro e pagamento)
   Marcus A. Rothenberger et al
   IEEE Transactions on Software Engineering, Vol. 29, No 9, (Set/2003).
5. CMMI Performance Results
   Exemplo de um caso específico (Boeing).
   Carnegie Mellon / Software Engineering Institute (SEI).
6. Adaptação dos Processos do Grupo de Reuso do ISO/IEC 15504-5 para as Áreas de Processo do CMMI (PDF)
   Leandro de Paula Silva
   Monografia de graduação apresentada ao Departamento de Ciência da Computação da Universidade Federal de Lavras (2006).
7. Decline and Fall of the American Programmer
   Edward Yourdon
   Yourdon Press (1992).
8. The Mythical Man-Month – Anniversary Edition
   Fred Brooks
   Addison-Wesley (1995).
   

===

* Ah, como eu gostaria de conhecer, nem que fosse um pouquinho só, os números tupiniquins…

“Criatividade vem dos indivíduos e não das estruturas e processos.”
– Fred Brooks

Mas no primeiro capítulo desta série não tinha uma citação do Peter Drucker dizendo que criatividade (ou inovação) é “uma disciplina sistemática, organizada e rigorosa”? Essa afirmação não bate de frente com a afirmação do Fred Brooks? Não. Elas são complementares. Quem cria é a equipe, os indivíduos que a compõem. Processos e estruturas devem ser desenhados com a clara intenção de facilitar a execução e o gerenciamento do trabalho criativo. Neste capítulo trataremos especificamente da formação e estruturação de uma equipe criativa. Nas duas últimas partes desta série trataremos especificamente dos processos. Encerramos o capítulo anterior perguntando como uma organização pode dar à luz uma equipe criativa.

Projetos desafiadores, aqueles que implicitamente exigem altas doses de criatividade, costumam funcionar como ‘imãs’ para os melhores profissionais. No cenário ideal, pouco plausível no contexto das organizações tradicionais, uma equipe criativa é totalmente formada por profissionais que se alocam de forma espontânea e voluntária. Essa é a realidade na grande maioria dos projetos de Software Livre (open source) e iniciativas similares, como a enciclopédia livre Wikipédia, por exemplo.

Em uma organização que já adote a estruturação por projetos, mesmo que parcialmente, é mais factível tentar a formação de uma equipe de voluntários. Para tal, ela deve tornar público o projeto, seus objetivos e eventuais restrições. O comitê que preparou o ante-projeto pode ser destacado para avaliar os candidatos. Estes deveriam apresentar suas motivações para participar daquele projeto e as habilidades que eles possuem e julgam ser importantes no contexto do empreendimento. Parece ser um bom indicador que pelo menos a metade de uma equipe criativa seja formada por voluntários. Eles desenvolvem um tipo de relacionamento com o projeto, um comprometimento ou até mesmo um sentimento de propriedade, que é muito salutar.

No entanto, ainda é mais comum que as equipes sejam formadas de forma arbitrária. Ou, colocando de outra forma, seus integrantes são indicados ou selecionados por um comitê ou pelo responsável pelo projeto. Neste cenário é desejável que a organização reserve um tempo para que os integrantes se conheçam e compartilhem suas visões acerca do projeto. O entrosamento, o conhecimento mútuo entre todos os integrantes, é uma característica das equipes criativas. Mas é algo que demanda considerável tempo para ser conseguido. Por outro lado, isto não significa que uma equipe de ‘desconhecidos’ não tenha condições de desenvolver um trabalho criativo. Ela tem, mas será mais lenta que uma equipe entrosada e também oferecerá maiores riscos de conflitos entre seus integrantes.

Uma alternativa intermediária para a formação de equipes criativas, que fica entre a alocação voluntária e a arbitrária, é a auto-seleção. A empresa seleciona um representante de cada especialidade requerida no projeto e nomeia-o líder. Cada líder pode optar por indicar ou contratar os outros integrantes de sua célula de trabalho, ou disparar uma convocação por voluntários. A estratégia dependerá do quanto ele conhece os outros profissionais disponíveis que compartilham a mesma área de especialização.

Um componente que pode facilitar o processo de formação de equipes, tanto para a organização quanto para o líder citado acima, são as chamadas Comunidades de Prática (CP). Apesar de seu aspecto informal, é sabido que uma organização pode incentivar e promover sua existência . Uma CP reúne pessoas que trocam experiências, compartilham interesses e conhecimentos. Para um líder, a participação em uma CP pode dar mais subsídios para a convocação ou não de uma pessoa (também participante da CP), além daqueles obtidos através da convivência em um departamento ou em uma série de projetos.

É importante lembrar que a importância das CP’s para uma organização em busca de aprendizado contínuo e criatividade vai muito além da facilitação de um processo de formação de equipes. Enquanto os projetos são finitos e relativamente esporádicos, uma CP é uma entidade e um processo de caráter permanente. A interação de uma equipe de projeto com as diversas CP’s que debatem temas correlatos, mesmo que informalmente e desprovida de compromissos, pode enriquecer o trabalho criativo.

Após a formação da equipe criativa, a organização deve influir muito pouco em sua estrutura. Isto porque se trata de uma estrutura orgânica, que deve se adaptar dependendo do momento do projeto. Uma equipe criativa deve se auto-definir, e saber se adaptar com agilidade. Trata-se de uma característica comum e fundamental das equipes criativas. Um aspecto complementado pelo auto-gerenciamento. Que não descarta a presença de líderes na equipe, muito pelo contrário. E qual é o perfil dos líderes de uma equipe criativa?

===

Próximo capítulo: “Liderando a Equipe Criativa“

Referências:

1. VASCONCELLOS, Paulo.
   Aprendizado Inter-Projetos. Finito – 2004.

A foto que ilustra este capítulo é de Nesster e foi obtida via FlickR.
É Creative Commons, aliás como tudo por aqui.