Na minha leitura, Scrum não fixa papéis para domínios que ele não toca. Mas fixa papéis para o que ele pretende resolver: o gerenciamento de projetos! IMHO, trata-se de outra leitura perigosa de uma boa proposta – de um bom modelo. O Jeff defende ‘especialistas generalistas’? Você pode me passar uma referência (artigo, link)?

Não estou resistindo ao conceito (dos especialistas generalistas) por teimosia. Nem por temer o retorno dos que nunca foram (os analistas programadores citados por ti). Não me entenda mal.

Acontece que em muitos projetos eu não posso abrir mão da presença de especialistas. Especialistas de verdade, não aqueles com os ‘20% da essência’.

Você já citou TOC. Que tal desenhar uma ‘dispersão de nuvem’ para testar a solução dos ‘especialistas generalistas’? De novo: pelo que eu entendi, o conflito – o problema que você está querendo resolver – é a concentração de poder e conhecimentos, certo? Pergunto de novo: a melhor solução é a eliminação dos especialistas?

Abraços,

Você perceveu que o problema das organizações interpretar errado um modelo é recorrente. Parece um sintoma de alguma coisa mais profunda, talvez precisemos modelos mais com mecanismos baka-yoke (à prova de bobeira) do lexico lean.

Por exemplo em Scrum, os membros da equipe não tem papeis definidos, e isto é explicito. Uma especie de mecanismo a prova de bobeira, porque organizações tem especial capacidade de mal interpretar modelos.

Toda vez que tem um cara que é o dono de uma especialidade ele se torna uma fonte de problemas de colaboração, e se depende da predisposição do cara a colaborar ou não, mais se da munição para ele se quiser não cooperar já que esta escrito que ele é quem faz e decide sobre x,y ou z.

O que você acha mais perigoso, ter uma pessoa numa equipe que é a unica que sabe uma coisa ou tem um skill especifico, ou 6 caras que sabem os 20% necessarios daquela especialidade para dar os 80% de retorno?

Onde ha mais concentração de poder, onde existe mais risco de perder conhecimento, onde ha mais posibilidade de ter gargalos?

Por favor lembra que eu era rupeiro dos bons, Scott tambem, e usaba UML desde a notação Booch ha uns 14 anos.

Eu pouco a pouco fui entendendo mais a logica de causa e efeito que existe em algumas coisas como os especialistas/generalistas, talvez o problema seja que isso te evoque uma resistencia ou você acredite que isto seja uma volta ao analista/programador que tanto nos deu problemas e que na verdade não era especialista em nada, so um generalista.

Abraços,
Juan.

O RUP realmente indica a necessidade de vários ‘perfis’ (bonés). É uma parte mal interpretada do modelo. Mas boa parte da culpa é dos próprios autores. Nada impede que um especialista utilize vários bonés do RUP.

Agora, a criação de ‘silos’ não é uma conseqüência natural da adoção do RUP ou CMMI ou qualquer outro modelo. Se ocorre, tenha certeza, é um problema da organização e da forma como ela lida com seus profissionais e projetos.

Também já briguei muito com DBA’s, por exemplo. ‘Silos’ de DBA’s eram muito comuns em empresas que afundaram os pés na jaca da arquitetura C/S logo em seu início. Os caras ganharam muito poder. Assim como os desenvolvedores Cobol tinham na geração imediatamente anterior. De novo: a culpa é da organização.

Se ela não consegue fazer com que seus especialistas COLABOREM para atingir os objetivos de um projeto, a solução é acabar com os especialistas? Além de não ser possível, a empresa só estaria criando um novo tipo de ‘sequestrador’. Mais perigoso ainda (porque seria mais poderoso).

Eu vou falar sobre médicos no próximo post sobre o assunto. É uma comparação que o Peter Drucker usa com certa freqüência. Sim, todo médico é um ‘generalista’. O meu, por exemplo, é clínico geral e cardiologista.

Agora, você já viu um médico que seja cardiologista, endocrinologista, nutricionista, pediatra, hematologista e imunologista? Tudo ao mesmo tempo? Não existe, não é mesmo?

Mas a sugestão do Scott vai neste sentido.

Abraços,

Sabemos que organizações que são orientadas a silos acabam não sabendo colaborar muito bem, e tem problemas de comunicação, que comprovadamente são causas raiz de fracaso em projetos de software.

Já aconteceu comigo em projetos, onde alguns especialistas, que não eram tão especiais assim, na area de analise ou na area de banco de dados tratabam o seu trabalho. Ao inves de tentar fornecer os conhecimentos da sua especialidade para o bom do projeto integrando com as outras especialidades, o que acontecia era que cada um puxaba o sistema para seu lado, forçando os outros a ter que aturar a solução dele, so porque sobre essa parte as pessoas podiam mandar e procurar o melhor da sua especialidade, e ahi ao inves de colaborar era necesario negociar.

Especialistas isolados, e especialização funcional pode ser um cancer para o projeto, já que ao inves de optimizar o todo do projeto para ter um projeto melhor, se acaba optimizando cada parte, cada função, sem importar se isto agrega ou não valor para o todo.

No livro a Meta do Dr. Goldratt, fala um pouco sobre o problema de optimização das partes e o impacto para o todo, se a meta não for a mesma…

Então a chave para entender o termo é que deve se procurar ser um especialista que sabe trabalhar junto de outros especialistas e que conhece as outras especialidades, mais sobre tudo é o estilo de trabalho em colaboração.

Em medicina é assim um medico antes de ser um especialista tem que ser um medico clinico, que basicamente é um generalista, ou seja eles tambem são especialistas-generalistas.

Abraços,
Juan.