Модель управления IT в одной продуктовой компании

Если ты стал руководителем в IT, то у тебя большие проблемы – достаточно сложно найти описанные модели организации производства и набора KPI's для CTO и CIO. Задача любого управленца любой отрасли – следить за конкурентами, «state of the art»- примерами и приносить лучшие практики в свою компанию. По своему опыту скажу, что тебе придется завести круг общения и делиться с другими СТО примерами в барах, на встречах, референс-визитах, конференциях.



На Хабре контента про модели управления и метрики мне найти не удалось, а его реально не хватает, поэтому решил поделиться своим опытом.

Давайте начнем с ответа на вопрос, за что в нашей компании отвечает СТО:

1. Команда. СТО отвечает за подбор и удержание крепкой команды инженеров, а также за их вовлеченность.
2. Архитектура.IT-ландшафт должен быть гибким, современным, а состояние продакшена должно быть прозрачным для всех.
3. Надежность. Всем понятно, что IT-ландшафт должен быть не только самым модным и молодежным, но и не падать.
4. Бюджет. В IT-компании расходы на IT – основная статья, поэтому не только финансовый директор, но еще и вы должны работать с этими расходами, а также смотреть за рыночными бэнчмарками.
5. Кибербезопасность. Вы тоже отвечаете за кибербезопасность. Не важно, есть у вас CISO или нет (спойлер – у нас есть). В конце концов вашими самыми прямыми руками делается все хорошее и плохое в IT-ландшафте этой компании.

Теперь давайте посмотрим метрики, которые помогут увидеть картину своей ответственности. Где-то метрики производные, т.к. измерить напрямую не получится.

1. Команда

Метрики

• укомплектованность функций IT. Зачем? Ответ — из-за низкой укомплектованности следует невозможность выполнения запланированных задач. Приоритет найма выставляется строго по показателю укомплектованности. Чем ниже укомплектованность функции, тем выше приоритет твоей вакансии для HR. Все просто.
• «текучесть» в разрезе функций. Зачем? Высокая/растущая текучка кадров означает, что у вас плохой климат в команде, проблемы с процессами или с заработной платой. Кластеризовать проблемы помогут exit — интервью с сотрудниками.
• процент сотрудников, приходящих по рекомендациям от текущих сотрудников (показатель реферальности). Растущий процент говорит о том, что вашим инженерам нравится у вас работать, они готовы рекомендовать вашу компанию своим близким людям и просто знакомым.

2. Архитектура

Здесь пока поле для экспериментов. Но все же:

Мои метрики

• Архитектурные отклонения. Что это? Архитектурное отклонение — это вы нашли на продакшене реализацию, не соответствующую утвержденному архитектурному стандарту. Зачем? IT ландшафт — огромная взаимосвязанная система, которая должна работать по правилам. Если не соблюдать правила, системы просто не будет.
• Метрики PageSpeed Insights в разрезе веб-приложений. Метрика релевантна для фронт-энда конечно же. Зачем? Забота о ваших пользователях. Низкие показатели – у вас тормозной сайт, плохо работающий на мобиле, вы на дне выдачи Google и конечно у вас очень плохо с экспертизой фронт-энда.

3. Надежность

Метрики

• Доступность в разрезе веб-приложений и сервисов. Без комментариев
• TOP виновников инцидентов за период. Зачем? где вам пора подключаться, как СТО и разбираться с архитектурой и процессами.
• TOP пострадавших сервисов за период.Зачем? опытный инженер проектирует систему так, чтобы минимально зависеть от внешних зависимостей. Если «пострадавший» часто попадает в вашу отчётность, вам пора и здесь разбираться с архитектурой и процессами.
• Crash-free вашего приложения на мобильных платформах. Без комментариев

4. Бюджет

Метрики

• Какой процент бюджета IT – это расходы на дата — центр, на разработку систем, сколько вы тратите на их сопровождение. Зачем? Есть уважаемые компании, как Gartner, которые ежегодно выпускают бэнчмарки расходов IT в разрезе статей. Полезный трафарет. Например, если ты на сопровождение тратишь больше, чем среднее значение твоих коллег по цеху, возможно, у тебя проблемы с архитектурой и релизным процессом. Если ты на хостинг тратишь больше своих коллег, то либо у тебя утилизация низкая, либо явно покупаешь overpriced оборудование и виртуализацию.
• TOP статей расходов в раскладке по драйверам. Зачем? Это твоя работа по оптимизации. Здесь, скорее всего, есть жир, который можно срезать и пустить на крутые штуки.
• -% исполнения бюджета. Без комментариев

5. Кибербезопасность

Метрики

• Найденные уязвимости в разрезе функций/команд. Зачем? Если тренд по уязвимостям восходящий, вам пора подключаться, как СТО и разбираться с архитектурой и процессами.
• Невыполнение SLA на закрытие уязвимостей.Зачем? Соблюдение дисциплины, помните я выше писал, что IT ландшафт — большая взаимосвязанная система, которая должна работать по правилам...

У читателя может возникнуть вопрос «А как же такие важные метрики, как тайм ту маркет, количество автоматических деплоев vs количество ручных, что-нибудь про плотность пулл-реквестов?» Ответ – да, когда-то на них смотрели, сейчас они для нас не актуальны. Это нормально для метрик, у каждой есть свой жизненный цикл.

Теперь перейдем к функциям в IT в DomClick. Я не буду цитировать классиков с их «разработка, внедрение, сопровождение, эксплуатация» – буду описывать функции на другом уровне абстракции:

