Epígrafe:
Era uma vez o Ouriço e o Ursinho que se encontraram na floresta.
- Olá, ouriço!
- Olá, Ursinho!
Então, palavra por palavra, piada por piada, o Ouriço foi atingido na cara pelo Ursinho...
Abaixo está uma discussão do líder de nossa equipe, bem como do Diretor de Desenvolvimento de Produto 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 desenvolve de acordo com um cenário semelhante ao descrito na epígrafe acima. Existem vários participantes que inicialmente têm uma disposição bastante favorável entre si, estão tentando resolver algum problema, mas no final o problema permanece sem solução e, por algum motivo, as relações entre os participantes da discussão acabam sendo prejudicadas.
A vida é diversa e ocorrem variações no cenário descrito acima. Às vezes a relação entre os participantes não é muito boa inicialmente, às vezes nem há um problema que exija uma solução direta (como, por exemplo, na epígrafe), às vezes depois da discussão a relação continua a mesma de antes de começar, mas em última análise, o problema não foi resolvido.
O que há de comum em todas as situações que podem ser definidas como situação de conflito laboral?
Em primeiro lugar, existem dois ou mais lados. Estas partes podem ocupar diferentes lugares na organização, estar numa relação de igualdade (colegas de uma equipa), ou em diferentes níveis da hierarquia (chefe - subordinado), ser individuais (funcionário) ou de grupo (em casos de conflito entre um funcionário e uma equipe ou duas equipes), e assim por diante. A probabilidade de conflito e a facilidade de sua resolução são muito influenciadas pelo nível de confiança entre os participantes. Quanto melhor as partes se conhecerem, quanto maior for o nível de confiança, maior será a probabilidade de chegarem a um acordo. Por exemplo, os membros de uma equipe distribuída que nunca interagiram cara a cara têm maior probabilidade de enfrentar conflitos por causa de uma simples questão de trabalho do que pessoas que tiveram pelo menos algumas interações cara a cara. Portanto, ao trabalhar em equipes distribuídas, é muito importante garantir que todos os membros da equipe se reúnam periodicamente e pessoalmente.
Em segundo lugar, numa situação de conflito no trabalho, as partes encontram-se numa situação de resolução de alguma questão que é importante para uma das partes, para ambas, ou para a organização como um todo. Ao mesmo tempo, devido às especificidades da situação, as partes costumam ter tempo suficiente e diversas formas de resolvê-la (formais, informais, reuniões, cartas, decisões de gestão, presença de metas e planos da equipe, o fato de uma hierarquia, etc.). Isso é diferente da situação de resolver uma questão de trabalho (ou não trabalhista) em uma organização de, por exemplo, resolver uma questão importante: “Ei, garoto, de que área você é?!” na rua, ou o conflito da epígrafe. No caso de resolução de um problema de trabalho, a qualidade do processo de trabalho e a cultura de resolução de problemas na equipe são importantes.
Em terceiro lugar, o factor determinante do conflito (do ponto de vista da nossa discussão) é o facto de as partes no processo não poderem chegar de forma independente a uma solução para a questão que seja adequada a todas as partes. A situação exige a intervenção de um terceiro, 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, esta é a situação pela qual devemos lutar. . Muito provavelmente nem saberemos de tal conflito, ou descobriremos por acaso depois de resolvido. Quanto mais problemas uma equipe conseguir resolver sozinha, mais eficaz ela será.
Outra característica do conflito que vale a pena abordar é o grau de intensidade emocional durante a decisão. O conflito não está necessariamente associado a um alto nível emocional. Os participantes não precisam gritar e agitar os braços para que a situação seja, em essência, um conflito. A questão não está resolvida, existe uma certa tensão emocional (talvez não se exprima claramente exteriormente), o que significa que nos deparamos com uma situação de conflito.
É mesmo necessário intervir nas situações de conflito ou é melhor deixar a sua resolução seguir o seu curso e esperar que o problema se resolva? Preciso. Nem sempre está em seu poder ou competência resolver completamente o conflito, mas em qualquer situação, em um conflito de qualquer escala, você pode assumir uma posição adulta, trazendo assim várias outras pessoas ao seu redor, mitigando as consequências negativas do conflito e contribuir para a sua resolução.
Antes de examinar alguns exemplos de situações de conflito, vejamos alguns pontos importantes comuns a todos os conflitos.
Na resolução de um conflito é importante estar acima da luta, e não dentro dela (isto também se chama “tomar uma meta-posição”), ou seja, não fazer parte de uma das partes no processo de resolução. Caso contrário, ter um árbitro externo auxiliando na decisão apenas fortalecerá a posição de uma das partes em detrimento da outra parte. Ao tomar uma decisão, é importante que ela seja moralmente aceita por todas as partes, como dizem, “comprada”. De modo que, mesmo que as partes não tenham ficado satisfeitas com a decisão tomada, pelo menos concordaram sinceramente em implementá-la. Como se costuma dizer, poder discordar e comprometer-se. Caso contrário, o conflito simplesmente mudará de aparência, o fogo latente permanecerá sob a turfeira e, em algum momento, inevitavelmente explodirá novamente.
O segundo ponto, em parte relacionado com o primeiro, é que se você já decidiu participar na resolução do conflito, leve-o o mais a sério possível do ponto de vista da comunicação e do estudo do contexto. Fale pessoalmente com cada uma das partes. Separadamente com cada um, para começar. Não se contente com o correio. No caso de equipe distribuída, pelo menos converse por videoconferência. Não se contente com boatos e relatos de testemunhas oculares. Compreender a história, o que cada lado quer, porque o querem, o que esperam, já tentaram resolver esta questão antes, o que acontecerá se não for resolvido, que soluções vêem, como imaginam a posição do outro lado, o que eles pensam, certo ou errado, etc. Carregue todo o contexto possível em sua cabeça, com a mente aberta, presumindo que todos estão certos. Você não está dentro do conflito, você está fora dele, numa metaposição. Se o contexto estiver disponível apenas em um tópico de postagem, pelo menos leia-o na íntegra e os tópicos e documentos relacionados a ele. Depois de ler, continue falando com sua voz. É quase certo que você ouvirá algo importante que não está no correio.
O terceiro ponto importante é a abordagem geral da comunicação. São coisas comuns, nada cósmicas, mas são muito importantes. Não tentamos economizar tempo, conversamos com todos os participantes, não criticamos a pessoa, mas consideramos as consequências de suas ações (não “você é rude”, mas “talvez os caras possam se ofender com essa coisa”), damos a oportunidade de salvar a face, conduzimos discussões pessoalmente, não na frente da fila.
Os conflitos geralmente são causados por um de dois motivos. A primeira está relacionada com se uma pessoa no momento do conflito está na posição de um adulto ou na posição de uma criança (mais sobre isto abaixo). Isso se deve à sua maturidade emocional, à capacidade de administrar suas emoções (que, aliás, nem sempre está relacionada à sua idade). A segunda razão comum é a imperfeição do processo de trabalho, que cria situações de zonas cinzentas em que a responsabilidade está distribuída entre os participantes, as expectativas das partes não são transparentes entre si e os papéis no processo são confusos.
Assim, ao resolver um conflito (bem como qualquer outro problema), um gestor deve ter em mente três perspectivas: curto prazo - para resolver o problema/conflito aqui e agora, médio prazo - para minimizar a probabilidade de surgimento de outro conflito. pela mesma razão, e a longo prazo - cultivar uma cultura adulta na pessoa da equipe.
Cada um de nós tem uma criança interior, com cerca de três ou quatro anos. Ele dorme a maior parte do tempo no trabalho, mas às vezes acorda e assume o controle. A criança tem suas próprias prioridades. É importante que ele insista que esta é a sua caixa de areia, a sua mãe o ama mais, a sua máquina é a melhor (o design é o melhor, ele programa o melhor, ...). Numa situação de conflito, uma criança pode apertar brinquedos, bater os pés e quebrar a espátula, mas não consegue resolver problemas de adultos (arquitetura de solução, abordagens para testes automatizados, datas de lançamento, etc.), não pensa em termos de benefícios Pela equipa. Uma criança em conflito pode ser encorajada, consolada e mandada para a cama pedindo-lhe que ligue para o seu adulto. Antes de iniciar uma discussão em uma situação de conflito, certifique-se de estar falando com um adulto, não com uma criança, e de que você mesmo está na posição de um adulto. Se o seu objetivo honesto no momento é resolver um problema sério, você está na posição de um adulto. Se o seu objetivo é bater os pés e quebrar a omoplata, esta é uma posição infantil. Mande sua criança interior para a cama e ligue para um adulto ou remarque a discussão. Uma pessoa toma uma decisão emocional e depois procura uma justificativa racional para isso. Uma decisão tomada por uma criança com base nas suas prioridades não será a ideal.
Além do comportamento no momento do conflito, a posição da criança ou do adulto também é caracterizada pelo nível de responsabilidade que a pessoa está disposta a assumir. Em suas manifestações extremas, a posição infantil de um programador, que conheci mais de uma vez, é a seguinte: escrevi o código, enviei para revisão - meu trabalho está concluído. Os revisores devem revisá-lo e aprová-lo, o controle de qualidade deve verificar, se houver problemas, eles me avisarão. Curiosamente, mesmo pessoas bastante maduras e experientes às vezes se comportam dessa maneira. O outro extremo da escala é que uma pessoa se considera responsável por garantir que seu código funcione, seja coberto por testes, tenha sido verificado pessoalmente por ele, tenha sido aprovado na revisão (se necessário, não há problema em enviar ping aos revisores, discutir questões por voz, etc.) e foi suprimido, o controle de qualidade fornecerá assistência se necessário, os cenários de teste serão descritos, etc. Em casos normais, o programador começa mais perto do nível adulto da escala ou avança para lá à medida que ganha experiência (desde que a cultura certa seja cultivada dentro da equipe). Em casos extremos, ele continua trabalhando, geralmente assumindo uma postura infantil, então ele e a equipe periodicamente têm problemas e conflitos.
Promover a cultura correta e madura em uma equipe é uma tarefa importante para qualquer gestor. É preciso muito tempo e esforço diário, mas o resultado vale a pena. Existem duas maneiras de influenciar a cultura da equipe – liderando pelo exemplo (que com certeza será seguido; a equipe sempre olha para o líder) e discutindo e recompensando o comportamento correto. Também não há nada obscuro ou muito formal aqui, apenas ao discutir problemas, observe que algo poderia ter sido feito aqui, enfatize que você percebeu quando foi decidido corretamente, elogie, observe durante a revisão do lançamento, etc.
Consideremos várias situações de conflito típicas, das mais simples às mais complexas:
Conflitos não relacionados a questões de trabalho
Muitas vezes há conflitos no trabalho que não estão relacionados a questões trabalhistas. Sua ocorrência e facilidade de resolução costumam estar diretamente relacionadas ao nível de inteligência emocional dos participantes, ao seu nível de maturidade, e não estão relacionadas à perfeição ou imperfeição do processo de trabalho.
Exemplos típicos: alguém não usa a máquina de lavar ou o chuveiro com frequência suficiente, o que outros não gostam, alguém é abafado, enquanto outros ficam com vento se abrirem a janela, alguém faz muito barulho e outros precisam de silêncio para trabalhar, e breve. É melhor não atrasar a resolução de conflitos deste tipo e não deixá-los seguir o seu curso. Eles não resolverão por conta própria e irão distraí-lo do trabalho todos os dias e envenenar o ambiente da equipe. Felizmente, resolvê-los geralmente não é um grande problema - basta conversar calmamente (individualmente, é claro) com um colega que negligencia a higiene, fornecer assentos confortáveis para pessoas que preferem silêncio/frieza, comprar fones de ouvido com absorção de som ou instalar divisórias , etc.
Outro exemplo que encontrei diversas vezes durante meu trabalho é a incompatibilidade psicológica dos membros da equipe. Por alguma razão, as pessoas simplesmente não conseguem trabalhar juntas; toda interação termina em escândalo. Às vezes, isso se deve ao fato de as pessoas terem opiniões divergentes sobre alguma questão urgente (geralmente política) e não saberem como deixá-las fora do trabalho. Convencê-los a tolerar uns aos outros ou a mudar seu comportamento é uma tarefa bastante fútil. A única exceção que encontrei são os jovens colegas com percepções abertas; o seu comportamento ainda pode ser gradualmente mudado através de conversas periódicas. Normalmente, o problema é resolvido com sucesso separando-os em equipes diferentes ou, pelo menos, proporcionando a oportunidade de sobreposição no trabalho muito raramente.
Em todas as situações anteriores, vale a pena falar pessoalmente com todos os participantes, discutir a situação, perguntar se veem algum problema neste caso, perguntar quais são, na sua opinião, as soluções e garantir a sua participação na tomada desta decisão. decisão.
Do ponto de vista da otimização do processo de trabalho (a perspectiva de médio prazo que mencionei), não há muito que se possa fazer aqui; o único ponto de otimização é levar em conta o fator de compatibilidade na hora de formar uma equipe e não colocar pessoas juntos com antecedência quem entrará em conflito.
Do ponto de vista da cultura de equipa, tais situações surgem com muito menos frequência em equipas com uma cultura madura, onde as pessoas respeitam a equipa e os colegas e sabem como resolver problemas de forma independente. Além disso, tais conflitos são resolvidos muito mais facilmente (muitas vezes de forma automática) em equipas onde existe um elevado nível de confiança, as pessoas trabalham juntas há muito tempo e/ou comunicam frequentemente fora do trabalho.
Conflitos relacionados a questões de trabalho:
Tais conflitos costumam ser causados por dois motivos ao mesmo tempo, tanto emocionais (o fato de um dos participantes não estar na posição de adulto) quanto pela imperfeição do próprio processo de trabalho. Talvez o tipo de conflito mais comum que encontrei sejam conflitos durante revisões de código ou discussões de arquitetura entre desenvolvedores.
Eu destacaria dois casos típicos aqui:
1) No primeiro caso, o desenvolvedor não pode obter uma revisão de código de um colega. O patch é enviado para revisão e nada acontece. À primeira vista, não há nenhum conflito óbvio entre os dois lados, mas se você pensar bem, é um grande conflito. A questão trabalhista não é resolvida, uma das partes (aguardando revisão) sente um desconforto evidente. Um subtipo extremo deste caso é o desenvolvimento em uma comunidade ou em equipes diferentes, enquanto o revisor pode não estar interessado neste código específico, devido ao carregamento ou outras circunstâncias, pode não prestar atenção à solicitação de revisão, e o árbitro externo (um gestor comum a ambos os lados)) pode nem existir.
A abordagem de solução que ajuda em tal situação relaciona-se precisamente com a perspectiva de longo prazo, a cultura de um adulto. Primeiro, a atividade inteligente funciona. Você não deve esperar que o código pendurado na revisão atraia a atenção do próprio revisor. Precisamos ajudar os revisores a notá-lo. Pingani algumas pessoas, faça perguntas sobre sincapagem, participe de discussões. Obviamente, é mais provável que a importunação prejudique do que ajude, é preciso usar o bom senso. Em segundo lugar, a pré-preparação funciona bem. Se a equipe entender o que está acontecendo e por que, por que esse código é necessário, se o design for discutido e acordado antecipadamente com todos, é mais provável que as pessoas prestem atenção a esse código e o aceitem para funcionar. Em terceiro lugar, a autoridade funciona. Se você quiser ser avaliado, faça muitas avaliações você mesmo. Faça análises de alta qualidade, com verificações reais, testes reais e comentários úteis. Se o seu apelido for bem conhecido na equipe, há maiores chances de seu código ser notado.
Do ponto de vista do fluxo de trabalho, possíveis melhorias aqui são a priorização correta que visa ajudar o desenvolvedor a atingir seus objetivos e os da equipe (revisar outros, escrever cartas para a comunidade, acompanhar o código com uma descrição de arquitetura, documentação, testes, participar de discussões com comunidade, etc.), evitar que os patches fiquem na fila por muito tempo e assim por diante.
2) O segundo caso comum de conflitos durante revisões de código ou design são visões diferentes sobre questões técnicas, estilo de codificação e escolha de ferramentas. De grande importância neste caso é o nível de confiança entre os participantes, pertencentes à mesma equipa, e a experiência de trabalho em conjunto. O beco sem saída ocorre quando um dos participantes assume uma postura infantil e não tenta ouvir o que o interlocutor quer lhe transmitir. Muitas vezes, tanto a abordagem proposta pela outra parte como a abordagem proposta inicialmente podem funcionar com sucesso e não importa, em princípio, qual delas escolher.
Um dia, um programador da minha equipe (vamos chamá-lo de Pasha) preparou um patch com alterações no sistema de implantação de pacotes, que foi desenvolvido e apoiado por colegas de um departamento vizinho. Um deles (Igor) tinha uma opinião forte sobre como exatamente os serviços Linux deveriam ser configurados ao implantar pacotes. Esta opinião diferia da abordagem proposta no patch e eles não concordavam. Como sempre, os prazos estavam se esgotando e era preciso tomar alguma decisão, era preciso que um deles assumisse um cargo de adulto. Pasha reconheceu que ambas as abordagens têm direito à vida, mas queria que sua opção fosse aprovada, porque Nem uma nem a segunda opção apresentavam vantagens técnicas óbvias.
Nossa discussão foi mais ou menos assim (de forma muito esquemática, é claro, a conversa durou meia hora):
- Pasha, teremos um congelamento de recursos em alguns dias. É importante juntarmos tudo e começarmos os testes o mais rápido possível. Como podemos passar por Igor?
— Ele quer configurar os serviços de forma diferente, colocou comentários aí para mim...
- E o que há, grandes alterações, muito rebuliço?
- Não, dá trabalho algumas horas, mas no final não faz diferença, vai funcionar de qualquer maneira, por que isso é necessário? Eu fiz algo que funciona, vamos aceitar.
- Escute, há quanto tempo você está discutindo tudo isso?
- Sim, já estamos marcando passo há uma semana e meia.
- Hum... podemos resolver em algumas horas um problema que já demorou uma semana e meia, e não resolver?
- Bem, sim, mas não quero que o Igor pense que eu desabei...
- Escute, o que é mais importante para você, emitir uma liberação, junto com sua decisão interna, ou matar o Igor? Podemos bloqueá-lo, entretanto, há uma boa chance de voar com a liberação.
- Bom... seria legal, claro, limpar o nariz do Igor, mas tudo bem, a liberação é mais importante, eu concordo.
- É realmente importante para você o que o Igor pensa? Para ser sincero, ele não dá a mínima, ele só quer uma abordagem unificada em diferentes áreas da coisa pela qual é responsável.
- Bom, ok, deixa eu fazer como ele pede nos comentários e vamos começar os testes.
- Obrigado, Paxá! Eu tinha certeza que vocês dois seriam os mais maduros, embora Igorek seja mais velho que você :)
O problema foi resolvido, o lançamento foi liberado dentro do prazo, Pasha não sentiu muita insatisfação, pois ele mesmo propôs uma solução e a implementou. Igor ficou geralmente satisfeito, porque... Sua opinião foi levada em consideração e eles fizeram o que ele sugeriu.
Outro tipo de conflito essencialmente igual é a escolha entre soluções/bibliotecas/abordagens técnicas em um projeto, especialmente em uma equipe distribuída. Em um dos projetos, que foi posicionado como utilizando C/C++, descobriu-se que a gestão técnica do projeto era categoricamente contra o uso de STL (Standard Template Library). Esta é uma biblioteca de linguagem padrão que simplifica o desenvolvimento e nossa equipe está muito acostumada com isso. Descobriu-se que o projeto está muito mais próximo do C do que do C++, o que não inspirou muito a equipe, pois a administração deu o seu melhor e recrutou jogadores plus muito legais. Ao mesmo tempo, a parte americana da equipe, tanto engenheiros quanto gestores, já trabalhavam na empresa há muito tempo, estavam acostumados com a situação atual e estavam satisfeitos com tudo. A parte russa da equipe foi reunida recentemente, em poucas semanas (inclusive eu). A parte russa da equipe não queria categoricamente abandonar a abordagem usual de desenvolvimento.
Intermináveis discussões escritas começaram entre os dois continentes, cartas em três ou quatro telas voavam de um lado para outro, em correspondências de grupo e pessoais, de programadores para programadores e gerentes. Como costuma acontecer, cartas desse tamanho não foram lidas por ninguém, exceto pelos autores e seus fervorosos apoiadores. Os bate-papos estalavam de tensão, transmitindo pensamentos em várias telas em diferentes direções sobre as vantagens técnicas do STL, quão bem testado ele é, quão seguro é e, em geral, quão maravilhosa é a vida com ele e quão terrível é sem ele .
Tudo isto durou bastante tempo, até que finalmente percebi que estávamos a discutir os aspectos técnicos da questão, mas o problema na realidade não era técnico. O problema não são as vantagens ou desvantagens do STL ou a dificuldade de trabalhar sem ele. O problema é bastante organizacional. Só precisávamos entender como funcionava a empresa em que trabalhávamos. Nenhum de nós tinha experiência de trabalho em tal empresa antes. Acontece que depois que o código foi desenvolvido e colocado em produção, o suporte passou a ser feito por pessoas completamente diferentes, de outras equipes, de outros países. Esta enorme equipe de engenharia de várias dezenas de milhares de engenheiros (no total) só poderia pagar um mínimo completamente básico de meios técnicos, por assim dizer, um mínimo mínimo. Qualquer coisa que fosse além do padrão de engenharia estabelecido fisicamente na empresa não poderia ser suportada no futuro. O nível de uma equipe é determinado pelo nível dos seus membros mais fracos. Depois que entendemos verdadeira motivação ações da parte americana da equipe, esse assunto foi retirado da pauta e juntos desenvolvemos e lançamos com sucesso o produto utilizando os padrões adotados pela empresa. Cartas e bate-papos neste caso não funcionaram bem; foram necessárias várias viagens e muita comunicação pessoal para chegar a um denominador comum.
Do ponto de vista do fluxo de trabalho, neste caso específico, ajudaria ter uma descrição das ferramentas utilizadas, requisitos para elas, restrições para adição de novas e justificativa para tais restrições. Tais documentos correspondem aproximadamente aos descritos nos parágrafos Estratégia de Reutilização e Ambiente de Desenvolvimento do “Manual do Gerente para Desenvolvimento de Software”, desenvolvido em . Apesar da idade, descreve perfeitamente todas as principais atividades e etapas de planejamento do desenvolvimento de software deste tipo. Ter documentos como este torna muito fácil discutir quais componentes e abordagens podem ser usados em um produto e por quê.
Do ponto de vista cultural, obviamente, com uma postura mais madura, em que as partes procuram ouvir e compreender a real motivação das ações dos seus colegas e agir com base nas prioridades do projeto e da equipa, e não no ego pessoal , o conflito seria resolvido de forma mais fácil e rápida.
Num outro conflito sobre a escolha de uma solução técnica, também demorei bastante tempo a compreender a motivação de uma das partes (foi um caso muito invulgar), mas depois de a motivação ficar clara, a solução era óbvia.
A situação é a seguinte: surge um novo desenvolvedor em uma equipe de cerca de 20 pessoas, vamos chamá-lo de Stas. Naquela época, nossa ferramenta padrão para comunicação em equipe era o Skype. Como se descobriu mais tarde, Stas era um grande fã de padrões abertos e software de código aberto, e usava apenas ferramentas e sistemas operacionais cujas fontes estavam disponíveis publicamente e que usavam protocolos descritos publicamente. O Skype não é uma dessas ferramentas. Passamos muito tempo discutindo as vantagens e desvantagens dessa abordagem, as tentativas de lançar análogos do Skype em diferentes sistemas operacionais, as tentativas de Stas de convencer a equipe a mudar para outros padrões, escrever para ele pessoalmente pelo correio, ligar para ele pessoalmente no telefone, compre para ele um segundo computador especificamente para Skype, etc. Por fim, percebi que este problema, em essência, não é técnico ou organizacional, é antes ideológico, até, pode-se dizer, religioso (para Stas). Mesmo que eventualmente conectássemos o Stas e o Skype (o que levou vários meses), o problema surgiria novamente em qualquer instrumento subsequente. Eu não tinha meios reais à minha disposição para mudar a visão de mundo de Stas e não havia razão para tentar mudar a visão de mundo de uma equipe que funcionava perfeitamente nesse ambiente. A pessoa e a empresa eram simplesmente ortogonais em sua visão de mundo. Nessas situações, uma boa solução é organizacional. Transferimos o Stas para outro time, onde ele era mais orgânico.
A razão deste conflito, na minha opinião, é a discrepância entre a cultura pessoal de uma determinada pessoa (que tem uma opinião forte que não lhe permite transigir) e a cultura da empresa. Neste caso, é claro que o erro do gestor. Inicialmente foi errado aceitá-lo para um projeto deste tipo. Stas eventualmente mudou para um projeto de desenvolvimento de software de código aberto e se destacou lá.
Um bom exemplo de conflito causado tanto pela atitude infantil do desenvolvedor quanto pelas deficiências do processo de trabalho é uma situação em que, na ausência de uma definição de feito, o desenvolvedor e a equipe de QA têm expectativas diferentes em relação à prontidão do o recurso transferido para o controle de qualidade. O desenvolvedor acreditava que era suficiente escrever o código e lançar o recurso por cima do muro para o controle de qualidade - eles resolveriam o problema lá. A propósito, um programador bastante maduro e experiente, mas esse era o seu limite interno de qualidade. O controle de qualidade discordou disso e exigiu mostrar e descrever o que ele mesmo havia verificado e exigiu um script de teste para eles. Eles tiveram problemas com a funcionalidade deste desenvolvedor no passado e não queriam perder tempo novamente. A propósito, eles estavam certos - o recurso realmente não funcionou, ele não verificou o código antes de enviá-lo para o controle de qualidade.
Para resolver a situação, pedi para ele me mostrar que tudo realmente funcionou (não funcionou, e ele teve que consertar), conversamos com a equipe e com a definição de QA de pronto (não conseguiram em escrevendo, porque não queríamos burocratizar muito o processo ), bom, logo nos separamos desse especialista (para alívio geral).
Do ponto de vista do fluxo de trabalho, possíveis melhorias neste caso são a presença de uma definição de feito, requisitos para suporte de cada funcionalidade unitária e testes de integração e uma descrição dos testes realizados pelo desenvolvedor. Em um dos projetos, medimos o nível de cobertura de código por meio de testes durante CI e se o nível de cobertura caísse após adicionar um patch, os testes eram marcados como falhados, ou seja, qualquer novo código só poderia ser adicionado se houvesse novos testes para ele.
Outro exemplo típico de conflito intimamente relacionado à organização do processo de trabalho. Temos um produto, uma equipe de desenvolvimento de 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 entende que o problema está no produto e transfere o problema para a equipe do produto. A equipe de produto está ocupada, um lançamento se aproxima, então um ticket com um problema de um cliente, perdido entre os outros tickets do desenvolvedor a quem está atribuído, fica pendurado por várias semanas sem atenção. O suporte pensa que o desenvolvedor está trabalhando no problema do cliente. O cliente espera e espera que seu problema esteja sendo resolvido. Na realidade, nada está acontecendo ainda. Depois de algumas semanas, o cliente finalmente decide se interessar pelo andamento e pergunta ao suporte como estão as coisas. Apoio pede desenvolvimento. O desenvolvedor estremece, olha a lista de tickets e encontra ali um ticket do cliente. Ao ler um ticket de um cliente, ele entende que não há informações suficientes para resolver o problema e precisa de mais logs e dumps. O suporte solicita informações adicionais do cliente. E então o cliente percebe que ninguém esteve trabalhando no problema dele todo esse tempo. E o trovão cairá...
Nessa situação, a solução do conflito em si é bastante óbvia e linear (consertar o produto, atualizar documentação e testes, apaziguar o cliente, lançar um hotfix, etc.). É importante analisar o processo de trabalho e perceber quem é o responsável por organizar a interação entre as duas equipas e porque é que esta situação se tornou possível em primeiro lugar. Está claro o que precisa ser corrigido no processo - alguém deve monitorar o quadro geral sem lembretes dos clientes, de forma proativa. Os tickets do cliente devem se destacar dos demais tickets dos desenvolvedores. O suporte deve verificar se a equipe de desenvolvimento está atualmente trabalhando em seus tickets e, caso contrário, quando poderá começar a trabalhar e quando os resultados poderão ser esperados. O suporte e o desenvolvimento devem comunicar e discutir periodicamente o status dos tickets, a coleta de informações necessárias para a depuração deve ser automatizada tanto quanto possível, etc.
Assim como na guerra o inimigo tenta acertar a junção entre duas unidades, também no trabalho o ponto mais delicado e vulnerável costuma ser a interação entre as equipes. Se os gestores de suporte e desenvolvimento tiverem idade suficiente, eles próprios poderão resolver o processo; caso contrário, o processo continuará a gerar conflitos e problemas até que intervenha um gestor que possa resolver a situação.
Outro exemplo típico que tenho visto repetidamente em diferentes empresas é uma situação em que um produto é escrito por uma equipe, os testes automáticos de integração para ele são escritos por uma segunda equipe e a infraestrutura na qual tudo é operado é acompanhada por uma terceira. equipe. Problemas durante a execução de testes surgem o tempo todo, e a causa dos problemas neles pode ser tanto o produto quanto os testes e a infraestrutura. Geralmente é problemático chegar a um acordo sobre quem deve realizar a análise inicial dos problemas, arquivar bugs, analisar logs do produto, testes e infraestrutura, etc. Os conflitos aqui são muito frequentes e, ao mesmo tempo, uniformes. No caso de alta intensidade emocional, os participantes muitas vezes caem em uma posição infantil e as discussões começam na série: “por que eu deveria mexer nisso”, “eles quebram com mais frequência”, etc.
Do ponto de vista do fluxo de trabalho, as etapas específicas para resolver um problema dependem da composição das equipes, do tipo de testes e produto, etc. Em um dos projetos, introduzimos o plantão periódico, em que as equipes monitoravam os testes um de cada vez, semana a semana. No outro, a análise inicial sempre foi feita pelos desenvolvedores dos testes, mas a análise foi muito básica e o produto ficou bastante estável, então funcionou bem. A chave é garantir que o processo seja transparente, que as expectativas sejam claras para todas as partes e que a situação seja justa para todos.
O conflito é mesmo um problema em uma organização? É um mau sinal que conflitos ocorram com frequência (ou apenas periodicamente) em sua equipe? Em geral não, porque se há crescimento, desenvolvimento, há algum tipo de dinâmica, então surgem questões que nunca foram resolvidas antes, e na hora de resolvê-las podem surgir conflitos. Este é um indicador de que algumas áreas precisam de atenção, de que existem áreas que podem ser melhoradas. É ruim se os conflitos surgirem com muita frequência, forem difíceis de resolver ou demorarem muito. Isto é provavelmente um sinal de processos de trabalho insuficientemente simplificados e de maturidade insuficiente da equipa.
Fonte: habr.com