Сколько стоит первая версия и от чего зависит оценка

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

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

1. Из чего на самом деле складывается число

Начните со сценариев. Сценарий — это то, что человек доводит до конца: лид становится клиентом, заказ превращается в оплату, а потом в отгрузку, сотрудник отправляет запрос, который руководитель принимает. У каждого сценария есть цепочка экранов, правил, состояний и прав доступа.

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

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

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

2. Внешний мир дороже внутреннего

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

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

3. Кто поставляет материалы, меняет число

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

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

4. Почему две оценки по одному брифу расходятся

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

Разницу можно найти. Спросите, что каждая оценка включает, а полезнее — что она исключает. Число, вокруг которого ничего не названо, — надежда с датой. Вопросы, отделяющие одно предложение от другого, всегда про внешние системы, роли, недостающие материалы и состояния, где что-то пошло не так. Ответьте на них один раз письменно, и дальше любые предложения сравнимы: они отвечают на одни и те же вопросы.

5. Как работа оплачивается на самом деле

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

Так число становится предсказуемым, но не фиксированным. Вы знаете цену следующего шага до того, как он начался. Можно остановиться после любого среза и оставить себе то, что уже работает. Изменение становится новой строкой со своей цифрой, а не пересмотром всей работы. И первая версия остаётся маленькой намеренно: в production уходит один сценарий, архитектура решается до кода, и остальное ложится поверх работающего.

6. Вопросы, делающие число предсказуемым

Задайте их до того, как кто-то что-то пообещает, письменно, и держите ответы рядом с предложением:

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

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

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