Por que eu devo ler este artigo: O objetivo é mostrar como a Teoria de Belbin pode ser utilizada para auxiliar na montagem de equipes de software. Desta forma, é possível montar equipes nas quais exista um melhor casamento entre o comportamento esperado no papel funcional e os comportamentos mais naturais do indivíduo alocado neste papel, impactando na produtividade e na motivação da equipe.

Formar boas equipes está longe de ser uma tarefa fácil, pois não se trata apenas de colocar pessoas altamente qualificadas para trabalhar juntas. Mas, uma vez que se consegue organizar as pessoas de acordo com suas personalidades e potenciais habilidades, a qualidade e a produtividade do trabalho desenvolvido podem ser melhoradas.

Desenvolvimento de software é uma atividade reconhecidamente complexa devido ao grande e diverso conjunto de fatores que podem afetar o desempenho e, consequentemente, o sucesso dos projetos. Entre estes fatores estão os aspectos essencialmente técnicos (linguagens, dispositivos, métodos de produção, processos de desenvolvimento, etc.), o conhecimento (ou não) do domínio do negócio, a qualificação técnica da equipe e a forma como as pessoas envolvidas interagem, se estruturam e se comportam diante das atividades do projeto de desenvolvimento. O último destes fatores está relacionado diretamente à composição do time (de desenvolvimento) de software, como discutido por Sawyer (2004).

Retenha talentos e aumente a produtividade dos seus programadores

Saiba mais DevMedia Plataforma Empresarial

A equipe de software tem sido estudada desde os primeiros dias da engenharia de software, em trabalhos seminais como Baker (1972) ou Brooks (1976). Estes enfoques essencialmente funcionais têm sido complementados, mais recentemente, com análises da influência do tipo de personalidade dos indivíduos no desempenho da equipe de software. Estes novos trabalhos têm buscado sua fundamentação conceitual em estudos e teorias sobre tipos de personalidade (por ex. Bradley & Herbert (1997)), teoria de papéis (por ex. Biddle (1979) e Belbin (1981)) ou estilos cognitivos (por ex. Kirton & Ciantis (1986)), entre outros.

Os resultados de vários autores, entre eles Gorla & Lam (2004), Rajendram (2005), Young et al. (2005) e Karn & Cowling (2006), apresentam evidências concretas de que certas personalidades têm melhor desempenho em determinados papéis do processo de desenvolvimento. Ou seja, conclui-se que um caminho para melhorar o desempenho de equipes de software é buscar o adequado casamento entre papel funcional ou técnico com a personalidade do indivíduo atribuído ao papel.

No entanto, todos conhecem histórias de equipes formadas apenas por estrelas (ótimos profissionais) e que não conseguiram um bom entrosamento, não renderam o esperado ou até mesmo falharam. Assim como o oposto, equipes desacreditadas, com participantes menos qualificados, obterem ótimos resultados. Isso acontece em diversas áreas, desde esportes e pesquisa até no mundo empresarial. Formar boas equipes está longe de ser uma tarefa fácil, pois não se trata apenas de colocar pessoas altamente qualificadas para trabalhar juntas. Mas, uma vez que se consegue organizar as pessoas de acordo com suas personalidades e potenciais habilidades, a qualidade e a produtividade do trabalho desenvolvido podem ser melhoradas (Ferreira, 2007).

Neste artigo é apresentada uma comparação entre as habilidades necessárias de alguns papéis funcionais descritos no Rational Unified Process (RUP) com as descrições dos papéis de time da Teoria de Papéis de Belbin (1981). O objetivo é identificar como a Teoria de Belbin pode ser utilizada para auxiliar na montagem de equipes de software nos quais exista um melhor casamento entre o comportamento esperado no papel funcional e os comportamentos mais naturais do indivíduo alocado neste papel.

Papéis de Time (Team Roles)

Segundo Belbin (1981), dentro de um contexto de trabalho em equipe todo indivíduo pode ser classificado de acordo com os seus conhecimentos e a sua função técnica e também com a forma como tende a se comportar, a contribuir e a se relacionar com outros integrantes. Para tanto, Belbin construiu um conjunto de Team Roles, ou papéis de time, que descrevem padrões que caracterizam o comportamento de um indivíduo em relação aos outros na facilitação do progresso de um time.

