Створюємо «Чудовий» проект (Minimum Delightful Product)

Minimum Viable Product vs. Minimum Delightful Product
 
 
Одна з найбільш популярних ідей з'явилася в індустрії розробки в останні роки, це концепція «Minimum Viable Product (MVP)» (Мінімально Життєздатний Продукт). Концентруючись на створенні MVP ви зменшуєте шанси що ви створите продукт, який не потрібен споживачеві. Ви можете сприймати її як основу широкої методології, яка впливає на замовника і досліджує користувача продукту в процесі розробки.
 
На перший погляд MVP відмінна ідея, тому, що вона звернена до головного антіпаттерну в продуктовій розробці: створення занадто великого числа фіч, в тому числі не затребуваних, в результаті витрачається занадто багато часу на розробку без запуску проекту або отримання реального фідбек від замовника і користувачів продукту.
 
Фокусувати увагу на «мінімальному» насправді просто. Це допомагає боротися з тенденцією створення фіч за принципом «зробимо, тому що це круто», навіть коли не ясно чи хочуть люди їх чи ні.
Додавання ідеї визначення «життєздатності» врівноважує спроби бути «мінімальним» шляхом фокусування уваги на тому факті, що нижче якогось порогу продукт стає непридатним для використання. З'ясування того, що ж замовник вважає «життєздатним» може бути не простим. Але в теорії — ітерації, дослідження та ведення діалогу дозволить вам досягти розуміння.
 
Використання тільки «життєздатного» продукту схоже на відвідування когось в реанімації. Він живий, але з ним добре часом не проведеш.
Для деяких сегментів це просто. Наприклад, в ентерпрайз бізнес-системах зазвичай вирішують технології які лежать в основі, функціонал, а так само збут / маркетинг. Якщо у вас є необхідний функціонал для того щоб почати продавати, тоді у вас є щось «життєздатне». Ви "знімаєтеся з якоря" і пускаєтеся в "плавання".
 
Але для багатьох ситуацій, просто слідування MVP мало для успіху.
 
Для споживчих продуктів, додатків для малого та середнього бізнесу, інструментів для розробки, «заліза», сфери ритейлу, та інших сегментів показник «життєздатності» не переконує. Використання тільки «життєздатного» продукту схоже на відвідування когось в реанімації. Він живий, але з ним добре часом не проведеш. В результаті, я бачу все більше і більше компаній хто сфокусований на MVP, виробляє продукти які зазнають краху при досягненні своїх цілей.
 
Альтернатива — сфокусуватися на створенні Minimum Delightful Product (MDP) (Мінімально чудовий продукт) .
 
Ідея «мінімального» майже як в MVP: створюємо тільки найнеобхідніше. Цікава частина — це створення продукту «чудовим» замість просто «життєздатного». «Чудовий» продукти закохують в себе користувачів. Вони відразу ж стають частиною життя користувачів або їх роботи. Тільки коли продукт «чудовий», тільки тоді це має сенс. Він працює так як ви очікували і приносить велике задоволення. Чудові продукти поширюються швидше, спрацьовує ефект «сарафанного радіо» і викликають більше задоволення.
 
Але напрошується питання, що робить продукт чудовим? Над цим питанням, я впевнений, міркувало багато людей мудрішими мене, але я вірю що чудовий, це результат трьох елементарних речей з'єднаних разом:
 
     
  • Гештальт продукту
  •  
  • Дизайн
  •  
  • Якість
  •  
 
 Гештальт продукту
Більшість продуктів досягають властивість "чудово" через гештальт продукту (як основа підходу). (По-моєму Алан Купер придумав цей термін у «The Inmates are Running the Asylum» , але я не зміг знайти точну посилання)
 
Гештальт продукту визначає "душу" користувацького досвіду. Це комбінація UX та функціоналу, який робить продукт фундаментально прекрасним. Зазвичай гештальт це частина продукту, яка залишається відносно постійною протягом тривалого часу:
 
     
  • Проста форма пошуку і сторінка результатів у Google
  •  
  • Список друзів і стрічка новин на Facebook
  •  
  • Спосіб яким Adobe Dreamweaver перемикається між HTML і редактором
  •  
  • Модель SAP API
  •  
  • Основа архітектури додатків і мульти-тач інтерфейс на iPhone і iPad
  •  
 
Ви можете досягти відмінного гештальт-Ефєкт просто зібравши правильні фичи разом. Це виникає від правильних елементів, що працюють разом таким чином, що користувач перестає думати про технології та просто досягає своїх цілей.
 
Коли гедтальт-ефект відмінний, продукт сприймається повноцінним і корисним, навіть якщо він не має весь функціонал який ви б хотіли в ньому бачити як користувач. Одним з спокус у підході MVP є спроба побудувати міст тільки до середини яру і викотити його у світ в надії отримувати ітеративний фідбек. Зворотній зв'язок буде «цей міст відстій», навіть якщо ідея моста через яр блискуча сама по собі. Без можливості проїхати мостом «з одного кінця в інший», продукт просто буде сприйматися не робочим, або безглуздим, або у випадку термінології «моста» — дуже небезпечним.
 
Говорячи про повноту, я не не маю на увазі всі фічі що ви можете уявити. «Мінімальність» все так само критична. Я говорю про повноту про яку говорив Кен Швабер, який придумав SCRUM, коли говорив про «пострілі трасуючою кулею через продукт» в книзі «Agile Project Management with Scrum» .
 
