Porque, nos atos seguintes, trabalhamos pela manutenção daquela estrutura. Não vou negar o que escrevi no artigo anterior: devemos premiar as equipes duradouras. Faltou alertar: desde que tenhamos ciência e antídotos para os riscos que elas representam. 

Um time com estrutura estável tende a ter uma forte coesão interna (bonding). Se essa estrutura for pouco porosa – de poucas trocas com outras equipes (baixo building) – ela se torna um silo. Pois é, uma estrutura moderna – multidisciplinar, autônoma e bem alinhada – está sujeita ao mesmo mal que aflige as unidades funcionais das organizações tradicionais: se transformar num silo que pouco colabora e não raro atua como se fosse o fim e não apenas um meio¹. 

O alto nível de building – de convivência e trocas constantes entre times – é a principal condição para o desenho de uma organização flexível. Se o building é alto, os profissionais vão transitar com mais facilidade entre os diversos times². 

Guildas e Capítulos

Não é por outra razão que não seja a promoção do building a presença de guildas e capítulos no modelo Spotify. Essas formações visam a troca de experiências e conhecimentos. São releituras pouco criativas das Comunidades de Prática, outra ideia elegante, simples e pouco eficaz na promoção de trocas entre times. Essas propostas são fracas para o building porque:

• seus encontros são esporádicos (os ciclos de feedback são longos);
• geralmente envolvem muita gente (12+ é muita gente);
• têm sérias restrições de tempo;
• favorecem temas amplos visando atender o maior número possível de colegas, o que aumenta o risco de papos superficiais e pouco práticos;
• muitos usam os formatos de palestra, aula ou demonstração. Leia-se: há grande risco de tédio, alienação, papos paralelos etc. 

Ou seja, essas estruturas são caras, de difícil implantação e com resultados no mínimo duvidosos. Apesar do início promissor, da motivação natural que vem das coisas novas, esses grupos tendem ao esvaziamento em poucos meses. O building pede por desenhos mais criativos e ambiciosos.

Desenhando o Intercâmbio entre Times

Uma das receitas mais enxutas e promissoras é o Pareamento Promíscuo³ ou Pareamento Cruzado. É simples pra chuchu.

Ingrediente: Um par, sendo cada membro de um time diferente

Modo de uso

1. A dupla se encontra diariamente
2. O encontro dura entre uma e duas horas
   (Claro, a dupla tem autonomia para definir o melhor momento)
3. A cada dia ou semana eles atuam em um dos dois projetos
4. Eles paream, ou seja, trabalham juntos em uma mesma história ou item do backlog
5. Este casamento deve durar pelo menos um mês. E não mais do que dois ou três meses, dependendo da complexidade dos domínios envolvidos.

O trabalho em pares, uma prática essencial da XP (eXtreme Programming), não é uma exclusividade dos desenvolvedores. Designers, analistas e zagueiros também podem trabalhar em duplas. Por que não? Como não?

Preciso me distanciar da ideia para fazer uma avaliação mais isenta. Porque, neste momento, vejo só benefícios: o potencial do olhar de fora para descobrir novas possibilidades; o refresco da troca de contexto; a possibilidade de trabalhar em outro domínio e/ou com outras tecnologias e ferramentas; além, claro, da intenção original da polinização cruzada. Tudo isso a custo zero? Pois é, parece bom demais para ser verdade. O que estou ignorando?

Uma estrutura tão promissora e rica mas não tão econômica quanto a sugerida acima é o Time Plugin⁴.

Ingredientes

• O time Plugin formado por 2+ profissionais que não estejam alocados em nenhum projeto específico.
• Se envolver um processo de onboarding, então os integrantes do Plugin são um tutor (coach não, tutor! – alguém que senta, ensina pareando e entrega) e pelo menos um novato (na organização, não necessariamente na profissão)
• Um time hospedeiro. A equipe ideal deve ter pelo menos uma das seguintes características:
  – Um ou mais membros prestes a sair do time em caráter temporário (férias ou licença programada) ou permanente
  – Código relativamente antigo (2+ anos)
  – Um cliente que há tempo (12+ meses) só demanda mais do mesmo

Modo de Uso

1. Conecte o time Plugin ao time hospedeiro
2. O acoplamento deve ser muito suave. Leia-se: os hábitos e rotinas do time hospedeiro não devem ser alterados
3. O time Plugin pode ou não participar das cerimônias (dailys, retros, reviews etc). A palavra final é do time hospedeiro ou de seu cliente
4. Se o objetivo é uma substituição, então
5. Após 15~30 dias de conexão, espera-se que o membro novato tenha condições de assumir uma posição, qualquer posição, no time principal
6. Isso é possível porque o novato realmente trabalhou naquele projeto, orientado inicialmente pelo tutor e depois por membros do time principal com quem pareou
7. No início da conexão, pelo menos por duas semanas, é indicado que o novato atue exclusivamente em refatoração. Depois, oportunamente, ele pode se aventurar em itens novos ou até mesmo participando de alguns experimentos (spikes).

Casos de Uso

Um time plugin pode oferecer diversas funcionalidades para uma organização:

• Cobertura de férias e licenças.
• Substituição permanente de membros.
• Área de onboarding: região segura onde um novo colaborador pode ser acomodado para entender o que é trabalhar naquela organização (cultura, métodos, ferramentas etc). Neste caso, a estrutura deve ser plugada nos diversos times existentes. Recomenda-se conexões com duração mínima de uma semana. Claro, desde que isso não resulte em meses e meses de onboarding.
• Refatoração Oportunista: todas as refatorações são oportunistas de alguma forma. Aqui a intenção parece ser outra: a cobertura de férias, por exemplo. A usamos como desculpa para dar um belo tapa (por 15 ou 30 dias!) no código. O cliente fica duplamente agradecido: pela manutenção da estrutura do time e pelo código que ganhou um banho de loja a custo zero.
• Spikes Interesseiros: há tempo o cliente não desafia o time principal. O relacionamento caiu na rotina. Há o risco do cliente cancelar ou pedir pela redução do contrato. É chegada a hora do código vendedor. Que o time plugin faça pesquisas e experimentos (spikes) na esperança de descobrir novas oportunidades de negócio para aquele cliente. Esta proatividade tende a render, no mínimo, uma boa surpresa e ótima impressão. 

