Interromper intermináveis ​​discussões técnicas e tomar uma decisão

Eu sempre me deparo com pessoas que gostam de transar por idades sobre as menores "coisas técnicas".

Não me interpretem mal, sou um programador nerd que adora o que faço, mas você sabe o tipo de conversa.

• Mac é muito melhor que Windows
• Não use um loop For Each, use um loop While
• Não compre um PC baseado em Intel, adquira um baseado em AMD.
• Devemos usar um contêiner de IoC sobre outro.

Todas essas "coisas" têm prós e contras válidos para ambos os lados, e você nunca obterá uma resposta "correta", e a pessoa nunca aceitará o argumento. (é claro que haverá alguns em que há uma resposta, talvez :).

Minha pergunta (estou chegando lá !!) é: Em uma equipe de software, como você percorre essas longas discussões sem inibir a inovação, para que uma decisão possa ser tomada e você possa resolver os problemas reais dos negócios.

Problema 1. Algumas pessoas não gostam de perder. Se eles não estão dando os tiros, eles vão debater até que os chamem por atrito.

Problema 2. Nada está realmente em jogo, então o debate é tolerado.

Nada está em jogo? Sim. A maioria das decisões tem impacto quase zero em dólar. O fato de que tudo se resume a "bater por muito tempo" significa que ambas as escolhas são efetivamente idênticas.

O que fazer?

1. Perceba que nada está em jogo.

2. Perceba que em 2 ou 3 anos, todo o assunto será reaberto porque algo fora da organização mudou.

3. Atirar uma moeda. A sério. Basta escolher algo e seguir em frente. Algumas pessoas verão a tolice no debate. Algumas pessoas debaterão a natureza da moeda que está sendo lançada. Se as pessoas não podem ficar satisfeitas com o sorteio, elas têm problemas de ego e precisam aprender que (a) nada está em jogo eb) que a decisão será alterada em alguns anos.

Se eles não conseguem descobrir que nada está em jogo, precisam escrever o valor em dólar de ambos os lados do argumento. Em algum momento, alguém pode ver que estão gastando mais horas de trabalho em análise do que vale a decisão real. Um sorteio produz um valor igual por um custo menor.

Algumas coisas a considerar:

1. Aceite apenas argumentos quantificáveis. Se alguém disser que economizará tempo, peça para quantificá-lo e mantenha-o na resposta. Dessa forma, se eles estão falando besteira, eles só conseguem fazer isso antes que todos saibam que são um flush quebrado.

2. Faça com que as pessoas assumam a responsabilidade por suas recomendações. Deixe claro que, no final do ano, se eles fizerem chamadas ruins, farão parte de sua avaliação. Não me importo de debates, mas quero pessoas com a coragem de suas convicções - se você vai jurar que algo é ótimo e espera que a adotemos, é melhor você viver com as consequências.

Essas são coisas reais para se afastar dos dois problemas de S.Lott - que algumas pessoas não gostam de perder e que nada está em jogo. Minha resposta está em jogo, para que não haja debate por causa do debate.

1. Timebox a discussão. - Se levar mais de 5 minutos para cada lado declarar seu caso, será muito complexo. Na verdade, usamos temporizadores de cozinha para isso . Eles funcionam maravilhosamente e custam cerca de 5 dólares.
2. Exija que os participantes discutam com dados e experiência.
3. Mantemos as opções em cima da mesa. Depois que cada lado tiver tempo, passamos mais 5 minutos discutindo as implicações de cada abordagem. Após 20 minutos, saímos e fazemos (implementamos). Se não funcionar, seguiremos com a outra abordagem.

A regra é simples. Uma vez que você não sabe o que escolher - pense no que é melhor para a empresa.

Sim, a escolha Intel v AMD não é tão fácil. Mas qual é o melhor para sua empresa? Por exemplo, se houver uma pessoa responsável por encomendar coisas e ele levará anos para encomendar um PC com processador AMD, mas a Intel pode ser encomendada em um minuto e você realmente não se importa com o que será - basta pedir um baseado na Intel, porque é melhor para a empresa.

Normalmente, essas discussões são realmente apenas bikeshedding . Pessoas discutindo qual formato de transferência ou que armazenamento de dados usar e muitos outros detalhes que devem ser realmente transparentes para todos os componentes, exceto aquele que implementa os mesmos detalhes. Ninguém se importa, desde que o componente cumpra o contrato de projeto e os responsáveis ​​sejam capazes de responder às alterações do contrato em um período de tempo razoável.

