Как заставить людей перестать ездить на велосипеде (сосредоточившись на мелочах)?

139

Мне поручили обучать другие команды новой кодовой базе, но я продолжаю сталкиваться с проблемой. Когда бы я ни пошел, чтобы на самом деле пройтись по коду с людьми, мы не продвинулись слишком далеко, пока все упражнение не перешло в велосипедную гонку (члены организации, которые несоразмерно важны для тривиальных вопросов). Так как они не знают кодовую базу, но думают, что должны помочь улучшить ее, они сосредотачиваются на вещах, которые они могут понять:

Why is that named that? (2 минуты, чтобы объяснить, почему он назван так, более 10 минут обсуждают новое имя)

Why is that an abstract base class rather than an interface? (2 минуты для объяснения, 10+ минут для обсуждения относительных достоинств этого решения)

...и так далее. Не поймите меня неправильно - хорошие имена и хороший, согласованный дизайн важны, но мы никогда не обсуждаем, что на самом деле делает код или как система разработана каким-либо осмысленным образом. Я провел несколько совещаний судейства, чтобы вывести людей из этих касательных, но они ушли - отвлекшись на то, каким будет код, который будет / должен быть, когда их тривиальность будет исправлена, и они упустят общую картину.

Поэтому мы попробуем еще раз позже (или с другой частью кодовой базы), и поскольку у людей не было достаточно знаний, чтобы преодолеть эффект байкшединга, это повторяется.

Я пробовал меньшие группы, большие группы, код, доски, визуальные диаграммы, гигантские стены текста, позволяя им просто приводить доводы до смерти, немедленно сокращая аргументы ... некоторые помогают больше, чем другие, но ничего не работает . Черт, я даже пытался заставить других людей из моей команды объяснить это, потому что я подумал, что, может быть, я просто плохо объясняю вещи.

Так как же вы достаточно обучаете других программистов, чтобы они перестали зацикливаться на мелочах и могли внести существенный вклад в дизайн?

Telastyn
источник
44
Мне неприятно это говорить, но мне кажется, что это явление иллюстрирует больше проблем с кодовой базой, чем с новичками.
Николь
30
Вы пробовали отложить вопросы до конца? «Подожди еще несколько минут, и я смогу объяснить в конце», а затем просто пролистываю остальную часть контента. Возможно, на некоторые из этих вопросов ответят сами
jozefg
21
@NickC, я считаю, что хороший код или нет, не имеет ничего общего с тем, как вы его понимаете, как вам удается получить ясную общую картину. Тратить время на мелкие детали с самого начала, не тратя время на то, чтобы получить начальную общую картину, плохо и никогда не поможет исправить этот потенциально плохой код.
Шиван Дракон
11
Какова цель обучения кого-то основам кода? Может быть, вы можете сообщить эту цель более четко и почему это важно, чтобы они могли видеть, что обсуждение нового имени объекта отвлекает от этой цели и должно быть зарезервировано для другой встречи.
LarsH
56
В этих ответах есть хороший совет. Я бы вкратце добавил: подумайте об использовании «процесса» в качестве своего союзника. Когда кто-то говорит, что «этот дизайн неоптимальный», правильный ответ «отлично», я рад, что вы заметили это. После этой встречи, пожалуйста, внесите ошибку в базу данных отслеживания с подробным описанием проблемы и предложенным вами решением. Команда по сортировке рассмотрит ваше предложение, приоритизирует его по отношению к остальным рабочим элементам и назначит его соответствующему разработчику, чтобы исправить его, как только все элементы с более высоким приоритетом будут исправлены. Двигаясь дальше ... "
Эрик Липперт

Ответы:

159

Я думаю, что проблема заключается в задаче: «Мне было поручено обучить другие команды новой кодовой базе».

Вам дали неправильную работу или, возможно, неправильно истолковали работу, которую вам дали.

Представляя на уровне кода, вы предлагаете мышление на уровне кода.

