Юрген Аппело - відомий на весь світ тренер, розробник і підприємець, а такой автор “Менеджменту 3.0”. Його книжка «Стартап, скейлап, скрюап» базується не тільки на власному досвіді з керування стартапами, але й на дослідженнях та інтерв’ю, проведених в багатьох країнах Європи. Юрген розповідає про успіхи відомих стартапів, а ще об’єднує методи та інструменти, що успішно використовуються ними на основі практик, популяризованих lean- та agile-спільнотами. Він звертається до засновників стартапів і членів їх команд, а також для незалежних і корпоративних лідерів і навчає   вдосконалювати і трансформувати свої організації і команди. 

Публікуємо уривок із книги, де Юрген ділиться досвідом про те, як оптимізувати беклог продукту та як це роблять в успішних компаніях.

Наповнюйте беклог продукту мінімально життєздатними функціями і постійно оновлюйте історії експериментів. 

Існують сотні книжок про стартапи та скейлапи, і майже всі вони розповідають про американські компанії. Гадаю, що останнім часом я хіба не двадцять разів почув або прочитав історію заснування «AirBNB». Це дійсно гарна історія. Вона проста, видатна та добре запам’ятовується. Але ніхто чомусь не пише про «Booking.com», що напряму конкурує з «AirBNB» і принаймні вп’ятеро більший. То чому? Можливо, тому, що штаб-квартира «Booking» розташовується в Амстердамі, а не в Сан-Франциско. Її історія не зосереджена навколо Кремнієвої долини, де часто шукають натхнення багато сучасних авторів.

Отже, я  вирушив в  Амстердам, аби дізнатися в  Мелані Весселс, agile- коуча з «Booking.com», як її колеги в компанії виконують свою  роботу.

«Ми прагнемо хаосу, щоби команди могли запроваджувати інновації, залишалися творчими та незалежними. Але ми також наполягаємо на деяких формах організації, тому існують межі, у яких команди можуть усе це робити. Є декілька речей, які ми вважаємо обов’язковими для всіх команд. Ми називаємо їх agile-основами “Booking”. Їх лише три: agile-ретроспектива, щоденний стендап і беклог продукту. Це ті практики, що їх, на нашу думку, необхідно додержуватися кожній команді». Мелані Весселс, agile-коуч у Booking.com (Амстердам, Нідерланди)

Я обожнюю беклоги. Я складаю беклоги для багатьох речей. Наприклад, одне з моїх хобі — відстежувати популярні науково-фантастичні та фентезійні книжки, що отримали літературні нагороди і мають високий рейтинг. Мені подобається відвідувати спеціалізовані вебсайти у пошуках цікавих творів, про які я раніше не знав, і виписувати їхні назви, імена авторів, дати публікації та приналежність до тієї чи іншої серії. Ось чому в моєму «читацькому беклозі» понад чотири тисячі назв книжок. Я розглядаю їх як варіанти або пропозиції для майбутнього читання. Ви також можете вважати його моїм особистим списком бажань. І це дійсно список бажань, оскільки я цілком розумію, що не зможу купити і прочитати всі ті книжки. У мене забагато інших справ. Також я маю перелік з понад тисячі місць на планеті, які я хотів би відвідати до того, як помру. І я також працюю над «беклогом найбожевільніших беклогів», що забирає у мене найбільше часу. 

До всіх беклогів слід ставитися подібним чином — хай то беклоги продукту, беклоги контенту, беклоги поліпшень чи будь-які інші списки незапланованих робочих завдань. Це насправді списки бажань, а не списки справ. У літературі з управління проєктами беклог продукту часто визначають як «список функціональних особливостей, потрібних у продукті» (а це вже список справ!) Але подібне визначення хибне. Беклог — це список функціональних особливостей, бажаних у  продукті (тобто список бажань). Ваш апетит завжди більший, ніж можливості. Я  бажаю прочитати чотири тисячі книжок і відвідати тисячу місць на п’яти континентах, але знаю, що цього не станеться через брак можливостей задовольнити мій безмежний апетит до читання та подорожей. Так само багато функцій у беклозі продукту не будуть реалізовані, тому що ми завжди маємо більше ідей і вимог, ніж можемо колись здійснити. Беклог продукту є інструментом, що зазвичай відповідає потоку формулювання гіпотез в інноваційному вирі, бо містить ідеї, що можуть виявитися вартими реалізації. Сергій Анікін, головний технічний директор «pipedrive», розповів мені, яким чином його команди покладаються на беклог продукту та інші scrum-практики:

