Коммерческое предложение на доработку чужого проекта: что писать и как считать
Доработка существующего продукта отличается от разработки с нуля одним: команда не знает, что именно ей досталось. Код писали другие люди, документации обычно нет, а решения внутри проекта принимались по причинам, которые уже никто не помнит. Оценить объём работ по описанию задачи в такой ситуации нельзя — оценка появляется только после того, как проект развернули, посмотрели в код и проверили, как он собирается. Поэтому предложение строится не вокруг списка доработок, а вокруг порядка: сначала погружение, потом обоснованная смета.
Вторая сложность — ответственность. Заказчик воспринимает нового подрядчика как хозяина продукта целиком и приносит ему все ошибки, включая унаследованные. Если границы не описаны в предложении, разбирательство «это ваша правка сломала или оно уже было» превращается в бесплатную работу. В документе нужно прямо разделить: что команда меняет по заданию, за что отвечает после изменений и что относится к прежнему состоянию системы и оценивается отдельно.
Из каких блоков собрать предложение
Опишите систему словами заказчика: назначение, аудитория, где размещена, кто вёл разработку раньше и когда работы остановились. Отдельно зафиксируйте, что состав и качество кода на момент подготовки предложения не проверялись, если доступов ещё не было.
Перечислите, что нужно получить до старта: репозиторий с историей, доступы к серверам и панели хостинга, база данных, домен, учётные записи внешних сервисов и платёжных систем, ключи интеграций. Укажите, что получение доступов от прежнего подрядчика — зона ответственности заказчика, и до их передачи работы не начинаются.
Опишите отдельный оплачиваемый этап: развернуть проект на своей среде, разобрать структуру кода и базы, проверить сборку и зависимости, выявить критичные места. Результат этапа — отчёт о состоянии проекта, перечень рисков и уточнённая оценка доработок, а не сами доработки.
Разложите задачи списком с оценкой в часах и порядком выполнения. Разделите обязательные работы по приведению проекта в рабочее состояние и новую функциональность, которую хочет заказчик, — это разные бюджеты и разные сроки.
Прямо укажите, что команда отвечает за код, который написала сама, а дефекты прежней разработки исправляются как отдельные задачи по согласованной оценке. Опишите, что при отказе заказчика от рефакторинга критичных участков команда фиксирует риск письменно и продолжает работу в текущей архитектуре.
Дайте ставку за час работы по ролям и оценку каждой задачи в часах, либо стоимость спринта фиксированной длительности. Для проектов с непредсказуемым состоянием кода честнее почасовая модель с потолком бюджета на этап, чем фиксированная цена по неизученной системе.
Опишите тестовую и боевую среды, порядок выкладки изменений, окно для релиза и правило отката. Укажите, что и в каком виде передаётся по завершении: репозиторий, инструкция по развёртыванию, описание внесённых изменений.
Что обычно входит в смету
- Развёртывание проекта на локальной и тестовой средеэтап
- Аудит кода, зависимостей и структуры базы данныхчас
- Отчёт о состоянии проекта и перечне рисковдокумент
- Восстановление сборки и обновление устаревших зависимостейчас
- Исправление унаследованных дефектов по согласованному спискузадача
- Доработка функциональности по заданиючас
- Рефакторинг критичных участков кодачас
- Перенос проекта на инфраструктуру заказчикаэтап
Блоки, смета с расчётом и условия уже готовы — останется вписать свои цены. Клиент открывает ссылку в браузере, а вы видите, кто её открыл и докуда дочитал.