Como faço para que as pessoas parem com o bikeshedding (concentrando-se em trivialidades)?

Acho que o problema é a tarefa: "Recebi a tarefa de ensinar a outras equipes uma nova base de código".

Você recebeu o trabalho errado ou talvez tenha interpretado mal o trabalho que recebeu.

Ao apresentar no nível do código, você convida a pensar no nível de código.

Comece no nível do sistema e apresente o design e as opções de design que foram feitas. Não permita discussões extensas: você não está revendo. Permitir perguntas: você quer que eles entendam o sistema. Se as pessoas "teriam feito de forma diferente", tudo bem. Talvez concordar. Ou não. Mas siga em frente. É assim que é agora.

Quando você chegar ao nível do código, você já os terá preparado com a terminologia do sistema. Os nomes (suponho) farão sentido. O mesmo que acima: sem discussão extensa, perguntas para entender. Siga em frente.

Agora defina alguns problemas de classe para trabalhar. Como podemos melhorar o X? Escolha algo não trivial que "siga o fluxo" do design do sistema e trabalhe com o que você mudaria. Eles deveriam estar recebendo a lógica do sistema agora. Escolha outro aprimoramento que poderia quebrar o sistema se feito de errado e mostre como isso pode ser feito corretamente. Esse deve ser um momento Ah Ha para eles. Alguns podem até bater em você!

É um show difícil, especialmente depois do falso começo que você teve. Parece que você já investiu muito tempo e esforço, e talvez haja um pouco de mim em relação a eles. 'Confessar e começar de novo. Nós assumimos que eles são pessoas inteligentes. Dê a eles o desafio de pensar no nível mais alto. E divida os grupos que já existem, selecionando seções diferentes de equipes para as novas sessões.

"Estacione-os". No início da aula, explique o que você deve discutir e explique claramente o que é considerado Off-Topic. Se lhe for feita uma pergunta que seja claramente OT, diga e siga em frente. Se eles retornarem, escreva a pergunta em um quadro branco (isso é crítico) para discussão posterior e siga em frente. No final da lição, quando eles estiverem no seu tempo, não no seu, observem a rapidez com que essas questões são resolvidas.

Defina expectativas corretamente e seja honesto, aberto e direto.

Certifique-se de que seus objetivos sejam abertos e transparentes.

Inicie as discussões com a visualização de alto nível promovida por andy256 (+1), mas também certifique-se de incluir seus objetivos, por exemplo,

"... ao analisarmos esse problema, vamos nos certificar de que não nos concentramos em x, yez. Também nos certificamos de não observar os detalhes da implementação, como a, b, c ou detalhes triviais como j, k, l Eu sei que há muitos detalhes no código e detalhes de coisas que poderiam ser endereçadas, melhoradas ou padronizadas, mas vamos tentar ver o que realmente está conseguindo em um primeiro nível mais alto "

So how do you educate other programmers enough that they stop fixating on trivialities and can meaningfully contribute to the design?

Primeiro, não pense em suas preocupações como "trivialidades" ou "bikeshedding". Essas são palavras de julgamento e são insultantes. Suas preocupações são válidas. Eles simplesmente não são importantes no momento.

A chave para qualquer boa reunião é que todos saibam:

• por que você está tendo uma reunião e
• o que você espera tirar dela
• quanto tempo deve durar

Indique essas coisas na frente, explicitamente e explique os objetivos.

Por exemplo, você pode dizer: "Esta reunião é para eu familiarizá-lo com o pacote Foo e como ele é usado em nosso módulo de relatórios. Meu objetivo é que você entenda o suficiente sobre Foo para trabalhar nos Relatórios de Barras. projeto chegando na próxima semana. Eu gostaria que terminássemos nos próximos 90 minutos. "

Então, quando um tópico aparecer, pode ser assim:

New person: "Why is FooWidget implemented as a facade pattern?"

You: "Well, I think it's because (short explanation of design decision)" or "I don't know."

Se a resposta for suficiente, ótimo. Se não, e continua:

NP: "Don't you think it would be better done as a singleton?"

You: "I hadn't really thought about it, but I'd like to keep moving ahead with explaining how FooWidget works."

NP: "But if it's done as a singleton then we can--"

