Проблему вы поймали верную: скорость мерить научились, а вот инженерное качество почти нет. Но у «грейда по 800 код-метрикам» встроенная проблема (мина замедленного действия) - тот самый закон Гудхарта, за который вы справедливо ругаете velocity. Как только по метрике считают грейд, то ее начинают "рисовать" (богатая поверхность метрик дает просто больше способов ее нарисовать).
Если инструмент как вход в разговор, то обеими руками за. Как замену человеческому суждению о грейде - очень поостерегся бы.
С половиной статьи и спорить не хочется - да, "Водопад" и правда соломенное чучело, и ритуал-ради-ритуала я тоже видел не раз. Но Вы бьете по Scrum-обрядовости и SAFe-бюрократии, а в проигравшие записываете evidence-based delivery, а это не одно и то же!
Тезис "Agile не масштабируется и рождает фавелу" как раз то, с чем я сталкивался/работал. Концептуальная целостность на масштабе теряется не от итераций, а когда не спроектированы границы команд. И чинится это не возвратом к чистому Top-Down (второсистемный эффект и закон Конвея никто не отменял), а проектированием границ команд как архитектуры (LeSS, Team Topologies). В отличие от "физики управления", это еще и измеримо (DORA, say/do-предсказуемость...).
Небольшая ирония напоследок: статья про "инженерную науку против эмпиризма" сама держится на метафорах про пекаря и метроном, без единой цифры. Мне не хватило ровно того, к чему вы призываете - данных.
Пришёл из соседнего цеха - я про delivery, а не про аналитику, но подписываюсь под каждым словом. Добавлю одну вещь, которую Ваша же история про ушедшего Сашу прямо просит: самый ценный документ на проекте не требование, а решение. Не "что сделали", а "почему сделали так и почему НЕ стали иначе». Требования устаревают, а "мы не используем API X, потому что…" - это ровно то знание, что уходит вместе с человеком.
У инженеров под это есть ADR (Architecture Decision Record): пять строк - дата, контекст, решение, последствия. Идеально ложится и в вашу MVD, и в правило "фиксируем с датой и именем".
И жирный плюс за "зачем бизнесу это нужно - нет ответа, не делаем". По-моему, из этого правила растут все остальные: живёт та документация, что отвечает на вопрос, который кто-то реально задаст снова. Остальное честно гниёт в "Архив_удалить". Пусть боятся)
Три вещи в этом тексте хочется перечитать: - Первое: "сумма локально правильных выводов дает общее поражение". Лучшее однострочное определение, зачем вообще нужен человек, отвечающий за целое. Половина работы руководителя доставки ровно про эту точку, где каждый по отдельности прав, а вместе тупик. - Второе: момент, когда технолог перестал планировать "вперед" и начал считать назад от критической встречи партии и оборудования. Вы, возможно, и не ставили такой акцент, но это же ровно логика теории ограничений: не оптимизируем все подряд, а подчиняем расписание одной узкой точке. Красиво, что команда пришла к этому не из книжки Голдратта, а из "просто смотрю и вижу". - Третье: честность про "менеджер ничего не создает". Мало кто решается такое написать. Добавлю от себя: создает, но то, на что нельзя показать пальцем. Вроде выращенного преемника или разговора, после которого проект не закрыли. Спасибо, что показали цену профессии, а не только ее глянец!
Вопрос спонсора про закупщиков - это же классический разрыв output/outcome, только рассказанный лучше, чем в большинстве книжек. У меня в практике ровно та же сцена, но только другие слова: команда показывает, что "скорость выросла и тикетов закрыли больше" (система работает), а бизнес спрашивает "клиенту-то стало легче?". И в этом месте обычно повисает пауза:)
Сильнее всего зашёл график со столбцом "Исчезло", заполненным один раз из пяти. Болезненно точная картинка: автоматизация чаще перекладывает ручную работу, чем убирает её, просто новая работа не попадает в отчёт. Мы постоянно считаем исчезнувшие операции и почти никогда появившиеся(
Также полностью согласен с "не начинайте с KPI". Число без исходного состояния - это не цель, а ставка (вы сами это слово и употребили). В доставке та же ловушка: назначить velocity на разработчика можно, но это уже не измерение, а способ научить людей рисовать нужную цифру. Добавил бы к карте выгод только одно: у неё, кроме владельца, должен быть срок годности. Бэйзлайн, который не сняли на старте, через год не с чем сравнивать (контекст уедет, и "посчитаем потом" превращается в "посчитать уже нельзя").
Когда дочитал, то поймал себя на том, что мы с разных концов пришли в одну точку (я про свою статью о LeSS и TT). Вы под моей статьей справедливо написали, что "несколько команд + один продукт" - это ещё не диагноз, а вывод. А здесь у вас та же мысль в чистом виде: "мы не разделили один проект - мы обнаружили несколько проектов, которые ошибочно считали одним".
В продуктовой разработке я проверяю это грубым тестом: имеет ли релиз ценность только когда все команды выкатились вместе или кусок можно довезти пользователю в одиночку. Если в одиночку, то "продукт" был просто вывеской и масштабировать надо не координацию, а наоборот, расцеплять.
И полностью подписываюсь под "паспорт спасает не шаблон, а полномочия вернуть его на доработку"! У меня то же самое с "готовностью задачи": она работает, только если команда реально может отказаться брать неготовое. Без этого права - всего лишь очередная форма для галочки.
"Код исполняется", по-моему, является ключевой строчкой всей статьи. Добавлю с другой стороны: ровно так же исполняется и оргструктура. Если бизнес не выбрал владельца сквозного результата, границы всё равно будут проведены (не решением, а тем, как исторически сложились команды и кто кому звонит в обед). Конвей сформулировал это ещё полвека назад: "...система повторяет коммуникации организации, которая её строит".
Поэтому Ваше "отлагательное вето" я бы распространил и на людей: прежде чем автоматизировать процесс, честно спросить, есть ли вообще тот, кто отвечает за него целиком. Если нет владельца, то система просто зальет бетоном текущую неразбериху, о чем Вы и пишете.
Спасибо за Ваш комментарий! И да, Вы правы в главном: я сжал шаг между диагнозом и рецептом, а он-то и есть самый важный, а в статье он подан слишком коротко. Кратко постараюсь исправиться здесь, ниже:
На практике до LeSS я вообще не дохожу, пока не пройден ровно указанный гейт. Первый вопрос - это правда один продукт или несколько потоков ценности, склеенных организационно? Проверка простая: релиз имеет ценность, только когда все команды выкатились вместе или команда способна довезти ценность своему пользователю сама? Если второе, то это не масштабировать Scrum, а наоборот, расщеплять то, что продуктом никогда не было.
Дальше уже идет Ваш список целиком: границы продукта, единый владелец результата, реальные полномочия PO (а не прокси без полномочий, "на бумаге") и, конечно же, природа зависимостей. И решение/лекарство абсолютно разное: организационные лечатся feature/stream-aligned-командами, а вот структурные командами не лечатся в принципе (там надо расцеплять систему или честно платить за координацию).
Но самое интересное, но и ироничное здесь в слендующем: LeSS сам "отказывается стартовать", пока не отвечены именно на те вопросы, которые Вы перечислили в своем коменте: "что есть продукт" и "кто тот единственный PO с властью приоритизации". Так что Ваша критика не против LeSS - это первый гейт честного LeSS (и правильно начинать искать болезнь ровно тогда, когда этот гейт проскакивают!).
Спасибо большое за действительно глубокий разбор (редкий по качеству)!
Спасибо! Отвечу коротко - Вы, кажется, уже всё для себя решили)
Уточню лишь, что те пункты выше и были моим личным порядком действий, просто без имён команд и внутренних цифр бывшего работодателя (в публичный комментарий их не выношу - это профгигиена, а не отсутствие кейса).
Рад был обменяться; вопросы реально помогли докрутить будущую статью. Успехов! 🙂
P.S. а насчёт «похоже на нейросеть»: если структурно и со ссылками читается как «слишком гладко», то приму за комплимент. За гладкостью года практики, а отсылки - чтобы Вы не верили мне на слово.
Отличный вопрос - Вы нащупали самую больную и самую интересную часть темы. Отвечу развёрнуто, потому что коротко тут легко соврать.
Сначала соглашусь: если «под предлогом адаптации» отвалились и оценки, и демо, а взамен не появилось ничего, то тревога бизнеса абсолютно законна. Это не «бизнес не понимает Agile», это реальная потеря прозрачности, и её надо закрывать. Вопрос только - чем?
Возвращать burndown и story points я бы не спешил: они и раньше давали иллюзию контроля, а не контроль (хотя признаюсь, я истинный поклонник относительных оценок/SP, но...). Я бы заменил выпавшие «якоря» на более честные.
Прозрачность без оценок - flow-метрики. Throughput (сколько ценных задач реально довезли за период), cycle time/lead time (сколько задача живёт от старта до прода), WIP и work item age (что «застряло»). Story points не критически нужны (опять же повторюсь, я их очень уважаю, но как один из инструментов, который работает тогда, когда действительно есть в нём необходимость) - throughput считает готовое, а не гипотетические очки. Прогноз бизнесу даём вероятностно: «по нашей истории с ~85% эти N задач выйдут к дате». Это язык бизнеса: как быстро, как стабильно, когда.
Здоровье доставки - DORA-4: частота релизов, время изменения до прода, доля неудачных изменений, время восстановления. Это про систему и поток, не про людей. И наглядно показывает бизнесу, что «машинка едет ровно».
«Показать инкремент» - вернуть, но дёшево. Потерянное демо - вот это реальная потеря. Не обязательно возрождать живое демо каждый спринт: хватит короткого async-чейнджлога «что вышло и какую ценность несёт». Дёшево и закрывает сразу и прозрачность, и вторую вашу боль.
Связать инженеров с ценностью. Раз «не видят инкремент» - в каждой задаче фиксируем «зачем» и ожидаемый эффект, а после релиза возвращаем команде цифры использования/adoption и отзывы клиентов (здесь, в том числе, в очень большой степени зависит от прОдукта (Product Ownera) - его постоянной работой с продуктом (в т.ч. и после релиза фичи) и взаимодействия с командой). Инженер, который видит, что его фича живёт - сам себе мотивация.
Про «измерять людей». Тут практика на удивление единодушна: мерить стоит систему, поток и исходы - не выработку конкретных людей. SPACE (Microsoft/GitHub), DORA и свежий DX Core 4 прямо предупреждают: индивидуальные output-метрики (строки, коммиты, velocity на человека) гарантированно геймятся (закон Гудхарта) и рушат командную работу. Даже McKinsey в 2024 попробовали продать «продуктивность на разработчика» - и получили публичную отповедь от Кента Бека и практиков ровно за это. Для человека метрики полезны как зеркало для роста, а не как линейка для оценки.
И, пожалуй, главное - важнее любой конкретной метрики то, кто ею владеет и зачем. Метрика, которую команда выбрала сама и крутит, чтобы улучшать поток - работает. Та же метрика, спущенная сверху как инструмент контроля, превращается в театр: её начинают рисовать, а не улучшать. Поэтому первый шаг: не «внедрить метрику», а договориться, что измеряем ради решений, а не чтобы кого-то поймать. Хорошее руководство даёт команде найти и обкатать то, что реально работает в её контексте, и спрашивает за исход, а не диктует единственно верную линейку сверху.
Вы, по сути, накидали план моей следующей статьи - «прозрачность и метрики без story points». Честно уместить её в комментарий не выйдет, так что, с вашего позволения, разверну отдельно. Спасибо за по-настоящему хороший вопрос!)
P.S. Отдельно отмечу: приятно видеть бэкенд-разработчика, который так предметно копает в управленческие метрики - обычно этим по-настоящему проникаешься уже из кресла руководителя. Если метите туда, то Вы заметно впереди графика 🙂
Небольшая ремарка: как раз середина статьи - не теория. Восемь команд, разработка отдельно, поддержка отдельно, баг из прода съедает у инженера полтора-два дня спринта - это мой собственный департамент (правильнее сказать, реальная ситуация в нескольких компаниях из моего реального опыта), а не пример из книжки.
Но соглашусь вот в чём: в статье мало сказано, чем такая перестройка оплачена. Если совсем по-суровому:
Ни один фреймворк не внедряется «по книжке». В реальности берёшь принципы (один бэклог, команда отвечает за свой кусок от и до) и адаптируешь под своих людей, свой легаси и своё начальство. У нас тоже был не «чистый LeSS», а рабочая версия под наш контекст.
Самое сложное - не механика, а люди. Инженеры не хотят брать поддержку («я разработчик, а не саппорт»), менеджеры боятся потерять контроль, у кого-то привычная роль исчезает. На это уходит больше сил, чем на все схемы вместе взятые.
Если "мандата" на большую перестройку нет - и не надо «внедрять фреймворк». Начните с одной боли: например, объедините разработку и поддержку в одной пилотной команде на одном участке продукта - и посмотрите на результат через пару месяцев. Это приземлённее любого фреймворка и именно так оно обычно и начинается.
А какая реальность у вас - сколько команд, и что болит сильнее всего? Интересно прикинуть, с чего начинал бы я.
Спасибо за отзыв! Замечание принимаю - статья писалась для тех, кто уже успел поуправлять несколькими командами, поэтому местами она тяжеловата.
Попробую простыми словами объяснить то, что в статье осталось за кадром:
SAFe - это способ организовать работу очень большой компании, где над одним делом трудятся сотни людей. Он строит «этажи»: наверху решают, куда идём; ниже - большие группы команд; ещё ниже - сами команды. Все живут по общему расписанию: примерно раз в квартал собираются и вместе планируют следующий кусок работы. Плюс - сотни людей двигаются согласованно и руководству всё видно. Минус - очень много правил, ролей и собраний: легко увязнуть в процессе и растерять скорость.
Scrum@Scale - придумал один из авторов Scrum. Идея другая: не строить этажи, а соединять обычные Scrum-команды между собой. Представители команд регулярно встречаются и решают общие вопросы - и так на каждом уровне, до самого верха. Главное правило: добавлять новые встречи и роли только там, где без них по-настоящему больно.
Если совсем на пальцах: SAFe строит завод с цехами и регламентами. Scrum@Scale - сеть небольших бригад, которые договариваются между собой. А LeSS (про который статья) предлагает третье: вообще не добавлять лишнего, а наоборот - убирать.
Идею про версию «для входящих в тему» забрал в работу - возможно, сделаю отдельный ликбез с картой фреймворков и простыми определениями. Спасибо, что дочитали!)
Проблему вы поймали верную: скорость мерить научились, а вот инженерное качество почти нет. Но у «грейда по 800 код-метрикам» встроенная проблема (мина замедленного действия) - тот самый закон Гудхарта, за который вы справедливо ругаете velocity. Как только по метрике считают грейд, то ее начинают "рисовать" (богатая поверхность метрик дает просто больше способов ее нарисовать).
Если инструмент как вход в разговор, то обеими руками за. Как замену человеческому суждению о грейде - очень поостерегся бы.
С половиной статьи и спорить не хочется - да, "Водопад" и правда соломенное чучело, и ритуал-ради-ритуала я тоже видел не раз. Но Вы бьете по Scrum-обрядовости и SAFe-бюрократии, а в проигравшие записываете evidence-based delivery, а это не одно и то же!
Тезис "Agile не масштабируется и рождает фавелу" как раз то, с чем я сталкивался/работал. Концептуальная целостность на масштабе теряется не от итераций, а когда не спроектированы границы команд. И чинится это не возвратом к чистому Top-Down (второсистемный эффект и закон Конвея никто не отменял), а проектированием границ команд как архитектуры (LeSS, Team Topologies). В отличие от "физики управления", это еще и измеримо (DORA, say/do-предсказуемость...).
Небольшая ирония напоследок: статья про "инженерную науку против эмпиризма" сама держится на метафорах про пекаря и метроном, без единой цифры. Мне не хватило ровно того, к чему вы призываете - данных.
Пришёл из соседнего цеха - я про delivery, а не про аналитику, но подписываюсь под каждым словом. Добавлю одну вещь, которую Ваша же история про ушедшего Сашу прямо просит: самый ценный документ на проекте не требование, а решение. Не "что сделали", а "почему сделали так и почему НЕ стали иначе». Требования устаревают, а "мы не используем API X, потому что…" - это ровно то знание, что уходит вместе с человеком.
У инженеров под это есть ADR (Architecture Decision Record): пять строк - дата, контекст, решение, последствия. Идеально ложится и в вашу MVD, и в правило "фиксируем с датой и именем".
И жирный плюс за "зачем бизнесу это нужно - нет ответа, не делаем". По-моему, из этого правила растут все остальные: живёт та документация, что отвечает на вопрос, который кто-то реально задаст снова. Остальное честно гниёт в "Архив_удалить". Пусть боятся)
Три вещи в этом тексте хочется перечитать:
- Первое: "сумма локально правильных выводов дает общее поражение". Лучшее однострочное определение, зачем вообще нужен человек, отвечающий за целое. Половина работы руководителя доставки ровно про эту точку, где каждый по отдельности прав, а вместе тупик.
- Второе: момент, когда технолог перестал планировать "вперед" и начал считать назад от критической встречи партии и оборудования. Вы, возможно, и не ставили такой акцент, но это же ровно логика теории ограничений: не оптимизируем все подряд, а подчиняем расписание одной узкой точке. Красиво, что команда пришла к этому не из книжки Голдратта, а из "просто смотрю и вижу".
- Третье: честность про "менеджер ничего не создает". Мало кто решается такое написать. Добавлю от себя: создает, но то, на что нельзя показать пальцем. Вроде выращенного преемника или разговора, после которого проект не закрыли. Спасибо, что показали цену профессии, а не только ее глянец!
Вопрос спонсора про закупщиков - это же классический разрыв output/outcome, только рассказанный лучше, чем в большинстве книжек. У меня в практике ровно та же сцена, но только другие слова: команда показывает, что "скорость выросла и тикетов закрыли больше" (система работает), а бизнес спрашивает "клиенту-то стало легче?". И в этом месте обычно повисает пауза:)
Сильнее всего зашёл график со столбцом "Исчезло", заполненным один раз из пяти. Болезненно точная картинка: автоматизация чаще перекладывает ручную работу, чем убирает её, просто новая работа не попадает в отчёт. Мы постоянно считаем исчезнувшие операции и почти никогда появившиеся(
Также полностью согласен с "не начинайте с KPI". Число без исходного состояния - это не цель, а ставка (вы сами это слово и употребили). В доставке та же ловушка: назначить velocity на разработчика можно, но это уже не измерение, а способ научить людей рисовать нужную цифру. Добавил бы к карте выгод только одно: у неё, кроме владельца, должен быть срок годности. Бэйзлайн, который не сняли на старте, через год не с чем сравнивать (контекст уедет, и "посчитаем потом" превращается в "посчитать уже нельзя").
Жду продолжение про владельца выгод)
Когда дочитал, то поймал себя на том, что мы с разных концов пришли в одну точку (я про свою статью о LeSS и TT). Вы под моей статьей справедливо написали, что "несколько команд + один продукт" - это ещё не диагноз, а вывод. А здесь у вас та же мысль в чистом виде: "мы не разделили один проект - мы обнаружили несколько проектов, которые ошибочно считали одним".
В продуктовой разработке я проверяю это грубым тестом: имеет ли релиз ценность только когда все команды выкатились вместе или кусок можно довезти пользователю в одиночку. Если в одиночку, то "продукт" был просто вывеской и масштабировать надо не координацию, а наоборот, расцеплять.
И полностью подписываюсь под "паспорт спасает не шаблон, а полномочия вернуть его на доработку"! У меня то же самое с "готовностью задачи": она работает, только если команда реально может отказаться брать неготовое. Без этого права - всего лишь очередная форма для галочки.
"Код исполняется", по-моему, является ключевой строчкой всей статьи. Добавлю с другой стороны: ровно так же исполняется и оргструктура. Если бизнес не выбрал владельца сквозного результата, границы всё равно будут проведены (не решением, а тем, как исторически сложились команды и кто кому звонит в обед). Конвей сформулировал это ещё полвека назад: "...система повторяет коммуникации организации, которая её строит".
Поэтому Ваше "отлагательное вето" я бы распространил и на людей: прежде чем автоматизировать процесс, честно спросить, есть ли вообще тот, кто отвечает за него целиком. Если нет владельца, то система просто зальет бетоном текущую неразбериху, о чем Вы и пишете.
P.S. а "Поезд с фонарем" забираю в цитатник:)
Спасибо за Ваш комментарий! И да, Вы правы в главном: я сжал шаг между диагнозом и рецептом, а он-то и есть самый важный, а в статье он подан слишком коротко. Кратко постараюсь исправиться здесь, ниже:
На практике до LeSS я вообще не дохожу, пока не пройден ровно указанный гейт. Первый вопрос - это правда один продукт или несколько потоков ценности, склеенных организационно? Проверка простая: релиз имеет ценность, только когда все команды выкатились вместе или команда способна довезти ценность своему пользователю сама? Если второе, то это не масштабировать Scrum, а наоборот, расщеплять то, что продуктом никогда не было.
Дальше уже идет Ваш список целиком: границы продукта, единый владелец результата, реальные полномочия PO (а не прокси без полномочий, "на бумаге") и, конечно же, природа зависимостей. И решение/лекарство абсолютно разное: организационные лечатся feature/stream-aligned-командами, а вот структурные командами не лечатся в принципе (там надо расцеплять систему или честно платить за координацию).
Но самое интересное, но и ироничное здесь в слендующем: LeSS сам "отказывается стартовать", пока не отвечены именно на те вопросы, которые Вы перечислили в своем коменте: "что есть продукт" и "кто тот единственный PO с властью приоритизации". Так что Ваша критика не против LeSS - это первый гейт честного LeSS (и правильно начинать искать болезнь ровно тогда, когда этот гейт проскакивают!).
Спасибо большое за действительно глубокий разбор (редкий по качеству)!
Спасибо! Отвечу коротко - Вы, кажется, уже всё для себя решили)
Уточню лишь, что те пункты выше и были моим личным порядком действий, просто без имён команд и внутренних цифр бывшего работодателя (в публичный комментарий их не выношу - это профгигиена, а не отсутствие кейса).
Рад был обменяться; вопросы реально помогли докрутить будущую статью. Успехов! 🙂
P.S. а насчёт «похоже на нейросеть»: если структурно и со ссылками читается как «слишком гладко», то приму за комплимент. За гладкостью года практики, а отсылки - чтобы Вы не верили мне на слово.
Отличный вопрос - Вы нащупали самую больную и самую интересную часть темы. Отвечу развёрнуто, потому что коротко тут легко соврать.
Сначала соглашусь: если «под предлогом адаптации» отвалились и оценки, и демо, а взамен не появилось ничего, то тревога бизнеса абсолютно законна. Это не «бизнес не понимает Agile», это реальная потеря прозрачности, и её надо закрывать. Вопрос только - чем?
Возвращать burndown и story points я бы не спешил: они и раньше давали иллюзию контроля, а не контроль (хотя признаюсь, я истинный поклонник относительных оценок/SP, но...). Я бы заменил выпавшие «якоря» на более честные.
Прозрачность без оценок - flow-метрики. Throughput (сколько ценных задач реально довезли за период), cycle time/lead time (сколько задача живёт от старта до прода), WIP и work item age (что «застряло»). Story points не критически нужны (опять же повторюсь, я их очень уважаю, но как один из инструментов, который работает тогда, когда действительно есть в нём необходимость) - throughput считает готовое, а не гипотетические очки. Прогноз бизнесу даём вероятностно: «по нашей истории с ~85% эти N задач выйдут к дате». Это язык бизнеса: как быстро, как стабильно, когда.
Здоровье доставки - DORA-4: частота релизов, время изменения до прода, доля неудачных изменений, время восстановления. Это про систему и поток, не про людей. И наглядно показывает бизнесу, что «машинка едет ровно».
«Показать инкремент» - вернуть, но дёшево. Потерянное демо - вот это реальная потеря. Не обязательно возрождать живое демо каждый спринт: хватит короткого async-чейнджлога «что вышло и какую ценность несёт». Дёшево и закрывает сразу и прозрачность, и вторую вашу боль.
Связать инженеров с ценностью. Раз «не видят инкремент» - в каждой задаче фиксируем «зачем» и ожидаемый эффект, а после релиза возвращаем команде цифры использования/adoption и отзывы клиентов (здесь, в том числе, в очень большой степени зависит от прОдукта (Product Ownera) - его постоянной работой с продуктом (в т.ч. и после релиза фичи) и взаимодействия с командой). Инженер, который видит, что его фича живёт - сам себе мотивация.
Про «измерять людей». Тут практика на удивление единодушна: мерить стоит систему, поток и исходы - не выработку конкретных людей. SPACE (Microsoft/GitHub), DORA и свежий DX Core 4 прямо предупреждают: индивидуальные output-метрики (строки, коммиты, velocity на человека) гарантированно геймятся (закон Гудхарта) и рушат командную работу. Даже McKinsey в 2024 попробовали продать «продуктивность на разработчика» - и получили публичную отповедь от Кента Бека и практиков ровно за это. Для человека метрики полезны как зеркало для роста, а не как линейка для оценки.
И, пожалуй, главное - важнее любой конкретной метрики то, кто ею владеет и зачем. Метрика, которую команда выбрала сама и крутит, чтобы улучшать поток - работает. Та же метрика, спущенная сверху как инструмент контроля, превращается в театр: её начинают рисовать, а не улучшать. Поэтому первый шаг: не «внедрить метрику», а договориться, что измеряем ради решений, а не чтобы кого-то поймать. Хорошее руководство даёт команде найти и обкатать то, что реально работает в её контексте, и спрашивает за исход, а не диктует единственно верную линейку сверху.
Вы, по сути, накидали план моей следующей статьи - «прозрачность и метрики без story points». Честно уместить её в комментарий не выйдет, так что, с вашего позволения, разверну отдельно. Спасибо за по-настоящему хороший вопрос!)
P.S. Отдельно отмечу: приятно видеть бэкенд-разработчика, который так предметно копает в управленческие метрики - обычно этим по-настоящему проникаешься уже из кресла руководителя. Если метите туда, то Вы заметно впереди графика 🙂
Спасибо, запрос справедливый - давайте приземлю)
Небольшая ремарка: как раз середина статьи - не теория. Восемь команд, разработка отдельно, поддержка отдельно, баг из прода съедает у инженера полтора-два дня спринта - это мой собственный департамент (правильнее сказать, реальная ситуация в нескольких компаниях из моего реального опыта), а не пример из книжки.
Но соглашусь вот в чём: в статье мало сказано, чем такая перестройка оплачена. Если совсем по-суровому:
Ни один фреймворк не внедряется «по книжке». В реальности берёшь принципы (один бэклог, команда отвечает за свой кусок от и до) и адаптируешь под своих людей, свой легаси и своё начальство. У нас тоже был не «чистый LeSS», а рабочая версия под наш контекст.
Самое сложное - не механика, а люди. Инженеры не хотят брать поддержку («я разработчик, а не саппорт»), менеджеры боятся потерять контроль, у кого-то привычная роль исчезает. На это уходит больше сил, чем на все схемы вместе взятые.
Если "мандата" на большую перестройку нет - и не надо «внедрять фреймворк». Начните с одной боли: например, объедините разработку и поддержку в одной пилотной команде на одном участке продукта - и посмотрите на результат через пару месяцев. Это приземлённее любого фреймворка и именно так оно обычно и начинается.
А какая реальность у вас - сколько команд, и что болит сильнее всего? Интересно прикинуть, с чего начинал бы я.
Спасибо за отзыв! Замечание принимаю - статья писалась для тех, кто уже успел поуправлять несколькими командами, поэтому местами она тяжеловата.
Попробую простыми словами объяснить то, что в статье осталось за кадром:
SAFe - это способ организовать работу очень большой компании, где над одним делом трудятся сотни людей. Он строит «этажи»: наверху решают, куда идём; ниже - большие группы команд; ещё ниже - сами команды. Все живут по общему расписанию: примерно раз в квартал собираются и вместе планируют следующий кусок работы. Плюс - сотни людей двигаются согласованно и руководству всё видно. Минус - очень много правил, ролей и собраний: легко увязнуть в процессе и растерять скорость.
Scrum@Scale - придумал один из авторов Scrum. Идея другая: не строить этажи, а соединять обычные Scrum-команды между собой. Представители команд регулярно встречаются и решают общие вопросы - и так на каждом уровне, до самого верха. Главное правило: добавлять новые встречи и роли только там, где без них по-настоящему больно.
Если совсем на пальцах: SAFe строит завод с цехами и регламентами. Scrum@Scale - сеть небольших бригад, которые договариваются между собой. А LeSS (про который статья) предлагает третье: вообще не добавлять лишнего, а наоборот - убирать.
Идею про версию «для входящих в тему» забрал в работу - возможно, сделаю отдельный ликбез с картой фреймворков и простыми определениями. Спасибо, что дочитали!)