6 ошибок при найме vCIO в России 2026 глазами того, кого нанимают

Зачем эта запись

Я много лет вёл ИТ как штатный руководитель в производственно-торговой компании, а теперь беру vCIO-проекты. Сторону заказчика знаю изнутри. Сторону исполнителя веду сам. Из этой двойной позиции описываю шесть ошибок, которые владельцы повторяют при найме внешнего ИТ-директора.

У каждой ошибки есть цена. Потерянные месяцы, сорванный бюджет, скрытый конфликт между владельцем и консультантом, который всплывает через полгода. Дальше по каждой ошибке разбираю, как она выглядит на первом разговоре и какую формулировку я даю или прошу, чтобы её закрыть.

Ошибка 1. Нанимать vCIO без NDA до первого разговора

Почему без NDA разговор бесполезен

Содержательный вводный разговор идёт 30–60 минут. Владелец рассказывает про реальные проблемы. Кто из инженеров держит критичный участок, какие конфликты в команде, какие подрядчики разочаровали, где лежат скелеты по 152-ФЗ. Без NDA владелец либо рассказывает поверхностно, либо рискует. Оба варианта плохие.

Моё правило по срокам

Я подписываю NDA в течение часа после первого письма. Свой шаблон держу наготове, шаблон владельца принимаю с небольшими правками. Когда со стороны кандидата на роль vCIO процедура NDA тянется неделю и дольше, это сигнал плохой организации или страха обязательств. Я такого консультанта на месте владельца отсеял бы на первом этапе.

Юридический каркас в 2026-м

NDA в России в 2026-м обычно опирают на режим коммерческой тайны по ФЗ-98 «О коммерческой тайне» (с опорой на ст. 1465–1472 ГК РФ о секрете производства и ноу-хау). Если в обмен попадают персональные данные, на этот случай оформляют отдельный документ — поручение на обработку ПДн по ч. 3 ст. 6 152-ФЗ, его в NDA не смешивают. У меня шаблон NDA на одну страницу с корректными отсылками. Готов прислать любому владельцу до первого разговора.

Ошибка 2. Просить «портфолио проектов» в публичном виде

Что не так с публичным портфолио

Когда мне говорят «пришлите портфолио клиентов с цифрами и логотипами», я слышу две вещи. Либо владелец привык к модели веб-агентств, где портфолио действительно публикуется. Либо у владельца нет своего опыта найма консультанта в зоне, где NDA работает по умолчанию.

Что означает полное публичное портфолио у CIO

Опытный ИТ-директор работает под NDA. На корпоративном уровне клиенты подписывают соглашение о неразглашении до начала работ, и это норма отрасли. Полное портфолио в публичном виде означает одно из трёх. Нарушение NDA с прошлыми клиентами. Мелкий опыт, где NDA не подписывали. Подделанные кейсы. Ни один вариант не помогает владельцу принять решение.

Чем я заменяю публичное портфолио

На первом разговоре я предлагаю взамен несколько вещей. Сначала обезличенные кейсы с конкретными цифрами и без названий компаний. Дальше реальный контакт для рекомендации, заранее согласованный с прошлым клиентом, — он подтвердит факт работы и базовые параметры. И разбор гипотезы по схеме «вот ваша задача, вот что я делал в похожей ситуации, вот результат». Это даёт больше понимания, чем двадцать публичных кейсов с логотипами.

Ошибка 3. Платить за процесс, а не за результат

Почему почасовая оплата без результата не работает

Почасовая оплата без описанного результата почти всегда ведёт к расползанию объёма. Владелец платит за часы, консультант выставляет часы, никто не сравнивает их с конкретным итогом. Через три месяца владелец видит сумму с шестью нулями и не может назвать, что именно изменилось. Это типичная картина, когда я прихожу на проект после предыдущего консультанта.

Моя модель — абонентское сопровождение плюс проекты с ценой

Я разделяю оплату на две части. Ежемесячное абонентское сопровождение (retainer) на фиксированную сумму с понятным составом работ. Плюс отдельные проекты с фиксированной ценой и описанным результатом. Сопровождение покупает регулярную ритмику работы. Созвон раз в неделю, отчёт раз в месяц, точечные консультации в рабочее время. Проектная часть покупает конкретный результат с датой сдачи и критериями приёмки.

Типовая структура контракта

В моих контрактах vCIO структура обычно такая. Абонентское сопровождение покупает порядка 8–10 часов в неделю — созвон, отчёт, точечные консультации. Отдельно идёт проектная часть. Например, аудит ИТ-зрелости за четыре недели по фиксированной цене, где в Постановке прописан результат — карта зрелости, бюджет, дорожная карта, шаблон отчёта. Дальше ежемесячная поддержка идёт по абонентскому договору, новые задачи берутся отдельными контрактами с фиксированной ценой. Конкретные суммы зависят от масштаба бизнеса и темпа работы.

Ошибка 4. Не согласовывать формат ежемесячного отчёта на старте

