Як не облажатися під час discovery фази проєкту

Для багатьох з нас discovery фаза проєкту може бути представлена фразою: “Ну ж бо, давайте скоріш почнемо роботу. Навіщо витрачати час?”. Люди дають вам гроші і кажуть побудувати ракету, але куди ця ракета полетить, і чи потрібна вона нам насправді? Про це краще дізнаватися на discovery етапі проєктів.   

Мене звати Олена Гончаренко, я Senior Service Delivery Lead у Brightgrove, зараз працюю над проєктом Ada Health. Сьогодні я хочу поговорити про важливість discovery фази проєкту та про те, як зробити так, щоб ваш проєкт став на правильний шлях. Таким чином, вам не доведеться перебудовувати свою ракету перед самим злетом. 

Поширений підхід до запуску проєкту—“давайте зробимо це якнайшвидше, ми в цьому впевнені”. Очевидно, без проведення discovery фази. Незабаром це перетворюється на “о, ми вже не так в цьому впевнені”. Люди хочуть бачити результати роботи якомога швидше з різних причин. Хтось залучив інвестиційний раунд, хтось мав неприємний досвід роботи з іншими контракторами тощо. 

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

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

Ось чому discovery фаза ІТ-проєкту, створення прототипу та інтерв’ю з користувачами є критично важливими як на рівні продукту, так і на рівні проєкту. Ще одна поширена річ—ми починаємо щось робити, а потім зупиняємося на хвилину і розуміємо, що щось йде не так.   

У бізнес-аналізі є стан “як є” і стан “як буде”. Вони дають нам змогу зрозуміти, де ми знаходимося зараз і куди рухається наш проєкт. Знаючи ці дві детермінанти, ми можемо прокласти свій шлях до покращення проєкту. Це дуже важливо для управління проєктом на етапі discovery. 

Люди часто описують майбутній стан, не розуміючи, чому вони хочуть його досягти саме таким чином. Отже, яку основну проблему ми вирішуємо в нашому стані “як є”? Як часто ми ставимо під сумнів те, що ми взагалі робимо? Використовуючи, наприклад, метод “5 why”, ми могли б заощадити чимало часу.  

Загалом, ми можемо розділити людей на 2 типи: ті, хто хоче почати якомога швидше і пропустити фазу discovery проєктів, і ті, хто хоче спочатку ретельно спланувати. Як працювати з кожним з них?   

Ті, хто хоче почати якнайшвидше: задавайте їм базові питання, навіть якщо вони можуть здатися дурними: Що ми робимо? Чому ми це робимо? Що дасть нам нова функціональність? Ці речі здаються очевидними, але багато людей не беруть їх до уваги на discovery етапі проєкту.   

У кожному проєкті повинна бути хоча б одна людина, яка буде постійно задавати питання. Дуже часто, якщо в проєкті немає штатного BA, QA виконує роль того, хто задає питання. Якщо QA також відсутній—беріть ініціативу в свої руки, незважаючи на свою роль.

Якщо я знаю, що збираюся запитати щось, на що вже давно мали б відповісти, я починаю зі слів: “Послухайте, можливо, я зараз запитаю щось дурне—ви можете мені це сказати—але скажіть, чи це дійсно так?”. Зазвичай відповідь така: “Знаєш, це не дурне питання, ми про нього навіть не думали”. І ми починаємо думати над проблемою разом.

Інші варіанти “дурних” запитань для фази discovery в проєкті можуть бути такими:

• “Чи можете ви пояснити концепцію/результат так, як пояснювали б це своїм дітям?”
• Питання з нереальними межами, наприклад, “чи потрібно відчиняти двері, щоб увійти в кімнату?” або “чи можемо ми поділити щось на 0?”. Зрештою, ви можете виявити, що дверей немає або що ми не можемо ділити інші числа на 0.
• “Чи можете ви схематично пояснити, що вам потрібно”, що зазвичай означає використання дуже простої схеми. Прикладом може бути щось на кшталт кругообігу води.

