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

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


