Базовых варианта ценообразования проектов (в частности, в data science) существует три: фиксированная цена, пропорционально затратам, и пропорционально результату. О выборе между ними рассказал Роман Чеботарёв, CTO из Theta Data Solutions, на конференции Data&Science в Яндексе.
Разговор ведётся в основном с точки зрения исполнителя (он менее защищён, ибо клиент всегда прав). Сложности обычно приходят при закрытии проекта: клиенту и исполнителю сложно договориться, сколько же заплатить за него. Поэтому договариваться надо заранее. И вот на что можно договориться.
1. Fix price
Fix price - самая понятная и привычная модель. Задачи, сроки, и стоимость заранее зафиксированы в договоре. Таких проектов большинство. Это единственно возможный вариант при тендере (а тендер - часто единственный способ войти с проектом в госкорпорацию). В этом варианте обычно интеллектуальная собственность принадлежит клиенту (если исполнитель явно не обозначает, что использует собственные наработки). В рамках этого формата может быть разная разбивка по срокам и разные условия с авансом.
Проблемы с такими проектами есть. Например, клиент часто считает, что мы его рабы, раз он нас купил, и увеличивает проект, звоня исполнителю ночью и вешая на него новые задачи. PM на проекте нужен как раз для того, чтобы очень чётко фиксировать требования, и перезакладывать ресурсы на всякий случай. Говорят, что изначально ожидаемые трудозатраты в процессе планирования стоит умножать на пи. Если проект хайповый (в его названии упоминаются ML, AI, или, не дай бог, блокчейн), то многие участники будут туда лезть просто, чтобы прикоснуться к великому, но не очень помогают (потому что не разбираются в теме), и не хотят брать ни за что ответственность ответственность. Поэтому стоит заводить устав проекта и сразу писать, кто за что отвечает. Когда приходит новый участник, стоит спрашивать, чем он хочит заниматься, и направлять его к соответствующему ответственному.
В Fix Price стоит избегать KPI на метрики качества, ибо исполнитель на самом деле не очень на них влияет - они зависят от данных, от поведения заказчика, от фазы луны, и прочих непредсказуемых факторов. Зафиксировав труднодостижимые KPI, бывает очень сложно потом проект закрыть. Поэтому, если клиент хочет коммита на показатели, надо требовать за них премию. А если конкретные ожидания от показателей качества есть, стоит фиксировать контрольный слепок данных, на котором будет проводиться приёмка.
Последний нюанс - гарантийная поддержка. 722 статья ГК говорит, что исполнитель должен исправлять ошибки в соответствии с деловой практикой в этой отрасли. Чтобы не становиться заложником непонятной "практики", стоит заранее обговорить, какая именно гарантийная поддержка предусматривается.
2. Time and material
Time&Material (T&M) модель выгодна для исполнителя, особенно для небольших команд. Здесь покупают время исполнителя по фиксированной ставке. Срок и размер договора может быть открыт. Платежи совершаются регулярно: в рамках договора формируются отдельные заказы, каждый из которых оплачивается пост-фактум по затраченному времени.
В этй модели тоже есть сложности. Например, клиент может быть не готов платить за менеджеров и другой вспомогательный персонал - это стоит явно закладывать или не закладывать в ставку заранее. Клиент будет пытаться стянуть модель к FixPrice, считая, что он лучше знает, сколько ресурсов на что нужно ("мой сын-одиннадцатиклассник в компьютерах понимает, он говорит, такое за день делается"). Тут стоит разбивать большую непонятную задачу на маленькие задачи, и управлять ожиданиям клиента в каждой по отдельности. Часто один из результатов работы текущего этапа - ТЗ на следующий этап. Наконец. ещё один риск такой модели - проект может в любой момент закончится, и у исполнителя будут простои.
3. Success Fee
Success Fee - самая пока что непопулярная модель, но понемножку она к нам просачивается. Это самая партнёрская модель: исполнитель оговаривает тот эффект, который он оптимизирует, и берёт какую-то долю (обычно от 5% до 20%) от фактической экономии. Услуги тут осуществляются по сервисной модели, платежи производятся регулярно, права на ИС принадлежат исполнителю. Заказчик не очень погружается в детали проекта - он просто даёт заказчику рулить, получает эффект и проверяет, что он рассчитан правильно. Эта модель вообще интересная для обоих сторон, но по разным причинам сложненькая.
Во-первых, эффект надо посчитать. Тут нужен базис для расчёта, и это проблема. Пусть, например, мы производим считы для Капитана Америки. Материалы (вибраниум и адамантий) дорогие, и их свойства варьируются от партии к партии. Выходной контроль такой: Тор бьёт молотом по щитам, и измеряется размер вмятины. Заказчику хочется экономить материалы, не слишком теряя в качестве, но от чего считать экономию? В исторических данных нужно найти сопоставимые кейсы с похожими условиями производства и свойствами материалов - а они могут быть неоднозначны или вообще не быть. Плюс данные (результаты испытаний) могут с большой погрешностью замеряться: что можно сказать о вмятине в 1 мм, измеренной с погрешностью 0.5 мм? Эффект будет со временем деградировать, т.к соревнуемся мы сами с собой. Клиент скорее всего не даст сравниваться с одними и теми же устаревающими данными. Ещё один риск - у клиент может резко что-то измениться в процессе. Например, адамантий могут заменить на сталь, и нужно всё переделывать - в договоре надо такие резкие изменения предусматривать (и требовать компенсации в этом случае них). И ещё один риск - клиент просто перестанет пользоваться рекомендациями нашего сервиса. Тут можно предусматривать минимальное количество использований, и требовать какой-то фиксированный minimal fee, который платиться, если даже сервис не очень используется. Но чтобы не было подозрений в коррупционной схеме, его тоже часто приходится измерять в эффекте.
Плюсы и минусы
Как вообще выбрать форму контрактования? Сейчас можно посмотреть на ситуацию глазами клиента - а это большая организация, и она заботится о бюджете. Им часто сложно законтрактовать что-то кроме fix price. Fix price обычно бюджетируются как капекс, и планируются типа на год. А два других типа - опекс, и там может быть низкая верхняя планка по бюджету.
Fix price подходит, если вы делает проект не один раз, и можете заложить все риски. Нормально, если это большой проект (ибо он долго поднимется), и у вас нет срочной нужны в деньгах (ибо их долго ждать). У вас должен быть хороший project manager, который будет управлять требованиями, всё согласовывая и при этом оставаясь хорошим человеком.
T&M хорош, если вам нужны быстрые деньги. Можно делать так, если вам заранее непонятен объем задач, или проект небольшой, и ваша задача - создать работающий прототип.
Success fee можно пробовать, если вы хорошо знаете, как устроен бизнес клиента, уже решали похожие задачи, и более-менее уверены в эффекте. И если вы сможете выжить, если получите за проект 0 рублей. Такие проекты хороши как PR, но (особенно если это первый проект) чаще всего убыточны.
Q: Что показывать заказчику, если не хочется показывать метрики?
A: В идеале мы показали потенциальный эффект на предпроектном пилоте, и после этого клиент уже понимает, что тут может быть польза, но в контракте KPI не пишутся. А в контракте лучше всего фиксировать конкретные use cases. На них можно заоверфититься, но тут уж ничего не поделаешь. Если заказчик опасается за переобучение, тестовую выборку можно бить надвое, и выдавать исполнителю одну половинку.
Q: Как балансировать типы разных проектов в портфеле?
A: Работать только по Success Fee примерно невозможно (и заказчиков, готовых на это, всё равно мало). Крупные исполнители (от 30 человек) могут удобно работать по fix price, ибо это у них будет уже планируемая штука - в одном проекте чуть перерасходуют ресурсы, в другом сэкономят, и в целом получится нормально. T&M в такой парадигме можно использовать в исключительных случаях, когда перспективы особенно туманны. T&M больше проходит для небольших команд - но они требуют много "жизненных сил".
Q: Какая средняя ставка по T&M на датасайнтиста?
A: Говорят, что от 3 до 5К в час, включая НДС. На первый взгляд кажется, это очень много. Но на самом деле в этой цифре много разных оверхедов, от налогов, до стоимости офиса, менеджеров, ПО, и так далее. Поэтому она адекватна.
На этой же конференции Data&Science рассказали о жизненном цикле коммерческого ML-проекта, о создании моделей, которым заказчик будет доверять, и о том, должен ли data scientist уметь писать код для продакшна.