Планувальники: спробуйте переключити їх з мислення “ми повинні спланувати все зараз” на мислення “ми можемо планувати поетапно”. Тоді ми зможемо спочатку виконати деякі завдання, перевірити, чи добре ми їх виконали, і перейти до наступної фази. Тут Agile є основним рішенням.   

Або використовуйте підхід KISS (keep it simple stupid). У мене був чудовий клієнт, який любив цей підхід і багато чому мене навчив. Перш ніж щось робити, він запитував: “Яке найпростіше рішення для цього?”. Таким чином, ви вирішуєте реальну проблему і перевіряєте свою гіпотезу. Далі можна працювати над доповненнями та покращеннями.

Нинішня команда провела дослідницьку фазу і оцінила 100% необхідного обсягу як кілька років розробки. Пізніше, однак, ми погодилися на MVP з обмеженою функціональністю. Крім того, MVP мав інтегровану бібліотеку, яка дозволила нам досягти очікуваних раніше результатів.

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

Такий підхід чудово працює, коли потрібно зробити щось нестандартне. Наприклад, після використання методу KISS ми часто дозволяли користувачам протестувати функцію лише для того, щоб зрозуміти, що це не те, чого вони очікували. На основі цих результатів ми могли переробити завдання, щоб покращити результат.

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

Це буде ставати легше, коли ваші стосунки з клієнтом покращуватимуться. З часом ви також зрозумієте, як краще ставити запитання. Краще дати зрозуміти на етапі discovery, що ви будете наполегливо ставити запитання, щоб переконатися, що проєкт пройде успішно.   

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

• Використовуйте активне слухання. Це означає ставити відкриті запитання, щоб заохотити до подальших відповідей, перефразовувати та обмірковувати сказане, а також слухати, щоб зрозуміти, а не відповісти. 
• Щоразу, коли у вас виникає відчуття, що щось не відповідає загальній картині, ставте уточнююче запитання. 
• Якщо вам незручно ставити запитання під час дзвінка, в якому беруть участь усі, запишіть його і поставте пізніше 1 на 1 або в чаті. Ви можете почати зі слів: “Я думав про те, що ми обговорювали / я читав свої нотатки, і у мене виникло питання…” 
• Використовуйте асинхронну комунікацію, наприклад, коментарі в документах, електронні листи тощо. 
• І найголовніше—не бійтеся запитувати. Краще запитати і отримати очевидні відповіді, ніж потім шкодувати, що не запитав. Будьте тією скалкою в дупі, бо, врешті-решт, всі будуть вам вдячні. 

Зазвичай я працюю в команді аутстафферів. Тому я звикла до того, що клієнти нехтують фазою discovery проєкту і розглядають нас як людей ззовні, які служать для того, щоб допомогти, і це все. Клієнти рідко мають протилежний погляд на нас як на повноцінних членів команди.  

Але для мене кожен проєкт, над яким я працюю,—як моя власна дитина. Тому я продумую, як зробити все найкраще, що дуже допомагає. Завжди думайте про те, що б ви зробили на місці клієнта.  

Якщо ви новачок і боїтеся виглядати нерозумно, ставлячи запитання, просто прийміть це. Правда в тому, що через багато років ви все ще можете відчувати себе дурним і недостатньо досвідченим перед тим, як поставити запитання. Ми всі люди, і всі ми можемо в чомусь помилятися. Краще попросити роз’яснення, ніж потім згадувати, коли вже занадто пізно.   

Не бійтеся помилятися—це трапляється з усіма. Важливо, які висновки ви зробите після цього.  

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

Клієнт, однак, попросив лише реалізувати те, що створили дизайнери. Ми запитали: “Гаразд, але яким ви хочете бачити свій продукт через 3 місяці?”, а відповідь була: “Я не знаю, але все буде працювати”. Ми мусили їх розчарувати, бо це було не так.  