Начните с системного уровня и представьте дизайн и варианты дизайна, которые были сделаны. Не допускайте расширенного обсуждения: вы не просматриваете его. Разрешите вопросы: вы хотите, чтобы они поняли систему. Если бы люди «сделали бы это по-другому», хорошо. Может быть согласен. Или нет. Но двигаться дальше. Это так, как сейчас.

Когда вы дойдете до уровня кода, вы уже получите их с системной терминологией. Имена (я предполагаю) будут иметь смысл. То же, что и выше: нет расширенного обсуждения, вопросы для понимания. Двигаться дальше.

Теперь установите некоторые классовые задачи для проработки. Как мы можем сделать улучшение X? Выберите что-то нетривиальное, что «идет в ногу» с дизайном системы, и проработайте то, что вы бы изменили. Они должны получить обоснование системы сейчас. Выберите другое усовершенствование, которое может сломать систему, если сделано неправильно, и покажите, как это можно сделать правильно. Это должно быть для них моментом Ах Ха . Некоторые могут даже побить тебя этим!

Это тяжелый концерт, особенно после фальстарта. Похоже, вы уже вложили много времени и усилий, и, может быть, есть чувство «я против них». «Признайся, и начни снова. Мы предполагаем, что они умные люди. Дайте им задачу мышления на более высоком уровне. И разбейте группы, которые уже существуют, выбрав различные сечения команд для новых сессий.

andy256
источник
3
Сначала я прошел инструктаж по высокоуровневому дизайну, а также провел обучение некоторым новым / незнакомым технологиям (контейнеры IoC, динамика), чтобы помочь подготовиться. Это обучение прошло довольно хорошо. Это хороший момент для поднятия.
Теластин
+1, чтобы не пытаться бороться с людьми с «экстрасенсорными взломами» типа «Я отвечу на ваши не по теме вопросы в и в ваше время!» а точнее меняя точку зрения
Буксы
3
Фантастический ответ. Мне особенно нравится предложение сделать акцент на том, «что он делает», а не на том, как называются его внутренние компоненты.
Даниэль Холлинрейк
66

«Припаркуй их». В начале урока объясните, что вы хотите обсудить, и четко объясните, что считается не по теме. Если вам задают вопрос, который явно является ОТ, скажите об этом и двигайтесь дальше. Если они вернутся к нему, напишите вопрос на доске (это важно) для дальнейшего обсуждения и продолжайте. В конце урока, когда они проводят свободное время, а не ваше, посмотрите, как быстро эти вопросы будут решены.

mattnz
источник
8
+1 Так люди чувствуют, что их не игнорируют.
andy256
Я согласен с этим. Если проблема заключается в том, чтобы обсуждать несущественные вещи слишком долго, тогда не обсуждайте несущественные вещи ...
Крис
7
Возможно, вместо того, чтобы отнимать у всех время, написав вопросы OT на доске, попросите спрашивающего принять это к сведению (на указанной вики-странице, вопрос JIRA, где бы то ни было).
LarsH
14
Я думаю, что физическое действие, потраченное на написание своего вопроса на доске, ясно показывает спрашивающему, что вы откладываете его вопрос (а не игнорируете его), и показывает остальной аудитории, кто задает все вопросы и таким образом откладывает прогресс.
Дж.Б. Уилкинсон
1
@LarsH - точно. Надев на белую доску, чтобы все видели, разговор прекращается. Если это произойдет снова, инструктор просто укажет на вопрос и скажет: «Я обещаю, что мы вернемся к нему».
Mattnz
21

Правильно устанавливайте ожидания и будьте честными, открытыми и искренними.

Убедитесь, что ваши цели открыты и прозрачны.

Начните обсуждения с точки зрения высокого уровня, продвигаемой andy256 (+1), но также убедитесь, что вы включили свои цели, например

«... когда мы смотрим на эту проблему, давайте удостоверимся, что мы не фокусируемся на x, y и z. Давайте также удостоверимся, что мы не рассматриваем детали реализации, такие как a, b, c или тривиальные детали такие как j, k, l. Я знаю, что в коде должно быть много деталей и деталей, которые могут быть рассмотрены, улучшены или сделаны более стандартными, но давайте сначала попробуем взглянуть на то, что на самом деле достигается на более высоком уровне "

