Як знайти вектор розвитку програмного продукту? Планування як наука

Основний принцип, за яким ми розвиваємо Macroscop сьогодні – «почути користувача і зробити те і так, як йому потрібно». Ми не просто придумали для себе таку стратегію, а отримали її на своєму досвіді, і цей шлях зайняв у нас 6 років. Про це ми розповідали в одному з попередніх постів. При цьому ми впевнені, що шлях виключно задоволення поточних потреб користувачів не може зробити компанію абсолютним лідером ринку. І якщо ви цього хочете, необхідно робити те, чого ніхто не робить, втілювати у своїх розробках те, що іншим здається неможливим.

Перетворюємо планування в точну науку

Як визначити вектор розвитку продукту і поєднати його корисність і інноваційність? Для того, щоб наші нові розробки з більшою ймовірністю «потрапили в ціль», було прийнято рішення провести глибоке дослідження і на основі його результатів запланувати нову версію. Визначенням стратегії розвитку Macroscop займається продакт-менеджер компанії, і ось за яким алгоритмом діяв він:

1. Виявити всі ідеї. Їх може бути багато, дуже багато.
Для того, щоб знайти всі варіанти нових функцій, доопрацювань і поліпшень, продакт-менеджер Macroscop:
• спілкувався з реальними користувачами продукту. Це були особисті бесіди з кількома десятками людей на зустрічах або по skype, в ході яких обговорювалися їх поточні потреби, ідеї і проблеми;
• спілкувався з технологічними лідерами галузі на виставках, форумах та конференціях;
• спілкувався з технічною підтримкою і групою якості компанії, щоб зрозуміти їх бачення необхідних змін і доробок на основі аналізу проблем користувачів;
• проаналізував річні цілі розробників (кожен співробітник компанії формулює початку року свої особисті цілі);
• проаналізував близько 10 тисяч оцінок і коментарів до демо-версії Macroscop від тих, хто її протестував;
• проаналізував, які модулі відеоаналітікі купують частіше;
• проаналізував запити на доопрацювання ЗА від великих замовників;
• попросив менеджерів з продажу, пресейл-інженерів і фахівців з навчання партнерів скласти своє бачення необхідних доробок і розробок на підставі їх спілкування з партнерами в рамках своїх напрямків діяльності.

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

2. Зважити кожну ідею.
Якби ми були необмежені в ресурсах, ми б реалізували всі 130 ідей. Але необхідно було вибрати конкретні завдання. Для цього ми зважили кожну ідею за 10 параметрами. Якщо не вдаватися в подробиці, то все зводилося до 2 параметрами — інноваційність та необхідність користувачам прямо зараз.
За необхідність відповідав цілий набір ваг з різним ступенем впливу: побажання користувачів безпосередньо, побажання менеджерів, побажання розробників і т. д. Друга оцінка, оцінка інноваційності, робилася умоглядно: ми самі сіли і подумали, наскільки та чи інша ідея інноваційною.

3. Візуалізувати розподіл.
Далі ми побудували такий графік: по одній осі відклали інноваційність, по другий – необхідність користувачам прямо зараз. Кожна ідея перетворилася в одну з точок на цьому графіку з координатами (вага інноваційності; вага необхідності)



Очевидно, що всі 130 завдань не реалізуєш в рамках найближчих версій, але треба вибирати ті, що знаходяться ближче до області (+∞; +∞). Тобто ідеальна завдання – суперинновационная і необхідна користувачам прямо зараз, та, за яку користувачі готові вже сьогодні заплатити гроші і користуватися їй.

Ми розділили графік на 3 зони:

1 зона (вище червоної лінії) – це ті ідеї, які треба реалізувати обов'язково. Вони мають одночасно високим рівнем інноваційності та високим рівнем потреби.

2 зона (між червоною і зеленою лініями) – ці завдання вирішуємо по можливості.

3 зона (нижче зеленої лінії) — неинновационные і непотрібні завдання (до речі, велика частина з цих 130 ідей туди потрапила). І ми їх не робимо

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

Перевести ідею в ціль

Є така формула: мета = мрія + термін виконання. І без чітких строків всі наші плани цілями не були. Ситуація ускладнювалася тим, що ми (як і багато розробники) іноді грішили затягуванням внутрішніх термінів виходу версій, які самі ж собі встановлювали.
Тому необхідно було продумати реальні, але амбітні терміни реалізації нових функцій і доробок згідно отриманого списку, які ми будемо дотримуватися.

Павло Дуров говорив, що кожен місяць потрібно випускати певну кількість поліпшень. У своєму блозі він описував щомісяця 7 поліпшень ВКонтакте: 7 поліпшень листопада, 7 поліпшень грудня і т. д.
Ми визнали позицію «Роби що хочеш, але випускай 7 оновлень в місяць і ритмічно розвивай свій продукт» сильної і вирішили застосувати її в Macroscop (природно, адаптувавши під нашу специфіку).
Продакт-менеджер компанії обговорив нову стратегію і термін 1 місяць з розробниками і після довгих суперечок конструктивних обговорень вони домовилися, що ми будемо випускати нову версію кожні 1,5 місяця.

Коли про терміні 1,5 місяця дізнався технічний директор, відповідальний за тестування нових версій продукту, він сказав, що це неможливо, так як зараз ми кожну версію тестуємо за 3 місяці. Тому що розробники дописують тільки нові функції і доопрацювання, а вони тестують не лише новинки, а ВЕСЬ ФУНКЦІОНАЛ з нуля. Версія, яка прийшла від розробників – це чорний ящик, який вони повинні перевірити вздовж і впоперек.

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

Разом вийде, що кожні 1,5 місяця ми випускаємо версію, але користувачу йде кожна друга, протестована версія. Щоб зрозуміти, скільки поліпшень ми повинні випускати кожні 1,5 місяці, ми проаналізували колишню швидкість нашої розробки і отримали все ту ж цифру 7, яка в нашому випадку включала: 1 завершений крок по інновацій (якийсь новий модуль відеоаналізу або істотне поліпшення поточного модуля) + 2 важливих для користувача функції або істотних покращення + 4 інших функцій або поліпшення.

Користувач – головний експерт

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

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

Всі ці нововведення ми розробили і ввели 2,5 місяці тому. Для того, щоб зрозуміти, наскільки точно ми сфокусувалися і вірно побудували процес розробки, повинне пройти набагато більше часу. Однак, відповідно до плану в кінці вересня ми випустили 1 нову внутрішню версію, в якій реалізували 7 запланованих поліпшень.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.