Sucesso na Adoção da Programação em Par

Em três anos e meio como consultor, eu gastei mais tempo conversando (com clientes) sobre programação em par do que sobre qualquer outro assunto. Geralmente, os desenvolvedores do cliente nunca haviam programado em par da maneira correta e não queriam fazer isso. Para piorar as coisas, o pensamento predominante no meio corporativo é que é um desperdí­cio ter duas pessoas trabalhando num mesmo computador.

Apesar dos preconceitos, normalmente quando saí­amos de um cliente os desenvolvedores e a empresa tinham tornado-se a favor da programação em par.

Adotar a programação em par com sucesso pode ser difí­cil mas é perfeitamente possí­vel se você levar em conta as lições que eu aprendi.

Esse artigo assume que você já praticou a programação em par e está procurando ajudar sua empresa a adotá-la aonde faz sentido. O conselho pode ser útil para pessoas em vários papéis; entretanto, o artigo foi escrito principalmente para desenvolvedores ou equipes que estão procurando adotar a programação em par.

Esse artigo não tenta explicar se você deveria ou não adotá-la. Existem benefí­cios e problemas nesse processo (como na maioria das coisas), e eu penso que já existe informação suficiente abordando esse assunto. Discutir os prós e contras da programação em par está fora do escopo desse artigo que é "se você já acredita na programação em par, como adotá-la com sucesso na sua equipe?"

Computadores para os Pares

Pela minha experiência, o maior passo para a adoção com sucesso da programação em par é usar os computadores apropriados para essa finalidade. Minha configuração preferida para os pares é mias ou menos como está descrita abaixo; no entanto, você pode personalizá-la conforme sua própria necessidade.

• Mesas lisas, de forma que as duas pessoas possam sentar-se confortavelmente uma ao lado da outra. Net Pryce também teve sucesso com mesas redondas. Escrivaninhas curvas não são confortáveis para duas pessoas, e deveriam ser evitadas.
• O computador mais rápido que você puder comprar para um ambiente de desenvolvimento. Se os computadores para os pares forem melhores que os individuais, há mais chance de serem usados. Além disso, se você vai comprar um computador ao invés de dois, é possí­vel gastar um pouco mais nele.
• Uma placa de ví­deo com uma saí­da DVI dupla. Os splitters funcionam, mas não muito bem. É muito melhor ter um DVI duplo para conseguir a resolução máxima.
• 2 monitores de 24 ou de 30 polegadas. Dois monitores grandes são muito bons para clonar (ou espelhar) seu desktop. O resultado (quando combinado com dois teclados e dois mouses) é que cada pessoa sente-se como se estivesse sozinho em sua própria estação.
• 2 teclados e 2 mouses. Tenha ambos, para que quem goste possa usá-los. Mas saiba que algumas pessoas preferem usar somente um teclado e um mouse.

A ideia é criar o melhor ambiente de trabalho possí­vel, mas tão confortável como se fosse seu próprio computador.

Já é difí­cil convencer alguém a deixar sua mesa (e seus headphones) para trás. E pedir a ela que faça isso e que, para piorar, trabalhe em um ambiente pior do que o anterior, parece uma tolice. Para equilibrar a situação, forneça um computador para o par que seja tão convidativo, a ponto de as pessoas quererem largar seus computadores pessoais.

Conseguir uma boa estação de trabalho para o par é o primeiro grande passo. Entretanto, também é importante configurá-la corretamente. No passado eu tive um resultado muito bom quando criei uma imagem da estação e a usei para configurar todas as outras da mesma maneira. Também é bom se você puder refazer a imagem das estações semanalmente. Os desenvolvedores vão adicionar novas ferramentas com frequência ou um novo alias para uma estação quando for necessário, mas aquela ferramenta ou alias não serão refletidos nos outros computadores para que as outras pessoas os usem também. Eu descobri que refazer a imagem com certa frequência força os membros das equipes a atualizarem a imagem, ao invés de apenas atualizarem as estações individualmente.

O que é gravado na imagem depende muito da equipe. Teoricamente seria um desastre se você pedisse à equipe para escolher um único editor, layout de desktop, etc. Na prática qualquer pessoa que valoriza seu salário vai querer trabalhar com as ferramentas mais produtivas. Esse conceito pode ser subjetivo, mas normalmente existe uma ferramenta que é melhor. Nos casos que não existe um vencedor óbvio, é mais fácil escolher um padrão e fazer a mudança. O resulado normalmente é muito bom: uma imagem com as melhores ferramentas que garantem a cada membro da equipe ser muito produtivo em qualquer estação para programação em par.

