Basecamp: хватит имитировать спринты, начните делать релизы
Все эти ваши «скрамы» и «двухнедельные инкременты» — это, по сути, бег по кругу с завязанными глазами. Вы встали на дорожку, и она никогда не заканчивается. Потому что перенос незавершенки в следующий спринт стал нормой. Basecamp плюнул на это. Они сказали: «Ребята, мы работаем жесткими шестинедельными циклами. Взяли коробку задач — закрыли. Не закрыли — ну и хрен с ней, идите гулять, фича в морозилку, а не в следующий спринт». И никаких ежедневных стоячих митингов, где вы смотрите в доску и делаете вид, что контролируете процесс. Они перед циклом делают «Shaping» — грубо говоря, главный мозг садится и набрасывает границы задачи настолько, чтобы разработчик не гадал, с какого конца подойти. И всё. Дальше команду не трогают. Зачем? Чтобы не выгорали от бесконечного «а давай еще добавим» и чтобы не имитировали бурную деятельность.
Теперь про то, почему, если вы скопируете один в один, то обгадитесь. У Basecamp нет инвесторов, которые дергают за ниточку каждую среду. У них продукт зрелый. У вас же заказчик (или ваш же отдел продаж) требует фичу «еще вчера». Если вы посадите свою команду из пяти человек на шестинедельный изолированный цикл и запретите туда влезать, вы через две недели получите бизнес-потерю. Вторая ловушка: их «Shaping» требует толкового продакта, который две недели только думает, а не тушит пожары. У вас такого нет. Ваш шейпинг превратится в пустую говорильню, а цикл станет идолом, ради которого вы забьете на реальную потребность рынка. Не делайте так.
А теперь, как сделать, чтобы работало у нормальных людей, у которых еще и поддержка висит.
Берем не 6 недель. Берем 3. Потому что три недели — это срок, на который вы еще можете что-то спрогнозировать в нашем хаосе. Далее. Заменяем их высоколобый Shaping на простое правило. За три дня до старта цикла вы или ваш техлид садитесь и пишете лист А4. Не ТЗ на 20 страниц, а именно тезисы границ: что мы делаем, что мы принципиально НЕ делаем (это важно!), и какие главные технические риски мы видим. Это не дизайн, это рамки для прыжка.
Алгоритм. Он простой, как лопата. Первый: замораживаете бэклог на эти три недели. Никаких «Ой, а давайте еще кнопочку». Точка. Второй: в понедельник утром первого дня цикла собираетесь на час. И читаете этот лист. Без прочтения — не допускаете к работе. Это отсекает вопросы «А что хотел заказчик?». Третий: ровно через полторы недели (середина) делаете чек-поинт на полчаса. Разработчики показывают, что у них есть. Если вы видите, что они отстают на 40% — вы не переносите дату. Вы режете функционал. Прямо на этом чек-поинте. Убираете фичи, которые не критичны. Четыре: конец цикла. Дедлайн жесткий, как бетонная стена. Что готово — выкатываем в прод. Что не готово — не выкатываем. Вообще. И в следующий цикл это не переносим, пока не пересмотрим, а надо ли оно нам.
Какой результат. Через пару таких циклов вы перестанете врать клиентам про даты. Потому что вы научитесь оценивать ровно столько, сколько можете сделать за три недели. Команда перестанет жить в состоянии вечного цейтнота — вместо 10 маленьких дедлайнов у них один большой, но реальный. Вы начнете убивать низкоприоритетный мусор, потому что он тупо не влезает в коробку. И самое вкусное: вы перестанете испытывать чувство вины за недоделку. Это не косяк. Это просто диагноз рынку: «Мы переоценили, давайте проще». Это экономит нервы и деньги.