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

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

Про книжку

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

Головна мета автора — уніфікація методів та інструментів, якы використовують стартапи та скейлапи Компанії, які показують значний ріст.

До вашої уваги пропонуємо уривок з книжки «Стартап, скейлап, скрюап».

Беклог продукту

Беклоги потрібні стартапам і скейлапам як освіта дітям і дорослим. Так само як у Booking.com і Pipedrive, у моєї команди теж є беклог продукту. Ми використовуємо його, щоби додавати ідеї, здатні підштовхнути нашу метрику Полярної зірки. Ми користуємося ним для узгодження функцій із нашим колесом ціннісної пропозиції. Ми навіть додали до нього деякі думки щодо створення версії застосунку для iOS (очевидно, на майбутнє).

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

Як працювати з беклогом

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

Незабаром після успішного завершення акціонерного краудфандингу, коли навесні наша команда зібралася на позаофісну зустріч у Барселоні, ми вирішили, що нам потрібен новий дедлайн. Краудфандингова кампанія добре прислужилася як спосіб зосередити командні зусилля.

Після надходження грошей нам бракувало конкретної дати для роботи в певному напрямку та утримання організованості. Адже метрика Полярної зірки допомагає нам зосереджувати увагу на певних ділянках роботи, а дедлайн надає відчуття терміновості. Ми вирішили, що велика конференція Agile-2018 у Сан-Дієго, на якій мене запросили виступити на початку осені, стане для нас наступною великою віхою. Так народився проєкт «Сан-Дієго».

Аби надати йому стартове прискорення, я створив новий беклог у вигляді таблиці. Стовпці являли собою перелік різних елементів нашої платформи (меню, користувачі, практики, вказівки), а рядки відображали різні типи поведінки користувача (пошук, публікація, оцінювання).

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

Користувацька історія

У своєму беклозі продукту ви маєте викласти ідеї щодо функцій як користувацькі історії. Користувацька історія — це короткий і простий опис функції, зроблений із точки зору особи, якій потрібна ця функція (зазвичай це користувач). Для кожної користувацької історії є сенс задокументувати ощадливого персонажа та частину колеса ціннісної пропозиції, для якої ви створюєте бажану функцію.

Деякі експерти пропонують розрізняти мінімально комерційно цінні функції (minimum marketable features, або MMF) і звичайні користувацькі історії. Автори Марк Денне і Джейн Клеланд-Хуанг визначили MMF як найменшу одиницю функціоналу, що має внутрішню ринкову цінність.

Опис MMF має зосереджуватися на перевагах, які користувач отримає завдяки цьому функціоналу, та критеріях прийнятності, що нададуть вам можливість перевірити, чи дійсно досягнуті ці переваги. Ви можете думати про MMF як про будь-які функції, про які радісно повідомите своїм споживачам у блозі, поштовій розсилці чи (якщо хтось більш ніж удвічі молодший за мене) у відео в Snapchat або Instagram. Не вартий оприлюднення лише функціонал низького рівня, що є частиною (більшого) MMF.

Історія експерименту

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

Команди в різних компаніях беруться до цієї справи по-різному — про це розповіли мої співрозмовники в «TransferWise» і «Taxify».

Історія TransferWise

Джефф МакКлеланд — керівник з питань споживчого досвіду у таллінському відділенні TransferWise. Він поділився зі мною досвідом, набутим протягом тривалого часу, коли його компанія віддавала функціям перевагу над архітектурою:

TransferWise — лондонська онлайн-служба грошових переказів, заснована в січні 2011 року естонцями Крісто Кярманном і Тааветом Хінрікусом. Компанія підтримує більше 750 валютних маршрутів по всьому світу.

Джефф МакКлеланд: Ми працювали над цим приблизно сім років і завжди були орієнтовані на продукт і на клієнта. Ми прагнули дуже швидко рухатися у багатьох напрямках. Отже, насправді в нас був дуже простий продукт, але ми намагалися завоювати багато нових територій.

У кожній країні нам було потрібно знайти місцевий банк-партнер. Нам була потрібна співпраця з місцевими регуляторними органами. Також було необхідно виконати всю технічну роботу в тих банках, і кожен банк відрізнявся від інших. Це означало, що доводилося багато чого створювати «з нуля», і так само з усіма платіжними методами, які ми почали підтримувати.

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

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

Гадаю, усі компанії зазнають труднощів із цими типами рішень: коли треба прискорюватися та розширюватися, а коли — уповільнюватися та стабілізуватися.

***

Ведення беклогу нагадує одвічний танець двох протилежних партнерів — порядку та хаосу. Результатом стає не збільшення визначеності, а рух крок у крок із постійними змінами. Коли ви усвідомите, що дійсно ведете беклог, то, можливо, почнете більш прискіпливо ставитися до ідей численних фіч, що ніколи не будуть реалізовані. Можливо також, що ви вдаватиметеся до періодичного очищення свого «списку бажань». Саме це я нещодавно зробив із тими чотирма тисячами книжкових назв.