Никто не умеет оценивать, или сколько стоит заказная разработка на самом деле

Привет! Меня зовут Егор, и я отвечаю за коммерцию и маркетинг компании Proscom. Мы создаем цифровые продукты для бизнеса, государства, сферы HR и образования.

Эта статья для тех, кто хочет понять, как и из чего складывается стоимость полного цикла разработки цифрового продукта, как компании подходят к расчетам и откуда берутся цены в предоставленных КП.

Спойлер – все рандомно, никто не умеет и не понимает, как оценивать работы. Даже если есть ТЗ, и оно максимально подробное.

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

И так, ситуация: нужен карьерный портал. Отправляем запрос в 9 компаний. От двух из них получаем уточняющие вопросы, остальным все ясно. Получаем КП от 6 из них — еще двое пишут, что оценивать не будут, и предлагают начать работать по T&M — это когда вы платите за фактически отработанное время специалистов. Одни пропадают. Разброс от 900 тысяч рублей до 35 миллионов рублей.

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

Есть задача, допустим, сделать личный кабинет пользователя на карьерном портале.

Ее смотрят технические специалисты. Дальше они ее декомпозируют. Редко — очень подробно. Ну или нет. Так и оставляют — «Личный кабинет». Без пояснения, что такое «Личный кабинет», какой в нем функционал. Дальше, даже если это человек опытный и делал так тысячу раз, у него в голове материализуются несколько кубиков со случайными числами, делается бросок раз, бросок два и появляется оценка — 148 часов. Он считает, что за это время выполнит задачу.

Почему 148? Он так оценил, он лучше всех тут разбирается в этом. Дальше это количество часов умножается на ставку, по которой продают специалиста, и бинго! Получается сумма.

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

Конечно, на итоговое КП могут влиять следующие факторы:

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

Что не так в этом всем? Дело в субъективности и относительности.
1. Тот, кто оценивал, в большинстве случаев не будет участвовать в разработке.
2. Он вообще не отвечает за то, что оценил. Даже по жопе не получит, не то что финансово. Исключение — оценивает руководитель компании, вот тут полный БДСМ начнется в случае провала.
3. Человек не умеет измерять время, это невозможно. Единственное, что возможно — это сравнить сложность разработки одного проекта с другим.
Это подтверждаем нашим десятилетним опытом и большим количеством просчетов в виде больших финансовых потерь. Короче, мы заплатили за это десятки миллионов рублей.

Что сделали мы? И почему я считаю, что это лучший подход — иначе я бы и не писал эту статью.

За основу мы взяли подход из Scrum Джеффа Сазерленда, натянув его на глобус реалий заказной разработки. Если не читали — абсолютный маст рид.
1. Мы отказались от оценки фичей, функционала, экранов и перешли к оценке пользовательских историй.
2. Мы отказались от оценки в часах — теперь оцениваем сложность. Это просто количество баллов. Число нужно брать обязательно из Чисел Фибоначчи. Потому что сложно сходу понять между 7 и 9 часами, а вот разница между 3, 5, 8, 13 и 21 очень даже понятна
3. Цифровой продукт на 90% состоит из одинаковых пользовательских историй. Для душнил — добавляйте перед названием «Я как пользователь хочу, чтобы…». И обычно это:

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

Например, под авторизацией и регистрацией мы рассказываем, что это обязательно одноразовые коды для телефона или email. Без дополнительной стоимости в виде страниц с восстановлением и хранением паролей, подсказок при создании пароля, ошибок при вводе.

Шаблонные пользовательские истории хранятся в нашей базе. И обычно, пресейл-аналитик собирает 90% сервисов из накопленной базы шаблонных историй.

Есть и процесс для добавления и обновления этой базы, останавливаться на этом не буду. Если интересно, пишите в комментах.

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

После этого автоматически формируется наше КП и улетает клиенту. Почитать можно тут.

Да, наш способ тоже не вершина эволюции. Но он дает свои плоды. Наши результаты формата план-факт стали более точными, стало заметно меньше убыточных проектов. Мы не падаем в историю «работаем только по T&M», чтобы выжить и не топтаться на одном месте. Огромная часть рынка не готова еще работать по таким правилам. Все еще есть процедуры закупок, где нужно кровью подписаться под указанную стоимость.

Огромная часть компаний живет не по продуктовым процессам, а про проектным. Продуктов нет, есть проекты, а значит, и Ганта нам нарисуйте, и роадмэп на 5 лет, и цену точную. До копейки.

Но мир меняется, компании развиваются, и все больше людей понимают, что значит «разрабатывать продукты», а не «завершать проекты».