You: "I'm sorry to interrupt, but I need to keep this focused on how FooWidget works. This meeting is only scheduled until 11:00 and we have a lot to get through. The design discussion will have to wait for another time."

Depois de passar por isso uma ou duas vezes, você pode resumi-lo para "Está fora do escopo desta reunião".

Note que você não diz "Isso é idiota para se preocupar" ou "Não importa" ou "Cale-se" ou "Você é novo demais para ter informações". Você está simplesmente concentrando a reunião no que precisa ser feito e no tempo envolvido.

Em certas organizações, você nunca conseguirá isso. Muitas organizações valorizam as disputas políticas e a escalada de escadas muito mais do que a capacidade intelectual, diligência e lealdade. E por que eles não. A escalada de escada coloca as pessoas em posições de poder, permite que elas melhorem suas vidas pessoais com renda mais discricionária e nunca se tornem obsoletas.

O único conselho que eu sugiro é que você deixe claro, no contexto de sua organização, se possível, que esses participantes destino pessoal dependem de sua compreensão, contribuição e esforço para o problema real que você está tentando resolver. Se essa é a arquitetura corporativa, expressa nessa base de código-de-rosa e todas as falhas, é isso. Deixe claro para eles que eles devem fornecer informações substanciais significativas sobre que . Não alguma outra aleatoriedade, que por acaso seja uma provocação de alguém mais velho ou outra pessoa, e ganhará bons pontos de brownie ao concordar com alguém do alto escalão.

Isso geralmente é difícil de fazer, já que o idoso geralmente não entende a tecnologia, não está interessado e, infelizmente, controla as matérias-primas: tempo do funcionário; contratar & fogo, política de sala de conferências, promoções, etc., etc. sério, et cetera ao enésimo.

O que você chama de bikeshedding, eu chamaria de converter o fluxo de pensamentos de alguém em nosso próprio. Ao discutir nomes, padrões, eles conseguem entender o código em seus próprios termos e não há como evitá-lo, é necessário.

Além disso, não há necessidade de um detalhamento detalhado de toda uma base de código, porque os detalhes serão esquecidos muito antes de eles começarem a trabalhar nele.

Com base nessas duas ideias, sugiro dividir a base de código em unidades e os alunos em grupos de duas pessoas. Para cada unidade de código, cada grupo terá, digamos, 25 minutos (depende do LOC , é claro), para poder para fazer um 5-10 minutos passo a passo do código para os outros. Três minutos de perguntas e repita com a próxima unidade. Explique é a palavra chave; eles têm que garantir que os outros tenham entendido tudo isso.

Você só estaria lá para impor tempo, sem problemas e controlando a unidade. Eles serão atores de seu aprendizado e estarão mais focados em explicar para os outros do que o bikeshedding.

Você pode requerer um esquema desenhado a mão de alto nível a partir deles da unidade de código, que será copiado e mantido nos documentos compartilhados pela equipe, para que eles tenham algo tangível a se referir no futuro. Isso é bom para ancorar as memórias também.

Desculpe se você já tentou isso ...

Já tentou fazer pré-aulas que as pessoas analisam individualmente?

Faça pequenos vídeos ou apresentações que expliquem o conteúdo, como o código funciona, ou basicamente tudo o que você quer ensinar em um formato onde eles precisam olhar por conta própria e aprender as informações que você está tentando ensinar. .

Depois, você usa as sessões com base em equipe para discutir problemas relacionados ao conteúdo. Você precisa identificar claramente que as sessões da equipe são para discutir e solucionar problemas relacionados apenas ao conteúdo.

Se você fornecer as lições para as pessoas individualmente, poderá evitar essa questão social em que uma única questão pode se tornar a voz do grupo como um coletivo e desviar o objetivo real das lições.

Tente ensinar primeiro o design da base de código, guie-o pela arquitetura, ANTES de começar a ver exemplos específicos. Dessa forma, eles podem ver como os exemplos de código que você vê se encaixam na imagem maior. Pense em como o seu programa de treinamento está estruturado. E inclua a motivação empresarial por trás do design.

Passei vários anos treinando outros desenvolvedores, e nunca entrei no código antes de mostrar como o sistema se encaixava. Então, quando consegui fazer exercícios de código no framework, as perguntas foram estruturadas e tratadas no tópico.