Каждый заказчик цифрового продукта стремится найти наиболее выгодное предложение на рынке аутсорсинга. После общения с подрядчиками он может получить слишком большой разброс цен за одну и ту же работу — порой в тысячу раз. Но можно ли получить за 500 тысяч такое же приложение, как за 5 миллионов рублей?

Технический директор KODE Николай Николенко считает, что не стоит бездумно выбирать компанию, которая ниже конкурентов оценивает проект, — это может быть маркетинговая уловка или недостаток компетенций разработчика. Поговорим о том, из чего складывается стоимость разработки мобильного приложения, как не попасться в руки недобросовестной компании и на чём можно сэкономить перед первым релизом.

Главная задача перед началом разработки

KODE создаёт цифровые продукты для государства и крупного бизнеса в России и Европе с 2013 года. Наша задача — помочь бизнесу диджитализировать его офлайн-компетенции.

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

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

Первая наша задача — определить, что на самом деле хочет получить заказчик. Мы понимаем, что ни один из наших клиентов не хочет просто потратить деньги. Разработка информационных систем и сервисов — дорогой и сложный процесс, он должен привести к определённому результату: росту числа пользователей, их лояльности или увеличению среднего чека, и в будущем прямо или косвенно покрыть инвестиции в разработку и внедрение системы.

От бизнес-задачи и аудитории будущей информационной системы зависит многое: даже сегмент девайсов, на который она будет запущена. В ТЗ от заказчика практически никогда нет всей нужной информации: как правило, это незаконченные бизнес-требования, описывающие основную функциональность. Крайне редко описываются ограничения интегрируемых систем. Дополнительные вопросы мы как компания-разработчик задаём сами — ведь именно у нас есть экспертиза и понимание, какие данные нужны. Только после детализации верхнеуровневых бизнес-задач и требований, обсуждения текущего IT-ландшафта заказчика, можно спроектировать технически правильное решение, от которого напрямую будет зависеть стоимость разработки.

Почему некоторые компании занижают цену на старте. Кейс KODE

К нам обратился заказчик для оценки довольно сложного проекта. После долгих переговоров и многочисленных обсуждений мы предоставили детализированную оценку. Спустя какое-то время он приехал к нам в офис весьма раздражённый: «Мы нашли компанию, которая делает всё то же самое, но в четыре раза дешевле». Стали разбираться — а то же ли самое она делает? Чтобы понять, из чего складывается цена, нужно погрузиться в детали. Мы попросили посмотреть документ с оценкой проекта — фич-лист, но его не было — договорённость с другим подрядчиком была на словах. Задали ещё пару вопросов, но заказчик не смог объяснить, что именно предлагает подрядчик за эту сумму.

Мы предложили сравнить факты и запросить у наших оппонентов фич-лист. В присланном документе стоимость разработки уже увеличилась на 20%, но всё ещё была ниже нашей. Тогда мы сели и стали разбирать по пунктам, чем он отличается от нашего: что учтено в каждой задаче, какая команда выделена на проект, какой результат заказчик увидит. Всего мы сравнили около 300 наших позиций с детализацией и 30 строчек от наших оппонентов. Приведу два показательных примера.

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

У заказчика в ТЗ был пункт про рассылку таргетированных пушей. В рамках первого общения с ним мы выяснили, что они хотят реализовать около 30 наборов триггеров, которые бы уведомляли пользователей о различных ситуациях. В оценке у оппонентов был один пункт — отправка таргетированных пушей, но они заложили только возможность отправить пуш с произвольным текстом, полагая, что это покрывает все кейсы. Мы же понимаем, что информационная система должна автоматизировать действия и ни один заказчик не будет выполнять рассылку вручную, необходимо реализовать отдельную бизнес-логику, прописать реакцию на все требуемые события, заложить шаблоны сообщений и персонифицировать их по каждому пользователю. А это точно выходит за оценку 8 часов у наших оппонентов.

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

Можно предположить, что низкая цена на старте проекта — это маркетинговый приём, но часто всё не так. Иногда аутсорс-компании не до конца понимают глубину задачи. Это показатель недостатка опыта или формального подхода: прочитали ТЗ — разрабатываем то, что написано. При таком подходе заказчик либо получает не тот результат, который ему нужен, либо доплачивает уже в процессе разработки.

Есть простое правило, которое мы часто подтверждали на практике: если после обсуждения проекта заказчику не предоставили фич-лист, а просто назвали цену, скорее всего она вырастет в процессе разработки.

Первый этап оценки проекта

Старт разработки начинается с оценки стоимости проекта, мы отталкиваемся от ТЗ и объёма работы. Декомпозируем функциональность приложения до отдельных фичей и считаем стоимость разработки каждой. На основе декомпозиции формируем документ с оценкой проекта — фич-лист. По сути, это таблица, в которой указаны:

• функциональность, которую предстоит разработать;
• специалисты и стоимость их работы в часах;
• сроки выполнения.

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

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

На чём можно срезать косты

Мы готовим фич-лист на основе бизнес-целей и объёма функциональности, а затем сталкиваемся с ограничениями.

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

Самый простой кейс — форма обратной связи. Её можно сделать кастомной: проработать всю логику и реализовать на сервере — это займёт у разработчика 60–90 часов. Можно упростить и направлять пользователя на имейл с заполненным шаблоном — это 2–4 часа работы. Возможны и промежуточные варианты. Любую фичу можно реализовать сложнее или проще. Мы показываем это заказчику и советуем делать упор на основную функциональность, которая принесёт деньги и лояльность аудитории.

В первом варианте формы обратной связи пользователь просто переходит в свой почтовый ящик и пишет письмо. Во втором — пишет сообщение непосредственно в приложении. В третьем — переходит в чат-бот приложения

Можно ли получить мобильное приложение за 500 тысяч рублей? Можно. Но по функциональности оно будет заметно отличаться от приложения за 5 миллионов.

5 критериев: на что обратить внимание при выборе подрядчика

1. Ответственный подрядчик задаёт много вопросов на старте проекта. Если вопросов нет, это показатель формального подхода.

2. Стоимость, которую назвали, не составив фич-лист, ничего не значит. Она изменится в процессе работы.

3. Фич-лист должен быть максимально детализирован.

4. Если нужно, спросите подрядчика, на чём можно сэкономить. Вам помогут определить наименее приоритетные фичи.

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