Апр. 28

Порівнюємо Spikes, Proof of Concepts, Prototype, MVP

Більше ніж п’ять років я займаюся мобільною розробкою, останні два роки на позиції Tech Lead у Symphony Solutions. У вільний час ми з командою працюємо над власним продуктом. У розробці або створенні стартапу я часто помічаю одні й ті самі помилки. Спеціалісти обирають між «дослідити» і «накодити». На початку створення продукту або фічі варіант «закодити» дасть відчуття миттєвого результату, але з часом і через масштабування вносити зміни стає все важче, а іноді майже неможливо. Як уникнути прикрих помилок і розвиватися планомірно? Як тестувати свої гіпотези?

Джерело

У розробці продукту легко помилитись. Помилитися з вибором технології, інтерфейсом або баченням кінцевого продукту загалом. Методи Spikes, proof of concepts, prototypes, MVP допоможуть планувати наступний крок без страху схибити, перевіряти гіпотези та припущення без втрати часу на розробку. На позиції Tech Lead я переосмислив важливість цих методів, адже вони коригують напрямок не тільки для мене особисто, а й для команди. Бездумно поринаючи в розробку з головою, я набив ґулі на власному продукті. Однак цей час пішов на користь, тому тепер я можу поділитися тим, як використовувати Spike, де потрібен прототип і що не потрібно називати MVP.

З’ясуємо, де і коли застосувати ці методи та чим вони відрізняються.

Стаття буде корисною всім, хто займається розробкою, менеджерам, стартаперам. Особливо тим, кому легше «накодити», ніж спланувати та оцінити ризики через брак нетехнічних знань.

Spike

Перший метод використовують для знаходження потенційних рішень. Саме потенційних, адже результатом має бути відповідь, а не технічна реалізація. Використовуючи цей метод, ми можемо проаналізувати, перш ніж братись за реальну роботу.

Що це

Проведімо аналогію, Spike (спайка) — розвідувальна місія. Вона потрібна тоді, коли в нас недостатньо знань для планування. Скажімо, ми хочемо вирішити щось за допомогою технології або сервісу, про які нічого не знаємо. Які ризики? Це взагалі можливо? Чи є ще варіанти?

Що робимо

Ставимо чітку ціль «Дослідити ризики...», «Знайти варіанти рішень для...»
Експериментуємо та визначаємо складність.
Аналізуємо можливості, не зациклюючись на одному рішенні.
Встановлюємо часові обмеження «2 години», «1 день» тощо.

Що отримаємо

Ми отримуємо знання у темі, про яку не знали. Завдяки цим знанням робимо вибір і відчуваємо впевненість у плануванні. Так уникаємо невизначеності й завжди розуміємо, куди прямуємо.

Приклад

На плануванні обговорюємо завдання «Додати функціонал з розпізнавання мовлення з аудіо в текст». PM відразу просить оцінити або питає, чи в когось є досвід зі схожими технологіями. Звісно, що оцінювати немає що, навіть якщо в команді є людина з досвідом роботи, технології могли вже змінитися або знання застаріти. Саме в такому випадку доцільно буде зробити спайку.

Тоді завдання звучатиме так: «Дослідити можливі інтеграції зі Speech to text сервісами, а також оцінити складність імплементації у продукті» (1 день). Результатом роботи мають бути знання у темі Speech to text, можливі варіанти інтеграцій або фреймворків, складність імплементації.

Можна написати dirty code в новому проєкті або бренчі, щоб протестувати його з технічного погляду. Не варто демонструвати готове рішення, нехай висновки робить команда на основі отриманих знань. Цей код не має бути видалений після.

Proof of Concept

Мета PoC — довести, що всі інвестиції в дизайн, продукт або напрям будуть доцільними. Цей метод дає змогу визначити, чи варто рухатись до конкретної концепції. Результатом може бути як робочий код, замальовки User Stories, так і базова інфраструктура.

Що це

PoC — така собі перевірка, демонстрація того, що ваша ідея, технологія або метод працює. Результат має бути достатнім для ухвалення рішення, а не готовим продуктом.

Що робимо