Quanto maior a rotatividade no time plugin, maior o nível de building alcançado. Quanto ele custa? Cerca de 10% de sua folha de pagamento atual, se houver a intenção de cobrir férias. Não é uma estrutura barata. Por isso é importante que ela seja rica em termos de funcionalidades oferecidas. 

Nada impede que você mantenha as guildas e capítulos enquanto testa as duas sugestões acima. Não há conflito. E você ganha a possibilidade de fazer uma comparação mais objetiva dos benefícios e custos de cada estrutura. Se você o fizer, por favor, não deixe de compartilhar. Os desenhos sugeridos acima foram testados em apenas uma organização. Há outras referências (veja notas abaixo), mas nada substitui a validação no mundo real, com times de verdade. Se você quer conversar mais sobre as ideias e não gosta do formato assíncrono, considere a participação em uma edição da aula sobre Grandes TIMES Pequenos. Se pretende colocar as ideias para rodar e quer alguma orientação, conte comigo.

Notas

1. Um mal muito bem documentado em The Silo Effect, de Gillian Tett (Simon & Schuster, 2016).
2. Bonding (coesão entre membros de um time), Building (desenvolvimento de parcerias com outros times) e Believing (confiança na organização) são os três tipos de Capital Social apresentados por Robert Bruce Shaw em Extreme Teams (Amacom, 2017). A matriz sugerida acima não é de Shaw. Sua elaboração é possível através de pesquisas internas. O building pode ser capturado através de duas perguntas: 1) Com que frequência você aprende coisas com outros times; e 2) Com que frequência você tem a oportunidade de ensinar coisas para membros de outros times.
3. Na versão original, citada por Scott Ambler em Beautiful Teams (O’Reilly, 2009), a promiscuidade é total: os casais são trocados todo santo dia. A diferença é que todos atuam no mesmo produto / projeto. Na versão aqui sugerida os participantes são necessariamente de times diferentes. E o par não é trocado diariamente. Caso contrário, não há building. A versão aqui apresentada recebeu colaborações inestimáveis de Altieres Lopes, Will Marcondes, Klaus Wuestefeld e grande elenco.
4. Pode ser confundido com os times capacitadores (enabling) propostos por Matthew Skelton e Manuel Pais em Team Topologies (IT Revolution Press, 2019). A versão aqui sugerida é um tanto mais ambiciosa em termos de funcionalidades oferecidas.
5. Foto de Karim Ghantous no Unsplash

Que seja eterno enquanto gerar resultados

Que seja eterno enquanto promover relacionamentos saudáveis e inspiradores. Não parece haver uma idade ideal para times. Nem pesquisas minimamente abrangentes sobre o assunto. Seria fácil chutar algo entre um e quatro anos. Dadas a velocidade das mudanças e a reincidência dos timecídios, parecem anacrônicos os times que conseguem sobreviver por mais de doze meses.

Configura-se um timecídio o desmanche de um time que estava gerando valor de facto ou demonstrava potencial para fazê-lo. Além do grande desconforto gerado, para os integrantes do time e para todos que se relacionavam com ele, um timecídio é causa clara e nunca contabilizada de grandes desperdícios. Porque aquele capital social – a coesão interna entre membros do time e as relações de confiança construídas com entes externos – não caiu do céu nem custou barato. E porque, claro, aquele ritmo de entrega de valor foi quebrado e pode demorar para ser retomado. 

Assim como devemos incentivar a cooperação², faz sentido que a gente celebre e até mesmo premie os times longevos. Isso é facilitado quando a empresa se organiza em torno de produtos e não de projetos. 

A Estabilidade Requerida

Nesses tempos líquidos, quanta estabilidade é possível? E quanta estabilidade é desejável? 

Há tempo nos ensinam que a aquisição de novos clientes é seis vezes mais cara do que a manutenção de um. É bem possível que essa conta esteja defasada. Porque, aparentemente, a infidelidade da freguesia só faz aumentar. 

Um time estável tende a aumentar a intimidade da organização com seus clientes e usuários. A confiança aumenta. É um ciclo virtuoso que deve ser motivado. Porque é mais fácil atender um cliente bem conhecido; Porque fica mais difícil perder um cliente bem atendido. Nesses tempos de vacas magérrimas, perder clientes por conta de mau atendimento/entendimento é um luxo só. 

Portanto, se não por outros motivos, a estabilidade de um time é desejável por significar relacionamentos melhores e mais estáveis com clientes. O que é um tanto mais notável e caro, mas não exclusivo, em empresas prestadoras de serviços. 

A Instabilidade Inevitável

Até que ponto as pessoas querem amarrar sua carreira a um produto ou linha de produtos? Quantos, hoje, topariam vincular sua evolução à permanência em uma mesma organização? A infidelidade é regra. E erram feio – feio em mais de um sentido – aqueles que atribuem apenas ao dinheiro a razão para tanta volatilidade. 

Muita gente, conscientemente ou não, busca variedade. Elas querem assuntos, funções e responsabilidades diferentes. Há mais opções supostamente mais atraentes a cada dia. É um mal dos nossos tempos o medo de ficar de fora³. Não será através de chantagens ou doping – os viciantes bônus, prêmios e promoções – que conseguiremos a motivação e consequente lealdade de um time. Ou seja, aquela estabilidade requerida pelas organizações raramente encontrará respaldo nos planos das pessoas. 

Nem sempre foi assim. Nossos pais e avós contam com orgulho a história de uma vida profissional que se desenvolveu em apenas uma ou duas empresas; Em um mundo que não existe mais. Ao  invés de cobrar por uma fidelidade impossível, as organizações precisam ser desenhadas não apenas para acomodar mas para incentivar essa fluidez. 

Como? 

Notas

