Como tentamos assédio moral

Se você tentar encontrar mobbing ou Mobbing em um mecanismo de pesquisa, uma parte significativa dos resultados será sobre "abuso psicológico de pessoas". Portanto, é melhor procurar imediatamente "programação mob". Nos 10 principais resultados do Yandex no momento (27/02/2019), há apenas um artigo em russo (e esse é uma tradução), mas há muitos artigos em inglês. Se você os olha com fluência, a maioria deles é uma teoria, não uma análise de qualquer caso prático. Todo mundo diz que isso ajudará a equipe a se tornar mais eficaz, distribuir localmente o conhecimento do projeto e desenvolver habilidades pessoais nas pessoas. Eu mesmo testei mobbing na prática durante um dos treinamentos de scrum e, francamente, fiquei encantado! Após consultar a equipe, decidimos realizar nossa sessão de teste de assédio moral.

Entre as vantagens dessa abordagem no trabalho, identificamos para nós mesmos valores como a disseminação de conhecimentos dentro da equipe e o desenvolvimento de habilidades adicionais para cada participante. Depois de organizar uma reunião dedicada ao assédio moral, estabelecemos três objetivos: primeiro, tentar assédio moral na prática. Em segundo lugar, para entender quais são as desvantagens e fatores negativos no nosso caso. Terceiro, determine se isso trará os valores acima para nossa equipe.

O que é mobbing

O fundador do mobbing como um estilo de trabalho de Woody Zuill o descreve da seguinte forma:

pessoas maravilhosas trabalhando juntas em uma tarefa ao mesmo tempo em um só lugar em um computador.

Ou seja, Mobbing é um estilo de trabalho quando uma equipe trabalha constantemente em conjunto e “se lança” em qualquer tarefa. Ao mesmo tempo, a tarefa passa por todas as etapas necessárias do seu ciclo de vida, e cada membro da equipe trabalha nela simultaneamente com todos. Assim, a imersão e o entendimento da tarefa por toda a equipe são alcançados.

Existem vários papéis no mobbing:

• Motorista: senta-se em um local de trabalho comum, faz exatamente o que o navegador diz.
• Navegador: dá instruções ao motorista. Se ele não sabe o que fazer, ele consulta a multidão (o resto da equipe), transmite as ações necessárias para o motorista.
• Mob: participa do desenvolvimento, informa ao navegador o que o motorista deve fazer.
• PO (proprietário do produto): sabe exatamente o que deve acontecer. Define a direção desejada para o movimento da equipe. Pode ser um motorista e um navegador.
• Facilitador: monitora o cumprimento das regras, anuncia mudanças, estaciona idéias. É desejável que exista uma pessoa nessa função.

Mobbing consiste em uma sessão, que consiste em ciclos, cada um dos quais consiste em turnos.
Sessão - período de tempo em que uma equipe trabalha em uma tarefa. Antes da sessão, a tarefa é selecionada e dividida em estágios, e seu objetivo é determinado - o que precisa ser obtido como resultado, por exemplo, o incremento do funcional.

Alterar - o intervalo de tempo entre a alteração das funções do motorista e do navegador. A mudança dura, via de regra, de 15 a 20 minutos. Mudanças mais curtas contribuem para maior velocidade e maior envolvimento da equipe.

Regras do jogo

Durante o turno, o motorista fica sentado no computador compartilhado e faz exatamente o que o navegador diz. A equipe observa e, se necessário, discute o que precisa ser feito. O navegador estrutura essa discussão e transmite ao motorista o que exatamente ele precisa fazer agora. O motorista ouve apenas as instruções do navegador e pode fazer perguntas. O navegador pode transmitir a pergunta para a equipe. O facilitador "estaciona" idéias que foram expressas, mas não usadas por um motivo ou outro.

No final da mudança de função, as funções de motorista e navegador são transferidas para outras pessoas em uma fila predefinida: o navegador atual vai para a multidão, o motorista se torna o navegador e a próxima pessoa na fila se torna o motorista da multidão. Quando cada membro da equipe visitou cada uma das funções, o “círculo se fecha”, ou seja, o ciclo termina.



Após a sessão de mobbing, cada um de nós compartilhou suas impressões, com base nas quais certas conclusões foram tiradas. Como resultado, obtivemos um resultado que deu uma compreensão de como e quando é melhor usar o mobbing e se ele se adequa à nossa equipe. Vou começar com impressões negativas.

Negativo