No estudo de Belbin, são identificados cinco princípios para o gerenciamento de times:

  • Membros de um time podem contribuir de duas formas para alcançar os objetivos do time: eles podem desenvolver bem um papel funcional de conhecimento técnico, quando a situação requisita, e podem ter um perfil de time (team role) valioso, o qual descreve um padrão de características comportamentais de como o indivíduo interage com o restante do grupo facilitando o trabalho da equipe;
  • Cada time precisa de um balanceamento ótimo nos dois aspectos: papéis funcionais e team roles. Esse nível dependerá dos objetivos e tarefas que o time está enfrentando;
  • A eficácia do time se dá pela capacidade dos integrantes de reconhecerem corretamente e ajustarem suas forças e experiências ao restante do time, adotando um team role específico;
  • As qualidades pessoais de cada um facilitam que o indivíduo se adéque a um team role, assim como limita as chances dele se adaptar a outro;
  • Um time deve distribuir seus recursos técnicos apenas quando os team roles estão bem estruturados e conseguem garantir a eficiência no trabalho em equipe.

Criar um time forte e coeso é uma ciência inexata. Existem coisas que podemos fazer para aumentar as chances de serem bem-sucedidos, mas é impossível dizer se o time realmente vai se sair bem. Trazer as pessoas certas para o projeto se torna crucial. Entretanto, não basta apenas entender como o indivíduo se comporta sozinho e sim, como ele interage em um determinado grupo. Não se trata de ter a pessoa certa para liderar, mas sim, pessoas capazes de trabalhar bem em conjunto e que possam se ajudar para alcançar um objetivo em comum.

Por tratar de aspectos pessoais não-estáticos, relativos ao comportamento situacional dos indivíduos, Belbin complementa que é possível um único indivíduo assumir mais de um papel na equipe, desde que não sejam papéis com características chocantes. Dessa forma, não é necessário que uma equipe tenha ao menos oito componentes para suprir todos os perfis.

Em seu trabalho original, Belbin (1981) definiu oito papéis de time:

  • Coordinator: Papel de liderança. As pessoas que representam adequadamente este papel tendem a ser calmas, autoconfidentes e exercerem liderança controladamente. Eles servem para guiar e controlar os membros do time em uma dada situação. Este papel está presente normalmente em posições de liderança mais permanentes. O Coordinator tem um forte senso de objetividade e consegue extrair todo o potencial de contribuição de cada membro do grupo.
  • Shaper: Segundo papel de Liderança. Líder autoritarista. É impaciente, provocativo e normalmente fica irritado nas reuniões do time. Melhor adequado a posições temporárias, como liderança de projetos. Apresentam uma direção forte, é dinâmico e tem coragem para levar o time a enfrentar os obstáculos.
  • Plant: Papel de criatividade. Simpatia com a inovação e a resolução de problemas. Normalmente é individualista, sério e não-ortodoxo. Seu gênio, imaginação, intelecto e conhecimento são seus pontos fortes, enquanto sua principal fraqueza é que despreza as implicações práticas dos problemas do time, além de criar uma forte relação pessoal com as suas ideias. Fonte de criatividade e originalidade do time. Tendência a ignorar o óbvio e optar pelo menos convencional.
  • Resource-Ivestigator: Papel de criatividade. Provê ideias a partir do mundo exterior ao time. Grande capacidade de comunicação, entusiasmo, extroversão, interesse em explorar sempre novas alternativas e enfrentar novos desafios. Sua principal fraqueza é que é levado a perder a motivação quando passa a fascinação inicial pelo trabalho. É a pessoa de contato externo do grupo.
  • Monitor Evaluator: Papel de equilíbrio. Tende a ser sóbrio e prudente, sem qualquer relação emocional com o trabalho exercido. Apresenta julgamento claro, discrição e pode parecer cínico e cético. Seu aspecto negativo é a sua falta de inspiração, bem como a sua incapacidade de motivar as outras pessoas. É a pessoa que constantemente analisa as soluções propostas e as decisões tomadas pelo time, evitando que o time cometa erros conceituais e aponta as falhas no plano antes de assumir compromissos.
  • Implementer: Papel de execução. Transformam os planos e conceitos definidos pelo time, em processos e ações práticas de trabalho. Apresenta grande capacidade de organização, trabalha duro, autodisciplinado e possui um senso prático destacável. Normalmente conversador, dá mais importância para o resultado geral da companhia do que aos seus interesses pessoais. Este membro tem uma grande habilidade de identificar as necessidades da companhia, bem como de assumir responsabilidades que os outros evitam, porém apresenta uma grande falta de flexibilidade e resposta lenta a mudanças de situações.
  • Team Worker: Papel de execução. Mediador interno ao grupo, habilidade social e sensitiva para com os sentimentos dos outros integrantes. Promove o espírito de equipe e atua motivando a equipe para trabalharem todos juntos em prol do objetivo comum. Resolve conflitos e atua como uma espécie de pacificador. É responsável por manter a coesão da equipe.
  • Completer Finisher: Papel de equilíbrio. É preciso, perfeccionista e busca sempre evitar erros, prestando muita atenção a todos os detalhes. É o papel que normalmente está disposto a levar o projeto até o fim.