Майкл Даррант
источник
+1 за первые 2 предложения. Однако говорить людям не думать о чем-то - это не хороший способ заставить их не думать об этом. «Что бы вы ни делали, не думайте о розовых единорогах». Прежде чем я упомянул розовые единороги, вы думали о них? Возможно нет. Если бы вместо этого я сказал: «Давайте не будем отвлекаться на воображаемых животных, а вместо этого сосредоточиться на австралийских животных», тогда вам могут прийти в голову коалы и кенгуру, но, вероятно, не розовые единороги.
Майкл Шоу
Хорошая точка зрения. Однако реальная цель заключается не в том, чтобы не думать людям (и не говорить), а в том, чтобы люди не вступали в затяжные разговоры, которые встречают убийц и моральных лохов. Люди всегда будут думать много недосказанного. Это нормально. В профессиональной деловой обстановке некоторые вещи говорят, а многие нет.
Майкл Даррант
17

Так как же вы достаточно обучаете других программистов, чтобы они перестали зацикливаться на мелочах и могли внести существенный вклад в дизайн?

Во-первых, не думайте об их заботах как о «мелочах» или «велосипедах». Это осуждающие слова, и они оскорбительны. Их опасения действительны. Они просто не важны в данный момент.

Ключ к любой хорошей встрече для всех:

  • почему у вас встреча и
  • что вы надеетесь получить от этого
  • как долго это должно продолжаться

Изложите эти вещи заранее и объясните цели.

Например, вы можете сказать: «Это собрание для меня, чтобы познакомить вас с пакетом Foo и с тем, как он используется в нашем модуле отчетности. Моя цель - дать вам достаточно понимания о Foo, чтобы вы могли работать над проектом Bar Reports» на следующей неделе. Я бы хотел, чтобы мы закончили в следующие 90 минут ".

Затем, когда появляется тема, она может выглядеть так:

Новый человек: «Почему FooWidget реализован как шаблон фасада?»

Вы: «Ну, я думаю, это потому что (краткое объяснение проектного решения)» или «Я не знаю».

Если ответа достаточно, это здорово. Если нет, то и продолжается

Н.П .: «Тебе не кажется, что это было бы лучше сделать как синглтон?»

Вы: «Я действительно не думал об этом, но я хотел бы продолжить объяснение того, как работает FooWidget».

НП: «Но если это сделано как синглтон, тогда мы можем…»

Вы: «Извините, что прерываю, но мне нужно сосредоточиться на том, как работает FooWidget. Эта встреча запланирована только до 11:00, и нам еще многое предстоит пройти. Обсуждение дизайна придется подождать в другой раз «.

После того, как вы пройдете через это один или два раза, вы можете записать его как «Это выходит за рамки этой встречи».

Обратите внимание, что вы не говорите: «Об этом глупо беспокоиться», «Это не имеет значения», «Заткнись» или «Ты слишком новичок, чтобы иметь ввод». Вы просто фокусируете собрание на том, что нужно сделать, и на какое время у вас есть.

Энди Лестер
источник
1
Легко сказать, когда докладчик действительно не заинтересован в обратной связи. Эти встречи проходят быстро. Никого не волнует.
Чукс
4

В определенной организации вы никогда не сможете достичь этого. Многие организации ценят политические споры и подъемы по лестнице больше, чем интеллектуальные способности, усердие и лояльность. И почему бы и нет. Восхождение по лестнице ставит людей на руководящие должности, позволяет им улучшать свою личную жизнь с более свободным доходом и действительно никогда не устареет.

Сравните эту борьбу за власть с реальным решением проблем, абстрактным мышлением и принятием решения по сложным вопросам, которые могут быть ответственны за последствия более позднего периода, и многие сотрудники тяжело тяготеют к тому, чтобы пытаться как можно больше ездить на велосипедах.

