Как Basecamp проверяла новую функцию поэтапно: практика Shape Up

Ситуация: идея нравится команде, но рано обещать её клиентам

Новая функция может выглядеть полезной на обсуждении, пока команда не пытается ею пользоваться. Если сразу объявить срок выпуска, эксперимент превращается в обязательство: приходится доводить до релиза даже то, что ещё не доказало свою ценность

Basecamp столкнулась с такой развилкой при создании Hill Charts, способа показывать неопределённость в ходе проекта. По описанию компании, команда ещё не знала, сработает ли идея. Поэтому она не стала сразу брать обязательство выпустить функцию клиентам

Что компания сделала

В подходе Shape Up возможную работу сначала оформляют как pitch. В нём должны быть названы проблема, допустимые затраты времени (appetite), основа решения, опасные неизвестные и то, что сознательно оставлено за границей. Такой документ помогает обсуждать не только привлекательность идеи, но и условия, при которых её имеет смысл проверять

Для Hill Charts Basecamp выбрала проверку в два решения. Сначала команда сформулировала первую версию, достаточно работоспособную для собственного использования. Она выделила на неё один цикл без обещания клиентского запуска. Если бы результат не убедил команду или появились более важные задачи, второго цикла могло и не быть

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

Как устроена проверка решения

В Shape Up руководители выбирают проекты на так называемом betting table. Они рассматривают подготовленные pitches и решают, чему дать людей и время в следующем цикле. Для существующих продуктов ожидание обычно состоит в том, что команда выпустит некоторую версию подготовленной работы к концу цикла. Для неопределённого эксперимента, как Hill Charts, Basecamp выбрала более осторожную рамку: сначала внутренняя версия и отдельная оценка следующего шага

Компания описывает и рабочую инфраструктуру этого процесса: pitches размещаются в команде Product Strategy внутри Basecamp, а после выбора для цикла создаётся проект с исходным pitch. Это позволяет команде видеть, какую проблему она решает и какие ограничения были приняты до начала разработки

Здесь не заявлен рост выручки, скорости или качества после внедрения. Официальные материалы подтверждают последовательность решений и факт выпуска Hill Charts, но не дают основания приписывать этому кейсу измеренный коммерческий эффект

Что близко к МетаРешениям

Basecamp не применяла метод МетаРешений. Сходство здесь в дисциплине проверки основания: отделить интересную идею от проверенного решения, назвать ограничение по ресурсам и заранее определить, какая новая информация даст право продолжить или остановиться

Проблема -> предел вложений -> внутренняя проверка -> новая информация -> отдельное решение о продолжении

В небольшой компании не требуется шестинедельный цикл или специальное совещание. Полезен сам принцип: не объединять пробу и полномасштабное внедрение в одно необратимое «да»

Что попробовать в своём бизнесе

Выберите инициативу, которую сейчас обсуждают как готовый проект. На одной странице запишите:

• Какую наблюдаемую проблему она должна решить
• Сколько времени и людей вы готовы вложить до следующего решения
• Какая самая маленькая рабочая версия даст новую информацию
• Что останется за пределами первой версии
• По какому факту вы продолжите, измените или остановите работу

Так собственник сохраняет управление развилкой, а команда получает понятные границы для самостоятельной работы. Если трудно определить первую проверку, пройдите мини-разбор МетаРешений

Источники

• Ryan Singer, Shape Up: Write the Pitch
• Ryan Singer, Shape Up: Place Your Bets
• Ryan Singer, Shape Up: How to Implement Shape Up in Basecamp