Фіча чи цінність?
Є кілька підходів щодо організації роботи команд в технологічних компаніях:
- Waterfall – один з найстаріших підходів, коли власник бізнесу ставить задачу на побудову одразу складної системи, команда бізнес-аналітиків створює величезний документ з вимогами, команда розробників одну за однією цю вимогу виконує. Цей метод мав сенс, коли спеціалістів, що можуть створити візію великої складної системи було дуже мало, а розуміння обмеженості такого підходу та цінності від ітеративності ще не з'явилося. Компанії витрачали величезні бюджети та створювали громіздкі проєкти, що виконували якоюсь мірою свої задачі, проте були дуже повільні та важкі у використанні. Сама побудова команд була скоріш авторитарна та доволі бюрократична.
- Ітеративний підхід (Agile/ Scrum) – прийшов з появою розуміння того, що систему ефективніше збирати з менших елементів, тестуючи та покращуючи кожен з них якомога швидше. З величезного списку необхідних функцій (беклогу) власник продукту вибирав, на його думку, найважливіші та передавав команді на аналіз та виконання. Команди брали певну кількість функцій, що можна зробити за одну ітерацію (або спринт), створювали та тестували її. В команді працював дизайнер, що на початку ітерації мав швидко створити дизайн для цієї фічі та перевіряв якість виконання після реалізації. Ефективність команди визначалась кількістю випущених фічей.
- Продуктовий підхід – з'явився як наступний етап в розвитку ітеративного, коли стало зрозуміло, що просто за кількість фічей користувачі та компанії вже не хочуть платити. В продукті цінність фічі для користувача вийшла на перший план і вибір необхідного функціоналу з беклогу став менше залежати від думки власника, а більше від реакції користувачів продукту, інформація про яку збирається через продуктові метрики.
Компанії, які швидше переорієнтуються на продуктовий підхід, швидше стануть ефективнішими та будуть мати більше шансів на виживання.
Ризики та фокус в продукті
Продуктова команда, реалізуючи візію власника бізнесу працює з чотирма видами ризиків:
- Ціннісні ризики – чи будуть люди користуватися, платити за продукт?
- Ризик юзабіліті – чи розберуться люди як користуватися продуктом?
- Ризик реалізації – чи можливо такий продукт створити?
- Ризик ефективності для бізнесу – чи принесе реалізація гроші бізнесу?
В здоровій продуктовій команді має бути достатньо експертизи, виливу та відповідальності, аби адресувати всі ці ризики. Зазвичай основу команди складає продуктове тріо:
- Продуктовий менеджер відповідає за розуміння цінності для користувачів та бізнесу та транслює цю інформацію команді,
- Дизайнер відповідає за юзабіліті,
- Розробники відповідають за реалізацію.
При цьому вся команда має спільне розуміння цінності, юзабіліті та реалізованості, комунікує спільною мовою та бачить результат своєї роботи через зміну продуктових метрик. У всієї команди одна мета та один контекст, що надихає всіх.
Продуктовий дизайнер приносить свою цінність в такій команді через вміння разом з продуктовим менеджером створити (чи прийняти) продуктову гіпотезу, проаналізувати її, разом з розробниками створити бачення реалізації, оформити та прокомунікувати дані дослідження.
Співпраця дизайнера та продуктового менеджера
Межі відповідальності продуктового менеджера та продуктового дизайнера часто пересікаються і в кожній компанії ці межі будуть різні.
Дуже важко гарантувати/очікувати на одні й ті ж задачі та підходи в різних компаніях. Тому дуже важливо, розуміючі основні ризики продукту, домовитися з продуктовим менеджером та знайти свій підхід.
Високорівневе бачення результату
Як би привабливо не виглядав ітеративний підхід, демократія та колаборація, складні системи вимагають візії більш високого рівня. Як в будівельній справі, так і в створенні цифрових проєктів існує архітектура – бачення бізнесових задач, реалізованих з допомогою інженерних систем та їх взаємодії.
Solution Architecture – це певна сукупність задач, що мають бути виконані, аби побудувати ефективну систему, яку можна буде масштабувати.
Коли ми говоримо про створення продуктів, як сервісу для сторонніх замовників, ми зазвичай починаємо з Solution Architecture.
Бачення архітектури проєкту включає такі шари:
- Бізнес-архітектуру – основні бізнес-юніти та їх взаємодію
- Інформаційну архітектуру – структуру інформації, на базі якої буде побудовано інтерфейс користувача. Якісна інформаційна архітектура будується базуючись на мапі/флоу/CJM всіх користувачів системи з розумінням взаємодії між ними.
- Технічну архітектуру - інженерні системи, що забезпечують функціонування бізнес-юнітів та їх взаємозв'язок з інформаційною архітектурою.
В продуктовій команді це бачення ввесь час еволюціонує разом з продуктом. Знання базових патернів побудови кожної з цих архітектур та аналіз інших проєктів з фокусом на архітектуру дозволяють будувати більш цілісні та якісні продукти на ранніх етапах.
/w=640,quality=90,fit=scale-down)
Дизайн концепт
Одним з артефактів, що входять до визначення Solution Architecture в продукті є дизайн концепція. Дуже стисла репрезентація майбутнього продукту, показана в кількох ключових екранах, але з розумінням всіх необхідних внутрішніх зв'язків продукту.
Product Roadmap
В продукті ми реалізуємо не всю функціональність одночасно, а в певній послідовності.
Залежно від важливості певної функціональності для роботи продукту визначається пріоритет реалізації:
- Спочатку основні функції системи, потім другорядні;
- Спочатку ті, що вирішать задачі більшої частини користувачів, потім спеціальні фічі для меншої аудиторії;
- Спочатку ті, що приваблять нових клієнтів до продукту, потім ті, що дозволять цих клієнтів втримати.
План розвитку продукту може визначатися як на квартал вперед, так і на кілька років.
Залежно від того, як змінюються продуктові метрики, цей план переглядається і пріорітети певних фічей змінюються.
Маючи план, його можна змінювати та будувати певні прогнози. Без плану та зафіксованих ідей подальшого розвитку рухатися набагато складніше.