Я не можу розповідати про суть проєкту, тому скористаюся прикладом Instagram. Клієнт хотів функцію текстових повідомлень, хоча ми говорили, що основна мета Instagram—це обмін фотографіями. Вони все одно наполягали на тому, що їм найбільше потрібен обмін повідомленнями.   

Пізніше з’ясувалося, що користувачі не хочуть писати тексти, вони хочуть публікувати фотографії. Тільки тоді ми змогли переключитися на цю функцію. Перше усвідомлення того, що щось йде не так, зазвичай відбувається після відгуків користувачів або коли ви просто бачите, що щось йде не так.   

Тут у нас є два варіанти. Перший, якщо вам пощастить,—це можливість перепрофілювати новостворену функціональність. Наприклад, ви можете інтегрувати її на іншій стадії проєкту.  

Другий і найгірший варіант—це просто викинути те, що ми зробили. У такому випадку, хоча ми і втратили деякий час, ми почали краще працювати як команда, що є великим плюсом. І, звісно, ми винесли уроки.  

Якщо ви маєте справу з клієнтами, які люблять ретельне планування, ви можете закінчити тим, що будете робити те, що вже було зроблено. Чим більше ми відкладаємо реальну роботу, тим більшим буде розрив між тими, хто вже це зробив, і нами. Щоб зайняти позицію новатора, нам доведеться робити більше.  

Я знаю, що починати буває важко. Особистий приклад: я люблю малювати, зокрема, малювати картини за номерами. Але я завжди кажу собі, що маю намалювати щось сама. Тоді я починаю обирати, що я буду малювати, яку фарбу використовувати, фонову музику і так далі. У цьому випадку ви ніколи не починаєте робити роботу—все, що ви робите, це плануєте.   

У якийсь момент ви повинні перестати планувати і почати малювати. Ви починаєте працювати і насолоджуватися процесом, що мотивує вас продовжувати і досягати поставлених цілей. Те саме стосується і проєктів. Коли ми плануємо щось лише на папері, це може тривати вічно і ніколи не здаватиметься правильним.  

Найкращий спосіб з’ясувати, що пішло не так,—це провести ретроспективу. Ви отримаєте свої уроки, і добре те, що ви можете зробити це як під час проєкту, так і після його завершення.   

Головне—не піддаватися впливу особистих неприязних почуттів і не звинувачувати інших, коли робите ретроспективу. Натомість розберіть результат і зрозумійте, чого всій команді більше не варто робити.   

Інший підхід, який ви можете використати—”посмертний”. Наприклад, ваш веб-сайт вийшов з ладу під час виробництва, тож ви спочатку виправляєте його, а потім уважно аналізуєте, що пішло не так. Це теж уроки, тільки в іншому форматі.   

Ідеальний перебіг фази discovery—це коли клієнт приходить з розумінням того, яку проблему він вирішує і хто є його користувачем. Потім, разом, ми починаємо детально розбивати рішення на частини.   

Однак кожен проєкт відрізняється від інших, і в будь-якому випадку щось може піти не так. Тому для мене справді ідеальна фаза discovery проєкту—це коли клієнт готовий до неї. Витративши від 2 днів до тижня на фазу discovery, ви можете змінити весь хід проєкту. 

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

Таким чином, уся команда добре розуміла, над чим ми працюємо. Клієнт також мав можливість представити своє бачення ідеального кінцевого продукту. Потім наша команда внесла свої пропозиції щодо цього бачення, щоб оптимізувати результат.   

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

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

Також не забувайте робити перерви під час напруженої мозкової роботи. Іноді ми виходили з офісу, нового для нас місця, оскільки ми знаходилися в місті клієнта, і просто гуляли кілька годин. Ми розмовляли, дивилися на речі, і іноді це теж допомагало придумати ідеї для проєкту!