Help Wanted: Especialistas Generalistas
Perdão. Não, o finito não está contratando 'especialistas generalistas'. O help necessário é outro. Preciso de ajuda na definição do termo. Queria entender as certezas que aparecem com certa freqüência em algumas listas de discussão e artigos. Normalmente o pessoal cita um artigo do Scott Ambler. Ele fala em 'Generalizing Specialists'. Tropicalizado, o termo virou 'Especialistas Generalistas'. Só a ausência do gerúndio já me deixa encucado. Mas o problema não está só na tradução não. Começa no próprio artigo do Mr Ambler. Ele cita Robert A. Heinlein, um escritor de ficção científica:
"Especialização é para insetos!". O romântico manifesto de Heinlein, em mãos erradas, pode causar um estrago e tanto. Vou surrupiar a réplica de alguém que não tem nada a ver com sci-fi, Peter Drucker [1]:
Mixando os dois autores podemos concluir que as empresas baseadas em informações são verdadeiras colméias ou formigueiros, certo? A analogia é interessante, mas não vou brincar com metáforas. Como eu disse em um rendiconti, meu problema é com os 'especialistas generalistas'. Lá eu disse que um melhor termo seria 'especialistas não-alienados': i) Profissionais que reconhecem e respeitam as outras especializações; ii) estão comprometidos com os objetivos do negócio (do projeto); e iii) sabem trabalhar em equipe. Acho que isso não deveria ser um diferencial - em lugar nenhum. É pré-req em qualquer profissão, não?
Mas a tese de Mr Ambler vai um pouco além. Para ele, 'reconhecer' as outras especializações é conhecê-las de fato. Ele chega a sugerir a seguinte trilha de evolução (é só um exemplo fictício, ele diz):
Não tenho nada contra um profissional buscar outras áreas de conhecimento. Muito pelo contrário. Mas a evolução acima é possível? Se Java, .Net, tecnologias de bancos de dados, metodologias de gerenciamento de projetos e de modelagem fossem congeladas - parassem de mudar e de evoluir, talvez. Mas, definitivamente, não é esse o caso. Alguém que tenha parado de estudar Java há 3 anos seria considerado um especialista hoje? Algumas das áreas de conhecimento citadas por Ambler se entrelaçam. É natural que o especialista em uma delas seja também muito bom em outra. Java e modelagem, por exemplo. Aliás, dependendo da ferramenta, trata-se de uma tarefa só. Um melhor exemplo talvez seja Java e testes, ou Java e deployment. Btw, neste último quesito, muita gente fica devendo. Mas essa é outra história.
O maior problema com a tese, em minha opinião, é a forma como ela desconsidera a dinâmica que vivemos. Alguém que tenha aprendido Cobol lá nos anos 80 até que poderia se dar bem hoje, com um mínimo de esforço de atualização. Podemos dizer o mesmo em relação ao VB ou Java, por exemplo?
O fato é que, para ser um especialista hoje em dia, gasta-se muito tempo. As plataformas tecnológicas cresceram muito, para os lados e para cima. A complexidade dos ambientes aumentou exponencialmente. E, pior, ainda são relativamente imaturas. Ou seja, mesmo que o cara não durma e seja um mestre em 'leitura dinâmica', é difícil se manter um especialista. O que dizer então de um 'especialista generalista' conforme proposto por Ambler? Só se ele já estiver contemplando o uso de um plug como o do Neo em Matrix.
O post ficou longo e, como eu previa, receberá uma seqüência. Quero colocar a questão dos 'especialistas generalistas' no contexto dos projetos. Tirando o lado individual, que procurei destacar aqui, trata-se do maior risco. Equipes multi-disciplinares viraram, em alguns lugares, equipes de profissionais multi-disciplinares.
Sei que a maior parte dos colegas defensores da tese do Ambler são muito bem intencionados. Juan Bernabó, por exemplo, apresenta-a de uma forma muito legal. Mas, infelizmente, não consigo ignorar um tom meio 'facista' de alguns. Me desculpem o termo - mas é assim que interpreto. Quando falam de 'super-desenvolvedores' que sabem fazer tudo no projeto, e ainda se auto-gerenciam... Sei lá, parece que querem dizer: "o mundo é nosso". Aliás, achar que dá para ser bom demais em tudo é uma baita falta de respeito com outros especialistas. Mas esse papo fica para a próxima semana.
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.
"Especialização é para insetos!". O romântico manifesto de Heinlein, em mãos erradas, pode causar um estrago e tanto. Vou surrupiar a réplica de alguém que não tem nada a ver com sci-fi, Peter Drucker [1]:
... conhecimento, por definição, é especializado. Com efeito, as pessoas realmente detentoras de conhecimentos tendem ao excesso de especialização, qualquer que seja seu campo de atuação, exatamente porque sempre se deparam com muito mais a aprender.
A organização baseada em informações exige, em geral, muito mais especialistas do que as empresas tradicionais do tipo comando e controle.
Mixando os dois autores podemos concluir que as empresas baseadas em informações são verdadeiras colméias ou formigueiros, certo? A analogia é interessante, mas não vou brincar com metáforas. Como eu disse em um rendiconti, meu problema é com os 'especialistas generalistas'. Lá eu disse que um melhor termo seria 'especialistas não-alienados': i) Profissionais que reconhecem e respeitam as outras especializações; ii) estão comprometidos com os objetivos do negócio (do projeto); e iii) sabem trabalhar em equipe. Acho que isso não deveria ser um diferencial - em lugar nenhum. É pré-req em qualquer profissão, não?
Mas a tese de Mr Ambler vai um pouco além. Para ele, 'reconhecer' as outras especializações é conhecê-las de fato. Ele chega a sugerir a seguinte trilha de evolução (é só um exemplo fictício, ele diz):
Não tenho nada contra um profissional buscar outras áreas de conhecimento. Muito pelo contrário. Mas a evolução acima é possível? Se Java, .Net, tecnologias de bancos de dados, metodologias de gerenciamento de projetos e de modelagem fossem congeladas - parassem de mudar e de evoluir, talvez. Mas, definitivamente, não é esse o caso. Alguém que tenha parado de estudar Java há 3 anos seria considerado um especialista hoje? Algumas das áreas de conhecimento citadas por Ambler se entrelaçam. É natural que o especialista em uma delas seja também muito bom em outra. Java e modelagem, por exemplo. Aliás, dependendo da ferramenta, trata-se de uma tarefa só. Um melhor exemplo talvez seja Java e testes, ou Java e deployment. Btw, neste último quesito, muita gente fica devendo. Mas essa é outra história.
O maior problema com a tese, em minha opinião, é a forma como ela desconsidera a dinâmica que vivemos. Alguém que tenha aprendido Cobol lá nos anos 80 até que poderia se dar bem hoje, com um mínimo de esforço de atualização. Podemos dizer o mesmo em relação ao VB ou Java, por exemplo?
O fato é que, para ser um especialista hoje em dia, gasta-se muito tempo. As plataformas tecnológicas cresceram muito, para os lados e para cima. A complexidade dos ambientes aumentou exponencialmente. E, pior, ainda são relativamente imaturas. Ou seja, mesmo que o cara não durma e seja um mestre em 'leitura dinâmica', é difícil se manter um especialista. O que dizer então de um 'especialista generalista' conforme proposto por Ambler? Só se ele já estiver contemplando o uso de um plug como o do Neo em Matrix.
.:.
O post ficou longo e, como eu previa, receberá uma seqüência. Quero colocar a questão dos 'especialistas generalistas' no contexto dos projetos. Tirando o lado individual, que procurei destacar aqui, trata-se do maior risco. Equipes multi-disciplinares viraram, em alguns lugares, equipes de profissionais multi-disciplinares.
Sei que a maior parte dos colegas defensores da tese do Ambler são muito bem intencionados. Juan Bernabó, por exemplo, apresenta-a de uma forma muito legal. Mas, infelizmente, não consigo ignorar um tom meio 'facista' de alguns. Me desculpem o termo - mas é assim que interpreto. Quando falam de 'super-desenvolvedores' que sabem fazer tudo no projeto, e ainda se auto-gerenciam... Sei lá, parece que querem dizer: "o mundo é nosso". Aliás, achar que dá para ser bom demais em tudo é uma baita falta de respeito com outros especialistas. Mas esse papo fica para a próxima semana.
.:.
- O Advento da Nova Organização
Peter F. Drucker. Artigo publicado originalmente na edição de jan-fev/88 da Harvard Business Review. Republicado no livro "Gestão do Conhecimento - HBR", da Editora Campus (2001).
.:.
Marcadores: carreira, conhecimento, equipe, generalizing_specialists, it_people
sábado, 26 de maio de 2007 |
Assine o finito
Lista completa no del.icio.us
O termo "especialista - generalista" surge de ter visto organizações, no caso do Scott grandes projetos usando RUP, que acaba naturalmente criando especialistas, tanto eu como ele já vivemos projetos grandes com muito formalismo, inclusive CMMI Nivel 5 onde as especialidades e especialistas tinham criado silos.
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.
Olá Juan. Antes de mais nada, agradeço seus comentários. Vamos lá:
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,
Caro Paulo,
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.
Acho que a gente precisa de melhores vendedores e promotores de modelos. E entender que senso de urgência não tem nada a ver com imediatismo. O que compromete muitos modelos não é a falta de mecanismos anti-bobeira. São os bobos!
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,