Как выстроить собственную систему управления

Путь Михаила не был заранее рассчитанной лестницей. Он изучал материаловедение и сверхпроводимость, затем работал верстальщиком учебных курсов, тестировщиком, разработчиком, администратором, аналитиком, руководителем проектов и генеральным директором небольшой компании. Собственный бизнес научил видеть работу целиком, но зависимость от одного заказчика привела к кассовому разрыву и болезненным расставаниям. После выплаты долгов диверсификация не получилась, и в 2013 году он выбрал найм, чтобы сменить среду и продолжить учиться.

В Альфа-Банк Михаила привела репутация: за полтора года до перехода он рекомендовал банку трёх сильных сотрудников, а затем сам написал их руководителю. Свободной позиции не было, но для Михаила решили её найти, потому что рекомендованные коллеги отлично себя показали. Проект лояльности закрыли через три недели после его прихода, зато внедрение CRM показало enterprise-дисциплину с заранее подготовленными обходными сценариями. Позже перенос облачной платформы лояльности в собственный контур обернулся почти новой разработкой. Михаил хотел уйти из-за потраченных денег, но COO назвал провал оплаченной банком учёбой, стал его ментором и помог разрулить проект. Вендорскую систему запустили примерно на неделю, затем заменили собственной параллельной разработкой. Урок — признать последствия, исправить их и превратить опыт в новую способность.

Авторитарный стиль помогал Михаилу в кризисах: один человек быстро задавал направление и снимал неопределённость. На уровне дирекции тот же механизм стал пределом, потому что организация зависела от суждения одного лидера. Самая болезненная ошибка — попытка заставить руководителей поддержать центр координации с помощью распечатанных заявлений об увольнении. Никто не подписал, но все обиделись. Нельзя приказать людям сотрудничать или просто объявить структуру: нужен общий язык взаимной ценности, зависимостей и будущей работы.

При переходе от проектов к продуктам автономной команде всё равно требовались изменения в десятках систем. Попытка собрать все компетенции внутри продукта дала большую группу с неравномерной загрузкой, поэтому над самостоятельными Scrum-командами появились руководители направлений и координаторы связей. Следующим шагом стали доменные CTO с ответственностью за технологический домен. Михаил сначала гордился ростом с пятисот до тысячи человек, но затем сменил критерий: важен результат, достигнутый меньшим ресурсом. Новая команда на каждое изменение часто маскирует неэффективность, поэтому инвестиции нужны в автоматизацию и повторно используемые платформенные возможности.

Разделение на продукт и платформу создаёт новый конфликт. Централизация собирает сильных инженеров, но отрывает их от пользовательской задачи; распределение по вертикалям сохраняет контекст, но ведёт к дублированию. Декларация «теперь вы одна команда» этот стык не решает. Михаил строит договор вокруг взаимной пользы: платформа должна облегчать работу продуктовых команд, а продукты — давать реальные сценарии и вклад. Цель — небольшие подвижные команды на сильной общей основе, хотя модель пока остаётся экспериментом.

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