Статті
Стендапи – марна трата часу
Як провести справді корисну зустріч продуктової команди
3 березня, 2020
Енді Джонс
Інвестор у Unusual Ventures

Енді Джонс, інвестор у Unusual Ventures, колишній growth- та продакт-менеджер Facebook, Twitter, Quora, експрезидент Wealthfront, вважає, що часті стендапи, на яких мало приділяється уваги прийняттю реальних рішень, насправді не допомагають, а затягують процес розробки та запуску продукту. Він пропонує замінити стендапи та статуси на ефективніші зустрічі.

Оригінал: Why “Standups” are Useless and How to Run Great Product Team Meetings

Більшість зустрічей – марна трата часу. А статуси – зустрічі-планерки, де всі збираються і розповідають, над чим вони зараз працюють – очолюють чарти непотрібності. Іронічно, але саме розмови про роботу – перше, що стає на заваді реальній продуктивній роботі. Крос-функціональна команда (продакт-менеджери, дизайнери, розробники, представники маркетингової групи і т.д.), що працює над новим продуктом, насправді отримує мало корисного від статусів.

“Стендапи” вас не врятують

Звичайно, буде дуже самовпевнено сказати, що я знаю рецепт ідеальної зустрічі крус-функціональної продуктової команди. Але я із впевненістю можу заявити, що найгірший вид статусів – це стендапи. І радію, що деякі команди починають їх проводити вже не щодня, а кілька разів на тиждень. Хоча всі ці популярні методології, в першу чергу Agile, так сильно закохали нас у стендапи, що навіть Slack вбудував у свій функціонал таку фічу.

У реальному ж світі більшість стендапів скочуються до кежуал бесід – вони мало стосуються роботи і аж ніяк не допоможуть запустити продукт швидше.

Єдиний час, коли стендап – це насправді корисна зустріч – перед самим запуском продукту. Це той час, коли вам необхідно впевнитися, що всі ланки готові. Чи ми готові запускати A/B тести? Чи готові хлопці з маркетингу публікувати пост про запуск і пушити PR-інструменти? Чи є у служби обслуговування клієнтів необхідні сценарії, аби відповідати на питання, які з’являться відразу після запуску?

Проведіть стендап, коли наближаєтесь до запуску, аби переконатися, що війська “готові звільнити Нормандію”. Тільки тоді це буде корисно.

У будь-якому іншому випадку – це найчастіше марна трата часу. Тому що більша частина розробки продукту складається з: 1) власне написання і компонування коду (building), 2) прийняття рішень. Перший пункт очевидний (команда зайнята власне створенням продукту), але другий пункт – це те, що ми розглянемо, бо на мітапах якраз і займаються обговоренням рішень (принаймні мають цим займатися).

Вирішуйте

Розробка нового продукту вимагає, аби приймались сотні рішень. Серед основних і очевидних:

  • Що обов’язково для MVP продукту (мінімально життєздатна версія)?
  • Хто буде головним дизайнером?
  • Як ми будемо просувати / продавати нову функцію?
  • Чи будемо ми проводити A/B тести?
  • Які наші цілі та ключові показники?

А ще існує довгий перелік рішень середнього та малого розміру, які потрібно приймати попутно. Наприклад:

  • Нам потрібно створювати новий компонент інтерфейсу, чи ми можемо використати якийсь із наявної бібліотеки?
  • Чи варто будувати функцію “X”, якщо вона потрібна лише на 3 наступні тижні?
  • Проводимо тест 50/50 чи A/B?
  • Ми доставляємо на всі три платформи паралельно: Інтернет, iOS та Android?
  • Чи можемо ми “забити” на Android, якщо там лише 5% наших користувачів?

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

Важкі (тобто великі) рішення, як правило, приймаються в ході проекту раніше (Що необхідно для MVP?), а середні та менші – як правило, пізніше (Чи можемо ми спростити компонент інтерфейсу “X”, аби скоротити бек-енд розробки на кілька днів?). Загальна кількість рішень наближається до нуля, із наближення продукту до запуску.

Команда розблоковується, коли приймаються рішення.

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

Методологія Google Design Sprint – чудовий приклад того, як команда може приймати важливі рішення швидше, а отже швидше отримати перший прототип, який можна протестувати.

Ще про стендапи

Перш ніж поділитися найефективнішим, на мою думку, форматом зустрічей для продуктових команд, я ще трохи розберу всюдисущий “стендап”.

