Як створити специфікацію продукту: 6 практичних порад
Гайд для product-менеджерів
Успішний продукт починається з інноваційної ідеї, аналітики, правильних інженерних рішень, маркетингових досліджень і сильної команди. Але без чіткого бачення, злагодженої комунікації та здатності пояснити складне простими словами реалізувати навіть найкращу задумку складно (а частіше — неможливо). Саме тому на старті розробки важливо створити якісну продуктову специфікацію. У цьому матеріалі — базові принципи, практичні поради та приклади специфікацій для продакт-менеджерів.
Що таке специфікація продукту?
Специфікація продукту — це документ, який детально описує функціональні та нефункціональні вимоги до продукту. Вона визначає, що саме має бути реалізовано, для кого, з якою метою та якими засобами. Це своєрідна дорожня карта для команди розробників, дизайнерів, тестувальників та інших учасників процесу створення продукту. Специфікація, яку ще іноді називають технічним стандартом, відповідає на запитання:
- що ми створюємо;
- для кого призначений продукт;
- які болі користувача ми розв’язуємо;
- які функціональні та нефункціональні характеристики матиме продукт;
- що вважати критерієм успіху (acceptance criteria).
Специфікація продукту охоплює загальний опис вимог до команди інженерів, розробників, дизайнерів тощо. Зазвичай його формує Product Manager і надає всю інформацію, потрібну для створення продукту з конкретними характеристиками та функціями. Беруть до уваги перелік стандартів, яким має відповідати продукт, залежно від ринків його реалізації та директивам, що діють на їхній території. Це своєрідні вимоги, які передають технічні характеристики продукту, інформацію про користувачів, бізнес-директиви та будь-які інші критерії, які допоможуть вашій команді під час створення продукту.
Вимоги до специфікації продукту
Продуктова специфікація є фундаментом та планом (roadmap), якого дотримується вся команда, працюючи над продуктом. Впродовж всього циклу розробки нею користуватимуться бізнес-аналітики, дизайнери, команда розробки, проєктні менеджери, продуктові дизайнери, UX-спеціалісти, маркетингова команда тощо. Специфікація допомагає:
- всім командам говорити однією мовою та тримати фокус на фінальному продукті;
- зменшити відсоток непорозумінь та помилок під час розробки;
- чітко візуалізувати очікування кінцевого користувача та замовника для всіх команд, що беруть участь у створенні продукту;
- прискорити ухвалення рішень у разі змін чи виникнення неочікуваних ситуацій.
Специфікація повинна бути чіткою, зрозумілою, логічно структурованою та висвітлювати потрібні деталі для команди. Жодних «можливо» чи «ймовірно». Інформація не має спричиняти подвійних трактувань чи відхилень від кінцевого результату. Також важливо погодити специфікацію з усіма сторонами.
Вміст специфікації продукту
Структура специфікації може варіюватися залежно від того, який продукт ви створюєте, ухвалених норм та вимог у вашій компанії чи команди, що бере участь у розробці та презентації продукту кінцевому користувачеві. Проте існують основні елементи, на які варто звернути увагу та внести в документ:
- Огляд продукту (Резюме). Починається з викладу ідеї продукту й надає коротке уявлення про нього, загальну концепцію, призначення та цільову аудиторію. Опис відповідає на запитання, для чого створюють продукт, яка його функціональність і зовнішній вигляд, які очікувані дати готовності та який вигляд він повинен мати.
- Бізнес-обґрунтування. Це обов’язковий пункт, який надає пояснення мотивів розробки продукту. Важливо донести бізнесу, які вигоди й переваги продукт дасть компанії після успішної реалізації. Також у ньому можуть описувати бюджети й інші ресурси, що знадобляться для створення продукту.
- Функціональні вимоги. Наводять основні функції кінцевого продукту, як він має поводитися під час взаємодії з користувачем. Цей блок є ключовим для команд розробників та інженерів. Зазвичай сюди додають документ з більш розширеним описом технічних характеристик. Тут можуть описувати стек технологій, API, інтеграції, платформи для розробки. Одним словом, все, що допоможе швидше та ефективніше взятися до роботи.
- Нефункціональні вимоги. Прописують вимоги до продуктивності (якщо актуальні), безпекові фактори, відповідність стандартам тощо.
- Історія користувача (User Stories). Це короткі речення від особи користувача, які описують, що має робити продукт з погляду користувача: «Я як користувач хочу…». Наприклад:
Я як керівник фінансового відділу, хочу мати змогу керувати рівнями доступу менеджерів до бази контрактів.
Зазвичай історія користувача охоплює критерій прийнятності результату (acceptance criteria) — це критерії, що визначають, чи задовольнив продукт історію користувача, наприклад, чи має він бажану функціональність.
- Портрет користувачів. Визначає цільову аудиторію та описує детальніше, для кого створюють продукт. У цьому розділі можуть навести інформацію про цільову демографічну групу, класифікацію професій чи сфери діяльності, на кого орієнтований продукт. Також описують, які проблеми (біль) можна розв’язати. Ви маєте фокусуватися на клієнті під час розробки, тому цей пункт важливий для специфікації.
- Користувацький досвід. UX-дизайн будь-якого продукту повинен бути зрозумілим та спрощувати клієнту життя й допомагати досягти бажаного результату під час користування. Тому в цьому розділі зазвичай прописують вимоги до інтерфейсу, навігації та зручності кінцевого продукту.
- Тестування. Будь-який продукт у процесі розробки проходить обов’язкове тестування, де перевіряють його функціональність, зрозумілість і коректність роботи. В цьому пункті специфікації прописують план юзабіліті-тестування, метрики якості тощо.
- Ескізи дизайну. Макети користувацького інтерфейсу допомагають команді візуалізувати кінцевий продукт і те, як користувачі з ним взаємодіятимуть. Якщо йдеться про фізичний продукт, а не програмне забезпечення, в цьому розділі можна навести замальовки, якої форми має бути продукт, які елементи керування мають бути й побажання щодо місця їхнього розташування. Порівняння з рішеннями конкурентів.
Кроки до створення специфікації продукту
Крок 1. Визначення проблеми
Проведіть дослідження, щоб визначити проблему, яку повинен розв’язати ваш продукт. На цьому етапі важливо розуміти, хто ваша цільова аудиторія та який її основний біль розв’яже ваш продукт. Можливо, варто провести опитування та вийти з додатковою комунікацією до вашої аудиторії, щоб зібрати більше даних. Для визначення проблематики також можна опрацювати звернення користувачів, їхні скарги чи запитання, запити на конкретні фічі та просто зворотний звʼязок.
Це момент, коли варто говорити з усіма — від маркетолога до інженера. Важливо зібрати повний перелік функціональних і нефункціональних вимог. Не забувайте також про безпеку, масштабованість та юридичні або етичні нюанси, якщо такі є.
В анотації специфікації обовʼязково стисло вкажіть зібрану інформацію.
Крок 2. Командне обговорення
Залучіть колег до обговорення отриманих даних. Більше людей не завжди краще, однак попередній досвід команди та свіжий погляд допоможуть визначити основні вимоги до продукту й обговорити потенційні ризики. До того ж це допоможе відчути важливість кожного ще на початку робіт. Також потрібно на цьому етапі узгодити вимоги із замовником.
Крок 3. Фіксування вимог
Чітко задокументуйте вимоги. Історії користувачів (user stories) допоможуть краще висвітлити, як саме має працювати кінцевий продукт. Уникайте загальних формулювань, пишіть конкретно. На цьому етапі важливо також встановити критерії успіху, щоб розуміти, чи продукт або нова функція готові до запуску. Наприклад, чи всі елементи інтерфейсу працюють? Чи досягнуто цільової швидкості завантаження? Чи задоволені тестові користувачі?
Крок 4. Дизайн
Підготуйте референси, надайте посилання на конкурентів. Опишіть ключові вимоги для команди дизайнерів. Організуйте за змоги юзабіліті-тестування навіть на ранньому етапі розробки. Це допоможе взяти до уваги деталі, які можуть команді та вам бути очевидними, а в кінцевого користувача спричиняти труднощі.
Крок 5. Тестування продукту
Обовʼязковий етап, без якого складно уявити реліз продукту. Навіть на ранніх термінах розробки варто створити прототип, який зможуть протестувати ваші найближчі клієнти чи співробітники. Під час тестування ви зі сторони побачите, чи є важливою та чи інша функція, чи не спричиняє вона непорозумінь та плутанини у користувачів тощо. На цьому етапі обовʼязково документуйте все, що впливатиме на фінальні зміни в продукті.
Крок 6. Доопрацювання та реліз
На етапі тестування продукту комунікуйте зі своїми клієнтами та занотовуйте критично важливу інформацію. Зважайте на побажання та зауваження, і коли впевнитеся, що взяли їх максимально до уваги та прямуєте до фінішної прямої, поділіться документом з командою, щоб запустити процес розробки релізної версії.
Специфікація продукту може зазнавати змін у процесі розробки. Це нормально, але головне постійно підтримуйте її в актуальному стані для того, щоб команди, які беруть участь у розробці та запуску продукту в реліз, були на одній хвилі. Може здаватися неочевидним одразу, однак колеги, які створюватимуть технічну документацію або маркетингові матеріали для запуску продажів, також користуватимуться вашою документацією.
Інструменти для створення специфікації продукту
Для створення специфікацій продуктів існує багато різних сервісів та інструментів. Можна скористатися вже готовими шаблонами або сформувати власний. Найзручніше буде користуватися прийнятими в компанії сервісами, наприклад, Confluence. Це своєрідна внутрішня база знань компанії, де можна впорядковано зберігати важливі документи для всіх продуктів і проєктів. З Confluence також зручно лінкувати документацію у створені щодо продукту завдання в Jira. Компанія Atlassian, яка є розробником Confluence, підтримує якісну базу знань з порадами для різних спеціалістів, що працюють над розробкою, та шаблонами документів.
Крім того, зручними для створення специфікацій та поширення їх серед команди можуть бути Notion або Google Docs. Сервіси Visme і Template.net також пропонують різні шаблони специфікацій залежно від типу продукту. Головне, щоб документ був у загальному доступі та зрозуміло оформленим.