A grande maioria de todos os problemas técnicos que você encontra no desenvolvimento de software são problemas de ciclismo. Simplesmente porque eles já têm soluções e a única pergunta é: qual solução você deseja escolher.
Você não deve se trancar nessas decisões. Você deve bloquear essas decisões em uma camada de abstração que dissocie seu aplicativo desses detalhes .
Os problemas realmente importantes no desenvolvimento de software são problemas de design no nível do recurso e do sistema. Tudo o resto é secundário.

Portanto, nem comece esses debates. Concentre sua energia em dividir seu projeto em partes independentes. Isso gera um software mais robusto e flexível. E se você conseguir identificar decisões técnicas que apresentam desvantagens claras (algo que você só pode fazer quando tiver um software em execução), poderá tomar uma decisão diferente sem afetar o restante do sistema.

A padronização é uma abordagem

Sua equipe deve chegar a um consenso sobre o que adotará como padrão para o desenvolvimento e depois cumpri-la por um período de tempo razoável (decidido pela equipe). Se o padrão falhar, um novo será adotado provavelmente a partir de um novo lote de possíveis estruturas de solução.

"Ei, esses PCs foram inúteis no final, vamos tentar Macs!"

ou

"Eu te disse! A primavera é muito melhor que a EJB."

E assim por diante.

Ter um padrão significa que o código se torna mais fácil de trabalhar com uma equipe, o que, por sua vez, leva a um ambiente mais produtivo.

Atualmente, estou testando a abordagem, o código chamado "conclave papal" e é bastante promissor. É baseado em uma história, que durante uma das eleições papais houve um "impasse" e os cardeais simplesmente não puderam fazer uma escolha. A entidade que hospeda uma eleição (provavelmente uma das principais da cidade) primeiro trancou cardeais em um prédio, depois reduziu drasticamente o suprimento de alimentos e depois removeu o teto do prédio para tornar o debate ainda menos confortável. Como esperado, os cardeais fizeram a escolha após a remoção do telhado, encerrando um impasse de três anos.

Portanto, minha abordagem é que, quando as pessoas discordam de algumas coisas, elas são forçadas a discutir isso até que tenham uma escolha. Não provoco nenhum outro desconforto, nem mesmo uma restrição de tempo e, é claro, não faço nada com o teto :). Tudo o que faço é trazer a questão constantemente todos os dias. Se alguém diz "Não podemos tomar uma decisão", respondo com "Bem ... você precisa". Até agora, não conheci uma pessoa tão irremediavelmente viciada em alguns pequenos detalhes tecnológicos. Depois de várias reuniões, eles tendem a procurar um compromisso como os cardeais.

Concordo que esta é mais uma discussão de sustentação do que cortá-la. No entanto, as discussões não são infinitas e, como vantagem, algumas pessoas após esse "conclave" tendem a evitar pequenos debates tecnológicos, o que torna as coisas mais confortáveis ​​para toda a equipe.

Li em algum lugar que você não deve viajar mais de seis juntos se precisar concordar sobre onde deve ir e o que fazer, pois não alcançará consenso.

Este é um excelente exemplo de por que precisa haver uma pessoa com poderes decisivos. Nesse exemplo em particular, essa pessoa precisa tomar uma decisão e dizer "precisa ser assim", e as outras precisam respeitar essa decisão para que um trabalho real possa ser realizado.

Se a decisão for ruim posteriormente, você pelo menos sabe ao certo e pode aprender com ela.

Uma abordagem é por votação e funciona bem em equipes de menor porte.

Enquanto dois indivíduos podem estar tendo a conversa; mova-o para um fórum aberto ... debate por N tempo e, em seguida, faça uma votação levantando as mãos.

Simples, mas democrático e permite avançar.

Uma pergunta semelhante poderia ser:

Como parar as guerras religiosas / de chamas nos fóruns?

Acho que @ S.Lott está certo em seu comentário, se o único ponto é "discussão", "ir embora" ou ignorá-lo, pode ser a única resposta. Eu usei essa técnica no passado.

Se o objetivo é encontrar uma solução, avalie os prós / contras do domínio em questão, defina um limite de tempo e (acene para a Nike) basta fazê-lo.

Idealmente - IMO - o líder técnico ou a figura da autoridade diz: "ok, obrigado por seus pontos, nós somos ..." som de dados "... seguindo a idéia do tipo" e assim por diante ". e todo mundo vai e se senta.

Geekery sobre pontos minúsculos desperdiçou uma quantidade enorme de meu tempo de reunião, e eu não quero mais ouvir isso. : - /

Acho que, quando você focaliza a conversa não na alternativa certa, mas em quais são as consequências de escolher a errada, você tende a não ficar muito atolado. Se chegarmos a um consenso de que, mesmo que A esteja certo, B não nos mate, ninguém fica com muita raiva se acabarmos com B. Se não podemos chegar a esse consenso, é geralmente porque há um problema real que temos que resolver.

