finito

Tag: Refatoração

  • Times Líquidos, Parte 2

    Times Líquidos, Parte 2

    Como uma organização pode promover fluidez entre seus times sem comprometer a coesão interna das equipes, as relações com clientes, a qualidade e o ritmo das entregas? O post anterior tentou explicar a motivação para este movimento. É hora de conversar sobre como ele pode ser feito.Que o profissional possa conhecer todas as alternativas e escolher o projeto, processo ou produto onde trabalhar é requisito tanto óbvio quanto raro, particularmente em terras tupiniquins. Normalmente contratamos para uma posição pré-determinada. Quase sempre para apagar incêndios. A inexistência de testes – de um onboarding minimamente planejado – explica boa parte dos problemas que testemunhamos desde sempre. Essa mentalidade mecanicista – a peça que deve porque deve se encaixar em dado mecanismo – tem poucas chances de sucesso em trabalhos criativos. E este é só o começo da história.

    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 Plugin4.

    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
  • Times Líquidos, Parte 2

    Times Líquidos, Parte 2

    Como uma organização pode promover fluidez entre seus times sem comprometer a coesão interna das equipes, as relações com clientes, a qualidade e o ritmo das entregas? O post anterior tentou explicar a motivação para este movimento. É hora de conversar sobre como ele pode ser feito.Que o profissional possa conhecer todas as alternativas e escolher o projeto, processo ou produto onde trabalhar é requisito tanto óbvio quanto raro, particularmente em terras tupiniquins. Normalmente contratamos para uma posição pré-determinada. Quase sempre para apagar incêndios. A inexistência de testes – de um onboarding minimamente planejado – explica boa parte dos problemas que testemunhamos desde sempre. Essa mentalidade mecanicista – a peça que deve porque deve se encaixar em dado mecanismo – tem poucas chances de sucesso em trabalhos criativos. E este é só o começo da história.

    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 Plugin4.

    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
  • Grandes Times Maduros

    Grandes Times Maduros

    Encerrei o post anterior afirmando que um time de verdade exala maturidade. Não porque algum cartório garante isso através de um caro certificado, longe disso. Acontece que é fácil distinguir um time maduro. Tanto quanto é relativamente simples identificar uma pessoa madura. Basta a convivência por algum tempo. Um time, assim como uma pessoa madura, tem forte presença / identidade, autoconhecimento e “a esperteza que só tem quem está cansado de apanhar”¹. 

    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 matricial4. 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 Lister5 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