Não espere ter a imagem totalmente correta da primeira vez. Isso não é um problema. A criação da imagem é um processo interativo que a equipe deve estar melhorando continuamente.

Eu também tive bons resultados com espaços emprestados. Quase todo mundo tem uma sala de reunião e estão dispostos a cedê-la quando você promete um ganho de eficiência em torno de 20% (para programação em par e espaços emprestados, um ganho de 20% é muito fácil de alcançar). Na DRW (meu atual local de trabalho) nós retiramos as baias da minha equipe e colocamos mesas. Nós abdicamos de nosso espaço 'pessoal' e criamos um ambiente totalmente voltado aos pares. Se eu quero trabalhar em particular, eu sempre posso levar um laptop para uma dessas salas de reunião.

Eu acredito que sem os computadores apropriados para os pares você pode tropeçar mesmo se seguir todos os outros conselhos desse artigo. Entretanto, vários analistas do artigo discordam de mim. Nós concordamos no seguinte ponto: a coisa mais importante é você retirar qualquer barreira à adoção. Na minha opinião a maior dificuldade é dar às pessoas um ambiente de trabalho confortável, mas como muitos analistas observaram, não há regras claras que sejam aplicadas em todos os casos. 

Foque em um membro da equipe de cada vez

Eu não acredito que seja possí­vel forçar uma pessoa a formar um par. Algumas pessoas gostam, outras não. Entretanto, você não fará amigos se forçá-los.

Eu tive muito mais sucesso usando a abordagem de "comer pelas beiradas". Geralmente eu inicio formando um par com alguém que ainda não está convencido, mas aberto à ideia. Não demora muito até que ele prefere trabalhar em par do que sozinho. Nesse momento eu sei que posso trabalhar com a próxima pessoa que está aberta à ideia. Eu sempre pego a fruta mais baixa e aos poucos vou alcançando a pessoa que está menos aberta à ideia dos pares.

O que acontece na maioria das vezes é que eu nunca chego à pessoa menos aberta aos pares. Uma das duas coisas normalmente acontecem antes de eu chegar nelas:

• Elas percebem que toda a equipe está trabalhando muito mais rápido e perguntam se também podem participar.
• Elas notam que toda a equipe está trabalhando muito mais rápido e acabam pedindo para sair. é óbvio que todo mundo que não acompanha a equipe tem um desempenho pior. Geralmente essas pessoas notam os indí­cios e vão embora.

Pela minha experiência, 90% das pessoas que você quer que fique preferem trabalhar em par. Por outro lado, é muito valioso imaginar como a perda de alguém que não quer trabalhar em par pode impactar seu projeto e a empresa. Algumas vezes faz sentido realocar essas pessoas para posições que não se sintam pressionadas ou ameaçadas. Outras vezes é melhor deixá-las mesmo ir.

Apenas para ser claro, existem muitos bons desenvolvedores que não acreditam no trabalho em par. Meu argumento é que muito provavelmente a maioria deles nunca trabalhou em par da maneira correta. Entretanto, mesmo depois de terem essa experiência, muitos deles irão preferir trabalhar sozinhos. Eu normalmente os classifico como bons profissionais, mas não tão bons para trabalharem em equipes compostas por pessoas que preferem trabalhar em par. A preferência pelos pares não é um indicativo de talento. Da mesma forma que não gostar disso não é um indicador da falta dele.

A longo prazo, eu acredito que é um erro manter visões opostas sobre a programação em par em uma equipe. O que tenho visto é que ambos os lados vêem que a opinião oposta é muito ineficiente. O resultado disso é que pessoas racionais e amigas parecem discutir o tempo todo sobre o assunto e gastam muito tempo argumentando e gerando controvérsias. Eu acredito que existe lugar para ambas as visões em uma empresa, mas não na mesma equipe. Uma parte da adoção com sucesso é ser capaz de identificar aqueles que nunca irão concordar, e não gastar tempo com um objetivo inalcançável.

Troca de par