Визначаємо, що саме перевіряємо. Бажано, щоб це була одна концепція.
Обмежуємо себе у часі «тиждень», «спринт», «місяць» тощо.
Документуємо всі висновки та результати.
Заздалегідь попереджаємо про те, що результат не може бути використаний у реальному продукті, а є лише доказом працездатності.

Що отримаємо

Впевненість у робочій моделі або технології. Ми демонструємо команді або замовнику базову реалізацію. Зможемо визначитись, чи варто рухатись далі.

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

Зазвичай у розробці PoC не часто використовують, тому що команди намагаються обирати перевірені та протестовані рішення. У бізнес-площині, навпаки, безліч невизначеностей і гіпотез, яким варто дати зелене світло. Або забути та не витрачати на це дорогоцінні ресурси.

Приклад

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

Створюємо PoC і тестуємо нейромережу на конкретній бізнес-задачі. Наприклад: відповіді на негативні коментарі всередині продукту. Ми не будемо відповідати на всі коментарі, фокусуємось лише на негативних, щоб мінімізувати ресурси.

Завдання звучатиме так: «Підтвердити або спростувати можливість відповіді на негативні коментарі за допомогою нейромережі». Результатом роботи може бути проста нейронна мережа, яка розрізняє серед усіх коментарів негативні й пропонує шаблонні відповіді. Після демонстрації результатів вирішимо, чи варто додати цей функціонал та розширити його на всі коментарі.

Prototype

Без тестування на потенційних користувачах визначити, чи справді продукт є зрозумілим та зручним, дуже складно. Прототипування створене для тестування продукту без його реалізації. Це не має бути робочий продукт, а лише його каркас. Без бекенду і бізнес-логіки. Ми повинні просто побачити його. Є багато варіантів прототипів, усе залежить від продукту, який ви розробляєте і якості його виконання: сторіборд, клікабельний мокап, хардвер-девайс на відкритій платі або ж просто намальовані ескізи.

Створімо прості правила гри для більшості IT-прототипів:

Користувач має зрозуміти принципи та структуру.
Прототип має передавати суть продукту.
Прототип повинен передавати масштаб майбутнього продукту.
Користувач має взаємодіяти або переміщатися по прототипу.
Маємо отримати зворотний зв’язок від користувачів або замовника.

Наш прототип — це не остання інстанція. Сприймайте його як запитання «Чи виконується наше ТЗ? Чи прототип зрозумілий?». Ітераційно покращуючи прототип і тестуючи його, ми обов’язково виграємо в часі та ресурсах у майбутньому.

Що це

Візуальний спосіб продемонструвати та протестувати продукт без суттєвих ресурсів. Це вже не просто методи та спроби, як було зі спайкою і PoC. Прототип — це річ із розмаїттям форм і розмірів. Популярні приклади прототипів у розробці та дизайні: мобільні мокапи, інтерактивні дизайни та вайрфрейми.

Що робимо

Визначаємо форму, в якій буде виконано прототип.
Домовляємось про юзер-сторі, які будуть продемонстровані, а які ні.
Попереджаємо, що не варто очікувати готового робочого продукту.
Визначаємо девайси, на яких можна буде протестувати прототип, гарантуємо результат лише на конкретних версіях чи розширеннях.
Документуємо всі висновки та результати для наступних ітерацій.

Що отримаємо

Цілісний та об’ємний вигляд продукту, хоч на «Кікстартері» реєструйся. Відчуття взаємодії з майбутнім продуктом. І найголовніше — можливість дешево внести зміни, отримати ітераційне удосконалення. Наш продукт еволюціонує ще на стадії тестування гіпотези.

Приклад

З проєктом chichi ми були учасниками хакатону, де за 48 годин мали продемонструвати свій продукт або його прототип. У нас була ідея створити застосунок для пошуку салону краси, якщо потрібно зробити послугу «Сьогодні» або «Завтра» і в заданий проміжок часу. У нас був лише PoC і база салонів краси та барбершопів міста. Ми зрозуміли, що зробити повноцінний продукт не встигнемо. Тоді вирішили створити прототип.