O principal é que precisamos ser maduros e entender que nem sempre podemos concordar um com o outro; o grande e maduro é aprender um com o outro, por que temos as posições que temos e, talvez, relacionadas à minha própria. pergunta, aprenda quais experiências e o motivo. Então podemos formar nossa própria opinião informada e ser condenado ou não.

Pessoalmente, não preciso ou espero que outras pessoas concordem comigo, seria bom, mas não importante. E até este ponto, cito Voltaire.

"Posso discordar do que você diz, mas vou defender até a morte, o seu direito de dizê-lo." -Voltaire, filósofo do século V

Toda reunião deve ter um presidente responsável pela agenda e manter a ordem (e levar minutos, embora possam delegar essa tarefa a outra pessoa se a reunião for grande demais para que ela possa lidar com tudo). A tarefa do presidente é dizer a alguém para parar de discutir ("pessoal, por favor, coloque-o offline" na fala corporativa).

Se não vale a pena nomear um presidente, não vale a pena ter uma reunião. Você também pode conversar no refrigerador de água.

Pode-se dizer "mais fácil falar do que fazer, quant_dev". Bem ... um presidente natural é um líder de equipe, gerente de projeto, gerente de equipe. Eles devem ter a autoridade necessária. Reuniões em que ninguém sabe quem realmente lidera as reuniões são sinais de caos na organização, um problema mais profundo que precisa ser resolvido.

Resolva os problemas gerais primeiro: precisamos de um servidor web, servidor de aplicativos, banco de dados etc.

Para os debates sobre qual banco de dados ou servidor usar, estacione esses itens para outra reunião.

Durante as reuniões subseqüentes, permita a discussão para "listar" as ofertas em potencial, como MySQl, MS SQL Server, Postgres etc.

Permita que os membros da equipe expressem suas opiniões, mas solicite que os apoiem com fatos. O produto X é péssimo! Não funciona, o produto Y não aumenta! É muito vago. Etc.

Depois que todos os detalhes estiverem prontos, você precisará colocá-lo em votação ou, como líder da equipe, tomar uma decisão executiva.

Se você precisar liberar um vencedor claro ou confirmar o suporte / a falta de um recurso / conceito, sinta-se à vontade para levar um tempo para fazer um POC (Proof Of Concept), mas perceba que isso levará tempo e há uma tendência para os desenvolvedores deseja executar com o que eles começaram ... Certifique-se de verificar todos os obstáculos / preocupações técnicas antes de ir com o POC.

Como líder de equipe, sinto que depende se a decisão deve ser tomada aqui e agora.

Se for necessário, procuro aquele com o menor custo de reversão. É sempre importante, como equipe de desenvolvimento, saber que sua decisão pode estar errada, você pode ter que fazer uma escolha ousada e mudar de idéia. O custo de fazer isso sempre deve ser minimizado.

Se puder esperar, considere o fato de que nenhuma das partes que discordam possui todos os fatos. Peça que eles se afastem e pesquisem mais e faça sua própria pesquisa.

Sempre fazemos isso no calor da batalha? Não, principalmente quando sou um dos que têm uma opinião acalorada (não pretendo ser perfeito). Mas acho que esse é o caminho para abordar essas situações. O time-boxe nunca parece levar todos a concordar, apenas leva a um argumento inconcluso.

A menos que você tenha um membro difícil da equipe, normalmente você não terá um debate sem fim, a menos que não haja nenhuma vantagem clara em qualquer uma dessas abordagens. A seguir, são apresentadas algumas boas abordagens para o empate:

• Deixe a pessoa que realmente tem que implementá-lo decidir.
• Para problemas de interface do usuário, deixe a pessoa mais ciente dos requisitos do cliente decidir.
• Deixe a pessoa com mais experiência sobre o assunto ou parte da base de código decidir.
• Deixe a pessoa com as mais rígidas restrições de horário ou limitações de mão de obra e recursos.
• Deixe a pessoa decidir quem tem objeções mais concretas do que teóricas.
• Encontre um compromisso entre as abordagens.
• Reúna mais informações e decida na próxima reunião, dando mais peso às pessoas que obviamente passaram algum tempo pesquisando desde a última reunião.

Quanto a como anunciar uma decisão, você apenas diz: "Ok, vamos continuar com isso por causa disso ". Se as pessoas sentirem que você lhes deu uma audiência justa e você não for insolente como líder, elas concordarão com sua decisão. Para os particularmente teimosos, você pode prometer reavaliar depois de uma certa quantidade de implementação, mas a maioria das pessoas a abandonará nesse ponto.

Um bom facilitador de reuniões pode facilitar esse tipo de discussão sem deixá-lo sair do controle.