Что делать, если IT уперся не в технологии, а в управляемость системы? Делимся опытом IT-трансформации
Привет! Я Виталий Головин, IT-директор в А ДЕНЬГИ. За три года работы наше IT-направление трансформировалось несколько раз. Мы прошли путь от небольшой команды разработчиков на аутсорсе до масштабной IT-структуры из 18 команд, в которых трудятся 150+ разработчиков. В статье расскажу, как мы трансформировались, за счет чего сохраняем управляемость и эффективность при быстром росте.
Сначала мы нанимали людей
А ДЕНЬГИ запустилась в 2022 году. Сначала работали узкой командой разработчиков на аутсорсе, потом формировали собственные команды разработки. В среднем в командах у нас семь-восемь человек: тестировщики, разработчики, аналитик, менеджер.
Несмотря на быстрый рост на старте, и по объему и по продуктовой части, до какого-то момента мы справлялись. Когда возникало ощущение, что рук не хватает — нанимали новых людей, формировали дополнительные команды. Но такой подход в какой-то момент перестал нас спасать.
На IT-подразделение было несколько точек давления. Одна из них — это рост клиентской базы. В первый месяц после запуска мы выдали 10 тысяч займов, а спустя год в базе было уже больше 250 тыс. клиентов. Это рост нагрузок на скоринг и на другие системы. Чтобы справиться с нагрузками, мы использовали технологические решения, например, перешли на собственные сервера с облачных.
Вторая точка давления — скорость доставки кода. Нам нужно было докручивать функционал, выкатывать новые фичи. Чаще всего в довольно сжатые сроки. У бизнеса была потребность делать больше и быстрее, и мы не всегда за ним успевали. Один из факторов, который мешал скорости — процесс релиза был слишком долгим и трудоемким. Мы выкатывали наше обновление на прод по два-три часа. Казалось бы, небольшая фича, а занимает в разработке недели, а потом еще полдня выкатываем. Все понимали, что так быть не должно.
Деплой 2.0 или первая трансформация
Мы собрали все проблемы, с которыми сталкивались при деплое, вооружились концепцией DORA-метрик и начали строить процессы и алгоритмы.
Принципы простые:
Релиз должен быть легким и простым. Для этого мы автоматизировали все ручные процессы и исключили «тормозящие» этапы в цепочке от коммита до продакшена. А сами обновления стали дробить на более мелкие инкременты и выкатывать чаще.
Быстро поднятое упавшим не считается. Сбои при выкатке случаются, и это нормально. Мы перестали придавать им значение, если успевали быстро восстановить систему. Это помогло команде привыкнуть к частым выкатам, выявить узкие места в пайплайне и метриках реального времени.
Если тест на проде, то на малой части (канареечные релизы). Мы никогда не выкатываем новую фичу/изменение на всех пользователей сразу. Сначала тестируем на небольшой группе, чтобы поймать баги в бою без массового коллапса.
Мы добились снижения релизного процесса с трех часов до тридцати минут. Кроме того, релиз перестал быть настолько рискованной процедурой, какой он был раньше, за счет внедрения канареечного релиза, тотального мониторинга и регламентирования процессов выкатки.
Изменения, которые мы внесли в рамках трансформации «Деплой 2.0», оказались эффективными, но их хватило только на год. Бизнес не стоял на месте, и перед нами возникли новые вызовы: выкатываем мы быстро, но так ли быстро производим?
Flow Framework или вторая трансформация
Даже при быстрых деплоях мы начали упираться в другое: задачи долго висели в бэклоге, фокус команд размывался, а локальные улучшения не всегда приводили к ускорению результата для бизнеса.
Каждая команда могла работать эффективно сама по себе, но суммарная скорость вывода ценности снижалась. Значит, нужно было смотреть не на отдельные процессы, а на работу всего IT как единого потока создания ценности. Ведь давно известно, что чем больше у тебя команд, тем больше проблем в межкомандном взаимодействии.
Так мы пришли к концепции Flow Framework. В отличие от первой трансформации, эта затронула весь IT целиком — от постановки задач до получения результата в продакшене.
В основе второй трансформации мы заложили несколько принципов:
Фокус на time-to-market. Ключевой метрикой для нас стало время от появления идеи до ее попадания к пользователю. Не скорость работы отдельного разработчика или команды, а именно время доставки ценности конечному клиенту.
Глобальная эффективность вместо локальной оптимизации. Мы перестали оптимизировать отдельные участки системы в отрыве от общего потока. Быстрая работа одной команды не имеет значения, если на следующем этапе задача застревает. Важна эффективность всей цепочки целиком.
«Начнем завершать и закончим начинать». Мы сознательно сократили количество параллельных задач в работе. Фокус сместился с постоянного старта новых инициатив на завершение уже начатых. Это снизило перегруз, упростило приоритизацию и сделало поток более предсказуемым.
Малый квант работы. Раньше задача могла длиться несколько дней и даже недель, и это считалось нормальным. Но с изменением подхода мы сделали все задачи не более одного-трех дней в разработке. Это сильно повышает управляемость и предсказуемость процесса.
Контроль «возраста задач». Когда мы говорим о времени доставки, важно не только, насколько быстро задачу взяли в работу, важно, когда ее завершили. А тут возникали моменты, когда сложные задачи зависали в паузе или между процессами, и на них особо никто не обращал внимания с позиции: «Сложно… Ну, не так оно и надо», включая заказчика. Для борьбы с этими зависшими задачами мы расширили инструментарий, метрики и точки контроля. Сейчас мы четко можем сказать, что все задачи на нашей доске актуальны.
По сути, Flow Framework стал для нас инструментом, который позволяет смотреть на работу IT как на единый поток работы. Он помогает каждому разработчику и каждой команде понимать, как их работа влияет на общий результат, где возникают узкие места и что именно тормозит поток.
Как реагировала команда на изменения
Масштабные изменения в процессах могут вызывать сопротивление — и наши трансформации не стали исключением.
С явным сопротивлением работать всегда проще. Чаще всего это была конструктивная критика или недопонимание: вопросы к новым принципам, сомнения в их необходимости, попытки разобраться, как изменения повлияют на конкретную команду. В таких случаях мы подробно объясняли, зачем запускаем трансформацию, какие проблемы она решает и какие выгоды дает в перспективе.
Сложнее было с неявным сопротивлением. В отдельных командах сохранялись привычные способы работы или формальное следование изменениям. И тут важно не идти по пути давления. Вместо этого мы делали ставку на прозрачность и диалог. Перед внедрением изменений проводили презентации, обсуждали логику решений, отвечали на вопросы. Уже в процессе трансформации регулярно возвращались к обсуждениям и корректировали подход, если видели недопонимание.
Были случаи, когда я подключался лично: приглашал тимлида, и мы вместе разбирали, что именно не работает, почему команда отклоняется от договоренностей и чем могу помочь. До необходимости «продавить» решение, дело не доходило.
Что в итоге
Первая трансформация дала нам управляемый и предсказуемый процесс доставки кода. Мы сократили время релизов, снизили риски при выкатке и убрали из процесса лишнее напряжение. Это позволило командам быстрее проверять гипотезы и увереннее реагировать на запросы бизнеса.
Подводить итоги второй трансформации пока рано, но можно сказать, что IT в целом стал прозрачнее: стало понятно, как задачи движутся по системе, где они застревают и что именно влияет на скорость результата. У руководителей появился единый язык общения и общее понимание того, на какие показатели стоит смотреть в первую очередь и почему. Это упростило управление командами и позволило сместить фокус с локальных действий на работу всего потока целиком.
На текущем этапе развития компании мы чувствуем устойчивость. Процессы работают предсказуемо, структура остается управляемой, а у команды есть задел для реализации новых, более амбициозных инициатив.
Мы не стоим на месте, и я уверен, что еще не раз будем пересматривать подходы и адаптировать систему под новые условия.