Se você está trabalhando com alguém que aceita a ideia de trabalhar em par, mas ainda não está convencido, faz sentido trabalhar junto com essa pessoa com certa frequência ou o tempo todo. As primeiras sessões em par são um perí­odo de ajuste e é importante tê-las na melhor situação possí­vel. Entretanto, já que alguém gostou da experiência e está gostando de programar em par, é melhor que ela comece a trabalhar com vários membros da equipe. Pela minha experiência é melhor permanecer em par com a mesma pessoa por um perí­odo de 1 a, no máximo, 2 dias. Essas linhas mestras podem ser influenciadas pelo contexto, mas historicamente elas são constantes para mim.

Existem visões diferentes sobre qual seria o melhor espaço de tempo para permanecer em par com outro companheiro de equipe. Como eu citei acima, eu geralmente fico um dia com meu par, mas nunca mais do que dois dias. Para outros pontos de vista, eu sugiro trocar de par uma vez por iteração e o pareamento aleatório. Ambos são o que eu consideraria extremos, mas tenho que reconhecer que existem contextos onde podem ser uma boa idéia. Trocar de par com frequência vai trazer pelo menos dois grandes benefí­cios.

• As pessoas têm ní­veis diferentes de familiaridade com as ferramentas (i.e. grep, IDEs), domí­nios de negócio, patterns, testes, etc. Por isso, faz sentido trabalhar com algum expert na área que você precisa implementar sua solução.
• Trabalhando com diferentes companheiros, permitirá que você equilibre melhor a quantidade de tempo gasta sendo um aprendiz ou um mentor.

Os benefí­cios da troca de pares nos leva à maior eficiência, o que nos ajuda a obter sucesso na transição.

Quem deveria guiar

As pessoas iniciantes na programação em par sempre perguntam: "vocês não acabam digitando ao mesmo tempo?" A resposta curta e simples é "não". Se existem situações em que alguém está digitando de mais ou de menos, a solução pode ser encontrada pelo Ping Pong.

Ping Pong é onde as duas pessoas se alternam escrevendo testes e implementações. O nome mais detalhado, Ping Pong Pair Test Development, é provavemente mais apropriado, mas não muito prático. O workflow da dupla seria algo assim:

1. O desenvolvedor 1 (D1) escreve um teste que vai quebrar.
2. O desenvolvedor 2 (D2) faz o teste passar implementando apenas o estritamente necessário.
3. D2 escreve um teste que vai quebrar.
4. D1 faz esse teste passar implementando apenas o estritamente necessário.
5. Volte ao passo 1. Continue nesse processo até a atividade terminar.

O Ping Pong pode ter bom resultado durante a fase de introdução da Programação em Par. Entretanto, depois de alguns dias eu penso que 'quem deveria estar digitando' deve ser determinado pelo papel que cada pessoa estiver desempenhando.

O Mentor

Em praticamente todas as atividades, uma dupla geralmente tem uma pessoa que conhece mais do que a outra a respeito do problema em questão. Nesse caso, geralmente é melhor que a pessoa que conhece menos conduza o trabalho. O mentor precisa mudar a forma de pensar de "eis o que eu faria para resolver esse problema" para "como posso levar meu companheiro à solução correta". Quando você estiver com o papel de mentor, é muito mais importante ser um professor do que um implementador. Você conhece o ditado: "Dê um peixe a um homem, e vai alimentá-lo por um dia. Ensine-o a pescar e irá alimentá-lo pelo resto da vida".

Observação: eu tenho percebido que esses papéis ajudam durante o aprendizado, adoção e estabilização do método. Quando você estiver aprendendo e adotando a programação em par, reconhecer que é um mentor e efetivamente transferir conhecimento para seu parceiro, pode permitir a construção de um alto nível de confiança entre vocês dois. Durante a fase de estabilização do processo, ser o mentor permite que você transfira conhecimento ao mesmo tempo que caminha para o completamento da solução.

Enquanto você estiver no papel de mentor, é bom considerar a visão geral e seu caminho atual. Você pode pensar em uma maneira simples para resolver o problema agora. Mas se encontrar um modo melhor de resolvê-lo, ensine ao seu companheiro como completar a tarefa usando a primeira ideia (com tempo determinado, se for necessário), e então lance rapidamente a outra ideia. Se essa realmente for melhor, garanta que seu companheiro entenda o motivo da mudança. Se for pior, é possí­vel voltar rapidamente à solução original.

