По нашей внутренней статистике 8 из 10 запросов заказчиков звучит следующим образом - разработать мобильное приложение или IT-решение в рамках конкретного фиксированного бюджета. При этом некоторые IT-команды готовы взяться за работу с ценой меньше заявленного бюджета, а другие оценивают задачу намного превышая требуемую стоимость. Как в этом случае заказчику выбрать подрядчика и получить желаемый результат в рамках имеющихся ограничений?
Давайте порассуждаем вместе на примере нашего кейса, из чего складывается стоимость разработки, на что стоит обратить внимание при выборе подрядчиков и можно ли разработать проект, вписавшись в фиксированный бюджет?
Основано на реальных событиях
Gravity Group занимается разработкой и интеграцией IT-решений для крупного и среднего бизнеса с 2014 года. Также в портфолио компании есть проекты от государственных заказчиков, например, мобильное приложение “К врачу”.
В конце мая наша команда получила запрос от интересного заказчика, сети спортивно-развлекательных центров - батутная арена, детские игровые комнаты, индивидуальные и групповые тренировки с тренерами по разным направлениям, организация и проведение соревнований, в том числе и серьезные региональные конкурсы по спортивной гимнастике, квесты для детей, проведение детских дней рождения и т.д.
Суть запроса - оценить стоимость и сроки разработки мобильного приложения, в котором должен быть реализован обязательный ряд разделов. Заказчик предоставил достаточно подробное, но не полное ТЗ, сказав, что есть ограничение по бюджету на определенную сумму и есть конкуренты, готовые сделать весь проект всего на 10% дороже бюджета.
По мнению нашей команды, техническое задание было продуктом упрощения какого-то другого документа, который упоминался вскользь. При упрощении логика была определена не полностью. Например, в приложении один из разделов “магазин призов” - можно купить приз и получить его на стойке администратора, но не описано, нужна ли корзина, как администратор поймет, что клиент оплатит приз, какая отчетность подразумевается, чтобы руководитель центра мог увидеть, сколько и каких призов было продано и сколько осталось.
В связи с этим команда Gravity составила список вопросов для получения полного перечня работ, который поможет объективно оценить проект. Исходя из полученных ответов было предложено 3 варианта решения поставленных задач и у каждого решения была своя оценка. Разница с бюджетом заказчика была от 40 до 200% в большую сторону. Так как наша команда при оценке любого проекта составляет полную детализацию, заказчику было предложено самому ознакомится с оценкой всех фич и оптимизировать приложение для первого релиза. А все, что не вошло в первую версию продукта, можно было бы перенести на следующие обновления. В таком случае мы могли бы вписаться в фиксированный бюджет, проект бы запустился и начал получать обратную связь от реальных пользователей.
Но заказчик был непоколебим - “все компоненты нужны, ни от чего отказываться не будем”. При этом с его же слов “конкуренты оценили, не задав ни одного вопроса”. Отсюда и выводы, что делать если бюджет ограничен:
Вопросы признак мастерства
Стоимость разработки, в нашем случае этап оценки, зависит от полноты проработанности ТЗ и вытекающих из него вопросов. Только после обсуждения всех деталей и бизнес-задач, можно приступать к этапу оценки. В противном случае оценка проекта, на наш взгляд, не имеет смысла. Она изменится в процессе работы.
Убедитесь, что ваше техническое задание проработано в полном объеме и понятно всем участникам будущего проекта.
Детализация всему голова
Получив хотя бы 2 оценки одного и того же проекта, стоит обратить внимание на детализацию. Что именно заложили в оценку оба подрядчика, какие работы и фичи будут реализованы на определенном этапе, с чем связаны такой объем работ и сроки. Зная ответы на эти вопросы, вы сможете более объективно оценить подрядчиков, уточнить почему был выбран тот или иной подход и метод.
Сравнивайте сравнимое, чтобы получить более объективную оценку.
Может не все сразу?
Благодаря подробной детализации вы можете понять, сколько стоит та или иная фича, что можно перенести на дополнительные работы после релиза, от чего можно отказаться и тем самым сэкономить и вписаться в ограниченный бюджет.
Если проект превышает фиксированный бюджет, разбейте его на части.
Все и сразу!
Такой вариант вполне возможен, но есть нюанс - если вы получили от разных подрядчиков по одному и тому же (проработанному) ТЗ приблизительно одинаковые оценки, которые превышают ваш бюджет, то может все таки прислушаться к профессионалам?
Увеличить имеющийся бюджет и зафиксировать его.
Учиться на своих ошибках
Можно пойти более рискованным путем, который мы не раз наблюдали - взять подрядчика с более низкой оценкой проекта, перекреститься и верить в чудо, что все получиться. А после неудачного опыта вернуться к тем, кто оценил объективно, задавал вопросы и сделал качественную детализацию, но уже с увеличенным бюджетом или сокращенным функционалом.
Заплатить за опыт, сделать выводы и не совершать подобных ошибок.
