Лучший способ обучать новых сотрудников [закрыто]

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

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

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

Создание новой документации для новых сотрудников считается низким приоритетом, и сейчас у меня есть ~ 40 часов, чтобы поработать над этим. Документирование системы текущим способом, которым я пишу техническую документацию, едва бы поцарапало поверхность за 40 часов. Особенно учитывая, что я должен документировать не только о кодовой базе, но и о развертывании и поддержке.

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

Дополнительная информация:
В настоящее время у нас есть и вики, и некоторая учебная документация, однако обе они довольно редки.

Хороший вопрос. Обучение программиста на рабочем месте очень редко воспринимается всерьез, и о нем часто не говорят.

Некоторые идеи, которые я видел, хорошо работают:

• В вашей вики есть новый пандус (тот, который вы пишете). В этом документе опишите задачи, которые новый сотрудник будет выполнять в течение первых 1-2 недель. Там, где я работаю, есть масса информации, которую можно узнать с самого начала, от внутреннего программного обеспечения / инструментов до процессов, до местоположений определенных типов информации. edit> у нас есть такие инструкции, как «установить x, y, z по порядку» со снимками экрана для настройки и т. д. Поэтому при настройке системы или фермы (ВМ) с помощью Win Server, SQL Server, SharePoint, BizTalk наше программное обеспечение не так просто, как оно звуки. Это относится и к другим версиям тех приложений, которые мы поддерживаем.
• Проблемы с практикой. Там, где я, у нас есть продукт, который предоставляет API-интерфейс большого размера. Поэтому нам всегда полезно просматривать собственную документацию по продуктам для написания (заранее определенных) расширений, как это делают наши клиенты. Поэтому, если у вас есть математическая библиотека как часть API вашего продукта, попробуйте на практике проблему «напишите калькулятор с использованием нашего API» или что-то в этом роде.
• Наставники хороши. Держать их. Мы делаем это и здесь, и это не только хороший способ встретить людей / завести друзей, но и они являются бесценным источником обучения. Я не рекомендую, чтобы это был самый последний человек, чтобы закончить обучение, потому что у них нет истории корпоративных знаний, как кто-то другой. Пусть все делают это по очереди.
• Мы делаем (примерно) еженедельные презентации / технические переговоры. Попросите новых сотрудников выбрать что-то из вашего продукта (или назначить его) и провести презентацию после 3-й недели. Убедитесь, что они знают, что есть место для их ошибок, и команда может исправить их, если они что-то напортачат в презентации.
• Пусть новые сотрудники будут работать над документацией, когда они начнут. Это заставляет их читать это.

Как отмечает Дэн МакГрат, хорошей идеей является поощрение новых сотрудников для улучшения вики и для них.

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

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

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

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

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

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

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

• Руководитель проекта (Джо) назначает вам задачу в Jira.
• Установите примерное время выполнения задачи на основе формулы x.
• Установите билет как «в процессе», когда вы начнете работать над ним.
• Создайте ветку из git, нажмите на ссылку, чтобы просмотреть 30-секундное видео об этом прогрессе.
• Напишите модульные тесты, основанные на ограничениях в проектной документации, см. Стр. Y для соглашений по именованию модульного тестирования
• Установить тикет для проверки и отправить код для проверки системы .. 'и т. Д.

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

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

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

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

Единственная альтернатива - позволить новым сотрудникам выполнять основную работу. Позвольте им написать некоторые части. Время, потраченное на их исправление (в форме обратной связи), будет меньше, чем в текущих ситуациях. Предоставьте несколько хороших шаблонов, и вам не придется беспокоиться о макете.

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

Если бы у меня было больше времени, я бы написал меньше.

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

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

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

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

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