O aprendiz

Se existe um mentor, a outra pessoa deve ser um aprendiz. Como aprendiz você tem apenas uma tarefa. Tome o controle do computador, discuta o problema até que você entenda-o e implemente a solução mais óbvia para você. Se sua solução for viável, o mentor deveria estar preparado a lhe ajudar com o que for necessário. Se sua solução não for tão boa, deveria ser fácil para o mentor mostrar as limitações da sua ideia e guiá-lo na direção da melhor alternativa.

Você não será mentor ou aprendiz para sempre. Eu considero essa classificação válida apenas para a atividade que você está fazendo neste momento. Eu posso ser um expert em Ruby e em Rails e meu parceiro ser especialista em SQL e Javascript. Quando estivermos implementando uma funcionalidade, poderemos trocar os papéis de mentor e de aprendiz muitas vezes. O importante é reconhecer quando a troca ocorre e deixar o aprendiz do momento guiar o teclado e o mouse.

Como regra geral, o aprendiz deveria conduzir na maior parte do tempo.

Um parceiro desinteressado e distraí­do

Algumas vezes seu parceiro não está muito interessado com a tarefa que vocês estão fazendo. Não é bom para nenhum dos dois trabalhar com uma pessoa desinteressada. O maior benefí­cio da programação em par é alcançar a melhor solução quando dois desenvolvedores colaboram entre si. Logicamente, um desenvolvedor desinteressado não está colaborando. Por consequência, a solução é inferior. No mí­nimo, a solução é tão boa quanto seria sem o par, e o tempo de 1 pessoa foi completamente desperdiçado.

Existem várias razões para o desinteresse do parceiro. Entretanto, descobrir esses motivos é uma questão pessoal que não pode ser satisfatoriamente respondida com uma fórmula genérica.

Um parceiro distraí­do, como o nome sugere, é uma pessoa que tem a atenção desviada facilmente pelo ambiente à sua volta. Essas pessoas tendem a aplicar menos tempo digitando, porque elas estão sempre ocupadas ajudando os outros. Os parceiros distraídos não são inúteis. De fato, eles contribuem muito com o código que seu parceiro está construindo. Entretanto, raramente eles contribuem com a totalidade de seu potencial porque estão sempre tentando resolver os problemas dos outros, ao mesmo tempo. Os parceiros distraí­dos podem gastar muito tempo lendo emails e fazendo outras tarefas secundárias.

Joel Spolsky acredita que um espaço de trabalho aberto é divertido, mas não produtivo. Apesar de não concordar com ele, eu consigo ver como alguns parceiros distraí­dos poderiam fazer um gerente chegar facilmente a essa conclusão.

Eu já fui um parceiro distraí­do. E também trabalhei com muitos deles. Eu acredito que isso acontece com todos nós, de tempos em tempos. No passado, eu vi as pessoas distraí­das serem gerenciadas pela criação de regras. Por exemplo: "nenhum notebook pessoal na sala de desenvolvimento". Essa regra pode amenizar o problema, mas cria outros.

O maior problema com parceiros desinteressados ou distraí­dos é que eles não estão participando 100% da programação em par, contradizendo, dessa forma, muitos ganhos de produtividade. Se você se vir ao lado de um parceiro desinteressado ou distraí­do, aí­ vão algumas dicas que podem ajudá-lo.

Meu método preferido para lidar com um parceiro distraí­do é praticar o Ping Pong. o Ping Pong força os dois a prestarem atenção o tempo todo. Um elemento legal nessa abordagem é que ela não exige nenhuma regra adicional que poderia trazer efeitos colaterais. A programação usando o Ping Pong ajuda a transformar um parceiro desinteressado em um parceiro colaborador. Por outro lado, a contribuição dele não é a máxima possí­vel. Eu descobri que ao lidar com um parceiro desinteressado, na verdade, é melhor você fingir que está perdido.

Tomar essa atitude pode ser chato, muito chato. Geralmente você tem uma ideia do que precisa ser feito ou está com a solução na cabeça. Você pode implementá-la sozinho e levar o parceiro desinteressado na carona. Infelizmente tenho visto que é exatamente isso o que acontece. Deixá-lo de lado, na carona, não é a melhor alternativa a longo prazo. Pode ser que um dia seu parceiro tenha que melhorar a solução que você construiu. Se ele não puder, simplesmente porque não prestou atenção, você vai ter que largar o que estiver fazendo para ajudá-lo. Pior ainda, você pode nem estar mais na equipe e o contexto do código estará definitivamente perdido.