A Tabela 1 explora sucintamente as características típicas, as qualidades e as fraquezas de cada papel de time.

Papel de Time (Título Original) Sigla Descritores Pontos Fortes Possíveis Fraquezas
Completer Finisher CF Ansioso, consciencioso, introvertido, tem autocontrole, tem autodisciplina, submisso e preocupado. Meticuloso, consciencioso, procura por erros e omissões, entrega sem atraso. Tendência a se preocupar demais. Relutante a delegar.
Implementer (Company Worker) IMP Conservador, controlado, disciplinado, eficiente, inflexível, metódico, sincero, estável e sistemático. Disciplinado, confiável, conservador e eficiente, transforma ideias em ações práticas. Um tanto inflexível. Lento para responder a novas possibilidades.
Team Worker TW Extrovertido, amigável, leal, estável, submisso, confortante, não assertivo e não competitivo. Cooperativo, suave, boa percepção e diplomático, escuta, constrói, evita atritos, acalma o clima. Indeciso em situações de conflito.
Specialist [Nota 1] SP Especialista, defensivo, não interessado nos outros, sério, tem autodisciplina, eficiente. Focado, dedicado, automotivado, provê conhecimento e habilidades raras. Contribui somente em um único tópico. Alonga-se em tecnicalidades.
Monitor Evaluator ME Seguro, fidedigno, justo, introvertido, de avanço lento, aberto a mudanças, sério, estável e sem ambições. Sóbrio, estratégico e perspicaz, visualiza todas as opções, julga com precisão. Não tem impulso e habilidade para inspirar outras pessoas.
Coordinator (Chairman) CO Dominante, confia nos demais, extrovertido, maduro, positivo, tem autocontrole, tem autodisciplina, estável. Maduro, confiante, bom diretor, esclarece objetivos, promove a tomada de decisão, delega bem. Pode ser visto como manipulador. Sobrecarregado com trabalho.
Plant PL Dominante, imaginativo, introvertido, original, pensamento radical, cheio de confiança, não se inibe. Criativo, não ortodoxo, soluciona problemas difíceis. Muito absorto em pensamentos; dificuldade para se comunicar efetivamente.
Shaper SH Abrasivo, ansioso, arrogante, competitivo, dominante, irritável, emocional, extrovertido, impaciente, impulsivo, autoconfiante. Desafiador, dinâmico, prospera sob pressão, tem impulso e coragem para vencer obstáculos. Suscetível a provocações. Ofende o sentimento das pessoas.
Resource Investigator RI Diplomático, dominante, entusiasta, extrovertido, flexível, inquisitivo, otimista, persuasivo, positivo, descontraído, social e estável. Extrovertido, comunicativo, explora oportunidades, desenvolve contatos. Excessivamente otimista. Perde interesse depois do entusiasmo inicial.
Tabela 1. Papéis de Time, Descritores, Pontos Fortes e Possíveis Fraquezas - Fonte: Belbin (1993), pg. 22
Nota 1: O Papel Specialist foi acrescentado ao conjunto de papéis de Belbin em seu trabalho mais recente (Belbin - 1993). Porém, este papel tem sido criticado na literatura e sua validade não é clara neste contexto. Portanto, este trabalho baseou-se na versão original (Belbin - 1981) e, por isso, não trata o papel Specialist.

Os papéis de time podem ser agrupados de acordo com sua tendência em relação à liderança ou criatividade, da seguinte forma:

  • Perfis de Liderança (Coordinator, Shaper): papéis de liderança de perfis opostos e, em certos contextos, antagônicos.
  • Perfis de Criatividade (Plant, Resource Investigator): perfis associados a solução de problemas que buscam esta solução com recursos próprios (Plant) ou de terceiros (Resource Investigator).
  • Perfis de Suporte (Specialist, Implementer, Teamworker, Monitor Evaluator): perfis que complementam o trabalho do time com competências e habilidades específicas.

