«Как сделать идеальное ИТ, и почему его захочет убить бизнес? | Сергей Буш»
🎙 ITBizRadio, выпуск первый
Термина BizOpsDev ещё нет.
Но вся основа уже звучит — через OpsDev, stream team и бизнес, вклиненный прямо в команду.
О чём разговор:
– как четверо айтишников делают то, чего не может сорок,
– как пожар в машинном отделении банка «Открытие» родил первую stream team,
– почему бизнес систематически убивает лучшие команды,
– и почему конвейер, построенный для других, делает несчастными самих строителей.
«Открытие» 2010-го и Digital Last [03:34]
Ведущий (Алексей): Друзья, всем привет. Очередной выпуск подкаста IT Biz Radio. В студии наша обычная команда: я — Алексей Куксенок, Толя Иванов и Саша Мартынов. Сегодня у нас интереснейший гость — Сергей Буш. Сам представился как самый старший айтишник из всех, кто был на нашем подкасте. Первую IT-компанию открыл аж в девяностом. Мы хотим поговорить о работе в банке «Открытие» — в своё время банк считался одним из образцов построения IT-бизнеса. Сергей, слово тебе.
Сергей: Спасибо, коллеги. Начну с того, что я создался не просто в девяностом, а одиннадцатого сентября — символическая дата для Америки. Было первым частным предприятием в городе Омске. До этого были только комсомольцы и кооперативы. Горбачёв издал указ, что можно создавать частный бизнес. Гербовая печать и всё по-взрослому.
В девяносто втором устроился в банк — думал, на три месяца. Происходил массовый выезд немцев из России, вся семья уехала, я думал, что тоже. Не уехал. В девяносто третьем запустили АБС на Oracle. В девяносто четвёртом поехал на стажировку в Leeds Building Society — четвёртый по размеру ипотечный банк Англии. Семь месяцев. С девяносто восьмого — кризис, диверсификация в инженерию: структурированные кабельные сети, десять лет полный цикл строительной компании, двести штатных сотрудников. В «Открытии» работал с десятого по тринадцатый-четырнадцатый год.
Ведущий: IT-шный бизнес в девяностом году — это вообще достижение. Торговать куртками — понимаю. Но IT? Настоящие мощные автоматизированные банковские системы — в яблочко попали.
Сергей: Яблочко в яблочко. Предприятие называлось «Лаборатория 321». На третьем курсе я попал в ведущую лабораторию номер 321 Омского политехнического. Занимались сверхпроводимостью, прикладными научными исследованиями.
Переброшу мостик: всякие гуру говорят, что ближайшая аналогия к software development — прикладные научные исследования. Например, Дейв Фарли.
Ведущий: Научная составляющая, предпринимательская, экспертиза в банке. Хочется, Серёж, глазами бизнеса, такого мощного предпринимателя, посмотреть на то, как ты взаимодействовал с IT и помогал ему выстроиться в «Открытии».
Сергей: Я только первый раз устроился как айтишник в омский банк. А когда начинаешь работать — понимаешь, что надо делать бизнес. IT — это всего лишь мощный инструмент, с помощью которого я решал бизнес-задачи.
С руководителем, который меня взял в «Открытие» — Алексеем Гонусом, отвечавшим за корпоративный блок, — мы познакомились в девяностые. Есть книжка John Seddon, «Beyond Command and Control» — тогда ещё не написанная, появилась позже. Посыл: Digital Last — вначале бизнес, потом IT. IT должно забирать с людей рутинные операции, чтобы люди занимались собственно делом.
Он знал, что группа из четырёх айтишников при правильной организации может сделать то, чего не может и сорок. После позитивного опыта у него была куча негативного — он привлёк меня с защитной целью. Устроился я не в IT — устроился в бизнес. Был вице-президент на выходе. Моя задача — облегчить взаимодействие бизнеса с IT и не дать случиться пожару в машинном отделении.
Ведущий: Ты был заказчиком для IT, получается? Куратором?
Сергей: Абсолютно. Представлял интересы заказчика. Не только IT на меня повесили — все сопутствующие функции: HR, финансовые аналитики, связывающие подразделения, — чтобы бизнесу не мешали, чтобы бизнесу помогали.
Ведущий: Требовался ли перевод с айтишного на бизнес-язык? Ставишь задачу — приходят айтишники и говорят: «Helm, Spring Boot, авторизация, REST, спецификации».
Сергей: Ты говоришь языком зрелого IT. А когда я пришёл в «Открытие» — низкая база. Совсем низкая. Что нужно корпоративному блоку? АБС, которая выполняет платежи, расчёты, считает процентики на кредитике. Банк-клиент. Электронная почта. Простейшая система контроля заданий — бегунок со статусами, к которому можно прикрутить документики. Всё. Больше бизнесу ничего не нужно.
Моя самая большая экспертиза — я строил stream-aligned teams. Это то, что в Team Topologies появилось только в девятнадцатом году, да и то вторым продолжением, уже с Remote. Раньше это называли DevOps, но термин замылили — сегодня DevOps — это больше инфраструктура. Правильнее называть OpsDev: эксплуатация и разработка — одна группа, вклиненная прямо в бизнес. Когда такая группа вклинена, что они строят с бизнесом? Не здание — они строят когнитивное облако. Не нагрузку — облако. Все soft skills для того, чтобы говорить с бизнесом на одном языке, описывая сущности. Идеально, когда эти сущности один в один оттранслировались в код — тогда любой разработчик сразу говорит на языке бизнеса.
Когда я пришёл в «Открытие» — я это делать не собирался. Я собирался не допустить пожара в машинном отделении.
Пожар в машинном отделении [17:09]
Ведущий: Что для тебя могло стать индикатором пожара в машинном отделении?
Сергей: Он и случился. Был борт минус один в корпоративном блоке. Если бы пожара не случилось — я просто работал бы советником. Но пожар случился сразу, в 2010 году. Посмотрел, что происходит, как работает почта, с какой скоростью онбординг, — и уже в десятом понял: нужно СХД начального уровня, простейшая CRM-ка, процессы хотя бы отследить. Стал под себя ресурсы подтягивать. А второго августа одиннадцатого просто упал весь банк-клиент.
Ведущий: Упал банк-клиент — как это произошло?
Сергей: Чисто по Cynefin. Свалились в хаос. Одним днём решили: обновить банк-клиент в нескольких центрах одновременно — Иркутск, Новосибирск, Пермь, Москва. Всё централизуется, обновляется — серверное и клиентское, зачастую по сети. Телефония того времени, не тот интернет, что сейчас. Плана отката не было вообще. Роллбэка не было. Дизастер-плана не было. Всё встало.
После этого невозможно дозвониться ни в одно отделение банка, ни одному человеку в банке. Даже в десятом году, если выключаешь банк-клиент, бумажные платёжки и звонки невозможны. Бизнес остановился полностью. Для больших корпоративных клиентов — могут привезти. Для малого бизнеса — настоящий шок.
Полыхало несколько недель. Потом передали под меня. Я восстановил, настроил, передал обратно в большой IT — больше не упало.
Что такое бизнес-модель «Открытия»? Постоянная merger & acquisition, присоединение банков, попавших в АСВ, грамотная накачка уставного капитала. Модель, не завязанная на то, что происходит на земле. Два уровня: воздух и земля. Воздух — идеальный пиар и маркетинг. Земля — то, как работают люди, что чувствуют клиенты. «Открытие» — это идеальный воздух, и именно его вы видите в первую очередь.
Ведущий: Какие были последствия инцидента? Как это поменяло твой функционал?
Сергей: Репутационно спасти было нечего. Ведущий акционер приезжал, совещания чуть ли не каждый день. Параллельно выяснилось: кредитные заявки, которые обещал подрядчик, — тоже провал. Стал вопрос: если хотим — надо делать самим. И тогда я создал stream-aligned team внутри «Открытия».
Stream team: бизнес внутри команды [22:18]
Сергей: Team Topologies — хорошая базовая книжка. Прочитать для исходника. Но ряд важных моментов там отсутствует. Есть раздел: кто пишет, тот и эксплуатирует — это резко повышает качество.
Ведущий: Феноменальное изменение культуры, кстати, — когда сами команды в дальнейшем поддерживают и эксплуатируют.
Сергей: У меня только так. По-другому не могу — это насилие и издевательство над людьми. Но в книжке не хватает акцента: в эту же команду должны входить ключевые специалисты из бизнеса. Не технологи от бизнеса, которые что-то пересказывают. Не аналитики. А люди, которые пользуются этим каждый день.
Ведущий: То есть после инцидента вы поняли: надо делать самописную систему, отвечающую требованиям по отказоустойчивости. Для этого ты начал создавать команду разработки, где не только сама команда отвечала за работоспособность на продакшене, но и бизнес включил внутрь?
Сергей: Абсолютно. Начальник отдела — стейкхолдер, менеджмент — обязан быть вовлечён. Но ключевой специалист — это человек, который выдаёт кредиты или ведёт операционное обслуживание. Нужна парочка. Как их найти? В любой работе есть люди, которым просто интересен компьютер. Они, как правило, лучшие — успевают и работу делать, и им нравится этим заниматься.
По Cynefin есть комплексная область — там живут счастливые люди. В сложном и простом — конвейер. На конвейере счастливых нет. Если человек сидит на кредитном или операционном конвейере — да, сложный сегмент, но все стремятся туда, где комплексное. Ради чего создан человеческий мозг. Оставить след во Вселенной, как Джобс говорил, — можно только когда ты часть созидательной команды.
В работе программистов очень мало сложных и тем более простых вещей — всё в комплексном. Поэтому stream-aligned team — вся здесь. А ключевые специалисты из бизнеса — вместе с ней, в том же домене.
Как застраховаться, если команду могут разрушить? Если вы большой бизнес — сразу делаете две, «колбаску с двух сторон». Если не можете на старте — чудесное решение: команда поделена между независимым подрядчиком и внутренней частью. Внутренняя половина — чистый OpsDev. Внешняя, в зависимости от безопасности и интеграции, — DevOps. Но они должны быть единой командой. Мне всегда помогала моя маленькая Лаборатория 321, которая сейчас называется Hardsoft 321.
Год, три, пять: жизненный цикл команды [28:41]
Ведущий: Каков срок жизни и когда отдача от stream-aligned team?
Сергей: Год на формирование. Через три года — «джизусы», ходящие по воде. На отрезке пяти-семи лет на существующих инструментах проводят первую технологическую революцию: пересобирают на лету всё то, что работало. Уже была фантастика — идёт турбонаддув. Бац, всё работало чудесно — стало ещё чудеснее. Функционал может расшириться. А если их не разрушить дальше, то за десяточку-пятнашку проводят вторую революцию — перестраиваются на новый инструмент. Две технических революции.
Ведущий: Каков средний срок жизни айтишника в организации?
Сергей: Меньше трёх лет, коллеги, и срок снижается. Посмотрите резюме всех IT-руководителей — сколько? Год-полтора. Три конверта как работали, так и работают.
Ведущий: Вот мы из бизнеса взяли человека в техническую команду. За три-пять-семь лет он теряет связь с бизнесовой составляющей. Он станет одним из нас, перестанет быть человеком от бизнеса. Как порешать?
Сергей: Последнюю фразу ты сказал абсолютно верно. На каком-то этапе он может захотеть мигрировать в технологию — не хочет больше работать в конвейере, хочет творчества. Если это случится — без потерь: на такое чудесное место всегда найдётся человек из бизнеса. А потерять связь с бизнесом ему почти невозможно — он там прожил годы, видит насквозь.
Горизонт планирования — неверно функционируете. Есть две модели. Проектная: сроки, деньги. И сервисная. CAPEX и OPEX. Эти команды — OPEX. Если начал разрабатывать кастомный софт, то сразу должен понимать: такая команда нужна навсегда. Это и есть минимум бюджета. Не хочешь — используй только коммодити. Коробочное решение, ничего под себя не дорабатывай.
Семечка: SugarCRM и открытые коды [30:52]
Сергей: Почему мы спаслись за счёт системы хранения данных и за счёт SugarCRM? Потому что не с нуля начинали — очень быстро.
Ведущий: Это же open source CRM получается.
Сергей: Это была фантастика. Почему open source? Есть понятие low code — хайп идёт. Раньше это называлось Rapid Application Development. Хайп заходит на второй круг. Так же как виртуализация, потом облака — просто виртуализация ещё не созрела, а облака залетели.
Что такое low code? Я беру SugarCRM, поскольку он свободный. Убираю из него сразу же девяносто процентов ненужного. Оставляю только то, что нужно. Коды открытые — всегда могу изменить, поправить прямо там, где проблема. Не пляшу вокруг приложения костылями.
Ведущий: Нет никакого вендор-лока, полностью владеешь кодовой базой.
Чем меньше исходная кодовая база — та семечка, из которой выращиваешь своё прикладное решение, — тем лучше. Тем быстрее команда за неё хватается, решает, получает quick wins. Там, где у бизнеса реально болит. Это позволяет команде выжить. Если за первый год её не затоптали, не разрушили — идём к фантастическому рубежу три года. После трёх — это ребята, которых разрушить очень непросто.
Бизнес убивает лучшие команды [35:16]
Сергей: Почему проблемы с бизнесом? IT не донесло до бизнеса, как правильно делать. Бизнес вообще не видит этот комплексный домен по Cynefin. Для него комплексного домена не существует. Это хаос или детский сад. Для него существует только сложный. Когда берут CIO — хотят, чтобы CIO разложил в диаграммы, в проекты.
Ведущий (Анатолий): То есть для бизнеса максимальная сложность — когда нужна группа экспертов. Собрать правильных — осилят. И система всегда в идеале стремится к конвейеру, который по чек-листам работает.
Сергей: Анатолий, ну ты убил. Такая команда — самый дешёвый и выгодный сценарий при полной стоимости владения. Не на круг — сразу. Представим: бизнес некрупный, не может сразу позволить даже одну DevOps-команду. Надо искать компанию, где есть состоявшиеся DevOps-команды, — занимаются, например, CRM или АБС. Покупаешь часть ресурса. Не отдельного программиста.
Скажешь: «Hardsoft 321, нам нужна поддержка от твоей команды. Берём одного виртуального специалиста». А команда в себе содержит и PM, и аналитика, и тестировщика — уникально, исходя из своих компетенций. И они тебя и поддерживают, и развивают. Но это навсегда. Как только под себя сделал кастомные коды, через три-четыре года, если человеко-лет вложишь в программирование, система становится комплексной, сложной — заменить её становится головной болью.
Ведущий: Звучит круто. А где оборотная сторона? Какие сложности, кроме того, что удовольствие держать такую команду стоит дорого? Какие фундаментальные минусы?
Ведущий: Я так понял, ещё сроки. Год на запуск минимум. А бизнесу нужно здесь и сейчас. Как в твоём кейсе — он рухнул. Какие три-четыре года — бизнес ждать не будет. Даже года не будет.
Убегание от тигра: как команда защищена [38:29]
Ведущий (Анатолий): Как такие команды вообще выживают при полном непроникновении бизнеса в то, что это научно-исследовательская работа? Что проектный подход тут не работает — как они выживают?
Сергей: Когда приходишь в любую организацию — живёшь в условиях убегания от тигра. Тебе не надо, чтобы бизнес понял тебя до конца. Съедят худшего. Эта команда — как только сформировалась, даже если ты просто сказал: «Ребята, будем работать так, побежали», — в течение месяцев недогоняема тигром. Тигр — это, называется, уволить. Или разрушить.
Quick wins эта команда увидит гораздо быстрее. Вторая защита — сам бизнес. Как только бизнес понимает, что есть люди, которым не пишешь в helpdesk, не звонишь через первую линию, — это вообще анафема. Просто люди, которые занимаются тобой. Только тобой. И решают всё остальное.
Этот переход между мутным IT и понятным IT — он происходит на берегу бизнеса. Команда защищена с двух сторон. При попытке уволить — рейтинг составляется, она очень быстро выходит в лучшие. И второе: бизнес будет биться за неё так же, как бьётся за свой финрез. Потому что наступает счастье.
Ведущий: Для какой организации такая схема не подойдёт?
Сергей: Мир не состоит из этих команд. Но в каждом бизнесе они есть, несмотря ни на что. У меня был инженер, он говорил: «В каждом банке есть четыре человека, которые понимают, что, как и где работает. Главное их найти».
Окунись в свой конвейер [46:45]
Ведущий (Анатолий): Время подкаста подходит к концу. Отличная подводка к тому, чтобы поговорить про то, как это на практике работало в «Открытии», — конкретные примеры разберём во втором выпуске. Кто с каким инсайтом уходит?
Ведущий (Алексей): Подход, про который рассказывает Сергей, сам в себе содержит разгадку. Когда построена такая команда — переводчик не нужен. Она является частью бизнеса, или бизнес является частью IT-команды. Они неразрывно существуют. Нет барьеров для разговора.
Ведущий (Александр): Очень правильно Сергей сказал про конвейер. Точное попадание в описание того, что происходит в айтишных средах. Почему люди выгорают? Потому что оказываются на конвейере. А на самых сложных и на самых простых задачах всегда конвейер. Ты сидишь как в бункере, сверху сыпется. Никакого развития. Человек выгорает.
Ведущий (Анатолий): Конкретная идея: на конвейере нельзя быть счастливым. Любой стейкхолдер мечтает оказаться в команде, где созидают — и этим можно пользоваться. И вторая мысль — «бегать от тигра». Ваша стратегия выживания — не стать худшей командой. Не перебежать тигра — бежать быстрее геолога.
Сергей: Коллеги, я от вас в восторге. Нравится, что вы всё время возвращаетесь к бизнесу. Где проблемы? Основная проблема — бизнес убивает эти команды. Всё пытается превратить в конвейер.
Ведущий: Пытается стандартизировать и убить курицу, которая несёт золотые яйца.
Сергей: Абсолютно. Парадокс — давайте пробросим мостик. Айтишники должны понять: мы строим конвейер для других. Когда поймём, что сами этого не хотим, — это более творческая работа, чем строить конвейер для других. А идея OpsDev: сам окунись в работу своего конвейера. Тогда он будет максимально эффективным. Творческую часть тоже надо осмыслить.
Такой подход позволяет не усложнять жизнь людям, а упрощать её. Мы делаем такие сложные конвейеры, в которых потом сами мучаются. Надо проще, проще, проще. А как это почувствуем? Только если мы сами — ops. Если часть нашей команды страдает от того, что мы написали. Нет второй линии поддержки. Мы первая и окончательная линия поддержки того, что написали.
Ведущий (Анатолий): Окунись в свой собственный конвейер, который ты создаёшь. Забавно, да.
Ведущий: Ребята, коллеги — вам это тоже на подумать. Мы пошли осмыслить. Спасибо большое, Серёга. Коллеги, спасибо, что нас слушали. Окунитесь в свой конвейер. Хорошего взаимодействия. Пока-пока.
Сергей: Спасибо. До встречи, пока-пока.