Я больше десяти лет делаю рекламные платформы. Команды за это время были разные — по размеру, по составу, по зрелости. Но почти всегда был один загон — всем почему‑то было очень важно работать по спринтам.
Не обязательно называть это скрамом, хотя обычно называли. Важна была именно двухнедельная итерация как фундамент вокруг чего строится планирование (или то, что им кажется), отчетность и разговор со стейкхолдерами.
Сразу оговорюсь: это разбор личного опыта, а не исследование. Цифр и названий компаний не будет, первые я не могу подтвердить, вторые не хочу светить. Интересно здесь то, что одно и то же повторялось независимо от команды и продукта.
Пока проекта нет в проде, спринты ничего не ломают
В первые месяцы работы над новым проектом приоритеты внутри спринта не меняются почти никогда. Оснований менять их просто нет — пользователей нет, денег нет, инцидентов нет. Вся обратная связь замкнута внутри команды, а все отчеты наружу в основном бодро рапортуют, что все идет по плану.
Мы просто последовательно выкатывали запланированное до первой продакшен‑версии. Двухнедельная нарезка была сверху и ни на что не влияла.
Что все это время мы работали практически по вотерфолу, стало понятно не тогда, а позже — в момент, когда проект перешел к следующей фазе. Пока фаза не сменилась, разницы не видно: спринты идут, задачи закрываются.
Запуск
Дальше проект выходит в прод, и ломается примерно все. Приоритеты скачут от критических багов к критическим фичам, без которых Самый Важный Клиент точно не будет пользоваться системой. План, составленный в понедельник, к среде устаревает.
Сначала я пытался описывать это через смену методологии. Есть же утверждение, что пока проблему не сформулировали, то и решать нечего. А использование названий методологий как будто бы сразу и решение предлагает — если не подходит одна, значит нужно просто использовать другую. Но по сути дело не в том, что вотерфол превратился в канбан. Скорее изменилась одна величина — горизонт планирования. Насколько далеко вперед можно планировать, прежде чем реальность обнулит план. До прода он измерялся месяцами. А после запуска парой задач. Но зато появилась величина которую мы можем измерять:‑)!
Эту величину не надо согласовывать, ее просто видно. Достаточно посмотреть, сколько живет составленный план, прежде чем его приходится переписывать: три дня, две недели, два месяца.
Спринт превращается в узкое место
Горизонт схлопнулся, а спринт остался. Вокруг него по‑прежнему строится вся работа команды.
В терминах теории ограничений спринт в этот момент становится узким местом системы. Пропускная способность определяется самым узким звеном, и на фазе запуска этим звеном оказывается двухнедельная итерация. Она не ускоряет работу, а замедляет ее.
Фрустрация с двух сторон
Формально критическую задачу нельзя брать в работу сразу, потому что это нарушит договоренность о том, как мы работаем. Но взять ее все равно приходится, и тогда нарушается обязательство на спринт. Что бы мы ни выбрали, одна из договоренностей ломается.
С одной стороны, хочется быстрее закрывать критические проблемы, но каждый такой заход ломает принятый порядок работы.
С другой — мы взяли обязательства на спринт, на месяц, на квартал, и не выполняем их, потому что поперек продуктовых задач постоянно идут критические.
Невозможно дожать подход до конца, если по ходу на штангу докидывают столько же. Именно это мы и пытались делать. Безусловно это утверждение верно если только вы не Чак Норрис — тогда подход сам себя дожмет.
Усилия были направлены не туда
Мы подстраивали горизонт планирования и бэклог под рабочие итерации. А надо было наоборот: подстраивать итерации под то, как система работает на самом деле.
Любопытно, что это ровно то, что написано в Аджайл манифесте. Там же фокус не на спринтах, оценках, или двухнедельных итерациях. Там говорится о том, что люди и взаимодействие важнее процессов и инструментов, а готовность к изменениям важнее следования плану. Команда, которая держит итерации, мешающие ей работать, будет прямо таки анти‑эджайл. Не смотря на все термины и ритуалы, все эти скрам‑борды, ретро‑митинги, planning poker и прочие термины которые кто‑то укажет у себя в линкедине. Ну то есть мы пытались быть гибкими, но только гнуть пытались горизонт планирования, который зависел от внешних факторов, вместо того чтобы изменить методику работы, которая была внедрена на абсолютно другом этапе жизни проекта.
Что с этим можно делать
Первый вариант — перейти на канбан. Задачи двигаются по статусам, очередь ротируется без влияния на соседние задачи, вместо обязательства на две недели вперед действует лимит на одновременную работу.
У этого выбора есть цена, про которую я сперва не подумал. Канбан переносит решение на уровень каждой отдельной задачи. Пока поток мелкий и однородный, команда приоритизирует сама. Но как только задачи разнородные и дорогие, решение по каждой поднимается до продакта, и он превращается в диспетчера, согласующего каждую карточку в бэклоге. Это противоположно тому, ради чего он там нужен. А точнее противоположно тому, чем я хотел бы заниматься каждый день. Поэтому продолжил искать решение дальше.
Второй вариант — остаться в спринтах, чтобы сохранить общее направление работы, но договориться на всех уровнях команды об одном: состав спринта в начале и в конце будет разным. Так устроена эта фаза.
Тогда задача не в том, чтобы все успеть, а в том, чтобы удерживать объем выполнимым. Влетела новая задача — что‑то из хвоста уходит сразу.
Здесь есть сложность, ответа на которую у меня пока нет. Влетевшую задачу нельзя оценить до того, как ее нормально проработали, то есть взяли в работу и какое‑то время помусолили. Значит, непонятно, сколько именно выбрасывать из хвоста. В итоге размен приходится делать по факту в конце спринта, а не в момент влета.
Третье, независимо от выбора. Продуктовые задачи на этой фазе будут страдать, и лучше признать это заранее. Со стейкхолдерами имеет смысл сразу договориться о целях, связанных с эксплуатацией: стабильность, время реакции, закрытие критических дефектов. Иначе каждую неделю придется объяснять, почему роадмап стоит на месте.
Как понять, что фаза закончилась.
Я считаю, что из фазы разработки в фазу запуска проект переходит получив первые реальные внешние деньги. Ну то есть можно до посинения гонять внутренние тесты хоть на сто долларов, хоть на сто тысяч, но это не сможет подтвердить принятие клиентами нашей готовности. Все расходы на тесты — это по сути именно наши расходы, рост оборотов по таким тестам будет ростом расходов. А вот когда продукт получит сто долларов от настоящего клиента — вот это уже доход, который в дальнейшем может превратиться и в десять тысяч. Этот критерий нельзя подделать никакой внутренней готовностью.
Следующий переход — из фазы запуска в фазу стабильной работы и развития. Я бы назвал его «по предсказуемости». Это момент когда платформа начинает выполнять бизнесовые планы, причем планы нормальные, без скидки на молодость проекта и оговорки, что это лишь тесты. На самом деле такое начинает ощущаться раньше чем становится видно в отчетах — по сути бэклог перестает переписываться каждые несколько дней и задачи запланированные на все более длительный срок начинают выполняться без влетов.
Если совсем коротко, то команда перестает действовать реактивно и начинает проактивно. Результаты с ней больше не случаются, она к ним приходит.
Дальше становится легче
Динамика проекта в какой‑то момент стабилизируется, и команда естественным путем приходит к спринтам, в которых содержимое действительно не меняется. Причем приходит сама, до того как кто‑то предложит это внедрить: горизонт планирования растет, и однажды дорастает до двух недель.
Главное — дожить до этого момента, не перессорившись внутри и не разочаровав стейкхолдеров настолько, чтобы команду разогнали.
Комментарии (13)
Dhwtj
15.09.2026 14:53Скорее изменилась одна величина — горизонт планирования. Насколько далеко вперед можно планировать, прежде чем реальность обнулит план. До прода он измерялся месяцами. А после запуска парой задач.
Надо смотреть статистику. Но обычно на внеплановые просто фиксированный резерв при котором по статистике плановые задачи редко вытесняются. Задача оптимизации на основе статистики.
garregusev Автор
15.09.2026 14:53Так и есть, тут только особенность в том, что на этапе когда проект запускается, слишком много критов возникает и выходит, что плановые задачи постоянно вытесняются. Сейчас подумал, что вот этот этап стабилизации после запуска я бы назвал "этапом накопления техдолга" :-). Что в этот момент спасает - то, что не смотря на костыльность срочных решений для критов, получается все эти решения как-то документировать и сохранять. В итоге склады с костылями не теряются, остаются видимыми и после стабилизации команда видит, что нужно причесать.
Dhwtj
15.09.2026 14:53Реальную эксплуатацию документировать обязательно! Желательно в коде или комментарии к коммиту. Прямо полностью issue. Так удобнее потом анализировать историю
Altimit
15.09.2026 14:53Обычно на внеплановую деятельность закладыаается бюджет внутри спринта.
Полезно также на тушение пожаров выделять отдельного человека с ротацией каждые неделю или спринт. Он будет защищать команду от постоянного дергания и он же будет выступать бюджетом на внеплановую деятельность.
Далее стоит понять, откуда берутся внеплановые таски. Если это критические баги, то нет ли в них паттерна. Не являются ли они следствием нарушения какого-то процесса в проектировании/разработке/тестировании? Возможно, удастся устранить первопричину вместо постоянной борьбы со следствием. Либо выявить новые проблемы превентивно, а не посфактум - тогда их можно будет вписать в спринты.
Если это критические фичи, то разобраться, кто именно и по каким критериям определяет критичность. По моему опыту, в большинстве случаев критичные фичи на самом деле не критичные. Просто стейкхолдеры умышленно перекручивают важность, т.к. видят в этом эффективный способ решения своей задачи.
garregusev Автор
15.09.2026 14:53да на этапе запуска проекта "первопричина" – это чаще всего пропущенные какие-то корнер кейсы на этапе проектирования архитектуры. ну т.е. когда проект живет уже несколько лет то да, там могут быть какие-то нарушенные принципы в проектировании, а именно на старте обычно просто не учтенные моменты какие-то
anikolaev_ru
15.09.2026 14:53В статье не нашел ни слова про цель спринта. А это ключевой элемент. Спринт, как и скрам в целом, предназначен для оптимизации business value. Если спринт не является продуктовым экспериментом, то это бесполезный контейнер, он ничего не оптимизирует. Канбан метод, вы правы, напротив очень помогает, потому что в 99% случаев команде надо оптимизировать delivery, а не business value. Потому что человек, который отвечает за окупаемость разработки в команде как правило не присутствует - он слишком высоко сидит, чтобы спускаться на уровень команды (а делегировать ответственность за стратегические цели по продуктовым/бизнес метрикам он не готов). В таких условиях команда вообще никак не может повлиять на business value, и единственное, что она может - улучшать delivery, и тогда спринт, обзор спринта, планирование спринта - это бесполезные ритуалы.
garregusev Автор
15.09.2026 14:53ага, пост в принципе как раз про это – что неоднократно встречались ситуации когда спринт являлся лишь контейнером и вся работа по скраму вокруг него была скорее симуляцией(и самообманом) оптимизации business value, а не ей самой. потому что на этапе запуска продукта об оптимизации еще слишком рано говорить
anikolaev_ru
15.09.2026 14:53На этапе маркетингового запуска продукта (официального выхода продукта на рынок), не происходит ничего такого, что бы принципиально отличалось от других этапов (до запуска, после запуска).
Любые действия бизнеса с участием каких-то серьезных изменений в кастомной IT-инфраструктуре бизнеса (тот самый production, который почему-то постоянно называют продуктом или проектом, и из-за чего упускают возможность понять реальный проект и реальный продукт) являются экспериментами. Эти эксперименты не всегда связаны с изменениями в кастомной IT-инфраструктуре, но серьезные изменения в кастомной IT-инфраструктуре по инициативе бизнеса всегда связаны с экспериментами. И существование этих экспериментов абсолютно не зависит от того, применяют разработчики скрам или они перешли на канбан-метод.
Реальный продакт (который отвечает за ROI/P&L, а не тот, у которого в профиле под аватаркой написано Product Owner) всегда работает над тем, чтобы растить бизнес-метрики. Помимо GTM, это всегда рискованные гипотезы запуска разных инициатив, рискованность которых снижается с помощью тех самых экспериментов. И некоторые риски связаны с long term operational costs или customer satisfaction (то самое business value в разработке). Для снижения таких рисков ему (продакту) приходится идти в разработку. Больше ему разработка по большому счету ни для чего не нужна (ему нужна эксплуатация / поддержка).
И тут всплывает реальная проблема, из-за которой попытки крутить и оптимизировать эти эксперименты (которые в скрам-гайде называются спринтами) чаще всего являются симуляцией. Продакт не хочет напрямую общаться с разработчиками про реальные цели фичей, которые он просит запилить. Он не хочет общаться с технарями про product goal и business value. Цитирую: "О чем с ними вообще можно говорить? Они на своём птичьем языке говорят, я их не понимаю". И/или происходит назначение переводчика с русского на русский: "У меня нет на это времени. Пусть проджект/продакт/аналитик займутся."
И в этих словах много истины, потому что разработчики как правило действительно не хотят (подчеркиваю - не "не могут", а "не хотят") разбираться в том, как устроен продукт заказчика и бизнес-модель вокруг него. Из-за этого в кастомной IT-инфраструктуре процветает архитектурная космонавтика и неустраняемый техдолг: вечная непредсказуемость хотелок бизнеса и их такое же вечное несоответствие архитектуре "продукта" (слово не случайно взято в кавычки именно тут, а не ранее).
Надо сказать, что когда технари хотят разобраться в продукте и бизнес-модели, то в большинстве случаев они натыкаются на непонимание со стороны продакта "Вам это зачем?". Ему даже в голову не может прийти, что запредельная совокупная стоимость владения продуктом связана именно с тем, что бизнес и его кастомная IT-инфраструктура написаны на разных языках и на любой чих нужен переводчик. Сильная разница между бизнес-моделью и архитектурой = много legacy, слабая разница = мало legacy.
Но (по разным причинам) скрам-то всё равно хочется применить, мы же хотим business agility. И вместо того, чтобы пойти в бизнес и найти там реальные спринты (эксперименты по снижению соответствующих рисков), менеджмент (а я встречал, когда технари сами) начинают крутить свои фейковые никому нафиг не нужные спринты. По этой причине очень распространено заблуждение, что спринт нужен для фиксации обязательств по поставке на период времени. И вроде бы всё по scrum guide, кроме "сущей мелочи" - sprint goal и product goal либо отсутствует, либо не имеют ничего общего с реальными ограничениями роста бизнеса заказчика.
И когда этот цирк с конями надоедает, от безысходности идем в kanban-метод. Хотя kanban-метод и scrum-фреймворк нельзя сравнивать и тем более противопоставлять. Потому что они, как уже наверное стало понятно, применяются на совершенно разных уровнях: kanban-метод для управления delivery, а scrum-фреймворк для управления business value. И поэтому они отлично сочетаются вместе, если бы не всё вышесказанное.
Ksu_Sof
15.09.2026 14:53Спринт хорош на поддержке изменений готового продукта (сопровождение с небольшими доработками), когда от заказчика идут потоком хотелки на доработку. Вот тут да, мы говорим в какой спринт мы это готовы сделать, сколько это стоит в трудоёмкости, и заказчик понимает что в какой спринт будет сделано и когда ждать свои пожелания. И до спринта должно быть планирование, может прям с заказчиком).
А когда мы разрабатываем новый продукт или его новую версию, делаем доработки по контракту - там спринты выглядят странновато... Там уместенее водопадный гант + разделение на PI или релизы (мажорные, минорные и т.д.) - так понятнее. Но спринты все равно живы))). Хотя задачи просто перелазят из одного в другое тут они служат для самого разработчика или аналитика - вот мой фронт работ на 2 недели. Неделя - мало, можно не успеть получить информацию, 3 - много, сложно накидывать работы на большие сроки. Хотя можно и на месяц планировать, если люди привыкнут.
garregusev Автор
15.09.2026 14:53все так. я пришел к мысли, что важно в первую очередь себе самому, а во вторую очередь команде смириться с тем, что "спринты" на этом этапе – это лишь контейнеры для хоть какого-то упорядочивания хаоса, а не реальный инструмент планирования. в этот момент жить все становится легче.
ну и, понятное дело, в момент устаканивания проекта, важно обратно вернуться к нормальному планированию, а не застрять в жонглировании асапами :-)
solaris_n
У меня следующий подход - мы договариваемся об обьеме работы который важен и может быть выполненен при самом худшем сценарии, но ПО будет доволен, а остальное это то, что мы постараемся выполнить, но не обещаем закрыть на 100 процентов. Вот эти задачи становятся кандидатами на выбывание в случае критической задачи, которая пришла после планирования. При этом не замарачиваемся над сравнением их размера, тут обычно два подхода - 1) одна задача пришла, другая ушла по менее значимости 2) все оставляем, но сдвигаем прироритеты. В любом случае у команды остается чувство выполненности поставленной задачи, а для ПО не является сюрпризом, что что-то не сделали, так как команда обязывалась закончить оставшееся. Другой момент если слишком часто такие прилёты. В этом случае надо разбираться с процессом и пересматривать договоренности или формат работы. В противном случае это превратиться в привычку и размер "обещанного" или в терминологии нашей команды "confident scope" будет уменьшаться и утратить свою ценность.
garregusev Автор
Ну это идеальный план, да. Особенно когда команда сама готова быть вот настолько адаптивной. Потому что у меня несколько раз был опыт когда тимлиды разработки, а иногда даже проджекты, до последнего бились за то чтобы все спринты были заранее распланированными и статическимию. А то, что проект только запустился – это проблемы продактов и бизнеса, что они не могут за месяц до начала спринта спланировать какие критические задачи появятся у проекта у которого в данный момент два юзера с оборотом в сотню баксов. Особенно когда за спиной такой команды стоит целый департамент без опыта запуска совсем новых продуктов, но с многолетним опытом поддержки существующих – вот это изменение рабочего подхода становится достаточно весомой задачей, как по эффекту в результате, так и по сложности в процессе.
solaris_n
Этот подход появился как ответ на фрустрацию команды из-за постоянных задач по исправлению инцидентов. Но да, много зависит от команды, менеджмента, людей. Серебрянной пули нету, все решается индивидуально.