«Ми просто обрали стандартний scrum-процес, що був дуже добре визначений. Немає потреби витрачати енергію на пояснення, що це означає. Ви берете книжку або запрошуєте agile-коуча, і всі більш-менш розуміють, у чому полягають їхні обов’язки. Спочатку ви просто запроваджуєте процес, зосереджуєтеся на циклі зворотного зв’язку та тримаєте під рукою всі необхідні ролі та артефакти. Ви не можете почати командну роботу без продукт-менеджера та беклога продукту. Іноді люди кажуть: “О’кей, будемо працювати за scrum-методологією, ось наші інженери”. Але засновники не приділяють достатньо часу або певних зусиль для створення беклога продукту, унаслідок чого невдовзі команди не знають, що робити». Сергій Анікін, головний технічний директор «Pipedrive» (Таллінн, Естонія)

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

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

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

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

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

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

    Існують інші типи елементів, що можуть входити до беклога продукту: звіти про баги, запити команди, історії покращень, технічна робота, піки, картки подяк тощо. Якщо фахова самоорганізована команда оптимізує свою продуктивність (у роботі із функціями) та навчання (в експериментах), їй належить самій вирішувати, як тримати під контролем усе інше, що необхідно робити. Команди в різних компаніях беруться до цієї справи по-різному — про це розповіли мої співрозмовники в «transferwise» і «taxify». 

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

    «Ми працювали над цим приблизно сім років і завжди були орієнтовані на продукт і на клієнта. Ми прагнули дуже швидко рухатися у багатьох напрямках. Отже, насправді в нас був дуже простий продукт, але ми намагалися завоювати багато нових територій. У кожній країні нам було потрібно знайти місцевий банк-партнер. Нам була потрібна співпраця з місцевими регуляторними органами. Також було необхідно виконати всю технічну роботу в тих банках, і кожен банк відрізнявся від інших. Це означало, що доводилося багато чого створювати “з нуля”, і так само з усіма платіжними методами, які ми почали підтримувати. Із технічної точки зору ми наражалися на ризик звести хатинку з карт. Ми вкладали всю свою енергію в максимально швидку роботу, щоби надати те, чого прагнули наші клієнти. Але в кінцевому рахунку це принесло нам купу неприємностей. Наразі ми прикладаємо дуже багато зусиль для виправлення нашого легасі-коду та витягання інформації із цієї монолітної бази даних до мікросервісів. Звісно, ми могли би зробити це раніше. Тепер нам доводиться приділяти багато часу інжинірингу та сповільнювати темпи, щоби побудувати кращу основу в той спосіб, що допомагатиме нам у наступні п’ять років. Гадаю, усі компанії зазнають труднощів із цими типами рішень: коли треба прискорюватися та розширюватися, а коли — уповільнюватися та стабілізуватися». 

Джефф МакКлеланд, керівник з питань споживчого досвіду «TransferWise» (Таллінн, Естонія)

Того самого дня я проводив інтерв’ю з Рійною Ейнберг із «taxify». Протягом розмови я зауважив, що «taxify» використала дещо інший підхід до пріоритизації беклога продукту:

«Головний компонент — автоматизувати якомога більше. Не наймайте людей лише для того, щоби було кому займатися безглуздям, що ви накодували, чи тим, із чим ви ще не визначилися. Але будьте винахідливими та автоматизуйте стільки, скільки можете, тому що це зберігає невелику чисельність працівників і підтримує їхню мотивацію. Людям нецікаво працювати з бозна-чим. Їм нецікаво мати справу з легасі-кодом. Вони набагато більше зацікавлені створювати щось нове, якісь розумні речі, ніж щось виправляти. Ми автоматизуємо навіть нашу клієнтську підтримку. Ми обираємо не тих людей, які відповідають на заявки з якимсь посібником у руках або чимось на кшталт цього, а тих, які постійно розмірковують: “Гаразд, у нас є питання від клієнтів. Як нам покращити обслуговування? Що ще ми можемо автоматизувати?”. Це дуже характерна річ саме для естонських стартапів, тому що наші ресурси обмежені. У нас немає тих можливостей, що є у стартапів у деяких інших країнах, де вони можуть просто винайняти сотню нових працівників. Нам доводиться стикатися з проблемою обмеженої кількості фахівців. І тому ми намагаємося бути винахідливими».