Прототипом стали Lo-Fi дизайни та функціонал із фільтрування. У застосунку на Android були картинки з дизайну і єдиний скрин з функціоналом. Ці скрини мінялись кілька разів і дизайнились у процесі, що кардинально змінювало вигляд аплікації за лічені години. Людина могла навігувати, бачити наповненість майбутніх скринів, скористатись основною функцією пошуку за часом і зробити фейкове бронювання, але не більше. У результаті суть продукту та застосунку було передано аудиторії та суддям хакатону. За 48 годин ми зробили декілька ітерацій, які в реальній розробці коштували б нам 48 тижнів роботи.

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

MVP

Я часто чую цю абревіатуру в різних контекстах. Люблю, коли суть MVP показують як доісторичний сайт з двотисячних, порівнюючи його зі свіжим зі словами: «Хлопці створили сайт. Вони були маленькі, а потім стали великі. Успіх!».

MVP набагато глибше і складніше питання, ніж здається. Якщо спайка, PoC і прототипи допомагають нам подолати технічні та дизайнерські питання, то MVP має ще одну важливу складову.

Абревіатура MVP має такі ознаки:

Minimum — мінімальний (про це ми вже чули, до того теж мінімізовували зусилля).
Viable — життєздатний.
Product — продукт (про це ми теж чули, ми ж створюємо його).

Про «мінімальний» і «продукт» більш-менш зрозуміло. Можна зробити щось маленьке, що виконує головну функцію продукту. Але як перевірити його життєздатність?

На мою думку, життєздатність перевіряє не команда або замовник, а ринок і реальний користувач. Тому перевірка MVP вимагає підприємницької складової. Через це у MVP безліч форм і тлумачень. Ми візьмемо за приклад типовий технічний MVP.

Що це

Мислити масштабно — починати з малого. Цей метод не має зменшувати вартості вашого продукту, а навпаки, проявляти його суть і дати шанс на життя.

Ми фокусуємось на тому, щоб надати користувачеві мінімально життєспроможний продукт, яким він може вже користуватись. Він уже має приносити людині користь, а ми можемо отримати зворотний зв’язок і зробити кращу версію продукту. Виконуємо кроки доти, доки користувач не буде задоволений або гіпотеза не буде підтверджена чи спростована.

Що робимо

Пам’ятаємо про велику ціль або масштаб.
Розділяємо на ітерації.
Фокусуємось на конкретному ринку, технології.
Обираємо одну його функцію, яка має найбільшу вагу.
Розробляємо її, не вдаючись до повної автоматизації та ідеальної якості.
Отримуємо відгуки від реальних користувачів.
Готуємо першу версію (ітерацію) робочою або навіть зарелізеною.
Документуємо всі висновки та результати для наступних ітерацій.

Що отримаємо

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

Пам’ятаєте картинку про MVP з машиною, яку будують з колеса, або коли починають зі скейтборду? Ось чудова стаття від її автора Генріка Кніберга. Він чудово пояснює суть MVP без води та із влучними прикладами. Він наполягає на тому, що критичним у роботі з MVP є вибір «скейтборду», першої ітерації продукту. Навіть якщо плануєте колонізувати Марс, почніть з чогось маленького.

Приклади

Calm. Пам’ятаєте про «безліч форм і тлумачень»? Дуже нетиповий приклад MVP подарувала нам компанія Calm, яка вчить людей медитації. Тоді, ще у 2010 році, Алекс Тью створив сайт DoNothingFor2Minutes.com. Завдання — не рухати мишку і клавіатуру протягом двох хвилин. Заспокоїтись і слухати звуки океану. Це все. Якщо у вас вийшло, ви можете купити книжку або залишити свою пошту.

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

Zappos. Співзасновник популярного онлайн-магазину взуття Тоні Шей у далекому 1999 році не був впевнений, що люди купуватимуть товари через сайт. Він створив простенький сайт-каталог взуття, який вони з командою сфотографували у взуттєвому офлайн-магазині. Коли перший клієнт придбав взуття, вони пішли у магазин, купили цю пару й надіслали покупцю поштою. Мінімальний? Так, нічого зайвого. Життєспроможний? Звісно, користувач отримав взуття, а команда реальні гроші. Продукт? Звісно, тепер можна і покращувати.

Висновок

Кожен з методів підійде на різних етапах створення продукту. Вони подані від найменшого — спайки і до найбільшого — MVP. Обираючи, почніть з найменшого і рухайтесь до MVP. Можливо, для вашої проблеми або гіпотези можна використати менш затратний метод і зберегти час.