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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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