Задать вопрос Поделиться знаниями Редактировать страницу

Заранее подготовленные первые задачи

Заранее подготовленные первые задачи — это последовательность специально отобранных рабочих или приближенных к рабочим заданий, с помощью которых новичок осваивает продукт, архитектуру, инструменты и процессы команды через практику, постепенно переходя к самостоятельной работе.

Это могут быть как безопасные учебные упражнения, так и задачи, максимально похожие на рабочие, или настоящие низкорисковые задачи из продукта. Для последних удобно держать специальный пул или помечать их отдельным тегом.

Похожий подход давно используется в open-source: задачи с меткой good first issue специально выделяются как подходящие для первого вклада в проект.

Какую проблему решают заранее подготовленные первые задачи

После вводных встреч, чтения документации и прохождения чек-листов новичку всё равно нужно научиться работать именно в этой команде: найти нужное место в коде или документации, разобраться в процессах, выполнить изменение, пройти ревью, тестирование и другие принятые этапы работы.

Если первые задачи не подготовлены, новичку часто достаётся либо случайная задача из текущего backlog, которая может оказаться слишком сложной или срочной, либо искусственное упражнение, мало связанное с реальной работой.

Хорошо подобранная первая задача позволяет одновременно получить два результата:

  • рабочий результат — что полезного получит команда после выполнения задачи;

  • учебный результат — что новичок после неё будет знать или уметь делать самостоятельно.

В этом и состоит KM-смысл практики. Документация передаёт знание о том, как принято работать, а задача позволяет применить это знание и получить собственный опыт. Через одну небольшую задачу человек может познакомиться сразу с продуктом, архитектурой, инструментами, соглашениями, процессом ревью и людьми, к которым нужно обращаться.

Такие же, как и онбординг в целом

  • У руководителей подразделений:

    • Новые сотрудники долго выходят на "производственную мощность"

    • Онбординг новых сотрудников забирает много сил

    • Разобщенность подразделений

  • У knowledge-менеджера:

    • Нужно привить культуру обмена знаниями

    • Нужно исправить ошибки в базе знаний

== Инструменты онбординга и примеры их реализации:

Важный критерий успешности онбординга — это срок выхода сотрудника на полную мощность. В зависимости от вашего бизнеса для вас нормой может быть как онбординг в полгода, так и онбординг в течение двух дней: для более сложных, исследовательских и малоизученных профессий и позиций он будет дольше, для линейных низкоквалифицированных — он должен быть сильно меньше.

Определить "полную мощность" может, как правило, руководитель эмпирически, а также он может сформулировать формальные критерии (например: сотрудник самостоятельно решает какой-то класс задач, или какая-то частая задача начинает занимать меньше N времени, или какой-то формальный показатель достигает определённого значения).

С чего начать внедрение этого изменения

Начните с 5–10 задач, которые уже встречались в вашей команде и хорошо подходят для обучения. Необязательно придумывать специальные упражнения с нуля.

Условно первые задачи можно разделить на четыре типа:

  1. Учебные. Результат нужен прежде всего самому новичку. Например, нарисовать схему взаимодействия сервисов или самостоятельно собрать приложение.

  2. Приближенные к рабочим. Новичок проходит настоящий процесс, но работает в тестовой среде или с уже решённой задачей.

  3. Безопасные рабочие. Настоящий небольшой баг, тест, рефакторинг, документация или автоматизация, которые полезны команде, но не критичны для ближайшего релиза.

  4. Исследовательские. Так называемый spike, прототип или исследование неизвестной области. Особенно хорошо подходят более опытным сотрудникам.

Для каждой задачи полезно явно записать:

  • рабочий outcome: какой результат должен появиться;

  • учебный outcome: чему эта задача должна научить;

  • границы использования ИИ и способ проверки: что можно/принято делегировать ассистенту или агенту и как новичок подтверждает, что понял и проверил результат;

  • какой контекст и материалы стоит прочитать перед началом;

  • ожидаемый результат и Definition of Done;

  • к кому обращаться с вопросами и кто делает review;

  • примерную сложность и место задачи в последовательности.

Например:

  • Задача: исправить небольшой баг в форме регистрации.

  • Рабочий outcome: ошибка исправлена и изменение доставлено пользователям.

  • Учебный outcome: новичок проходит полный цикл изменения — находит нужный модуль, запускает проект и тесты, делает изменение, создаёт merge request и проходит code review.

При подборе задач можно ориентироваться на опыт других команд.