1. Definição de Zygmunt Bauman, em livro homônimo (Zahar, 2007), para os nossos tempos de extremas incertezas.
2. Em uma das edições da conversa sobre Grandes TIMES Pequenos rolou um debate sobre o uso do termo cooperação em detrimento de colaboração. Opto pelo primeiro desde que aprendi que co-opera, do original em latim, significa comprometimento com o resultado. Co-labora, também do latim, refere-se ao trabalho em equipe, no mesmo local, ombro a ombro – mas não fala sobre resultados. A distinção é bem didática em Six Simple Rules, de Yves Morieux e Peter Tollman (HBR, 2014).
3. Fear of Missing Out, ou FoMO, no original em inglês. Na Wikipédia: https://pt.wikipedia.org/wiki/S%C3%ADndrome_de_FOMO
4. Foto de Devon Janse van Rensburg no Unsplash.

Times de verdade são raros. Times maduros são raríssimos. Tanto mais em uma cultura que ainda não percebeu quanto desperdício e mal estar causa toda vez que desmonta um time ou não dá bola para seu desmanche. Um economista chutador não hesitaria em cravar que os timecídios custam bilhões de dólares anualmente. Ele não estaria errado. Porque é difícil e demorado formar um time de verdade.

Formação: O Parto

Dado um desafio, quase sempre nebuloso e ambíguo, é preciso descobrir e classificar as competências necessárias para vencê-lo. Tentamos simplificar a coisa com profissionais full-stack. Só para relembrar como são mentirosos os atalhos e ineficazes os times de iguais. Cedo ou tarde vamos descobrir que só a variedade de talentos e interesses será capaz de absorver toda a variedade que virá das partes envolvidas.

Esses talentos (o que sabem fazer) e interesses (o que pretendem aprender) precisam se encaixar. A isso chamamos entrosamento. Sabemos que ele não acontecerá do dia para a noite. Desconfiamos que ele pode não acontecer. 

Inventamos divertidos jogos e dinâmicas para team building – para a formação de times. Alimentamos a esperança de que seria possível acelerar com brincadeiras algo que só ocorre quando a conversa é séria. Entrosamento de verdade só é alcançado quando o time resolve conflitos e problemas de verdade. Quando cria confiança. Os jogos, neste momento, não servem para muita coisa além de quebrar o gelo e provocar risadas ou vergonha alheia. 

Só saberemos se aquele time-todo tem potencial para ser maior que a soma das partes jogando-o, o quanto antes, para as feras (aka stakeholders). Todo parto é um choque de realidade. Não há razão para adiar este encontro. Porque só assim o time conhecerá as fronteiras, interfaces e modos que guiarão o seu funcionamento. 

Confrontação: A Infância Difícil

Toda novidade causa estranheza e algum nível de desconforto. Estamos tratando de um grupo de pessoas que foi reunido pela primeira vez e jogado em um contexto diferente. Ainda que o ambiente seja receptivo, haverá desconfiança. Haverá insegurança. E tudo isso é muito normal. Usando aquele raciocínio linear proposto pelo modelo de Tuckman², entramos na etapa de confrontação (storming).

Nosso principal objetivo aqui é reduzir o frio na barriga – é eliminar o grosso das incertezas. Para tanto, precisamos fazer perguntas e testar as respostas em ciclos bem curtos. Estamos tateando no escuro, descobrindo um caminho. Por isso os ciclos rápidos de feedback são cruciais. 

O modelo de Tuckman, cuja versão original é de 1965, não esconde o jeito cascata de pensar. Cabe aqui a observação de que a confrontação (storming) pode ocorrer a todo instante e isso não é necessariamente ruim. Um time em que tudo parece estar funcionando o tempo todo é muito mais preocupante do que um time onde os confrontos são relativamente comuns. 

Este primeiro confronto merece destaque porque é ou deveria ser a única infância de um time. Acontece que cada mínima mudança em sua estrutura significa um novo começo. Justificável ou não, cada troca de membros de um time é quase um reset. Porque afeta todo mundo. 

Normatização: A Confiança Adquirida

Um time se estabiliza quando há confiança compartilhada entre os membros e entre estes, como entidade única, e as demais partes envolvidas. Palavra chave: CONFIANÇA. 

Confiança = (credibilidade * intimidade) / risco

Para entender³:

• Credibilidade: coloco a mão no fogo por fulana/o?
• Intimidade: quão bem a/o conheço?
• Risco: o que pode acontecer se fulana/o pisar na bola?

Confiança de verdade não acontece por decreto nem é garantida por diplomas ou certificados. A única maneira de saber se podemos confiar em alguém é confiando, ensinou Hemingway. Confiança se ganha e se perde no dia a dia. Caramba, estamos cansados de saber disso. Mas, por favor, me siga. Imagine um time com 5 pessoas. 

R = (N (N-1))/2

R é o número de relações possíveis em um time. N é o tamanho do time. Neste caso, temos 10 relacionamentos. São dez relações de confiança que precisam ser cultivadas. Insisto: isso não acontece da noite para o dia.

Pense em todos os membros de seu time atual. Há  quanto tempo vocês estão juntos? Você colocaria a mão no fogo por todos? Quanto tempo demorou para você desenvolver essa (des)confiança? 

Velozes e Curiosos

“É incrível o quanto a gente consegue enxugar – em termos de documentos e processos – quando há confiança mútua.”
– Daryl Kulak e Hong Li⁴

Confiança = Velocidade. Velocidade na tomada de decisões e em resoluções de conflitos. Velocidade dos ciclos de feedback. Velocidade que destaca um time.

Quanto tempo um time demora para atingir essa velocidade, esse nível de confiança? Quanto isso custa? Cada timecídio representa esse custo multiplicado por dois. Porque aquilo que foi descartado deverá ser reconstruído do zero.

Se ser enxuto de verdade significa combater desperdícios, então uma de nossas prioridades deveria ser a redução drástica dos timecídios. Algumas sugestões:

• Enxergar PRODUTOS e não projetos;
• Contratar PESSOAS FÍSICAS COMO PESSOAS FÍSICAS;
• Reconhecer e bonificar O MÉRITO DOS TIMES e não dos indivíduos;
• Incentivar e bonificar a LONGEVIDADE DOS TIMES;
• Ler Peopleware e entender porque burocracia, mau uso do tempo, prazos mentirosos e desleixo com a qualidade são desmotivadores e, consequentemente, causas comuns de timecídios.

