Оценка, которой можно верить: как читать смету на автоматизацию
"Разработка - от 150 до 400 часов" - это не оценка, а надежда. Разбираю с позиции заказчика, что должно быть в смете на автоматизацию, чтобы её можно было проверить: одна вилка, буфер отдельной строкой, чужая зона ответственности вне часов и четыре вопроса подрядчику.

Собственник получает от подрядчика оценку: "Разработка - от 150 до 400 часов". Что с этим делать, непонятно. Разброс в два с половиной раза, из чего он складывается - неизвестно, а торговаться не о чем: цифра монолитная.
Я пишу такие оценки регулярно - и для крупного заказчика с проектным офисом, и для небольших клиентов. За это время сложился набор требований к документу, и почти все они на самом деле нужны не исполнителю, а тому, кто платит. Разберу их с позиции заказчика: что должно быть в оценке, чтобы её можно было проверить.
Одна вилка, а не три
Самый частый дефект - несколько чисел в одном документе. В шапке "ориентировочно 200 часов", в тексте "чистой работы дней двадцать", в таблице сумма даёт 260, а в письме звучит "ну, месяца полтора".
Каждое из этих чисел получено по-своему, и ни одно не отвечает за остальные. Разговор об объёме превращается в спор о том, какую цифру считать настоящей.
Правило простое: в документе ровно одна вилка, и она везде одинаковая. Строки таблицы обязаны суммироваться ровно в итог. Если подрядчик не может сложить свою же смету - он не разобрал задачу, а прикинул на глаз.
Буфер - отдельной строкой
В любой оценке есть неизвестное: чужой сервис поведёт себя не так, данные окажутся грязнее, чем обещали, вылезет ошибка в стороннем модуле. Это нормально, и на это закладывается запас.
Ненормально - когда запас растворён внутри строк. Тогда каждая позиция выглядит раздутой, заказчик начинает резать по живому, а подрядчик защищает воздух, не называя его вслух.
Честный формат: строки - реальное время работы, буфер - отдельная строка процентом от итога. Я обычно закладываю тридцать процентов и пишу это прямым текстом. Тогда торг идёт предметно: можно обсуждать риск, а можно сознательно его снять и работать без запаса, понимая последствия.
Отдельно: если заказчик сам называет потолок ("у нас девять часов, больше нет"), буфер не добавляется, а под цифру подгоняется объём работ. Это его право - решать, сколько задача стоит. Задача подрядчика - честно сказать, что в эти часы влезет, а что нет.
Реальные часы, а не "стандарт-разработчик"
Я оцениваю фактическое время связки инженер плюс ИИ-ассистент - то, за сколько работа реально будет сделана. Без пересчёта на условного среднего разработчика и без накруток "потому что бывает всякое".
Для заказчика это важнее, чем кажется. Оценка в реальных часах проверяема: по факту сдачи видно, попал подрядчик или нет, и следующая оценка от него стоит дороже или дешевле доверия. Оценка в абстрактных единицах непроверяема никогда.
Что не входит в часы
Отдельный раздел, которого почти никогда нет, а он самый ценный. В любом проекте есть работа, которая часами не измеряется, потому что зависит не от исполнителя:
- ожидание доступов;
- чужой сервис, который должен доработать другая команда;
- регламентные окна выкатки;
- согласования на стороне заказчика.
Это не часы, это календарь. Смешивать их с трудозатратами нечестно в обе стороны: подрядчик либо прячет простой в свои часы, либо потом объясняет, почему "двадцать часов работы" заняли месяц. Гораздо честнее написать отдельно: вот наши часы, вот зона вашей ответственности, вот от чего зависит срок.
Опциональное - вне итога
В любой задаче есть "хорошо бы ещё": вторая интеграция, админка для настройки, отчётность. Место этому - отдельная строка с пометкой, что в основной объём оно не входит.
Когда желательное подмешано к обязательному, заказчик платит за то, чего не заказывал, а подрядчик получает вечно растущий скоуп. Разделение снимает обе проблемы и, что важно, даёт заказчику управление: пилот сегодня, расширение - после того как первый этап себя оправдал.
Почему всё таблицей и почему в конце
Две мелочи, которые сильно влияют на восприятие.
Всё, что можно, - таблицей: блок работ, объём, комментарий, итоговая строка. Прозаический вывод в конце ("в целом, думаю, недели три") не нужен: итог - это строка таблицы, и она одна.
А сама оценка идёт в конце документа, а не в начале. Сначала разбор задачи: что понято, какие есть развилки, что предлагается делать и почему. Тот, кто принимает решение, всё равно листает в конец - но, дойдя туда, он уже видит, за что именно платит. Оценка, поставленная первой строкой, читается как ценник без товара.
Что забрать себе
Когда получаете оценку, задайте четыре вопроса. Они безошибочно отделяют разобранную задачу от прикидки на глаз:
- Складываются ли строки в итог?
- Где буфер и сколько он?
- Что в этом сроке зависит не от вас?
- Что из перечисленного можно не делать в первом этапе?
Если подрядчик отвечает на все четыре не задумываясь - он задачу разобрал. Если начинает объяснять, что "так не считают" - вы держите в руках не оценку, а надежду.
Новые разборы - на почту
Разборы задач автоматизации: что автоматизировать, сколько это стоит и что даёт в цифрах. Одно письмо на статью, без рекламы чужих продуктов.


