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

Как выбрать подрядчика для разработки B2B-портала, маркетплейса и другого сложного программного обеспечения? Можно ли сравнивать IT-компании по стоимости часа? Вопрос, насколько безопасно выбирать подрядчика с низкими ценами, волнует многих управленцев. С одной стороны, хорошее стоит дорого. И, сэкономив, можно «купить» себе море проблем. С другой — бюджет не резиновый, ресурсы всегда ограничены (так уж устроен бизнес). Где золотая середина и справедливая цена?

Меня зовут Андрей Путин, я управляющий партнёр IT-компании kt.team с двадцатилетним опытом в разработке. В этой статье я расскажу, почему не стоит сравнивать разработчиков по стоимости часа и выбирать IT-подрядчика по предварительной оценке технического задания. Информация будет полезна руководителям компаний, техническим директорам и другим decision maker'ам.

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

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

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

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

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

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

• дорогое оборудование;
• накладные затраты на персонал (офис, обслуживание сотрудников — еда, ДМС и многое другое);
• налоги;
• накладные затраты на бизнес-процессы (бухгалтерия, менеджмент, безопасность, сервисы автоматизации и т. д.).

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

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

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

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

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

• составом работ — результатом выполнения задачи считаем строгое исполнение прочтённого или учитываем необходимые корректировки в процессе работы;
• количеством учтённых рисков;
• наличием (а в подавляющем большинстве — отсутствием) юнит-, интеграционных, API-функциональных тестов.

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

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

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

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

• речь об интернет-магазине, который генерирует 20 % численности всех покупателей в офлайн-магазины сети с годовой выручкой 40 миллиардов рублей;
• собственный годовой оборот онлайн-магазина — более трёх миллиардов рублей.

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

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

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

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

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

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

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

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

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

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

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

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

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