<\/a><\/noindex>Em segundo lugar, em uma situa\u00e7\u00e3o de conflito no trabalho, as partes est\u00e3o diante da resolu\u00e7\u00e3o de uma quest\u00e3o importante para uma das partes, para ambas ou para a organiza\u00e7\u00e3o como um todo. Nesse contexto, devido \u00e0s especificidades da situa\u00e7\u00e3o, as partes geralmente t\u00eam tempo suficiente e v\u00e1rios modos de resolver o problema (formais, informais, reuni\u00f5es, cartas, decis\u00f5es da lideran\u00e7a, exist\u00eancia de objetivos e planos da equipe, fato de haver hierarquia, etc.). Isso difere da situa\u00e7\u00e3o de resolver uma quest\u00e3o de trabalho (ou n\u00e3o) na organiza\u00e7\u00e3o, por exemplo, de resolver uma quest\u00e3o importante: \u201cEi, cara, de qual bairro voc\u00ea \u00e9?!\u201d na rua, ou de um conflito como o do ep\u00edgrafo. No caso da resolu\u00e7\u00e3o de uma quest\u00e3o de trabalho, a qualidade do processo de trabalho e a cultura de resolu\u00e7\u00e3o de quest\u00f5es na equipe s\u00e3o importantes.<\/p>\n
Em terceiro lugar, um fator determinante do conflito (do ponto de vista da nossa discuss\u00e3o) \u00e9 o fato de que as partes do processo n\u00e3o conseguem chegar a uma solu\u00e7\u00e3o que satisfa\u00e7a a todos. A situa\u00e7\u00e3o exige a interven\u00e7\u00e3o de uma terceira parte, um \u00e1rbitro externo. Este ponto pode parecer controverso, mas, em ess\u00eancia, se a situa\u00e7\u00e3o de conflito foi resolvida com sucesso sem a interven\u00e7\u00e3o de um \u00e1rbitro externo, a quest\u00e3o foi resolvida com sucesso e as rela\u00e7\u00f5es entre as partes n\u00e3o se deterioraram, essa \u00e9 a situa\u00e7\u00e3o a que devemos aspirar. Provavelmente, n\u00e3o saberemos sobre um conflito como esse, ou saberemos acidentalmente ap\u00f3s sua resolu\u00e7\u00e3o. Quanto mais quest\u00f5es a equipe puder resolver de forma independente, mais eficaz ela ser\u00e1.<\/p>\n
Outra caracter\u00edstica do conflito que vale a pena mencionar \u00e9 o grau de tens\u00e3o emocional durante a resolu\u00e7\u00e3o. O conflito n\u00e3o est\u00e1 necessariamente ligado a um alto grau de emo\u00e7\u00e3o. Os participantes n\u00e3o precisam gritar e acenar com as m\u00e3os para que a situa\u00e7\u00e3o seja, na ess\u00eancia, conflituosa. Se a quest\u00e3o n\u00e3o \u00e9 resolvida, e uma certa tens\u00e3o emocional est\u00e1 presente (talvez n\u00e3o expressa externamente de forma clara), ent\u00e3o temos uma situa\u00e7\u00e3o de conflito.<\/p>\n
\u00c9 necess\u00e1rio intervir em situa\u00e7\u00f5es de conflito ou \u00e9 melhor deixar que a resolu\u00e7\u00e3o aconte\u00e7a naturalmente e esperar que o problema se resolva por conta pr\u00f3pria? Sim, \u00e9 necess\u00e1rio. Nem sempre est\u00e1 em seu poder ou compet\u00eancia resolver completamente um conflito, mas em qualquer situa\u00e7\u00e3o, em um conflito de qualquer escala, voc\u00ea pode assumir uma posi\u00e7\u00e3o madura, assim influenciando ainda mais algumas pessoas ao seu redor, amenizando as consequ\u00eancias negativas do conflito e contribuindo para sua resolu\u00e7\u00e3o.<\/p>\n
Antes de discutirmos alguns exemplos de situa\u00e7\u00f5es de conflito, vamos abordar alguns pontos importantes que s\u00e3o comuns a todos os conflitos.<\/p>\n
Ao resolver um conflito, \u00e9 importante estar fora da disputa, e n\u00e3o envolvido nela (isso tamb\u00e9m \u00e9 conhecido como \"assumir uma meta posi\u00e7\u00e3o\"), ou seja, n\u00e3o se colocar lado a lado com uma das partes. Caso contr\u00e1rio, em vez de atuar como um \u00e1rbitro externo ajudando na resolu\u00e7\u00e3o, voc\u00ea apenas fortalecer\u00e1 a posi\u00e7\u00e3o de uma das partes em detrimento da outra. Ao tomar uma decis\u00e3o, \u00e9 crucial que ela seja moralmente aceita por todas as partes, como diz o ditado, \"comprada\". Assim, mesmo que as partes n\u00e3o fiquem entusiasmadas com a decis\u00e3o tomada, elas pelo menos concordar\u00e3o sinceramente em cumpri-la. O que se chama de estar em um estado de discordar e se comprometer. Caso contr\u00e1rio, o conflito simplesmente mudar\u00e1 de forma, o fogo smouldering continuar\u00e1 debaixo das cinzas e, em algum momento, inevitavelmente reatar\u00e1.<\/p>\n
O segundo ponto, parcialmente relacionado ao primeiro, \u00e9 que se voc\u00ea decidiu participar da resolu\u00e7\u00e3o do conflito, trate isso com a m\u00e1xima seriedade em termos de comunica\u00e7\u00e3o e compreens\u00e3o do contexto. Converse pessoalmente com cada uma das partes. Comece separadamente com cada uma. N\u00e3o se contente com e-mails. No caso de uma equipe distribu\u00edda, pelo menos converse por videoconfer\u00eancia. N\u00e3o se contente com rumores e relatos de testemunhas. Entenda a hist\u00f3ria, o que cada parte quer, por que quer, o que espera, se j\u00e1 tentaram resolver a quest\u00e3o antes, o que acontecer\u00e1 se n\u00e3o for resolvido, quais op\u00e7\u00f5es de solu\u00e7\u00e3o veem, como imaginam a posi\u00e7\u00e3o da outra parte, o que consideram certo ou errado, etc. Carregue em sua mente todo o contexto poss\u00edvel, de forma imparcial, presumindo que todos t\u00eam raz\u00e3o. Voc\u00ea n\u00e3o est\u00e1 dentro do conflito, voc\u00ea est\u00e1 fora dele, em uma posi\u00e7\u00e3o meta. Se o contexto estiver dispon\u00edvel apenas em um thread de e-mail, leia pelo menos todo o conte\u00fado e as discuss\u00f5es relacionadas e documentos. Depois de ler, ainda assim converse pessoalmente. \u00c9 quase garantido que voc\u00ea ouvir\u00e1 algo importante que n\u00e3o est\u00e1 nos e-mails.<\/p>\n
Um terceiro ponto importante \u00e9 a abordagem geral da comunica\u00e7\u00e3o. Estas s\u00e3o coisas comuns, nada elaborado, mas que t\u00eam um grande significado. N\u00e3o tente economizar tempo, converse com todos os participantes, critique n\u00e3o a pessoa, mas as consequ\u00eancias de suas a\u00e7\u00f5es (n\u00e3o dizer 'voc\u00ea foi rude', mas 'talvez as pessoas possam se ofender com isso'), d\u00ea oportunidades para manter a dignidade, realize as discuss\u00f5es pessoalmente, e n\u00e3o na frente do grupo.<\/p>\n
Os conflitos geralmente s\u00e3o causados por uma das duas raz\u00f5es. A primeira est\u00e1 relacionada a estar a pessoa na posi\u00e7\u00e3o de adulto ou na posi\u00e7\u00e3o de crian\u00e7a no momento do conflito (sobre isso mais abaixo). Isso est\u00e1 ligado \u00e0 sua maturidade emocional, \u00e0 capacidade de gerenciar suas emo\u00e7\u00f5es (o que, ali\u00e1s, n\u00e3o est\u00e1 sempre relacionado \u00e0 sua idade). A segunda raz\u00e3o comum \u00e9 a imperfei\u00e7\u00e3o do processo de trabalho, que cria situa\u00e7\u00f5es de zonas cinzentas, nas quais a responsabilidade est\u00e1 difusa entre os participantes, e as expectativas das partes n\u00e3o s\u00e3o transparentes entre si, pois os pap\u00e9is no processo est\u00e3o indefinidos. <\/p>\n
Portanto, ao resolver um conflito (assim como qualquer outra quest\u00e3o), o gerente deve considerar tr\u00eas perspectivas: a de curto prazo \u2014 resolver a quest\u00e3o\/conflito aqui e agora, a de m\u00e9dio prazo \u2014 minimizar a probabilidade de outro conflito surgir pela mesma raz\u00e3o, e a de longo prazo \u2014 cultivar uma cultura de adultidade na equipe. <\/p>\n
Dentro de cada um de n\u00f3s, existe uma crian\u00e7a interior, com cerca de tr\u00eas a quatro anos. A maior parte do tempo, ela est\u00e1 dormindo no trabalho, mas \u00e0s vezes acorda e assume o controle. Esta crian\u00e7a tem suas pr\u00f3prias prioridades. \u00c9 importante para ela afirmar que este \u00e9 seu castelo de areia, que a mam\u00e3e o ama mais, que seu carrinho \u00e9 o melhor de todos (o design \u00e9 o melhor, ele programa melhor que os outros, \u2026). Em uma situa\u00e7\u00e3o de conflito, a crian\u00e7a pode apertar seus brinquedos, bater os p\u00e9s e agitar a p\u00e1, mas ela n\u00e3o pode resolver quest\u00f5es adultas (arquitetura da solu\u00e7\u00e3o, abordagens para testes autom\u00e1ticos, prazos de lan\u00e7amento, etc.), ela n\u00e3o pensa em termos de benef\u00edcios para a equipe. A crian\u00e7a em um conflito pode ser confortada, acalmada e enviada para dormir, pedindo para chamar seu adulto. Antes de come\u00e7ar a discuss\u00e3o em um contexto de conflito, certifique-se de que voc\u00ea est\u00e1 conversando com um adulto, e n\u00e3o com a crian\u00e7a, e que voc\u00ea mesmo est\u00e1 na posi\u00e7\u00e3o de um adulto. Se seu objetivo honesto neste momento \u00e9 resolver uma quest\u00e3o s\u00e9ria, voc\u00ea est\u00e1 na posi\u00e7\u00e3o de um adulto. Se seu objetivo \u00e9 bater os p\u00e9s e agitar a p\u00e1 \u2014 essa \u00e9 uma posi\u00e7\u00e3o infantil. Coloque sua crian\u00e7a interior para dormir e chame o adulto, ou adie a discuss\u00e3o. As pessoas tomam decis\u00f5es emocionais e depois buscam uma justificativa racional. A decis\u00e3o, tomada pela crian\u00e7a, com base em prioridades infantis, n\u00e3o ser\u00e1 otimizada.<\/p>\n
Al\u00e9m do comportamento em momentos de conflito, a posi\u00e7\u00e3o infantil ou adulta \u00e9 tamb\u00e9m caracterizada pelo n\u00edvel de responsabilidade que a pessoa est\u00e1 disposta a assumir. Nos casos extremos, a posi\u00e7\u00e3o infantil de um programador, que encontrei v\u00e1rias vezes, se manifesta assim: eu escrevi o c\u00f3digo, enviei para revis\u00e3o \u2014 meu trabalho est\u00e1 conclu\u00eddo. Os revisores devem analis\u00e1-lo e mescl\u00e1-lo, a QA deve test\u00e1-lo, se houver problemas \u2014 eles me informar\u00e3o. Estranhamente, at\u00e9 pessoas bastante adultas e experientes \u00e0s vezes se comportam dessa forma. O outro extremo da escala \u00e9 quando a pessoa se considera respons\u00e1vel pelo seu c\u00f3digo funcionar, estar coberto por testes, ter sido verificado pessoalmente, passar com sucesso pela revis\u00e3o (se necess\u00e1rio, sem problemas em contatar os revisores, discutir quest\u00f5es por voz, etc.) e ser mesclado, com a QA recebendo ajuda se necess\u00e1rio, cen\u00e1rios de testes ser\u00e3o descritos, etc. Normalmente, um programador est\u00e1 mais pr\u00f3ximo do lado adulto da escala desde o in\u00edcio ou se desloca para l\u00e1 conforme acumula experi\u00eancia (desde que a equipe cultive a cultura correta). Em casos extremos, ele continua a trabalhar frequentemente assumindo a posi\u00e7\u00e3o infantil, ent\u00e3o ele e a equipe enfrentam problemas e conflitos periodicamente.<\/p>\n
Cultivar uma cultura correta e madura na equipe \u00e9 uma tarefa importante para qualquer gerente. Isso exige tempo e esfor\u00e7o di\u00e1rio, mas o resultado vale a pena. Existem duas maneiras de influenciar a cultura da equipe \u2014 pelo exemplo pessoal (que ser\u00e1 seguido, a equipe sempre observa o l\u00edder) e pela discuss\u00e3o e incentivo do comportamento adequado. Aqui tamb\u00e9m n\u00e3o h\u00e1 nada de complicado ou excessivamente formal, apenas ao discutir problemas, observe como poderia ter sido feito de outra forma, destaque quando perceber que a decis\u00e3o foi correta, elogie, mencione durante a an\u00e1lise de lan\u00e7amento, etc.<\/p>\n
Vamos considerar algumas situa\u00e7\u00f5es de conflito t\u00edpicas, do simples ao complexo:<\/p>\n
Conflitos n\u00e3o relacionados a quest\u00f5es de trabalho<\/b><\/p>\n
Frequentemente, ocorrem conflitos no trabalho que n\u00e3o est\u00e3o relacionados a quest\u00f5es de trabalho. Sua ocorr\u00eancia e a facilidade de resolu\u00e7\u00e3o geralmente est\u00e3o diretamente ligadas ao n\u00edvel de intelig\u00eancia emocional dos participantes, ao n\u00edvel de maturidade deles, e n\u00e3o est\u00e3o relacionadas \u00e0 perfei\u00e7\u00e3o ou imperfei\u00e7\u00e3o do processo de trabalho.<\/p>\n
Exemplos t\u00edpicos incluem algu\u00e9m que n\u00e3o usa a m\u00e1quina de lavar ou o chuveiro com frequ\u00eancia suficiente, o que desagrada os outros, algu\u00e9m que sente calor e outra pessoa que se incomoda ao abrir a janela, algu\u00e9m que faz muito barulho e os demais precisam de sil\u00eancio para trabalhar, e assim por diante. \u00c9 melhor n\u00e3o procrastinar na resolu\u00e7\u00e3o de conflitos desse tipo e n\u00e3o deixar que a situa\u00e7\u00e3o se desenrole sozinha. Eles n\u00e3o v\u00e3o se resolver por conta pr\u00f3pria e desviar\u00e3o diariamente a aten\u00e7\u00e3o do trabalho e envenenar\u00e3o a atmosfera na equipe. Felizmente, solucionar esses problemas geralmente n\u00e3o \u00e9 complicado \u2014 apenas converse calmamente (claro, um a um) com o colega que desregula a higiene, forne\u00e7a uma disposi\u00e7\u00e3o confort\u00e1vel para aqueles que preferem sil\u00eancio\/refrigera\u00e7\u00e3o, compre fones de ouvido ac\u00fasticos ou instale divis\u00f3rias, etc. <\/p>\n
Outro exemplo que encontrei algumas vezes durante meu trabalho \u00e9 a incompatibilidade psicol\u00f3gica entre os membros da equipe. Por alguma raz\u00e3o, as pessoas simplesmente n\u00e3o conseguem trabalhar juntas, cada intera\u00e7\u00e3o termina em esc\u00e2ndalo. \u00c0s vezes, isso est\u00e1 relacionado ao fato de que as pessoas t\u00eam vis\u00f5es polarizadas sobre uma quest\u00e3o candente (geralmente pol\u00edtica) e n\u00e3o sabem deix\u00e1-las fora do trabalho. Convenc\u00ea-las a suportar uma \u00e0 outra ou mudar seu comportamento \u00e9 uma tarefa bastante ingratificante. A \u00fanica exce\u00e7\u00e3o que encontrei foram os jovens colegas com uma mentalidade aberta, cujo comportamento ainda pode mudar gradualmente por meio de conversas peri\u00f3dicas. Normalmente, a quest\u00e3o \u00e9 solucionada ao separ\u00e1-los em equipes diferentes ou, pelo menos, garantindo que tenham a possibilidade de se cruzar no trabalho com extrema raridade.<\/p>\n
Em todas as situa\u00e7\u00f5es mencionadas, vale a pena conversar pessoalmente com todos os envolvidos, discutir a situa\u00e7\u00e3o, perguntar se eles veem algum problema neste caso, questionar quais, em sua opini\u00e3o, s\u00e3o as poss\u00edveis solu\u00e7\u00f5es e garantir sua participa\u00e7\u00e3o na tomada de decis\u00e3o.<\/p>\n
Do ponto de vista da otimiza\u00e7\u00e3o do fluxo de trabalho (uma perspectiva de m\u00e9dio prazo \u00e0 qual me referi), n\u00e3o h\u00e1 muito a fazer aqui; o \u00fanico ponto de otimiza\u00e7\u00e3o \u00e9 considerar o fator de compatibilidade ao formar a equipe e evitar antecipadamente colocar juntos as pessoas que ir\u00e3o conflitar. <\/p>\n
Do ponto de vista da cultura da equipe, essas situa\u00e7\u00f5es ocorrem com muito menos frequ\u00eancia em equipes com uma cultura madura, onde as pessoas respeitam a equipe e os colegas e sabem como resolver quest\u00f5es de forma aut\u00f4noma. Al\u00e9m disso, conflitos desse tipo s\u00e3o resolvidos com muito mais facilidade (frequentemente de maneira autom\u00e1tica) em equipes onde h\u00e1 um alto n\u00edvel de confian\u00e7a, as pessoas trabalham juntas h\u00e1 muito tempo e\/ou se comunicam frequentemente fora do trabalho.<\/p>\n
Conflitos relacionados a quest\u00f5es de trabalho:<\/b><\/p>\n
Esses conflitos s\u00e3o geralmente causados por ambas as raz\u00f5es ao mesmo tempo, tanto emocionais (quando um dos participantes n\u00e3o est\u00e1 na posi\u00e7\u00e3o adulta) quanto pelas imperfei\u00e7\u00f5es do pr\u00f3prio processo de trabalho. O tipo de conflito mais comum que encontrei s\u00e3o os conflitos durante o processo de revis\u00e3o de c\u00f3digo ou discuss\u00e3o de arquitetura entre desenvolvedores. <\/p>\n
Aqui, eu destacaria dois casos t\u00edpicos:<\/p>\n
1) No primeiro caso, o desenvolvedor n\u00e3o consegue obter a revis\u00e3o de c\u00f3digo de um colega. O patch foi enviado para revis\u00e3o, e nada acontece. \u00c0 primeira vista, n\u00e3o h\u00e1 um conflito claro entre as duas partes, mas, se voc\u00ea pensar bem, \u00e9 de fato um conflito. A quest\u00e3o de trabalho n\u00e3o \u00e9 resolvida, uma das partes (que est\u00e1 aguardando a revis\u00e3o) sente um desconforto evidente. Uma variante extrema desse caso \u00e9 o desenvolvimento em comunidade ou em equipes diferentes, onde o revisor pode n\u00e3o estar interessado naquele c\u00f3digo espec\u00edfico, podendo, devido \u00e0 carga de trabalho ou outras circunst\u00e2ncias, ignorar completamente o pedido de revis\u00e3o, e pode n\u00e3o haver um \u00e1rbitro externo (geral a ambas as partes, o gerente) no local. <\/p>\n
Uma abordagem para resolver isso se relaciona com uma perspectiva de longo prazo e a cultura do adulto. Primeiro, a atividade racional funciona. N\u00e3o se deve esperar que um c\u00f3digo em revis\u00e3o chame a aten\u00e7\u00e3o do revisor por si s\u00f3. \u00c9 necess\u00e1rio ajudar os revisores a not\u00e1-lo. Acione algumas pessoas, fa\u00e7a perguntas na reuni\u00e3o, participe das discuss\u00f5es. \u00c9 evidente que ser insistente pode ajudar mais do que prejudicar, mas o senso comum deve ser empregado. Em segundo lugar, a prepara\u00e7\u00e3o pr\u00e9via \u00e9 essencial. Se a equipe entende o que e por que est\u00e1 acontecendo, para que aquele c\u00f3digo \u00e9 necess\u00e1rio, e o design foi discutido e aprovado previamente por todos, as pessoas ter\u00e3o mais probabilidade de notar esse c\u00f3digo e aceit\u00e1-lo no trabalho. Em terceiro lugar, a autoridade \u00e9 importante. Se voc\u00ea quer que seu c\u00f3digo seja revisado, fa\u00e7a muitas revis\u00f5es voc\u00ea mesmo. Realize revis\u00f5es de qualidade, com verifica\u00e7\u00f5es reais, testes reais e coment\u00e1rios \u00fateis. Se seu nome \u00e9 conhecido na equipe de forma positiva, h\u00e1 mais chances de que seu c\u00f3digo receba aten\u00e7\u00e3o.<\/p>\n
Em termos de fluxo de trabalho, as melhorias poss\u00edveis aqui s\u00e3o a defini\u00e7\u00e3o correta de prioridades, visando ajudar o desenvolvedor a atingir seus objetivos e os objetivos da equipe (fazer revis\u00f5es de outros, escrever e-mails para a comunidade, acompanhar o c\u00f3digo com descri\u00e7\u00f5es de arquitetura, documenta\u00e7\u00e3o, testes, participar de discuss\u00f5es com a comunidade, etc.), evitar que patches fiquem muito tempo na fila, e assim por diante. <\/p>\n
2) O segundo caso comum de conflitos durante a revis\u00e3o de c\u00f3digo ou design s\u00e3o diferentes vis\u00f5es sobre quest\u00f5es t\u00e9cnicas, estilo de codifica\u00e7\u00e3o e escolha de ferramentas. O n\u00edvel de confian\u00e7a entre os participantes, a perten\u00e7a a uma mesma equipe e a experi\u00eancia de trabalho conjunto s\u00e3o aspectos de enorme import\u00e2ncia. O impasse ocorre quando um dos participantes adota uma postura infantil e n\u00e3o tenta entender o que o interlocutor est\u00e1 tentando comunicar. Muitas vezes, tanto a abordagem proposta pelo outro lado quanto a abordagem inicialmente sugerida podem funcionar com sucesso e n\u00e3o importa qual delas seja escolhida. <\/p>\n
Certa vez, um programador da minha equipe (vamos cham\u00e1-lo de Pasha) preparou um patch com mudan\u00e7as no sistema de implanta\u00e7\u00e3o de pacotes, que foi desenvolvido e mantido por colegas do departamento vizinho. Um deles (Igor) tinha uma opini\u00e3o forte sobre como os servi\u00e7os Linux deveriam ser configurados ao implantar pacotes. Essa opini\u00e3o diferia da abordagem sugerida no patch, e eles n\u00e3o conseguiam chegar a um acordo. Como de costume, os prazos estavam apertados, e era necess\u00e1rio chegar a uma solu\u00e7\u00e3o; algu\u00e9m precisava assumir uma postura adulta. Pasha reconheceu que ambas as abordagens tinham m\u00e9ritos, mas queria que sua op\u00e7\u00e3o prevalecesse, j\u00e1 que n\u00e3o havia vantagens t\u00e9cnicas claras em nenhuma das duas op\u00e7\u00f5es. <\/p>\n
Nossa discuss\u00e3o foi mais ou menos assim (muito esquem\u00e1tica, claro, a conversa durou meia hora): <\/p>\n
\u2014 Pasha, temos o freeze de funcionalidade em alguns dias. \u00c9 importante que reunamos tudo e comecemos os testes o mais r\u00e1pido poss\u00edvel. Como podemos passar pelo Igor?
A quest\u00e3o foi resolvida, o lan\u00e7amento foi feito a tempo, o Pasha n\u00e3o estava insatisfeito, pois ele mesmo sugeriu a solu\u00e7\u00e3o e a implementou. O Igor estava mesmo satisfeito, pois sua opini\u00e3o foi considerada e o que ele prop\u00f4s foi executado.<\/p>\n
Outro tipo de conflito semelhante \u00e9 a escolha entre solu\u00e7\u00f5es t\u00e9cnicas\/livrarias\/abordagens em um projeto, especialmente em uma equipe distribu\u00edda. Em um dos projetos, que se posicionava como usando C\/C++, acabou que a gest\u00e3o t\u00e9cnica do projeto era categoricamente contra o uso da STL (Standard Template Library). Essa \u00e9 uma biblioteca padr\u00e3o do idioma que simplifica o desenvolvimento, e nossa equipe estava muito acostumada a us\u00e1-la. Aconteceu que o projeto estava muito mais perto de C do que de C++, o que n\u00e3o inspirava muito a equipe, j\u00e1 que a gest\u00e3o fez um esfor\u00e7o e contratou realmente bons programadores de C++. Ao mesmo tempo, a parte americana da equipe, tanto engenheiros quanto gerentes, trabalhava na empresa h\u00e1 muito tempo e estava acostumada com a situa\u00e7\u00e3o existente, ficando satisfeita. A parte russa da equipe foi reunida h\u00e1 pouco tempo, em algumas semanas (inclusive eu). A parte russa da equipe n\u00e3o queria abrir m\u00e3o da abordagem que estava acostumada para o desenvolvimento.<\/p>\n
Come\u00e7aram intermin\u00e1veis discuss\u00f5es por escrito entre os dois continentes, e-mails de tr\u00eas a quatro telas voavam de um lado para o outro, em distribui\u00e7\u00e3o em grupo e pessoais, de programadores \u2014 para programadores e gerentes. Como costuma acontecer, ningu\u00e9m al\u00e9m dos autores e seus fervorosos apoiadores leu e-mails desse tamanho. As conversas estavam tensas, trocando muitas ideias sobre as vantagens t\u00e9cnicas da STL, qu\u00e3o bem testada e segura ela era, e, em geral, como a vida \u00e9 maravilhosa com ela e como horr\u00edvel \u00e9 sem ela. <\/p>\n
Isso durou bastante tempo, at\u00e9 que finalmente percebi que est\u00e1vamos discutindo os aspectos t\u00e9cnicos da quest\u00e3o, enquanto o problema n\u00e3o era, na realidade, t\u00e9cnico. A quest\u00e3o n\u00e3o estava nas vantagens ou desvantagens do STL ou na complexidade de trabalhar sem ele. O problema era mais organizacional. Precis\u00e1vamos apenas entender como a empresa em que trabalh\u00e1vamos funcionava. Nenhum de n\u00f3s tinha experi\u00eancia anterior em uma empresa desse tipo. O que acontece \u00e9 que, ap\u00f3s o desenvolvimento do c\u00f3digo e seu lan\u00e7amento em produ\u00e7\u00e3o, a manuten\u00e7\u00e3o era feita por pessoas totalmente diferentes de outras equipes, em outros pa\u00edses. Essa enorme equipe de engenharia, que contava com v\u00e1rias dezenas de milhares de engenheiros (no total), s\u00f3 podia permitir-se o m\u00ednimo b\u00e1sico de recursos t\u00e9cnicos, por assim dizer, o minimum minimorum. Tudo que ia al\u00e9m dos padr\u00f5es de engenharia estabelecidos na empresa fisicamente n\u00e3o poderia ser suportado posteriormente. O n\u00edvel da equipe \u00e9 determinado pelo n\u00edvel dos seus membros mais fracos. Depois que entendemos a real motiva\u00e7\u00e3o<\/i> das a\u00e7\u00f5es da equipe americana, essa quest\u00e3o foi retirada da pauta, e todos n\u00f3s juntos desenvolvemos e lan\u00e7amos o produto com os padr\u00f5es adotados pela empresa. Emails e chats, nesse caso, n\u00e3o funcionaram bem; foi necess\u00e1rio v\u00e1rias viagens e muito contato pessoal para chegarmos a um entendimento comum.<\/p>\n
Do ponto de vista do fluxo de trabalho, neste caso espec\u00edfico, seria \u00fatil ter uma descri\u00e7\u00e3o das ferramentas utilizadas, os requisitos para elas, as restri\u00e7\u00f5es sobre a adi\u00e7\u00e3o de novas, e a justificativa para tais restri\u00e7\u00f5es. Esses documentos correspondem aproximadamente ao que \u00e9 descrito nos pontos da Estrat\u00e9gia de Reuso e Ambiente de Desenvolvimento do guia \"Manager's Handbook for Software Development\", elaborado em NASA.<\/a><\/noindex>. Apesar de sua idade, ele descreve magistralmente todas as atividades principais e etapas do planejamento do desenvolvimento de software desse tipo. A presen\u00e7a de documentos semelhantes facilita muito o processo de discuss\u00e3o sobre quais componentes e abordagens podem ser usados no produto e por que.<\/p>\nDo ponto de vista cultural, \u00e9 evidente que, em uma posi\u00e7\u00e3o mais madura, onde as partes tentam ouvir e compreender a verdadeira motiva\u00e7\u00e3o por tr\u00e1s das a\u00e7\u00f5es dos colegas e agem de acordo com as prioridades do projeto e da equipe, e n\u00e3o com o ego pessoal, o conflito poderia ser resolvido de forma mais simples e r\u00e1pida.<\/p>\n
Em outro conflito relacionado \u00e0 escolha de uma solu\u00e7\u00e3o t\u00e9cnica, tamb\u00e9m levei um tempo consider\u00e1vel para entender a motiva\u00e7\u00e3o de uma das partes (o caso era bastante incomum), mas, uma vez que a motiva\u00e7\u00e3o ficou clara, a solu\u00e7\u00e3o se tornou \u00f3bvia. <\/p>\n
A situa\u00e7\u00e3o era a seguinte: em uma equipe de cerca de 20 pessoas, surgiu um novo desenvolvedor, vamos cham\u00e1-lo de Stas. Nossa ferramenta padr\u00e3o de comunica\u00e7\u00e3o na equipe, naquele momento, era o Skype. Como se descobriu depois, Stas era um grande f\u00e3 de padr\u00f5es abertos e software de c\u00f3digo aberto, e usava apenas ferramentas e sistemas operacionais cujos c\u00f3digos fonte estavam dispon\u00edveis publicamente e que utilizavam protocolos descritos publicamente. O Skype n\u00e3o se enquadra nessas ferramentas. Gastamos uma quantidade enorme de tempo discutindo os pr\u00f3s e contras dessa abordagem, tentando executar equivalentes do Skype em diferentes sistemas operacionais, nas tentativas de Stas de convencer a equipe a adotar outros padr\u00f5es, escrevendo para ele pessoalmente por e-mail, ligando para ele pessoalmente por telefone, comprando um segundo computador especificamente para o Skype, etc. Finalmente, percebi que esse problema n\u00e3o era, essencialmente, t\u00e9cnico ou organizacional, mas sim uma quest\u00e3o de vis\u00e3o de mundo, at\u00e9 poderia se dizer religiosa (para Stas). Mesmo que, por fim, tiv\u00e9ssemos conectado Stas ao Skype (o que j\u00e1 consumiu v\u00e1rios meses), o problema surgiria novamente com qualquer outra ferramenta. Eu n\u00e3o tinha realmente meios de mudar a vis\u00e3o de mundo de Stas, e n\u00e3o havia raz\u00f5es para tentar mudar a vis\u00e3o de mundo da equipe, que funcionava perfeitamente bem nesse ambiente. A pessoa e a empresa simplesmente eram ortogonais em sua vis\u00e3o de mundo. Em situa\u00e7\u00f5es como essa, uma boa solu\u00e7\u00e3o \u00e9 organizacional. Transferimos Stas para outra equipe, onde ele se encaixava melhor.<\/p>\n
Na minha opini\u00e3o, a raz\u00e3o desse conflito reside na incompatibilidade entre a cultura pessoal de um indiv\u00edduo espec\u00edfico (que tem uma opini\u00e3o forte que n\u00e3o lhe permite fazer concess\u00f5es) e a cultura da empresa. Neste caso, \u00e9, sem d\u00favida, um erro do gerente. Foi um erro desde o in\u00edcio contrat\u00e1-lo para um projeto desse tipo. Stas acabou se mudando para um projeto de desenvolvimento de software de c\u00f3digo aberto e l\u00e1 se destacou muito bem.<\/p>\n
Um bom exemplo de conflito causado pela posi\u00e7\u00e3o infantil do desenvolvedor e pelas falhas no processo de trabalho \u00e9 a situa\u00e7\u00e3o em que, na aus\u00eancia de uma defini\u00e7\u00e3o de pronto, o desenvolvedor e a equipe de QA t\u00eam expectativas diferentes em rela\u00e7\u00e3o \u00e0 prontid\u00e3o da funcionalidade enviada para QA. O desenvolvedor achava que era suficiente escrever o c\u00f3digo e passar a funcionalidade para QA - l\u00e1 eles resolveriam. Ali\u00e1s, era um programador bastante experiente, mas esse era seu padr\u00e3o interno de qualidade. A equipe de QA discordava disso e exigia que ele mostrasse e descrevesse o que havia verificado, al\u00e9m de pedir um roteiro de testes para eles. Eles j\u00e1 haviam tido problemas no passado com a funcionalidade desse desenvolvedor e n\u00e3o queriam perder tempo novamente. Al\u00e9m disso, eles estavam certos - a funcionalidade realmente n\u00e3o funcionava e ele n\u00e3o tinha verificado o c\u00f3digo antes de envi\u00e1-lo para QA. <\/p>\n
Para resolver a situa\u00e7\u00e3o, pedi que ele me mostrasse que tudo realmente funcionava (n\u00e3o funcionava e ele teve que consertar), conversamos com a equipe e com o QA sobre a defini\u00e7\u00e3o de pronto (decidimos n\u00e3o document\u00e1-la, pois n\u00e3o quer\u00edamos burocratizar demais o processo), e logo nos separamos desse especialista (para al\u00edvio geral).<\/p>\n
Do ponto de vista do processo de trabalho, poss\u00edveis melhorias neste caso seriam a inclus\u00e3o de uma defini\u00e7\u00e3o de pronto, a exig\u00eancia de que cada funcionalidade tivesse testes unit\u00e1rios e de integra\u00e7\u00e3o, e a documenta\u00e7\u00e3o dos testes realizados pelo desenvolvedor. Em um dos projetos, medimos o n\u00edvel de cobertura do c\u00f3digo com testes durante o CI e, caso o n\u00edvel de cobertura ca\u00edsse ap\u00f3s a adi\u00e7\u00e3o de um patch, os testes eram marcados como n\u00e3o passados, ou seja, qualquer novo c\u00f3digo s\u00f3 poderia ser adicionado na presen\u00e7a de novos testes para ele. <\/p>\n
Mais um exemplo t\u00edpico de um conflito intimamente relacionado \u00e0 organiza\u00e7\u00e3o do fluxo de trabalho. Temos um produto, uma equipe de desenvolvimento desse produto, uma equipe de suporte e um cliente. O cliente tem problemas com o produto e entra em contato com o suporte. O suporte analisa o problema e percebe que a quest\u00e3o est\u00e1 no produto, ent\u00e3o repassa a quest\u00e3o para a equipe de produto. A equipe de produto est\u00e1 em um per\u00edodo de alta demanda, com um lan\u00e7amento se aproximando, portanto, o ticket com o problema do cliente, perdido entre os outros tickets do desenvolvedor a quem foi atribu\u00eddo, permanece sem aten\u00e7\u00e3o por v\u00e1rias semanas. O suporte pensa que o desenvolvedor est\u00e1 trabalhando no problema do cliente. O cliente espera e espera que sua quest\u00e3o esteja sendo abordada. Na realidade, nada est\u00e1 acontecendo. Ap\u00f3s algumas semanas, o cliente finalmente decide perguntar sobre o progresso e questiona o suporte sobre como est\u00e3o as coisas. O suporte pergunta \u00e0 equipe de desenvolvimento. O desenvolvedor se assusta, revisa a lista de tickets e encontra o ticket do cliente. Ao ler o ticket do cliente, ele percebe que n\u00e3o tem informa\u00e7\u00f5es suficientes para resolver o problema e precisa de mais logs e dumps. O suporte solicita informa\u00e7\u00f5es adicionais ao cliente. E \u00e9 ent\u00e3o que o cliente percebe que ningu\u00e9m trabalhou em sua quest\u00e3o todo esse tempo. E a tempestade surge...<\/p>\n
Nessa situa\u00e7\u00e3o, a solu\u00e7\u00e3o do pr\u00f3prio conflito \u00e9 bastante \u00f3bvia e linear (consertar o produto, atualizar a documenta\u00e7\u00e3o e os testes, apaziguar o cliente, lan\u00e7ar um hotfix, etc.). \u00c9 importante analisar o fluxo de trabalho e entender quem \u00e9 respons\u00e1vel pela organiza\u00e7\u00e3o da intera\u00e7\u00e3o entre as duas equipes, por que essa situa\u00e7\u00e3o se tornou poss\u00edvel. \u00c9 claro que algo precisa ser corrigido no processo \u2014 algu\u00e9m deve monitorar o cen\u00e1rio geral sem que seja necess\u00e1rio lembretes dos clientes, de forma proativa. Os tickets dos clientes devem se destacar entre os demais tickets dos desenvolvedores. O suporte deve ver se a equipe de desenvolvimento est\u00e1 trabalhando nos seus tickets no momento; se n\u00e3o, quando poder\u00e1 come\u00e7ar a trabalhar e quando se pode esperar um resultado. O suporte e o desenvolvimento devem se comunicar periodicamente e discutir o status dos tickets, a coleta das informa\u00e7\u00f5es necess\u00e1rias para depura\u00e7\u00e3o deve ser o mais automatizada poss\u00edvel, etc.<\/p>\n
Assim como em uma guerra o inimigo tenta atacar a jun\u00e7\u00e3o entre duas unidades, no trabalho o ponto mais delicado e vulner\u00e1vel costuma ser a intera\u00e7\u00e3o entre as equipes. Se os gerentes de suporte e desenvolvimento forem suficientemente maduros, poder\u00e3o corrigir o processo por conta pr\u00f3pria; caso contr\u00e1rio, o processo continuar\u00e1 a gerar conflitos e problemas at\u00e9 que um gerente intervenha e possa resolver a situa\u00e7\u00e3o.<\/p>\n
Outro exemplo caracter\u00edstico que encontrei repetidamente em diferentes empresas \u00e9 a situa\u00e7\u00e3o em que um produto \u00e9 desenvolvido por uma equipe, os testes de integra\u00e7\u00e3o automatizados s\u00e3o realizados por outra equipe e a infraestrutura que suporta tudo isso \u00e9 gerenciada por uma terceira equipe. Problemas surgem constantemente durante a execu\u00e7\u00e3o dos testes, e as causas podem estar tanto no produto quanto nos testes e na infraestrutura. O desafio geralmente \u00e9 chegar a um acordo sobre quem deve realizar a an\u00e1lise inicial dos problemas, registrar bugs, analisar os logs do produto, dos testes e da infraestrutura, etc. Conflitos aqui s\u00e3o bastante frequentes e, ao mesmo tempo, padronizados. Em situa\u00e7\u00f5es de alta tens\u00e3o emocional, os participantes muitas vezes adotam uma postura infantil e come\u00e7am discuss\u00f5es do tipo: \u201cpor que eu devo lidar com isso?\u201d, \u201celes quebram mais frequentemente\u201d, etc. <\/p>\n
Do ponto de vista do fluxo de trabalho, os passos espec\u00edficos para resolver a quest\u00e3o dependem da composi\u00e7\u00e3o das equipes, do tipo de testes e do produto, etc. Em um dos projetos, implementamos turnos regulares, onde as equipes monitoravam os testes em uma escala rotativa semanal. Em outro, a an\u00e1lise inicial sempre era realizada pelos desenvolvedores dos testes, mas a an\u00e1lise era bastante b\u00e1sica e o produto bastante est\u00e1vel, ent\u00e3o isso funcionava bem. O principal \u00e9 garantir a transpar\u00eancia do processo, clareza nas expectativas para todas as partes e a sensa\u00e7\u00e3o de justi\u00e7a da situa\u00e7\u00e3o para todos.<\/p>\n
Um conflito na organiza\u00e7\u00e3o \u00e9 um problema? \u00c9 um mau sinal que sua equipe frequentemente (ou periodicamente) tenha conflitos? Em geral, n\u00e3o, pois se h\u00e1 crescimento, desenvolvimento e alguma din\u00e2mica, surgem quest\u00f5es que antes n\u00e3o eram resolvidas, e ao resolv\u00ea-las, podem ocorrer conflitos. Isso indica que algumas \u00e1reas precisam de aten\u00e7\u00e3o, que h\u00e1 espa\u00e7o para melhorias. \u00c9 ruim quando os conflitos ocorrem com muita frequ\u00eancia e s\u00e3o dif\u00edceis ou longos de resolver. Isso provavelmente \u00e9 um sinal de processos de trabalho mal estruturados e de imaturidade da equipe.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u042d\u043f\u0438\u0433\u0440\u0430\u0444: \u0412\u0441\u0442\u0440\u0435\u0442\u0438\u043b\u0438\u0441\u044c \u043a\u0430\u043a-\u0442\u043e \u0432 \u043b\u0435\u0441\u0443 \u0401\u0436\u0438\u043a \u0438 \u041c\u0435\u0434\u0432\u0435\u0436\u043e\u043d\u043e\u043a. \u2014 \u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439, \u0401\u0436\u0438\u043a! \u2014 \u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439, \u041c\u0435\u0434\u0432\u0435\u0436\u043e\u043d\u043e\u043a! \u0422\u0430\u043a, \u0441\u043b\u043e\u0432\u043e \u0437\u0430 \u0441\u043b\u043e\u0432\u043e, \u0448\u0443\u0442\u043a\u0430 \u0437\u0430 \u0448\u0443\u0442\u043a\u043e\u0439, \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u043b \u0401\u0436\u0438\u043a \u043e\u0442 \u041c\u0435\u0434\u0432\u0435\u0436\u043e\u043d\u043a\u0430 \u043f\u043e \u043c\u043e\u0440\u0434\u0435 \u2026 \u041f\u043e\u0434 \u043a\u0430\u0442\u043e\u043c \u0440\u0430\u0441\u0441\u0443\u0436\u0434\u0435\u043d\u0438\u044f \u043d\u0430\u0448\u0435\u0433\u043e \u0442\u0438\u043c\u043b\u0438\u0434\u0430, \u0430 \u0442\u0430\u043a\u0436\u0435 \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440\u0430 \u043f\u043e \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044e \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430 RAS \u2014 \u0418\u0433\u043e\u0440\u044f \u041c\u0430\u0440\u043d\u0430\u0442\u0430 \u043e \u0441\u043f\u0435\u0446\u0438\u0444\u0438\u043a\u0435 \u0440\u0430\u0431\u043e\u0447\u0438\u0445 \u043a\u043e\u043d\u0444\u043b\u0438\u043a\u0442\u043e\u0432 \u0438 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u044b\u0445 \u043c\u0435\u0442\u043e\u0434\u0430\u0445 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0438\u043c\u0438. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043a\u043e\u043d\u0444\u043b\u0438\u043a\u0442\u043e\u0432, […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27283,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[702],"tags":[],"class_list":["post-36457","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Gerenciamento](\"\/wp-content\/uploads\/2019\/07\/de379c9eedec8cecda6651b5339a0277.jpg\")