Portanto, fingir estar confuso é chato, mas contribui para o melhor interesse da equipe. Ao invés de implementar a soluão, pergunte ao seu companheiro: "Como vamos resolver esse problema?" Não aceite a primeira resposta. Normalmente ela será rápida, mas inacreditavelmente esquisita. Contribua com suas sugestões, mas não deixe-o saber que você já tem a solução. Pelo contrário, continue fazendo perguntas. Existe a possibilidade de você entender a solução do seu parceiro. Se isso acontecer, finja que não entendeu. Force-o a escrever os 3 primeiros testes e a implementar o código que faz os testes passarem. Nesse momento, tome o controle e escreva um teste, mas deixe-o implementar a solução. Depois, aos poucos, vá fazendo a transição para o Ping Pong, mas não faça essa mudança rapidamente. Ao invés disso, faça com que seu parceiro desinteressado codifique cerca de 65% da solução. Não vai demorar muito para que ele transforme-se em uma peça ativa e importante no processo, beneficiando a vocês dois.

O parceiro corretor ortográfico

Grandes lacunas de conhecimento podem transformar um parceiro em nada mais do que apenas um corretor ortográfico. Eu tenho visto isso ao longo de anos. No entanto, aconteceu comigo recentemente. Eu comecei em um novo trabalho e, no meu segundo dia, formei um par com um dos caras mais seniores da empresa, para implementar em Java uma biblioteca que ele tinha escrito anteriormente para .Net. Eu era novo nesse domí­nio de conhecimento. Eu nunca havia feito nada profissional em Java. Eu nunca havia visto a versão .Net dessa biblioteca. Eu nunca tinha usado o sistema de mensagens com o qual a biblioteca interagia. Eu nunca havia usado IntelliJ para codificar Java. E por aí­ vai.

Eu era um inútil para meu parceiro. A tarefa tinha um prazo apertado, e a diferença de conhecimento entre nós era tão grande que eu estava reduzido ao silêncio, exceto quando percebia algum erro de digitação. Eu digitei um pouquinho, mas foi basicamente fazendo o que meu parceiro mandava.

Apesar de eu referir trabalhar em par, se um companheiro não está ajudando em nada mais além de corrigir os erros de digitação, provavelmente esta não é a melhor alternativa de composição da equipe. Além disso, quando um companheiro experiente precisa desacelerar para explicar as coisas, a tarefa vai acabar demorando mais para terminar. Quando a diferença de conhecimento pode ser transposta, normalmente o trabalho transcorrerá da melhor maneira possí­vel. Entretanto, quando essa diferença é tão grande a ponto de não poder ser diminuí­da e afeta o prazo de entrega da tarefa, o par deve ser dividido.

Quando não formar pares

Existem várias situações nas quais faz sentido não formar um par, além da citada anteriormente, onde um parceiro é reduzido à tarefa de correção ortográfica. Outras situações comuns podem ser:

• Quando ler sobre uma biblioteca ajudará no futuro
• Melhorar uma solução complexa ou depurar um erro difí­cil com alguém que tem muito menos experiência. Geralmente não é ideal formar pares que precisem combinar exploração da solução com nivelamento de conhecimento.

É importante lembrar que essas situações não são as melhores oportunidades para a programação em par. Isso não significa que os pares não possam ser formados quando tiver que realizá-las. Assim sendo, você deve ter em mente que um dos parceiros pode não ficar muito interessado ou ser capaz de ajudar. Uma das maneiras de atrapalhar a adoção da programação em par é colocar alguém em uma posição que não possa ajudar.

Nem toda tarefa precisa de um par, mas a quantidade das que precisam é infinitamente maior do que a quantidade das que não precisam.

Quando Dan North revisou esse artigo, ele assinalou: Talvez não seja a quantidade de tarefas, mas sim o tipo delas. Qualquer atividade normal de desenvolvimento (programar, escrever os testes, projetar) tende a ter maior qualidade quando são feitas em par. Para as tarefas que não compõem o dia-a-dia do desenvolvimento, como pesquisa, melhoria, administração de ambiente, não dão um bom retorno. Portanto, é melhor não fazê-las em par.

