Якщо в проєкті відсутнє бачення продукту і його розуміння, то розробники часто стикаються з кількома проблемами. Це відсутність розуміння того, навіщо створюється продукт, невідповідність готового рішення очікуванням клієнта або навіть поява певного “сміттєфункціонала” безпосередньо перед релізом.
Бачення проєкту: розбираємося з терміном
Бачення — це натхненний опис того, чого організація хотіла б досягти в рамках проєкту. Або ж опис проєктних цілей, який в ідеалі заснований на економічному прогнозі. Зазвичай поняття об’єднує в собі обидва визначення і спрямовує команду до правильного вибору наступних кроків для досягнення кінцевої мети.
Етап 1: Початок роботи над проєктом, фаза ініціації та планування.
Тут може бути декілька проблем. По-перше, це те, про що йшлося на початку — нерозуміння того, навіщо потрібна розробка продукту. А по-друге — менеджмент в стилі “Just do it!”, без пояснення мети роботи та відповідей на запитання з боку замовника.
Ці проблеми мають вирішуватися відразу. З точки зору методології, найпростішим варіантом для використання залишається Scrum. Адже для того, щоб розпочати Scrum-проект, потрібне бачення продукту і його беклог — про це говорив ще один зі співзасновників цієї методології, Кен Швабер.
Vision, або бачення, має бути оформленим у документ — короткий опис суті майбутнього продукту. Тут йде мова про те, що це за продукт, які цілі і завдання його створення, хто його користувачі і які основні можливості майбутньої системи. Він відповідає на такі питання:
- Хто наші користувачі?
- Які в них потреби?
- Яким функціоналом ми задовольнимо потреби?
- Порівняння з наявними продуктами.
- Цільові терміни та бюджет.
Такий документ не має займати більше однієї сторінки. Він буде корисним у спілкуванні зі стейкхолдерами для формування у них уявлення про те, чим ви займаєтесь. Непоганий шаблон такого документа є у Романа Піхлера — провідного експерта з управління продуктами, що спеціалізується на цифрових продуктах і agile-практиках. Виглядає він так:
Vision statement
- Цільова група
На який сегмент ринку спрямований продукт? Хто його цільова аудиторія та клієнти? - Потреби
Які потреби задовольняє продукт і яку цінність він представляє для користувачів та клієнтів? Які емоції він пробуджує? - Продукт
Назвіть від 3 до 5 якостей продукту, що мають вирішальне значення для його успіху. Як він приблизно буде виглядати? Які його унікальні точки продажу? - Цінність
Яку користь від продукту отримає компанія? Наприклад, які джерела його доходу? З чого складається його вартість? Які канали продажу будуть використовуватися? Чи дозволить він заощадити?
Для успішного створення бачення продукту на проєкті обов’язково має бути присутній візіонер — людина, яка просуває бачення продукту і чітко розуміє кінцеву мету проєкту. Ним може виступати продакт менеджер, бізнес аналітик, власник продукту, представник замовника, рідше — менеджер проєкту.
Етап 2: Розробка і впровадження
Найбільш розповсюджена проблема на цьому етапі — втрата фокусу під час довгої роботи над масштабним проєктом. Пам’ятати про мету проєкту при роботі над кожною функцією дозволить підтримка наступної ієрархії:
Ще один ефективний інструмент запобігання цій проблемі — так званий User Story Mapping, або карта історій користувача. Варто завести її на проєкті, щоб бачити продукт в контексті всього функціоналу і використання його користувачем.
З точки зору розробки важливим є проєктування, орієнтоване на користувача. Тобто під час командних зустрічей обговорюється не просто те, як потрібно щось зробити, а як це хоче бачити користувач. Такий підхід дозволяє тримати фокус на баченні та на кінцевій цінності продукту протягом всього процесу розробки.
Ще одна проблема етапу розробки — scope creep. Це неконтрольоване розростання меж проєкту, яке призводить до зриву дедлайну, перевищенню бюджету чи зниження якості продукту. Чітко сформоване бачення — один з інструментів подолання проблеми. Саме воно дозволяє відрізнити зміни, які дійсно є бізнес-виправданими від тих, які є беззмістовними та не відповідають меті продукту.
Етап 3: Реліз
Проблеми при релізі — найгірші, адже виправити їх найскладніше. Вони означають те, що ви робили щось неправильно на двох попередніх етапах. Існує певна закономірність: що пізніше в процесі розробки виявляється проблема, то дорожче її вирішення. Як результат, реліз може не відбутися ніколи. Або ж врешті решт виникне питання, чому не випустити продукт, який має хоча б якусь мінімальну цінність для користувача?
Саме поняття мінімально життєздатного продукту (MVP) підтримує ваше бачення того, що є цінним для користувача і дозволяє отримання зворотного зв’язку від ринку. Окреслення MVP дає змогу уникнути затягування релізу, домовитися з замовником про його випуск з подальшим доопрацюванням необхідних функцій.
Існує ще декілька інструментів, які можуть бути корисними на етапі релізу. Це сценарії користувача — наочне схематичне представлення того, як користувач вирішує своє завдання за допомогою сайту чи додатку. Та концепція Jobs To Be Done — вона допомагає з’ясувати, які завдання ваш продукт буде вирішувати для клієнта. Обидва рішення стануть у пригоді у випадку незадоволеності клієнта готовим рішенням. Адже на них можна посилатися при обговоренні початкових вимог та результату їх реалізації.
Підсумки
Визначайте бачення продукту, використовуйте правильні техніки для акцентування і, головне, підтримуйте фокус команди на баченні, тому що просто написати Vision — це ще нічого не значить. Потрібно повертатися до нього під час додавання кожної нової функції — тільки за таких умов можна уникнути багатьох проблем у роботі над проєктом.
Покращити свої навички ви можете на нашому курсі Business Analysis Intensive Online.