YADRO. В подходе Руслана Назарова используется практически лестница от обучения к самостоятельной работе. Сначала есть учебное упражнение — например, самостоятельно нарисовать устройство системы хранения данных. Затем идут безопасные технические задачи, максимально приближенные к реальности: собрать артефакты, установить релиз на тестовый сервер, запустить автотесты, поработать с логами. После этого новичок переходит к настоящим, но некритичным для релиза задачам: тестам, автоматизации, исследованиям, рефакторингу и документации. Сложность постепенно увеличивается, а помощь наставника уменьшается. См. доклад Руслана Назарова "Onboarding. Адаптация новичка" и его статью на Хабре.

hh.ru. Первой задачей мобильного разработчика часто выбирали рефакторинг legacy-экрана. Такая задача хороша не столько своей простотой, сколько тем, что заставляет новичка познакомиться сразу с несколькими важными частями системы: DI, модулями, framework’ами и библиотеками. Хорошая первая задача необязательно должна быть самой простой — полезно смотреть на то, сколько нужных знаний о системе она открывает. См. "Все на борт! Онбординг и адаптация новых сотрудников".

Улей. Для junior-разработчиков задачи дают от простого к сложному. Цель первой небольшой задачи — провести человека через весь путь от получения задачи до релиза; примером такой задачи может быть небольшая ошибка в настройках. См. описание онбординга junior-разработчиков.

Альфа-Банк. Для мобильных разработчиков используется отдельный onboarding-проект: задачи в Jira идут от простого к сложному, содержат ссылки на документацию и примеры production-кода, а для экспериментов есть отдельный репозиторий, где новичок не может сломать production. См. "100 дней из жизни новичка".

GitLab. В GitLab онбординг оформляется как заранее созданный issue с общими и специфичными для роли задачами. Есть и хороший пример учебной задачи через настоящую работу: новому сотруднику нужно изменить свою запись на Team Page и пройти настоящий workflow создания и review merge request. См. GitLab Onboarding Handbook и инструкцию по изменению Team Page.

Есть и исследовательское подтверждение такого подхода. В исследовании Microsoft, опубликованном на ICSE 2021, выделены три стратегии подбора онбординг-задач: Simple-Complex, когда сложность постепенно растёт; Priority-First, когда новичок берёт обычные приоритетные задачи из backlog; и Exploration-Based, когда ему дают плохо определённую исследовательскую задачу. Для junior-разработчиков особенно хорошо показал себя постепенный путь Simple-Complex, а исследовательские задачи чаще подходят опытным специалистам. См. A Case Study of Onboarding in Software Teams: Tasks and Strategies.

Первые задачи и разработка с ИИ

ИИ-ассистенты и кодовые агенты позволяют новичку разобраться в незнакомой кодовой базе и выполнить первые изменения значительно быстрее. Но здесь же возникает новый риск: задача может быть выполнена, а новичок при этом почти ничему не научится.

Поэтому при подготовке первых задач стоит определять не только рабочий и учебный outcome, но и что можно делегировать ИИ и как проверяется результат. Удобно фиксировать это одним из трёх режимов: ИИ без ограничений, ИИ только как помощник или ИИ сознательно ограничен на время задачи. Хорошая первая задача по-прежнему должна требовать от новичка понять нужную часть системы, оценить предложенное решение и объяснить, почему полученное изменение корректно.

Это меняет и подход к подбору задач. Простой баг, тест или рефакторинг сегодня часто выполняется агентом почти целиком, поэтому простота реализации сама по себе больше не критерий. Предпочтительнее задачи с большой обучающей площадью — те, что вынуждают разобраться в архитектуре, бизнес-правилах, процессе доставки, режимах отказа и во взаимодействии с людьми. Кейс hh.ru с рефакторингом legacy-экрана — как раз пример такой задачи: она ценна не простотой, а количеством знаний о системе, которые сотрудник получит.

Первые задачи полезны и для самой базы знаний: если ни новичок, ни агент не могут найти важное соглашение или шаг настройки, это сигнал обновить документацию или инструкции в репозитории (AGENTS.md, CLAUDE.md, ADR) — и такое обновление разумно включить в саму задачу. Подробнее об этом — в практиках документирования на лету и ИИ в процессах разработки.

Отдельно стоит сознательно сохранить человеческое взаимодействие. ИИ хорошо закрывает «неудобные мелкие вопросы», которые новичок стесняется задать коллегам, — этот эффект отмечается в систематическом обзоре Novice Developers' Perspectives on Adopting LLMs for Software Development. Но он не должен заменять обсуждение архитектуры, разговор на ревью и контакт с носителями доменных знаний.

