ЛК
Меню
Как Agile и Канбан помогают топ-менеджерам: опыт Бориса Фальсона

Как Agile и Канбан помогают топ-менеджерам: опыт Бориса Фальсона

В новом эпизоде подкаста Алекс Цыбульник беседует с Борисом Фальсоном — автором книги «Гибкие управления проектами и продуктами», экс-STO Softline, экс-техническим директором Headhunter и вице-президентом по продукту и аналитике в Сбермаркете. Один из пионеров Agile и Канбана в России — с этим званием он сегодня и пришёл в подкаст.

Кто такой Борис и почему его стоит слушать?

Борис с юности занимался программированием и математикой, но довольно быстро понял — его больше интересует управление. Начинал с открытия филиала разработческой компании в Оренбурге. Потом — CTO в Softline Development, где впервые столкнулся с Agile. Затем Headhunter — и здесь произошёл переход от классических процессов к Scrum, а затем и к Канбану. В Сбермаркете он уже не строил процессы с нуля, а был заказчиком крупной Канбан-системы — одной из крупнейших в стране, охватывавшей 1500 человек.

Почему Agile вообще понадобился?

Когда Борис пришёл в Softline, в компании использовались «водопадные» процессы в духе PMBOK — формальные, жёсткие, с отчужденным подходом. Хотелось большего: ценности для заказчиков, нормальных человеческих отношений внутри команд, гибкости. Так он познакомился с Никитой Филипповым и Асхатом Уразбаевым — фигурами, которые заложили основу Agile в России. С этого и начался путь.

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

Практика: как они это делали?

  • Пользовались простыми, но мощными инструментами, как берндауны в Excel, чтобы отслеживать скорость работы команды.
  • Вводили стендапы и визуализацию, несмотря на сопротивление — особенно в командах, у которых раньше процессов вообще не было.
  • Применяли инженерные практики из экстремального программирования — Борис подчёркивает, что без этого Agile превращается в пустую обёртку.

Почему Agile в России — это особый кейс?

В отличие от США, где Agile пришёл на смену избыточной бюрократии, в России он часто заменял её полное отсутствие. Были команды, в которых задачи просто «впихивались» снаружи без всякого процесса. Поэтому Agile нередко воспринимался как навязываемая бюрократия — особенно там, где раньше работали «по наитию». Но с другой стороны, Scrum помогал изолировать команды от хаоса хотя бы на спринт, что дало ощутимые плюсы.

Agile в России вырос в уникальных условиях — без фанатизма, с прагматикой и попыткой выстроить хоть какую-то систему. Да, были и карго-культы, и формальные внедрения, но опыт Бориса — пример того, как всё может работать по-настоящему.

Когда Agile идёт не туда: дичь, KPI и почему Agile у троечников не работает

Иногда Agile-команды начинают делать такие вещи, от которых волосы встают дыбом. Например, кто-то решает выплачивать премии по количеству сожжённых человеко-часов и гордо называет это Agile. Или KPI начинают завязывать на Story Points — хотя это примерно как драться микроскопом. Подобные истории — не редкость, причём и в довольно серьёзных компаниях.

Зачем это делают?

Часто причина кроется не в методах, а в том, что у команды (или руководства) не меняется ценностная база. Люди берут инструмент и используют его не по назначению. Менеджер, который искренне считает, что «люди плохо работают без жёстких KPI», увидит в любом числовом индикаторе повод «подогнать» под отчётность. Неважно, что он не понимает сути — главное, что теперь есть кнопка давления.

Вот отсюда и возникает та самая дичь — когда Agile только снаружи. Читается книжка, внедряется «ABCD», но за этим не стоит ни доверия, ни понимания, зачем всё это делается.

Agile — не про всех

Тут стоит признать: Agile работает не у всех. Или, как метко замечено — «Agile у троечников не работает». Чтобы скрам действительно полетел, нужна взрослая команда: профессионалы, которые уже варились в разных продуктах, умеют работать в сложных системах и понимают, что такое «делать хорошо».

Если дать полную свободу посредственной команде, где люди привыкли только к API и жёсткому регламенту, — с большой вероятностью продукт не выйдет. Или не выйдет вовремя. Им нужны чёткие процессы, рельсы и дедлайны. Потому что, если человек не нацелен на результат, не умеет брать ответственность, Agile становится просто хаосом.

Почему WIP-лимиты нужны даже сильным командам

Кто-то может подумать: раз уж речь идёт о профессионалах, зачем им какие-то лимиты? Но это не так. Даже самые крутые разработчики иногда хватаются за десять задач и не доводят ни одну до конца. Практика WIP-лимитов (Work In Progress) как раз помогает это отследить. Сильные команды воспринимают это не как ограничение, а как подсветку: где узкое место, где сбоит поток.

А для менее зрелых команд — это может быть вообще физическое ограничение. Доска с дырочками, в которые больше карточек просто не влезает — и всё, хочешь-не хочешь, завершай начатое.

Байка из OpenAI и почему у Google не получилось

Хороший пример важности фокуса — история одного из первых инженеров OpenAI. Его спросили, почему Google, изобретя архитектуру трансформеров, не сделал революцию на рынке LLM. Ответ: в

Google не было фокуса. Каждый занимался своим, VIP-лимитов не было, ресурсы размазывались. А в OpenAI была компактная, сфокусированная команда, которая могла объединить усилия. Вот и вся разница.

Книжки по теме: что стоит почитать