Симптом — «А где посмотреть, что сделано в этом месяце?»

Через три месяца после старта владелец смотрит на присланный отчёт и спрашивает: «А где мне посмотреть, что сделано за месяц?» Это значит, что формат отчёта не согласовали на старте. Документ собран в формате, удобном исполнителю, а владельцу непонятно, какие решения он должен принять, читая его.

Мой шаблон — одна страница A4, четыре блока

Я договариваюсь о формате на стадии подписания контракта. Один лист A4, четыре блока. Что сделано за месяц (3–5 пунктов с результатом). Ключевые метрики — доступность, среднее время восстановления, доля повторных инцидентов P1, бюджет к плану. Риски и инциденты P1. План на следующий месяц с конкретными результатами. На второй странице, если нужно, лежит приложение с подробностями.

Почему отчёт держу коротким

Сжатый отчёт владелец читает целиком. Перегруженный бросает на второй странице, и риски остаются непрочитанными. Поэтому я держу формат одна A4 плюс приложение и не утапливаю главное в разборе каждого мелкого тикета. Документ нужен не для отчётности ради отчётности, а чтобы владелец принял три-четыре решения за десять минут чтения.

Ошибка 5. Подписывать сопровождение без точки контроля

Зачем нужны две разные защиты для владельца

В долгосрочном контракте vCIO я закладываю два разных механизма, и владельцу важно их не путать. Первый — постоянный двусторонний выход с уведомлением за 30 дней. Он работает в любой момент. Если сотрудничество перестало приносить ценность, любая сторона предупреждает за месяц и расходится без штрафа. Второй — обязательный плановый пересмотр на 90-м дне. Это запланированная в договоре точка, где мы намеренно останавливаемся и оцениваем результат.

Что происходит на 90-м дне

На плановом пересмотре я как vCIO показываю, что сделано и что не сделано. Владелец говорит, устраивает ли его темп и формат работы. По итогам три исхода. Продолжаем по тем же условиям. Меняем формат, например темп сопровождения или состав работ. Расходимся без обид. Без этой точки владелец рискует оказаться заложником. Платит, не понимая отдачи, а поднимать разговор о разрыве самому затратно по нервам. Плановый пересмотр снимает с него эту неловкость, потому что разговор уже прописан в договоре.

Когда выход срабатывает раньше планового пересмотра

Бывает, что сопровождение нужно прекращать до 90-го дня, и тогда работает 30-дневный выход. Самый частый случай — владелец не выделяет даже обещанные полчаса в месяц на отчёт. Созвоны переносятся подряд, решения откладываются, регламенты лежат без подписи. Если владелец не вовлекается, ежемесячное сопровождение не работает в принципе. vCIO без читающего владельца теряет мандат. На этот случай я честно поднимаю выход, возвращаю неотработанную часть оплаты и рекомендую коллегу, готового работать в режиме «приехал, сделал, уехал». Такому бизнесу подходит проектный формат, а не постоянное стратегическое сопровождение.

Ошибка 6. Не проверять живую практику

Чем опасен vCIO без рук

vCIO, который не может объяснить устройство 1С на уровне инженера или нарисовать на салфетке архитектуру корпоративной сети с тремя VLAN, — поверхностный консультант. Он способен переписать главу из учебника и написать рекомендации общими формулировками. На уровне реальных решений в инциденте такой консультант беспомощен.

Три вопроса, которые я задаю на первом разговоре

На вводном разговоре у меня есть три практических вопроса. Я задаю их и жду конкретных ответов от кандидата на роль vCIO.

1. 1С. Что такое транзакционная блокировка в 1С и как её диагностировать?
2. Сеть. Зачем нужен VLAN, зачем VPN, на каком уровне OSI работает каждый и почему это не взаимозаменяемые вещи? Толковый ответ звучит так. VLAN — это сегментация сети на канальном уровне (L2, 802.1Q), а VPN — шифрованный туннель через недоверенную среду, который не привязан к одному уровню (бывает L2, чаще L3 на IPsec, бывает L4–L7 на SSL/TLS). Это разные классы технологий с разным назначением.
3. DNS / почта. Что произойдёт, если у домена убрать MX-запись и оставить только A-запись? Толковый ответ такой. По RFC 5321 сработает неявный MX (implicit MX, приоритет 0), отправляющий сервер попробует доставить почту на A-запись, и формально она пойдёт. Это плохая практика. Часть почтовых серверов неявный MX не делают и сразу вернут отказ, нет приоритезации и резерва, ломается выделенный почтовый узел.

На каждый вопрос инженер отвечает за 1–2 минуты по существу. Поверхностный кандидат отвечает общо или переводит разговор на методологию. Сильного инженера такие вопросы не отсеивают, потому что правильный ответ как раз и звучит «это объекты разных слоёв и назначений».

Зачем живая практика именно vCIO

