Ценообразование в разработке. Почему разработка не должна быть дешёвой?

Сколько зарабатывают разработчики

Высококвалифицированных специалистов не хватает везде, и рынок труда в IT не исключение. Здесь работодатели конкурируют за сотрудников. Зарплаты растут, офисы становятся круче, нематериальная мотивация (которая тоже стоит денег) воспринимается как must have. Такая ситуация везде: у нас есть офисы в трёх городах (Москва, Краснодар, Тольятти), и везде зарплаты сбалансированы — их медианные значения отличаются не более чем на 30 %. Ни один из трёх городов нельзя назвать «дешёвым».

Зарплата разработчика зависит от его навыков, технического уровня, опыта, специализации (стека). Средняя заработная плата в сфере IT во втором полугодии 2019 года составила 113 313 рублей в месяц. Архитектор программного обеспечения, например, получает в среднем 190 тысяч рублей в месяц, frontend-разработчик — 100 тысяч рублей.

Да, мы знаем редкие истории об IT-компаниях, где разработчикам платят 30 тысяч рублей в месяц. Это всегда заканчивается одинаково: огромной текучкой.

Себестоимость рабочего места разработчика

Кроме зарплаты, цена на услуги IT-специалиста включает:

Представим, что себестоимость обеспечения одного сотрудника — 100 тысяч рублей в месяц (возьмём зарплату ниже рынка и минимальные налоги). Если поделить эту сумму на количество рабочих часов в месяце (а их примерно 140 с учётом обедов), то стоимость часа уже не может быть ниже 714 рублей.

Если же ваша команда состоит из архитекторов да сеньоров, то с учётом налогов и недорогого менеджера на команду самый-самый минимум себестоимости окажется в районе 250 тысяч рублей в месяц. Это чуть больше 1785 рублей в час. Добавьте хотя бы незначительные затраты на инфраструктуру (минимум 10 %) — уже получается 1964 рубля в час. Если вы встретите цену ниже этих значений, можете быть уверены: или есть нюансы относительно уровня команды, или же будут мультипликаторы в выставляемых часах.

Если компании сбалансированы по стоимости часа, значит, заказчику можно отправить ТЗ и сравнить количество часов? Вдруг одна команда сделает быстрее, чем другая? Тут вас будет ждать другой нюанс.

Разница в оценке в несколько раз вряд ли означает, что подрядчики оценили одно и то же. Скорее всего, вы видите разные подходы к реализации ваших пожеланий с разными допущениями относительно рисков.

Заказчик ожидает, что это цена за одинаковый объём работ и одинаковое исполнение. Но по факту это выбор между реализацией А и реализацией Б. Они различаются:

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

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

Оценивать стоимость разработки в абсолютных величинах некорректно. Разберём на примере, почему.

Как думаете, пять миллионов рублей за разработку e-Commerce-проекта — это дорого? Если говорить абстрактно, то пять миллионов — внушительная сумма. Также могут быть известны и другие данные:

Пять миллионов уже не кажутся большой суммой, ведь 0,04 % прироста конверсии окупают весь проект за месяц.

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

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

Иначе говоря, продукт разработки — это актив (генерирующий деньги), но смотрят на его стоимость как на стоимость пассива (потребляющего деньги). Да, продукт разработки нематериальный, но мы можем сравнить его со станком на производстве. Неважно, во сколько заводу обошёлся станок, если он окупается и работает без сбоев, правда? И будет досадно, если дешёвый станок не справится со своими задачами, будет тормозить конвейер, простаивать, вечно требовать ремонта?

Стоимость разработки и глубина проработки и планирования должны уравновешиваться потенциалом программного продукта, его ROI (return on investment, рус. окупаемость инвестиций).

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

На самом деле разработка по ТЗ невыгодна и неудобна. Его сложно написать, по нему сложно принимать работу, и в процессе многие требования меняются.

И госы, и крупные бюрократизированные клиенты — у всех всё меняется. В нашей копилке уже с десяток крупных проектов, которые запускались в состоянии, сильно расходящемся с ТЗ!

Подробно о ТЗ в IT писала моя коллега Джеклин Баффо в другой статье — «MVP, или как не попасть в бесконечную разработку». Там же есть и интересные кейсы, пример процитирован ниже.

«Создание ТЗ длиной в год.

Департамент нашего постоянного клиента попросил сделать объём по фикспрайсу. Мол, требования понятны, функционал простой, мы сами нарисуем макеты, вы только сделайте. Собрать ТЗ на „понятные" требования и подписать на них договор удалось только через год (!), ведь у заказчика есть работа, кроме согласования ТЗ, читать большой документ сложно и долго — пока обсуждаешь одну часть документа, забывается другая, через какое-то время нужно отредактировать уже ранее написанные части и т. д.

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

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

Одни подрядчики не учитывают реально существующие проблемы (занижают риски). Другие, наоборот, любят «напустить страху», учитывают сложности, которых нет. Проводя тендер, каждый подрядчик будет думать: «Нужно ли мне делать КП на основании ТЗ или стоит переосмыслить его в меньшую или большую сторону?»

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

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