Меня зовут Дмитрий Фомин. Я работаю в компании DNS с 2006 года. С 2010 года прошел путь от начинающего разработчика до CTO одного из направлений. DNS – довольно крупная компания и лидер на рынке цифровой техники в России. В ее инфраструктуре функционирует множество систем, построенных на платформе 1С:Предприятие.
Крупнейшая система и дефицит кадров
Самая масштабная система в компании – УБД. Ее объем составляет около 40 терабайт, а в разработке и сопровождении задействовано порядка 200 программистов 1С. Многие годы компания DNS активно росла, и в какой-то момент столкнулась с острым дефицитом специалистов 1С на локальном рынке – в городе Владивостоке. Чтобы закрыть потребность в кадрах, компания приняла решение организовать собственные обучающие курсы.
Успешный эксперимент: обучение внутри компании
Благодаря этим курсам в компанию пришел более стабильный поток квалифицированных специалистов – эксперимент оказался очень успешным. Об этом опыте уже рассказывали мои коллеги на различных конференциях. Моя статья посвящена как раз последствиям быстрого притока новых разработчиков в компанию.
Задача: управление командой с преобладанием новичков
Направление «Логистика» отвечает за все процессы, связанные с перемещением товара – от поставщика до конечного клиента. Это одно из стратегических направлений, которое регулярно получает амбициозные планы по развитию. Для реализации масштабных изменений потребовалось быстро увеличить ресурсы команды разработки.
В мою команду стали поступать выпускники внутренних курсов сплошным потоком. В какой-то момент новички составляли более 80% команды. За несколько лет мы накопили значительный опыт управления такой командой. В итоге нам удалось выстроить устойчивую группу из нескольких десятков опытных специалистов с почти нулевой текучестью кадров.
Цель статьи: советы начинающим лидам
В этой статье я хочу предложить несколько практических советов, которые помогут начинающим лидам справиться с управлением командой, в которой много новичков. При этом эти рекомендации будут полезны и в любых других командах разработки. Давайте разберемся, с какими основными проблемами сталкиваются команды, где преобладают начинающие разработчики.
Основные проблемы в командах с новичками
Прежде всего – высокая нагрузка на руководителя и старших разработчиков. Из-за этого они вынуждены уделять новичкам недостаточно внимания. Также возникает сложность с подбором задач, адекватных уровню начинающего специалиста. Все это приводит к тому, что новички медленно адаптируются, долго входят в рабочие процессы и слабо разбираются в архитектуре и методах разработки. В итоге многие задачи реализуются с задержками и низким качеством.
Общие стратегии решения проблем
Что можно с этим сделать? Во-первых, выстроить эффективную систему наставничества, включая привлечение джунов в роли наставников. Необходимо регулярно анализировать процессы, выявлять узкие места и оптимизировать их. Следует создать и поддерживать базу знаний по всем ключевым процессам. Важно повышать проработанность технических заданий, внедрять различные виды ревью – как инструменты групповой разработки. Также стоит внедрить специализацию и наладить синхронизацию внутри команды.
Эффективное наставничество: почему джуны – лучшие наставники
Теперь подробнее о некоторых подходах, которые на первый взгляд могут показаться неочевидными. Начинающему программисту крайне важно быстро освоить рабочие процессы и культуру разработки, адаптироваться в команде и стать ее полноценным участником. Для этого ему необходим наставник – тот, кто поможет пройти путь постепенного роста и к которому можно будет обратиться с любым вопросом.
Что делать, если в команде подавляющее большинство – новички? Если каждый опытный разработчик будет курировать по несколько новичков, у него просто не останется времени на выполнение своей основной работы. В такой ситуации не бойтесь привлекать в наставники программистов с опытом 6–9 месяцев.
Такие специалисты часто более ответственно относятся к своей роли наставника. Кроме того, они лучше понимают трудности новичка, потому что сами недавно прошли через этот этап. Джун понимает джуна и его проблемы лучше, чем опытный сеньор, и общается с ним на одном языке. Соответственно, его помощь оказывается более эффективной.
А можно ли сравнить такого джуна-наставника с опытным синьором? Разве знает он какие-то глубинные особенности платформы, какие-то хитрые приемы разработки? Нет – это и не нужно, потому что у нас нет цели сделать из новичка супер-специалиста за три месяца. Нам необходимо, чтобы новичок быстро адаптировался в команде и освоил базовые навыки, при этом без сильного влияния на команду. И с этой задачей джун-наставник отлично справится.
Нужно ли заставлять всех быть наставниками? Нет, потому что многие программисты не готовы взаимодействовать с остальными участниками в такой роли. Но важно доносить до команды, что от наставничества выигрывает не только новичок, но и сам наставник. Когда что-то объясняешь другому человеку, начинаешь сам это лучше понимать.
При этом нужно сделать процесс наставничества максимально понятным и простым для программистов, чтобы у них не возникал стресс от одной мысли о том, что они будут наставниками. В базе знаний надо описать весь процесс наставничества, а также наши ожидания от наставника.
Долгосрочное наставничество и ротация
Также важно помнить: наставничество не должно заканчиваться по истечении испытательного срока. Лучше выстроить целую сеть наставников и организовать между ними ротацию – передачу опыта по цепочке. Ведь для профессионального роста программисту необходимо не только практиковаться, но и систематически изучать теорию.
Теория и практика: как давать задачи новичкам
Не менее важен и практический опыт – решение реальных задач и работа с существующими механизмами. Теория и практика дополняют друг друга и усиливают эффект от обучения. Чтобы новичок стабильно получал практические навыки, ему нужно давать четко проработанные и понятные задачи.
Да, полезно и нужно давать время от времени задачи на «растягивание» – такие, где нет детального описания, и требуется самостоятельно разобраться в проблеме. Однако в первый год работы таких задач должно быть минимальное количество. Основная часть заданий должна содержать подробное и понятное описание того, что именно нужно сделать. Декомпозируйте задачи так, чтобы их планируемое время реализации не превышало 10–12 часов. Чем меньше и проще задача – тем легче новичку понять, что от него требуется, и тем проще контролировать ход ее выполнения.
Проработка технических заданий и вовлечение команды
Хорошо, если в команде есть системные аналитики. Но если их нет, руководитель не должен брать на себя всю ответственность за формирование задач – иначе он рискует стать узким местом в процессе. Вовлекайте в подготовку задач всех опытных участников команды. Это помогает распределить нагрузку и повысить качество ТЗ.
Дополнительно улучшить проработанность технических заданий помогает ревью требований – когда второй участник проверяет уже подготовленное задание, анализирует его полноту, логику и, что особенно важно, понятность для исполнителя.
Культура самостоятельности и помощи
С самого первого дня работы программист должен усвоить: перед тем как задать вопрос, нужно сначала попытаться найти ответ самостоятельно. Если за разумное время это сделать не удается – тогда уже стоит обратиться за помощью.
Алгоритм поиска ответа можно выстроить следующим образом:
– сначала изучить документацию,
– затем заглянуть в код,
– проверить, как решались похожие задачи ранее,
– обратиться к наставнику,
– если он не в курсе – к другим коллегам или руководителю.
Важно, чтобы в команде была здоровая атмосфера, где все готовы помогать друг другу, и новички не боятся задавать вопросы.
Техническое ревью перед началом кода
Роль наставника – не только помогать при возникновении трудностей. Получив задачу, программист не должен сразу приступать к написанию кода. Сначала нужно внимательно изучить описание, понять, какие механизмы затрагиваются, составить план реализации и подойти к наставнику для проведения так называемого технического ревью – синхронизации по пониманию задачи и предполагаемому решению. Техническое ревью позволяет вовремя скорректировать направление, избежать ошибок и сэкономить время, не тратя его на реализацию неверного подхода.
Ревью кода как инструмент качества и обучения
Ревью кода – это проверка и анализ кода вторым (или несколькими) разработчиками по различным критериям: читаемость, соответствие стандартам, эффективность, безопасность и т.д. Ревью кода должно быть в любой команде – каждый коммит должен проходить проверку хотя бы одним другим участником.
Преимущества этого очевидны: повышение устойчивости системы (бас-фактора), выявление ошибок до публикации, рост качества кода, распространение командной культуры и обучение.
Последний аспект особенно важен для новичков. Ревью кода становится важным каналом передачи знаний – через него junior-разработчики учатся у более опытных коллег, не только получая замечания, но и видя лучшие практики в действии.
Парная реализация как метод быстрого обучения
Парная реализация – это эффективный прием быстрого обучения. Заключается он в следующем: наставник реализует базовую часть механизма, а основные функции поручает менее опытному программисту, который выполняет их под контролем в виде отдельных задач.
Например, заказчик запросил реализацию инструмента учета опозданий логистических компаний. В рамках этого инструмента должны быть предусмотрены: различные способы вывода информации, цветовое выделение, возможность редактирования и сохранения данных, печатная форма, отправка уведомлений по email и т.д.
В таком случае первую задачу – создание минимальной рабочей версии – выполняет наставник. Остальные задачи он передает новичку, который реализует их под его контролем. В результате наставник глубже погружается в процесс обучения, а новичок быстрее осваивает типовые приемы и архитектурные решения.
Автономность команды: как избежать зависимости от руководителя
Если руководитель вручную распределяет задачи между разработчиками, это становится неэффективным даже в небольшой команде. Задачи могут внезапно закончиться или заблокироваться – и тогда программист вынужден простаивать, ожидая новую задачу от руководителя. Эта проблема усиливается по мере роста команды.
Возникает вопрос: зачем вообще руководитель выполняет такую операционную функцию? Почему весь процесс разработки замыкается на одном человеке? Гораздо правильнее сформулировать простые и понятные правила, по которым разработчики сами могут выбирать задачи из подготовленного бэклога.
Еще лучше – настроить систему так, чтобы они могли брать только те задачи, которые соответствуют их уровню и не заблокированы другими задачами.
Делегирование и устранение узких мест
Конечно, речь идет не о новичках. Им задачи по-прежнему должны выдавать наставники – по тем же правилам и из того же бэклога.
Как только опытные разработчики начнут самостоятельно брать задачи, ничего страшного не произойдет. Напротив, руководитель освободится от рутинных действий и сможет сосредоточиться на более важных задачах: настройке процессов, стратегии и развитии команды. Также стоит проанализировать все функции, где руководитель выступает узким местом, и делегировать их обратно в команду.
База знаний: ключ к быстрой адаптации
Новичок быстрее осваивает процессы и адаптируется в команде, если все ключевые процессы зафиксированы в базе знаний. Необходимо оцифровать все рабочие процессы разработки – в виде статей, схем, регламентов, договоренностей и гайдов – и объединить их в единую логическую цепочку. Следуя по ней, программист сможет самостоятельно ознакомиться со всеми необходимыми материалами. При этом статьи и схемы должны быть понятными и учитывать все возможные варианты развития процессов.
Преимущества описанных процессов
Благодаря такой системе новичок может самостоятельно находить ответы на свои вопросы, быстро понимать, что и когда нужно делать, и к кому обратиться в случае необходимости. Эти материалы полезны не только для новичков – опытные разработчики тоже могут к ним обращаться. В результате у всей команды формируется единое понимание процессов, сокращается время на непродуктивное взаимодействие и снижается вероятность сбоев при реализации задач.
Примеры из практики: BPMN, код-ревью, план обучения
В нашей базе знаний, например, есть три типичных примера. Во-первых – процессы, описанные в нотации BPMN, с наглядной схемой:
Во-вторых – статья по код-ревью:
В-третьих – это план изучения материалов для новых сотрудников. Следуя по нему, новичок последовательно знакомится с теми материалами, которые мы считаем необходимыми. Ссылку на первую статью из этого плана можно отправлять новому сотруднику в день выхода – в виде приветственного письма на почту.
Кроме того, описанные процессы позволяют анализировать текущие практики, выявлять узкие места и улучшать их. Конечно, база знаний должна постоянно поддерживаться в актуальном состоянии.
Специализация: от скептицизма к признанию
По возможности стоит вводить специализацию: программисты должны фокусироваться на конкретных механизмах и бизнес-процессах. Это помогает им быстрее осваивать сложные области и эффективнее расти до уровня опытных разработчиков.
Раньше я считал, что специализация – это скорее вред, чем польза. Мне казалось, что чем больше механизмов и процессов "потрогает" программист, тем быстрее он станет опытным. Однако, внедрив сначала базовую, а затем и более глубокую специализацию, я осознал, что ошибался. Именно глубокое погружение в конкретные области помогает разработчику быстрее становиться настоящим экспертом.
Баланс специализации: избегайте узких мест и выгорания
При этом важно учитывать бас-фактор: нельзя допускать появления уникальных экспертов, без которых процесс останавливается. Обязательно обеспечьте, чтобы по каждому критическому механизму было вовлечено как минимум два человека.
В то же время избегайте чрезмерной узкой специализации. Если разработчик работает только с одним инструментом или модулем, высок риск выгорания и, как следствие, ухода из компании. Важно находить баланс.
Главный совет: не сидите на двух стульях
И последний, самый простой, но в то же время самый важный совет: не сидите на двух стульях. Передайте всю непосредственную разработку другим членам команды, а сами сосредоточьтесь на управлении, анализе и улучшении процессов. Да, отказаться от любимого программирования бывает непросто – но лучше сохранить его как хобби. И тем более это важно, чем больше команда и чем больше в ней начинающих разработчиков.
При этом не переставайте изучать технологии. Это поможет вам оставаться авторитетом для команды и говорить с ней на одном профессиональном языке.
Надеюсь, мои советы окажутся для вас полезными. Если есть вопросы – пишите их в комментариях – я с удовольствием отвечу.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.
