Интеграция джуна в проект

К написанию статьи меня сподвигло посещение SQA-days. В одном из докладов человек рассказал о системе их адаптации новых тестировщиков и эта система практически один в один повторяла нашу, а к нашей я пришла из не IT проекта (мне и раньше приходилось обучать новых сотрудников - несмотря на нюансы, общие процессы оказались схожими). И так как к этому времени я уже помогла еще двум коллегам из других организаций составить план адаптации, то решила - чего молчать, расскажу ка я про это прилюдно, раз тема волнует многих.

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

За этот месяц я собрала в вордовский документ все то, что узнала, и когда через некоторое время мне удалось уговорить начальство на создание внутреннего тестировщического портала (ну как уговорить... диалог был примерно таким: "а давай я портал замучу?" - "ну давай, только быстренько"), вся эта информация ушла на портал. А потом расширилась, и у нас получился портал с полноценной базой знаний. Параллельно я разработала полноценную систему по внедрению джунов в проект.

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

Для чего нужна эта система:

  1. Ускорить процесс адаптации, чтобы новенький побыстрее начал приносить пользу (экономическая выгода)
  2. Уменьшить количество вопросов новенького к коллегам - это здорово отвлекает (психологическая выгода, ну и немного экономическая)
  3. Систематизировать все знания о проекте - это полезно и стареньким сотрудникам (просто сплошная выгода)

Шаги адаптации:

  1. День первый. Получение первого инструктажа (отдел кадров, выдача компьютера, первые доступы и т.п.). Торжественное вручение презентации и корвалола.
  2. День второй. Отбираем корвалол. Знакомство с командой. Проговариваем голосом еще раз про - проекты, процессы и прочее. Пожалуй, на этом заканчивается близкое общение с джуном, начинается его самостоятельная работа. Установка софта, чтение документации по конкретному проекту. Презентация становится его библией на ближайшие несколько недель.
  3. День третий. Из-за специфики нашего проекта, третий день может растянуться - у нас достаточно долго получаются все доступы к Jira и прочим интересным местам. Поэтому приходится знакомить стажера с актуальными талонами, в которых он может начать разбираться скриншотами. Но вообще на третий день мы уже поручаем вникать в проблемы модуля, к которому прикреплен стажер. Чтобы не случился переизбыток информации, каждый новый человек знакомится с одним, конкретным модулем, и к нему прикрепляется тестировщик, знающий модуль от и до. Со временем джуны переходят к другому модулю, когда уже будут немного в курсе проекта в целом.
  4. День шестой. Опрос стажера - чего ему не хватает для работы (оборудования, информации). С какими трудностями он столкнулся (конечно, с непреодолимыми трудностями мы разрешаем вопрос сразу, не дожидаясь шестого дня, но общие вопросы оставляем как раз на начало второй рабочей недели).
  5. День десятый. К этому моменту человек уже знаком с очертаниями проекта, с актуальными проблемами своего модуля, и мы отвлекаем его от всего, что он делал до этого. Просто, чтобы переключить его и поручаем писать SQL запросы к БД. У нас на портале есть база постоянных запросов, которые мы используем регулярно, но всегда есть то, чего не хватает. Поэтому мы поручаем нашим стажерам написать пару новых запросов под наши нужды и пару запросов, которых не хватает лично им. Этим мы добиваемся решения сразу трех проблем: 1. даем человеку переключить мозг, 2. новенький ближе знакомится с нашей БД, 3. если повезет, наша база знаний пополнится новыми готовыми SQL-запросами.
  6. Две недели на проекте. Стендап команды тестирования с джунами. Возможно это не очень актуальный шаг для других проектов, но мы редко встречаемся своим узким кружком для поговорить, а команда у нас условно-распределенная (мы все живем в одном городе, но сидим в разных офисах, а то и на удаленке, а тут такая прекрасная возможность встретиться вживую). Для кого-то будет актуальным zoom-джойн для всех тестировщиков. Мы стараемся в эту встречу пообщаться с новенькими и друг с другом об актуальных проблемах. В эту встречу можно поменять дуэты из стареньких+новеньких тестировщиков, прикрепить новеньких к новым модулям, просто послушать как у них дела. Ну и вообще это неплохое время поболтать всем вместе. 
  7. Месяц на проекте. К этому моменту на всех проектах у новеньких немного разные знания, умения и полномочия. В нашем они уже полноценно пишут проверки, скрипты, заводят талоны (под присмотром старших товарищей, конечно). К этому моменту они уже умеют общаться в чатиках (божемой, это вообще одно из самых сложных - выпнуть стажера в общий чат задавать вопросы!), разбираются кто есть кто в команде, начинают понимать в какую сторону им хочется двигаться. Процесс адаптации еще не закончен, но дальше он уже идет по индивидуальному сценарию.

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

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

 Какие выводы я сделала при подготовке джуниоров к суровой жизни большого IT проекта:

  • Для облегчения жизни нужен портал с базой знаний и презентация с выжимками из этого портала, а так же с описанием первых шагов;
  • Некоторых приходится заставлять задавать вопросы в общих чатах или в личных сообщениях коллегам. Новенькие часто боятся спросить о чем-то нелепом, стесняются показаться глупыми. Приходится как малышей толкать их поиграть с друзьями. Иногда я объясняю взрослым людям, что если кто-то посчитал их глупым из-за вопроса или ошибки, то это проблема того человека, раз он не помнит как это, прийти на новый проект.

© 2019 YU-GO.RU