Quanto tempo dura um time de verdade? Quanto deveria durar?

Notas

1. Tom DeMarco e Timothy Lister (Dorset House, 1987-2013). Em edição tupiniquim, a tradutora Kátia Aparecida Roque optou por Equipecídio (Makron Books, 1990).
2. https://pt.wikipedia.org/wiki/Modelo_de_Tuckman
3. Surrupiei a fórmula de The Fractal Organization: Creating sustainable organizations with the Viable System Model, de Patrick Hoverstadt (Wiley, 2011).
4. The Journey to Enterprise Agility (Springer, 2017). Veio do mesmo livro a afirmação seguinte, Confiança = Velocidade. Este é o primeiro princípio do Pensamento Sistêmico colocado por Daryl Kulak e Hong Li.
5. Foto de Toa Heftiba no Unsplash

Um time maduro sabe o que quer e se garante. Ele é necessariamente viável – capaz de sobreviver e prosperar de forma autônoma. O que não faz dele uma bolha. Porque um time verdadeiramente maduro sabe que é um sistema aberto e entende que não tem utilidade fora de seu ambiente ou deslocado de seu propósito. Um time de verdade não é apenas reativo – orgânico – na má interpretação dada a essa palavra. Um time maduro exerce influência e coevolui com seu meio. Ele experimenta, aprende e propõe mudanças. Um time maduro não copia, rouba.

Grandes Times Roubam

Pablo Picasso: “Bons artistas copiam, grandes artistas roubam”. Eles não roubam o produto final, a obra prima. Isso dá cadeia e não tem graça nenhuma. Assim como não tem graça chamar times de squads porque isso parece moderno ou bonitinho. Esquadrão nunca foi um sinônimo simpático para TIME. 

Grandes times, assim como os grandes artistas, roubam a inspiração que levou àquela obra ou produto. Chamar time de squad é só perfumaria. Aliás, a cópia do modelo Spotify entra no rol dos problemas que causamos porque estávamos apressados demais para acionar o nosso senso crítico². Os chapters e guildas – outros termos vendedores porque diferentes – nada mais são do que releituras das antigas Comunidades de Prática³. Pequenas adaptações que foram apresentadas de forma a justificar ou disfarçar uma organização matricial⁴. Quem copia sabe que o modelo não funcionou nem no Spotify?

Escalar a agilidade – um dos objetivos originais do modelo Spotify – é um problema que já mereceu zilhões de palavras escritas e algumas berradas. Não tenho a menor pretensão de apresentar uma visão alternativa. Até porque nunca fui além de alguns poucos times e dezenas de pessoas sob minha responsabilidade. Entretanto, depois de trinta e tantos anos de carreira, posso falar sobre times maduros e suas ideias roubadas.

Por  Exemplo

Guildas e chapters são soluções para qual ou quais  problemas? O assunto me é particularmente caro porque ele justificou a criação deste finito há dezesseis anos. Criei este espaço para desenvolver e apresentar um trabalho sobre o Aprendizado inter-projetos. Em suma:

• Como fazer com que os times troquem experiências e evitem a reincidência de erros e problemas?
• É possível promover uma evolução homogênea dos times ao mesmo tempo em que lhes é oferecida a máxima autonomia?

As comunidades de prática e todas as suas versões pós-modernas – guildas, chapters etc – correm o mesmo risco. Passado o entusiasmo inicial, muito rapidamente elas podem ficar irrelevantes e vazias. Há um motivo bem quente para isso: o inferno nosso de cada dia. A correria tende a matar tudo o que não tenha aplicação imediata, promissora e barata. 

Na melhor versão dessas comunidades a participação é voluntária. O que tende a aumentar o interesse e a qualidade das conversas. No entanto, a participação é voluntária… Já me deparei com gente que deixou de ir aos encontros quinzenais por medo de ser percebido como alguém com a agenda folgada.

Conclusão: esses mecanismos de incentivo ao aprendizado são elegantes e cheios de boas intenções. O problema é que raramente encontram um ambiente que os favoreça. Insistimos em variações da mesma ideia desde o início dos anos 1990. Chamar encontros ou reuniões de lean coffee e ser generoso nos comes e bebes não adiantou muita coisa. Passa da hora de tentarmos coisas diferentes.

Por exemplo: 

• Pense em uma dupla ou time que você pode plugar em um time fixo de forma a oferecer funcionalidades adicionais por um certo período. 
• Pode oferecer, por exemplo, o necessário olhar de gente “de fora” em busca de oportunidades de melhoria. Se estamos falando de um time de desenvolvimento de software, temos aqui um plugin para a Refatoração Oportunista. Além do potencial ganho de qualidade, podemos esperar:
  • Polinização cruzada – difusão mais rápida e ampla de conhecimentos
  • Mais gente com condições de participar daquele projeto/produto
  • Treinamento com a finalidade de cobrir férias, licenças ou qualquer outra ausência minimamente previsível
• Na correria do dia a dia, quantos times têm tempo e recursos para fazer pesquisas e experiências? Falando novamente de software, quantos spikes em média os times realizam a cada sprint? Um time plugável pode oferecer tal possibilidade sem comprometer o que já foi combinado com clientes e usuários. 
• Em um prestador de serviços, esses spikes podem ser utilizados para a descoberta de novas oportunidades de negócio. Se tornam Spikes Interesseiros. Criam argumentos de vendas que vão muito além do blablablá “somos ágeis f*ckin’ black belt acreditados pra chuchu etc”.
• Pense nisso: times livres e plugáveis, sem formação ou propósito fixos, podem fortalecer os times fixos ao mesmo tempo em que promovem a troca de conhecimentos e experiências. Com a mão na massa, não em auditórios ou cafés.
• Por fim, mas não menos importante: os times livres parecem ser bastante adequados para os processos de on-boarding, para a acolhida e preparação de novos colaboradores.

