Всем привет! Меня зовут Стас, я работаю в Контуре в проекте Экстерн, и, параллельно с основными обязанностями, занимаюсь тем, что обучаю стажёров — уже состоявшихся разработчиков (не только программистов) и студентов. Учатся они у меня разным вещам, относящимся к процессу создания ПО, уже больше семи лет.
Раньше мне в голову не приходил вопрос — зачем я учу людей? Что получаю от этого? Если для обучаемого (будь то студент в университете, стажёр на работе или опытный разработчик на мастер-классе) профит более-менее ясен (и то, зависит от качества обучения), то что это даёт мне как преподавателю, рассказчику, эксперту? Более того, почему компания не против такой моей активности, а наоборот, даже поощряет её?
Теперь я серьёзно задумался об этом и расскажу в статье.
Когда я начинал работать над … назовём это «проявлением рефлексии», то собирался рассмотреть заявленные выше вопросы на примере двух курсов, которые веду в Контуре: крэш-курса для сотрудников (конкретно — блок по REST API) и мастер-класса по Playwright (базового уровня). В процессе понял, что стоит рассмотреть больше активностей, чтобы собрать больше примеров, сильнее раскрывающих мой взгляд на всё это.

Сторона 1: компания
Для первого примера возьмём крэш-курс для разработчиков.
Изначально главная задача крэш-курса — мягкий онбординг новичков. Курс состоит из нескольких блоков, часть из которых посвящена технологиям и продуктам инфраструктурных команд, используемых в Контуре, и проводится как для бэкендеров, так и для фронтендеров. Со временем добавилось новое значение — передача экспертизы в различных областях всем разработчикам (которые уже работают какое-то время в компании), а не только новичкам. Один из примеров — это как раз блок по REST API.
Что получает от этого компания? У посещающих курс сотрудников повышается общий технический уровень, появляется возможность узнать best practices, которые выработаны в течение долгого времени. Неочевидный момент — формируются горизонтальные связи: обучаемые могут в любой момент написать преподавателю, чтобы проконсультироваться по вопросам, подобным тем, что разбирали на занятии. Со временем эти связи могут вырасти в небольшое сообщество, либо «прорасти» в состав преподавателей (так я и пришёл вести блоки крэш-курса, будучи когда-то слушателем).
Выше я уже писал, что изначальной целью курса был мягкий онбординг новых сотрудников, это тоже идёт на пользу компании.
Второй пример — мастер-класс по основам написания тестов на Playwright.
Он был призван решить цель тогда ещё не всей компании, а конкретного проекта по переходу к Playwright для написания e2e-тестов на веб-сервисы (для большего понимания рекомендую ознакомиться со сравнениями Selenium, который ранее был основным инструментом, и самого Playwright).
Из особенностей цели — ранее e2e-тесты писали исключительно на C# и на Selenium, что привносило особенности в сами тесты — многое приходилось реализовывать самостоятельно. Теперь же выбрали новый инструмент, в котором разработчики учли опыт предыдущих фреймворков, за счёт чего он отличается от уже ставшего привычным Selenium.
Главный же вызов состоял в переходе к тестам на TypeScript (обоснование я здесь опущу, но готов рассказать отдельно). С Playwright мало кто был знаком, поэтому решили сначала презентовать его на внутренней конференции тестировщиков в виде мастер-класса по основам инструмента — запуск тестов, работа с режимами codegen, ui, debug, создание артефактов прогонов, их просмотр, фикстуры. Со временем этот МК стал проводиться для разных ролей без привязки к каким-либо событиям, а постепенно стал выходить и за рамки отдельно взятого проекта.
Профит компании здесь в том, что сотрудники обучаются новому инструменту более-менее согласованно, то есть, за счёт консолидации знаний в мастер-классе они (знания) распространяются примерно одинаково. К тому же, дальше обретённые навыки уже могут распространяться более стихийно, без участия преподавателей.
Третий пример, уже более классический — занятия в университетах.
Это самый популярный способ транслировать знания, но пусть это не умаляет его важности. Тут я не буду приводить в пример конкретный курс (я вёл в разное время разные), но у них общие задачи и цели.
Главная задача — дать студентам, которые могут стать будущими сотрудниками компании, знания, которые помогут в ней же легче стартовать, быстрее вникнуть в контекст и быстрее расти.
Зачем? Обычно те, кого ты вырастил, больше разделяют твои ценности, да и более лояльны к тебе, что для компании очень важно. Это помогает и в вопросе адаптации новых сотрудников, и в их удержании (звучит так, как будто их насильно приковали к компании, но нет, это добровольно). Ещё проще это делать, если вы можете участвовать в составлении учебного плана студентов.
Такая схема сейчас работает с направлением ФИИТ (Фундаментальная информатика и информационные технологии) в Уральском федеральном университете, которое является результатом партнёрства УрФУ и Контура. Очень много дисциплин там ведут сотрудники компании, они же и постоянно развивают курсы, адаптируя под текущую реальность и добавляя самое актуальное на сегодняшний день.
Неожиданное обоснование преподавания в университете принесло Минцифры с обновлением условий аккредитации IT-компаний: теперь участие в образовательных активностях не просто приветствуется, но и необходимо для сохранения статуса.
Сторона 2: обучаемый
Я не анализировал заданные в начале вопросы с позиции того, кому «вверяют» знания, но в процессе обучения эта сторона, наверное, самая важная, при этом, выгода её самая очевидная.
Вот что получают «студенты» (давайте для краткости назовём их так, будем подразумевать всех слушателей занятий и курсов):
новые знания: преподаватели, которые работают в компании, стараются давать самое актуальное;
тот самый нетворкинг: знакомство с другими «студентами», с которыми можно коммуницировать не только в рамках занятия; с преподавателями, к которым можно обратиться с разными вопросами (часто не только в рамках занятия). А ещё — с учащимися в университете, они так-то и компанию порекомендовать могут (в рамках стажировки, например);
возможность повлиять на наполнение курса с помощью обратной связи или даже с помощью «внедрения» в ряды преподавателей ?. Да, есть два «но»: это польза уже будущим поколениям, а не конкретно себе, а ещё авторы материала должны быть заинтересованы в его улучшении, однако использование такого института именно студентами показывает тем, кто даёт знания, что всё не зря, и мотивирует работать над содержанием дальше.
Сторона 3: преподаватель
Что же получают те, кто становится преподавателями? В первую очередь, как бы это ни было очевидно, — кайф от передачи знаний и общения с другими разработчиками. Появляется возможность аккумулировать весь свой опыт по конкретному вопросу и распространить его среди других людей, тем самым, возможно, обретя единомышленников. А если найдутся те, кто поставит под сомнение то, что им преподносят, — ещё лучше, ведь в споре рождается истина, и можно либо принять противоположную точку зрения, либо найти новые аргументы, которые могут принести пользу в будущей работе. Например, во время каждого нового занятия на блоке REST API разработчики задают разные хитрые вопросы, которые они хотят применить на практике. Приходится собирать весь свой опыт и находить решение очень быстро. Каждый раз я удивляюсь, какие решения удаётся придумать. Ну и новые горизонтальные связи я уже упоминал.
Во-вторых, есть некоторый материальный профит в виде небольших премий и горизонтального премирования от других сотрудников. В Контуре есть система премирования сотрудников сотрудниками, называется «Горизонт». В ней те, кто побывал на курсе, могут выразить небольшую денежную благодарность преподавателям.
В случае с курсом по Playwright для меня причины те же самые — кайф от передачи опыта и общения, чувство, что это приносит пользу другим людям и компании в целом, а также некоторые материальные плюшки, к которым на этот раз добавился мерч разных внутренних конференций. К тому же, этот курс попал в одну из итераций программы поощрения для разработчиков, где и победил в номинации «Передача знаний».
В случае с университетом польза в том, что лучших студентов можно схантить как минимум в компанию, максимум — себе в команду. В моей предыдущей команде несколько человек так или иначе прошли через курсы, которые я вёл, да и сам я туда попал, в том числе, благодаря знакомству с преподавателем.
(Не)официальное обращение (и чуток вброса)
Зачем я всё это рассматривал, да и ещё профит компании описывал (наверное, даже самый большой блок получился)? Не просто так, а с целью привлечь внимание руководителей к вопросу горизонтального распространения экспертизы (сиречь, преподавательская активность).