Я не противопоставляю vCIO инженеру. vCIO ведёт стратегию, бюджет, отчётность, выбор подрядчиков. Руки нужны ему не для того, чтобы чинить сервер 1С в 2 часа ночи (это работа инженера), а чтобы внятно спорить с подрядчиком и понимать, что чинит инженер. Без живой практики vCIO превращается в бюрократа.

Знак, по которому я сам отказываюсь

Главная причина моих отказов

Есть один сигнал, по которому я отказываюсь от проекта на старте, даже когда коммерчески всё выглядит выгодным. Владелец не готов слышать неудобные выводы аудита. Это самая частая причина моих отказов на вводном разговоре.

Как это звучит на первом разговоре

Формулировки узнаваемые. «У нас в целом всё хорошо с ИТ, нужны мелкие улучшения». «У нас сильная команда, руководитель ИТ работает восемь лет, мы им довольны». «Все процессы выстроены, осталось их формализовать». «Нам нужно, чтобы консультант провёл аудит и подтвердил, что мы движемся правильно».

За такими формулировками часто стоят нерешённые системные проблемы, которые владелец либо не видит, либо не готов признать. После аудита я приду с выводами вроде «команду надо усиливать», «процессов нет, всё держится на знаниях в головах», «бюджет ИТ нерационален в нескольких статьях». Владелец, который ждал одобрения, отвергает выводы и расторгает контракт или сопротивляется рекомендациям. В итоге теряет и деньги, и время.

Карта формулировок и моих решений

Один прямой вопрос на проверку готовности

На вводном разговоре я задаю один прямой вопрос. «Если по результатам аудита я скажу, что нужно менять руководителя ИТ, вы готовы это услышать?» Когда в ответ звучит «да, мы готовы» с паузой и осмыслением, я работаю. Когда «нет, у нас сильная команда» без паузы, я отказываюсь и рекомендую коллегу, который специализируется на формальных аудитах для регулятора без жёстких выводов.

Чек-лист из 10 вопросов на первом разговоре

Как пользоваться чек-листом

Этот чек-лист я бы дал владельцу, который выбирает vCIO, чтобы защитить его от шести ошибок выше. Вопросы от владельца к кандидату. Ответы конкретные, не общими словами.

Десять вопросов кандидату на роль vCIO

1. NDA. Готовы ли вы подписать NDA до первого содержательного разговора? В какие сроки и по какому шаблону, вашему или нашему?
2. Опыт под NDA. Обезличенные кейсы с цифрами без названий компаний. Реальный контакт для рекомендации, которому мы можем позвонить.
3. Модель оплаты. Покажите типовой контракт. Что входит в абонентское сопровождение, что идёт отдельным проектом, фиксированная ли цена у проекта.
4. Формат отчёта. Покажите шаблон ежемесячного отчёта. Сколько страниц, какие блоки, какие метрики.
5. Точка контроля. Условия выхода из контракта без штрафа и срок уведомления. Есть ли плановый пересмотр и на какой день он назначен.
6. Живая проверка. Три технических вопроса под ваш стек. По 1С — что такое транзакционная блокировка и как её диагностировать. По сети — зачем нужен VLAN, зачем VPN и на каком уровне OSI работает каждый. По почте — что произойдёт без MX-записи у домена и как поведёт себя неявный MX.
7. Готовность к неудобным выводам. Прямой вопрос кандидату. «Что вы сделаете, если по результатам аудита нужно будет менять руководителя ИТ?»
8. Зона компетенций. В каких отраслях работали, в каких не работали. Где себя считаете сильным, где слабым.
9. Сертификация. Какие сертификации, в каком году получены. Какое продолженное обучение в последние 12 месяцев.
10. Доступность. Сколько часов в неделю планируете на наш контракт. Сколько других клиентов одновременно ведёте. Кто закроет роль, если вы выпадете на две недели.

Как читать ответы кандидата

Хороший кандидат отвечает на эти 10 вопросов за 25–35 минут без подготовки. На сложный вопрос делает паузу и отвечает по существу. На незнание чего-то отвечает «не работал с этим, могу разобраться» или «не моя зона, не возьму». Слабый кандидат уходит в общие слова или в рекламу своих услуг.

Зачем читал

Если вы выбираете vCIO — запишитесь на 30-минутный разговор через форму контакта. Я отдам этот чек-лист в письменном виде, даже если в итоге вы выберете не меня. Серьёзно.

Если вы только думаете «нужен ли нам vCIO вообще», посмотрите сравнение vCIO и штатного CIO. Там матрица из четырёх параметров, которая отвечает на этот вопрос быстрее, чем десять разговоров с кандидатами. Когда уже понятно, что у вас vCIO-сценарий, и вы готовы к аудиту, посмотрите карту ИТ-зрелости за 4 недели. Это первый стандартный проект, с которого начинается работа vCIO. Про регламенты, которые я отдаю клиенту по результатам аудита, читайте в записи про ITIL для 50–500 человек.