Às vezes, o papel do navegador não é totalmente claro. Em algum momento, por exemplo, o analista pode estar nessa função e o desenvolvedor pode ser o motorista. O navegador recontou o que a equipe estava dizendo a ele, sem entender completamente "o que tudo isso significa", devido à falta de experiência em desenvolvimento. Como resultado, surgiram situações em que o navegador simplesmente não fazia sentido transmitir as instruções do comando, porque, primeiro, o desenvolvedor ouve o comando, então por que ele precisa de um intermediário? Em segundo lugar, o motorista entende como agir nessa situação, mas de acordo com as regras do papel, suas mãos estão atadas.

Também observamos que, se o navegador precisar examinar a próxima guia no ambiente de desenvolvimento para determinar a próxima etapa, ele precisará expressar essa ideia e aguardar que o driver mude a guia. Ele próprio teria feito isso enquanto manifestava o pedido ao motorista, com todos "sejam gentis" e "por favor, obrigado".

A dificuldade é que temos dois desenvolvedores trabalhando remotamente. Em primeiro lugar, adicionou tempo para uma operação como “alternar os direitos para o cursor”: para que o administrador remoto pudesse mostrar algo na tela, mas ao mesmo tempo não assumir o controle do mouse. Para isso, foi necessário expandir a janela de controle da conferência, habilitar a pessoa certa a controlar o cursor e minimizar a janela. Não leva muito tempo, mas distrai muito, impede-a de uma tarefa (na qual ela acaba de começar a mergulhar) e geralmente interfere. Como resultado, após cada turno, o novo navegador precisava perguntar ao anterior o que ele queria fazer agora, ambos tinham que se lembrar disso, “sincronizar” e só então seguir em frente.

Outra dificuldade devido ao “afastamento” de alguns funcionários são seus vizinhos. Em algum momento, um vizinho do navegador remoto decidiu fazer furos em toda a casa, então ouvimos uma gama completa de sons acompanhantes com amplificação. Isso, como você sabe, não nos ajudou em nada.

Como tínhamos muito tempo limitado (uma hora para uma sessão de assédio moral), nossos turnos eram muito curtos - 5 minutos (para que cada participante tivesse tempo de visitar esse ou aquele papel pelo menos uma vez). Também é fortemente, na minha opinião, refletido no progresso. Como dito anteriormente, todos os participantes da sessão estavam imersos na tarefa somente no final do turno (1-2 minutos até o final) e, após esse curto período de tempo, todos estavam distraídos com a mudança. É claro que você não fará muito dessa maneira.

Outra equipe gostaria de mais tempo para pensar “silenciosamente” e discutir idéias, mas mudanças frequentes provocavam a tentativa de examinar mais com as mãos do que a hipótese.

Não consideramos o caso mais simples para uma experiência de uma hora: uma tarefa de outro projeto que não era muito familiar para nossa equipe. Na maioria das vezes, descobrimos como esse pedaço de código que precisamos alterar geralmente funciona. Durante o total de 7 horas de trabalho (1 hora para cada membro da equipe), realmente não entendemos qual lado abordar essa tarefa.

O fator foi observado que toda a equipe vê a solução para o problema de um certo ponto de vista, incluindo um testador. Assumimos que no futuro (quando chegássemos ao estágio apropriado) isso poderia afetar negativamente a objetividade dos testes, porque todos saberíamos "como funciona" e subconscientemente tentaríamos evitar gargalos. Infelizmente, isso é apenas uma suposição.

Mas nossa outra hipótese foi confirmada. Mesmo antes da sessão, sugerimos que, se pessoas com visões diferentes se depararem enquanto trabalham na mesma tarefa, haverá uma corrida de idéias. Foi exatamente o que aconteceu: alguns desenvolvedores sugeriram a depuração local por meio de testes de integração, outros - implementando completamente o processo de negócios que deveria ser alterado. Cada lado apresentou argumentos convincentes. Saímos dessa situação devido ao fato de termos decidido tentar uma abordagem primeiro e, se no momento acordado percebermos que esse método exige mais trabalho, usaremos uma opção alternativa.

As configurações no ambiente de desenvolvimento acabaram sendo um obstáculo: cada um dos desenvolvedores se sente confortável com seus próprios parâmetros específicos. Nesse caso, havia apenas um ambiente de desenvolvimento e, é claro, nem todos gostaram de suas configurações.

Conseguimos até cometer um erro de facilitação: pouco antes do final do turno, o futuro motorista foi tomar um chá. Como resultado, seu navegador também saiu para preparar o chá, e assim perdemos um turno no tempo.

Como você pode ver, alguns fatores negativos surgiram como resultado de erros organizacionais, mas, no entanto, eles mostraram como fazer melhor e por quê.

Positivo

