Тримайте замітку про впровадження культури експериментів. Якщо що, до речі – це скоріше процесно-комунікаційна складова, не технічна. Якими технічними засобами її підтримувати, вирішувати вам залежно від вашого “ІТ-зоопарку”, я описую загальні принципи.
Точка ️ – ви команда-фічегенератор, у якій роблять завдання за планом.
Навіщо вам переходити в експерименти, тут писати не буду.
Одразу до справи: хочемо в Точку ️, де ви маєте окремий процес брейншторму і формування гіпотез, оцінювання цих гіпотез (включно із зовнішніми джерелами), планування швидких експериментів, оцінювання результатів і наповнення беклогу завданнями вже за результатами цих експериментів.
Тут я беру невелику команду, яка сама і займається експериментами, і сама ж робить потім core продукт. Від цього вже потім можна перейти до поділу growth/core команди, ділити команду на кілька продуктів тощо.
Одразу кажу: алгоритм не мій, я тільки його виконувала разок, але гуглення не допомогло знайти мені джерело, тому хто зможе мені вказати автора, буду вдячна. Може я навіть щось напридумувала, ну дуже давно це було.
Крок 1️⃣ Аналіз історичних даних. Нічого не змінюємо в поточному процесі
Беремо попередні кілька релізів і виписуємо: зліва фіча, праворуч – скільки вона принесла. Це іноді непросто, але корисно зрозуміти, як оцінити щось зроблене.
Знаходите наявні дані, шукаєте як порахувати економічний ефект вашої роботи за попередні 2-3 місяці. Сумно, якщо в мінус працювали весь цей час, я і таке бачила – але це тільки доп. аргументи, щоб ввести культуру експериментів.
Крок 2️⃣ Додаємо пост-аналіз у процес
Під час написання ТЗ і обговорення впровадження будь-якої зміни ви плануєте, як можна порахувати її економічний ефект після її впровадження.
Наприклад, позначаєте, що ця заявка на продукт прийшла з нової кнопки або з нового сервісу. І включаєте в процес аналізу запуску (або створюєте процес аналізу запуску) підрахунок результатів після. Потроху діліться результатами з командою і керівником.
Крок 3️⃣ Додаємо прогнозування, скільки принесе фіча
І в пост-аналізі починаємо порівнювати, наскільки сильно не влучили в прогноз, і через що, щоб кожну ітерацію покращувати процес. Вчимося прогнозувати без галюцинацій.
Крок 4️⃣ Вибираємо спосіб скорингу
Загалом будь-який, важливо щоб було щось про гроші і ключову метрику і про складність/ресурси/терміни виконання. Потроху між наявними завданнями починаємо вибирати з урахуванням цього скорингу. Продовжуємо порівнювати прогноз із результатами.
Тут маленька пауза для коментаря. На цьому етапі ви вже можете потихеньку вхідні запити від керівника/стейкхолдерів пооцінювати. Як подавати: ми хочемо розуміти, як зробити кожну фічу так, щоб вона реально нам щось заробила, і ось я приблизно так оцінюю розробку, а ось так – скільки ми заробимо. Нам норм таку фічу брати? Які параметри хочеш уточнити в моделі?
Крок 5️⃣ Експерименти
У вас набралася історія (десь квартал, наприклад) і ви можете нормально скорити і вибирати поточні завдання. Тепер нарешті підходимо до експериментів !
Коли ви бачите в беклозі фічу, яка велика, складна, потенційно смачна, але дорога в ресурсах – пропонуєте зробити спочатку експеримент. Не починайте зі складного, мій перший експеримент був відправленим по сегменту вручну листом із заявкою на новий продукт, яку заповнило рівно 6 осіб. Ми пішли подумати і вийшли з новим продуктовим УТП, добре заробили.
За цей час стейкхолдери вже звикли (в ідеалі), що рахувати гроші від фічі до – корисно. Розкажіть їм, як ваш експеримент допоможе підтвердити цінність і уточнити грошову вигоду, щоб ваша команда швидше наважилася братися за такого “слона”.
Далі – той самий принцип, по кроках.
Крок 6️⃣ Розділіть процеси
Окремо експерименти, окремо розробка вже відносно перевіреного. У нас з’явилося на цей момент 2 беклоги і 2 планування. У спринт без перевірки через дешевий експеримент йшли завдання на 1-5 годин роботи (коли довше планувати експеримент, а робити точно треба) і баги. У процесі планування експериментів генеруєте і накидаєте будь-які гіпотези, спираючись на те, що вам треба перевірити, придумуєте експерименти і потім скорите складність їх виконання.
Крок 7️⃣ Генерація нових гіпотез
Відходьте від того, щоб гіпотези перевіряли цінність запропонованих фіч. Починаєте генерувати їх за цілями – як виростити конверсію? Як збільшити дохідність? Загалом реальні проблеми, які є у продукту. Звідти вже накидаєте експерименти і їх скорите, а стейкхолдерів потихеньку привчаєте приносити проблеми і завдання “виростити метрику Х”, а не “зробіть кнопку Y”. Таке все одно буде, але у вас уже буде процес, як це перетворити на хороший експеримент і завдання.
Якщо порівняєте цю інструкцію з тим, що було вище про зміни, – побачите, що такий алгоритм залишає вам свободу говорити про зміни тоді, коли ви відчуваєте, що набрали достатньо фактичної інформації, впевнені у своїх силах, і розумієте ситуацію у вас у компанії та як терміново вам потрібні ці зміни.
Може, у вас стейкхолдери – експерти й самі класно прогнозують, що саме рухатиме продукт уперед, самі – тоді ви посилюватимете їхні прогнози експериментами й даватимете їм більше інформації для ще крутіших ідей. А комусь це допоможе не витрачати ресурси команди на нереалістичні прожекти, і там важливо, що ви не затіваєте масштабну переробку всього, а дієте поступово.
PS Написала і зрозуміла, що до кожного кроку може виникнути багато запитань – нумо обговорювати в коментарях!
Тільки, щоб я не захлинулася, питання на кроці 7, пов’язані з тим, як генерувати життєздатні гіпотези та НЕ генерувати завідомо провальні, як дешево та швидко їх перевіряти аж до розроблення повноцінного рішення і навіть MVP, я відразу переадресую.
