Как не сорвать бюджет и сроки разработки: чек-лист заказчика
На старте проекта заказчик и подрядчик почти всегда сходятся на сумме и дате запуска. Через пару месяцев смета оказывается больше, а дата — дальше, причём не из-за одного крупного события, а из-за десятка мелких договорённостей, которые никто не зафиксировал письменно. Разберём, где расходятся план и факт, что заказчик проверяет до подписания договора, что контролирует каждую неделю и какой резерв закладывает, чтобы бюджет и срок не разошлись с планом.
Почему бюджет и срок расходятся с планом
Разработка оплачивается как оценка будущей работы, а не как покупка готового товара с ценником. Пока продукт не описан детально, сумма и дата в коммерческом предложении остаются прогнозом: подрядчик считает по тому объёму, который увидел, а работать будет по тому, который выяснится в процессе. Расхождение появляется ровно там, где прогноз строили на общих формулировках, а разработка пошла по конкретике.
По нашему опыту перерасход почти никогда не выглядит как одно крупное событие, о котором можно рассказать на совете директоров. Он набирается из мелочей: уточнили сценарий на созвоне и не внесли в документ, три недели ждали доступ к учётной системе, поменяли макет экрана после того, как экран уже разработан. Каждый эпизод по отдельности стоит немного, вместе они дают ту самую разницу между планом и фактом.
| Источник расхождения | Как это выглядит на проекте | Когда становится заметно |
|---|---|---|
| Неполное описание объёма работ | Каждую неделю появляются «небольшие уточнения», которых не было в оценке | В середине разработки |
| Изменения по ходу проекта | Согласованный экран переделывают после того, как он готов и протестирован | Ближе к приёмке |
| Ожидание на стороне заказчика | Доступы, тексты, данные каталога приходят позже запланированного | С первой недели, но копится незаметно |
| Интеграции с внешними системами | Учётная система или платёжный сервис отдаёт данные не в том виде, на который рассчитывали | На этапе подключения интеграций |
| Приёмка одним списком | Замечания приходят разом в конце, а не по мере готовности блоков | В последние две недели проекта |
| Забытые статьи расходов | Аккаунты разработчика в сторах, серверы, платные внешние сервисы всплывают перед запуском | Перед запуском |
Практический вывод из таблицы простой: половина причин лежит не на стороне подрядчика, а на стороне заказчика и в организации совместной работы. Именно поэтому чек-лист заказчика работает — он закрывает ту часть, которой подрядчик управлять не может.
Что фиксируется до старта: объём, срок, цена
Управляемый проект начинается с трёх письменных договорённостей: что именно делаем, к какому сроку и за какие деньги. Дальше к ним добавляются ещё две, о которых вспоминают реже: как принимаем работу и что делает сам заказчик. Пока эти пять пунктов существуют только в переписке и в голове менеджера, спорить об отклонениях будет не с чем.
| Что фиксируем | Что это закрывает | Чем оборачивается отсутствие |
|---|---|---|
| Объём работ: перечень экранов, сценариев, интеграций, ролей пользователей | Границу между «входит в цену» и «считается отдельно» | Спор о том, была ли задача в оценке, каждые две недели |
| Срок с контрольными точками | Возможность увидеть отставание в начале, а не в конце | Отставание становится известно, когда исправлять его уже дорого |
| Цена и порядок изменений | Правило, по которому новая задача попадает в проект и в бюджет | Изменения принимаются устно, счёт растёт без общего понимания причин |
| Состав приёмки: что и по каким признакам считается сделанным | Понятный критерий «готово» для каждого блока работ | Приёмка растягивается, потому что стороны понимали результат по-разному |
| Обязанности заказчика: доступы, контент, сроки согласования | Часть плана, за которую отвечает бизнес, а не подрядчик | Простои команды, которые всё равно оплачиваются временем проекта |
Последняя строка — самая недооценённая. Договор обычно детально описывает обязанности исполнителя и в двух словах — обязанности заказчика, хотя именно на этой стороне возникают недели ожидания. Если у вас нет описанного продукта, отдельным шагом стоит заказать разработку технического задания: документ с экранами, сценариями и требованиями к интеграциям превращает разговор о цене из спора в арифметику. Порядок шагов по подготовке заказа разобран в пошаговом чек-листе заказа разработки.
Как модель оплаты влияет на риск перерасхода
Модель оплаты не делает проект дешевле или дороже сама по себе — она распределяет неопределённость между сторонами. При фиксированной цене неопределённость берёт на себя подрядчик и закладывает её в сумму. При оплате по факту её берёт заказчик и получает взамен гибкость. В модели готовой платформы часть неопределённости снимается заранее, потому что базовые сценарии уже разработаны и проверены на действующих проектах.
| Параметр | Фиксированная цена | Оплата по факту (Time & Materials) | Готовая платформа: интеграция + лицензия + доработки |
|---|---|---|---|
| Что известно до старта | Итоговая сумма и дата | Ставки ролей и порядок отчётности | Стоимость и срок интеграции, размер ежемесячного платежа |
| Что происходит при изменении задачи | Оформляется дополнительное соглашение, срок сдвигается | Задача попадает в ближайшую итерацию, счёт растёт на её объём | Базовое остаётся в пакете, уникальный сценарий считается отдельно по часам |
| Срок до первого запуска | 120–250 рабочих дней для крупного продукта с нуля | Зависит от объёма, границы срока заранее не фиксируются | До 30 рабочих дней на интеграцию под бренд |
| Сильная сторона | Сумма понятна заранее и защищена договором | Продукт можно менять по ходу, не переподписывая договор | Короткий срок запуска и предсказуемая ежемесячная сумма |
| Ограничение | Любое изменение проходит через переговоры и сдвигает дату | Итоговая сумма проекта заранее не зафиксирована | Базовые сценарии заданы модулями, уникальная логика оплачивается сверх пакета |
| Когда подходит | Объём описан детально и меняться не будет | Продукт исследовательский или дорабатывается уже работающий | Нужен работающий канал продаж в понятный срок |
Ни одна модель не выигрывает по всем строкам сразу. Фиксированная цена сильнее там, где объём стабилен, и слабее, когда продукт уточняется по ходу; оплата по факту работает наоборот. Подробное сравнение двух моделей с расчётами — в разборе Fixed Price и Time & Materials, а сравнение подходов к самой разработке — в материале о моделях разработки. Цифры по пакетам платформы держим в одном месте — на странице тарифов.
Чек-лист заказчика: до подписания договора
Это стадия, где решения стоят дешевле всего, а влияют на итог больше всего. Пройдите список до того, как подпишете документы, — каждый пункт закрывает конкретную причину перерасхода из первой таблицы.
Объём работ: что должно быть описано
- Перечень экранов и сценариев. Не «личный кабинет», а список того, что пользователь в нём делает: смотрит заказы, повторяет заказ, меняет адрес, оформляет возврат.
- Список интеграций поимённо. Учётная система, платёжный сервис, служба доставки, система лояльности — с указанием, у кого готовые методы обмена данными уже есть.
- Роли и права. Покупатель, менеджер, администратор: у каждой роли свой набор экранов, и он влияет на объём работ сильнее, чем кажется.
- Целевые платформы и каналы запуска. iOS, Android, веб-версия; публикация в App Store, Google Play, RuStore и других сторах под аудиторию проекта.
- Что в объём не входит. Раздел «не входит» полезнее раздела «входит»: он снимает половину будущих споров.
- Требования к данным. Кто готовит каталог, описания, фотографии, и в каком формате они передаются.
Оценка: как читать смету
- Смета разбита по задачам, а не одной строкой. «Разработка приложения — 3 000 000 ₽» проверить нельзя; список задач с часами — можно.
- Указаны роли и их ставки. Аналитик, дизайнер, разработчик интерфейса, серверный разработчик, тестировщик, руководитель проекта — состав команды объясняет сумму.
- Видно, что заложено на тестирование и приёмку. Если этих строк нет, они появятся позже как отдельный счёт.
- Есть оценка интеграций отдельно от остального. Это самая подвижная часть сметы, и она должна быть видна.
- Сравнивайте предложения по составу, а не по итоговой цифре. Более низкая сумма часто означает более узкий объём работ, а не более выгодные условия.
Здесь мы смотрим на смету глазами того, кто принимает решение о старте. Из чего складывается сама цена — часы, роли, ставки, факторы удорожания и способы уложиться в меньший бюджет — разобрано отдельно в материале про стоимость разработки программного обеспечения.
Договор: пункты про деньги и срок
- Порядок изменения объёма. Кто оформляет запрос, за сколько дней даётся оценка, кто утверждает и как это влияет на дату.
- Контрольные точки с признаками готовности. Не «дизайн», а «согласованы макеты ключевых экранов из списка приложения №1».
- Сроки согласования на вашей стороне. Если заказчик отвечает на макеты десять дней, это должно быть в графике, а не сюрпризом.
- Условия приёмки и исправления замечаний. Срок на замечания, срок на исправление, что считается существенным недостатком.
- Гарантийный период и что в него входит. Обычно это устранение дефектов, а не развитие функциональности — формулировка должна это разделять.
- Условия по аккаунтам в сторах и правам на результат. Здесь модели у подрядчиков различаются, и лучше прочитать этот пункт до подписания, а не после.
Отдельно проверьте самого подрядчика: юридическое лицо и срок его работы, наличие компании в реестре аккредитованных IT-компаний, опубликованные проекты с описанием задач и результата. Если продукт уже существует и вы выбираете подрядчика на развитие — начните с аудита кода: он показывает реальное состояние проекта до того, как вы согласуете бюджет доработок.
Чек-лист заказчика: в ходе работ
После подписания договора управление бюджетом превращается в рутину: короткая регулярная проверка вместо больших разбирательств раз в квартал. Задача заказчика на этой стадии — видеть отставание в тот момент, когда оно ещё измеряется днями.
Ритм отчётности
- Одна встреча в неделю с фиксированной повесткой. Что сделано, что в работе, что мешает, есть ли отклонение от контрольной точки.
- Письменное резюме после каждой встречи. Решения, принятые голосом и не записанные, через месяц перестают существовать для обеих сторон.
- Демонстрация работающего продукта, а не скриншотов. Промежуточная версия на реальном устройстве показывает состояние проекта честнее любого отчёта.
Что запрашивать у подрядчика
- Отчёт по израсходованным часам в разрезе задач — при оплате по факту это основной инструмент контроля.
- Список открытых дефектов с приоритетами. Растущий список при неизменной скорости исправления — ранний признак сдвига даты.
- Статус интеграций отдельной строкой. Именно здесь проекты чаще всего теряют недели, и именно эту строку обычно не показывают.
- Перечень принятых изменений с их стоимостью. Сумма мелких доработок должна быть видна нарастающим итогом, а не всплывать в счёте.
Что зависит от вас
- Один ответственный со стороны бизнеса. Когда согласуют пять человек с разными мнениями, срок согласования умножается на пять.
- Согласование в оговорённый срок. Каждый день ожидания макета — день, который команда потратит на что-то другое, а вернётся к задаче с переключением.
- Дисциплина изменений. Хорошая идея, пришедшая на середине разработки, попадает в список следующей версии, а не в текущий объём.
- Готовность данных к нужному этапу. Каталог, тексты, фотографии и доступы к внешним системам передаются по графику, а не в неделю приёмки.
Если хочется перевести контроль в цифры, посмотрите 15 метрик разработки: там разобраны показатели скорости, качества и предсказуемости, по которым состояние проекта видно без погружения в код.
Чек-лист заказчика: перед запуском и в первые недели
Последний отрезок проекта опаснее для срока, чем середина: работы почти закончены, ощущение готовности высокое, а впереди приёмка, модерация в сторах и первые обращения пользователей. Каждый из этих шагов занимает время, которое редко попадает в исходный план.
Приёмка
- Сценарии проверяются по списку из договора, а не по общему впечатлению от продукта.
- Проверка идёт на реальных устройствах разных моделей и версий операционных систем, включая недорогие смартфоны вашей аудитории.
- Замечания сводятся в один список с приоритетами и передаются целиком, а не по одному сообщению в мессенджере.
- Отдельно проверяются платежи и обмен данными с учётной системой — на боевых настройках, а не на тестовых.
Как устроена проверка со стороны команды и что входит в её объём, подробно разобрано в материале о тестировании мобильных приложений.
Публикация в сторах
- Аккаунты разработчика оформлены заранее. Регистрация юридического лица в сторах занимает время и требует документов.
- Материалы карточки готовы до подачи: иконка, скриншоты, описание, политика конфиденциальности, возрастной рейтинг.
- В графике заложено время на модерацию и возможные замечания. Требования площадок опубликованы: правила проверки App Store и чек-лист запуска Google Play.
- Определён список сторов под аудиторию проекта: App Store, Google Play, RuStore и другие площадки по запросу.
Первые недели после запуска
- Кто и как быстро отвечает на обращения пользователей и отзывы в сторах.
- Кто отслеживает сбои и ошибки и по какому порядку они попадают в работу.
- Что относится к гарантии, а что — к развитию продукта. Разделение должно быть согласовано до запуска, иначе первый же спор съест неделю.
Расходы этой стадии обычно недооценивают: во что обходится сопровождение и из чего оно складывается, разобрано в материале про стоимость поддержки приложения после запуска.
Что реально сдвигает срок
Опоздания редко возникают из-за того, что разработчики пишут код медленнее плана. Три причины дают основную часть сдвига, и все три поддаются подготовке заранее.
Интеграции с внешними системами
Приложение обменивается данными с учётной системой, платёжным сервисом, службой доставки, программой лояльности. Скорость этого этапа определяется не вашей командой и не подрядчиком, а тем, есть ли у поставщика этих систем готовые методы обмена данными и кто отвечает за доступы. Когда методы уже есть, подключение — предсказуемая работа. Когда их нужно разрабатывать на стороне поставщика, срок зависит от очереди в чужой компании. Проверьте это до старта: одного письма поставщику учётной системы достаточно, чтобы понять, с чем имеете дело.
Контент и данные каталога
Каталог на десятки тысяч позиций, описания, фотографии, характеристики, соответствие категорий — всё это готовит бизнес, и всё это нужно раньше, чем кажется. Продукт без данных нельзя ни толком протестировать, ни показать на приёмке. Практика показывает, что подготовка каталога занимает больше времени, чем разработка экрана, который его показывает.
Согласования на стороне заказчика
Между «макет отправлен» и «макет согласован» лежит время, за которое подрядчик не отвечает, но которое входит в календарный срок проекта. Помогает одно правило: один ответственный, оговорённый срок ответа, письменное решение. Если согласование действительно требует нескольких служб, заложите это в график открыто, а не надейтесь на скорость.
Сколько стоит подготовка проекта и какой резерв закладывать
Цена подготовительных шагов
Работы, которые снижают риск перерасхода, стоят на порядок меньше самой разработки и оцениваются фиксированной суммой. Разработка технического задания начинается от 80 000 ₽: в эту сумму входят описание сценариев и экранов, требования к интеграциям и структура данных, по которым дальше считается смета; не входят дизайн-макеты и разработка. Оценка уже работающего продукта перед планированием бюджета на развитие — аудит мобильного приложения от 60 000 ₽ и от 7 дней, на выходе — отчёт по состоянию кода, интерфейса и метрик с перечнем работ; внедрение исправлений в эту сумму не входит.
Для ориентира по самой разработке: по нашей оценке рынка бюджет крупного заказного e-commerce-продукта с нуля начинается от 5–10 млн ₽ и предполагает собственную команду сопровождения после запуска. Запуск на готовой платформе устроен иначе: единоразовая интеграция под бренд с известной стоимостью, ежемесячный лицензионный платёж с включённой поддержкой и отдельная оплата доработок сверх базового набора. Актуальные цифры по пакетам держим в одном месте — на странице тарифов.
Статьи расходов вне сметы подрядчика
Резерв — это не подушка «на всякий случай», а деньги под предсказуемые статьи расходов, которые обычно не попадают в смету подрядчика, потому что не относятся к разработке. Заложите их сразу, и бюджет перестанет выглядеть сорванным там, где он был неполным. Разбор самой стоимости разработки — по каким факторам она меняется и как её уменьшить без потери качества — вынесен в отдельный материал о стоимости разработки.
| Статья расхода | Что это | Когда возникает |
|---|---|---|
| Аккаунты разработчика в сторах | Регистрационные взносы площадок, оформляются на юридическое лицо заказчика | До подачи приложения на модерацию |
| Серверы, домены, сертификаты | Инфраструктура, на которой работает серверная часть продукта | С этапа разработки и далее ежемесячно |
| Платные внешние сервисы | Эквайринг, рассылки, карты, аналитика, антифрод — по тарифам поставщиков | С запуска и далее по обороту |
| Контент и съёмка | Фотографии товаров, описания, тексты интерфейса на стороне бизнеса | До приёмки |
| Доработки после первых недель работы | Изменения, которые становятся очевидны, когда продуктом пользуются реальные покупатели | Первые два-три месяца после запуска |
| Привлечение пользователей | Реклама и продвижение установок — отдельный бюджет, не связанный с разработкой | С запуска |
По нашему опыту разумный ориентир резерва на первый год — 15–20% сверх стоимости разработки: примерно столько уходит на доработки по итогам первых недель эксплуатации и на обновления под новые версии операционных систем. Если продукт работает на платформе, часть этих расходов уже включена в ежемесячный платёж: техническая поддержка, мониторинг и обновления модулей входят в лицензию, а по фактическим часам считаются только новые сценарии сверх базового набора. Для продуктов, сделанных другим подрядчиком, сопровождение оформляется отдельной услугой — технической поддержкой приложений.
Сводка: что чаще всего ломает план
Соберём наблюдения в одну таблицу — её удобно взять на встречу с подрядчиком и пройти по строкам вместе.
| Что произошло | Чем оборачивается | Что предотвращает |
|---|---|---|
| Оценка дана по короткому описанию продукта | Сумма пересматривается на середине проекта | Техническое задание или детальный перечень работ до договора |
| Изменения принимаются устно | Объём растёт незаметно, спор о причинах в конце | Письменный порядок изменения объёма с оценкой каждого запроса |
| Контрольных точек нет | Отставание видно за две недели до даты | Промежуточные точки с признаками готовности |
| Интеграции оставлены на конец | Срок зависит от очереди в чужой компании | Проверка готовых методов обмена данными до старта работ |
| Тестирование сжато в последнюю неделю | Дефекты находят пользователи, исправления идут в авральном режиме | Проверка идёт параллельно разработке, а не после неё |
| Расходы после запуска не заложены | Продукт запущен, а развивать его не на что | Резерв на сопровождение и доработки первого года |
Строки таблицы пересекаются с типичными управленческими промахами при заказе разработки — они собраны отдельно в материале про ошибки заказчика при разработке мобильного приложения.
Как срок и бюджет закреплены в нашей модели работы
Модель FITTIN состоит из трёх частей. Первое — единоразовая интеграция платформы под ваш бренд. Второе — ежемесячные лицензионные платежи, в которые уже включены затраты на техническую поддержку команды FITTIN. Третье — доработки нового функционала по Time & Materials со сметой и оценкой по часам перед стартом задачи.
Для бюджета и срока это означает три конкретные вещи. Стоимость и срок интеграции известны до начала работ: запуск занимает до 30 рабочих дней, потому что каталог, корзина, оплата, личный кабинет, программа лояльности и уведомления уже разработаны и проверены на действующих проектах — их настраивают под бренд, а не пишут заново. Сопровождение не превращается в отдельный счёт после запуска: мониторинг, обновления модулей и обновления безопасности входят в ежемесячный платёж. Уникальные сценарии считаются отдельно и всегда до старта задачи, так что расширение продукта — это решение бизнеса с известной ценой, а не сюрприз в конце месяца. Обновления сторонних сервисов — платёжных, учётных, маркетплейсов — тоже относятся к отдельным работам, и это стоит учитывать при планировании года.
Платформа устроена как конструктор: любой из модулей можно доработать под сценарий конкретного бизнеса, поэтому короткий срок запуска не означает фиксированного набора возможностей. Сама платформа включена в реестр российского ПО под номером 2487103, а единая кодовая база на Flutter для приложения и сайта даёт дополнительный эффект для бюджета: исправленный сценарий не нужно оплачивать дважды — отдельно для веба и отдельно для мобильного приложения. Направления описаны на страницах мобильных приложений для интернет-магазинов, сайтов для интернет-магазинов и связки сайта и приложения под ключ, а цифры по пакетам — на странице тарифов.
Когда продукт выходит за рамки готовых модулей — корпоративная система, B2B-сервис, уникальная бизнес-логика, — работа идёт как заказная разработка с оценкой по объёму. Если задача в том, чтобы усилить свою команду на время проекта, а не передавать его целиком, есть отдельный формат — аутстаффинг Flutter-разработчиков с включением за несколько дней.
Кейсы: где план и факт сошлись
Три проекта, где ограничение по бюджету или сроку было условием задачи. Метрики приведены со страниц кейсов.
Finn Flare — перезапуск вместо поддержки двух приложений
Бренд одежды перезапустил мобильное приложение на Flutter вместо развития двух отдельных продуктов под iOS и Android. Со страницы кейса: бюджет разработки оказался в 2,5 раза меньше, а скорость разработки — в 1,5 раза выше. Механика простая: одна кодовая база вместо двух означает один набор работ на каждое изменение, а не два.
Сатурн — 30 000 товаров и 20 городов в одном приложении
Со страницы кейса «Сатурн»: каталог свыше 30 000 товаров и корректная работа приложения во всех 20+ городах присутствия сети — с городскими ценами, наличием и условиями доставки. Такой объём данных и региональная логика — как раз тот случай, когда подготовка каталога и правил на стороне бизнеса идёт параллельно разработке, иначе она становится узким местом на приёмке.
Сыроварня — полнофункциональное приложение сети ресторанов за 2 месяца
Сеть ресторанов получила приложение, в котором одновременно работают меню, заказ и доставка, бронирование столиков с привязкой к заведениям сети, программа лояльности и раздельная оценка визитов, блюд и ресторанов. Со страницы кейса: запуск занял 2 месяца. Срок здесь удержан за счёт того, что уникальными проектировались только механики бронирования и оценок, а базовые сценарии заказа и оплаты брались из готовых модулей.
Итог: чек-лист на одной странице
Бюджет и срок держатся не на жёсткости договора, а на том, насколько подробно описан объём и насколько регулярно стороны сверяют план с фактом. Короткий порядок действий, который закрывает большую часть причин перерасхода:
- Опишите продукт до разговора о цене. Экраны, сценарии, интеграции, роли, целевые платформы — этот список и есть предмет договора.
- Требуйте смету по задачам с ролями и часами. Итоговая цифра без состава работ не поддаётся проверке и сравнению.
- Зафиксируйте порядок изменений и контрольные точки. Изменения будут в любом проекте; управляемыми их делает письменная процедура.
- Ведите недельный ритм и один список замечаний. Отставание, замеченное в днях, исправляется днями.
- Заложите резерв на статьи вне сметы подрядчика. Сторы, инфраструктура, внешние сервисы, доработки первых месяцев.
Для бизнеса, которому нужен работающий канал продаж в понятный срок, оптимальный сценарий — модель с фиксированной интеграцией и известным ежемесячным платежом: она снимает неопределённость по базовой части продукта и оставляет открытой возможность дорабатывать уникальные сценарии по мере роста.
Что делать дальше:
- Прикинуть срок и бюджет под свой набор функций — калькулятор стоимости разработки.
- Описать продукт документом, по которому можно считать и принимать работу, — разработка технического задания.
- Оценить состояние работающего продукта до планирования бюджета на развитие — аудит мобильного приложения от 7 дней.
- Посмотреть, как задачи решались на других проектах, — кейсы, или обсудить свой через контакты.
Вопросы и ответы
Почему стоимость разработки приложения растёт в процессе работы?
Основных причин две. Первая — объём работ был описан общими словами, и детали выясняются по ходу: у экрана оказывается пять состояний вместо одного, у каталога — нестандартные правила цен. Вторая — изменения, которые принимались устно и не оценивались отдельно. Обе решаются одинаково: детальный перечень работ до договора и письменный порядок, по которому новая задача попадает в проект вместе с оценкой её стоимости и влияния на дату.
Сколько времени занимает разработка мобильного приложения?
Срок зависит от того, пишется продукт с нуля или разворачивается на готовой платформе. Крупный заказной продукт занимает 120–250 рабочих дней до первой версии. Интеграция готовой платформы под бренд с настройкой модулей, подключением учётной системы и оплаты и публикацией в сторах занимает до 30 рабочих дней. На обоих сценариях срок сдвигают одни и те же вещи: готовность данных и контента, скорость согласований на стороне бизнеса и наличие готовых методов обмена данными у внешних систем.
Что выбрать — фиксированную цену или оплату по часам?
Фиксированная цена подходит, когда объём описан детально и меняться не будет: вы знаете сумму заранее, но каждое изменение проходит через дополнительное соглашение и сдвигает дату. Оплата по фактическим часам подходит для исследовательских задач и для доработок работающего продукта: продукт можно менять по ходу, но итоговая сумма проекта заранее не фиксируется. На практике часто выигрывает сочетание: фиксированная стоимость на понятную часть работ и оплата по часам на доработки, которые появятся после запуска.
Какой резерв закладывать сверх стоимости разработки?
По нашему опыту ориентир на первый год — 15–20% сверх стоимости разработки. Эти деньги уходят на доработки по итогам первых недель эксплуатации и на обновления под новые версии операционных систем. Отдельно от резерва планируются расходы, которые не относятся к разработке: регистрационные взносы аккаунтов в сторах, серверы и домены, платные внешние сервисы вроде эквайринга и рассылок, подготовка контента и бюджет на привлечение пользователей.
Что должно быть в договоре на разработку приложения?
Помимо предмета и цены — пять пунктов, от которых зависит управляемость проекта: перечень работ приложением к договору, контрольные точки с признаками готовности, порядок изменения объёма с оценкой каждого запроса, условия приёмки со сроками на замечания и исправления, гарантийный период с описанием того, что в него входит. Отдельно стоит прочитать пункты об аккаунтах в сторах и о правах на результат работ — здесь условия у подрядчиков различаются.
Кто отвечает за срыв срока — подрядчик или заказчик?
Ответственность распределяется по графику. За скорость своих работ отвечает подрядчик, за передачу данных, доступов и согласований в оговорённые сроки — заказчик. Поэтому в графике должны быть отражены обе стороны: если согласование макетов занимает у бизнеса десять рабочих дней, это часть календарного срока проекта, а не форс-мажор. Практика показывает, что заметная доля сдвигов приходится именно на ожидание ответов и данных со стороны заказчика.
Как проверить смету на разработку, если нет технического образования?
Проверяется не техническая часть, а структура документа. Смета должна быть разбита по задачам, а не сведена в одну строку; у каждой задачи указаны роль и количество часов; отдельными строками показаны тестирование, приёмка и интеграции. Дальше сравнивайте предложения по составу работ, а не по итоговой сумме: более низкая цифра обычно означает более узкий объём. Если продукт уже существует и речь о его развитии, независимую оценку состояния даёт аудит кода.
Во сколько обходится приложение после запуска?
После запуска расходы делятся на три части: инфраструктура и платные внешние сервисы, сопровождение продукта и развитие функциональности. На платформе сопровождение входит в ежемесячный лицензионный платёж — мониторинг, обновления модулей и обновления безопасности; новые сценарии сверх базового набора считаются по фактическим часам со сметой до старта задачи. Для продукта, сделанного другим подрядчиком, сопровождение оформляется отдельной услугой, а объём и формат определяются после аудита.
Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации.
