На каждом проекте, рано или поздно, наступает момент, когда появляется необходимость ввести в команду аналитиков еще одного сотрудника. И, если появилась данная необходимость, значит команда аналитиков либо уже не справляется с объемом работы, либо не будет справляться с ним в ближайшее время. Чтобы новый сотрудник начал как можно быстрее забирать на себя часть задач по анализу, необходимо ввести его в проект. Конечно, в каждом проекте есть свои тонкости и нюансы — знание их и специфика работы с ними придет со временем и после погружения в проект. На начальном же этапе знакомства с проектом, документацией, жизненным циклом задач и работой команды можно придерживаться разработанного «Чек-листа онбординга системного аналитика». Он позволит максимально быстро и без лишних вопросов провести онбординг нового системного аналитика.

Откуда взялась проблема?

При приеме нового сотрудника в компании существует стандартный предонбординг и сам онбординг для всех новичков, разработанный HR-специалистами. В нем есть все необходимые шаги для начала работы и расписаны активности на первые пару-тройку дней.

• Список документов для оформления и адрес офиса.

• Анонс первого рабочего дня (тезисно, что ждет новичка в первый день).

• Получить учетную запись, технику и ПО.

• Посмотреть welcome-видео.

• Вступить в корпоративные чаты и каналы.

• Познакомиться с начальником и командой

• Узнать, что такое таймшиты и как их правильно заполнять

• Пройти обучение по охране труда и курс по информационной безопасности.

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

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

Как показала практика, все задаваемые вопросы можно разбить на несколько групп: кто ответственный, как это сделать, когда делать, где делать и главный вопрос — зачем.

Онбординг для аналитика с помощью 5W

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

Требование — это основной, хотя и не единственный, документ, создаваемый аналитиком, он является артефактом. При его создании аналитику важно помнить о пяти вопросах, на которые должны быть получены четкие ответы: «Как?», «Где?», «Когда?», «Кто?» и «Зачем?». В основу модели Шеррингтона 5W заложены пять вопросов, ответы на которые дают понимание целей и интересов:

• «Кто?» — кто пользователь продукта;

• «Как?» — как будут использовать продукт;

• «Когда?» — когда будут использовать продукт;

• «Где?» — где будут использовать продукт;

• «Зачем?» — зачем будут использовать продукт, какая цель будет достигнута.

Если ответить на эти вопросы, поменяв слово «продукт» на интересующую сущность, можно структурировать предполагаемые вопросы нового сотрудника при онбординге. Это сократит время на погружение в проект и уменьшит вероятность возврата к «уже решенному» вопросу.

Собрав всю нужную информацию в таблицу и применив для каждого пункта 5W-вопросы, мы получили «Чек-лист онбординга системного аналитика», который предназначен для более полного и быстрого старта новичка на проекте.

И не только для новичка

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

Рассмотрим пример, который покажет возможность структурированного рассказа ментора по одному из пунктов. Возьмем пункт «Версионность требований» и построим рассказ согласно пунктам таблицы.

ГДЕ? Версионность организована непосредственно в артефакте, который находится в пространстве знаний confluence, через макрос UI Expand. Версионность требований ведется в каждом документе.

КАК? Все данные версии собраны в таблицу. Сами изменения в документации выделяются отдельным цветом, таким же цветом и сама версия документа в макросе. Для каждой новой версии присваивается порядковый номер. Применяется преимущественно сквозная нумерация. Если в рамках одной задачи были произведены несколько поэтапных изменений, согласованных с заказчиком, то возможно применение подверсий. Указывается также и дата изменения в рамках текущей версии.

КОГДА? Новая версия документа создается ВСЕГДА, если необходимо изменение этого артефакта согласно текущей задаче. Если необходимо выполнять изменения документации параллельно в нескольких задачах, то указывается версия к каждому изменению позадачно и задается цвет, отличный от остальных используемых цветов в документе, соответствующий определенной версии изменения.

КТО? Человек, внесший изменения, в рамках новой версии указывается в графе «Аналитик». Также указывается лицо, инициирующее изменение (PO, Архитектор и т.д.), в графе «Инициатор». Аналитик и Инициатор указываются через @, что позволяет системе самой подсказать написание имени, сгенерируется ссылка на профиль пользователя. Пользователь получит на почту сообщение со ссылкой на страницу, где его упомянули.

ЗАЧЕМ? Версионность требований показывает историю изменений артефакта: указывается задача, в рамках которой были внесены изменения и кратко описываются ключевые изменения. Для согласования изменений, в рамках конкретной задачи, указывается номер версии артефакта.

Часто упускается рассказ про возможность использования разных цветов при одновременном изменении документации в рамках нескольких задач. Ситуация, когда два аналитика вносят изменения в документацию синим цветом, может увеличить время на изучение документации или вообще приведет к ошибкам со стороны разработки и тестирования. Применение 5W в рассказе о создаваемом артефакте или его изменении позволяет сделать информацию более полной и упомянуть те нюансы, которые обычно упускаются при первом рассказе, вызывая затруднения при работе в дальнейшем.

Подведем итог

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

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

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