Um time ou organização exala maturidade ao explorar alternativas e criar soluções. Os exemplos acima não sanam todas as questões colocadas. Não era essa a intenção. Assim como a originalidade absoluta não é meta de ninguém, nem dos artistas mais picassos. Porque ela, a originalidade total, não existe. Já a maturidade, seja de um time ou organização, não só existe como é fácil de ser percebida.

Assim como é fácil de ser destruída. DeMarco e Lister⁵ criaram até um nome para isso: Timecídio. Tema do próximo post. Até lá!

Notas

1. Trecho da música Selvagem dos Paralamas do Sucesso (Selvagem?, 1986).
2. Há tempo sapateamos nessa calçada infame. Em 1970, por exemplo,  interpretamos muito mal um artigo de Winston W. Royce e glorificamos o modelo Waterfall. Agora, apesar dos inúmeros avisos (compilados neste artigo, em inglês), fizemos o mesmo com o modelo Spotify.
3. https://pt.wikipedia.org/wiki/Comunidade_de_pr%C3%A1tica
4. https://pt.wikipedia.org/wiki/Departamentaliza%C3%A7%C3%A3o_matricial
5. Peopleware: Productive Projects and Teams (Dorset House, 1987|2013).
6. Foto de Anna Samoylova no Unsplash

De Verdade

“De verdade” se tornou um sobrenome necessário porque vulgarizamos a palavra “time”. Qualquer grupo de pessoas é tratado como time. Não é bem assim. 

O primeiro requisito crucial para a formação e identificação de um time é um objetivo. Apesar de seus diversos interesses – e é importante que um time seja formado por pessoas com interesses diversos¹ – os integrantes do time compram a mesma briga. Isso não se dá de imediato. Em um mundo cada vez mais complexo, objetivos quase nunca são cristalinos nem unânimes. A definição do problema – do objetivo – é parte do problema. E é o primeiro passo para a formação de um time. 

Buscamos a cooperação – o pleno acordo em relação aos fins e aos meios para alcançá-los. Mas sabemos que a competição, agora e em outros momentos da iniciativa, é mais que necessária. Porque só assim podemos explorar a melhor maneira de realizar aquele objetivo. Da matriz ao lado, o único quadrante que deve incomodar, ainda mais quando recorrente, é o conflito. Os demais fazem parte do dia a dia de um time saudável².

Um time de verdade não se caracteriza apenas por buscar e alcançar os objetivos – por realizar resultados. Isso um bando (pseudo-time) consegue fazer, mesmo que de vez em quando. Em times de verdade há relacionamentos saudáveis e motivadores. Ou seja, nesta matriz, apenas um quadrante nos interessa. Não queremos estar em alianças temporárias – onde todos os comparsas se dão muito bem e entregam muito mal – e muito menos em celas.

Por entregar resultados enquanto nutre bons relacionamentos, um time de verdade tende a desenvolver uma identidade única. Às vezes ele ganha até nome, marca e mascote. No entanto, a identidade que interessa – a que fica – geralmente é a sua principal característica: entregador, cascudo, corajoso, atencioso, maduro e por aí vai. 

Este é o primeiro CDP (Core Design Principle) ou Princípio Fundamental para o desenho de times: Forte identidade e senso de propósito. 

Princípios Fundamentais

Elinor Ostrom³, Nobel de Economia em 2009, encontrou em um conjunto com oito princípios uma resposta para a Tragédia dos Comuns⁴. Estamos começando a descobrir que esses princípios podem explicar a diferença entre times bem e mal sucedidos⁵. Um time aumenta suas chances de sucesso se:

1. Desenvolver uma forte identidade e senso de propósito
2. For justo no rateio de benefícios e custos
3. Tomar decisões de forma justa e inclusiva
4. Monitorar o comportamento que foi acordado de antemão
5. Aplicar sanções progressivas 
6. Sanar conflitos de maneira rápida e justa
7. Contar com autonomia local
8. Tiver a garantia de que todos os demais times e níveis da organização utilizam os mesmos princípios de governança listados acima

Cada princípio será detalhado oportunamente⁶. Neste momento é interessante destacar o seguinte: Os princípios 1~6 tratam das questões internas de um time; os princípios 7 e 8 tratam da relação do time com a organização e demais equipes. 

Releia a lista de princípios fundamentais com calma, por favor. É importante.
Obrigado.

Repare como o CDP#7 – contar com autonomia local – é chave. Porque é o grau de autonomia conquistado pelo time que vai guiar a configuração de todos os CDPs anteriores. Autonomia não é carta branca. A auto-organização não acontece quando fronteiras não são definidas. Ou seja, a organização propõe ou impõe limites. A partir deles, cada time desenvolve sua própria cultura – seu jeito de fazer as coisas. 

Existem três fatores principais delimitando o grau de autonomia que será oferecido aos times. O primeiro é subjetivo: confiança. Cabe aqui um pitaco direto de Hemingway: “Só há uma maneira de saber se você pode confiar em uma pessoa: confiando nela.” Se vale pra gente, vale para times.

Os outros dois fatores são objetivos: as necessidades de integração e padronização da organização. O grau de autonomia possível é inversamente proporcional à essas necessidades. Considere, por exemplo, quanta autonomia há em uma agência bancária. Ou até onde vai a liberdade de um squad do Spotify ou de um time do Google para escolher ou criar as suas próprias ferramentas. 

Um time de verdade sabe de cor e salteado o que busca. Ou seja, seu alinhamento é total. Ele estará no quadrante A ou B da matriz ao lado, dependendo da cultura e das necessidades da organização. Que fique claro: um time de verdade sempre persegue o espaço A. Porque é sinceramente comprometido com a melhoria contínua. Mas ele compreende e aceita eventuais restrições. 

Um time de verdade exala maturidade. Tema do próximo post. Até lá!

Notas

1. Porque, como já vimos, “só a variedade absorve variedade”.
2. O modelo de (Bruce) Tuckman, de 1965, se equivoca ao fixar o estágio Storming (confrontação) como o segundo de um total de cinco que caracterizariam o ciclo de vida de um time. As tempestades são relativamente frequentes e isso não é necessariamente ruim nem indesejável em um time saudável. Sobre o modelo: https://pt.wikipedia.org/wiki/Modelo_de_Tuckman
3. https://pt.wikipedia.org/wiki/Elinor_Ostrom
   Ela também nos presenteou com a Lei de Ostrom: “um arranjo de recursos que funciona na prática pode funcionar na teoria”.
