Герой подкаста — Александр Томилов, авторизованный Agile-инструктор от IC Agile, практикующий коуч, человек, который провёл десятки команд через трансформации. Сегодня он делится кейсом внедрения Канбана в «Ленте».
Немного о себе
Александр начинал карьеру как инженер-машиностроитель, но судьба занесла его в IT через визуализацию, работу с клиентами и интерфейсы. В 2016 году он впервые столкнулся с Agile — на собственном стартапе. С тех пор это стало его профессиональным направлением.
Как всё началось
После стартапа Александр начал работать независимым консультантом. Один из первых крупных клиентов — «Силовые машины», где он совмещал инженерный бэкграунд с коучингом. Компания входила в группу «Севергрупп», и вскоре его пригласили в другой актив группы — «Ленту».
Изначально он пришёл как скрам-мастер и agile-коуч в проектный офис по трансформации — это не IT, а бизнесовое направление, работающее со всей компанией.
Как Канбан пришёл в IT
Команда Александра запускала обучающие программы по Agile в разных подразделениях. Одна из них прошла и в IT. После тренинга «Agile Basics» появилось несколько заинтересованных команд. Вскоре поступил запрос на запуск полноценного Канбана.
— Мы рассказали, показали, и это вызвало интерес. Руководитель разработки поддержал идею, и три команды (ну, две с половиной, как это обычно бывает) стали первыми пилотами.
Выбор Канбана был не случаен: IT в «Ленте» — это центр затрат, а не ценности, что сразу делает классический Scrum менее уместным. Канбан же дал нужную гибкость и прозрачность.
Что показал старт
На первом этапе командные «болячки» были типичны: перегруз, постоянные переключения, неясные требования, изменчивые приоритеты, функциональные «колодцы» внутри и вне команд. Ничего экзотического, но и этого было достаточно, чтобы задуматься о системных изменениях.
Формат запуска был практичным: начали с команд, а заинтересованных стейкхолдеров подключали позже, уже в процессе работы. Это помогло избежать избыточной бюрократии и быстрее выйти на первые результаты.
Как Канбан стал драйвером трансформации в крупной организации: кейс «Ленты»
После запуска первой Kanban-системы команды в «Ленте» начали работать по новым правилам. Первая доска была собрана в Miro — с кастомными карточками, тёплой атмосферой и вниманием к деталям. Когда в компании появилась Jira, команды переехали туда, и началось настоящее движение: этапы формирования команд, сопротивление, адаптация. В итоге одна команда сошла с дистанции, две другие — успешно развивались, и уже через год сформировался сильный кейс, на который можно было опираться.
Эту стратегию внутри называли «передовое хозяйство»: сначала создаётся один успешный пример, который можно масштабировать. Пример показал отличные метрики: улучшился lead time, повысилось качество взаимодействия, команды стали чувствовать себя увереннее, а руководство признало эффективность подхода. Началась трансформация.
Переход к масштабированию через Flight Levels
Следующим этапом стало внедрение концепции Flight Levels — организации управления на нескольких уровнях. Это позволило сфокусировать людей вокруг цепочек создания ценности. Появились домены (команды команд), а следом — доменные команды (второй уровень), и далее стратегический уровень (третий).
Важно: понимание необходимости масштабирования возникло не сверху и не в результате совещания, а органически — через очевидную пользу и результаты. Когда люди увидели, что подход работает, сопротивление стало бессмысленным. Организация просто почувствовала, что это эффективно.
Эволюция через микро амбициозность
Трансформация шла не через стресс и принуждение, а через «путь микро амбициозности» — постепенное, но устойчивое развитие. Без давлений, без ломки. Спокойно, с уважением к тем, кто не готов к изменениям. Никто не заставлял участвовать — в процесс вовлекались только те, кто сам был готов. Именно это и дало устойчивость.
По словам Александра Томилова, трансформация шла по принципу: «лучше быть заразительным примером, чем агитатором». И в этом была своя магия: когда команды видели реальные улучшения — они сами хотели быть частью этого процесса.
Поддержка сверху и безопасность внутри
Руководство IT активно поддерживало инициативу. Но даже с этой поддержкой не обошлось без скепсиса со стороны более консервативных сотрудников. Тем не менее, в команде не было увольнений, не было драматичных уходов. Наоборот, среда стала безопасной — и это было решающим фактором.
Сама атмосфера в команде обрела характер «племенной» значимости: появилась общая цель, ощущение принадлежности, уважение к вкладу каждого. Изменения не спускались сверху, а зарождались изнутри — из опыта, из примеров, из результатов.
Основные паттерны сопротивления: инженерный и процессный
Александр выделяет два ключевых паттерна, через которые команды воспринимают Канбан:
- Инженерный паттерн — фокус на инструментах, а не на людях. Здесь важно напоминать себе, что «люди важнее процессов». Канбан ради Канбана — бессмыслен. Он нужен, только если помогает достигать осознанных целей.
- Процессный паттерн — попытка зафиксировать процесс «раз и навсегда». Однако Канбан поощряет разнообразие и постоянную адаптацию. Регламенты — не истина в последней инстанции. Важно научиться мыслить гибко, становиться наставниками, а не бюрократами.
Пример — лучший способ обучения
По мнению Александра, лучший способ трансляции ценностей — это быть их носителем. Не тренинг, не сертификат, а личный пример. Только когда ты живёшь в этой парадигме — она начинает «заражать» других. И это главный драйвер устойчивых изменений.
«Любое знание — это всего лишь слухи, пока ты не прочувствовал его в мышцах», — говорит он, ссылаясь на мудрость одного из племён Папуа-Новой Гвинеи.
Двойные послания и партизанщина: как не стоит внедрять изменения
Когда речь заходит о трансформации культуры, без участия лидеров не обойтись. Александр чётко обозначает: структура первична, и если руководитель декларирует одни ценности, а транслирует другие — подчинённые будут следовать тем, которые проявлены в действии. Это психология. Так работает «двойное послание»: на словах — «давайте поговорим», на деле — «где твой отчёт».
Подобная шизофреногенная коммуникация разрушает доверие, и вместо адаптации идёт откат. Поэтому любые изменения должны начинаться с головы — с руководителей.
Отсюда — логичный вопрос: а можно ли внедрить Agile снизу, «партизанскими» методами?
Александр делится опытом: «Меня уволили в тот день, когда я попробовал». Партизанщина — история болезненная и рискованная. Может быть, на старте, как тренировочный полигон, и сработает. Но без социализации, без контрактов с руководством — превращается в хронический стресс. «Нельзя жить долго в состоянии когнитивного диссонанса», — отмечает он.
Вместо партизанщины — микроэксперименты. Это и есть суть первого соглашения в Канбан-методе: «Соглашение об изменениях». Маленький шаг — визуализировать работу, договориться о правилах коммуникации — безопасен и работает эволюционно. Без резких движений, но с устойчивым результатом.
Kanban Maturity Model: от индивидуальных задач к потокам ценности
Лёша (ведущий) дополняет: Канбан хорош тем, что его можно внедрять с любого уровня зрелости. На «нулевом» уровне — это может быть индивидуальная практика. На уровне ML1 — договорённости в команде: визуализация, WIP-лимиты, обратная связь.
Но вот дальше — на уровне ML2 и выше — без поддержки руководства и мышления на уровне сервиса (end-to-end) не выжить. Здесь появляются роли вроде менеджера потока, и без бережливого мышления не обойтись. То есть настоящая трансформация начинается не с фреймворка, а с подхода к работе и взаимодействию.
Эволюционные изменения: путь через сомнение
На вопрос о собственных изменениях Александр отвечает без пафоса: «Я стал больше сомневаться». Сомневаться в том, что казалось незыблемым, ставить под вопрос собственные убеждения — и вот уже мышление становится эмпирическим. Именно это, по его мнению, и есть путь эволюции: не революции, а постоянного уточнения и переосмысления.
Почему Канбан — это «автомат Калашникова» среди методов?
Канбан, по словам Александра, завоевал популярность, потому что работает там, где Scrum не приживается. Большая часть IT сегодня — это поддерживающие функции, не продуктовая разработка. А Scrum, хоть и любим многими, требует высокого уровня зрелости, ясных целей и структуры. Канбан же скромен: как «автомат Калашникова», срабатывает в любых условиях, даже при минимальной вовлеченности и ресурсе.
