Simples, Complicado ou Complexo?

By , 21/11/2011 9:59 AM

Even though models of complex systems are usually incomplete, they can still be valid and useful because they give us complementary (and possibly contradicting) viewpoints.
(Systems Theory and Complexity: Part 1 – Kurt A. Richardson)

All models are wrong, but some are useful.
(Evolutionary Operation – Box and Draper)

O Gartner em seu relatório “PPM in a Complex World: Identifying Complexity” indica que saber identificar quando um projeto ou programa é complexo é uma habilidade básica necessária a todos líderes de projetos e programas, pois tais projetos devem ser gerenciados diferentemente para serem bem sucedidos.

Obviamente, não existe um método determinístico para classificar um sistema como complexo. Sendo assim, devemos fazer uso de modelos que, mesmo incompletos, permitirão visões complementares (e as vezes contraditórias) que auxiliarão na decisão de quando classificar um sistema como complexo.

O modelo mais famoso (devido ao Scrum) é conhecido como Agreement & Certainty Matrix e foi desenvolvida pelo Prof. Ralph Stacey. Este modelo (vide figura abaixo) permite a classificação de uma determinada questão a partir de duas dimensões: o nível de acordo e o nível de certeza sobre a questão.

Um outro modelo bastante famoso é conhecido como Cynefin Matrix (vide figura abaixo). Desenvolvido originalmente para a área de gerenciamento do conhecimento, criado pelo pesquisador David Snowden, define quatro classificações baseadas na relação entre causa e efeito e define a melhor abordagem de ação para cada classificação.

O último modelo (vide figura abaixo) foi criado por Jurgen Appelo (autor do livro Management 3.0). Este modelo possui duas dimensões: estrutura e comportamento.

Na dimensão estrutura, um sistema pode ser simples (fácil de entender) ou complicado (difícil de entender). Na dimensão comportamento, um sistema pode ser ordenado (totalmente previsível), complexo (de alguma forma previsível) ou caótico (muito imprevisível). O autor destaca que é possível atuar na simplificação do sistema (tornando a estrutura mais simples) mas não é possível atuar na “linearização” do sistema (tornarndo o comportamento mais previsível).

O denominador comum dos três modelos é a questão da certeza, da previsibilidade. Projetos contendo componentes mais previsíveis estão mais distantes do caos (vide figura abaixo), e portanto, se beneficiam de práticas mais tradicionais. Projetos contendo componentes menos previsíveis (como a maioria dos projetos envolvendo desenvolvimento de software), estão mais próximos do caos, e portanto, possuem características distintas e necessitam de práticas diferenciadas. No próximo post pretendo abordar algumas dessas características.

Nota: Todas as ilustrações utilizadas neste post foram criadas por Jurgen Appelo, fazem parte do seu livro e estão disponíveis para uso.

 

Panorama Theme by Themocracy