A Teoria de Papéis é complementada por uma ferramenta de análise chamada Team Role Self-Perception Inventory (TRSPI, Belbin (1981), pg. 153), com o qual é possível identificar os papéis exercidos ou preferidos por um indivíduo em uma situação de trabalho em grupo. O TRSPI (versão original com 8 papéis) é composto de 7 questões, com 8 itens por questão. Cada item descreve um comportamento relativo a uma situação de trabalho em grupo e está relacionada a um papel de time. O respondente deve atribuir 10 pontos entre os 8 itens em cada questão, de forma a refletir a sua autopercepção de como se comporta em cada situação descrita.

As pontuações não são utilizadas diretamente. Existe uma tabela de normas que classifica a tendência ao comportamento de acordo com o papel em uma escala de quatro valores: Low, Average, High e Very High. Com esta escala, indivíduos com pontuação nos níveis High e Very High tendem a exibir o comportamento descrito no papel, enquanto aqueles com pontuação Low ou Average terão deficiência ou dificuldades em assumir o comportamento descrito.

Adequação de perfis de personalidade e papéis funcionais do RUP

As recomendações abaixo foram desenvolvidas a partir de uma pesquisa de campo realizada através da aplicação de uma adaptação do questionário Self Perception Inventory - SPI em 40 profissionais distribuídos em três fábricas de software com atuação em Recife.

  • O gerente de projeto deve apresentar um perfil de liderança e coordenação orientado a pessoas, como o perfil CO (Coordinator). De fato, a pesquisa demonstra que os gerentes de projetos entrevistados têm tendência a assumir tal papel. Porém, a pesquisa também demonstra uma aparição significativa do perfil IM (Implementer). O que se justifica por se tratar de um perfil focado para o resultado geral do processo da organização. O papel que é responsável direto pelo resultado geral do projeto deve exercer uma grande habilidade de identificar as necessidades da companhia. Os dados também indicam que os gerentes de projeto com maior nível de satisfação são aqueles que apresentam um grau extremamente alto de IM e CO em conjunto, ou que apresentam apenas um dos dois perfis, porém exerce exclusivamente esta função no projeto (a maioria dos gerentes de projeto entrevistados exerce a função em conjunto com algum papel de analista).
  • O engenheiro de processos, ao contrário do gerente de projeto, deve assumir um papel de coordenação, porém mais orientado à atividade, a fim de estabelecer um processo objetivo e eficiente de desenvolvimento de software e de garantir que tal processo será respeitado e gerenciado. A pesquisa quantitativa indica que a incidência do perfil SH (Shaper) somado ao CO (Coordinator) garante a satisfação do indivíduo, enquanto apenas a aparição do CO (Coordinator) causa sua insatisfação. Desse modo infere-se que o SH (Shaper) é o perfil mais indicado.
  • O gerente de controle de mudanças, por sua vez, deve assumir uma posição de grande prudência e corretividade conceitual, adequando-se ao perfil ME (Monitor Evaluator), a fim de evitar que pequenas falhas possam se transformar em grandes problemas durante todo o projeto. É importante, porém não essencial, que o gerente de controle de mudanças apresente também um grau mais alto em um perfil de coordenação orientado à atividade, como o SH (Shaper).
  • O gerente de configuração deve ser assertivo para assegurar que os desenvolvedores não ignorem a política e os procedimentos de configuração. Pela necessidade de ser atento aos detalhes, o gerente de configuração deve possuir um perfil analítico destacável, como ME (Monitor Evaluator). A pesquisa quantitativa mostra que em 50% dos casos este perfil se destaca entre os gerentes de configuração que estão satisfeitos. É comum a renegação da disciplina de gerência de configuração em muitos projetos, o que pode indicar que os 50% restante não tenha um bom controle de configuração de seus projetos.
  • O papel de gerente de implantação deve assumir um perfil semelhante ao do gerente de projeto no que diz respeito ao trabalho pesado, capacidade de planejamento com foco na organização e orientação por resultados características referentes ao perfil IM (Implementer). Isso se deve pelo fato de ser uma disciplina crítica do projeto, da qual o resultado interfere completamente na satisfação do cliente. Inclusive, como sugestão do próprio RUP, ambos os papéis podem ser exercidos pelo mesmo indivíduo.
  • O gerente de testes necessita de um alto desempenho em um perfil orientado à ação. É deste papel a responsabilidade pelo esforço geral dos testes. De fato, a pesquisa indica que o perfil mais comum entre os gerentes de testes satisfeitos é o IM (Implementer), aparecendo em 100% dos casos mesmo quando todos estes assumem simultaneamente papéis de Analista.
  • O analista de negócios é o papel que lidera e coordena a modelagem dos casos de uso de negócios. Deve assumir um perfil que despende bastante atenção principalmente no tratamento com os clientes para captação das necessidades deste. É importante também que este papel tenha capacidade também de negociar com o cliente os aspectos de projeto que possam interferir nos interesses gerais da organização. Estas características são representadas pelos perfis CO (Coordinator) e IM (Implementer). Este analista pode ainda assumir um perfil mais cerebral que apoiará na modelagem da arquitetura de negócios. A pesquisa prática indica que, de fato, os dois perfis são os mais comumente destacados nos profissionais analistas de negócios. Mais dois detalhes que a pesquisa prática revela é que o nível do perfil cerebral é diretamente proporcional ao grau de satisfação do indivíduo; e que, por apresentar características semelhantes ao gerente de projeto, em 80% dos casos o analista de negócio assume também papéis de gerência no projeto.
  • O analista de sistemas é responsável pela modelagem dos casos de uso de análise do sistema. Suas características comportamentais são semelhantes ao analista de negócios. Frequentemente o analista de negócios também assume o papel de analista de sistema. O principal diferencial aparece com o aumento da aparição de um perfil mais criativo. Por necessitar de um perfil essencialmente orientado a pessoas, a nova característica do analista de sistemas agora é o RI (Resource Ivestigator).
  • O especificador de requisitos deve contemplar os perfis IM (Implementer) e CF (Completer Finisher), pois está sob sua responsabilidade um dos principais artefatos da fase de Análise, a especificação dos casos de uso. No contexto de fábricas de software, a qualidade desse artefato é definitiva para o desenvolvimento de um produto, visto que é o principal meio de comunicação entre o cliente final e o núcleo de desenvolvimento da fábrica. A pesquisa prática indica que o perfil IM (Implementer) está presente em 75% dos especificadores de requisitos. Porém exibe uma grande escassez de CF (Completer Finisher), o que pode ser uma das principais causas da excessiva quantidade de alterações comumente solicitadas nos sistemas produzidos. A pesquisa indica também que para este papel, a satisfação do usuário é inversamente proporcional ao grau de aparição do perfil CO (Coordinator).
  • O analista de teste avalia a modelagem do sistema e identifica as necessidades de teste do sistema. Então, por necessitar de uma visão crítica e criteriosa, este analista deve assumir o perfil ME (Monitor Evaluator). Na prática, o que acontece é de indivíduos que exercem outros papéis de analista, bem como outros papéis de gerência, assumirem a responsabilidade pela análise de testes, o que acaba por prejudicar a produção de testes confiáveis por essas organizações, consequentemente aumentando as estatísticas sobre o insucesso de projetos de software.
  • O papel de arquiteto de software é responsável pela definição de diretrizes para o desenvolvimento, e deve implementar a característica criativa da equipe. Na pesquisa prática, 50% dos arquitetos satisfeitos assumem um grande grau de CO (Coordinator), porém todos eles exercem simultaneamente papéis de analistas, o que descarta o perfil como essencial. O diferencial capaz de influenciar diretamente na satisfação do arquiteto é a aparição de um alto grau de PL (Plant) ou RI (Resource Investigator). Por outro lado, o nível de aparição do CO (Coordinator) é inversamente proporcional à satisfação do profissional. Outro fator ao qual o arquiteto de software não se adéqua perfeitamente é ao acúmulo de papéis de gerente ou testador.
  • O papel de implementador deve assumir um perfil voltado à implementação de tudo que foi planejado e especificado até então. Este papel, por estar na base do processo produtivo, deve apresentar um interesse em produzir resultado mais do que em produzir planos. Essas características, típicas de um IM (Implementer), se confirmam na prática os implementadores satisfeitos apresentando um grau bastante significativo deste perfil. É interessante notar que dois terços dos implementadores entrevistados também exercem o papel de testador. Aqueles que atuam exclusivamente no papel de implementar possuem graus significativos do perfil TW (Team Worker).
  • O integrador, por sua vez, deve assumir um perfil orientado à atividade, de persistência e detalhismo, como CF (Completer Finisher). De fato, o perfil mais evidente na pesquisa (100% dos casos) é orientado a atividade, porém é o IM (Implementer). É importante notar também que o integrador e por isso apresenta o perfil IM (Implementer) em evidência.
  • O testador põe em prática os testes, sendo o papel central que cuida da condução e do registro dos seus resultados. Por apresentar características bastante pragmáticas, o perfil adequado para o testador é IM (Implementer). A pesquisa prática revelou que os testadores que destacam normalmente o perfil IM (Implementer) encontram-se satisfeitos. Isso também justifica o grande número de testadores, mais de 90%, que também exercem papéis de desenvolvedor.

