A multidisciplinaridade as vezes parece ser uma palavra mágica, principalmente quando é mal interpretada ou super valorizada.
A multidisciplinaridade, ou chamada por alguns como multifuncionalidade, é a característica de se poder realizar várias funções diferentes, ou de se ter o conhecimento de várias disciplinas podendo aplicá-las para a resolução de problemas ou para o desenvolvimento de produtos.
Em outras palavras, é o poder de se realizar mais de uma função, por exemplo, administrar um banco de dados, planejar a arquitetura de um sistema, programar códigos em Java, realizar uma análise de negócio ou levantamento de requisitos, testar um sistema e gerenciar tarefas.
O Scrum é o framework mais conhecido no mundo ágil, e uma de suas também mais conhecidas e contestadas regras é que o Time deve ser multidisciplinar.
Esta contestação parte primeiro dos defensores de outras práticas de gerenciamento, como as tradicionais, e segundo pelos próprios defensores do ágil que interpretam de forma errada esta regra.
Quando o Scrum determina que o Time deve ser multidisciplinar, ou multifuncional, a regra é simples: o Time deve ser, e não os indivíduos. Muitos contestam esta regra porque entendem (ou são ensinados) que os indivíduos devem ser todos multidisciplinares dentro do Time, ou seja, todos devem saber e poder fazer tudo, e assim vão atender a multidisciplinaridade do Scrum.
O correto entendimento desta regra é que o Time deve ser multidisciplinar, ou seja, dentro do Time deve se ter vários indivíduos cada um com a sua especialidade individual e juntos formarem uma equipe multifuncional, e que o Time como um todo poderá realizar todas as tarefas e atividades do projeto.
É fácil entender que isso é verdade, porque quem conhece uma única pessoa que é especialista em tudo? Sinceramente, eu não conheço, nem na área de TI, nem na área de medicina, nem na área de engenharia, enfim, em nenhuma.
O grande desafio proposto pelo Scrum, é formar um Time multidisciplinar, com vários profissionais especialistas em cada necessidade do projeto, e que todos se ajudem mutuamente para completar os trabalhos. Aqui é que está o grande segredo, e também o que normalmente gera a confusão. O Scrum provoca o Time a desenvolver esta multidisciplinaridade, expandindo e espalhando os conhecimentos a respeito das disciplinas envolvidas e disseminando entre o Time as capacitações adquiridas.
No entanto, não podemos confundir isso com “Todos devem saber tudo e fazer tudo“. Isso sim é um mito. O que a multidisciplinaridade tenta provocar no Scrum é que os indivíduos aprendam um com os outros e com isso sejam capazes de ajudar o Time e realizarem tarefas que antes não conseguiam realizar, mas não como especialistas, apenas como executores que contribuem para completar as tarefas.
Vamos ver um exemplo:
Temos em um Time um DBA Oracle, um Programador Sênior Java e um Tester. Cada um tem as suas tarefas direcionadas de acordo com o seu perfil, o que é normal na vida real e nos projetos reais. Porém, digamos que o Programador finalizou todas as suas tarefas e o DBA também, fazendo com que o Tester acumulasse tarefas e gerasse um gargalo na finalização da história. Para evitar isso, e contribuir para completar a história de um Sprint, tanto o Programador quanto o DBA podem aprender com o Tester e ajudá-lo a completar as suas tarefas, fazendo com as tarefas sejam de todos. Lembrando que isso não significa que o Programador e o DBA se tornaram, ou deviam se tornar, especialistas em Testes. Na verdade as tarefas mais complexas ou que precisam do especialista serão realizadas pelo Tester, e as mais simples pelos outros dois.
Assim eu finalizo este post sobre o mito da multidisciplinaridade. Este conceito ou regra, funciona muito bem, e inclusive não é um conceito exclusivo do ágil, as equipes multidisciplinares são encontradas em diversos tipos de projetos, metodologias e boas práticas. A grande questão é entender que o Time como um todo deve ser multidisciplinar, e não cada um dos indivíduos que o compõe, e o ponto diferencial do Scrum é a forma com que ele contribui para que esta multidisciplinaridade seja espalhada e expandida dentro do Time gerando indivíduos mais capacitados, mais pró-ativos e mais colaborativos.
Então é isso, multidisciplinaridade sim, mas no Time, não nos indivíduos.
