Epígrafe:
Um dia, o Ouriço e o Ursinho se encontraram na floresta.
— Olá, Ouriço!
— Olá, Ursinho!
Assim, palavra por palavra, piada por piada, o Ouriço levou um tapa do Ursinho...
Abaixo estão as reflexões do nosso líder de equipe, bem como do diretor de desenvolvimento de produtos da RAS — Igor Marnat sobre as especificidades dos conflitos de trabalho e possíveis métodos para gerenciá-los.
A maioria dos conflitos que encontramos no trabalho se desenrola de acordo com um roteiro semelhante ao descrito acima no epígrafe. Existem alguns participantes, inicialmente favoráveis entre si, que tentam resolver alguma questão, mas, no final, o problema permanece sem solução, e a relação entre os participantes da discussão, por algum motivo, acaba estragada.
A vida é diversificada; no cenário descrito acima, há variações. Às vezes, as relações entre os participantes não são muito boas desde o início, às vezes não há nem uma questão que exija solução imediata (como, por exemplo, no epígrafe), às vezes, após a discussão, as relações permanecem as mesmas que antes, mas a questão, no final, não é resolvida.
O que todos os casos que podem ser definidos como situações de conflito de trabalho têm em comum?
Em primeiro lugar, a presença de duas ou mais partes. Essas partes podem ocupar diferentes lugares na organização, estar em relações de igualdade (colegas na equipe) ou em diferentes níveis de hierarquia (supervisor — subordinado), ser individuais (empregado) ou grupais (em casos de conflitos entre um empregado e a equipe ou entre duas equipes), etc. O nível de confiança entre os participantes influencia muito a probabilidade de conflito e a facilidade de sua resolução. Quanto melhor as partes se conhecem e maior o nível de confiança, maior a chance de chegarem a um acordo. Por exemplo, colegas de uma equipe distribuída que nunca se comunicaram pessoalmente têm uma probabilidade maior de entrar em uma situação de conflito ao resolver uma questão de trabalho simples do que pessoas que se comunicaram pessoalmente pelo menos algumas vezes. Portanto, ao trabalhar em equipes distribuídas, é muito importante garantir encontros pessoais periódicos entre todos os membros da equipe.
Em segundo lugar, em uma situação de conflito no trabalho, as partes estão diante da resolução de uma questão importante para uma das partes, para ambas ou para a organização como um todo. Nesse contexto, devido às especificidades da situação, as partes geralmente têm tempo suficiente e vários modos de resolver o problema (formais, informais, reuniões, cartas, decisões da liderança, existência de objetivos e planos da equipe, fato de haver hierarquia, etc.). Isso difere da situação de resolver uma questão de trabalho (ou não) na organização, por exemplo, de resolver uma questão importante: “Ei, cara, de qual bairro você é?!” na rua, ou de um conflito como o do epígrafo. No caso da resolução de uma questão de trabalho, a qualidade do processo de trabalho e a cultura de resolução de questões na equipe são importantes.
Em terceiro lugar, um fator determinante do conflito (do ponto de vista da nossa discussão) é o fato de que as partes do processo não conseguem chegar a uma solução que satisfaça a todos. A situação exige a intervenção de uma terceira parte, um árbitro externo. Este ponto pode parecer controverso, mas, em essência, se a situação de conflito foi resolvida com sucesso sem a intervenção de um árbitro externo, a questão foi resolvida com sucesso e as relações entre as partes não se deterioraram, essa é a situação a que devemos aspirar. Provavelmente, não saberemos sobre um conflito como esse, ou saberemos acidentalmente após sua resolução. Quanto mais questões a equipe puder resolver de forma independente, mais eficaz ela será.
Outra característica do conflito que vale a pena mencionar é o grau de tensão emocional durante a resolução. O conflito não está necessariamente ligado a um alto grau de emoção. Os participantes não precisam gritar e acenar com as mãos para que a situação seja, na essência, conflituosa. Se a questão não é resolvida, e uma certa tensão emocional está presente (talvez não expressa externamente de forma clara), então temos uma situação de conflito.
É necessário intervir em situações de conflito ou é melhor deixar que a resolução aconteça naturalmente e esperar que o problema se resolva por conta própria? Sim, é necessário. Nem sempre está em seu poder ou competência resolver completamente um conflito, mas em qualquer situação, em um conflito de qualquer escala, você pode assumir uma posição madura, assim influenciando ainda mais algumas pessoas ao seu redor, amenizando as consequências negativas do conflito e contribuindo para sua resolução.
Antes de discutirmos alguns exemplos de situações de conflito, vamos abordar alguns pontos importantes que são comuns a todos os conflitos.
Ao resolver um conflito, é importante estar fora da disputa, e não envolvido nela (isso também é conhecido como "assumir uma meta posição"), ou seja, não se colocar lado a lado com uma das partes. Caso contrário, em vez de atuar como um árbitro externo ajudando na resolução, você apenas fortalecerá a posição de uma das partes em detrimento da outra. Ao tomar uma decisão, é crucial que ela seja moralmente aceita por todas as partes, como diz o ditado, "comprada". Assim, mesmo que as partes não fiquem entusiasmadas com a decisão tomada, elas pelo menos concordarão sinceramente em cumpri-la. O que se chama de estar em um estado de discordar e se comprometer. Caso contrário, o conflito simplesmente mudará de forma, o fogo smouldering continuará debaixo das cinzas e, em algum momento, inevitavelmente reatará.
O segundo ponto, parcialmente relacionado ao primeiro, é que se você decidiu participar da resolução do conflito, trate isso com a máxima seriedade em termos de comunicação e compreensão do contexto. Converse pessoalmente com cada uma das partes. Comece separadamente com cada uma. Não se contente com e-mails. No caso de uma equipe distribuída, pelo menos converse por videoconferência. Não se contente com rumores e relatos de testemunhas. Entenda a história, o que cada parte quer, por que quer, o que espera, se já tentaram resolver a questão antes, o que acontecerá se não for resolvido, quais opções de solução veem, como imaginam a posição da outra parte, o que consideram certo ou errado, etc. Carregue em sua mente todo o contexto possível, de forma imparcial, presumindo que todos têm razão. Você não está dentro do conflito, você está fora dele, em uma posição meta. Se o contexto estiver disponível apenas em um thread de e-mail, leia pelo menos todo o conteúdo e as discussões relacionadas e documentos. Depois de ler, ainda assim converse pessoalmente. É quase garantido que você ouvirá algo importante que não está nos e-mails.
Um terceiro ponto importante é a abordagem geral da comunicação. Estas são coisas comuns, nada elaborado, mas que têm um grande significado. Não tente economizar tempo, converse com todos os participantes, critique não a pessoa, mas as consequências de suas ações (não dizer 'você foi rude', mas 'talvez as pessoas possam se ofender com isso'), dê oportunidades para manter a dignidade, realize as discussões pessoalmente, e não na frente do grupo.
Os conflitos geralmente são causados por uma das duas razões. A primeira está relacionada a estar a pessoa na posição de adulto ou na posição de criança no momento do conflito (sobre isso mais abaixo). Isso está ligado à sua maturidade emocional, à capacidade de gerenciar suas emoções (o que, aliás, não está sempre relacionado à sua idade). A segunda razão comum é a imperfeição do processo de trabalho, que cria situações de zonas cinzentas, nas quais a responsabilidade está difusa entre os participantes, e as expectativas das partes não são transparentes entre si, pois os papéis no processo estão indefinidos.
Portanto, ao resolver um conflito (assim como qualquer outra questão), o gerente deve considerar três perspectivas: a de curto prazo — resolver a questão/conflito aqui e agora, a de médio prazo — minimizar a probabilidade de outro conflito surgir pela mesma razão, e a de longo prazo — cultivar uma cultura de adultidade na equipe.
Dentro de cada um de nós, existe uma criança interior, com cerca de três a quatro anos. A maior parte do tempo, ela está dormindo no trabalho, mas às vezes acorda e assume o controle. Esta criança tem suas próprias prioridades. É importante para ela afirmar que este é seu castelo de areia, que a mamãe o ama mais, que seu carrinho é o melhor de todos (o design é o melhor, ele programa melhor que os outros, …). Em uma situação de conflito, a criança pode apertar seus brinquedos, bater os pés e agitar a pá, mas ela não pode resolver questões adultas (arquitetura da solução, abordagens para testes automáticos, prazos de lançamento, etc.), ela não pensa em termos de benefícios para a equipe. A criança em um conflito pode ser confortada, acalmada e enviada para dormir, pedindo para chamar seu adulto. Antes de começar a discussão em um contexto de conflito, certifique-se de que você está conversando com um adulto, e não com a criança, e que você mesmo está na posição de um adulto. Se seu objetivo honesto neste momento é resolver uma questão séria, você está na posição de um adulto. Se seu objetivo é bater os pés e agitar a pá — essa é uma posição infantil. Coloque sua criança interior para dormir e chame o adulto, ou adie a discussão. As pessoas tomam decisões emocionais e depois buscam uma justificativa racional. A decisão, tomada pela criança, com base em prioridades infantis, não será otimizada.
Além do comportamento em momentos de conflito, a posição infantil ou adulta é também caracterizada pelo nível de responsabilidade que a pessoa está disposta a assumir. Nos casos extremos, a posição infantil de um programador, que encontrei várias vezes, se manifesta assim: eu escrevi o código, enviei para revisão — meu trabalho está concluído. Os revisores devem analisá-lo e mesclá-lo, a QA deve testá-lo, se houver problemas — eles me informarão. Estranhamente, até pessoas bastante adultas e experientes às vezes se comportam dessa forma. O outro extremo da escala é quando a pessoa se considera responsável pelo seu código funcionar, estar coberto por testes, ter sido verificado pessoalmente, passar com sucesso pela revisão (se necessário, sem problemas em contatar os revisores, discutir questões por voz, etc.) e ser mesclado, com a QA recebendo ajuda se necessário, cenários de testes serão descritos, etc. Normalmente, um programador está mais próximo do lado adulto da escala desde o início ou se desloca para lá conforme acumula experiência (desde que a equipe cultive a cultura correta). Em casos extremos, ele continua a trabalhar frequentemente assumindo a posição infantil, então ele e a equipe enfrentam problemas e conflitos periodicamente.
Cultivar uma cultura correta e madura na equipe é uma tarefa importante para qualquer gerente. Isso exige tempo e esforço diário, mas o resultado vale a pena. Existem duas maneiras de influenciar a cultura da equipe — pelo exemplo pessoal (que será seguido, a equipe sempre observa o líder) e pela discussão e incentivo do comportamento adequado. Aqui também não há 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ão foi correta, elogie, mencione durante a análise de lançamento, etc.
Vamos considerar algumas situações de conflito típicas, do simples ao complexo:
Conflitos não relacionados a questões de trabalho
Frequentemente, ocorrem conflitos no trabalho que não estão relacionados a questões de trabalho. Sua ocorrência e a facilidade de resolução geralmente estão diretamente ligadas ao nível de inteligência emocional dos participantes, ao nível de maturidade deles, e não estão relacionadas à perfeição ou imperfeição do processo de trabalho.
Exemplos típicos incluem alguém que não usa a máquina de lavar ou o chuveiro com frequência suficiente, o que desagrada os outros, alguém que sente calor e outra pessoa que se incomoda ao abrir a janela, alguém que faz muito barulho e os demais precisam de silêncio para trabalhar, e assim por diante. É melhor não procrastinar na resolução de conflitos desse tipo e não deixar que a situação se desenrole sozinha. Eles não vão se resolver por conta própria e desviarão diariamente a atenção do trabalho e envenenarão a atmosfera na equipe. Felizmente, solucionar esses problemas geralmente não é complicado — apenas converse calmamente (claro, um a um) com o colega que desregula a higiene, forneça uma disposição confortável para aqueles que preferem silêncio/refrigeração, compre fones de ouvido acústicos ou instale divisórias, etc.
Outro exemplo que encontrei algumas vezes durante meu trabalho é a incompatibilidade psicológica entre os membros da equipe. Por alguma razão, as pessoas simplesmente não conseguem trabalhar juntas, cada interação termina em escândalo. Às vezes, isso está relacionado ao fato de que as pessoas têm visões polarizadas sobre uma questão candente (geralmente política) e não sabem deixá-las fora do trabalho. Convencê-las a suportar uma à outra ou mudar seu comportamento é uma tarefa bastante ingratificante. A única exceção que encontrei foram os jovens colegas com uma mentalidade aberta, cujo comportamento ainda pode mudar gradualmente por meio de conversas periódicas. Normalmente, a questão é solucionada ao separá-los em equipes diferentes ou, pelo menos, garantindo que tenham a possibilidade de se cruzar no trabalho com extrema raridade.
Em todas as situações mencionadas, vale a pena conversar pessoalmente com todos os envolvidos, discutir a situação, perguntar se eles veem algum problema neste caso, questionar quais, em sua opinião, são as possíveis soluções e garantir sua participação na tomada de decisão.
Do ponto de vista da otimização do fluxo de trabalho (uma perspectiva de médio prazo à qual me referi), não há muito a fazer aqui; o único ponto de otimização é considerar o fator de compatibilidade ao formar a equipe e evitar antecipadamente colocar juntos as pessoas que irão conflitar.
Do ponto de vista da cultura da equipe, essas situações ocorrem com muito menos frequência em equipes com uma cultura madura, onde as pessoas respeitam a equipe e os colegas e sabem como resolver questões de forma autônoma. Além disso, conflitos desse tipo são resolvidos com muito mais facilidade (frequentemente de maneira automática) em equipes onde há um alto nível de confiança, as pessoas trabalham juntas há muito tempo e/ou se comunicam frequentemente fora do trabalho.
Conflitos relacionados a questões de trabalho:
Esses conflitos são geralmente causados por ambas as razões ao mesmo tempo, tanto emocionais (quando um dos participantes não está na posição adulta) quanto pelas imperfeições do próprio processo de trabalho. O tipo de conflito mais comum que encontrei são os conflitos durante o processo de revisão de código ou discussão de arquitetura entre desenvolvedores.
Aqui, eu destacaria dois casos típicos:
1) No primeiro caso, o desenvolvedor não consegue obter a revisão de código de um colega. O patch foi enviado para revisão, e nada acontece. À primeira vista, não há um conflito claro entre as duas partes, mas, se você pensar bem, é de fato um conflito. A questão de trabalho não é resolvida, uma das partes (que está aguardando a revisão) sente um desconforto evidente. Uma variante extrema desse caso é o desenvolvimento em comunidade ou em equipes diferentes, onde o revisor pode não estar interessado naquele código específico, podendo, devido à carga de trabalho ou outras circunstâncias, ignorar completamente o pedido de revisão, e pode não haver um árbitro externo (geral a ambas as partes, o gerente) no local.
Uma abordagem para resolver isso se relaciona com uma perspectiva de longo prazo e a cultura do adulto. Primeiro, a atividade racional funciona. Não se deve esperar que um código em revisão chame a atenção do revisor por si só. É necessário ajudar os revisores a notá-lo. Acione algumas pessoas, faça perguntas na reunião, participe das discussões. É evidente que ser insistente pode ajudar mais do que prejudicar, mas o senso comum deve ser empregado. Em segundo lugar, a preparação prévia é essencial. Se a equipe entende o que e por que está acontecendo, para que aquele código é necessário, e o design foi discutido e aprovado previamente por todos, as pessoas terão mais probabilidade de notar esse código e aceitá-lo no trabalho. Em terceiro lugar, a autoridade é importante. Se você quer que seu código seja revisado, faça muitas revisões você mesmo. Realize revisões de qualidade, com verificações reais, testes reais e comentários úteis. Se seu nome é conhecido na equipe de forma positiva, há mais chances de que seu código receba atenção.
Em termos de fluxo de trabalho, as melhorias possíveis aqui são a definição correta de prioridades, visando ajudar o desenvolvedor a atingir seus objetivos e os objetivos da equipe (fazer revisões de outros, escrever e-mails para a comunidade, acompanhar o código com descrições de arquitetura, documentação, testes, participar de discussões com a comunidade, etc.), evitar que patches fiquem muito tempo na fila, e assim por diante.
2) O segundo caso comum de conflitos durante a revisão de código ou design são diferentes visões sobre questões técnicas, estilo de codificação e escolha de ferramentas. O nível de confiança entre os participantes, a pertença a uma mesma equipe e a experiência de trabalho conjunto são aspectos de enorme importância. O impasse ocorre quando um dos participantes adota uma postura infantil e não tenta entender o que o interlocutor está tentando comunicar. Muitas vezes, tanto a abordagem proposta pelo outro lado quanto a abordagem inicialmente sugerida podem funcionar com sucesso e não importa qual delas seja escolhida.
Certa vez, um programador da minha equipe (vamos chamá-lo de Pasha) preparou um patch com mudanças no sistema de implantação de pacotes, que foi desenvolvido e mantido por colegas do departamento vizinho. Um deles (Igor) tinha uma opinião forte sobre como os serviços Linux deveriam ser configurados ao implantar pacotes. Essa opinião diferia da abordagem sugerida no patch, e eles não conseguiam chegar a um acordo. Como de costume, os prazos estavam apertados, e era necessário chegar a uma solução; alguém precisava assumir uma postura adulta. Pasha reconheceu que ambas as abordagens tinham méritos, mas queria que sua opção prevalecesse, já que não havia vantagens técnicas claras em nenhuma das duas opções.
Nossa discussão foi mais ou menos assim (muito esquemática, claro, a conversa durou meia hora):
— Pasha, temos o freeze de funcionalidade em alguns dias. É importante que reunamos tudo e comecemos os testes o mais rápido possível. Como podemos passar pelo Igor?
— Ele quer configurar os serviços de outra forma, colocou comentários pra todo lado ...
— E quanto a isso, grandes reworks, muito trabalho?
— Não, é trabalho para algumas horas, mas no final não faz diferença, tanto faz, vai funcionar, por que isso é necessário? Eu fiz uma coisa que funciona, vamos aceitá-la.
— Escuta, há quanto tempo vocês estão discutindo isso?
— Já faz quase uma semana e meia que estamos patinando.
— Em ... podemos resolver a questão em algumas horas, que já leva uma semana e meia, e não fazemos isso?
— Bem, sim, mas eu não quero que o Igor pense que eu dei para trás ...
— Escuta, o que é mais importante para você, lançar a versão, junto com sua solução, ou vencer o Igor? Podemos vencer, mas, claro, tem uma boa chance de atrasar o lançamento.
— Bem ... seria legal, claro, dar uma lição no Igor, mas tudo bem, o lançamento é mais importante, concordo.
— Você realmente se importa tanto com o que o Igor pensa? Para ser sincero, ele está um pouco se lixando, ele só quer uma abordagem única em diferentes partes da coisa pela qual ele é responsável.
— Ok, vou fazer como ele pede nos comentários e começar os testes.
— Obrigado, Pasha! Eu estava certo de que dos dois, você seria o mais maduro, embora o Igor seja mais velho que você :)
A questão foi resolvida, o lançamento foi feito a tempo, o Pasha não estava insatisfeito, pois ele mesmo sugeriu a solução e a implementou. O Igor estava mesmo satisfeito, pois sua opinião foi considerada e o que ele propôs foi executado.
Outro tipo de conflito semelhante é a escolha entre soluções técnicas/livrarias/abordagens em um projeto, especialmente em uma equipe distribuída. Em um dos projetos, que se posicionava como usando C/C++, acabou que a gestão técnica do projeto era categoricamente contra o uso da STL (Standard Template Library). Essa é uma biblioteca padrão do idioma que simplifica o desenvolvimento, e nossa equipe estava muito acostumada a usá-la. Aconteceu que o projeto estava muito mais perto de C do que de C++, o que não inspirava muito a equipe, já que a gestão fez um esforço e contratou realmente bons programadores de C++. Ao mesmo tempo, a parte americana da equipe, tanto engenheiros quanto gerentes, trabalhava na empresa há muito tempo e estava acostumada com a situação existente, ficando satisfeita. A parte russa da equipe foi reunida há pouco tempo, em algumas semanas (inclusive eu). A parte russa da equipe não queria abrir mão da abordagem que estava acostumada para o desenvolvimento.
Começaram intermináveis discussões por escrito entre os dois continentes, e-mails de três a quatro telas voavam de um lado para o outro, em distribuição em grupo e pessoais, de programadores — para programadores e gerentes. Como costuma acontecer, ninguém além dos autores e seus fervorosos apoiadores leu e-mails desse tamanho. As conversas estavam tensas, trocando muitas ideias sobre as vantagens técnicas da STL, quão bem testada e segura ela era, e, em geral, como a vida é maravilhosa com ela e como horrível é sem ela.
Isso durou bastante tempo, até que finalmente percebi que estávamos discutindo os aspectos técnicos da questão, enquanto o problema não era, na realidade, técnico. A questão não estava nas vantagens ou desvantagens do STL ou na complexidade de trabalhar sem ele. O problema era mais organizacional. Precisávamos apenas entender como a empresa em que trabalhávamos funcionava. Nenhum de nós tinha experiência anterior em uma empresa desse tipo. O que acontece é que, após o desenvolvimento do código e seu lançamento em produção, a manutenção era feita por pessoas totalmente diferentes de outras equipes, em outros países. Essa enorme equipe de engenharia, que contava com várias dezenas de milhares de engenheiros (no total), só podia permitir-se o mínimo básico de recursos técnicos, por assim dizer, o minimum minimorum. Tudo que ia além dos padrões de engenharia estabelecidos na empresa fisicamente não poderia ser suportado posteriormente. O nível da equipe é determinado pelo nível dos seus membros mais fracos. Depois que entendemos a real motivação das ações da equipe americana, essa questão foi retirada da pauta, e todos nós juntos desenvolvemos e lançamos o produto com os padrões adotados pela empresa. Emails e chats, nesse caso, não funcionaram bem; foi necessário várias viagens e muito contato pessoal para chegarmos a um entendimento comum.
Do ponto de vista do fluxo de trabalho, neste caso específico, a presença de uma descrição dos recursos utilizados, requisitos para eles, limitações na adição de novos e justificativas para tais limitações teria sido útil. Esses documentos correspondem aproximadamente ao que é descrito nos pontos da Reuse Strategy e do Development Environment do manual “Manager’s Handbook for Software Development”, desenvolvido em . Apesar de sua idade, ele descreve magistralmente todas as atividades principais e etapas do planejamento do desenvolvimento de software desse tipo. A presença de documentos semelhantes facilita muito o processo de discussão sobre quais componentes e abordagens podem ser usados no produto e por que.
Do ponto de vista cultural, é evidente que, em uma posição mais madura, onde as partes tentam ouvir e compreender a verdadeira motivação por trás das ações dos colegas e agem de acordo com as prioridades do projeto e da equipe, e não com o ego pessoal, o conflito poderia ser resolvido de forma mais simples e rápida.
Em outro conflito relacionado à escolha de uma solução técnica, também levei um tempo considerável para entender a motivação de uma das partes (o caso era bastante incomum), mas, uma vez que a motivação ficou clara, a solução se tornou óbvia.
A situação era a seguinte: em uma equipe de cerca de 20 pessoas, surgiu um novo desenvolvedor, vamos chamá-lo de Stas. Nossa ferramenta padrão de comunicação na equipe, naquele momento, era o Skype. Como se descobriu depois, Stas era um grande fã de padrões abertos e software de código aberto, e usava apenas ferramentas e sistemas operacionais cujos códigos fonte estavam disponíveis publicamente e que utilizavam protocolos descritos publicamente. O Skype não se enquadra nessas ferramentas. Gastamos uma quantidade enorme de tempo discutindo os prós 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ões, 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ão era, essencialmente, técnico ou organizacional, mas sim uma questão de visão de mundo, até poderia se dizer religiosa (para Stas). Mesmo que, por fim, tivéssemos conectado Stas ao Skype (o que já consumiu vários meses), o problema surgiria novamente com qualquer outra ferramenta. Eu não tinha realmente meios de mudar a visão de mundo de Stas, e não havia razões para tentar mudar a visão de mundo da equipe, que funcionava perfeitamente bem nesse ambiente. A pessoa e a empresa simplesmente eram ortogonais em sua visão de mundo. Em situações como essa, uma boa solução é organizacional. Transferimos Stas para outra equipe, onde ele se encaixava melhor.
Na minha opinião, a razão desse conflito reside na incompatibilidade entre a cultura pessoal de um indivíduo específico (que tem uma opinião forte que não lhe permite fazer concessões) e a cultura da empresa. Neste caso, é, sem dúvida, um erro do gerente. Foi um erro desde o início contratá-lo para um projeto desse tipo. Stas acabou se mudando para um projeto de desenvolvimento de software de código aberto e lá se destacou muito bem.
Um bom exemplo de conflito causado pela posição infantil do desenvolvedor e pelas falhas no processo de trabalho é a situação em que, na ausência de uma definição de pronto, o desenvolvedor e a equipe de QA têm expectativas diferentes em relação à prontidão da funcionalidade enviada para QA. O desenvolvedor achava que era suficiente escrever o código e passar a funcionalidade para QA - lá eles resolveriam. Aliás, era um programador bastante experiente, mas esse era seu padrão interno de qualidade. A equipe de QA discordava disso e exigia que ele mostrasse e descrevesse o que havia verificado, além de pedir um roteiro de testes para eles. Eles já haviam tido problemas no passado com a funcionalidade desse desenvolvedor e não queriam perder tempo novamente. Além disso, eles estavam certos - a funcionalidade realmente não funcionava e ele não tinha verificado o código antes de enviá-lo para QA.
Para resolver a situação, pedi que ele me mostrasse que tudo realmente funcionava (não funcionava e ele teve que consertar), conversamos com a equipe e com o QA sobre a definição de pronto (decidimos não documentá-la, pois não queríamos burocratizar demais o processo), e logo nos separamos desse especialista (para alívio geral).
Do ponto de vista do processo de trabalho, possíveis melhorias neste caso seriam a inclusão de uma definição de pronto, a exigência de que cada funcionalidade tivesse testes unitários e de integração, e a documentação dos testes realizados pelo desenvolvedor. Em um dos projetos, medimos o nível de cobertura do código com testes durante o CI e, caso o nível de cobertura caísse após a adição de um patch, os testes eram marcados como não passados, ou seja, qualquer novo código só poderia ser adicionado na presença de novos testes para ele.
Mais um exemplo típico de um conflito intimamente relacionado à organização 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ão está no produto, então repassa a questão para a equipe de produto. A equipe de produto está em um período de alta demanda, com um lançamento se aproximando, portanto, o ticket com o problema do cliente, perdido entre os outros tickets do desenvolvedor a quem foi atribuído, permanece sem atenção por várias semanas. O suporte pensa que o desenvolvedor está trabalhando no problema do cliente. O cliente espera e espera que sua questão esteja sendo abordada. Na realidade, nada está acontecendo. Após algumas semanas, o cliente finalmente decide perguntar sobre o progresso e questiona o suporte sobre como estão as coisas. O suporte pergunta à 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ão tem informações suficientes para resolver o problema e precisa de mais logs e dumps. O suporte solicita informações adicionais ao cliente. E é então que o cliente percebe que ninguém trabalhou em sua questão todo esse tempo. E a tempestade surge...
Nessa situação, a solução do próprio conflito é bastante óbvia e linear (consertar o produto, atualizar a documentação e os testes, apaziguar o cliente, lançar um hotfix, etc.). É importante analisar o fluxo de trabalho e entender quem é responsável pela organização da interação entre as duas equipes, por que essa situação se tornou possível. É claro que algo precisa ser corrigido no processo — alguém deve monitorar o cenário geral sem que seja necessário 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á trabalhando nos seus tickets no momento; se não, quando poderá começar 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ções necessárias para depuração deve ser o mais automatizada possível, etc.
Assim como em uma guerra o inimigo tenta atacar a junção entre duas unidades, no trabalho o ponto mais delicado e vulnerável costuma ser a interação entre as equipes. Se os gerentes de suporte e desenvolvimento forem suficientemente maduros, poderão corrigir o processo por conta própria; caso contrário, o processo continuará a gerar conflitos e problemas até que um gerente intervenha e possa resolver a situação.
Outro exemplo característico que encontrei repetidamente em diferentes empresas é a situação em que um produto é desenvolvido por uma equipe, os testes de integração automatizados são realizados por outra equipe e a infraestrutura que suporta tudo isso é gerenciada por uma terceira equipe. Problemas surgem constantemente durante a execução dos testes, e as causas podem estar tanto no produto quanto nos testes e na infraestrutura. O desafio geralmente é chegar a um acordo sobre quem deve realizar a análise inicial dos problemas, registrar bugs, analisar os logs do produto, dos testes e da infraestrutura, etc. Conflitos aqui são bastante frequentes e, ao mesmo tempo, padronizados. Em situações de alta tensão emocional, os participantes muitas vezes adotam uma postura infantil e começam discussões do tipo: “por que eu devo lidar com isso?”, “eles quebram mais frequentemente”, etc.
Do ponto de vista do fluxo de trabalho, os passos específicos para resolver a questão dependem da composição 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álise inicial sempre era realizada pelos desenvolvedores dos testes, mas a análise era bastante básica e o produto bastante estável, então isso funcionava bem. O principal é garantir a transparência do processo, clareza nas expectativas para todas as partes e a sensação de justiça da situação para todos.
Um conflito na organização é um problema? É um mau sinal que sua equipe frequentemente (ou periodicamente) tenha conflitos? Em geral, não, pois se há crescimento, desenvolvimento e alguma dinâmica, surgem questões que antes não eram resolvidas, e ao resolvê-las, podem ocorrer conflitos. Isso indica que algumas áreas precisam de atenção, que há espaço para melhorias. É ruim quando os conflitos ocorrem com muita frequência e são difíceis ou longos de resolver. Isso provavelmente é um sinal de processos de trabalho mal estruturados e de imaturidade da equipe.
Fonte: habr.com
