Як правильно передавати та приймати знання щодо проєкту: що важливо знати бізнес-аналітикам

Бізнес-аналітики час від часу приймають існуючі проєкти від колег і самі передають їх іншим. Так відбувається регулярно. І от, що я помітила: інколи фахівці мало приділяють увагу цьому процесу, хоча він дуже важливий. Від доступності та повноти 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 від промахів у комунікації.

Опишіть команду вашого проєкту, вказуючи особливості конкретних спеціалістів. Зазвичай усі кажуть, що розробники класні і профі у своїй справі. Але все ж таки не полінуйтеся додати нюанси. Можливо, хтось потребує особливого підходу у спілкуванні, у вибудовуванні робочих процесів, може, комусь треба більше стороннього контролю в роботі. Ці знання допоможуть аналітику уникнути непорозуміння з колегами.

Як приймати знання про проєкт

Новачку доведеться поринути у всю наявну інформацію. Щоб полегшити читання даних, раджу спробувати такі прийоми:

• Step by step approach

Покроковий підхід помітно покращує розуміння проєкту. І цей принцип гідний окремої розповіді, тож про нього окремо поговоримо далі.

• Нотатки

Робіть для себе короткі записи про основні фічі проєкту та цікаві деталі. Вони можуть заощадити багато часу на обході всієї 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 не є чимось складним. Правильно налаштувавши цей процес, усе відбудеться досить легко — як для аналітика, який передає знання, так і для колеги, який їх приймає. Зрештою, ваша ефективна взаємодія добре позначиться на самому проєкті.