У видавництва «Фабула» виходить український переклад книги Юргена Аппело «Стартап, скейлап, скрюап». Головна мета автора — уніфікація методів та інструментів, що успішно використовуються стартапами та скейлапами на основі принципів і практик, популяризованих lean- та agile-спільнотами в усіх сферах управління бізнесом. AIN.UA публікує уривок з книги.
Найтемніший шлях
Керуйте очікуваннями зацікавлених сторін за допомогою дорожньої карти продукту, створеної на основі експериментів, результатів і планування за методом хвилі, що накочується.
— Коли з’явиться версія для iOS? Після демонстрації нашого продукту на конференції «Agile- 2018», що проходила в Сан-Дієго, це було чи не найпоширеніше питання. І щоразу нашою відповіддю було: «Ми почнемо працювати над iOS-версією лише після того, як виявимо відповідність продукту та ринку». Поки споживачі не користуються нашим продуктом досить масово, немає сенсу розширюватися на інші платформи. Навіщо дублювати продукт, що й досі не працює як належить? Однак наші потенційні споживачі дотримувалися іншої думки. Вони жадали спробувати наш мобільний застосунок у своєму улюбленому смартфоні або іншому ґаджеті, що працював в одних на операційній системі Android, а в інших — на iOS.
Деякі технічно обізнані читачі здивуються: то чому ми не використали крос-платформний фреймворк, що може працювати і з Android, і з iOS? Перша відповідь буде такою: як стартап ми потребували швидкого експериментування, а ви можете бути швидкими лише в тому, що добре вмієте робити. Виявилося, що в нашій команді є чудові розробники для Android. Створюючи мінімально життєздатний продукт і шукаючи відповідності продукту та ринку на стадії Підтвердження, ми вважали цілком нормальним використання технологій, у яких ми є швидкими і гнучкими. Зміна технологій і перебудова бази мали б відбуватися на стадії Стабілізації — якщо колись ми її досягнемо.
Наша команда спробувала визначити, коли виникне слушний час для початку роботи над iOS-версією. Спочатку ми вважали, що це буде другий квартал поточного року. Потім ми відсунули цю справу на початок осені. А згодом оголосили, що початок цієї роботи планується (за сприятливих умов) на кінець року. Хай би що відбувалося з розробкою нашого продукту, обставини завжди втручаються в процес. Та й плани зазвичай змінюються частіше, ніж погода в Нідерландах.
Створення дорожньої карти — загального стислого викладу еволюції продукту в напрямку його візії — одне з найскладніших завдань як для стартапів, так і для скейлапів. Споживачам, інвесторам, членам ради директорів і працівникам потрібна певна ясність щодо того, куди рухатиметься компанія в найближчому майбутньому. Адже це — шлях. І люди мають право знати, куди і коли він приведе. Також і засновники бажають пересвідчитися, що їхні команди працюють над тими напрямками, що мають найбільшу комерційну цінність.
Окрім того, деякі зацікавлені сторони в організації потребують від команди розробників продукту надання зобов’язань до певної дати чи якихось орієнтирів для підготовки маркетингових компаній, навчальних програм чи підтримки клієнтів. Та й самій продуктовій команді необхідне планування для «воронки наймання» і визначення дат. Отже, дорожня карта продукту — важливий інструмент для доведення плану продукту до всіх зацікавлених сторін.
Ось що розповів мені в Таллінні про свій досвід розробки продукту на посаді головного технічного директора компанії «pipedrive» Сергій Анікін:
«Як компанія, що налічує понад 400 співробітників, серед яких 180 є інженерами, ми неминуче стикаємося з проблемою пріоритизації ідей, тому що їх дуже багато. Як дізнатися, які з них є насправді важливими? Добре, що чимало вказівок і досі надходить від засновників. Вони розуміють проблеми і запити споживачів краще, ніж будь-хто, тому що мають оригінальну візію продукту, яка поступово змінюється з плином часу. Ми отримуємо відгуки від клієнтів, ринок продовжує рухатися — але поки візія засновників не реалізована, ця первинна дорожня карта залишається в їхній уяві. Іноді нам доводиться робити кілька кроків назад і щось переробляти. Ми здійснили багато перебудов, тому що зворотний зв’язок продовжує надходити. Суть у тому, що це взагалі не гонитва за функціоналом. Переважно йдеться про те, що по-справжньому важливе для споживачів, що заважає їм використовувати весь потенціал конкретного інструмента». — Сергій Анікін, головний технічний директор «Pipedrive» (Таллінн, Естонія)
Логічно, що засновники продовжують надавати вказівки для дорожньої карти продукту, користуючись своєю візією, але вони не єдині, хто має цікаві ідеї. Боріс Дібольд, головний технічний директор компанії «Seven Senders», розповів мені, як одного разу, ще працюючи в іншій компанії, він збирав вартісні пропозиції:
«На корпоративному стендапі в понеділок я оголосив, що керуватиму вправами зі складання стратегії продукту і хочу, щоби всі присутні запропонували свої ідеї та поміркували над тим, у якому напрямку та чому саме нам слід рухатися. Я попросив узяти участь не тільки тих, хто працював над нашим продуктом, але й інших співробітників компанії, тому що всі були дуже ним захоплені. Я сказав: «Привіт, мені потрібна ваша допомога. Я буду доступний весь тиждень і почую всі ваші ідеї, а потім ми подивимось, як зібрати їх докупи та щось із цим зробити”.
Я надав їм шаблон, щоби вони могли обміркувати кілька запитань, а потім повідомити мені все, що забажають потрібним. За цей тиждень я поспілкувався із, приблизно, 40 людьми і почув дуже багато цінного. Я побачив серед їхніх пропозицій деякі закономірності, виокремив архетипи та разом із СЕО, який теж був одним із засновників, продовжив формувати бачення. Потім ми обговорили опрацьовані ідеї з меншим, але дуже активним колом членів первинної групи і нарешті викристалізували візію продукту. Весь процес був дуже обмежений у часі і тривав два тижні. Ми виявили, що найкращі пропозиції не обов’язково надходять від продукт-менеджерів — їх можуть надавати “приховані ентузіасти” в командах. Окрім того, залучення всіх співробітників до процесу обговорення замість того, щоби здійснювати його за зачиненими дверима, додало команді надзвичайної енергії вже після того, як ми зафіксували візію. Це було дуже, дуже цікаво». — Боріс Дібольд, головний технічний директор компанії «Seven Senders» (Берлін, Німеччина).
У Таллінні керівник з питань споживчого досвіду компанії «transferwise» Джефф МакКлеланд також відзначив, що планування та перепланування дорожньої карти продукту є копіткою та об’ємною роботою, до якої залучаються всі команди:
«Одна з наших практик — щоквартальне планування — відбувається доволі інтенсивно. У компанії 1200 працівників, і ми наново визначаємо свої плани кожні три місяці. Чому? Тому, що це не лише планування, а й механізм комунікації. Щонайменше раз на квартал ті чи інші команди обговорюють зі спорідненими командами (тобто тими, що працюють, так би мовити, слідом за ними) те, що вони збираються робити далі. Отже, команди отримують корисний зворотний зв’язок і намагаються узгодити деякі міжкомандні зобов’язання. В ідеалі кожна команда вважається незалежною, але в реальності так ніколи не буває. Жодна команда не є по-справжньому незалежною, тому їм доводиться координувати свої наміри і плани». — Джефф МакКлеланд, керівник з питань споживчого досвіду компанії «TransferWise» (Таллінн, Естонія)
Складно створювати дорожні карти продукту у швидко змінюваних середовищах — а саме в таких умовах зазвичай функціонують стартапи і скейлапи. Сама по собі метафора «дорожня карта» створює хибне відчуття визначеності. Вона натякає, що майбутнє продукту зафіксоване, що всі розвилки, перехрестя та бічні виїзди відомі заздалегідь, і команді залишається тільки вправно просуватися до цілі. Просто введи місце призначення у Waze, увімкни сповіщення про небезпеки та стан дорожнього руху — і вперед! Але реальність є інакшою.
Команді з розробки продукту, особливо на ранніх етапах життєвого циклу бізнесу, майбутнє здебільшого невідоме, оскільки пріоритети весь час змінюються і є багато непідтверджених припущень, що потребують перевірки. Просування дорожньою картою з неперевіреними гіпотезами природно призводить до виникнення нових ідей. Це тягне за собою змінення пріоритетів, а значить, і створення нової версії дорожньої карти. Заплановані функції та релізи продукту відкладаються або взагалі зникають, що викликає розчарування зацікавлених сторін. У результаті страждають надійність і довіра, і відбувається це завдяки тому, що люди просто роблять те, що їм належить робити: випробовують якісь речі з метою дізнатися, працюють вони чи ні.
Рішення всіх цих проблем вимагає трьох важливих змін, що утворюють дорожню карту продукту, яка фіксує основні експерименти і результати на часовому графіку. Якщо ви почнете розглядати свою дорожню карту як план отримання уроків і результатів із прогнозом, що стає все більш розпливчастим у майбутньому, то зможете значно зменшити розчарування зацікавлених сторін.
Перший крок до перепроєктування дорожньої карти продукту — зосередженість на експериментах. Основне завдання стартапів, як відомо,— за допомогою ощадливих експериментів з’ясувати, що працює, а що ні. Дослідження є основним режимом роботи від стадії Ініціації до стадії Стабілізації. Це означає, що коли команда стартапу щось позначає на дорожній карті, то замість додання функцій продукту з датою її постачання додаються експерименти з датами навчання.
Замість того, щоби обіцяти споживачам, що, наприклад, iOS-версія застосунку стане доступною до певної дати, краще спочатку з’ясувати, який підхід треба обрати для мультиплатформної розробки. Ми й гадки не матимемо, скільки знадобиться часу на iOS-версію нашого продукту, якщо спершу не дізнаємося, як вести розробку для різних пристроїв. Інакше кажучи, краща обіцянка — мати рішення щодо мультиплатформної розробки до певної дати. Так само і всі інші дати, що ви повідомляєте зацікавленим сторонам за допомогою дорожньої карті, мають бути датами завершення експериментів та отримання важливих даних.
Інший крок у перепроєктуванні дорожньої карти продукту — найбільш актуальний для скейлапів, ніж стартапів,— полягає у формуванні мислення з позиції радше комерційних цілей і споживчих переваг, ніж окремих функцій. Зосередьтеся не на вихідних даних, а на результатах, обмірковуючи, який тип результатів означатиме просування до вашої метрики Полярної зірки. Замість обіцянок конкретних рішень, що складаються із функцій, ви надаєте обіцянку приділити увагу певним темам, що відкривають перспективу досягнення переваг.
Наприклад, повідомляючи про перевагу типу «завантаження та перегляд функцій, використовуваних на iPhone», ви маєте утриматися від обіцянок конкретних технологічних рішень. Що довше ви чекатимете перед повідомленням про конкретне рішення, то більше інформації встигнете отримати, щоб обрати найкраще. Дехто називає подібний підхід «цілеспрямованою дорожньою картою». Дати, що ви повідомляєте зацікавленим сторонам, є датами, до яких ви плануєте вирішити важливі проблеми, не конкретизуючи, як саме ви це зробите.
Третій крок перепроєктування дорожньої карти продукту, що допоможе вам вирішити проблему постійно змінюваних пріоритетів,— це застосування планування за методом хвилі, що накочується (рис. 18.1). Вам треба поділити дорожню карту на кілька частин, зазвичай — на три. Вони отримують назви «Зараз», «Наступне» та «Пізніше», або «Короткострокове», «Середньострокове» та «Довгострокове». Перша частина охоплює період від одного до чотирьох тижнів; друга — від одного до трьох місяців, й остання — це все, що лежить за горизонтом щонайменше у три місяці. (Ці часові діапазони можуть за потреби відрізнятися, але принцип залишається тим самим.)
Якщо ви поділите дорожню карту продукту на три не надто визначені часові проміжки та призначите тим проміжкам невиразні назви замість конкретних дат і місяців, будь-хто зрозуміє, що ви цілком упевнені у тому, над чим працюєте зараз, менш упевнені, яка робота виявиться наступною та досі не впевнені стосовно всіх експериментів і результатів, запланованих на пізніший період.
У Парижі команда аналітиків користувацького досвіду розповіла мені, що планування за методом хвилі, що накочується,— це золота середина між тим, що хочуть почути зацікавлені сторони, і тим, що готова пообіцяти команда розробників.
Источник: ain.ua
Самые актуальные новости - в 
