Бюджет на разработку проекта: ожидание и реальность

А соблюден ли бюджет?

Согласно данным исследования Panorama Consulting Solutions, только в 26% ERP проектов (Enterprise Resourse Planning, с англ. – управление ресурсами предприятия) компаниям удалось уложиться в предполагаемый бюджет. В то же время опрос показал, что в 57% случаев компании столкнулись с превышением бюджета по тем или иным причинам.

Источник: Panorama Consulting Solutions (2016)

Опираясь на статистику, компаниям стоит закладывать как минимум 20% от изначальной стоимости проекта на дополнительные расходы. Как правило, именно такой объем «финансовой подушки» способен застраховать от непредвиденного повышения стоимости.

Источник: Panorama Consulting Solutions (2016)

В этой статье мы рассмотрим основные причины, почему первоначальная стоимость IT-проекта не всегда совпадает с финальной, и предложим советы, как нивелировать возможные риски.

Причина 1. Неправильное понимание цены клиентом

Проблема бюджета зачастую начинается с неверных ожиданий клиента по цене. Как показывает опыт, более 50% клиентов изначально «не попадают» в бюджет. Чаще остальных неверные ожидания строят руководители стартапов, для которых это первый опыт взаимодействия с IT-сферой. Почему же так происходит?

На просторах интернета много информации о различных платформах, с помощью которых можно построить сайт. Клиент заходит на эту платформу, узнает стоимость, получает условную цифру в X рублей. Затем звонит другому разработчику, озвучивает свою идею и слышит цену в 3X рублей. Всё дело в том, что далеко не все идеи можно уложить в рамки «ящика», который предлагает массовая платформа. В свою очередь, разработчик реализует для клиента индивидуальное решение, способное полностью раскрыть необходимый функционал.

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

Мы часто работаем с клиентами, которые уже «обожглись». Наняв разработчика с ценой ниже рыночной, заказчик остается недоволен, приходит к нам, и мы начинаем работать с нуля. В таком случае финальный бюджет вырастет в 2–3 раза, ведь придется оплатить и сам проект, и неудачный прошлый опыт.

Причина 2. Планы – бесполезны, планирование — бесценно

На этапе согласования разработчик оценивает сложность задач и потенциальные риски.

Если клиент подписывает договор с фиксированной стоимостью, компания закладывает риски в стоимость проекта. Учитываются непредвиденные сложности при реализации отдельных функций, изменение стоимости необходимых ресурсов и другое. Сыграют эти риски или нет – забота разработчика, клиент в любом случае платит указанную в контракте сумму.

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

Причина 3. Сложность и/или уникальность проекта

Чем сложнее задачи проекта, тем больше риск отклониться от первоначальной стоимости. Например, если разрабатывается очередной dating app (с англ. — приложение для знакомства) по типу популярного приложения Tinder, то функции находятся на поверхности.

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

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

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

Для масштабных проектов (от 5 тыс. часов) нецелесообразно полностью опираться на техническое задание – в 99% случаях оно меняется. Лучше начинать с MVP (minimum viable product – минимально жизнеспособный продукт). Выпустив базовую версию приложения, можно получить обратную связь от реальных пользователей, чтобы осмысленно расширять функционал.

Причина 4. Длительный срок проекта

Если проект длительный (6 мес. и более), бизнес-потребности клиента могут измениться. Многое зависит от сферы деятельности, активности компании, желания соответствовать последним трендам рынка, которые быстро меняются.

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

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

Причина 5. Это не баг, это фича

Заключая договор с фиксированной стоимостью, разработчик всегда предоставляет гарантийный срок – период, в течение которого все баги (ошибки в программах) устраняются бесплатно. Этот срок зависит от объема работ. Например, если разработка велась два месяца, то, как правило, все ошибки находятся за первый месяц использования приложения.

Для проектов с почасовой оплатой возможны разные варианты. Как правило, последующая поддержка проекта осуществляется за счет заказчика. Если нет четко запланированного времени на тестирование, то разработчик не может подписаться на фиксированный гарантийный срок. Чаще всего, критичные «баги» устраняются бесплатно, но за остальные исправления придется заплатить.

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

Причина 6. Полный форс-мажор, товарищи!

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

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

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

В таких кейсах риски делятся 50 на 50, чтобы всем было комфортно. В этом случае, разработчику важно не только покрыть расходы, но и сохранить лояльность клиента, поэтому зачастую находится компромисс.

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

Заключение

Еще один важный момент: успешная реализация проекта невозможна без эффективного взаимодействия. Чем быстрее вы ответите на вопросы — тем лучше. И, пожалуйста, доверяйте профессионалам. Выбирайте разработчика, который готов не только сделать дизайн и написать код, но правильно услышать ваши требования и им соответствовать.