4. https://pt.wikipedia.org/wiki/Trag%C3%A9dia_dos_comuns
5. David Sloan Wilson em This View of Life: Completing the Darwinian Revolution (Patheon, 2019) e Herb Bowie no artigo Agile Software Development and the Core Design Principles for Teams.
6. Converso sobre todos eles na aula Grandes TIMES Pequenos.
7. Foto de Shane Rounce no Unsplash

Não entendo como eles podem tocar tantos projetos simultaneamente. E, considerando que essas empresas contam com algumas dezenas de AN’s, não entendo como elas conseguem disparar e cuidar de tantas iniciativas.

O burburinho vira debate quando emendo uma segunda recomendação: AN’s deveriam trabalhar sempre em duplas. Uma rápida conta de padaria, que tanto caracteriza a matemática dos novos tempos, deve deixar todos aturdidos: “Hoje tenho 100 projetos e 10 AN’s. Você está sugerindo que eu contrate 190 analistas?!?” Isso sim seria uma bela política para geração de (bons) empregos. Mas reconheço sua inviabilidade.

É fato que a sobrecarga insana de trabalho não é um privilégio dos AN’s. Infelizmente, é outra característica do século XXI. Mas ninguém deveria aceitar isso como um fato consumado e pronto. No caso específico dos AN’s não é difícil descobrir e tentar corrigir as razões de tanto trabalho¹.

Em primeiro lugar é preciso dizer que nenhuma empresa tem tantos projetos assim. Projetos, com ‘P’ maiúsculo, devem representar apenas algo entre 10% e 20% de toda a demanda. O restante trata de alterações ou evoluções em soluções existentes, nos famigerados sistemas legados. E por que as empresas estariam utilizando analistas de negócios para cuidar de solicitações de manutenção em aplicações?

Uma desculpa razoável seria a competência desses profissionais para o desenvolvimento de requisitos. O que muitas organizações não entendem é que não existem, na grande maioria dessas solicitações, requisitos. Não no sentido de existirem necessidades verdes o suficiente para justificar todo o processo de maturação intrínseco à Análise de Negócios. Noventa e tantos por cento das novas necessidades dos usuários são simples e diretas, como por exemplo: “coloca um novo campo assim nesta tela”. Gastar AN’s com solicitações dessa natureza é um belo desperdício.

Sabe-se lá por que cargas d’água inventaram um novo nome para atendentes de help-desk. Sim, porque solicitações de manutenção deveriam ficar no âmbito daquele grupo que um dia batizamos “help desk”.

Ouço de algumas empresas que parte das solicitações tem real necessidade de Análise do Negócio. Ok, mas quantas? Duvido que sejam 10% delas. E insisto: é desperdício. Mas entendo: começaram a colocar AN’s para desempenhar essa função na vã esperança de melhorar um cadinho a qualidade do atendimento. Acontece que a solução virou um tiro de bazuca no pezão: AN’s estão aprendendo a desenvolver um monte de coisa. Leem o BABoK ou participam do FAN e absorvem dezenas de ferramentas que podem tornar seu dia a dia menos desagradável. Pena que sejam coisas que agregam muito pouco ou nada quando o trampo é só de manutenção de sistemas. Pior: são coisas que custam tempo e dinheiro.

Uma grande, imensa empresa tupiniquim se prepara para experimentar um novo desenho. Deve instituir a figura dos Analistas de Demandas ou algo parecido. Seria o meio termo entre analistas de negócios e atendentes de help-desk. Não sei se a solução não deveria ser simplesmente uma melhor preparação do pessoal de suporte. Uma preparação que passasse obrigatoriamente pela especialização. Por exemplo: o cara que atende chamados sobre impressoras não pode ser o mesmo que recebe solicitações para o SAP/R3. Parece óbvio, mas não é tanto assim em alguns lugares que conheço.

Não há processo ou ferramenta que substitua um simples “Não!”

Um segundo fator que contribui muito para a sobrecarga de AN’s é a incapacidade que algumas organizações têm de falar “Não”. Em tempos de nervos à flor da pele, competição interna sanguinolenta, políticas demasiadamente corretas e grave miopia onde deveria existir só *Visão*,  a impressão que fica é que todas as demandas e projetos são prioritários, vitais e pra ontem. Uma peneirinha meio esburacada já ajudaria muito. Gastamos tanto com soluções para gestão de portfólios, PMO’s e afins, e seguimos sem a mínima capacidade de dizer qual projeto merece mais atenção e recursos. Enquanto uma organização não aprender a colocar suas iniciativas e demandas em uma fila indiana (uma atrás da outra, sem exceção) ela seguirá com a sensação de sempre ter mais trabalho do que recursos disponíveis para executá-lo².

Justificando as Sugestões

“Que tal sugerir que cada dupla de AN’s tenha um mordomo ao seu dispor?” Já ouvi algo parecido, de um colega que interpretou de maneira um tanto precipitada minhas sugestões. Não defendo sombra e água fresca para AN’s. Apenas insisto que eles não conseguirão provar seu valor se: i) Trabalharem em mais de um projeto (ou dois projetos pequenos); e ii) Não trabalharem em duplas. Por favor, me permita justificar.

Defendo que todo projeto de software seja desenvolvido seguindo um modelo Iterativo e Incremental. Deve estar implícita nesta sugestão a necessidade dos AN’s permanecerem no projeto do primeiro até o último dia. E, a menos que o projeto seja pequenininho, é impossível que os AN’s cuidem (bem) de mais de um. Repito: impossível.

