Привет, Хабр!

Shape Up — метод продуктовой разработки из Basecamp, выложенный отдельной книгой в свободный доступ. Придумывали его люди, уставшие от спринтов, бэклога на четыреста тикетов и вечного переноса задач из итерации в итерацию.

Главный ход там в том, что вместо вопроса «сколько эта задача займёт» задают вопрос «сколько эта задача стоит нашего времени».

Ответ называется аппетитом, звучит как «шесть недель» или «две недели», и дальше решение подгоняют под срок. Не срок под решение, а наоборот.

Разница кажется словесной ровно до первого цикла.

Оценка — это прогноз, за который никто не отвечает и который всегда оказывается меньше правды.

Аппетит — это бюджет: не влезает решение — режут решение.

Восьминедельный такт

Календарь простой: шесть недель цикла плюс две недели остывания, и так по кругу.

Шесть недель выбраны не случайно.

За этот срок успеваешь сделать что‑то заметное, но ещё не забываешь, зачем начинал.

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

Квартал, наоборот, слишком длинный: к середине никто не помнит исходную постановку, и она тихо мутирует во что‑то другое.

Внутри цикла команду не трогают.

Ни планёрок с переприоритизацией, ни «загляни на полчаса», ни новых вводных от продукта.

Дело тут не в комфорте разработчиков, а в том, что весь метод держится на обязательстве закончить в срок, а требовать такое обязательство с человека, которого дёргают трижды в неделю, бессмысленно.

В две недели остывания плановой работы нет вообще.

Команда чинит баги, доделывает хвосты, лезет в те места кода, до которых полгода не доходили руки, кто‑то берёт отпуск.

В эти же две недели проходит betting table.

Остывание выбрасывают при внедрении первым делом, и обычно это убивает всю конструкцию.

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

Цикл не обязан быть занят одним большим проектом.

  • Большая ставка — один проект на все шесть недель, команда из дизайнера и двух программистов.

  • Малые ставки — две‑три штуки по одной‑две недели, обычно на одного дизайнера и одного программиста.

Аппетит у них свой, правила те же, просто масштаб другой.

Больше трёх человек в проект не сажают: координация съедает выигрыш от срока.

Питч: пять частей, ни одной лишней

До попадания в цикл работа проходит формовку.

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

В питче всего пять частей:

  • Проблема. Что конкретно ломается у пользователя, с примером.

  • Аппетит. Шесть недель или две. Бюджет, а не прогноз.

  • Решение. Основные элементы, нарисованные грубо.

  • Кроличьи норы. Места, где команда провалится на неделю, и заранее принятые решения по ним.

  • Ноу‑гоу. Что мы намеренно не делаем, чтобы влезть в аппетит.

Формулировка проблемы должна быть историей, а не задачей.

Не «улучшить онбординг», а «человек доходит до третьего шага, упирается в форму с ИНН, которого у него с собой нет, и не возвращается».

Из первой формулировки не следует ничего, из второй следует сразу несколько решений.

Аппетит объявляется до того, как придумано решение.

Против ранней детализации в книге придуманы два приёма.

  1. Бредбординг рисует только связи между экранами и кнопками, без всякой графики.

  2. Наброски толстым маркером не дают прорисовать мелочи физически: линия слишком жирная. И то и другое держит автора подальше от готового макета и оставляет инженерам пространство.

Всякие ненужные процессы формовщик обязан найти и закрыть решением: «шрифты не трогаем, берём существующие», «интеграцию делаем только для первого провайдера».

А ноу‑гоу делает половину работы всего метода.

Ставка вместо бэклога

Бэклога в Shape Up нет.

Список из четырёхсот тикетов, который никто никогда не разгребёт, это не инструмент, а склад вины.

Растёт он быстрее, чем вычищается, каждый его обзор стоит человеко‑часов, и девяносто процентов записей никогда не будут сделаны.

Идеи вместо этого живут где придётся: в переписке, в личных списках, в головах.

Важные всплывают сами, потому что про них напоминают. Неважные умирают, и это правильный исход.

Раз в восемь недель собирается betting table. В Basecamp за стол садятся CEO, CTO, старший программист и продуктовый стратег, встреча занимает час‑два, питчи все читают заранее.

Обсуждают четыре вопроса:

  1. Важна ли проблема?

  2. Верный ли аппетит — не «сделаем ли за шесть недель», а «стоит ли эта штука шести недель»?

  3. Нравится ли решение?

  4. Те ли люди сейчас свободны?

