Как устроен IT-департамент: структура и роли

IT-департамент строится не по должностям, а по функциям, и в зрелой компании их девять: руководство (CIO и CTO), разработка, инфраструктура и DevOps, контроль качества (QA), информационная безопасность, продукт, управление проектами (PMO), работа с данными и архитектура. Каждая функция отвечает за свой контур: разработка создаёт продукт, инфраструктура держит его в проде, QA охраняет качество, ИБ — безопасность, продукт определяет, что вообще делать. В небольшой компании несколько функций совмещает один человек, а с ростом каждая выделяется в отдельное направление со своим руководителем. Понимание этой карты помогает увидеть, какие зоны у вас закрыты людьми, а какие держатся на одном энтузиасте или не закрыты вовсе.

CIO (Chief Information Officer) и CTO (Chief Technology Officer) — это два разных лидера IT, которых часто путают. CIO отвечает за внутренние информационные системы компании: ERP, корпоративный софт, инфраструктуру, IT-сервис для сотрудников и автоматизацию бизнес-процессов. Его клиент — внутренний бизнес. CTO отвечает за технологию продукта, который компания продаёт наружу: архитектуру, разработку, технологический стек и инженерную стратегию. Его клиент — внешний рынок. В продуктовой IT-компании ключевая фигура — CTO, а CIO может вообще отсутствовать. В крупном небанковском бизнесе, где IT обслуживает операции, наоборот, центральная роль у CIO. В части компаний обе роли совмещает один технический директор, и важно заранее понимать, какой именно фокус вам нужен.

Структура IT растёт вместе с компанией и проходит понятные стадии. На старте всё закрывают двое-трое инженеров: один человек одновременно пишет код, выкатывает релизы и чинит сервер. На стадии роста выделяется руководитель разработки и появляются тимлиды, отдельно вырастает DevOps и QA, потому что ручной выкаткой и тестированием уже не обойтись. Когда продукт становится сложным, обособляются продукт (CPO или Head of Product), управление проектами (PMO) и архитектура — кто-то должен держать целостность системы. На зрелой стадии добавляются информационная безопасность как отдельная функция и работа с данными (Head of Data), а над всем выстраивается слой руководства из CIO и/или CTO. Главная ошибка — копировать структуру корпорации на стадии, где она избыточна, или, наоборот, годами держать критичные функции на одном человеке.

Зоны ответственности удобно держать в голове как таблицу «функция — руководитель — за что отвечает». Руководство (CIO, CTO) отвечает за технологическую стратегию и связь IT с бизнесом. Разработка (руководитель разработки, тимлиды) — за создание и развитие продукта в срок и в нужном качестве. Инфраструктура и DevOps — за то, чтобы система стабильно работала в продакшене и релизы выкатывались быстро и безопасно. QA — за качество и предсказуемость релизов. Информационная безопасность — за защиту данных и устойчивость к атакам. Продукт (CPO, Head of Product) — за то, что именно мы строим и зачем. PMO и менеджеры проектов — за сроки, ресурсы и координацию. Head of Data — за данные как актив и аналитику. Архитектура — за целостность и масштабируемость технических решений. Когда зоны размыты, появляются провалы на стыках, за которые формально не отвечает никто.

Это зависит от стадии и рисков, но недооценивают эту функцию чаще, чем переоценивают. Пока компания маленькая, безопасностью по остаточному принципу занимается DevOps или системный администратор, и какое-то время этого хватает. Но как только вы обрабатываете персональные данные клиентов, проходите аудиты, работаете с финансами или становитесь заметной мишенью, безопасность нужно выделять в отдельную функцию с собственным руководителем, который не подчинён разработке. Причина проста: если ИБ подчинена тем, чью работу она должна проверять, она всегда проигрывает в приоритетах скорости релизов. Отдельный руководитель информационной безопасности нужен тогда, когда цена утечки или простоя для вас уже выше, чем стоимость самой роли, и тянуть с этим решением до первого инцидента — дорого.

Первым нанимают не специалиста, а того, кто закроет самую дорогую для вас зону риска и сможет дальше выстроить команду сам. Чаще всего это сильный технический лидер — руководитель разработки или технический директор, который на старте и пишет код, и принимает архитектурные решения, и нанимает первых инженеров под себя. Если у вас уже есть продукт, но он разваливается под нагрузкой, в приоритете архитектура и DevOps. Если продукт ещё не определён и команда бьётся не над тем, первым нужен человек на стороне продукта. Ошибка — нанимать узких исполнителей раньше, чем появился тот, кто умеет ставить им задачи и отвечать за результат. Если внутри сложно понять, какая роль закроет ваш риск первой, разумно опереться на тех, кто подбирает IT-руководителей ежедневно и видел десятки таких развилок.