Мінімальний життєздатний продукт (minimum viable product, MVP) — продукт із мінімальними, але достатніми для задоволення потреб перших споживачів функціями
Зараз дуже багато статей на цю тему. Більшість присвячено стартапам і продуктовим ІТ-компаніям.
Але MVP — дуже корисна річ у розробці загалом.
Тут я поділюся досвідом застосування MVP у сервісних підрозділах розробки компаній поза ІТ-галуззю.
Отже, у нас є розробник, а можливо, і не один.
Ви їхній керівник.
Вони на окладі, і у вас не болить голова, чим виплатити їм зарплату наприкінці місяця.
І у вас є замовники. Внутрішні, але від цього не менш важливі й улюблені :-)
І одного разу в когось у компанії виникає думка: а розробімо продукт X.
Отже, бажання замовника є, він має повноваження й готовий працювати.
Поїхали.
Добре, якщо процес, який ми закладаємо в продукт, уже існує. І перебуває хоча б на якійсь стадії автоматизації.
Але найчастіше налагоджений процес у тому самому Excel — просто мрія аналітика. Сувора реальність зазвичай така, що немає не лише Excel, а й самого процесу. Людям потрібно дати інструмент і навчити їх виконувати роботу за його допомогою. Це я називаю «налагодити процес».
І ось тут починаються складнощі.
Якщо запитувати людей, що їм потрібно, які саме функції має містити майбутній продукт, найімовірніше, отримаємо набір космічних побажань, мало пов'язаних із реальністю. Тому що:
- «Раптом керівник прочитає? Треба думати на перспективу!» І замовляють певні речі, які, можливо, знадобляться потім, у світлому майбутньому.
- «Про всяк випадок». Тоді замовляють усе підряд і побільше.
- «Процес незрозумілий, тому потреби теж». Потреб немає взагалі.
Гаразд.
Можна взяти всі ці потреби, зовсім уже космічні прибрати й почати роботу.
Пам'ятаємо про оклад розробників? Замовники є, запит є — працюємо!
Але шансів зрештою налагодити процес і впровадити продукт небагато. Особливо якщо йти за класичною каскадною моделлю.
Та головне — набір космічних побажань зростатиме.
На кожній демонстрації згадуватимуть нові «забуті» важливі прикраси, без яких «не злетить».
Специфіка внутрішньої розробки в тому, що впродовж проєкту змінювати вимоги легше. Особливо додавати їх.
Звісно, у справжніх PM і справжніх аналітиків такого не трапляється. У них усі проєкти завжди завершуються вчасно й точно в межах бюджету. А ТЗ точні й зрозумілі. Але ми зараз не про них...
Отже, розробка триває, і паралельно росте беклог із «дуже важливих і потрібних космічних прикрас». Кінця-краю цьому не видно. Особливо якщо користувачі взагалі не надто хочуть автоматизації — пам'ятаємо про Шарика з фоторушницею? Проєкт ризикує перетворитися на проєкт-камікадзе.
Глухий кут.
І тут концепція MVP дає шанс на виживання.
Робимо мінімум, з яким можна працювати. Можливо, незручно, повільно, частина речей не автоматизована, але працювати можна.
І віддаємо користувачам. Точніше, намагаємося віддати.
Якщо воно нікому особливо не потрібне — згортаємо проєкт. Це ще легко зробити, адже на нього не витрачено багато людино-годин. Демотивації майже не буде. Навіть навпаки: радість від того, що не змарнували багато часу.
Якщо ж продукт справді потрібний, користувачі візьмуть MVP.
Головне, щоб MVP не погіршував поточне становище користувача загалом. Тобто десь може бути незручно й навіть складніше, але десь — легше, а головне — видно перспективу.
І тут, після того як користувачі почали РЕАЛЬНО працювати з продуктом, навала космічних побажань закінчується. З'являється зворотний зв'язок. Чіткі, конкретні пропозиції. Команда входить у робочий ритм. З'являється драйв від того, що кожен бачить результати своєї праці: одні попросили й отримали, інші зробили — і їхньою роботою користуються.
Усе. Далі варіантів немає: проєкт завершиться успіхом.
І навіть якщо проєкт невеликий, це однаково буде чудово.