Tempo reservado para trabalhar em par

Em geral, se você concluir que é melhor fazer sua atividade atual sozinho, separe o par imediatamente. Em contrapartida, eu tenho visto como uma boa prática, definir um intervalo de tempo no dia que você pode trabalhar em par (o tempo reservado). Normalmente esse espaço de tempo fica entre 60% e 70% do seu dia total de trabalho. Por exemplo, se você trabalha das 8:00 às 17:00, seu tempo reservado seria de 10:00 às 16:00.

Durante esse horário, você não é obrigado a formar o par (você nunca deveria "ser obrigado" a isso). Mas você deveria estar disponí­vel para um par. Se você estiver fazendo uma atividade que é melhor desempenhada sozinho, então não forme um par. Se você não estiver com um par, mas está fazendo uma atividade que é melhor com um parceiro, procure um ou ofereça-se para realizar a tarefa junto de outra pessoa. Também é útil (quando possí­vel) jogar as atividades "solitárias" para fora desse horário reservado para os pares. Por exemplo, se você recebe a solicitação para corrigir um defeito de prioridade média às 14:00 e seu parceiro não sabe nada a respeito da rotina que deu erro, provavelmente será melhor esperar até as 16:00 para tentar resolver esse problema.

O tempo reservado para trabalhar em par também é legal porque propicia uma certa flexibilidade no horário de trabalho.

A maior objeção para o trabalho em par é que as pessoas "precisam de seu tempo individual" e não são "capazes de trabalhar em par 8 horas por dia". Eu acho esse argumento engraçado porquê eu nunca imaginei alguém trabalhando em par durante todo um expediente, e acho que todo mundo precisa de sua individualidade. Eu prefiro destinar 70% do meu tempo ao trabalho em par. Mas tenho alguns amigos que preferem 60% e outros 95%. Eu não sei quem está certo, mas é importante formar os pares quando for vantajoso, e separá-los quando não for.

A coisa mais simples que pode funcionar

"Fazer a coisa mais simples que pode funcionar" é a frase mais conhecida da maioria dos desenvolvedores ágeis, mas nem sempre é fácil saber como praticá la. Se você fizer algo muito simples, pode ser criticado por ter uma visão muito curta. Entretanto, se você faz alguma coisa mais complexa, será criticado por gastar seu tempo e o de quem precisar dar manutenção na sua solução. A programação em par pode dar-lhe a confiança de que sua solução é simples e ao mesmo tempo suficientemente robusta para funcionar.

Quanto estiver trabalhando em par, tenha a determinação de buscar a coisa mais simples que vai funcionar. Num par existe a possibilidade de vocês estarem criando inteligentemente uma solução elegante que vai ser usada de verdade. Buscando a solução mais simples, você estará apto a criar funcionalidades rapidamente e gastar menos tempo dando manutenção nas existentes. Esse ganho de eficiência deveria ajudar a impulsionar a ideia de adoção da programação em par.

Revisão obrigatória do código

Se você quer melhorar a qualidade do código, outra pessoa da equipe deveria revisá-lo. De fato, algumas leis (SOX, HIPPA) exigem que todo código de produção seja revisado. Se você está pensando em adotar a programação em par, mas é esperto o suficiente para reconhecer que a imposição dessa ideia não vai funcionar, você deveria impor a revisão do código (para todos os códigos de produção). Para satisfazer o requisito de revisão de código, você poderia optar pela revisão convencional ou pela programação em par. A maior diferença entre as duas alternativas é que a primeira é crí­tica e tem a conotação de propriedade e de defesa, enquanto a outra é colaborativa. Ter seu código revisado é quase sempre um processo doloroso, e não demora muito para as pessoas optarem por fazerem os pares, quando identificam que é melhor assim.

Obrigar alguma coisa é sempre um risco grande, e eu só faria isso como última alternativa.

Conclusão

Ser "permitido" a formar pares não é sucesso. O sucesso é alcançado quando a equipe gosta do trabalho em par e torna-se mais produtiva por causa disso. Se você abordar a adoção desse ponto de vista, terá uma chance maior de sucesso. Entretanto, ao aplicar as ideias acima, tente implementá-las de um jeito que estejam focadas no fortalecimento e na eficiência da equipe.