Когда малому бизнесу нужен внешний CTO

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

Ниже — шесть ситуаций, в которых роль внешнего технического директора (её ещё называют fractional CTO) окупается быстрее, чем альтернативы: наём в штат, ещё один подрядчик или «пока подождём».

1. Технические решения принимает тот, у кого нет времени их проверять

Основатель согласовывает архитектуру между звонками с клиентами. Подрядчик присылает смету на переписывание, и проверить её некому: нет человека, который одновременно понимает код и отвечает за бизнес-результат. В такой ситуации любая оценка принимается на веру — а веры в технологиях хватает ровно до первого инцидента.

Внешний технический директор закрывает именно этот разрыв: он читает код и смету и говорит на языке денег и рисков. Не «это плохая архитектура», а «это решение добавит две недели к каждому релизу и увеличит стоимость инфраструктуры вдвое».

2. Подрядчиков несколько, и у каждого свои правила

Типовая картина: сайт делает одна студия, мобильное приложение — вторая, интеграцию с банком — третья, поддержку — фрилансер по знакомству. Каждый работает добросовестно, но границы ответственности размыты, а сквозные вещи — доступы, окружения, релизный ритм, приёмка — не делает никто.

Роль технического директора здесь — не «заменить всех», а установить общий контур: кто за что отвечает, как принимаются работы, по каким критериям считается результат, где хранятся секреты и как выглядит отчёт о поставке. Подрядчики при этом обычно остаются.

3. Релизы замедлились, а объяснения звучат убедительно

«Мы чистим техдолг», «нужен рефакторинг», «ещё немного и всё поедет» — эти формулировки могут быть правдой, а могут быть способом не называть настоящую причину. Отличить одно от другого без человека, который умеет читать код и метрики, почти невозможно.

Технический директор начинает с диагностики: где именно теряется время, сколько стоит каждый участок техдолга в инженерных днях, что можно не трогать. И только потом принимается решение о рефакторинге, переезде или замене подрядчика.

4. Нужна технологическая стратегия, а не список «хотелок»

Стратегия — это документ, где написано, что мы делаем в этом году, что не делаем и почему. В нём есть сроки, стоимость и развилки: монолит или сервисы, своя команда или подрядчик, облако или выделенные серверы. Без такого документа каждый новый проект начинается с переговоров о том, «как правильно».

Хорошая стратегия на 12–24 месяца укладывается в 15–25 страниц и переживает смену подрядчика. Плохая — в 80 слайдов и живёт до первого квартального пересмотра.

5. Готовитесь к сделке, раунду или партнёрству

Покупатель, инвестор или крупный партнёр задаёт неудобные вопросы: кому принадлежат права на код, какие лицензии используются, что с персональными данными, сколько на самом деле стоит сопровождение, кто останется после сделки. Ответы на них готовятся заранее — это technical due diligence, независимое заключение по технологической части.

Такое заключение защищает обе стороны: продавец перестаёт бояться вопросов, покупатель получает картину, а не презентацию.

6. Команда выросла, и процессы перестали масштабироваться

Пять человек договаривались устно, пятнадцать — уже не могут. Нужны роли, зоны ответственности, релизный ритм, метрики, план найма под задачу, а не под вакансии. Это управленческая работа, которая редко появляется сама.

Чем это не является

Чтобы не купить не то, что нужно, стоит разделить три роли:

• Подрядчик на задачи — делает то, что попросили, и отвечает за объём работ. Ответственность за то, правильные ли это задачи, остаётся у бизнеса.
• Консультант — даёт рекомендации и уходит. Если рекомендацию не выполнить, ничего не меняется.
• Внешний технический директор — входит в управленческий контур, отвечает за решения, ведёт архитектуру, принимает работы и отчитывается за результат.

Разница проявляется в мелочах: консультант оставляет отчёт, технический директор — регламент, который соблюдается; консультант разбирает один вопрос, технический директор держит картину целиком.

Сколько это занимает и как начать

Рабочий режим — два-три дня в неделю при частичной роли и больше при полной загрузке. Вход почти всегда одинаковый: сначала платная диагностика на две-три недели с фиксированным результатом — карта техдолга, реестр рисков, оценка ёмкости команды и план на 90/180/365 дней. По итогам диагностики принимается решение: ретейнер, программа с вехами или остановка.

Диагностика самодостаточна: если после неё вы решите двигаться своей командой, карта и план останутся у вас. Это и есть главный тест на добросовестность — платить за документ, по которому можно действовать без автора.

Короткий чек-лист

Роль пора вводить, если хотя бы два пункта из этого списка верны:

• технические решения согласуются людьми без технической подготовки;
• в проектах участвуют три и более подрядчика без общих правил;
• сроки релизов систематически срываются, причины меняются;
• нет документа с планом развития технологий на год;
• предстоит сделка, раунд или крупный партнёр с аудитом;
• командой управляют по памяти, а не по регламентам и метрикам.