Если хочется глубже понять, как работают такие команды и почему доверие и автономность важнее процессов — есть две отличные книги:

  • No Rules Rules, она же «Никаких правил» — про культуру Netflix. Как доверие и плотность талантов позволяют упростить бюрократию и ускориться.
  • Drive Дэниела Пинка — про мотивацию в работе. Почему люди работают не из-за KPI, а ради мастерства, автономии и смысла.

Обе книги отлично ложатся на философию Agile, особенно если говорить о knowledge work, а не только про процессы.

Немного про экспертов

В начале 2010-х сильное впечатление произвели Асхат Уразбаев и Никита Филиппов — один больше про процессы, другой про продуктовый подход. Из западных — Мартин Фаулер и Уорд Каннингем (автор Wiki и один из подписантов Agile-манифеста).

Про Канбан — Лёша Пименов, у него мощная связка теории и практики. И, конечно, Алексей Жеглов — с его математическим подходом к фреймворкам вроде Fit for Purpose. Ну и если хочется покопаться в предсказаниях и метриках — Трой Магиннес и его Excel-модели для анализа потока задач — настоящий клад.

Почему Kanban стал ключевым инструментом в HeadHunter и Сбермаркете: практический взгляд от Бориса Фальсона

Когда Борис Фальсон пришёл в HeadHunter, он уже имел опыт работы с Agile, особенно со Scrum. Однако на определённом этапе встал вопрос: как увеличить количество проверяемых продуктовых гипотез? Scrum отлично подходит для проработки качественных гипотез — но не даёт инструментов для масштабного роста количества проверок. Именно здесь в игру вошёл Kanban.

Миссия: максимизировать поставку валидированной ценности

Команда в HeadHunter сформулировала для себя чёткую цель: максимизировать поставку проверенной пользовательской ценности. Под ценностью понимали метрики — отклики, приглашения, показатели счастья пользователя. Под валидированностью — результаты A/B-тестов.

Проще говоря, вся работа раскладывалась на два множителя:

  • Качество гипотез — за это отвечают процессы Discovery;
  • Количество проверок — именно здесь Kanban стал незаменим.

Почему Scrum не справился, а Kanban — да

Scrum был эффективен для детального проработки задач, но не масштабировался по скорости. Kanban же позволил:

  • Сфокусироваться на throughput и lead time;
  • Выстроить простые правила внутри процессов, например: если задача оценена выше определённого порога, её обязательно пересматривает технический директор и директор по продукту на предмет упрощения или устранения оверинжиниринга;
  • Подключить автоматизацию — флаги в Jira, подсветка «зависших» задач, отчёты для топ-менеджеров по долгоживущим задачам.

Как измерялась эффективность потока

Для измерения эффективности потока команда:

  • Делила этапы на In Progress и Done;
  • Смотрела, сколько времени реально тратится на полезную работу;
  • Учитывала периоды простоя — для этого использовали флажки в Jira и собственную визуализацию.

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

Организационные препятствия и «взрослые» проблемы

Самые существенные барьеры возникали не внутри команд, а на стыке с другими подразделениями и подрядчиками. Kanban буквально «вскрывал» эти узкие места. Решением стало:

  • Проведение регулярных операционных ревью на уровне компании;
  • Кластеризация проблем и подключение топ-менеджмента для устранения узких мест вне зоны влияния команд;
  • Работа с подрядчиками на основе метрик и прозрачных SLA.

Что получилось сделать в Сбермаркете

В Сбермаркете масштаб задач был в разы выше. Первоначальная идея собрать всё на одной Jira-доске провалилась: слишком большой объём. Тогда Борис поступил иначе:

  • Создал новую доску и попросил команды заводить туда ключевые проекты;
  • Провёл деление доски на Upstream (Discovery) и Delivery-этапы;
  • Настроил метрики (в том числе lead time и throughput) на всех уровнях структуры: от команды до домена.

Использовали BI-плагины для Jira, строили дашборды по процентилям, а не только по среднему или медиане. Это позволило избежать иллюзий и понять реальную скорость процессов.

Какие решения принимались на основе метрик?

Метрики помогали принимать стратегические решения о фокусе:

  • Где проседает производительность;
  • Куда направить внимание топ-менеджмента;
  • Какие домены требуют поддержки или глубокой диагностики.

Главное — не сравнивать «яблоки с апельсинами»: клиентский и операционный домены работают в разном ритме и с разными циклами A/B-тестов.

Как это помогает топ-менеджеру?

Если ты технический директор — Kanban просто must-have. Но если ты руководишь бизнесом, продуктом или подрядчиками, — важно не только внедрить Kanban, но и продвигать его через soft power. Чтобы команды начали мыслить метриками, потоком, скоростью и фокусом на ценности.

Тренинги по теме

Cамообучение Канбан Методу

Откройте для себя дверь в мир Канбан Метода, используя опыт сотен практиков в российских и зарубежных компаниях.

15 000 ₽

Запуск Канбан Инициатив

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

от 50 000 ₽

Развитие Канбан Инициатив

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

от 50 000 ₽


Канбан для Скрама

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

от 25 000 ₽


Канбан для Управления Продуктом

Необходимый набор знаний для выстраивания End-to-End потока создания клиентской ценности, построения Discovery Канбан-системы и нахождения баланса между Discovery и Delivery частями вашего процесса создания ценности.

от 50 000 ₽


Канбан Коучинг и Организационная Зрелость

Набор социологических и психологических инструментов для проведения эволюционных изменений в компаниях с использованием Канбан Модели Организационной Зрелости.

от 90 000 ₽