Тот же обзор отмечает, что влияние LLM на взаимодействие новичка с наставником пока не изучено. Непонятно, где проходит граница: какие вопросы полезно закрывать через ИИ, а какие – обязательно человеку.

Более широкая тема — как онбордить разработчика в саму агентную инженерную работу: делегирование, надзор за агентами, контекст-инжиниринг, параллельные агенты. Это отдельная большая практика, а не часть подготовки первых задач.

Запуск пилотного проекта

Выберите одну команду и ближайшего новичка. Вместе с руководителем и наставником подготовьте небольшую последовательность из 3–5 задач. Например:

  • Developer: собрать и запустить проект → исправить небольшой баг → добавить тест → сделать небольшое рабочее изменение.

  • QA: развернуть тестовое окружение → воспроизвести известный дефект → пройти существующий тестовый сценарий → добавить или улучшить тест.

  • Analyst: воспроизвести существующий отчёт → разобраться в источниках данных → описать известный бизнес-кейс → самостоятельно разобрать небольшое новое требование.

  • Support: разобрать несколько уже закрытых обращений → воспроизвести проблему на тестовом стенде → обработать учебный инцидент → решить реальное низкорисковое обращение под review наставника.

Не стремитесь сразу построить идеальную программу на три месяца. Для первого пилота достаточно проверить, помогает ли подготовленная последовательность быстрее перейти от чтения материалов к самостоятельной работе.

Смотреть можно на несколько простых сигналов:

  • сколько времени прошло до первой завершённой end-to-end задачи. Обратите внимание, что классический time to first pull request с появлением агентов становится всё более слабым сигналом: PR может появиться очень рано и почти без участия новичка. Более честный ориентир — время до первого изменения в продакшене, которое сотрудник самостоятельно понял и проверил;

  • когда появилась первая задача, которую сотрудник смог выполнить преимущественно самостоятельно;

  • уменьшается ли количество помощи наставника от задачи к задаче;

  • способен ли новичок пройти принятый в команде рабочий процесс целиком;

  • какие знания, инструкции или доступы неожиданно понадобились во время выполнения задач.

Последний пункт особенно полезен для KM: первые задачи становятся ещё и способом проверить качество существующей базы знаний.

Масштабирование успеха

После нескольких онбордингов не фиксируйте последовательность намертво. Сохраняйте удачные задачи как шаблоны, а настоящие низкорисковые задачи помечайте в backlog тегом вроде onboarding, starter-task или good-first-task. Если процесс онбординга уже ведётся через трекер задач, пул первых задач удобно держать там же.

Пул нужно регулярно пополнять: рабочие задачи закрываются, архитектура и процессы меняются, а старые учебные задания постепенно перестают отражать реальность.

Хороший вариант — иметь несколько последовательностей для разных ролей и уровней. То, что полезно стажёру, может оказаться слишком простым для senior-разработчика. Для опытного сотрудника иногда лучше небольшой исследовательский spike, который позволит самостоятельно исследовать систему и найти нужных экспертов. Исследование Microsoft, упомянутое выше, также показывает различия между предпочтительными стратегиями для junior и senior разработчиков.

Более масштабная версия этой практики — буткемп, когда новичок сначала пробует задачи нескольких команд, а уже потом выбирает постоянную.

Такой подход использовался, например, в Яндекс.Еде: после предбуткемпа, который знакомит с инструментами и процессами разработки в компании в целом, разработчики по две недели работали в разных командах, а затем выбирали наиболее подходящую. См. доклад Ильи Шишкова, описание онбординга разработчиков Яндекс.Еды и более ранний кейс Яндекса на Хабре.

Другие варианты организации онбординга разработчиков: IT Bootcamp в Сбере, онбординг в Авито, онбординг разработчиков в Т-Банке и процесс адаптации в Ozon.

Это уже более сложная организационная модель и, скорее, отдельная практика онбординга.

Со временем имеет смысл развивать несколько подходов

В процессе развития онбординга он может объединять несколько подходов.

В докладе "Добро пожаловать на борт: вводим новых разработчиков в команду" (статья) описана целостная система онбординга, включающая в себя: менторство в онбординге, экскурсию по офису, автоматизацию и трекинг процесса онбординга, правила составления Quick Start документа, практические задания, тестирование онбордящихся и идеи упражнений по проектированию.

