Модель Sbergile 2.0: как это было устроено
Собрано 04.09.2026 из двух источников: моего скрипта к видео (сентябрь 2017) и расшифровки самого видео. Текст описывает модель такой, какой она была в 2017 году, и публикуется как архив, а не как рекомендация на сегодня. Смотреть исходное видео.
Зачем крупному банку, у которого всё хорошо, перестраивать работу? Вопрос звучал именно так, и он справедливый. Банк занимал ведущие позиции и в России, и в мире, а трансформация быстрой не бывает: изменить процессы, структуру команд и сам подход к работе — это не один год.
Ответ был в другом. Рынки и экономика меняются, конкуренты становятся быстрее, и через пять лет уже не факт, что будет так же хорошо, как сейчас. Перестраиваться начинают не тогда, когда прижало, а пока запас есть.
Четыре цели
Сокращённое время до рынка. Веб-приложение потенциально может отдавать новый функционал клиенту несколько раз в день, мобильное от одного дня до недели. От идеи до рук клиента должно проходить не восемнадцать месяцев, а два-три.
Эффективнее с теми же ресурсами. Сокращать операционные расходы, ставить новые инструменты и процессы, делать работу быстрее меньшими силами.
Делать то, что нужно. Не отвлекаясь на второстепенное. Фокус на клиента и на то, что ему нужно сейчас.
Люди как капитал. Привлечь лучших можно, только создав условия для интересной работы. И работа должна приносить удовольствие, иначе лучшие не приходят.
Четыре условия, без которых цели недостижимы
Отказ от микроменеджмента и лишнего контроля: человек сам ищет лучший способ решить задачу. Автономность команд, а значит кросс-функциональность и работа над своим продуктом от начала до конца, с возможностью самостоятельно вывести результат наружу. Отказ от компонентных команд в пользу сквозных. Цель, которая задаёт направление и границы: измеримая, с бизнес-ценностью, и приоритеты команда расставляет исходя только из неё. И полномочия вместе с ответственностью, причём важно, чтобы команда сама эти правила приняла.
Сквод
Команда в модели называется сквод, и в нём не больше девяти человек. Сквод собирается вокруг цели, а значит должен нести все компетенции, чтобы дойти до неё сам. Дошёл — сквод может быть расформирован, а на его месте собран другой, с теми компетенциями, которых требует новая цель.
Типов сотрудников в скводе два.
Customer Journey Expert, эксперт пользовательского опыта. Сфокусирован на своей области знаний, отвечает за достижение целей команды, максимально ориентирован на потребности клиента и может сменить сквод, не меняя позиции.
Инженер. Сфокусирован на разработке и сопровождении, отвечает за достижение целей наравне с экспертом, несёт сквозную ответственность за ИТ в команде и трайбе и работает над сокращением времени до рынка своего продукта.
Скводы объединяются в трайб, и число скводов в трайбе не ограничено. Ограничение другое: скводов должно хватать ровно на то, чтобы трайб двигался к своей цели.
Владелец продукта
В каждом скводе выделяется лидер, и это роль владельца продукта. Роль, а не позиция, и выполнять её может либо эксперт по клиентскому опыту, либо инженер, в зависимости от цели команды.
Он определяет цели и способы измерить их достижение, собирает и приоритизирует бэклог, проводит события команды и связывает бизнес с ИТ. С лидером трайба встречается еженедельно, около получаса. В больших трайбах появляется центральный владелец продукта, который представляет три-пять команд и одновременно ведёт свою.
Три события, которых раньше не было
Со стендапом, планированием, обзором и ретроспективой все знакомы. Модель добавила к ним три встречи, и вот они как раз были новыми.
POCLAC. Неформальная еженедельная встреча не длиннее тридцати минут. На ней разбирают, какова текущая цель сквода, может ли команда двигаться к ней без препятствий, хватает ли владельцу продукта ресурсов, какие компетенции надо развивать, чтобы дойти быстрее. И там же участники сквода получают обратную связь.
Portfolio Marketplace. Раз в месяц, четыре часа, участвуют лидер трайба и владельцы продуктов. Синхронизируют цели скводов с целью трайба, выявляют зависимости между ними и правят планы на горизонт не больше трёх месяцев.
Quarterly Business Review. Раз в квартал, четыре часа, участвуют члены правления и лидеры трайбов. Обсуждают цели и что было сделано за квартал для их достижения, говорят про ресурсы, корректируют цели трайбов и зависимости между ними.
Что из этого стоит помнить
Sbergile 2.0 относилась к масштабируемым моделям типа Spotify и разделяла ценности и принципы Agile-манифеста. Внутри неё могли применяться Scrum, Kanban, XP и другое, если это не спорило с тем, что модель задавала прямо.
Самое живучее в этой конструкции не структура и не названия ролей, а горизонт трёх месяцев на планах и квартальный разговор про цели с правлением. Названия ролей за девять лет поменялись у всех, а вот ритм проверки целей работает и сегодня.