Для перевірки гіпотези ми використовуємо Build, Measure, and Learn Loop Еріка Райса, автора методології Lean Startup.
Наш шлях до перевірки гіпотези виглядає таким чином:
- Ми перетворюємо нашу бізнес-ідею на гіпотезу.
- Будуємо MVP за допомогою якого ми її перевіримо.
- Показуємо MVP користувачам, щоб виміряти результат.
- Ми досліджуємо отримані дані, щоб прийняти одне з трьох рішень:
- Ми будуємо цю ідею, адже отримали підтвердження її життєздатності.
- Ми відмовляємось від ідеї, адже переконалися що це рішення не працює.
- Ми продовжуємо досліджувати модифікуючи або ідею, або рішення, бо наша впевненість є недостатньою.
Мінімально життєздатним продуктом (Minimum Viable Product, MVP) є артефакт, що дозволяє перевірити гіпотезу.
Ми перевіряємо гіпотезу поступово складність реалізації мінімально життєздатного продукту, як наслідок — збільшуючи нашу впевненість. В цьому нам допомагає крива правди.
- Хибне розуміння lean методологій.
- Надмірна впевненість у розумінні потреб користувачів.
- Занадто оптимістична оцінка часу необхідного для перевірки гіпотези.
Що робити, коли стейкхолдер приходить з вже готовим рішенням?
Проте виникає питання: а що стояло за цим рішенням? Як цей стейкхолдер до цього рішення дійшов?
Якщо ми почнемо імплементувати рішення як є, замість поступового руху малими кроками, то високий шанс отримати артефакт, на який було витрачено багато часу. Але на жаль, з низьким рівнем впевненості у його ефективності. Це дуже ризиковано.
Тому для побудови комунікації зі стейкхолдером та зрозуміти, яку проблему він намагається вирішити нам допоможе фреймворк прийняття рішень Кеневін (Cynefin).
В ньому ми відносимо проблему її до одного з п’яти доменів: відоме невідоме, відоме відоме, невідоме невідоме, непізнане невідоме, та невизначеність.
Домен проблеми №1: Відоме невідоме
Складна проблема, що включає багато змінних у добре відомому контексті.
Наприклад, бізнесу може зменшитись кількість оформлених замовлень та зростати незадоволеність клієнтів. Адже при доставці товарів трапляється багато помилок: доставили не те, не туди, не в тій кількості чи комплектності тощо.
Що ми робимо?
Процес нам відомий та, скоріше за все, задокументований. Проблемою є лише взаємодія між його ланками, що ймовірно спричинена ефектом зіпсованого телефону. Десь якусь інформацію бізнес, як система не вірно інтерпретує, не передає, чи передає з запізненням тощо.
Як ми це робимо?
Для складної проблеми ми: досліджуємо проблему → аналізуємо результати → проектуємо рішення.
Домен проблеми №2: Відоме відоме
Проста проблема, що включає невелику кількістю змінних у добре зрозумілому середовищі з доступними прикладами вирішення.
Наприклад, у бізнесу зросла кількість дзвінків до служби підтримки через те, що клієнти не знають статус їх замовлень.
Що ми робимо?
Тут рішення напрошується само собою. Ми беремо найефективніший з існуючих прикладів відображення статусу в особистому кабінеті та адаптуємо під наш продукт. Проблема вирішена.
Як ми це робимо?
У випадку простої проблеми ми: досліджуємо проблему → категоризуємо проблему → проєктуємо рішення.
Домен проблеми №3: Непізнане невідоме
Проблема, що викликана обставинами, які ми не можемо контролювати (хаосом).
Наприклад, ми раптово дізнаємось що наш сервіс зламали російські хакери, вкрали особисті дані користувачів, зашифрували прод 2048-бітним ключем та зробили дефейс сайту, розмістивши туди якесь непристойне гоатсе (якщо не знаєте, не гугліть що це).
Що ми робимо?
Є ситуація яка загрожує бізнесу фінансовими та репутаційними збитками, але ми не знаємо чому це сталося. Після хакерського злому, нам слід якнайшвидше відновити функціонування системи та прибрати те кляте гоатсе з сайту. А вже потім розбиратися чому це сталося та як можна уникнути повторення в майбутньому.
Як ми це робимо?
Для вирішення хаотичної проблеми ми спершу: діємо → досліджуємо проблему → проектуємо рішення.
Домен проблеми №4: Невідоме невідоме
Комплексна проблема, що є унікальною для конкретного випадку в незнайомому контексті та без встановлених шаблонів вирішення.
Наприклад, нашу команду найняли спроєктувати сервіс електронного документообігу для Уганди. Читаючи цей пост, покладіть руку на серце і спитайте себе чи зможете ви знайти цю країну на мапі? І взагалі, що ви знаєте про цю країну, хто там живе, якою мовою спілкується, як там із законодавством та рівнем проникнення діджиталізації? Ось так виглядає невідоме невідоме на практиці.
Що ми робимо?
У випадку проєктування системи електронних документів для Уганди на ранніх етапах нам варто піти інкрементальним шляхом, щоб поступово покращити наше розуміння контексту. І зрозуміти взагалі, чи є на це запит, і якщо є, то якої аудиторії? Це дозволить нам зменшити ризики отримати продукт що буде нікому не потрібен.
Як ми це робимо?
Стикаючись з комплексною проблемою нам варто піти більш обачним шляхом, тому ми: робимо експеримент → досліджуємо реакцію → проєктуємо рішення.
Домен проблеми №5: Невизначеність
Проблема, яку ми не можемо віднести до жодної з категорій через брак знань чи розуміння контексту.
Як ми це робимо?
У випадку невизначеності, проблему слід поділити на складові частини поменше, і категоризувати кожну з них окремо.
Конструктори для MVP
Сьогодні MVP можна зібрати з величезної кількості різноманітних сервісів. Можна використовувати щось одне або поєднувати кілька з допомогою конекторів та low code інтеграцій:
- Сайт-білдери (лендінги, промо)
- eCommerce платформи (прийом замовлень)
- Боти Telegram/Viber (магазини, порадники)
- Сервіси-конектори та інтеграції (Calendly, Zapier тощо)
- Групи та чати (інформаційні ресурси, зміна поведінки)
- Lego, Arduino, Raspberry-Pi (хардварні рішення)