A Tabela 2 apresenta o mapeamento sumarizado entre todos os papéis do RUP e seus perfis adequados do Belbin.

IM CO SH PL RI ME TW CF
X X Analista do Processo de Negócios
X X X Analista de Sistemas
X Analista de Teste
X X Arquiteto de Software
X X Designer
X X Designer de Banco de Dados
X X Designer de Cápsulas
X X Designer de Interface de Usuário
X X Designer de Negócios
X X Designer de Teste
X Engenheiro de Processo
X X Especificador de Requisitos
X Gerente de Configuração
X Gerente de Controle de Mudanças
X Gerente de Implantação
X Gerente de Projeto
X Gerente de Testes
X X Implementador
X Integrador
X Revisor de Arquitetura
X Revisor de Código
X Revisor de Design
X Revisor do Modelo de Negócios
X Revisor do Projeto
X Revisor de Requisitos
X Testador
  • CH – Chairman
  • PL – Plant
  • ME – Monitor Evaluator
  • TW – Team Worker
  • SH – Shaper
  • RI – Resource Investigator
  • CW – Company Worker
  • CF – Completer Finisher
Tabela 2. Mapeamento dos perfis de Belbin nos Papéis do RUP

Recomendações gerais para montagem de times

Com base na análise das adequações descritas anteriormente, é possível delinear as seguintes recomendações gerais para montagem de times:

  • O Gerente de Projetos deve comunicar bem: não sendo possível alocar um Coordinator como gerente, os papéis Resource-Investigator e Team-Worker também relacionam positivamente com esta função, pois são papéis com forte perfil de comunicação e orientados a pessoas, característica universalmente aceitas como importante no gerente de projetos. Estes resultados também são consistentes com Fernandes & Silva (2007).
  • Cuidado com Gerentes Shapers: indivíduos com preferência por um comportamento do tipo Shaper tendem a assumir posições de liderança em times, de acordo Belbin, mas suas características negativas dificultam o relacionamento interpessoal dentro e fora do time. Apesar de Shapers poderem ser importantes em projetos com necessidade de lideranças fortes e “enérgicas”, é necessário ter cuidado com os potenciais conflitos que podem surgir, principalmente se outros membros do time tiverem tendências ao mesmo papel.
  • Excesso de Criatividade pode Prejudicar a Implementação: papéis relacionados à criatividade, Plant e Resource-Investigator, se relacionam negativamente com as habilidades necessárias do papel Implementador. Indivíduos com estes papéis tendem a ser muito bons na solução de problemas complexos, mas perdem o interesse na atividade assim que a solução é encontrada. Atividades classicamente repetitivas ou rotineiras, como codificação e teste, não são adequadas para indivíduos com estes papéis.
  • Criatividade é um Traço Importante para o Arquiteto de Software: a relação positiva do papel Arquiteto de Software com os papéis de time associados à criatividade, Plant e Resource-Investigator, mostra que este traço de personalidade é importante para as atividades de desenho da arquitetura de sistemas.
  • O Analista de Sistema deve ter Afinidade com Pessoas: o modelo aponta para uma relação positiva do papel Analista de Sistemas com os papéis de Belbin que naturalmente tem facilidade no relacionamento interpessoal e boas habilidades de comunicação, como Resource-Investigator, Team-Worker e Coordinator.
  • Completer-Finisher e Monitor-Evaluator são Importantes na Implementação: indivíduos que exibem comportamento de Completer-Finisher e Monitor-Evaluator são meticulosos, bons avaliadores e preocupados em entregar seus trabalhos no prazo. Apesar de serem apenas medianos em relação à criatividade, possuem características positivas para tarefas de codificação, teste e controle de qualidade.
  • Lideranças devem ser estabelecidas dentro dos subtimes: O perfil TW (Team Worker) aparece em apenas uma sugestão de adequação para os papéis do RUP. Isso ocorre pelo fato do perfil TW ser um perfil de mediação interna do grupo. Num contexto de fabricação de software, podem ser identificados vários subtimes durante o processo produtivo sejam subtimes de analistas, subtimes de programadores, de testadores, etc. O perfil TW (Team Worker) é entendido que deve ser realçado por algum membro destas subequipes sempre que da existência destas.

