Буквально на днях, спустя три недели после выхода на работу, мой новый программист пишет такой же код, как и трое моих других опытных разработчиков, которые на том же проекте около года. В свою очередь эти трое создают единую архитектуру, дают одинаковые названия сущностям и пишут чистый код, что сильно упрощает проведение code review и облегчает всем понимание кода.
В этой статье я поделюсь своим опытом : за счет чего же я этого достиг. Я думаю мой опыт может быть вами применен в любой сфере IT и не только!
Синдром утенка
Давным давно, на заре своей IT карьеры, порядка 10 лет назад, я был на должности руководителя группы отдела технической поддержки. В мои обязанности входило обеспечение техподдержки клиентов компании. Нужно было принимать звонки и помогать клиентам. У нас в отделе было 2 группы. Одной управлял я, другой мой коллега. В каждой группе было где-то 8 — 10 человек. На тот момент мы оба были без опыта обучения и управления людьми, мы были из бывших сотрудников поддержки. Мы хорошо знали как все работает с технической точки зрения, но опыта управления у нас не было. Соответственно нам никто ничего не объяснял, ничему не учил и не передавал опыт. Как следствие мы управляли своим персоналом по наитию и по большому счету делали все то же самое, что делал с нами наш предыдущий «босс», когда мы были обычными инженерами. Так сказать в полной мере воплощали «синдром утенка», повторяли все за ним. Естественно, новых сотрудников нужно было обучать. И следуя синдрому утенка, мы оба, как и наш предыдущий босс, когда всего было 6 человек в отделе, обучали своих подчиненных лично. Садились рядышком с обучаемым на стульчик и объясняли: “вот смотри, тут у нас …”. И в таком режиме обучение проходило пара рабочих дней. Мне кажется, что мы таким образом обучали абсолютно всех инженеров около двух лет. За эти два года я даже умудрился расписать 2 листа А4, с порядка 40 вопросами, которые нужно успеть обсудить с учеником за эти 2 дня. И все бы наверное так и шло своим чередом, пока где-то спустя 2 года, один из моих инженеров подрос профессионально и в один прекрасный летний день спросил у меня: «А зачем ты им постоянно объясняешь одно и то же? Не легче ли описать мануал с типовыми вопросами и дать им читать, а потом что непонятно проговорить лично?». Я не доверительно отнесся к его словам, ведь разве люди способны сами понять такую “сложную” тему как протокол sip или работу с wireshark? Я был просто уверен что однозначно — нет. Но парень вызвался написать данный мануал сам и проконтролировать результаты с обучаемым, я согласился.
Правило Паретто.
Через 3 дня он мне прислал первый мануал по wireshark, с картинками и описаниями всех основных команд которыми мы пользовались и как в нем анализировать sip, rtp трафик и т.д. Я рискнул, дал одному из новых сотрудников изучить работы с wireshark по данному мануалу. Затем они созвонились с обучаемым, и с час что-то обсуждали. После этого я стал проверять знания новичка. И вы знаете, мне понравилось. Новичок действительно с помощью данного мануала усвоил и применял на практике все основные, типовые моменты где-то 80%. Остальные 20% он узнавал от меня, либо при работе с коллегами или в интернете. То есть я на практике видел работу закона Паретто, 20% усилий ( проговорить основные моменты в работе) дают 80% результата. Убедившись в эффективности прокачки людей по гайдам, я перестал их обучать по wireshark вообще, стал давать читать только данный мануал.
Оказывается, люди с высшим образованием способны прочитать материал и понять его сами
После нескольких успешных обучений wireshark только по гайду, я стал размышлять на тему как так вышло, что я учил сотрудников 2 года лично, тратил на них свое время, силы, повышал на них голос, иногда грубил. Мне казалось что они сами не были способны изучить те темы, которым я их учил и единственный носитель истинности и правды это был - я сам, именно вследствии этого у меня было явное недоверие к тому, чтобы они обучались сами. Но как показала практика, они без меня , сами, прекрасно и спокойно обучились основным моментам, на которые уходило 80% времени. Как так? И тут мне пришла гениальная мысль «А если человек умеет читать, то возможно он способен понять что написано?», тем более мы целенаправленно брали на работу только людей с высшим образованием. А что еще студенты делают, как не читают книги и изучают их, а тем более делают это на результат, чтобы получить оценку? И тут меня осенило: оказывается, люди с высшим образованием способны прочитать материал и понять его.
Масштабирование.
Как только я это осознал, я сразу понял, что подобные гайды просто необходимо масштабировать по другим темам, которым я учил. Я написал порядка еще 7 гайдов, и сложил их в одну папку с говорящим названием «Система обучения». В итоге у меня так впервые за 2 года моей «управленческой карьеры» появилась папка, в которой были собраны основные моменты в работе.
Делегирование
Мне понравился тот момент , что новичок прокачался без моего участия, а также то, что его знания проверял не я. Я предположил , что данному опытному сотруднику было несложно обучить новичка, т.к новичок перед этим прочитал его гайд. Спустя месяц — два я решил опробовать данный эксперимент с другим опытным инженером. Объяснил ему ситуацию , показал гайд, и поставил задачу обучить очередного новичка wireshark. Особого негатива я у него не увидел, наверное потому-что задача была поставлена в четких рамках, уже был составлен мануал, и нужно было проверить , что человек его прочитал. Результат был такой же, как и в первый раз. И тут меня осенило: оказывается, не обязательно учить людей самому, а можно это делегировать. А для того чтобы у «учителя» не было «молчаливого отрицания», всего-то нужно ему предоставить уже готовый материал и замотивировать. Мне это так понравилось, что я поставил это дело на поток. Теперь за обучение в моей группе отвечал самый опытный инженер, и я практически перестал заниматься этим лично.
В этой статье я поделюсь своим опытом : за счет чего же я этого достиг. Я думаю мой опыт может быть вами применен в любой сфере IT и не только!
Синдром утенка
Давным давно, на заре своей IT карьеры, порядка 10 лет назад, я был на должности руководителя группы отдела технической поддержки. В мои обязанности входило обеспечение техподдержки клиентов компании. Нужно было принимать звонки и помогать клиентам. У нас в отделе было 2 группы. Одной управлял я, другой мой коллега. В каждой группе было где-то 8 — 10 человек. На тот момент мы оба были без опыта обучения и управления людьми, мы были из бывших сотрудников поддержки. Мы хорошо знали как все работает с технической точки зрения, но опыта управления у нас не было. Соответственно нам никто ничего не объяснял, ничему не учил и не передавал опыт. Как следствие мы управляли своим персоналом по наитию и по большому счету делали все то же самое, что делал с нами наш предыдущий «босс», когда мы были обычными инженерами. Так сказать в полной мере воплощали «синдром утенка», повторяли все за ним. Естественно, новых сотрудников нужно было обучать. И следуя синдрому утенка, мы оба, как и наш предыдущий босс, когда всего было 6 человек в отделе, обучали своих подчиненных лично. Садились рядышком с обучаемым на стульчик и объясняли: “вот смотри, тут у нас …”. И в таком режиме обучение проходило пара рабочих дней. Мне кажется, что мы таким образом обучали абсолютно всех инженеров около двух лет. За эти два года я даже умудрился расписать 2 листа А4, с порядка 40 вопросами, которые нужно успеть обсудить с учеником за эти 2 дня. И все бы наверное так и шло своим чередом, пока где-то спустя 2 года, один из моих инженеров подрос профессионально и в один прекрасный летний день спросил у меня: «А зачем ты им постоянно объясняешь одно и то же? Не легче ли описать мануал с типовыми вопросами и дать им читать, а потом что непонятно проговорить лично?». Я не доверительно отнесся к его словам, ведь разве люди способны сами понять такую “сложную” тему как протокол sip или работу с wireshark? Я был просто уверен что однозначно — нет. Но парень вызвался написать данный мануал сам и проконтролировать результаты с обучаемым, я согласился.
Правило Паретто.
Через 3 дня он мне прислал первый мануал по wireshark, с картинками и описаниями всех основных команд которыми мы пользовались и как в нем анализировать sip, rtp трафик и т.д. Я рискнул, дал одному из новых сотрудников изучить работы с wireshark по данному мануалу. Затем они созвонились с обучаемым, и с час что-то обсуждали. После этого я стал проверять знания новичка. И вы знаете, мне понравилось. Новичок действительно с помощью данного мануала усвоил и применял на практике все основные, типовые моменты где-то 80%. Остальные 20% он узнавал от меня, либо при работе с коллегами или в интернете. То есть я на практике видел работу закона Паретто, 20% усилий ( проговорить основные моменты в работе) дают 80% результата. Убедившись в эффективности прокачки людей по гайдам, я перестал их обучать по wireshark вообще, стал давать читать только данный мануал.
Оказывается, люди с высшим образованием способны прочитать материал и понять его сами
После нескольких успешных обучений wireshark только по гайду, я стал размышлять на тему как так вышло, что я учил сотрудников 2 года лично, тратил на них свое время, силы, повышал на них голос, иногда грубил. Мне казалось что они сами не были способны изучить те темы, которым я их учил и единственный носитель истинности и правды это был - я сам, именно вследствии этого у меня было явное недоверие к тому, чтобы они обучались сами. Но как показала практика, они без меня , сами, прекрасно и спокойно обучились основным моментам, на которые уходило 80% времени. Как так? И тут мне пришла гениальная мысль «А если человек умеет читать, то возможно он способен понять что написано?», тем более мы целенаправленно брали на работу только людей с высшим образованием. А что еще студенты делают, как не читают книги и изучают их, а тем более делают это на результат, чтобы получить оценку? И тут меня осенило: оказывается, люди с высшим образованием способны прочитать материал и понять его.
Масштабирование.
Как только я это осознал, я сразу понял, что подобные гайды просто необходимо масштабировать по другим темам, которым я учил. Я написал порядка еще 7 гайдов, и сложил их в одну папку с говорящим названием «Система обучения». В итоге у меня так впервые за 2 года моей «управленческой карьеры» появилась папка, в которой были собраны основные моменты в работе.
Делегирование
Мне понравился тот момент , что новичок прокачался без моего участия, а также то, что его знания проверял не я. Я предположил , что данному опытному сотруднику было несложно обучить новичка, т.к новичок перед этим прочитал его гайд. Спустя месяц — два я решил опробовать данный эксперимент с другим опытным инженером. Объяснил ему ситуацию , показал гайд, и поставил задачу обучить очередного новичка wireshark. Особого негатива я у него не увидел, наверное потому-что задача была поставлена в четких рамках, уже был составлен мануал, и нужно было проверить , что человек его прочитал. Результат был такой же, как и в первый раз. И тут меня осенило: оказывается, не обязательно учить людей самому, а можно это делегировать. А для того чтобы у «учителя» не было «молчаливого отрицания», всего-то нужно ему предоставить уже готовый материал и замотивировать. Мне это так понравилось, что я поставил это дело на поток. Теперь за обучение в моей группе отвечал самый опытный инженер, и я практически перестал заниматься этим лично.