Хочу призвать вас (менеджеров, тимлидов, вышестоящее руководство): поощряйте такие вещи! Можно начать с малого — устраивать летучки в рамках команд, на которых разработчики будут делиться чем-то новым в мире технологий и практик. Со временем можно начать проводить кросс-командные мероприятия. Если к вам придёт разработчик с идеей провести мастер-класс — поддержите его, выделите ему время на подготовку и проведение, это всё окупится в виде повышения технического уровня ваших же сотрудников. Наградите сотрудника премией, пусть и небольшой — всё равно приятно, да и мотивации это придаёт, что бы там ни говорили про альтруизм.
Теперь обращаюсь к разработчикам: делитесь своими знаниями. Это поможет вам привести понимание каких-то вещей к общему знаменателю как минимум в своей команде, как максимум — задать движение всей компании. Также это позволяет нарастить горизонтальные связи, да и просто делиться знаниями бывает приятно. Про работу с университетом даже и говорить особо нечего — по моему мнению, это основная кузница будущих джунов, которые в будущем могут вырасти и в топов компании.
Название статьи я несколько связал с песней группы Architects — Dying Is Absolutely Safe с альбома For Those Who Wish To Exist. «Умирать» тут не надо, а вот желание жить и развиваться напрямую связано с развитием. Если будете поощрять развитие и передачу опыта — всё получится, нет — рискуете как минимум осесть в болоте (а сейчас уже и в аккредитации), максимум — потерять всех ценных сотрудников и бизнес, ну или своё лицо в глазах соискателей. Или голос, как Сэм Картер, вокалист этих самых Architects (отдельная моя боль, не удержался, чтобы не упомянуть). Не забывайте, что у вас есть свой голос, и чем громче его слышно, тем легче вам и набирать новых сотрудников, и не терять уже имеющихся.
На этом я и оставлю вас, уважаемые читатели, размышлять.