1. Продуктовая разработка. Команды, создающие продукты, за счет продажи которых компания получает основной доход. Здесь смешанные команды бизнес и IT. Есть РО и CJE, которые отвечают на вопрос «что делать» и «в каком приоритете», инженеры отвечают на вопрос «как делать».
2. Разработка платформенных сервисов (Сore). Команды, создающие «фундаментальные» сервисы. Те сервисы, которыми или пользуются все в компании, например сервисы авторизации и аутентификации, API Gateway, файловое хранилище, продуктовый биллинг и т.д.
3. Внутренняя разработка. Команда, создающая системы для работы самой компании – корпоративный портал, система для бухгалтерии и финансов, автоматизация всех внутренних процессов в компании.
4. Веб-стандарты (Web Core) Команда, которая определяет стандарты web-фронта во всей компании, ведет разработку общей библиотеки UI-компонентов, подключается к решению сложных и пограничных фронтовых задач.
5. Мобильная платформа. Мобильная разработка всегда стоит особняком из-за особенностей мобильных платформ: начиная от разработки, заканчивая другим процессом тестирования и выкатки релизов в прод. У нас есть свой «фреймворк» работы мобильной разработки, о котором, думаю, напишем в отдельной статье. Спойлер — большая часть наших мобильных разработчиков трудится в командах Продуктовой разработки бок о бок с фронтами и бэками.
6. Развитие и сопровождение инфраструктуры. Команда, которая целиком и полностью отвечает за сеть, железо, ОС, виртуалки, k8s, базы данных.
7. Платформа DevOps. Для компаний среднего размера этот вопрос уже важен и требует создания отдельной функции. У нас выделенная команда занимается созданием лучшего пайплайна с канарейками и прочими полезными плюшками.
8. Архитектура. Функция, которая готовит представление IT ландшафта на самом верхнем уровне. Очень важна, когда у бизнеса есть только идея и пока не понятно, в какие команды отдавать реализацию или потребуется создание отдельной команды.
9. R&D. Команда решает задачи, технология применения которых пока непонятна. Какие-нибудь проекты с VR/AR, которым точно найдется место в недвижимости, но пока нет ни консьюмерской технологии и непонятен бизнес-эффект.
10. Конкурентная разведка. Функция, которая собирает информацию об устройстве IT-коллег по цеху. Всегда интересно знать, каким ресурсом (стек, команда, модель управления) другие компании решают похожие задачи. Конечно, только твои божественные руки пишут самый лучший код, но это не так, твои коллеги тоже кое-что понимают в IT и у них надо учиться.
11. Управление IT контрактами. (не путать с закупкой). Эта функция отвечает за оптимизацию контрактов и улучшений условий контрактов со всеми IT — вендорами. Это прежде всего переговорщики.
12. Data Science. В современном IT у вас должна быть команда DS с как минимум компетенциями RecSys и ML. OCR и NLP – по потребностям, скорее всего, вы просто купите продукты какого-нибудь вендора. У нас есть весь набор компетенций, включая OCR. Сервисы распознавания документов и классификации изображений разработаны внутри DomClick.
13. Работа с данными. Основная задача функции, чтобы данные в компании были легкодоступными. Отсюда вытекают задачи по стандартизации моделей данных разных сервисов, мониторингу наличия данных, их полноты и актуальности.
14. Интеграционная команда. Команда отвечает за координацию интеграций с внешними сервисами, где много коммуникаций, участвует несколько команд, где появляются контракты или жесткие дедлайны и scrum уже не помогает

Компоновка функций в DomClick выглядит вот так:



На досуге рекомендую почитать статью нашего руководителя разработки внутренних и core — сервисов, а также статью инженера из подразделения Развитие и сопровождение инфраструктуры. Будет немного понятно, чем ребята занимаются.

Функция – это не обязательно большая команда людей. Какие-то функции могут состоять из одного человека, но они должны быть, кто-то эту задачу должен решать. Возможно, на первых порах, вы сами.

Компоновку этих функции оставляю на ваше усмотрение, т.к она зависит от компетентности ваших сотрудников. Дам только два совета из личной практики:

1. Функция Развитие и сопровождение инфраструктуры обязательно должна быть равноудалена от остальных функций. Это значит, что она всегда должна быть независимой. В компании не должно быть конфликтов и вопросов, что у кого-то лимитов в k8s больше, кому-то админа дали более профессионального, а кто-то железо и виртуалки всегда получает первый.
2. Если ваш бизнес большой и у вас несколько команд Продуктовой разработки, то нельзя совмещать одну из продуктовых команд с командой Разработки платформенных сервисов. Причина простая – весь бэклог сore будет забит пожеланиями конкретной продуктовой команды, а не потребностями всей компании. И самое плохое, еще и реализация будет заточена под стек этой команды.

У нас есть интересные отличительные особенности, которые значительно упрощают работу и нивелируют конфликты по вопросу приоритетов. Вы же помните, что IT, кроме создания и продажи продуктов, также необходимо переходить на новые версии API-смежников, проводить рефакторинг, устранять уязвимости, разбирать корневые проблемы:

1. Каждая команда выделяет 20% своего времени на инженерную квоту. В эту квоту мы стараемся решать все вышеописанные задачи и заниматься исследованиями, если остается время. Важно: в 20% НЕ входят баги и блокеры по кибербезопасности, они устраняются за счет продуктовой квоты.
2. У крупных направлений продуктовой разработки (несколько agile-команд работают над одним продуктом) есть своя небольшая платформенная команда, которая в целом следит, чтобы «кафтан не разъехался» и решает только инженерные задачи данного продукта.

В заключение

1. Модель управления первична – она сильнее, чем культура компании.
2. Любая система стремится к равновесию, поэтому в изменениях будьте настойчивы.
3. Каждый год пересматривайте свою модель управления. Как пример, функция Управление IT контрактами появилась у нас в 2020 году, а Веб-стандарты (Web Core), R&D,Конкурентная разведка — в 2019.