Команда, в которой я сейчас работаю, испытывает довольно высокую текучесть кадров, члены которой обычно переходят на разные проекты в рамках одной компании. В настоящее время наша «тренировка» для новых участников состоит в том, чтобы соединить их с основным контактом (обычно самым последним, кто завершит их обучение), который предоставит им практический опыт и попросит более старших разработчиков, если новый новичок спросит что-то у наставника. не знает Это дает возможность новому наемнику быстро принять участие и бросает вызов наставнику, чтобы улучшить его / ее понимание системы.
Однако, как вы можете себе представить, этот стиль обучения занимает очень много времени и не обеспечивает очень хорошую передачу знаний (распространяются неправильные представления, расширяются пробелы).
Мне было поручено создавать документацию и учебные материалы для наших будущих новых сотрудников. Я уже время от времени делаю технические записи, но они предназначены для конечного пользователя и очень специфичны, содержат множество скриншотов и занимают много времени.
Создание новой документации для новых сотрудников считается низким приоритетом, и сейчас у меня есть ~ 40 часов, чтобы поработать над этим. Документирование системы текущим способом, которым я пишу техническую документацию, едва бы поцарапало поверхность за 40 часов. Особенно учитывая, что я должен документировать не только о кодовой базе, но и о развертывании и поддержке.
Как я могу быстро написать документацию, чтобы как можно быстрее получать новых сотрудников, не тратя значительное время на написание документации?
Дополнительная информация:
В настоящее время у нас есть и вики, и некоторая учебная документация, однако обе они довольно редки.
источник
Ответы:
Хороший вопрос. Обучение программиста на рабочем месте очень редко воспринимается всерьез, и о нем часто не говорят.
Некоторые идеи, которые я видел, хорошо работают:
Как отмечает Дэн МакГрат, хорошей идеей является поощрение новых сотрудников для улучшения вики и для них.
источник
Во-первых, я бы посоветовал вам не делать свой новый учебный документ по найму настолько подробным, как то, что вы написали бы для клиента. Он должен быть достаточно техническим, чтобы новый разработчик мог его использовать в качестве руководства, но не настолько подробным, чтобы описывать каждую мелочь. Они смогут поговорить с командой, если у них возникнут вопросы.
Какие 10 главных вещей нужно знать новому найму, чтобы они были полезны для вашей команды? Сконцентрируйся на этих вещах. Сделайте их своим хит-листом, чтобы у нового разработчика было достаточно работы и информации, чтобы поддерживать их работу. Если в списке слишком много вещей, спросите себя, будут ли они делать это в первые две или три недели. Если они не будут делать что-то в это время, то, возможно, это не должно быть в бортовом руководстве.
Для каждого раздела вашего руководства, убедитесь, что в верхней части выделено нужное лицо. Таким образом, если у нового найма есть какие-либо вопросы, они знают, к кому обратиться за помощью. Кроме того, убедитесь, что один член команды не является участником слишком большого количества разделов. Вы не хотите занимать время у одного человека новыми вопросами найма, если они не являются наставником.
Не тратьте всю свою неделю на этот документ. Оставьте себе некоторое время, чтобы настроить его после того, как вы позволите хотя бы одному новому набору пройти его. Посмотрите, что работает хорошо, что нет, и исправьте.
источник
Недавно я начал работу над аналогичным документом на своем рабочем месте с аналогичными временными рамками. Я сочувствую тому, что легко хотеть написать это на очень детальном уровне, как я это делал поначалу тоже, но это на самом деле может привести к обратным результатам.
Если кто-то новый начинает свою роль, он, вероятно, завален информацией за первые несколько недель. Я считаю, что их первоначальное обучение должно стать умопомрачительным занятием для разработчика, который работает в компании в течение нескольких лет, намного усложнит то, что кому-то нужно знать в течение первых нескольких месяцев или даже года на этой должности. Поддерживайте его на высоком уровне, попробуйте использовать стандартные жаргоны и понятия, а затем расширять их с учетом специфики процессов компании.
Для меня первая итерация этого документа - это просто набросок SDLC, который мы используем на моем рабочем месте, со списком ролей, связанных с каждым шагом, несколькими примерами людей, которые выполняют эти роли, и конкретными контрольными списками, связанными с каждый шаг жизненного цикла, а также. Лично я считаю, что контрольные списки необходимы в учебных целях, а также во всем, что я делаю на работе. Например:
Надеемся, что ваш новый сотрудник должен быть знаком с большинством концепций и теперь иметь пошаговое руководство о том, как процессы применяются в компании. Я также делаю небольшую демонстрацию процесса от начала до конца, используя реальные документы из проектов, которые, по моему мнению, были хорошо выполнены.
Как уже упоминалось, это также живой документ, поэтому разделы могут быть расширены, так как определено, что им нужно больше информации. Вся команда должна быть вовлечена в поддержание его в актуальном состоянии. Это может быть вики, документ OneNote, что угодно, но что-то, что все люди могут редактировать и просматривать, а затем привлекать других людей к его совершенствованию, когда у них есть свободное время здесь и там. Таким образом, один человек не делает этого и не распространяет свой собственный процесс на всех новых сотрудников.
После того, как они рассмотрели процесс, попросите их выполнить небольшую функцию / исправление ошибки в не критически важном проекте и попросите их задать вопросы, которые не рассматриваются в документе. Запишите, что это за вопросы, потому что они, вероятно, должны быть первыми элементами, которые вы добавите в документ при следующей работе над ним.
источник
Вы не можете комбинировать делать что-то подобное, не тратя время. По крайней мере, если вы хотите сделать это самостоятельно. Вы должны спросить себя, действительно ли необходимо документировать это так точно, как вы пытаетесь?
Единственная альтернатива - позволить новым сотрудникам выполнять основную работу. Позвольте им написать некоторые части. Время, потраченное на их исправление (в форме обратной связи), будет меньше, чем в текущих ситуациях. Предоставьте несколько хороших шаблонов, и вам не придется беспокоиться о макете.
источник
Я полагаю, вы уже знаете, что они поставили перед вами задачу невыполнимой. Как писатель, вы, вероятно, уже знакомы с цитатой Марка Твена:
Учитывая практически отсутствие ресурсов, вероятно, лучшее, что вы можете сделать, - это получить картотеку и попросить всех сделать копию того, что у них уже есть, и поместить ее в картотеку. Таким образом, вы, по крайней мере, можете сказать новому сотруднику: «Если вы хотите что-то узнать о системе, то вам стоит начать с картотеки».
Хорошее письмо занимает время, период. Далее это необходимо адаптировать к целевой аудитории. То, что работает для конечных пользователей, не будет тем, что нужно программисту.
Не говоря уже о том, что хорошее обучение не ограничивается письменными материалами, оно будет включать полный набор образовательных ресурсов, включая онлайн, аудиторию, мультимедиа и т. Д.
Как говорится: «Если вы думаете, что образование стоит дорого, попробуйте стоимость невежества».
Кроме того, само собой разумеется, что рассмотрение документации как факта, который необходимо сделать после факта, а не превращение его в неотъемлемую часть процесса с первого дня, свидетельствует о системной организационной проблеме.
источник