Considerações Finais

Tanto a literatura recente de gerenciamento de projetos quanto a literatura da psicologia indicam que existe uma relação positiva entre a adequação do perfil pessoal ao papel funcional e o desempenho do indivíduo na função (Bradley & Herbert, 1997). Ou seja, pessoas tendem a ter melhor desempenho quando estão realizando funções que combinam com seu comportamento natural.

Sendo assim, para os gerentes de projetos, estas recomendações para a alocação de pessoas nos papéis do RUP servem como uma poderosa ferramenta para melhorar diversos aspectos da composição de times de software além de complementar os processos de seleção de pessoal e montagem de times.

Referências:
  • Andrade, P. C. (2000) “Guia de Profissões e Mercado de Trabalho”, Ed. Oriente-se, 1ª edição.
  • Aritzeta, A., Swailes, S. and Senior, B., (2005) “Team Role Preference and Cognitive Styles". Small Group Research, Vol. 36, No. 4, 404-436.
  • Belbin, M.R. (1981) “Management Teams: Why they succeed or Fail”, Butterworth-Heinemann Ltd.
  • Belbin, M.R. (1993) “Team Roles at Work”, Elsevier Butterworth-Heinemann Ltd.
  • Biddle, B.J. (1979) “Role theory: Expectations, identities, and behaviors”. New York: Academic Press.
  • Bradley, John H. and Herbert, Frederic J. (1997), “The effect of personality type on team performance”, Journal of Management Development, Vol. 16, No. 5, pp. 337-353, MCB University Press.
  • Fernandes, Flávio L.M. e da Silva, Fabio Q.B. (2007) “Relações entre Competências Pessoais e Tipos de Personalidade do Gerente de Projetos de Software”, II Congresso de Gerenciamento de Projetos, PMI.
  • Ferreira, Henrique S. (2007) “Um Estudo Da Adequação De Personalidades E Papéis Na Metodologia Scrum De Desenvolvimento De Software”. Trabalho de graduação apresentado no Centro de Informática-CIn da UFPE.
  • França, A. César C. e da Silva, Fabio Q. B. (2007) “Um estudo sobre Relações entre Papéis Funcionais do RUP e o Comportamento Pessoal no Trabalho em Equipe em Fábricas de Software”. III Workshop Um Olhar Sociotécnico sobre a Engenharia de Software – WOSES.
  • Gorla, N. and Lam, Y.W., (2004). “Who Should Work With Whom? Bulding Effective Software Project Teams”. Communications of the ACM, Vol. 47, No. 6, pp. 79-82.
  • Karn, J. and Cowling, T. (2006) “A Follow up Study of the Effect of Personality on the Performance of Software Engineering Teams”. Proceedings of the 2006 ACM/IEEE International Symposium on Empirical Software Engineering (ISESE’06), Rio de Janeiro, Brazil, pp. 232-241.
  • Kruchten, P. (2003) Introdução ao RUP – Rational Unified Process, Rio de Janeiro: Editora Ciência Moderna Ltda.
  • Rajendran, M. (2005) “Analysis of team effectiveness in software development teams working on hardware and software environments using Belbin Self-perception Inventory”, Journal of Management Development, Vol. 24 No. 8, pp. 738-753, Emerald Group Publishing Limited, 0262-1711, DOI 10.1108/02621710510613753.
  • Sawyer, S. (2004) “Software Development Teams”. Communications of the ACM, Vol. 47, No. 12, pp. 95-99.
  • Young, S.M. et al. (2005) “Personality Characteristics in an XP Team: A Repertory Grid Study”. ACM Workshop on Human and Social Factors of Software Engineering (HSSE), ACM SIGSOFT Software Engineering Notes Vol. 30 , Issue 4.