Pense nas principais tarefas desempenhadas por um AN: entender um negócio e determinado problema ou oportunidade; e entender o usuário, suas necessidades e restrições. Ambos “entendimentos” ocorrem simultaneamente, em diversas situações. Vamos simplificar e usar o modo mais corriqueiro: o AN entrevistando um usuário. Ele deve prestar atenção em seu interlocutor e conduzir a entrevista. O “olho no olho” é importante, assim como a leitura de sinais, caretas e tiques. A explicitação da conversa, seu registro na forma de diagramas, especificações de casos de uso etc, é igualmente importante. E demanda a mesma fatia de atenção. Como um AN pode desempenhar bem, simultaneamente, duas funções tão distintas?³

Já experimentei de tudo para substituir a explicitação anotada: gravação de áudio, vídeo etc. Nada substitui uma segunda cabeça. Ao término de uma entrevista, no momento da análise dos requisitos aprendidos, ela completa o entendimento, ajuda a destacar pontos obscuros e dúvidas. Enfim, duas cabeças sempre serão melhor que uma.

Outra justificativa para o uso de duplas é o melhor aproveitamento das habilidades de cada um. Tem analista que parece ter nascido para a socialização: é bom de papo, transmite segurança e sabe lidar com usuários e clientes. Outros são talentosos na redação e desenho. É relativamente raro encontrar um AN que faça muito bem as duas coisas. Como é impossível que ele faça bem as duas coisas simultaneamente, por que não equipá-lo com seu par ideal?

Eu sei, a implementação dessas sugestões tem que entrar na fila. As empresas que pretendem obter o máximo da Análise de Negócios devem ter outras prioridades: i) Aprender a dizer “Não!”; ii) Colocar os projetos em fila indiana; e iii) Separar o hoje (operação) do amanhã (projetos). E não é que a Análise de Negócios pode ajudá-las até nisso? Bom, acabei de arrumar mais areia para os abarrotados caminhõezinhos dos AN’s. Inté!

.:.

Observações:

1. Eu quis dizer que a identificação dos problemas é fácil. Sua solução, nem tanto.
2. Perguntinha retórica mas necessária: capacity planning só vale para máquinas?
3. Vira e mexe me deparo com uma solução curiosa: o AN diz que anota tudo rapidinho, priorizando o contato “olho no olho” com o usuário ou cliente. Depois volta para casa e “passa tudo a limpo”, inclusive escrevendo os casos de uso. Esforço total: 4 horas, por exemplo. Se ele tivesse um par que o isentasse da anotação, ciente de que “passar a limpo” é desperdício e que especificações de casos de uso são construídas na frente do usuário, consumiria as mesmas 4 horas.
4. A imagem utilizada, “Colorful toy trucks parked in a circle“ é de Horia Varlan e foi obtida no Flickr.

Perdão Bilac, mas não resisti. Não é a primeira vez que surrupio belas obras com fins questionáveis. Certo não será a última. A espoleta da vez não veio de TI, mas de um mundo tão distante quanto Pandora está da Terra: veio da bola, do pé na bola, do futebol. É a Copa que se aproxima. Mas não deveria ser. O futebol é algo tão rico de ensinamentos que merecia outro status e mais presença. Pena, ele segue em outra direção. E acaba de perder um de seus melhores tradutores, Sr. Armando Nogueira. Pena. Mas voltemos ao princípio: “Ora (direis) Gerir Estrelas!”

“Certo perdeste o senso!” Porque, se há algo difícil de gerenciar, é a tal da estrela. Dá de mil e um no pior dos piores projetos. Dá de mil e dois no pior dos piores fregueses. Estrela, como o Flamengo está aprendendo da pior maneira, está sempre acima da gerência. Não apenas na grana depositada mensalmente, mas em praticamente tudo.

É certo que estrelas de verdade brilham. Adriano foi o artilheiro do último campeonato brasileiro. Sem ele provavelmente o Hexacampeonato não teria acontecido. Em outra nação, a Corinthiana, Ronaldo decidiu, no primeiro semestre de 2009, uma série de partidas importantes. Sem ele o Timão não teria conquistado dois campeonatos. Benefícios assim costumam fazer com que os custos sejam tratados como pequenos detalhes, bobeirinhas. Perdão, mas são pouquíssimos no mundo que podem tratar um milhão de qualquer coisa por mês como um pequeno detalhe. No Brasil, talvez o Batista e mais dois. E olhe lá!

O custo (exorbitante) de uma estrela é fixo. Seus resultados variam mais que bolsa de valores em tempos de crise. O que permite concluir que, em médio e longo prazos, uma estrela nunca se paga. Ok, “nunca diga nunca”. Então fechamos com “quase nunca se paga”.

Defina “Estrela”

Estrela é o craque, o expert, o bambambam em determinada área do conhecimento. Domina como poucos sua arte. Quando brilha, o faz de forma tão intensa que cega, maravilha e entorpece.

Se a definição se limitasse ao que foi escrito acima este artigo não teria razão de existir. Acontece que uma estrela é apaixonada pelo próprio umbigo. Se acha tão acima dos normais que acaba criando um universo só seu. Heliocêntrico, é claro. Tem seus próprios processos e regras. Seus próprios horários e calendários. E ai de quem discordar.

Talvez só o futebol rivalize com TI no número de pessoas que recebem, de forma pejorativa ou não, apelidos como “deus”, “rei”, “gênio”, “monstro”, “fenômeno” etc. Mas há ESTRELAS e estrelas. Existem as anãs e as pagãs, as supernovas e os buracos negros. Supernovas, por exemplo, berram por “autogerenciamento” mas não conseguem botar ordem na própria mesa. Já os buracos negros sugam toda a energia (e recursos) ao seu redor – são mal humorados de nascença – e costumam sumir antes que algum resultado seja entregue.

Em comum todos os (nossos) tipos de estrelas só apresentam dois fatores: i) normalmente são realmente bons no que fazem;  mas, ii) são difíceis, chatos, desagradáveis etc etc etc.

Seu Projeto depende de uma Estrela?

Meus pêsames. Ops… perdão. Não são raros, particularmente numa área tão nova, dinâmica e mal formada como TI, projetos que dependam muito da atuação de um craque. E é importante notar que nem todo craque é estrela. É claro que existem os humildes e mortais – que se caracterizam principalmente pelo tanto que são cientes de suas próprias limitações. Traduzindo: craques sabem dizer “NÃO”, “NÃO SEI” e também nunca apresentam estimativas absolutas. Mas você não deu a sorte de contratar um craque. Tens uma estrela em suas mãos. E agora?

