ru

Чек-лист предложения на разработку: что в нём должно быть?

Короткий ответ

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

Используйте список ниже как оценочный лист, а не как список пожеланий. Отметьте каждый пункт: отвечено, отвечено частично, отсутствует. Колонка «отсутствует» и есть результат: это одновременно ваш список вопросов подрядчику и — если подрядчиков двое — единственное основание, на котором их предложения вообще можно сравнивать.

Как это выглядит на практике

Основатель попросил трёх подрядчиков дополнить сметы «недостающими пунктами» из этого списка. Двое вернулись с ценой примерно на 20% выше и заметно более длинным документом. Третий ответил, что на этой стадии вопросы неактуальны, и смету не менял. Этот ответ оказался самой полезной информацией во всей закупке.

Чек-лист

Объём: включено, исключено и промежуток между

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

Владение — критично

Владение кодом, репозиторием и инфраструктурой, где в ответе стоит сторона, а не настроение. «Клиент», «подрядчик», «совместно» и «эскроу» — рабочие варианты; нерабочий только один: «не указано».

Передача прав — критично

Когда переходят права: по оплате, по завершении или никогда. И что именно переходит: реализация под конкретного клиента — это не то же самое, что все компоненты, которые подрядчик переиспользовал.

Условия выхода — критично

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

Резервные копии и данные

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

Деньги во времени

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

Поддержка, SLA и ответственность за безопасность

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

Зависимости, допущения и заявленные риски

Что подрядчик ждёт от вас, из чего он исходил, называя эту цену, и что, по его мнению, может пойти не так. Все три — признак предложения, написанного тем, кто уже что-то сдавал.

Приёмка, тестирование и документация

Как вы поймёте, что работа закончена. Критерии приёмки, какое тестирование входит и какую документацию вы получаете — три вещи, которые чаще всего подразумевают и реже всего записывают.

Чего этот ответ не покрывает

  • Полное предложение не гарантирует хорошего результата. Оно гарантирует, что вы с подрядчиком расходитесь в меньшем числе вопросов, чем разошлись бы иначе.
  • Не каждый пункт применим к каждому проекту. Небольшому внутреннему инструменту не нужны условия выхода, о которых стоит торговаться. Регулируемой инвестиционной платформе — нужны.
  • Веса важнее количества. Двадцать отвеченных вопросов при пяти неотвеченных критических — документ слабее, чем пятнадцать отвеченных, включающих все пять.
  • Список о том, что должно быть в предложении, а не о том, что должен уметь продукт. Функциональные требования — отдельный документ, и если его нет, это и есть находка.