В новом эпизоде подкаста Алекс Цыбульник беседует с Борисом Фальсоном — автором книги «Гибкие управления проектами и продуктами», экс-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. Чтобы команды начали мыслить метриками, потоком, скоростью и фокусом на ценности.