Единственный совет, который я предлагаю, заключается в том, чтобы вы четко разъяснили в контексте вашей организации, если это возможно, что личная судьба этих участников зависит от их понимания, вклада и усилий, направленных на решение реальной проблемы, которую вы пытаетесь решить. Если это корпоративная архитектура, выраженная в этой ошибочной кодовой базе и всех ее сбоях, то все. Дайте им понять, что они должны предоставить существенную значимую информацию об этом . Не какая-то другая случайность, это случайность старшего кого-то или другого, которая принесет им хорошие очки брауни, если согласится с кем-то из старших.

Это часто трудно сделать, так как старший человек обычно не понимает, какая технология используется, не заинтересован и, к сожалению, контролирует сырье: время сотрудников; нанять и уволить, политика конференц-зала, продвижение по службе и т. д. и т. д. серьезно, и так далее до н.

Энди Смит
источник
3

То, что вы называете байкшедингом, я бы назвал преобразованием чьего-либо потока мыслей в наши собственные. Обсуждая имена, шаблоны, они понимают код в своих собственных терминах, и нет никакого способа предотвратить это, это необходимо.

Кроме того, нет необходимости проходить очень подробное прохождение всей базы кода, потому что детали будут забыты задолго до того, как они начнут работать над этим.

Основываясь на этих двух идеях, я бы предложил разбить кодовую базу на блоки, а учащихся - на группы из двух человек. Для каждой единицы кода у каждой группы, скажем, 25 минут ( конечно, в зависимости от LOC ), будет возможность пройти 5-10 минут обхода кода для других. Три минуты вопросов и повторите со следующим блоком. Объясните это ключевое слово; они должны убедиться, что другие все поняли.

Вы были бы там только для того, чтобы навязать время, без посторонних тем и управления подразделением не было достаточно понято. Они будут акторами своего обучения и будут более сосредоточены на объяснении другим, чем на велосипедах.

Вам может потребоваться нарисованная вручную схема высокого уровня модуля кода, которая будет скопирована и сохранена в документах, используемых командой, поэтому в будущем у них будет что-то реальное. Это хорошо, чтобы закрепить воспоминания тоже.

Извините, если вы уже попробовали это ...

feydaykyn
источник
1

Вы пробовали делать предварительные уроки, которые люди просматривают индивидуально?

Сделайте короткие видео или презентации, которые объясняют содержание, как работает код или, в основном, все, чему вы хотите научить их, в формате, в котором им нужно посмотреть на него самостоятельно и узнать информацию, которую вы пытаетесь научить их.

Затем вы используете групповые сеансы для обсуждения вопросов, связанных с контентом. Вы должны четко определить, что групповые сессии предназначены для обсуждения и устранения проблем, связанных только с контентом.

Если вы предоставляете уроки людям на индивидуальной основе, вы можете избежать той другой социальной проблемы, когда отдельный вопрос может стать голосом группы как коллектива и отвлечь от реальной цели уроков.

Джо
источник
13
Нееет ......., а не видео ..... "Смерть от Powerpoint" была вытеснена еще худшей судьбой ......, Хотя это будет иметь желаемый эффект остановки вопросов - угрожать им больше видео, которые занимают 10 минут, чтобы объяснить, что можно прочитать за 30 и понять за секунды ....
mattnz
6
+1 mattnz Проблемы коммуникации вряд ли будут улучшены при одностороннем взаимодействии.
Майкл Даррант
1
Я не хочу останавливаться, даже если я в видео! Какой формат видео / кодек отключает паузу? :) :) :)
Каз
1

Попробуйте сначала научить их дизайну кодовой базы, проведите их по архитектуре, ДО того, как вы начнете искать конкретные примеры. Таким образом, они могут увидеть, как примеры кода, на которые вы смотрите, вписываются в общую картину. Подумайте о том, как структурирована ваша тренировочная программа. И включить бизнес-мотивацию за дизайн.

Я провел несколько лет, обучая других разработчиков, и я никогда не углублялся в код, пока не показал им, как система работает вместе. Затем, когда я заставил их выполнять упражнения с кодом в рамках, вопросы были структурированы и были тематическими.

качающийся
источник