Также стоит обратить внимание на доклад Александра Афёнова "Сверстать всех наверх: Онбординг новых сотрудников", он сменил несколько лидерских позиций в Lamoda и наблюдал масштабирование и изменение практик онбординга в компании, он считает, что в компании сложился фреймворк и делится им в докладе. В этот фреймворк входят следующие практики:

  • Buddy внутри команды, кому можно задавать вопросы, регулярно встречаться и передавать знания (это время учтено в спринт-планинге и поощряется на перфоманс-ревью);

  • Погружение в бизнес компании, в задачи и проблемы, что именно придётся автоматизировать: induction лекция на несколько часов о работе каждого департамента, о решении задач бизнеса, об успехах и провалах;

  • IT-онбординг: рассказ о процессах разработки, инфраструктуре, к кому с чем идти, история технических решений;

  • IT Gathering: сбор всего ИТ раз в квартал, куда мы идем и куда пришли, что нового, какие планы. С новичками говорят на равных.

  • Экскурсия на склад, рассказ обо всех производственных процессах, где новички видят, что они будут автоматизировать (опционально: экскурсия на фотостудию, создание контента для сайта и возможность побыть курьером-водителем, поразвозить заказы, подождать примерку и т.д.);

  • Q&A каждый день, выделенное время на задавание вопросов. Не замена 1-1 встречам.

  • Чек-лист: все, что человеку нужно освоить за определённый период, куда получить доступы и в чём поучаствовать, например, понять, что показывается на борде в Grafana.

Ещё один доклад от Руслана Остропольского из Сберздоровья про онбординг в распределенной команде (статья-выжимка на VC и слайды), он рассказывает о трёх подходах к онбордингу (лекция тимлида, наставничество и онбординг по плану из вики-системы) и их плюсах / минусах для разных ситуаций.

Докладчик поделился, что входит в их онбординг "квик старт":

  • культура и ценности команды, подходы к работе;

  • административные и организационные моменты;

  • инструменты и доступы;

  • проекты и команды, кто за что отвечает;

  • процессы.

Из интересных идей:

  • Структурируйте путь новичка в виде roadmap, чтобы он видел следующие шаги и последовательность действий;

  • Использовать вложенность страниц, делайте кросс-ссылки между разделами, например, про разработку и тестирование, так разные отделы могут поддерживать свои куски;

  • Используйте скриншоты и видео;

  • Добавляйте контакты в помощь;

  • Присваивайте каждому пункту Definition of done, что является результатом каждого шага или как проверить его выполнение.

Что может пойти не так

Дать первую попавшуюся задачу из backlog. Она может оказаться срочной, слишком большой или требовать знаний, которые новичок ещё физически не мог получить. Стратегия Priority-First используется на практике, но в исследовании Microsoft часть новичков отмечала сложности и снижение уверенности при слишком сложных задачах в начале онбординга.

Сделать все задачи полностью искусственными. Новичок хорошо научится проходить учебные упражнения, но переход к реальному проекту всё равно окажется отдельным онбордингом. По возможности учебная задача должна использовать те же инструменты, процессы и соглашения, которые используются в работе.

Выбрать слишком большую первую задачу. Лучше несколько завершённых небольших задач с быстрой обратной связью, чем одна "учебная фича" на месяц. В YADRO практический этап начинается с задач длительностью от нескольких часов до пары дней, а затем сложность постепенно увеличивается.

Агент прошёл онбординг вместо новичка. Влитый merge request больше не является достаточным доказательством того, что человек чему-то научился. Если задача закрыта, но сотрудник не может объяснить решение, найти его в коде и предсказать последствия изменения, учебный outcome не достигнут — и выяснится это позже, на более сложной задаче или на инциденте. Поэтому в первых задачах полезно спрашивать не только "работает ли", но и "почему сделано именно так".

Не сформулировать учебный результат. Если известно только, что нужно сделать, но не понятно, чему задача должна научить, в пул быстро начинают попадать просто "несрочные задачи, которые никто не хочет брать".

Дать задачу и оставить новичка одного. Первая задача нужна не для проверки, "выплывет человек или нет", а для передачи знаний. На старте должны быть понятны наставник, способ задать вопрос и человек, который даст обратную связь.

Забыть обновлять пул. Если учебные задачи работают с устаревшим кодом, старым процессом или несуществующей инфраструктурой, практика начинает передавать новичкам знания о том, как команда работала раньше, а не о том, как она работает сейчас.

Лицензия Creative Commons | by Igor Tsupko, Lana Novikova, Rodion Nagornov & community