Só tenho duas dicas:

1. Não crie a ilusão de um relacionamento duradouro. Contrate a estrela especificamente para um projeto. E faça girar em torno dela um ou dois planetas (funcionários de sua confiança) que tenham: i) estômago forte; ii) vontade de aprender.
2. Vincule todo e qualquer pagamento à entrega de resultados. Faça com que a estrela se comprometa realmente com o sucesso do projeto. Desconheço outra maneira que não seja através do zelo extremo com os desembolsos e reembolsos.

Seu Gerente é a Estrela?

Hmmm… Mas que situação, hem? Não prestou atenção na hora da entrevista não? Ok, pode não ser o fim do mundo. Considere uma das alternativas abaixo:

1. Trocar de emprego;
2. Tomar o lugar do gerente;
3. Ajudar alguém (gente boa) a tomar o lugar do gerente;
4. Convencer o gerente que ele será mais importante, mais bem visto, mais sexy e bem sucedido se começar a trabalhar para a equipe, esquecendo o comportamento “comando & controle” e aprendendo que a “delegação de poderes” o fortalece e não o contrário. Pode garantir que, se ele aceitar tudo isso, será convidado para todos os happy-hours e churrascos da turma.

Você é a Estrela?

Desculpa aí. Não é nada pessoal não, viu gente fina?

Inté!

.:.

Slinky Abstract, a foto utilizada este artigo, é de Paul Stevenson.

When solving problems, diversity may matter as much as, or even more than, individual ability.

– Scott Page (professor na Universidade de Michigan e autor de “The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools and Society“).

Meme achado-forçado, que ajuda no debate sobre ‘Especialistas Generalistas’.

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.

“Especialização é para insetos!”. O romântico manifesto de Heinlein, em mãos erradas, pode causar um estrago e tanto. Vou surrupiar a réplica de alguém que não tem nada a ver com sci-fi, Peter Drucker :

… conhecimento, por definição, é especializado. Com efeito, as pessoas realmente detentoras de conhecimentos tendem ao excesso de especialização, qualquer que seja seu campo de atuação, exatamente porque sempre se deparam com muito mais a aprender.

A organização baseada em informações exige, em geral, muito mais especialistas do que as empresas tradicionais do tipo comando e controle.

Mixando os dois autores podemos concluir que as empresas baseadas em informações são verdadeiras colméias ou formigueiros, certo? A analogia é interessante, mas não vou brincar com metáforas. Como eu disse em um rendiconti, meu problema é com os ‘especialistas generalistas’. Lá eu disse que um melhor termo seria ‘especialistas não-alienados’: i) Profissionais que reconhecem e respeitam as outras especializações; ii) estão comprometidos com os objetivos do negócio (do projeto); e iii) sabem trabalhar em equipe. Acho que isso não deveria ser um diferencial – em lugar nenhum. É pré-req em qualquer profissão, não?

Mas a tese de Mr Ambler vai um pouco além. Para ele, ‘reconhecer’ as outras especializações é conhecê-las de fato. Ele chega a sugerir a seguinte trilha de evolução (é só um exemplo fictício, ele diz):

Não tenho nada contra um profissional buscar outras áreas de conhecimento. Muito pelo contrário. Mas a evolução acima é possível? Se Java, .Net, tecnologias de bancos de dados, metodologias de gerenciamento de projetos e de modelagem fossem congeladas – parassem de mudar e de evoluir, talvez. Mas, definitivamente, não é esse o caso. Alguém que tenha parado de estudar Java há 3 anos seria considerado um especialista hoje? Algumas das áreas de conhecimento citadas por Ambler se entrelaçam. É natural que o especialista em uma delas seja também muito bom em outra. Java e modelagem, por exemplo. Aliás, dependendo da ferramenta, trata-se de uma tarefa só. Um melhor exemplo talvez seja Java e testes, ou Java e deployment. Btw, neste último quesito, muita gente fica devendo. Mas essa é outra história.

O maior problema com a tese, em minha opinião, é a forma como ela desconsidera a dinâmica que vivemos. Alguém que tenha aprendido Cobol lá nos anos 80 até que poderia se dar bem hoje, com um mínimo de esforço de atualização. Podemos dizer o mesmo em relação ao VB ou Java, por exemplo?

O fato é que, para ser um especialista hoje em dia, gasta-se muito tempo. As plataformas tecnológicas cresceram muito, para os lados e para cima. A complexidade dos ambientes aumentou exponencialmente. E, pior, ainda são relativamente imaturas. Ou seja, mesmo que o cara não durma e seja um mestre em ‘leitura dinâmica’, é difícil se manter um especialista. O que dizer então de um ‘especialista generalista’ conforme proposto por Ambler? Só se ele já estiver contemplando o uso de um plug como o do Neo em Matrix.

O post ficou longo e, como eu previa, receberá uma seqüência. Quero colocar a questão dos ‘especialistas generalistas’ no contexto dos projetos. Tirando o lado individual, que procurei destacar aqui, trata-se do maior risco. Equipes multi-disciplinares viraram, em alguns lugares, equipes de profissionais multi-disciplinares.

Sei que a maior parte dos colegas defensores da tese do Ambler são muito bem intencionados. Juan Bernabó, por exemplo, apresenta-a de uma forma muito legal. Mas, infelizmente, não consigo ignorar um tom meio ‘facista’ de alguns. Me desculpem o termo – mas é assim que interpreto. Quando falam de ‘super-desenvolvedores’ que sabem fazer tudo no projeto, e ainda se auto-gerenciam… Sei lá, parece que querem dizer: “o mundo é nosso”. Aliás, achar que dá para ser bom demais em tudo é uma baita falta de respeito com outros especialistas. Mas esse papo fica para a próxima semana.

1. O Advento da Nova Organização
   Peter F. Drucker. Artigo publicado originalmente na edição de jan-fev/88 da Harvard Business Review. Republicado no livro “Gestão do Conhecimento – HBR”, da Editora Campus (2001).