Чек-лист онбординга системного аналитика
На каждом проекте, рано или поздно, наступает момент, когда появляется необходимость ввести в команду аналитиков еще одного сотрудника. И, если появилась данная необходимость, значит команда аналитиков либо уже не справляется с объемом работы, либо не будет справляться с ним в ближайшее время. Чтобы новый сотрудник начал как можно быстрее забирать на себя часть задач по анализу, необходимо ввести его в проект. Конечно, в каждом проекте есть свои тонкости и нюансы — знание их и специфика работы с ними придет со временем и после погружения в проект. На начальном же этапе знакомства с проектом, документацией, жизненным циклом задач и работой команды можно придерживаться разработанного «Чек-листа онбординга системного аналитика». Он позволит максимально быстро и без лишних вопросов провести онбординг нового системного аналитика.
Откуда взялась проблема?
При приеме нового сотрудника в компании существует стандартный предонбординг и сам онбординг для всех новичков, разработанный HR-специалистами. В нем есть все необходимые шаги для начала работы и расписаны активности на первые пару-тройку дней.
Список документов для оформления и адрес офиса.
Анонс первого рабочего дня (тезисно, что ждет новичка в первый день).
Получить учетную запись, технику и ПО.
Посмотреть welcome-видео.
Вступить в корпоративные чаты и каналы.
Познакомиться с начальником и командой
Узнать, что такое таймшиты и как их правильно заполнять
Пройти обучение по охране труда и курс по информационной безопасности.
Даже при прохождении этих шагов возникает масса вопросов. Где получить технику, получить учетную запись, пройти обучение? Кто выдаст технику, добавит в чаты и каналы, расскажет про таймшиты? Когда проходить обучение и заполнять таймшиты? Зачем нужны таймшиты, чаты и каналы? И так далее. Отвечая на эти вопросы, наставник тратит много времени и сил. Порой вопросы повторяются, что приводит еще к большему дискомфорту со стороны как ментора, так и со стороны нового сотрудника. Когда заканчиваются общекорпоративные активности, начинается часть онбординга внутри проекта — изучение структуры документации. Рассказать про проект, документацию, процессы в команде сложно, а предположить возможные вопросы вообще нереально.
Часто бывает, что не вся информация была выдана или не все вопросы были заданы по одному из пунктов, что приводит к неполному пониманию того или иного процесса или действия. Когда это непонимание начинает мешать работе, то приходится возвращаться к, как казалось, уже решенному вопросу. Это опять создает дискомфорт для обеих сторон онбординга и тормозит сам процесс.
Как показала практика, все задаваемые вопросы можно разбить на несколько групп: кто ответственный, как это сделать, когда делать, где делать и главный вопрос — зачем.
Онбординг для аналитика с помощью 5W
Возьмем во внимание главные задачи системного аналитика: сбор, анализ, формализация и согласование требований к системе. Другими словами, управление требованиями на протяжении всего их жизненного цикла.
Требование — это основной, хотя и не единственный, документ, создаваемый аналитиком, он является артефактом. При его создании аналитику важно помнить о пяти вопросах, на которые должны быть получены четкие ответы: «Как?», «Где?», «Когда?», «Кто?» и «Зачем?». В основу модели Шеррингтона 5W заложены пять вопросов, ответы на которые дают понимание целей и интересов:
«Кто?» — кто пользователь продукта;
«Как?» — как будут использовать продукт;
«Когда?» — когда будут использовать продукт;
«Где?» — где будут использовать продукт;
«Зачем?» — зачем будут использовать продукт, какая цель будет достигнута.
Если ответить на эти вопросы, поменяв слово «продукт» на интересующую сущность, можно структурировать предполагаемые вопросы нового сотрудника при онбординге. Это сократит время на погружение в проект и уменьшит вероятность возврата к «уже решенному» вопросу.
Собрав всю нужную информацию в таблицу и применив для каждого пункта 5W-вопросы, мы получили «Чек-лист онбординга системного аналитика», который предназначен для более полного и быстрого старта новичка на проекте.
# | Вопрос | Как? | Где? | Когда? | Кто? | Зачем? |
1 | Рабочая техника | Как получить | Где получить | Когда получить | Кто выдает | Зачем нужна та или иная техника |
2 | Формат работы (офис/гибрид/удаленный). Если в офисе | Как организован доступ в офис | Где получить ключ-доступ | Когда работает офис | Кто выдает ключ-доступ | Зачем заранее предупреждать, если тебе нужно в нерабочее время в офис |
3 | Получение доступов к системам для внутреннего использования (Confluence, JIRA, HelpMe, Почта, REdmine) | Как получить | Где оформить заявку | Когда ждать доступ | Кто должен запросить доступ (сотрудник или руководитель) | Зачем та или иная платформа? |
4 | Пройти обучение по технике безопасности | Как пройти (он-лайн или офф-лайн) | Где будет информация | Когда, в какой срок необходимо | Кто ответственный | Зачем это нужно |
5 | Пройти обучение по информационной безопасности | Как пройти (он-лайн или офф-лайн) | Где будет информация | Когда, в какой срок необходимо | Кто ответственный | Зачем это нужно |
6 | Коммуникации | Как и какие чаты и каналы существуют | Где происходит внутрикомандное общение | Когда и какие вопросы можно решать через чаты | Кто ответственный | Зачем они нужны |
7 | Заведение учетных записей на отдельных окружениях продукта (Среда тестирования, Продуктивная среда, Платформа для дизайнеров, Система логирования и т.д.) | Как получить | Где оформить заявку | Когда ждать доступ | Кто должен запросить доступ (сотрудник или руководитель) | Зачем та или иная платформа |
8 | Метод управления проектом (Scrum/ Kanban/ Waterfall / другое) и принятые в команде церемонии | Как работает команда (какой метод управления проектом) | Где отражены основные манифесты | Когда проводятся основные встречи | Кто проводит встречи и как они построены | Зачем и почему такой порядок действий в данной методологии |
9 | Глоссарий (Принятая терминология проекта и продукта) | Как используется | Где расположен | Когда дополняется | Кто изменяет | Зачем трассируется |
10 | Эксплуатационная документация/Руководство пользователя | Как и для кого применяется | Где расположена | Когда дополняется | Кто изменяет | Зачем актуализируется |
11 | Описание интеграций (Спецификации API, процессы и потоки данных) | Какой формат имеет | Где расположен | Когда используется | Кто ответственный за написание | Зачем трассируется |
12 | Документация требований (User Story, Use Case, Mind Maps, Макеты, Прототипы) | Как или какой формат применим для проекта | Где шаблоны и примеры | Когда данный формат не применим | Кто проводит ревью | Зачем или почему выбран данный формат |
12.1 | Версионность требований | Как и какой порядок | Где отражается | Когда присваивается новая версия | Кто создает новую версия | Зачем нужна |
12.2 | Трассировка требований | Как осуществляется (ссылки, requirements и т.д.) | Где используется | Когда не используется | Кто пользуется | Зачем нужна |
12.3 | Содержание требований: макеты | Как связаны (изображения, ссылки и т.д.) | Где используется | Когда не используется | Кто ответственный | Зачем и как заказать макет |
12.4 | Содержание требований: тест-кейсы | Как связаны (ссылки, requirement и т.д.) | Где расположены | Когда используются | Кто ответственный за написание | Зачем и как проводится тестирование (ручное или авто) |
12.5 | Этапы согласования требований | Как осуществляется | Где отражается отметка о согласовании | Когда нет необходимости в согласовании | Кто согласует | Зачем и кто за кем согласует |
13 | Уровень участия в тестировании, демонстрации продукта, обучении пользователей и решении проблем в работе продукта | Как и какой объем дополнительной деятельности возложен на аналитика | Где, на каких платформах происходят данные виды деятельности | Когда необходима данная деятельность от аналитика | Кто определяет необходимость вовлечения в ту или иную работу аналитика | Зачем и почему нужна данная деятельность от аналитика |
И не только для новичка
Применять таблицу в виде чек-листа при онбординге со стороны новичка удобно и практично. Собранные воедино вопросы по всем основным пунктам позволяют получить максимально полную информацию. Также эту таблицу может использовать наставник при рассказе о проекте, документации и необходимых активностях со стороны аналитика.
Рассмотрим пример, который покажет возможность структурированного рассказа ментора по одному из пунктов. Возьмем пункт «Версионность требований» и построим рассказ согласно пунктам таблицы.
ГДЕ? Версионность организована непосредственно в артефакте, который находится в пространстве знаний confluence, через макрос UI Expand. Версионность требований ведется в каждом документе.
КАК? Все данные версии собраны в таблицу. Сами изменения в документации выделяются отдельным цветом, таким же цветом и сама версия документа в макросе. Для каждой новой версии присваивается порядковый номер. Применяется преимущественно сквозная нумерация. Если в рамках одной задачи были произведены несколько поэтапных изменений, согласованных с заказчиком, то возможно применение подверсий. Указывается также и дата изменения в рамках текущей версии.
КОГДА? Новая версия документа создается ВСЕГДА, если необходимо изменение этого артефакта согласно текущей задаче. Если необходимо выполнять изменения документации параллельно в нескольких задачах, то указывается версия к каждому изменению позадачно и задается цвет, отличный от остальных используемых цветов в документе, соответствующий определенной версии изменения.
КТО? Человек, внесший изменения, в рамках новой версии указывается в графе »Аналитик». Также указывается лицо, инициирующее изменение (PO, Архитектор и т.д.), в графе »Инициатор». Аналитик и Инициатор указываются через @, что позволяет системе самой подсказать написание имени, сгенерируется ссылка на профиль пользователя. Пользователь получит на почту сообщение со ссылкой на страницу, где его упомянули.
ЗАЧЕМ? Версионность требований показывает историю изменений артефакта: указывается задача, в рамках которой были внесены изменения и кратко описываются ключевые изменения. Для согласования изменений, в рамках конкретной задачи, указывается номер версии артефакта.
Часто упускается рассказ про возможность использования разных цветов при одновременном изменении документации в рамках нескольких задач. Ситуация, когда два аналитика вносят изменения в документацию синим цветом, может увеличить время на изучение документации или вообще приведет к ошибкам со стороны разработки и тестирования. Применение 5W в рассказе о создаваемом артефакте или его изменении позволяет сделать информацию более полной и упомянуть те нюансы, которые обычно упускаются при первом рассказе, вызывая затруднения при работе в дальнейшем.
Подведем итог
Все пункты, к которым заданы вопросы, разбиты на две группы: первая отвечает за общую документацию и организацию рабочего процесса в команде. Вторая относится непосредственно к документации, создаваемой аналитиками. Каждая из двух групп так или иначе влияет на создаваемый артефакт.
При включении нового сотрудника в команду или проект и при знакомстве с продуктом очень важно, чтобы это произошло менее болезненно и для новичка, и для того сотрудника, который будет обучать нового члена команды. Возврат к вопросам, которые уже обсуждали, пункты, по которым нет окончательного понимания, и неполный перечень всех этапов увеличивает продолжительность онбординга нового сотрудника и требует больше времени на обучение со стороны ментора. Придерживаясь этого чек-листа, можно сократить энергозатраты куратора, а также уменьшить время ознакомления нового аналитика с организацией работы, задачами и проектом в целом.
В таблице перечислены основные, базисные, пункты, на которые следует обратить внимание. При адаптации чек-листа под разные проекты ее можно дополнять и расширять.
