Как правильно передавать и принимать знания по проекту: что важно знать бизнес-аналитикам

Бизнес-аналитики иногда принимают существующие проекты от коллег и сами передают их другим. Это происходит регулярно. И вот что я заметила: иногда специалисты мало уделяют внимание этому процессу, хотя он очень важен. От доступности и полноты Knowledge Transfer зависит скорость вхождения в незнакомый проект любого BA.

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

Что такое Knowledge Transfer

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

• Общая информация о проекте

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

• Стейкхолдеры

Опишите, кто эти люди и чем занимаются на проекте, какие у них полномочия, какие правила взаимодействия с ними и эскалации, к кому обращаться по тем или иным вопросам. Также укажите каналы коммуникации (email, Slack, Telegram и т.д.) и расписание митингов (как часто с кем конкретно из стейкхолдеров, в каком формате).

Если стейкхолдеров на проекте много, непременно распишите их роли и дела между собой: от порядка утверждения изменений до возможных личных характеристик. Здесь пригодится создание Stakeholder Communication Plan или матрицы RACI.

• Менеджмент требований

Разберите структуру по существующим в проекте требованиям. Укажите, в каком формате вы описываете, какой должна быть структура требований, как проходит процесс их утверждения. Полезными будут и разные наблюдения по работе с заказчиком по этим вопросам. Например, какие подходы ему понравились, а какие нет. Или поделитесь, насколько стоит ему доверять при внесении изменений, чтобы потом не объяснять клиенту в стиле «вы же сами захотели это изменить». В идеале — составьте схему, как нужно обрабатывать запросы на изменения утвержденных требований.

• Описание требований

Это могут быть Feature List, SRS (software requirements specification) и любые другие документы, созданные, как правило, предыдущим BA. Подробное изучение этих материалов очень важно. Ведь при знакомстве с проектом новый аналитик с его «чистым сознанием» может сразу заметить недостатки и хорошие подходы в выборе и описании требований, которые должны решить проблемы бизнеса. Это позволит дополнительно оптимизировать проект.

Что важно знать новому ВА о проекте

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

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

Также важно передать все доступы:

• Requirements — системы по типу Confluence, Jira и другие, где эти требования соблюдаются.
• Дополнительные знания — это Google Docs, файлы и документы проекта в облачном хранилище.
• Дизайн — дайте новичку доступ к сервису, где вы храните мокапы, чтобы он взглянул на дизайн.
• Платформы управления проектом — доски типа Trello, ASANA, ClickUp и т.д.
• Проект — кредиты к dev и prod или ссылка на приложение позволят аналитику самому испытать продукт, пощелкать кнопки в интерфейсе, лучше понять, как работает система.

Расскажите о клиенте, его характере и о том, как вам вместе работалось. Это поможет новому специалисту быстрее найти подход к человеку. Это описание можно сделать в произвольной форме: строгий ли клиент, сколько времени уделяет проекту, скрупулезный ли он и т.д. Еще следует указать желаемый формат общения. К примеру, клиент может редко отвечать на email, поэтому ему лучше писать только в Slack — так будет быстрее. Такие простые подсказки уберегут нового BA от промахов в коммуникации.

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

Как принимать знания о проекте

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

• Пошаговый подход

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

• Заметки

Делайте для себя краткие записи об основных фичах проекта и интересных деталях. Они могут сэкономить много времени на обходе всей SRS в поисках важных нюансов.

• Диаграммы

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

• Ссылки

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

• Особенно важный момент в процессе вхождения в проект — узнать о заказчике

Конечно, интересно узнать от предыдущего аналитика, какой человек клиент. Но учтите, что это будет субъективное мнение. Возможно, определенное поведение заказчика связано с его отношением к конкретному BA и вами все будет иначе.

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

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

Почему мне так нравится Step by step approach

Этот метод я успешно опробовала уже на нескольких Knowledge Transfers. В чем суть: вы разбиваете проект на взаимосвязанные блоки, которые можно рассматривать отдельно. Новый аналитик по каждому такому блоку проходит три этапа:

1. Изучение требований с чтением SRS, тикетов в Jira и других материалов.
2. Подготовка вопросов по всем не до конца понятным моментам.
3. Митинг-ревью по всем требованиям с аналитиком, передающим проект.

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

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

В книге Анатолия Левенчука «Системное мышление» я прочла о таком понятии, как метаноя. Оно означает изменение мыслей и свидетельствует о свойстве прохождения порога понимания.

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

Поначалу все смотрится логично. Но полноценная картинка у вас в голове еще не складывается. И это нормально. Понимание информации появляется позже, когда вы подробно знакомитесь с продуктом. Вы начинаете задавать вопросы коллегам, хотя в начале на них вам вроде бы отвечали. Просто в тот момент у вас еще не настал порог понимания проекта. Поэтому очень важно придерживаться принципа Step by step approach.

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

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

Принцип Step by step approach в реальных проектах

Недавно я передавала коллеге один средний по размеру проект из нескольких частей: сайт, админка и онлайн-магазин. Сайт был небольшим, и я поручила новой BA изучить требования к нему:

• в результате аналиткиня просмотрела сайт, глянула на все разделы, просмотрела SRS и тикеты в Jira, а затем подготовила вопросы;
• далее мы прошли вместе по всему сайту, как демо;
• по такому же сценарию прошлись и с админчастью, и с онлайн-магазином.

В общей сложности Knowledge Transfer занял около полуторы недели, что довольно быстро. На масштабных проектах экономия времени может быть еще больше. Той же коллеге я передавала большой сайт с множеством частей и блоков: Оплата, Поиск, Мой профиль и т.д. BA шла тем же путем, что и в прошлый раз. В итоге передача знаний шла две недели. Хотя я в свое время потратила на изучение и понимание этого проекта почти месяц. А все потому, что я никак не могла разобраться во всех деталях. Мне приходилось снова и снова возвращаться в Knowledge Transfer и перечитывать отдельные моменты по два-три раза.

Хочу подчеркнуть личные впечатления коллеги после нашего сотрудничества. По ее словам, Knowledge Transfer был безболезненным, лишенным стресса. Вся информация подавалась дозировано. По каждому функционалу мы проводили Q&A-сессии, во время которых она могла разобраться, что было сделано в определенном блоке, почему именно так, что система делает в конкретном месте и как она не должна делать. Отдельно аналиткиня отметила пользу диаграмм даже при наличии требований. Составление схемы упрощало понимание процессов.

У нее сложилось ощущение, будто она сама участвовала в написании требований. А это совсем другой, более качественный уровень восприятия проекта.

Понятно, что я использую Step by step approach и в обратных ситуациях — когда сама принимаю Knowledge Transfer. Недавно я зашла в большой проект, который длится уже больше года. Пошаговое изучение блоков помогло мне быстрее сориентироваться и разобраться во всем. Также была полезна запись онбординга. При необходимости восстановить в памяти какие-то моменты, я не бежала к кому-то в команде с вопросами, а просматривала видео и сама находила нужную информацию. Это сэкономило время и силы.

Распространенные ошибки в процессе Knowledge Transfer

На основе собственного опыта я выделила несколько типичных ошибок, которые следует избегать бизнес-аналитикам:

• Knowledge Transfer за один подход

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

• Отсутствие Stakeholder Communication Plan и Requirements Management Plan

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

• Выборочное чтение требований

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

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

Вместо вывода

Как видите, Knowledge Transfer — не что-то сложное. Правильно настроив этот процесс, все произойдет достаточно легко — как для аналитика, передающего знания, так и для принимающего коллеги. В конце концов ваше эффективное взаимодействие хорошо скажется на самом проекте.