Про що учасники стендапу (тобто всі в команді) розповідають на стендапах?

  • Над чим я працював учора?
  • Над чим я працюю сьогодні?
  • Які проблеми мене блокують?

З цим форматом є кілька великих проблем.

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

Частина команди може бути заблокована з двох причин: очікування (наприклад, бекенд розробка чекає ясності в ТУ зовнішнього інтерфейсу) чи відсутність прийнятого рішення. І тоді немає змісту на стендапах говорити,  «Я заблокований через «X», потрібно сказати: “давайте зберемось разом і приймемо рішення по Х, аби ми могли рухатись уперед”.

На стендапах не відводиться час на прийняття рішень. Там лише повідомляють про блокування, а не вирішують проблему. Одного повідомлення мало, потрібно приймати рішення.

Простий план, що дозволить рухатись уперед

Я маю просту альтернативу, яка дозволить проводити продуктивніші зустрічі продуктової команди та покращить цикли розробки продукту. На мою думку, підкріплену роками досвіду, найефективніший формат зустрічей продуктової команди (та і для більшості зустрічей взагалі) такий:

  1. Виконати: хто виконує яку ключову задачу, та в який термін.
  2. Вирішити: які рішення необхідно прийняти?

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

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

Збір відкритих запитань

Щоб підготуватися до проведення ефективної зустрічі продуктової команди, я б запитав у ліда кожної з команд (інженерної, маркетингової, дизайн-команди тощо), яке рішення їм потрібно прийняти. Зібрані запитання вніс у порядок денний. Паралельно склав би список запитань, що з’явились під час мітингів з прийняття рішень. З обидвох блоків зібрав би такий план:

Виконати:

  1. (Джош) Дає останню версію iOS-дизайну Теммі до 13.09
  2. (Діанна) Надсилає маркетинговий текст для перевірки на відповідність до 15.09
  3. (Енді) Синхронізує з відділом data science пункти A/B тесту до 15.09.
  4. Тощо.

Вирішити:

  1. Нам слід включити 3-5-денне покращення UI-дизайну як частину запуску MVP чи ні?
  2. Варто просити про ще одного бек-енд-інженера чи у нас немає паралельних процесів, які можна закрити за допомогою додаткових ресурсів до дати запуску?
  3. Хто може взяти на себе customer development для наступного етапу нашої дорожньої карти? Чи варто нам взагалі починати його, а чи відкласти на тиждень-два?
  4. Тощо.

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

Решту зустрічі (на що зазвичай відводили 60 хвилин) ми витрачали на прийняття колективних рішень. Часто кілька членів команди вже обговорили певні питання до зустрічі і вони могли ознайомити всіх учасників з контекстом і запропонувати рішення. У цих випадках питання вирішувались за лічені секунди або кілька хвилин. В інших ситуаціях (приблизно 30% випадків) рішення вимагало широкого обговорення.

Тоді я просив 2–3 найздібніших і найвідповідніших членів команди сформувати швидку робочу групу пізніше цього ж або наступного дня, щоб обговорити проблему і запропонувати рішення. Про їхню рекомендацією решту колективу повідомляли  електронною поштою, через Slack або особисто на наступній зустрічі продуктової команди. Фактично у нас паралельно проходило кілька одночасних зустрічей з прийняття рішень. Так ми постійно рухалися до зменшення невизначеності.

(Використовуйте зустрічі команди та обговорення, щоб швидко усунути запитання без відповідей)

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

Журнал рішень

Слід також звернути увагу на журнал прийняття рішень як частину такого формату зустрічей. Я пропоную використовувати єдиний документ Google, щоб зберігати записи про план кожної попередньої зустрічі і прийняті рішення. Це стане в нагоді у процесі «розбору польотів» («post mortem») після запуску продукту – для оцінки того, що команда зробила добре, а що могла краще. Часто губиться контекст прийнятих рішень, особливо якщо їх приймали ізольовано кілька людей та/або кілька тижнів чи місяців раніше.

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

Підсумок

Формат стендапу, популяризований в методології Agile, на жаль, недостатньо пристосований для ефективного розвитку продукту в команді. Цикли розвитку затягуються через те, що рішення приймаються повільно. Якщо замінити щоденні стендапи на менш часті мітинги, продуктові команди зможуть заощадити багато витраченого часу і створювати продукти швидше.

avatar
Енді Джонс
Інвестор у Unusual Ventures
Колонка

У нас є ще дещо для вас