беклог – последние статьи и новости

Багато хто з нас є візіонерами. Як незалежні та корпоративні підприємці, засновники та лідери організацій і генератори ідей, ми уявляємо собі речі, які ще не існують. Ми прагнемо, щоби ті речі перетворилися на реальність. Про книжку Саме тому книжка «Стартап, скейлап, скрюап» буде актуальною для засновників стартапів, членів їхніх команд, а також для незалежних і корпоративних підприємців та бізнес-лідерів. Автор книжки Юрген Аппело базується не тільки на власному досвіді з керування стартапами, але й на дослідженнях та інтерв’ю, проведених у багатьох країнах Європи. Головна мета автора – уніфікація методів та інструментів, які використовують стартапи і скейлапи . До вашої уваги пропонуємо уривок із книжки «Стартап, скейлап, скрюап». Танго ентропії Існують сотні книжок про стартапи та скейлапи, і майже всі вони розповідають про американські компанії. Гадаю, що останнім часом я хіба не двадцять разів почув або прочитав історію заснування Airbnb. Це дійсно гарна історія. Вона проста, видатна та добре запам’ятовується. Але ніхто чомусь не пише про Booking.com, що напряму конкурує з Airbnb і принаймні вп’ятеро більший. То чому? Можливо, тому що штаб-квартира Booking знаходиться в Амстердамі, а не в Сан-Франциско. Її історія не зосереджена навколо Кремнієвої долини, де часто шукають натхнення багато сучасних авторів. Отже, я вирушив в Амстердам, аби дізнатися в Мелані Весселс, agile-коуча з Booking.com, як її колеги в компанії виконують свою роботу. Мелані Весселс: Ми прагнемо хаосу, щоби команди могли запроваджувати інновації, залишалися творчими та незалежними. Але ми також наполягаємо на деяких формах організації, тому існують межі, у яких команди можуть усе це робити. Є декілька речей, які ми вважаємо обов’язковими для всіх команд. Ми називаємо їх agile-основами Booking. Їх лише три: agile-ретроспектива, щоденний стендап і беклог продукту. Це ті практики, що їх, на нашу думку, необхідно додержуватися кожній команді. Беклоги Я обожнюю беклоги . Я складаю беклоги для багатьох речей. Наприклад, одне з моїх хобі – відстежувати популярні науково-фантастичні та фентезійні книжки, що отримали літературні нагороди і мають високий рейтинг. Мені подобається відвідувати спеціалізовані вебсайти у пошуках цікавих творів, про які я раніше не знав, і виписувати їхні назви, імена авторів, дати публікації та приналежність до тієї чи іншої серії. Ось чому в моєму «читацькому беклозі» понад чотири тисячі назв книжок. Я розглядаю їх як варіанти або пропозиції для майбутнього читання. Ви також можете вважати його моїм особистим списком бажань. І це дійсно список бажань, оскільки я цілком розумію, що не зможу купити і прочитати всі ті книжки. У мене забагато інших справ. Також я маю перелік з понад тисячі місць на планеті, які я хотів би відвідати до того, як помру. І я також працюю над «беклогом найбожевільніших беклогів», що забирає у мене найбільше часу. До всіх беклогів слід ставитися подібним чином – хай то беклоги продукту, беклоги контенту, беклоги поліпшень чи будь-які інші списки незапланованих робочих завдань. Це насправді списки бажань, а не списки справ. У літературі з управління проєктами беклог продукту часто визначають як «список функціональних особливостей, потрібних у продукті» (а це вже список справ!) Але подібне визначення хибне. Беклог – це список функціональних особливостей, бажаних у продукті (тобто список бажань). Ваш апетит завжди більший, ніж можливості. Я бажаю прочитати чотири тисячі книжок і відвідати тисячу місць на п’яти континентах, але знаю, що цього не станеться через брак можливостей задовольнити мій безмежний апетит до читання та подорожей. Так само багато функцій у беклозі продукту не будуть реалізовані, тому що ми завжди маємо більше ідей і вимог, ніж можемо колись здійснити. Беклог продукту є інструментом, що зазвичай відповідає потоку формулювання гіпотез в інноваційному вирі, бо містить ідеї, що можуть виявитися вартими реалізації. Беклог продукту Беклоги потрібні стартапам і скейлапам як освіта дітям і дорослим. Так само як у Booking.com і Pipedrive, у моєї команди теж є беклог продукту. Ми використовуємо його, щоби додавати ідеї, здатні підштовхнути нашу метрику Полярної зірки. Ми користуємося ним для узгодження функцій із нашим колесом ціннісної пропозиції. Ми навіть додали до нього деякі думки щодо створення версії застосунку для iOS (очевидно, на майбутнє). Ми ведемо цей список бажань, щоби уникнути марнування зайвих розумових здібностей на утримання всіх гарних пропозицій у голові. Замовляючи нову книжку, я обираю ту чи іншу з мого ретельно складеного списку бажань. Я не марную часу, намагаючись пригадати безліч варіантів. Подібним чином, коли ми обираємо нові функціональні особливості, щоби включити їх у план, то звертаємося до беклога продукту, а не до колективних спогадів команди. Як працювати з беклогом Беклоги продукту існують у багатьох формах. Є шалена кількість доступних професійних інструментів, що полегшують створення та ведення беклогів. Але ви можете так само використати простий документ, базу даних, стікери на дошці або індексні картки у файловій системі. Залежно від обраного вами інструмента ви можете пріоритизувати функцій згідно різних критеріїв, об’єднати функції в логічні угрупування та подбати, щоби пропозиції у списку були взаємопов’язані та відповідали візії продукту. Незабаром після успішного завершення акціонерного краудфандингу, коли навесні наша команда зібралася на позаофісну зустріч у Барселоні, ми вирішили, що нам потрібен новий дедлайн. Краудфандингова кампанія добре прислужилася як спосіб зосередити командні зусилля. Після надходження грошей нам бракувало конкретної дати для роботи в певному напрямку та утримання організованості. Адже метрика Полярної зірки допомагає нам зосереджувати увагу на певних ділянках роботи, а дедлайн надає відчуття терміновості. Ми вирішили, що велика конференція Agile-2018 у Сан-Дієго, на якій мене запросили виступити на початку осені, стане для нас наступною великою віхою. Так народився проєкт «Сан-Дієго». Аби надати йому стартове прискорення, я створив новий беклог у вигляді таблиці. Стовпці являли собою перелік різних елементів нашої платформи (меню, користувачі, практики, вказівки), а рядки відображали різні типи поведінки користувача (пошук, публікація, оцінювання). Розглядаючи кожну клітинку в таблиці, я міг досліджувати, як різні функціональні особливості досягатимуть узгодженості в нашій платформі, якщо ми реалізуємо їх із огляду на цілий рядок або стовпець. Наприклад, якими мають бути ті ділянки, у яких здійснюється пошук? І якими є різновиди користувацької поведінки, що потрібні нам для складання вказівок? Я призначив рівень терміновості (високий, середній, низький) і рівень важливості (один чи два бали) кожній клітинці в таблиці. Беклог продукту виглядав складним, але насправді система була досить простою. Щотижня члени команди отримували бали залежно від того, над скількома функціями вони завершили роботу. Завдяки діаграмі вигорання завдань ми могли відстежувати графік тренду зароблених балів, і це надавало нам відчуття наближення до дедлайну проєкту. Користувацька історія У своєму беклозі продукту ви маєте викласти ідеї щодо функцій як користувацькі історії. Користувацька історія – це короткий і простий опис функції, зроблений із точки зору особи, якій потрібна ця функція (зазвичай це користувач). Для кожної користувацької історії є сенс задокументувати ощадливого персонажа та частину колеса ціннісної пропозиції, для якої ви створюєте бажану функцію. Деякі експерти пропонують розрізняти мінімально комерційно цінні функції (minimum marketable features, або MMF) і звичайні користувацькі історії. Автори Марк Денне і Джейн Клеланд-Хуанг визначили MMF як найменшу одиницю функціоналу, що має внутрішню ринкову цінність. Опис MMF має зосереджуватися на перевагах, які користувач отримає завдяки цьому функціоналу, та критеріях прийнятності, що нададуть вам можливість перевірити, чи дійсно досягнуті ці переваги. Ви можете думати про MMF як про будь-які функції, про які радісно повідомите своїм споживачам у блозі, поштовій розсилці чи (якщо хтось більш ніж удвічі молодший за мене) у відео в Snapchat або Instagram. Не вартий оприлюднення лише функціонал низького рівня, що є частиною (більшого) MMF. Історія експерименту Ще один елемент беклога продукту – ощадливий експеримент чи історія експерименту. Ощадливі експерименти є гіпотезами щодо цінності, які ви бажаєте перевірити. Але коли ви переносите експерименти з беклога продукту до канбан-дошки, пам’ятайте, що історії експерименту не можна вважати завершеними, поки вони не підтверджені як гіпотези. Щоби домогтися цього, команді знадобиться застосувати деякі інструменти підтвердженого навчання, як-от інтерв’ю зі споживачами чи спліт-тести. Існують інші типи елементів, що можуть входити до беклога продукту: звіти про баги, запити команди, історії покращень, технічна робота, піки, картки подяк тощо. Якщо фахова самоорганізована команда оптимізує свою продуктивність (у роботі із функціями) та навчання (в експериментах), їй належить самій вирішувати, як тримати під контролем все інше, що необхідно робити. Команди в різних компаніях беруться до цієї справи по-різному – про це розповіли мої співрозмовники в TransferWise і Taxify. Історія TransferWise Джефф Макклеланд – керівник з питань споживчого досвіду у таллінському відділенні TransferWise. Він поділився зі мною досвідом, набутим протягом тривалого часу, коли його компанія віддавала функціям перевагу над архітектурою: TransferWise – лондонська онлайн-служба грошових переказів, заснована в січні 2011 року естонцями Крісто Кярманном і Тааветом Хінрікусом. Компанія підтримує більше 750 валютних маршрутів по всьому світу. Джефф Макклеланд: Ми працювали над цим приблизно сім років і завжди були орієнтовані на продукт і на клієнта. Ми прагнули дуже швидко рухатися у багатьох напрямках. Отже, насправді в нас був дуже простий продукт, але ми намагалися завоювати багато нових територій. У кожній країні нам було потрібно знайти місцевий банк-партнер. Нам була потрібна співпраця з місцевими регуляторними органами. Також було необхідно виконати всю технічну роботу в тих банках, і кожен банк відрізнявся від інших. Це означало, що доводилося багато чого створювати «з нуля», і так само з усіма платіжними методами, які ми почали підтримувати. Із технічної точки зору ми наражалися на ризик звести хатинку з карт. Ми вкладали всю свою енергію в максимально швидку роботу, щоби надати те, чого прагнули наші клієнти. Але в кінцевому рахунку це принесло нам купу неприємностей. Наразі ми прикладаємо дуже багато зусиль для виправлення нашого легасі-коду та витягання інформації із цієї монолітної бази даних до мікросервісів. Звісно, ми могли би зробити це раніше. Тепер нам доводиться приділяти багато часу інжинірингу та сповільнювати темпи, щоби побудувати кращу основу в той спосіб, що допомагатиме нам у наступні п’ять років. Гадаю, усі компанії зазнають труднощів із цими типами рішень: коли треба прискорюватися та розширюватися, а коли – уповільнюватися та стабілізуватися. *** Ведення беклогу нагадує одвічний танець двох протилежних партнерів – порядку та хаосу. Результатом стає не збільшення визначеності, а рух крок у крок із постійними змінами. Коли ви усвідомите, що дійсно ведете беклог, то, можливо, почнете більш прискіпливо ставитися до ідей численних фіч, що ніколи не будуть реалізовані. Можливо також, що ви вдаватиметеся до періодичного очищення свого «списку бажань». Саме це я нещодавно зробив із тими чотирма тисячами книжкових назв.

No items found.