Створення IT-продукту — це об’єднання творчої енергії та технічних знань команди з організаційними скілами менеджера. При цьому від дій PM-а багато в чому залежить, наскільки комфортно й ефективно пройде Delivery процес. У статті детально розповімо про те, на яких етапах і на що саме Product Manager повинен звернути максимум уваги.
Що собою являє Delivery Process
Delivery Process — комплекс робіт, до якого входить розробка, налагодження, тестування та запуск продукту з подальшим супроводом і внесенням змін за необхідності.
Пропонуємо розглядати процес Delivery, що складається з 5 етапів:
- Definition of Requirements (Need Help);
- Delivery Definition;
- Development;
- Delivery Event;
- Maintenance (Feedback and Support).
На практиці Delivery Process може багаторазово повторюватися, якщо продукт затребуваний на ринку. Для цього важливо на етапі Definition of requirements і Delivery Definition правильно визначити для кого, що і як робимо — тобто сформувати основні вимоги для IT-рішення. Основні постачальники ідей — користувачі та стейкхолдери, команда розробки, відділи маркетингу та продажів.
Definition of requirements
Насамперед необхідно знайти відповідь на запитання: «Хто взаємодіятиме з продуктом і яку користь отримає користувач від цього?» Наприклад, застосунок зможе поліпшити бізнес-процеси, знизити витрати, прискорити роботу. Правильне визначення потенційних користувачів та їхніх потреб — база для розроблення плану з технічної реалізації проєкту і стратегії подальшого просування. Особливо актуально для MVP.
Для наявного застосунку формування вимог зазвичай починається з аналізу того, що можна поліпшити в поточній версії IT-продукту: які фічі додати, а що залишити без змін або зовсім прибрати. Робиться це все на підставі даних, отриманих після тестування поточної версії та зворотного зв’язку користувачів. Під час пошуку вимог до IT-рішення обов’язково враховуйте думку і рекомендації відділів сейлзу та маркетингу — часто від цього залежить ефективність просування і швидкість продажів продукту.
Delivery Definition
Коли визначено потенційних користувачів IT-рішення і є попереднє розуміння, яким воно має бути, стартує Delivery Definition. На цьому етапі визначають, чи можлива реалізація проєкту в принципі. Solution Architect перевіряє всі запити: чи є подібне на ринку або це щось нове, чи можна вбудувати в поточну версію застосунку тощо.
По суті на Delivery Definition аналізують потенційну життєздатність продукту:
- уточнюють основні функціональні вимоги та бізнес-цілі;
- складають попередній план робіт;
- розраховують приблизну вартість і терміни.
На практиці часто трапляються ситуації, коли після Delivery Definition зсувають старт розроблення, повністю переглядають концепцію або зовсім відмовляються від проєкту. Якщо все добре, йде плановий перехід до Development.
Development
Процес розробки у кожної команди будується індивідуально, але багато в чому залежить від використовуваної методології та методики управління проектами. Наприклад, Scrum диктує обов’язкове demo, що дуже важливо для Delivery. Якщо ви хочете, щоб ваш продукт потрапив на ринок у потрібному вигляді, обов’язково підбивайте проміжні підсумки і за необхідності вносьте корективи в роботу.
Старт Development зазвичай починається зі створення юзерсторі. Потім складають чіткий план робіт з обов’язковим зазначенням основних контрольних точок — milestones, що відносяться виключно до процесу розробки. З цього моменту починається технічна реалізація продукту з обов’язковими проміжними demo і фідбеками за ними з подальшим переходом до етапу Delivery Event.
Delivery Event
На цьому кроці відбувається створення фінального demo, його презентація і тестування для отримання розширеного фідбеку. Річ у тім, що на етапі Development перевіряти продукт найімовірніше буде невелика кількість лояльно налаштованих користувачів. У таких умовах складно отримати об’єктивну картинку, тому важливо правильно провести Delivery Event.
У процесі чудово допомагають відео-презентації, організація тренінгів з використання продукту, підказки в самому застосунку. Мета всіх цих заходів — запустити максимально готовий продукт у вигляді MVP або оновленої версії наявного застосунку для всіх користувачів і перейти до етапу Maintenance.
Maintenance
На запуску продукту Delivery не закінчується — триває постійний процес отримання та аналізу фідбеку від користувачів, а також інформації про дефекти. На підставі цих даних вносяться корективи в технічну частину продукту, стратегії маркетингу і продажів.
Загалом правильний Delivery Process завжди включає в себе обробку зворотного зв’язку на всіх етапах:
- При створенні demo перевіряйте ідею і корегуйте ідею за необхідності, щоб отримати найбільш точний результат на даний момент.
- Обов’язково стежте за перфомансом, щоб Delivery не був “змазаний”, наприклад, через проблеми із сервером.
- Уважно ставтеся до фідбеків користувачів і тікетів про помилки роботи застосунку, адже вони можуть наштовхнути на цікаві ідеї та виявити нових постачальників вимог.
На практиці часто трапляється ситуація, коли вчасно опрацьований зворотний зв’язок дає змогу визначити критичну вразливість або розширити потенціал застосунку. Головне, щоб у процесі Delivery всі учасники чітко знали свої ролі та розуміли, що їм потрібно робити на кожному етапі.
Участники на Delivery
| Етапи | Учасники |
| Definition of RequirementsDelivery Definition | Business AnalystProduct OwnerCTO / StakeholderSolution ArchitectProject Manager |
| Development | Product OwnerBusiness AnalystDevelopment Tech LeadProject Manager |
| Delivery Event | Project ManagerProduct OwnerBusiness AnalystSupport Lead |
| Maintenance | Support LeadProject ManagerProduct OwnerBusiness Analyst |
З таблиці видно, що продакт, проєктний менеджер і бізнес-аналітик в ідеалі повинні брати участь на всіх етапах. На практиці часто Product і Project Manager — одна й та сама людина, особливо на невеликих проєктах. Business Analyst основну роль відіграє при визначенні вимог до продукту і у формуванні технічного завдання команді розробників.
Stakeholder — база для збору інформації, а без Solution Architect складно уявити грамотне опрацювання фізибіліті на етапі Definition. Можна скільки завгодно говорити про роль продакта, але процес розробки багато в чому лягає «на плечі» Development Tech Lead. На етапі Delivery Event має сенс підключити Support Lead для ознайомлення з функціональністю готового застосунку і його бізнес-логікою — йому надалі це стане в пригоді на Maintenance.
Якщо говорити про тривалість і ступінь важливості етапів, то збір вимог впевнено посяде перше місце. Ви разом із командою можете створити ідеальний застосунок з погляду бізнес-логіки та технічної реалізації, але помилка під час визначення тієї самої ЦА та її болю може нівелювати всі зусилля — продукт просто не буде затребуваним. У підсумку компанія втратить час, гроші і, можливо, зазнає репутаційних втрат. Саме тому досвідчені Product Managers радять приділити максимум уваги вимогам до майбутнього застосунку.
Як налагодити процес Delivery
У Delivery Process по суті беруть участь 2 команди — продуктова і розробки. Умовно вони можуть бути незалежні одна від одної, але на практиці часто перетинаються на етапі уточнення функціональних вимог і розробки технічного завдання. Product і Project Managers — основні сполучні ланки між ними, і організація робочих процесів у їхній зоні відповідальності.
Що врахувати на старті проєкту
- Обговоріть формат взаємодії між учасниками, щоб усім було зручно.
- Домовтеся про те, що має вийти в результаті роботи, щоб не було потім неприємних сюрпризів на кшталт «ми це не обговорювали», «цього не було в ТЗ».
- Обговоріть показ ранніх прототипів: у якому вигляді, як часто.
- Уточніть термінологію і зони відповідальності, щоб зменшити хаос у роботі.
- Особисто познайомтеся з реальними людьми по позиціях і проговоріть список зобов’язань із кожним за потреби — це знизить відсоток непорозумінь.
Що врахувати на етапі виконання
- Сформуйте список можливих ризиків і дій щодо їх усунення. Наприклад, як не допустити зриви термінів.
- Організуйте раннє інформування учасників з важливих питань.
- Визначте обов’язкові та необов’язкові активності, їхній пріоритет і частоту.
Як дотримуватися Delivery процесу
Припустимо, ви налагодили роботу команди та взаємодію зі стейкхолдерами, пройшли всі етапи й успішно запустили проєкт. Чудово — тепер потрібно це постійно повторювати. Такий підхід дасть змогу отримувати очікувані результати, підвищити якість виконуваних робіт, знизити вартість супроводу процесу.
Дуже важливий момент для ефективної роботи менеджера — дотримання формальностей:
- Збирайте конкретні артефакти після закінчення будь-якого етапу, наприклад, оформлені фічі.
- Плануйте всі зустрічі/події.
- Будьте в курсі зміни людей на позиціях у проєкті, негайно проговорюйте список зобов’язань із тими, хто прийшов.
Список завжди можна розширити, але виконання навіть цих пунктів істотно спрощує роботу PM-а і його взаємодію з командою. Дотримуючись формальностей, ви уникнете хаосу на проєкті та знизите ризики.
Замість висновків
Стабільний Delivery Process — запорука успішного запуску продукту, який має високі шанси стати популярним на ринку. Головне в процесі — правильно визначити бізнес-цілі, вимоги до застосунку і грамотно вибудувати взаємодію учасників на всіх етапах. Для цього важливо підібрати відповідну команду фахівців, визначити між ними ролі та зони відповідальності, контролювати пріоритетність завдань і хід роботи. Також пам’ятайте, що повторюваність і дотримання формальностей — ключ до високих результатів.