Memes, originalmente introduzido por Richard Dawkins no livro The Selfish Gene, são genes culturais; ideias que se propagam entre as pessoas e afetam a nossa forma de pensar e agir. Julian Everett sugeriu que podemos olhar as práticas de desenvolvimento de software, ideias e cultura como uma coleção de memes. Ao fazer isso, nosso entendimento sobre o que funciona e porque pode ser ativado em nossa cabeça. Questões como "Os projetos de TI são a forma correta para aumentar o valor do negócio para uma organização?" e "Será que a ideia de XP sobre atendimento no cliente está errada?" são levantadas e nos levam à respostas surpreendentes.
Julian começa descrevendo o ciclo de vida do meme:
1) Duvidosamente: resultado de um problema não resolvido ou um fenômeno que não se encaixa dentro de nossa visão do mundo atual.
2)(bio)diversidade: uma série de novas ideias são então consideradas como possíveis soluções ou maneiras de integrar a nova experiência em nossa visão do mundo.
3) Meme Dominante: uma ideia particular é adotada como a “melhor” explicação/solução e torna-se incorporada dentro da visão do mundo atualizado.
4) Meme Zumbi: mudança de contexto social ou de negócio, tornando o meme que anteriormente era dominante a não relevante. Agora está “morto” e precisa começar a descansar antes de começar a causar estrago.
5) Meme Lázaro: uma ideia morta que é trazida de volta a vida, porque as mudanças de contexto social ou de negócio tornam-se relevantes novamente.
Em seguida Julian descreve como este ciclo de vida do meme pode ser visto no negócio:
Dentro do contexto de negócio, os memes podem ser vistos como o DNA do pool de ideias de uma organização que se expressa como um “fenótipo extendido” ou uma escala de efeitos: estratégia comercial para orçamentos, marketing, projetos de TI, etc.
Se considerarmos o subconjunto de memes que constituem MMFs bem fatorada [A minimum marketable feature (mmf) é o menor conjunto possível de funcionalidades que, por si só, tem valor no mercado. Você poderia lançar seu software com apenas uma dessas funcionalidades e você veria algum benefício.], então as opções reais são o mecanismo para determinar quais memes organizacionais deveriam ser expressados e quando devem ser expressados (via o exercício do ponto ideal) e, igualmente importante quais memes precisam ser removidos (via avaliação negativa).
Zumbis são as coisas que causam os estragos reais: financeiramente é evidente que estamos vivendo nesse momento, a queda de um meme zumbi econômico– a hipótese eficiente de mercado (que resultou na desregulamentação de mercados capitais, etc). Mais perto de casa, alguns dos piores problemas que tenho visto causado por programas de tecnologia tem resultado em “projetos zumbi”, onde há uma resistência para terminar apesar de claramente mudada as condições de negócio e comerciais que já não se adicionam…
Agora, se fôssemos olhar para as unidades de valores de negócio como um MMF, então a ideia de Projetos de TI tornam-se arcaicas e inúteis:
A teoria evolucionária mudou o foco de pensamento biológico de organismos de genes. Da mesma forma, uma perspectiva evolucionária para a entrega de software enfatiza a necessidade de parar de focar em projetos de TI e começar a pensar unicamente em termos de MMFs. Então as organizações com alta liquidez de recursos tornam-se criadouros de caçadores de business value onde os times são continuamente reimplantados em qualquer parte da empresa que tem o valor elevado do MMFs a serem implementados.
Julian também aponta e "coloca fogo" na noção XP, de um cliente olhar para a prática como um meme:
Vamos pegar o exemplo do Cliente XP novamente. Eu iria (contenciosamente) sugerir uma razão pela qual o meme se espalhou pelo ambiente da indústria de software foi porque a maioria das pessoas que formularam o XP eram consultores de algum tipo. Ex. Clientes XP eram também seus clientes no sentido real, financeiro. Em outras palavras, a realidade econômica do fitness landscape favoreceu uma definição de cliente informado pelo "sucesso do projeto", mas este sucesso era do consultor ao invés de ser do cliente. E como um consultor de TI, qual é a melhor forma de assegurar seu pagamento? O velho meme foi "on-time, on-budget" usado como um veículo de tarifação padrão, mas que então foi substituído pelo mesmo ajuste de noção do cliente XP feliz e "onisciente". Totalmente compreensível, porque como o consultor não quer ter uma dependência financeira sobre o cliente com uma estratégia comercial mais ampla possivelmente instável (daí as dificuldades com a definição do contrato ágil). Entretanto a partir de uma perspectiva do cliente, a satisfação do stakeholder é em grande parte irrelevante na figura como um todo - isso é puramente estratégia comercial e entrega de ROI a longo prazo.
Este é um modelo atraente que podemos usar para ver o mundo de desenvolvimento de software. O que você pensa sobre isso?