Os participantes observaram que esse estilo de trabalho permite que as pessoas que normalmente recebem tarefas da empresa as analisem e testem, se aprofundem no processo de solução direta desses problemas. Eles viram trabalho neles do outro lado: quais etapas uma tarefa percorre no caminho para sua implementação. Tornou-se óbvio para eles quais ações os desenvolvedores estão realizando para entender como abordar sua solução. Assim, todo mundo vê e entende o que está acontecendo atualmente com a tarefa.

Tornou-se óbvio para alguns de nós por que os desenvolvedores geralmente exigem uma análise mais profunda ao descrever uma tarefa e por que às vezes fazem perguntas bastante absurdas, à primeira vista, esclarecedoras.

Sem dúvida, esta é uma experiência nova e valiosa para cada um de nós. Além disso, uma colaboração tão incomum ajuda a fortalecer a equipe, ou seja, serve como uma espécie de formação de equipe: pela primeira vez, alguém viu o trabalho direto da outra pessoa, aprendeu seus pensamentos em uma determinada situação.

Resultados

Tendo discutido o feedback recebido uns dos outros sobre a sessão, chegamos a certas conclusões.

De acordo com nossos resultados, verificou-se que, no assédio moral, você não deve trabalhar absolutamente com toda a equipe, ou pelo menos não constantemente. Em nossa realidade, se toda a equipe estiver trabalhando em apenas uma tarefa, as negociações com os contratados não serão realizadas e as solicitações dos usuários não serão processadas. Você pode, é claro, fazer isso até o seu turno chegar, mas depois precisa se distrair, mudar para a tarefa que todos estão resolvendo e abandoná-la novamente e lembrar o que parou antes do turno.

É necessário que o navegador seja um pouco mais experiente que o motorista. Caso contrário, acaba sendo um jogo de telefone quebrado, quando o navegador tenta passar literalmente ao motorista o que ele disse, sem entender completamente "o que tudo isso significa". Você pode, por exemplo, alterar os papéis por vez. Se você não pode fornecer aos casais navegadores mais poderosos, mas precisa ensinar as pessoas a trabalhar não apenas de acordo com a especialização deles, então, em nossa opinião, a programação de pares será mais eficaz.

Temos a impressão de que o mobbing funcionaria bem quando novos desenvolvedores aparecessem na equipe, ou alguém da equipe decidisse programar. Então, ao conduzir ataques com desenvolvedores experientes, os recém-chegados mergulham rapidamente em projetos de equipe e entendem os princípios e regras de trabalho geralmente aceitos.

Da mesma forma, você pode trabalhar em uma tarefa na qual apenas uma pessoa em uma equipe possui experiência (sim, temos essa pessoa e esse projeto) para difundir conhecimento entre as demais.

Tínhamos a suposição de que mobbing é bom para equipes de tigres: equipes formadas para resolver alguma tarefa urgente. Mas isso pode funcionar se, pelo menos, a equipe estiver na mesma sala e com o ambiente de desenvolvimento preparado para a maioria. Caso contrário, haverá perda de tempo devido a fatores de comunicação desnecessários.
Se uma equipe acabou de formar e, idealmente, um novo projeto está sendo formado junto com ela, o mobbing pode funcionar bem. Nesse caso, cada participante verá como e por que certas decisões conceituais, arquitetônicas e outras são tomadas, haverá um desequilíbrio no conhecimento sobre o projeto.

Por fim, as mudanças são necessárias por mais tempo. Pelo menos 15 a 20 minutos, em vez dos nossos 5. E você precisa fazer algo com a regra de que um motorista está apenas nas mãos de um navegador, sem cabeça própria.

Então, tentamos atacar na prática nas condições do trabalho de nossa equipe. Algumas regras interferiram conosco, algo que não entendemos, em algum lugar que cometemos erros. No entanto, sentimos sobre nós mesmos o que é, se é possível e se precisamos trabalhar nesse estilo. De acordo com os resultados desse experimento, não recebemos totalmente os valores que identificamos para nós mesmos como os mais importantes. Vale a pena considerar que tentamos mobbing por apenas uma hora com turnos muito curtos, porque esses resultados podem não ser os mais confiáveis. Ao trabalhar no assédio moral em "tempo integral", alguns problemas não surgirão e outros serão superados após a "adaptação" ao processo. Provavelmente, simplesmente não conseguimos obter os valores que precisávamos em tão pouco tempo. Para saber com certeza, vale a pena tentar assédio moral em outras situações, mas essa será uma história completamente diferente.

PS
Você pode ler e ver os seguintes materiais sobre o tópico:
GOTO 2017 - Programação de Mob: uma abordagem de equipe inteira - Woody Zuill
Woody Zuill - Um dia de Mob Program
Blog Agilix Consulting: Matando filas e acelerando uma equipe com Mobbing