Компания даёт команде шесть недель без прерываний, команда обязуется закончить. Вторая половина в обычном спринтовом планировании обычно не проговаривается, из‑за чего и первая не работает.

Первое, обо что спотыкаются при внедрении, это баги. В цикл они не попадают. Мелкие копятся до остывания, там на них и уходит часть двух недель.

Крупный баг идёт на betting table обычной ставкой и конкурирует с фичами. А если за несколько циклов накопилось столько, что это уже не мелочь, ставят отдельный цикл целиком под разгребание.

Предохранитель

Самое основное правило метода: проект, не доехавший за шесть недель, по умолчанию закрывают. Не продлевают.

Работает предохранитель не как наказание, а как давление внутрь цикла. Продлить нельзя — значит, единственный способ доехать — это резать объём по ходу. Такое резание, scope hammering, и есть основная работа команды на второй‑четвёртой неделе.

Функциональность для этого делят не по слоям и не по задачам, а на куски, которые можно собрать, интегрировать и выпустить независимо от остальных. Кусок «бэкенд для экспорта» бесполезен, кусок «экспорт в CSV работает от кнопки до файла» — годится.

Необходимое от украшения отличают одним вопросом. Замкнётся ли история пользователя без этого куска?

Человек оформил заказ и получил подтверждение — история замкнулась, а анимация на кнопке и красивое пустое состояние в неё не входят.

К середине цикла становится видно, что примерно половина запланированного на этот вопрос отвечает «да, замкнётся», и эту половину выбрасывают без сожалений.

Обойти предохранитель можно за минуту, если не добавить ещё одно правило.

Готово — значит, выкачено. Не смержено, не «осталось задеплоить в понедельник».

Иначе команда объявляет себя готовой на шестой неделе, а выкатка тянется ещё две, и всё возвращается к продлению под другим названием.

Закрытый проект не исчезает навсегда. Важная идея вернётся на следующий betting table, уже с учётом того, что команда успела понять. Но вернётся как новая ставка, а не как незакрытый долг, который таскают за собой и оправдываются на каждом планировании.

Холм вместо процентов

Хилл‑чарт можно утащить себе, даже если весь остальной метод вам не подходит. Это горка, по которой ползёт каждый кусок работы:

  • левый склон — неизвестное: непонятно, как делать, сколько там подводных камней, взлетит ли подход;

  • вершина — всё выяснено, остались руки;

  • правый склон — исполнение без сюрпризов.

«Готово на восемьдесят» не значит ничего: восемьдесят процентов написанного кода могут стоять на левом склоне, где ещё неизвестно, работает ли основная идея. А кусок, переваливший вершину, доедет почти наверняка, даже если кода там меньше.

Руководителю хватает взгляда на картинку. Кусок, третью неделю не двигающийся на левом склоне, требует разговора сегодня, и не про сроки, а про то, во что человек упёрся. Статусные встречи для этого не нужны.

Точки на горке двигает сама команда, она же первой и замечает застрявшее.

Где метод ломается

Ограничения книга проговаривает вяло, скажу основные:

  • Жёсткие внешние сроки.

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

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

  • Быстрая смена курса. Шесть недель без права вмешаться — роскошь компании с понятным продуктом.

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

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

С чего начинать

Целиком внедрять не надо, авторы сами это говорят. По возрастанию сложности:

  1. Аппетит вместо оценки на ближайшей крупной задаче. Назовите срок первым, решение подгоните под него.

  2. Ноу‑гоу в постановке. Одна строчка о том, чего мы не делаем.

  3. Готово — значит, выкачено. Правило на одну фразу, которое вскрывает половину скрытых просрочек.

  4. Хилл‑чарт вместо процентов на любой доске, которая у вас уже есть.

  5. И только если первые четыре прижились — календарь. Циклы без остывания не работают, остывание без циклов бессмысленно, а betting table без питчей — это обычное планирование с новым названием.

Аппетит меняет разговор с командой в тот же день: вместо торговли про две недели или три начинается обсуждение, что выбросить. И довольно быстро выясняется, что выбрасывать не хочется никому, и вот тут становится видно, кто в команде готов принимать решения, а кто ждёт, что срок сдвинут.

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

Продолжим разбираться в этих подходах на бесплатных уроках:

  • 23 сентября в 20:00. «Как системному аналитику проводить архитектурное ревью и находить риски до начала разработки». Записаться.

  • 22 октября в 20:00. «Управление изменениями требований». Записаться.

Больше бесплатных уроков сентября смотрите в дайджесте.

Комментарии (0)