Cordekk
так сейчас с бумом ИИ может ваши джуны и не нужны будут, вот ведь какая проблема.
PhonkX Автор
Я думаю, обучение джунов (как и любой "новой крови" в IT) в том или ином виде ещё нескоро потеряет актуальность, и вот почему:
1. Текущие варианты нейросетей ещё упираются как в размер контекстного окна для управления всей кодовой базой отдельно взятого проекта, так и в необходимость использования огромных вычислительных мощностей (которые уже не выглядят безграничными), которые есть далеко не везде, особенно если вопрос касается локальных инстансов LLM, которые, по крайней мере, крупные компании стараются использовать (ибо коммерческая тайна, безопасность данных и прочее).
2. Пока человечество не перестроит все свои процессы так, чтобы им управляло ИИ (я не только про быт, а ещё про взаимодействие компаний/государства/разных социальных институтов, может даже, друг с другом), будут нужны "переводчики" с условно "человеческого" языка (хоть и достаточно структурированного) на какой-то язык требований, понятный ИИ. Сейчас такую роль выполняют программисты либо цепочки из аналитиков-программистов-менеджеров, так и останется, хоть и внешний вид такого "перевода" поменяется. Да, общие задачи и сейчас уже можно описывать простым языком, но всегда остаётся место для более точного запроса, если стоят специфичные требования.
Cordekk
просто в использовании ИИ мы все такие же джуны
dimulyaechayev
При таком раскладе у нового поколения специалистов, которые будут работать только покладаясь на ИИ будут проблемы, которые видно уже сейчас. Что бы создать что-то действительно качественное, нужно понимать бизнес-логику, поэтому тут скорее всего придётся переквалифицироваться в архитекторы, раз уж сама по себе разработка может отойти ИИшкам
oeditus
«Придётся переквалифицироваться в архитекторы» — это примерно как «новый робот пылесос заставил дворника переквалифицироваться в профессора».
Cordekk
погонщика роботов-пылесосов
Cordekk
и бизнес-логика поддается ИИ анализу.
недавно пробовал проведение интервью с Qwen для отрисовки схемы процесса.
он задает наводящие вопросы, я отвечаю.
на выходе полное описание процесса, текстовый регламент, схема, инструкция (выжимка) для дальнейшей проработки требований, чтобы пустить в разработку.