Предыстория: я единственный разработчик приложений, работающий в компании по обработке данных. Из-за этого у меня довольно высокий «автобус-фактор», и все это знают. Руководство заинтересовано в том, чтобы я передал некоторые свои навыки и знания другим сотрудникам, и это, очевидно, хорошее деловое решение.
Однако с этим есть две проблемы.
Первая и самая насущная проблема заключается в том, что персонал, которого меня просят обучить, недостаточно квалифицирован. Они оба являются опытными разработчиками баз данных, которые в своей далекой карьере работали с промежуточным программным обеспечением и интерфейсными технологиями. Но мы говорим о 10-20-летней давности. По опыту знаю, что дефицит знаний колоссальный.
Чтобы еще больше усложнить проблемы, я занимаюсь самообучением. Почти все, что я узнал, было связано с опытом работы. Я понятия не имею, как правильно структурировать обучение людей. И, если уж на то пошло, как научиться это делать.
Я высказал эти опасения руководству, которое сказало, что они счастливы, пока я стараюсь изо всех сил. Они хотят, чтобы я проводил обучающие встречи, техническую документацию, учебные материалы и тому подобное. Меня не будут судить о том, насколько эффективны мои методы, пока я их применяю. Это кажется разумным.
Тем не менее, я, очевидно, хотел бы сделать все возможное, чтобы мое время и усилия принесли пользу всем участникам. Где же я могу начать учиться тренироваться, если я не тренер, никогда не тренировался, а мои ученики намного ниже требуемого стандарта?
РЕДАКТИРОВАТЬ: После «горячих вопросов» я вижу здесь три выдающихся ответа. Не знаю, что выбрать. Возможно, мне потребуется несколько недель, чтобы увидеть, какой набор предложений работает лучше всего. Спасибо за все ваши полезные советы.
Как специалист по данным, я был бы крайне раздражен, если бы кто-то попытался превратить меня в разработчика приложений для автобусного фактора. Это просто недальновидно со стороны вашего руководства. Это все равно, что попросить бухгалтера обучиться работе с персоналом. Я упоминаю об этом только потому, что вы, вероятно, столкнетесь с сопротивлением со стороны этих людей. Я также упоминаю об этом, потому что они не неквалифицированные, у них совершенно другая профессия, и если вы относитесь к ним как к неквалифицированным и глупым, это столкнется с вашим обучением, что создаст проблемы.
Я считаю, что первый шаг — это определить, какие вещи им, скорее всего, нужно будет делать, и задокументировать их в Wiki. Маловероятно, что они захотят, чтобы эти люди создавали вещи с нуля, а устраняли неполадки и держали их вместе, пока вы не вернетесь, или они не наймут нового разработчика приложений. Если это правда, то сортируйте то, что вы хотите им сказать, до самых важных вещей. Составьте список наиболее распространенных производственных проблем, а затем создайте шпаргалку для каждой проблемы и узнайте, что нужно сделать, чтобы ее исправить.
Научите их, например, тому, как интерпретировать сообщения об ошибках и как найти информацию в любом журнале, который делает ваша система, и когда перезагрузить сервер, и на что это повлияет, если вы это сделаете. Научите их своим стандартам кодирования. Научите их, где код хранится в системе управления версиями и как его использовать (хотя я думаю, что большая часть работы с базами данных должна выполняться в системе управления версиями, она не во многих местах, поэтому они могут не знать, как ее использовать). Дайте им список. любых применимых имен серверов и паролей и убедитесь, что у них есть соответствующие права для работы на этих серверах.
Найдите местный контакт для места, где есть внештатные разработчики. Убедитесь, что ваша компания знает, что они могут получить поддержку от этих людей, если проблема выходит за рамки навыков специалистов по данным. Вы, люди, работающие с данными, и, в конечном счете, ваше руководство будут счастливее, если будет запасной план. Шансы, что вы сможете превратить этих людей в разработчиков приложений за короткое время, невелики. Лучшее, на что вы можете надеяться, это то, что они могут решить простые проблемы, они знают, где что находится, и могут объяснить бизнес фрилансеру для сложных вещей.
Документируйте все, что можете. Цель состоит в том, чтобы люди могли найти то, что им нужно для работы, когда вас нет рядом.
Я бы также посоветовал вам начать процесс проверки кода с этими людьми. В этом случае важно не столько найти проблемы в коде, сколько познакомить их с вашим последним кодом и его требованиями, вашим стилем кодирования и вашим мыслительным процессом о вашем дизайне. Объясняя им вещи, вы, вероятно, заметите некоторые ошибки, которых не замечали.
Когда у вас есть общая производственная проблема, которую нужно решить после того, как вы рассмотрели наиболее распространенные проблемы на сеансе обучения, пусть они следят за вами и документируют каждый ваш шаг. Убедитесь, что вы даете им понять, что поощряете вопросы. Если они делают документацию, они, скорее всего, напишут ее так, как им будет лучше понять. У разных людей разные стили обучения, и вы, по сути, создаете вики, которая будет более полезна для них, чем для вас. Так что пусть сами решают, как это организовать.
Если их обязанности удерживают их от слежки за вами, то сделайте всю вики самостоятельно, работая над проблемами, пока они свежи в вашей памяти.
Для некоторых простых проблем, после того, как они отследили вас и шаги были задокументированы, вы предлагаете им выполнить шаги, пока вы их отслеживаете. Это придаст им больше уверенности в том, что они действительно могут выполнить задание. Это то, что мы сделали, когда недавно преобразовали некоторых разработчиков приложений в специалистов по данным.
Основная философия преподавания должна быть
Существует множество курсов по обучению людей, некоторые онлайн, некоторые из реальных учебных заведений. Не думаю, что у тебя есть на это время.
Итак, давайте начнем с 10-минутного ускоренного курса.
Как и во всем, каждый шаг можно разбить на более подробные шаги. Иметь google/bing для написания технической документации, создания обучающих пакетов и т. д.
Я был в очень похожем положении пару лет назад - самоучка, единственный владелец десятков сервисов, которыми пользуются сотни людей, высокий фактор автобуса. Ваш вопрос точно описывает мою ситуацию в 2014 году.
Многие из этих ответов, кажется, предлагают документацию, но для меня это был не очень хороший план - мои услуги менялись быстро , так быстро, как могли произойти реорганизации или изменения политики. Документация печально известна тем, что готовится медленно и почти сразу же устаревает. Попытка задним числом собрать страницы спецификаций, объясняющие минуты, была для меня неудачной. И единственные люди, читающие это, будут низкоквалифицированными людьми, пришедшими, чтобы помочь мне, которые всегда просто просят меня разъяснить, что я написал в любом случае.
Я решил это несколькими способами.
Не пытайтесь собрать серию мастер-классов — вы заняты. Вы единственный, кто может делать свою работу, поэтому ваше время драгоценно. Пригласите своих новых людей в тень/в пару с вами, пока вы отлаживаете проблему или реализуете второстепенную функцию. Не ждите, пока появится «правильная» ошибка, просто возьмите одного из своих людей и посадите его, пока вы рассказываете, что вы делаете. Это замедлит вас, но не так сильно, как попытки собрать презентации, и это даст им непосредственный опыт. Сопряжение было (для меня) наиболее ценным использованием времени для обучения — оно очень быстро ставит новых людей на ноги по сравнению с вики-документами.
Поймите, что вы не сможете научить их всему. Не так важно, чтобы они понимали построчно каждый созданный вами класс, и более важно, чтобы они понимали географию кода — если они понимают, к каким файлам кода обращаться, чтобы узнать, как что-то работает, это им очень поможет. больше, чем презентация с глубоким погружением в одну конкретную вещь.
Особенно, если ваши люди являются администраторами баз данных по профессии, они, вероятно, будут понимать логику в первую очередь с точки зрения схем, а уже потом функциональность. Попробуйте определить несколько основных путей данных. Большинство приложений берут данные из одного или двух основных источников и изменяют их по запросу пользователя. Если вы можете определить это, объясните своим разработчикам как можно больше этого пути данных. Физически пройтись (в отладчике), что происходит, когда пользователь делает запрос, откуда берутся данные, какие классы отвечают за их загрузку/сохранение, если у вас есть кеши, то покажите, где они живут и какая ожидается их свежесть .
Разделите знания. Не учите их обоих одному и тому же — если это не является какой-то важной частью ваших услуг, то не бойтесь распространять их среди разных людей. При этом используется тот факт, что им потребуется время, чтобы усвоить то, что они изучают, но вы можете учить гораздо быстрее, чем это время усвоения. Это также позволяет им сосредоточиться на меньшем фрагменте изображения, даже если он все еще большой. Вам не нужно разделять их по частям, но полезно разделить проблемное пространство и завоевать его.
Вероятно, у вас есть несколько рефакторингов, которые вы давно хотели сделать — какой-то странный сервис, который действительно сложно отлаживать даже вам. Делай их. И, как всегда, в конце возьмите с собой кого-нибудь из своих людей, чтобы показать им, как работает рефакторинговая система.
Поговорите с ними , не позволяйте им вежливо откланяться, за которыми они следят. Они будут потеряны и сбиты с толку. Выбросьте несколько фраз вроде «Я знаю, что это было слишком сложно, это довольно сложно. Что-то из этого не имело смысла?» и старайтесь предлагать им задавать вопросы как можно чаще — вы не сможете научить их, если не знаете, что они усваивают.
Более того, если они зайдут и зададут вам вопрос, это будет вашим наивысшим приоритетом , даже если вы просто посмотрите на них и скажете: «Я иду на встречу прямо сейчас, это, вероятно, продлится 30 минут, я найти тебя потом».
После того, как вы потратили некоторое время, показывая им веревки, найдите что-нибудь, чтобы передать им. Какое-то несрочное задание, на выполнение которого у вас уйдет неделя или больше. Запланируйте с ними пары, чтобы увидеть, что у них есть и куда они идут с этим - конечно, исправьте их и дайте им подсказки о том, как программировать, пока вы этим занимаетесь (например, «вы могли бы использовать foreach здесь»).
Обзоры кода. Попросите их отправить вам различия (или используйте систему проверки кода) и просмотрите их. Не «оценивайте» обзоры, просто отметьте ошибки или опишите, как их можно улучшить. Если ошибок нет, не мешайте им вносить свой вклад в код (не заставляйте их чувствовать себя исключенными вами), но убедитесь, что у них есть элемент, который они могут отслеживать и немедленно исправлять.
Что еще более важно, поскольку ваша команда явно растет, а вы не упомянули о намерении уйти, сейчас самое время серьезно заняться качеством кода. Дальше будет только хуже, поэтому каждый класс и метод, которые вы (и они) редактируете, с этого момента должны получить автодок-комментарий. Если вы еще этого не сделали, начните разбивать свой код на модули и пытаться разбить методы, которые выполняются для сотен строк, и распутать вложенные классы.
Создайте документацию для начала, пошаговые процедуры того, что вы хотите научить, с пояснениями деталей, где это необходимо.
Это создает базовую справку, на которую вы можете опираться и отвечать на вопросы, и, вероятно, это самый важный аспект. У этого также есть большое преимущество концентрации ваших знаний таким образом, которым вы, возможно, не пытались заниматься раньше. Я определенно нахожу это полезным даже для себя, потому что многие вещи, которые я делаю, довольно сложны, и это избавляет меня от переосмысления множества шагов, если я делал это раньше.
Остальное в основном работает с этим справочным материалом, добавляя к нему или изменяя его по ходу дела. Без него вы будете просто прыгать туда-сюда, не закладывая надлежащей основы. Половина того, чему вы учили, быстро забудется, и вы можете пропустить много шагов, предполагая, что они понимают, тогда как на самом деле они заблудились на 1/2 часа раньше и понятия не имеют, о чем вы.
Похоже, что ваши коллеги обладают общими техническими знаниями, но не имеют навыков в конкретных технологиях, которые вам нужны. Это кажется отличной возможностью для онлайн-курсов, таких как Plurarsight или Egghead.
Правда в том, что большинство из нас не являются великими учителями, потому что быть учителем — это набор навыков, отличный от тех, которым мы обычно обучаемся. Вместо этого зачем создавать планы уроков по основам технологии, когда их уже много?
Вы упомянули, что руководство хочет, чтобы вы разработали какой-то план, так как насчет того, чтобы попросить руководство подписаться на Pluralsight и тратить несколько часов каждую неделю на изучение одного из курсов? Таким образом, у вас есть
Если то, что я читаю, правда — то, что вы единственный оставшийся в живых после знания, — на карту может быть поставлена ваша собственная безопасность работы в том смысле, что вы можете быть заблокированы, если вы это сделаете, и заблокированы, если вы не осуществите передачу знаний. .
Я знаю, что фирма, за которую я шел, осознала ситуацию, когда все яйца были в одной корзине (с точки зрения технических навыков), и решила закрыть проект и сократить бизнес-единицу/подразделение, а не пытаться выкарабкаться из ямы, которую они должны были никогда не попадал в первую очередь. Талантливого ведущего разработчика уволили, когда стало ясно, что используемые технологии устарели, а затраты и выгоды от сохранения возможностей не оправдываются.
Настоящий вопрос заключается в следующем... (независимо от каких-либо проблем с контролем качества - поскольку похоже, что в настоящее время фирма мало что теряет в этом отношении) - может ли компания выманить вас всех - выведя все это за границу, используя больше затрат на персонал малая часть настоящего?
Если "да", то для вас часы уже тикают, может каждый сам за себя - так что я бы больше занимался вашей собственной переподготовкой. Переквалификация в качестве ведущего HR/инструктора по управлению знаниями (если вы можете заставить фирму заплатить за это) может быть хорошей подстраховкой.
Если ответ на этот вопрос был "нет", то я желаю вам удачи, чтобы удержаться у руля, - потому что, если стратегическое руководство вашей фирмы столь же безжалостно, как один из моих бывших работодателей - вам это может понадобиться.
Предполагая, что они хотят учиться, направьте их на вводный курс по технологиям/языкам/и т. д., которые вы используете. Это не должно быть причудливо, просто что-то, чтобы заставить их начать. Деньги компании гораздо лучше потратить на то, чтобы кого-то, кто является профессиональным учителем, профессионально преподавать, чем впихивать вас в эту роль.
Лично я гораздо лучше учусь, делая, чем когда кто-то говорит мне. Программирование — это ремесло и навык, а не заучивание наизусть. Вы должны сделать это и с ними тоже. Не ходите с ними в конференц-зал и не разговаривайте часами. Достаньте компьютеры и займитесь настоящим программированием.
Начните с малого, действительно с малого. «Напишите это маленькое приложение», «настройте этот маленький скрипт». Простые изменения с определенным началом и окончанием, которые должны занять всего несколько часов. Первые несколько раз сядьте с ними и пройдитесь по процессу. Вы даже можете подумать о парном программировании или чем-то подобном. Пусть они следят за вами в течение дня и начинают выполнять работу, но каждый раз, когда вы следите за ними, пусть они делают все больше и больше, пока вы даете советы, а в конце просто наблюдаете.
Ничто, кроме опыта, не даст им опыта. Поэтому лучшее, что вы можете сделать, — это дать им такую возможность, в то же время давая рекомендации и защищая компанию от любых потенциальных ошибок.
Как человек, находящийся в немного похожем положении, я не могу выделить достаточно времени, чтобы документировать как ваши процессы, так и код, и поддерживать их в актуальном состоянии. Даже если документация уже есть, ее не помешает переписать и выделить этапы, которые могут быть непонятны или изменились со временем. Вы должны делать это независимо от того, отвечаете ли вы за обучение или нет, на случай, если вас собьет автобус.
Начните с документирования регулярных процессов. Напишите план и заполните детали.
Если есть какое-либо кодирование, убедитесь, что существует хотя бы базовый набор стандартов, которые все понимают и которым следуют.
Не забудьте поделиться документами со своими коллегами, прежде чем запланировать обучение, чтобы они могли просмотреть и задать вопросы.
Что касается самого обучения, то в прошлом я всегда сидел и следил за моими коллегами, пока они выполняли работу.
Преподавание — это совершенно другой набор навыков — потребуется много времени и много практики, чтобы научиться этому. Я думаю, что лучше всего будет уменьшить объем работы для себя.
Вы сказали, что руководство в основном хочет, чтобы вы показали, что вы стараетесь, и это хорошо. Тем не менее, я уверен, что вы и ваши коллеги не любите тратить свое время попусту, поэтому вам, вероятно, следует попытаться оправдать усилия, которые вы тратите.
Если бы я был на вашем месте, я бы первым делом встретился с вашими коллегами и спросил их, что им интересно узнать. Это значительно сократит количество материала, которому вы могли бы их научить. Вы также получите представление о том, что они думают о своих сильных и слабых сторонах, и как это совпадает с вашим восприятием. Это даст вам то, что вам нужно для разработки первого «курса». Рассмотрите возможность встречи один на один, если это возможно, так как люди будут более честными.
Для первого блюда не берите слишком высоко. Используя то, что вы узнали из своих первых выступлений, составьте список из 1-3 наиболее важных концепций или навыков, которым вам нужно будет их научить. Если они короткие, используйте 3, если нет, просто придерживайтесь одного. Затем запланируйте потратить около часа на то, чтобы обучить их этим вещам. Представьте, что вы знаете о предмете столько же, сколько и они. Какая информация вам понадобится, чтобы изучить навык или концепцию? Какие упражнения помогут вам их практиковать? Создайте короткую лекцию и пример упражнения для каждой темы. Также создайте очень короткое «домашнее задание», чтобы дать им возможность попрактиковаться.
Выполнение всего этого займет пару дней, так что вы можете понять, почему важно максимально ограничить область действия. После вашего первого «курса» вы гораздо лучше поймете, каковы ваши сильные и слабые стороны с точки зрения преподавания. Теперь ваша миссия — работать над недостатками, продолжая разрабатывать и преподавать короткие курсы по образцу того, что сработало в первом.
Когда вы делаете эти курсы, держите свои заметки в порядке. Они станут вашей документацией. По мере того, как вы будете лучше организовывать и передавать информацию, документация будет улучшаться и облегчать обучение.
Будет сложно научиться преподавать самостоятельно, но у вас действительно есть преимущество в том, что вы разработчик-самоучка — вы знаете, чему вам нужно научиться, чтобы хорошо выполнять свою работу. Многие люди, у которых были только хорошие учителя, так и не научились понимать это самостоятельно. Недостатком является то, что вы также не знаете многих стандартных методов обучения или способов структурирования обучения, поэтому вам придется изучать эту часть по ходу дела. Я бы искал стандартные учебники на любом языке или в той области, в которой вы работаете. Это даст вам примеры того, как структурировать знания.
Удачи!
Много хороших идей. До сих пор я не видел никаких рекомендаций по разработке небольших видеороликов с использованием инструментов захвата экрана. Документируйте процессы с помощью PSR.exe, многие люди не знают об этом инструменте, но он встроен в ОС Microsoft. Это экранный учебник, который вы можете аннотировать.
В большинстве ответов предполагается, что испытуемые хотят учиться (например, Тим Б.). Я бы сделал шаг назад и подтвердил это предположение, прежде чем выяснять «как». Когда учащиеся не заинтересованы и не мотивированы, обучение не будет эффективным, каким бы хорошим оно ни было, особенно в практической дисциплине, где практика абсолютно необходима для получения знаний и их эффективного использования.
Я предполагаю, что цель состоит в том, чтобы эти разработчики баз данных стали опытными до точки заполнения ваших больших ботинок, если это необходимо. Их спрашивали, звучит ли это как отличный план, или они активно просили об обучении в этих областях? Осведомленность о бизнес-потребности и активное отношение к ее реализации — разные вещи, требующие разного сочетания условий для их поддержания. Таким образом, хотя эти разработчики могут кивать, когда руководство поднимает эту тему на собраниях, они могут быть в лучшем случае пассивными или даже открыто сопротивляться, когда речь идет о фактическом обучении и изменении поведения (как его цели).
Есть несколько существенных преимуществ в том, чтобы сделать шаг назад и подтвердить мотивацию к обучению, прежде чем приступать к решениям:
Корректировка ожиданий и подхода: если разработчики не мотивированы и, скорее всего, будут пассивными учениками, потребуется один подход к обучению, в то время как, если они активны в этом, подход будет другим (например, требуется меньше надзора/удерживания за руку, другая мотивация). мониторинг структуры/прогресса, большая или меньшая автономия, предоставляемая учащимся, необходимая большая или меньшая гибкость с точки зрения выбора тем, порядка тем, модальности презентации и т. д.).
Экономия времени/усилий за счет обеспечения того, чтобы принятая стратегия обучения соответствовала потребностям учащихся и целям обучения (например, избегая тратить время/деньги на создание рабочих инструкций или подписку на онлайн-курсы только для того, чтобы увидеть минимальное использование/прогресс). Когда люди не хотят что-то делать, они, как правило, превосходно придумывают творческие отговорки и оправдания, чтобы не делать этого (например, рабочая нагрузка, разные стили обучения). Может быть трудно, если вообще возможно, определить, какие из этих оправданий действительны, а какие нет.
Начиная с правой ноги. Отличный способ гарантировать, что обучение не удастся, — это потребовать (принудить) его к участникам. С другой стороны, отличный способ максимизировать рентабельность инвестиций в обучение — это создать структуру поощрения, чтобы участники были внутренне заинтересованы в изучении материала (т. е. стремились учиться ради обучения, например, когда они искренне заинтересованы в предмет). В последнем случае участники самостоятельно адаптируют содержание к своему стилю обучения, встраивают его в свое расписание, регулируют темп обучения и т. д. Лучший ученик — это тот, кто принимает все эти индивидуальные решения самостоятельно, с может быть, какое-то руководство/совет извне (когда они в этом нуждаются). Просто подумайте, сколько головной боли это может избавить вас,
Я надеюсь, что эти мысли помогут вам шире взглянуть на то, что происходит (или не происходит) с точки зрения того, как преподносится и структурируется обучение, и внести некоторые коррективы, которые помогут максимизировать его эффективность в долгосрочной перспективе. Удачи!
Не предполагайте ничего об их знаниях. Подтвердите это. Вместо того, чтобы говорить, что они недостаточно квалифицированы, пусть какой-нибудь уважаемый авторитет объяснит им это. Microsoft, Brainbench, я уверен, что есть и другие поставщики тестов. Раньше Brainbench показывал слабые и сильные стороны, а также результаты тестов и ваше положение — все это можно использовать. Проведение стандартизированного теста важно, поскольку оно устраняет субъективный фактор.
Как только базовый уровень взят, не тренируйте базовые навыки. Позвольте другим сделать это за вас. Онлайн-курсы, такие как Udemy, Pluralsight и другие, могут помочь каждому получить базовый уровень. Это намного дешевле любой другой альтернативы. И они могут работать лучше по двум причинам:
Вы можете устареть на пару лет. К тому времени, когда вы всех обучите, разрыв будет больше. Чтобы оставаться на переднем крае технологий, вам нужно прекратить заниматься бизнесом, большинство людей не могут себе этого позволить.
Они умеют тренироваться. И да, за преподаванием стоит наука. Вы не можете просто передать знания в чужой мозг через USB. Вы также не можете говорить об этом и надеяться, что ваш ученик что-нибудь помнит. Задействовано много психологии.
Если вы хотите повысить шансы на успех, изучите и выберите курсы для них. К сожалению, в сети много мусора.
Следующий шаг (или вы можете сделать параллельно) — задокументируйте то, что вы знаете о приложениях, которые вы создали на высоком уровне. Предположим, вам нужно объяснить другому разработчику, такому же, как вы, который знает стек, имеет большой опыт, включая последние приемы, но который только что пришел в компанию и ничего не знает о вашем коде.
Начните зондировать людей, если ваша документация имеет смысл. Пусть задают вопросы. Обобщите, посмотрите, какая область вызывает наибольшее беспокойство. Там подробно. Смыть, повторить.
Есть и другой ответ на проблему «фактора автобуса». Если что-то случится (я бы предпочел думать о том, что вы выиграли в лотерею и решили уйти на месте, а не столкнулись с настоящим автобусом), конечно, компания в плохом положении. Но какое-то время все будет работать без вас, и это ситуация, когда вы нанимаете подрядчика для краткосрочного решения, а потом нанимаете нового разработчика с соответствующим опытом.
Конечно, им придется заплатить хорошие деньги за хорошего подрядчика, который сможет взять на себя вашу работу. Но у того, кто действительно хорош в этом, не будет проблем с тем, чтобы заменить вас. И через несколько месяцев оставьте все в порядке, чтобы его взял на себя средний разработчик. Переобучение ваших коллег, чтобы они могли выполнять работу, которую они, скорее всего, никогда не выполнят, будет и дорогостоящим, и не очень полезным.
Просто убедитесь, что нет ничего, что находится в вашем уме и больше нигде. Процедуры, которые необходимо соблюдать, чтобы все работало. Пароли, которые необходимы (и которые вы не должны записывать). И вместо того, чтобы документировать вещи, когда вы делаете что-то, требующее соблюдения процедур, попросите своего начальника выделить вам секретаря на несколько часов, который точно записывает все, что вы делаете, и которому строго приказано не упускать никаких подробностей.
Заставьте их делать вашу работу на некоторое время.
Например, если ваша работа в качестве разработчика приложений заключается в разработке приложения, назначьте им следующую задачу по разработке приложений.
Скажите им, что:
Потому что:
Учитывая, что вы в состоянии выполнить работу, вы, вероятно, в состоянии (если вас попросят) объяснить любой конкретный аспект в любом количестве деталей.
Ожидайте, что это (обучение) займет некоторое время. Надеюсь, руководство ожидает этого и с этим все в порядке. Когда я таким образом помогал (обучал) новых сотрудников, я примерно представлял, что на подробное объяснение задачи у меня уйдет столько же времени, сколько на то, чтобы выполнить ее самому; это заняло даже больше времени, чем для нового сотрудника. Например, работа (например, новая функция), которая может занять у меня три дня, чтобы сделать ее самостоятельно, займет у меня три дня, чтобы подробно объяснить ее, а у стажера уйдет пара недель.
Таким образом, вознаграждение (прибыль или сэкономленное время) не происходит мгновенно: оно наступает через несколько месяцев, когда новый сотрудник набирает обороты и может работать более или менее независимо.
О, да, помимо того, чтобы заставить их задавать специальные вопросы, вы должны проводить обзоры/проверки кода всего, что они заканчивают. Когда они говорят, что готовы к обзору кода, ваш первый вопрос может быть «Вы тестировали это?» В обзоре кода вы ищете очевидные ошибки. Идеальная ясность, к которой нужно стремиться, состоит в том, что код считается завершенным не тогда, когда «в нем нет явных ошибок», а тогда, когда «очевидно, что в нем нет ошибок».
Ваша критика в обзоре кода должна быть:
Вы программист, а не учитель, однако было время, когда вы не были программистом. Точно так же, как вы научились делать первое, вы можете научиться делать второе.
Поговорите со своей компанией о предоставлении вам обучения тому, как обучать других.
Лилиенталь
Боб Твей
Брандин
Нео
Боб Твей
Нео
Джаред Смит
Боб Твей
Доминик
Моника Челлио
JDługosz
Джакомо1968
скрежет729
Виктор Меллгрен
Виктор Захаров
business objective here is to rapidly train other staffНевозможно. Вы не можете преодолеть 20-летний разрыв за неделю.code_dredd