Здоров, я — Любік Кислюк, Lens production manager у Snap Inc. До Snap працював на посаді COO в Robosoft industries, а також head of BA в Adtelligent. За 3 роки в IT я багато косячив сам і бачив, як косячать інші, будучи як виконавцем, так і замовником. До сьогоднішніх порад додав офігенні кейси зі своєї практики про те, чому так робити НЕ ТРЕБА! Запасайтеся міцними напоями й погнали!
Як не треба працювати зі стейкхолдерами й командою
Де б ви не працювали й чим би не займалися — скрізь є люди, з якими потрібно взаємодіяти, й від налагодженої комунікації з якими залежить дуже багато: продуктивність, подальша співпраця, рейтинг вашої компанії на ринку. Зараз розповім, як максимально швидко справити негативне враження в очах усіх цих людей.
1. Не погоджуйте вимоги із замовником
Ви розумієте, що хоче замовник краще за нього самого — до чого додаткові мітинги?
Щоб замовник співпрацював з вашою командою максимально довго, потрібно дотримуватися наступної послідовності: спочатку клієнт вам озвучує свою «хотілку», ви як аналітик розробляєте бізнес-вимоги, обговорюєте їх із командою розробки й перш ніж брати ці вимоги до роботи, утверджуєте те, що ви розробили із замовником. Дехто нехтує цим простим правилом.
Я сам, бувало, грішив цим на початкових етапах, коли не вистачало часу або здавалося, що я все розумію до кінця, і це саме те, чого хоче замовник. Насправді важливо, щоб замовник сам підписався під тим, що далі йтиме в роботу.
Запам’ятовуйте все на слух, вірте у свою пам’ять!
Дуже хороший інструмент, який я раджу своїм студентам і стажерам для фіксування вимог – це диктофон. Він не раз мене рятував, причому в різних контекстах і ситуаціях. Диктофон допомагає вирішити три задачі:
- Ви нічого не проґавите. Бувають такі випадки, коли стейкхолдер може бути невловимим або говорити не зовсім зрозумілою мовою, тому не завжди вдається вловлювати його думки на льоту.
- Ви не перепитуватимете по 10 разів, якщо ще не встигли вникнути в термінологію та контекст нового проєкту. Досить просто записати на диктофон усі думки й побажання стейкхолдера, а далі, скориставшись базою знань чи допомогою інших фахівців, якось розшифрувати те, що він мав на увазі.
- Якщо людина надалі почне відмовлятися від своїх слів, ви матимете доказ зворотного. Таке теж іноді трапляється, причому не через те, що замовник хоче повередувати, а через те, що він справді міг забути.
Жодного разу в моїй практиці ніхто не відмовлявся від запису слів на диктофон, навпаки, всі люди охоче погоджувалися. Головне — правильно подати використання цього інструменту, мотивуючи тим, що записуєте не для того, щоб усе, що скаже замовник, було використано проти нього в суді, а щоб нічого не проґавити й розробити вимоги швидше і якісніше.
Не варто щоразу запитувати: «Чи можна записувати вас». Ви, як правило, працюватимете в рамках компанії досить довго й достатньо лише один раз сказати: «Давайте для того, щоб я нічого не упустив, і щоб вимоги були розроблені краще, запишу це на диктофон».
2. Зберігайте майбутню реалізацію в таємниці від технічної команди
Поводьтеся як експерт у всіх технічних нюансах, а команді ставте будь-які цілі – вивезуть. Якщо не впораються – треба міняти команду.
Якщо ви плануєте стати авторитетом і полегшити життя команді, перш ніж затверджувати бізнес-вимоги із замовником, потрібно отримати підтвердження команди про те, чи можливо це реалізувати в принципі, й якщо так, то які ресурси для цього будуть потрібні. Тільки після цього можна йти до стейкхолдера й надавати реалістичний естімейт.
Якщо ви відразу чуєте від замовника відверту нісенітницю (розробити ракету за $10) і розумієте, що це неможливо реалізувати, говоріть про це вже на етапі обговорення.
Коли ви не впевнені в тому, чи можливо реалізувати запит чи ні, важливо уточнити, що ці тонкощі вам потрібно обговорити з технічним лідом або будь-яким іншим менеджером, який керує розробкою даного продукту.
Після того, як ви затверджуєте з техлідом, що це можливо зробити, можна давати відповідь замовнику про те, в якому вигляді й в рамках якого бюджету ви готові розробляти функціонал.
3. Кому потрібна оптимізація процесу взаємодії з командою та замовником. Нудно!
Все, що об’єднує команду й замовника – ви, їхній вірний товариш бізнес-аналітик! Якщо всіх перезнайомити, можуть вирішити, що ви — зайвий менеджерський прошарок.
Взаємодія з командою та замовником має бути постійною та безперервною. Якщо замовник внутрішньої і він доданий у ваш task tracker, то можна додати додаткову функцію, яка проставляє апрув.
У моїй практиці на одному з проєктів використали jira й у нас був stakeholder, який хотів, щоб без його згоди жоден ticket не проходив. Ми поставили на дошці ticket, що статус ставки «need username approve». Йому щоранку приходив список із цих ticket-ів, він їх переглядав й апрувив або деклайнив. Досить ефективний механізм, у нас він добре себе проявив.
Ще один можливий варіант — це коментар із твердженням від замовника в документі з вимогами.
Мені зручно розробляти вимоги в гуглодоках, хтось робить це у Confluence чи Quip, питання смаку. Якщо вирішите працювати з гуглодоками — досить просто надати всім зацікавленим особам доступ на коментування і після того, як замовнику все подобається, він може в заголовку документа писати, що затверджує вимоги. Зазвичай цього достатньо, щоб пустити їх у роботу.
Якщо ви, скажімо, використовуєте паперову документацію, таке теж іноді зустрічається, то апрувом буде класичний підпис на папері. Людина підписується під тим, що вона замовляла.
Важливо збирати питання технічної команди та відповідати на них.
Один із варіантів механізму комунікації — доступ на коментування в документ, що розробляється. Це також може бути якийсь регламентований мітинг, коли ви щотижня збираєтеся для того, щоб прогрумити ті вимоги, які збираєтеся затверджувати.
Під час розробки вимог я рекомендував би надати доступ на коментування хоча б ліду, щоб він відразу запитував про те, як ви описуєте якісь речі, які можуть бути не до кінця зрозумілі й команді розробки. Відповідаючи на питання, вони, по-перше, можуть зробити якісь пропозиції більш оптимальними, ніж ті, які ви описуєте, або сказати, можливо це реалізувати чи ні — словом, дати інформацію, яку ви далі транслюватимете на замовника.
Але, як правило, мітинги займають якийсь час — це ресурси, гроші, а глянути одній людині пробігтися документом протягом 15-20 хвилин і відразу відсікти якісь грубі помилки або можливість/неможливість реалізації, як мені підказує практика, досить ефективно.
Збирайте фідбек від команди про канали комунікації та механізми взаємодії.
Вислуховуйте пропозиції та приймайте те, що може покращити комунікацію, прискорити процес або знизити витрати (прибрати зайвий крок із флоу, додати чи прибрати якийсь мітинг). Люди, як правило, дуже охоче дають якісь пропозиції та краще відгукуються надалі, якщо ви ці пропозиції слухаєте, приймаєте й застосовуєте.
4. Аналізуйте ринок лише на етапі ініціації проєкту
Якщо постійно аналізувати ринок і конкурентів — коли працювати?
Часта помилка бізнес-аналітиків — робити конкурентний аналіз на довготривалих проєктах лише один раз, на етапі ініціації. Важливо аналізувати конкурентів хоча б раз у якийсь період, все залежить від домену, в якому ви працюєте. Якщо це якийсь mobile gamedev, то конкурентний аналіз потрібен практично перманентно й постійно. Якщо ви розробляєте фінансові інструменти або якісь довготриваліші продукти — потрібно проводити аналіз хоча б раз на півроку.
Коли хлопці, з якими я працював, захотіли розробляти один продукт у 2018 році, ми зробили конкурентний аналіз і зрозуміли, що на ринку не вистачає якихось фіч, і ми порвемо ринок, якщо зайдемо з цими фічами. Потім відволіклися на розробку інших продуктів і через вісім місяців вирішили повернутися до розробки цього продукту. Всі тішили себе думкою про те, що рік тому ніхто нічого не мав, зараз ми залетимо на ринок і будемо в шоколаді.
Я виявив ініціативу, вирішив повторно зробити конкурентний аналіз і виявив, що всі ці фічі, про які була розмова рік тому, у двох конкурентів уже реалізовані, у тому чи іншому вигляді. Якби я не зробив аналіз, то кілька місяців розробки зійшли б нанівець.
Чи повинен BA займатися конкурентним аналізом, залежить від того, яка роль бізнес-аналітиків у даному проєкті чи продукті. Якщо замовник гарний у своєму домені й постійно тримає руку на пульсі, аналітик не повинен робити подвійну роботу. А якщо замовник, скажімо, хоче щось, але при цьому не супер круто орієнтується в ринку, то аналітик повинен як мінімум виділити основних гравців і раз у якийсь час хоча б просто заглядати на їх сайт, стрічку новин і стежити за контентом.
Інструменти й ресурси для аналізу дуже прості – конкуренти вам самі про все розкажуть. Заходьте на їхній блог і дивіться хронологію того, що вони викочували і коли. Якщо ж ми говоримо про якісь вже програмні продукти, то конкурентний аналіз — це як мінімум:
- аналіз трафіку на веб-сайт;
- B2C — елементарно зареєструватися на платформі або продукті конкурента і скористатися ним — це вже є бізнес-аналіз;
- B2B — промислове шпигунство. Конкурент сам все розповість, якщо сприйматиме вас як потенційного клієнта.
Я сам одного разу проводив B2B шпигунство, коли значну кількість часу розвивав один майданчик для того, щоб через нього поспілкуватися з конкурентами та скористатися їх технічним рішенням. Це дало чимало плодів. B2B сегмент сам по собі складніший і промислове шпигунство там серйозніше. Потрібно мати мало не цілий відділ чи хоча б кількох людей, які займатимуться якимись проєктами, і зможуть бути клієнтами конкурентів.
Ще один інструмент промислового шпигунства — поїздка на виставки, де представники компаній дуже багато розповідають про себе, вам досить просто відправити туди людину, яка зіграє роль потенційного клієнта. Звичайно, не кожен конкурент розповість казна-кому, які в проєкті кілер фічі, поки не підписав контракт, але, проте, це теж працює.
Як не розробляти вимоги
5. Можна наплювати на швидкість на користь якості
Перфекціонізм понад усе! Доводьте до ідеалу вимоги будь-якого запиту, навіть якщо на це потрібно 20 років!
Іноді «молоді» аналітики намагаються розробляти вимоги дуже скрупульозно не там, де це потрібно й не враховують, що ринок змінюється щохвилини.
Наведу приклад зі своєї практики, коли команда дуже багато часу витратила на розробку досить стандартного функціоналу реєстрації логіна. Його вимоги розтягнулися на 20 сторінок, де описали практично все, що можна було описати в природі, хоча, насправді, потрібно було сконцентруватися на ядрі проєкту, а цей функціонал просто реалізувати стандартно й по ходу наступних ітерацій його доопрацьовувати. Тут важливо оцінити кількість наданого часу й важливості якості при розробці вимог щодо аналогії з розробкою продукту.
6. Не пріоритезуйте беклог
Ви повинні відчути серцем, яке завдання найважливіше.
При формуванні беклога важливо розуміти, що він повинен бути більшим, ніж на одну ітерацію, тому що можуть змінитися пріоритети або фіча просто виявиться непотрібною і виникне недовантаження команди.
Замовник буде дуже незадоволений, тому що найдорожче, що є в IT для замовника, — це вартість команди розробки, так що краще намагайтеся робити беклог більше, ніж на 1 спринт.
Бувають ситуації, коли дуже складно пріоритизувати backlog.
Я працював над продуктом і зіткнувся з ситуацією, коли замовник каже, що потрібно терміново впроваджувати щось одне, support каже, не можемо жити без чогось іншого, сейлз кричить: «Відкладай все, нам потрібно продавати клієнту щось третє!» Власник бізнесу каже: «Це все нісенітниця, давай мені роби ось це, я хочу, щоб було як у конкурентів».
Ви сидите й розумієте, що у вас backlog на два місяці й у всіх фіч максимальний пріоритет. У таких випадках є дуже корисна практика, яку я запозичив у scaled agile framework – WSJF.
WSJF (Weighted Shortest Job First) — система, яка дозволяє оцінити завдання по ряду факторів і зібрати нумерований список, на початку якого виявляться найпростіші в реалізації, але при цьому найцінніші з точки зору бізнесу задачі.
Формула WSJF = Cost of Delay / Job size, де
Cost of Delay = (Business Value + Time Criticality + Risk Reduction or Opportunity Enablement).
А тепер покомпонентно:
- Business Value (бізнес-цінність) — наскільки фіча буде корисна бізнесу та клієнту (чим більше, тим краще).
- Time Criticality (часова критичність) – завдання потрібно виконувати негайно чи можна зачекати? Наприклад, важливо випередити конкурента (що вище, тим краще).
- Risk Reduction and/or Opportunity Enablement (фактор ризику (або можливості)) — чи знижує ця фіча ризики чи, може, відкриває можливості нових ринків? (Чим вище, тим краще).
- Job duration / size (складність роботи) — технічна складність реалізації фічі (чим менше, тим краще).
Якщо у бізнесу й команди є час на оптимізацію робочого процесу, ідеальним способом застосування WSJF буде проведення спільного мітингу з командою розробки та представниками клієнта. Нехай кожна зі сторін оцінить завдання в сторі поінтах, в результаті чого сформується загальна таблиця, що складається зі стовпців: Назва фічі/ініціативи, Business Value (чим більше, тим краще), Time Criticality (чим більше, тим краще), Risk Reduction and/or Opportunity Enablement (що більше, краще), Job duration / size (що менше, краще).
Після оцінки кожної з фіч за всіма параметрами, стане зрозуміло, за яку задачу варто взятися вже завтра, а яка може почекати більше місяця.
Як не оформляти документацію
7. Не актуалізуйте документацію
Усі люблять шукати 200 відмінностей між документацією проєкту та його реалізацією.
Зараз розповім, чим може загрожувати неактуальна документація.
Я зіткнувся з ситуацією, коли забезпечував перехід від віддаленої на in-house команду. Проєкт був досить складний, розроблявся на дуже динамічному ринку й тому документація була стара.
Вийшло так, що багато пунктів у документації не актуалізували, тому що в команді не було бізнес-аналітика, просто Project Manager на етапі ініціації описав, як виглядатиме продукт, і далі нічого не актуалізував.
Коли моя команда бралася за проєкт, то між тим, що написано в документації і тим, як продукт працював насправді, була величезна різниця. Це дуже плутало всіх учасників процесу.
Підтримувати документацію у консистентному вигляді не так складно: достатньо після кожного спринту вносити зміни, що сталися за цей час. Якісь речі в документації у будь-якому випадку не будуть розроблені: щось було неможливо, якийсь функціонал змінили, але основна структура має відповідати реальності.
8. Залиште теоретикам інструменти й техніки бізнес-аналізу
Навіщо витрачати час на теорію, коли на практиці все по-іншому! Розбирайтеся по ходу діла й не обтяжуйте себе непотрібною інформацією.
Хорошому бізнес-аналітику важливо використовувати в роботі User Story, Use Case та UML діаграми (state machine діаграми, entity relationship або activity diagram), тому що вони:
- дозволяють більш складні речі описати простіше та зрозуміліше;
- допомагають описати те, що словами описати неможливо в принципі;
- дозволяють візуалізувати вимоги, тому що набагато простіше сприймати візуалізацію системи, ніж її текстовий опис.
На самому початку кар’єри мені доручили опис одного дуже складного функціоналу і я, щоб не впасти в багнюку обличчям, нормально так овертаймив, бо треба було описати функціонал у дуже стислий термін.
Я не володів інструментами, про які знаю зараз, виходить, у мене були якісь задачі, але зброї для вирішення цих задач не було. Я сидів і думав, як би описати вимоги так, щоб було зрозуміло. Пам’ятаю, сидів на роботі до ранку, обійнявши енергетики. У результаті в мене вийшли user story, опис User flow і щось на кшталт Use Case, хоча жодним із цих інструментів на той момент я не володів. З точки зору розробки вимог, я був новачком і вийшло, що сам для себе й винайшов такий кривий варіант перерахованих вище інструментів.
Коли я вивчав інструменти та вдосконалював свої навички, то зрозумів, що міг би витратити на це не ночі, а кілька годин, тому з тих пір раджу розширювати свій інструментарій. Деякими речами ви навіть не скористаєтеся, але якщо раптом зіткнетеся з якоюсь проблемою, у вас буде широкий арсенал озброєння для того, щоб її вирішити. Це насправді дуже прискорює роботу.
Що стосується інструментів візуалізації, особисто я працював з:
- Balsamiq (для вайрфреймів і простих мокапів);
- Lucidchart (для діаграм);
- Invision Studio (для складних мокапів і динамічних прототипів).
Інструментів насправді набагато більше, але на початковому етапі вам буде достатньо цих трьох.
9. Забудьте про структуру документації
Ви — художник, ви так бачите, і вам ніколи наводити красу в шрифтах і заголовках. Важлива суть, а не форма!
Якщо ви все ж таки плануєте прискорити процес розробки, документація повинна бути не тільки зрозумілою, але ще й зручною в навігації та приємною для читання. Здавалося б дрібниця, але після того, як я якийсь час уже попрацював із документацією і побачив документ свого стажера, зрозумів, що цей пункт треба винести у поради.
З погляду цінності, він описав усе правильно, а ось з точки зору форматування, на це було боляче дивитися та складно орієнтуватися. Справа не в перфекціонізмі, а в тому, що різні шрифти й різні розміри заголовків плутають, порушується порядок вкладеності та страждає логіка.
Важливо:
- розробити всі шаблони та стандарти документів з вимогами в рамках проєкту, над яким ви працюватимете;
- скласти список документів, що передбачаються на цьому проєкті;
- переконатися, що всі учасники процесу знають про те, які у проєкті є документи, на яких етапах вони розробляються і на які питання відповідають.
Наприклад, можливо, ви із замовником вирішили, що спочатку робите документ Product Vision, потім Product Requirement Document і лише після них — специфікації. Ви повідомляєте команду, й вона очікує побачити не якісь там документи, а бізнес-бачення, PRD і детальні специфікації. Вони розуміють, що нічого іншого до них не заходитиме, й це нормально.
10. Залишіть команду без доступу до документації
Вони не зможуть погано реалізувати те, про що не знають!
Переконайтеся, що у всіх учасників є необхідні доступи і права, а також чи учасники отримують вчасно потрібні повідомлення про важливі зміни.
При роботі з гуглодоками я б рекомендував відразу при створенні дока надавати доступ на коментування за посиланням у рамках компанії (тобто тільки на корпоративні пошти).
Якщо у вас нормально налагоджена комунікація із замовником, то ви вносите зміни й нагадуєте йому через особистий канал комунікації, наприклад, по телефону або в месенджери: «Я вніс зміни до вимог і мені потрібен ваш апрув».
Ви як автор документа з вимогами, повинні бути й модератором цього процесу. Запитання, на які вже відповіли, коментарі, які вже не є релевантними — видаляйте! Вони збережуться в історії коментування, а те, що було цінним у цих коментарях, вносите в тіло документа.
11. Забудьте хорошу ідею, яка спала на думку
Ви все запам’ятаєте, не варто нагромаджувати документацію!
Коли ви, наприклад, розробляєте документ під чергову ітерацію, і на думку спала ідея, реалізація якої зараз точно не увійде в скоуп, але при цьому ви розумієте, що було б непогано впровадити її в майбутньому — зафіксуйте цю ідею в рамках документації проєкту. Часто такі речі забуваються, а за кілька місяців згадуєш, що хотіли ще розробити, але конкуренти вже вас випередили й впровадження фічі більше не має сенсу. Так що для процвітання продукту варто запровадити блок із пропозиціями й ідеями від команди.
Висновки:
Щоб менше лажати, робіть висновки на основі мого досвіду.
- Узгоджуйте вимоги із замовником.
- Обговорюйте майбутню реалізацію з технічною командою у процесі розробки вимог.
- Оптимізуйте процес взаємодії з командою та замовником.
- Аналізуйте ринок і конкурентів.
- Дотримуйтесь балансу швидкість/якість.
- Пріоритезуйте беклог.
- Актуалізуйте документацію.
- Використовуйте інструменти й техніки бізнес-аналізу.
- Дотримуйтесь структури документації.
- Переконайтеся, що всі учасники мають необхідні доступи, й вони отримують вчасно потрібні повідомлення про важливі зміни.
- Введіть блок з пропозиціями й ідеями.