"Теперь нам вечно держать дорогих Data Scientist'ов в штате?" Что нужно после сдачи проекта

Ближе к концу почти любого проекта с данными или ML я слышу один и тот же вопрос, и задаёт его обычно собственник, а не технический директор: "То есть теперь нам придётся вечно держать этих дорогих Data Scientist'ов в штате?" За ним стоит понятный страх. Человек смотрит на ставку специалиста, умножает на двенадцать месяцев и на годы вперёд и видит раздутый ФОТ ради системы, которую якобы способен обслуживать только редкий и дорогой человек. А заодно - вечную завязку на меня как на подрядчика, если своего такого человека нет.

Отвечу прямо. Страх обоснованный, компании действительно так попадают. Но держится он на одном смешении: работа, которую делает Data Scientist на этапе постройки, и работа, которую кто-то должен делать после сдачи, - это две разные работы с разной ценой.

Откуда берётся этот страх

Ставка Data Scientist'а высокая, потому что вы платите за исследовательскую часть: выбрать подход, разобраться в ваших данных, собрать признаки, обучить и проверить модель, отбросить пять вариантов, которые не сработали. Это дорогая интеллектуальная работа, и на этапе постройки она действительно нужна.

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

Про то, что под словом "команда данных" прячутся три разные роли с разной зарплатой, у меня есть отдельная заметка: роли data scientist, аналитика и инженера пора разводить.

Что на самом деле стоит дорого, а что нет

Дорогая часть проекта - разовая. Это проектирование: какой подход выбрать, какие признаки считать, как валидировать результат, где границы применимости. Её платят один раз, и результат этой работы - не человек в штате, а зафиксированная, описанная система.

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

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

Первый путь: получать результат как услугу

Здесь вы вообще не держите специалиста по данным. Вы потребляете результат.

Настроенная система живёт как сервис: у неё есть вход (ваши данные) и выход (оценки, прогноз, размеченные записи, готовая витрина или дашборд). Вы отдаёте данные, получаете результат и платите за сервис, а не за штатную единицу. Кто крутит машинерию внутри - забота поставщика, будь это готовый SaaS под вашу задачу или аналитика как услуга с моей стороны.

Когда это подходит:

• Задача не меняется каждую неделю, поток данных стабильный.
• Вам важен результат, а внутренняя кухня как таковая вам не нужна.
• Держать ради этого штатного Data Scientist'а объективно дороже, чем платить за сервис.

Честная оговорка тут одна, и я называю её сразу: сервис - это своя форма зависимости. Вы завязаны не на дорогого сотрудника, а на поставщика и его платформу. Это нормальный размен, но у него есть цена выхода, и посчитать её надо до того, как подписались, а не когда захотели уйти. Про это - отдельная заметка: считать стоимость выхода до подписания.

Второй путь: ваши люди перезапускают настроенные цепочки

Здесь система остаётся у вас, но обслуживать её будет не исследователь, а ваш существующий аналитик.

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

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

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

1. Замораживаю конвейер и версионирую его. Настроенная цепочка дообучения фиксируется целиком: код, параметры, версии данных. Это не обещание "потом пришлю скрипт", а работающая, воспроизводимая система с одной кнопкой запуска.

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

3. Ставлю метрики здоровья и пороги. Чтобы деградацию было видно на приборной панели, а не по жалобам пользователей через три месяца. Модель, которая тихо поехала, опаснее модели, которая явно сломалась.

4. Обучаю одного-двух ваших аналитиков вживую. Не презентацией на час, а несколькими реальными прогонами их руками, пока я рядом. Человек должен сам перезапустить цепочку и сам прочитать метрики, прежде чем я уйду.

5. Явно провожу границу "звоните мне". Где заканчивается операционная работа по чек-листу и начинается та, ради которой действительно нужен я или другой специалист. Ваш аналитик должен знать не только что делать, но и чего не трогать.

6. Оставляю тонкую связь вместо штатной единицы. Небольшой ретейнер на редкие случаи дешевле постоянной дорогой ставки в разы, и он честнее: вы платите за доступ к экспертизе тогда, когда она нужна, а не держите её простаивающей в штате на всякий случай.

Честные оговорки

Было бы нечестно продавать это как "сдал и забыл". Есть границы, и я называю их до старта, а не после.

• Модели деградируют. Данные меняются, мир меняется, и точность настроенной модели со временем плывёт. Кто-то должен за этим следить, но это работа наблюдения по метрикам, а не постоянное исследование. Про то, как это происходит тихо, у меня есть отдельная заметка: модели деградируют незаметно.

• Есть задачи, где исследователь нужен постоянно. Если ваш домен быстро меняется, если модель - это ядро продукта и конкурентное преимущество, если каждый месяц нужен новый подход, а не перезапуск старого, тогда штатный Data Scientist оправдан. Я честно скажу, что это ваш случай, вместо того чтобы продавать красивую передачу, которая развалится.

• Если в цепочке крутятся персональные данные, это отдельный слой. Дообучение на клиентских данных - это ещё и вопрос 152-ФЗ, а не только точности. На него я смотрю отдельно: аудит ИИ на защиту персональных данных.

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

Если коротко

• Страх "теперь держать дорогих специалистов вечно" держится на смешении двух разных работ: построить систему и запускать уже настроенную.
• Дорогая часть - разовое проектирование. Его платят один раз, и его результат - зафиксированная система, а не штатная единица.
• Путь первый: получать результат как услугу (SaaS или аналитика как услуга) и вообще не держать специалиста. Оговорка - завязка на поставщика, посчитайте стоимость выхода заранее.
• Путь второй: ваш существующий аналитик перезапускает замороженную цепочку по runbook. Тяжёлое сделано, остаётся операция по чек-листу.
• Нормальная передача - это заморозка, runbook, метрики здоровья, живое обучение ваших людей и явная граница "звоните мне".
• Есть случаи, где штатный исследователь действительно нужен. Тогда я говорю это прямо.

Если вы на середине проекта с данными и уже думаете, во что он превратится после сдачи, - это правильный момент обсудить. Хорошая передача проектируется с самого начала, а не пришивается в конце. Обсудить задачу можно через форму на главной, и первый разговор ни к чему вас не обязывает. </content> </invoke>