«Трасуюча куля» дає вам мінімальну функціональність щоб перебратися через прірву по мосту — щоб продукт був цілісним і робітникам. Наприклад: Замість запуску Facebook-а з "новинний стрічкою", але без "друзів", ви робите і «френдинг» і "новинну стрічку", таким чином, ви отримуєте цілісний User Experience, замість того щоб детально опрацьовувати всі фічі кожної з підсистем.
 
 Дизайн
Гештальт на сьогоднішній день є найбільш важливим компонентом «Чудовий». Наступний компонент це графічний дизайн. Я глибоко вірю у важливість дизайну, але я думаю що він все таки другорядна по порівнянні з гештальт. Графічний дизайн не означає велику кількість «малювання». Він може бути дуже простим, як сторінка пошуку Google і видачі результатів, або багатим функціоналом як OS X. Як люди, ми завжди відчуваємо щастя і радість від краси. Продукти які красиві — вони і чудові.
 
 Якість
Нарешті, останнім елементом "восхітітелності" є якість. Чудовий гештальт і прекрасний дизайн втрачають свою цінність коли якість відстійне. На жаль, занадто часто MVP стає VCP (very crappy product) (дуже паскудної продукт). За іронією долі це відбувається від упусканія з виду дуже базової agile-концепції: коли щось зроблено, воно має бути зроблено. Іншими словами, якщо функція реалізована вона повинна працювати без проблем. Функція не може включати в себе всі можливості які ви можете собі уявити, але те, що вона включає повинен працювати добре.
 
Ймовірно, сама серцевина гештальт iPhone є сенсорний екран. Коли спочатку він був створений, оригінальний пластиковий екран досягли гештальт і дизайн-ефекту, таким чином iPhone пішов у виробництво. Але тоді, в останню хвилину, після тестового використання телефону протягом декількох тижнів, Джобс вирішив, що пластмасовий екран не досить високої якості, він дряпається занадто легко. Залишалося всього 6 тижнів до початку поставки телефону, він зажадав команду замінити на скло, і через титанічні зусилля вони замінили і випустили вчасно.
 
iPhone є одним з найуспішніших продуктів споживчої техніки Уявіть собі, щоб було б якби команда Apple, створювала iPhone застосовуючи MVP. Звичайно, вони повинні були б поставити телефон з пластиковим екраном. Що ще б вони пропустили? Не йти по шляху моделі додатків (можливість створювати свої окремі додатки), а залишити жорстко зашитий функціонал програмної оболонки? Змусили працювати мульти-тач, але також розмістили висувається (складається) клавіатуру на всякий випадок? Скільки б паскудних версії нам довелося б терпіти, перш ніж ми б отримали дивовижний продукт, який він став у версії 1.0? (Можливо, дивлячись на історію інших виробників телефонів ви зрозумієте суть.)
 
Без сумнівів, Apple зробив купу тестів і прототипів, але в той же час вони і поставили перед собою дуже високу планку того що вони хочуть створити. Вони не стали поставляти продукт поки не добилися правильного гештальт-ефекту (мульти-тач екран і платформу додатків), дизайн був прекрасним, і якість теж.
 
При всьому при цьому, версія 1.0 залишила багато речей за бортом. Час життя батареї було невеликим, дозвіл екрана могло б бути краще, можливості камери були мінімальні, традиційні додатки смартфонів (контакти, пошта, звонилка, календар) були не кращий за інших, деякі стверджують — що гірше, лідером ринку була компанія Blackberry. Так само, не було справжнього маркету додатків, не було фронтальної камери, і так далі. Хіба відсутність всього цього створює «мінімальний» продукт? Я б сказав, так. Але «мінімальність" не жертвує «Чудовий».
 
 Висновок
У світі програмної розробки більше свободи ніж у світі hardware. Ви можете набагато легше щось перебрати і змінити. Так software-розробники, можуть пропустити приклад c iPhone. Але багато програмні продукти, а також інші продукти, такі як магазини роздрібної торгівлі та побутового обслуговування будуть добре розвиватися, зосередивши увагу на MDP, а не на MVP.
 
Перш ніж ви надихнетеся і пориньте у створення продукту щоб скоріше запуститися, зробіть крок назад і надайте повагу вашим користувачам. Працюйте з проблемами пов'язаними із створенням чудового продукту, в той же час, зберігайте функціонал мінімальним і виходите на ринок відразу ж як тільки вирішите завдання, які перед вами стояли.
 
Нарешті, майте на увазі, що Ітеративна та зворотній зв'язок є безцінними, але створювати відмінні продукти не вийде просто збираючи зворотний зв'язок і використовуючи результати A / Б-тестування. Все це також приходить з осяянням і майстерністю.
 
Не кожен інженер проектує відмінні продукти, так само, як не кожен художник малює прекрасні картини. Ніяка кількість ітеративного тестування не замінить геніальність винахідника і дизайн прекрасних продуктів, які чудові в використанні. Так що не бійтеся віддавати належне майстерності, що ви і ваша команда вклали в продукт, а так само бажання дати користувачам щось чудове або, ще краще — чарівне.
  
Оригінал: www.startupblender.com / product-planning / minimum-viable-product-vs-minimum-delightful-product
 
 Дана стаття досить поверхнева, але якщо тема виявиться цікавою, то я спробую розвинути тему в наступних перекладах і статтях.

Джерело: Хабрахабр

0 коментарів

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