Как оценить стоимость разработки и почему “там же на пару часов” почти никогда не пара часов

Есть одна фраза, которую разработчики слышат регулярно: «Да там же вроде на пару часов работы». Обычно речь идёт о чём-то действительно небольшом с точки зрения клиента – добавить кнопку, новое поле в форме, поменять расчёт,
подключить интеграцию или чуть-чуть изменить существующий функционал.

И я прекрасно понимаю, откуда это берётся. Клиент видит конечное изменение – была одна кнопка, стало две. Логично предположить, что разработчик просто открыл нужный файл, дописал несколько строк, нажал «сохранить» и пошёл пить кофе. Было бы неплохо, конечно.

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

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

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

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

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

Конечно, бывают задачи реально на двадцать минут. Бывают на два часа, и оценка сразу попадает почти идеально. Но если разработчик сначала говорит, что ему нужно посмотреть проект и разобраться в связях, это обычно не попытка раздуть смету – он просто ещё не знает, насколько глубоко закопана та самая «маленькая кнопка».

В разработке вообще довольно забавная математика. Иногда написать нужный код занимает меньше времени, чем понять, какой код вообще нужно написать. И вот как раз за вторую часть работы почему-то чаще всего забывают платить мысленно.