В заказной разработке я все меньше верю в «красивые» корпоративные калькуляторы оценки, где к разработке автоматически докидываются проценты на тестирование, тимлида, РП, аналитику, управление и прочие роли.

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

Почему?

Потому что фича — это не только «написать код».

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

И вот здесь у меня появляется главный вопрос к процентным коэффициентам.

Если разработчик оценил фичу в 80 часов, почему тестирование автоматически должно быть, например, 20%? А если там сложная бизнес-логика, много интеграций, нестабильные требования и несколько ролей пользователей? А если тимлиду нужно не «чуть-чуть посмотреть», а полноценно погрузиться в архитектуру, ревью и риски? А если РП придется не просто «вести проект», а постоянно держать в руках заказчика, ожидания, бюджет, сроки, риски и коммуникации?

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

При этом я считаю, что РП должен доверять оценке команды.

Но доверять — не значит слепо переносить ее в КП или план-график.

Команда оценивает работу из своей профессиональной картины мира. РП обязан добавить управленческий слой: риски, буферы, зависимости, приемку, коммуникации, неопределенность, возможные возвраты и человеческий фактор.

Оценка команды отвечает на вопрос: «Сколько нам нужно, чтобы сделать?» Оценка РП должна отвечать на другой вопрос: «Сколько нам реально нужно, чтобы довести это до результата, который примет заказчик?» И это разные вопросы.

Мое наблюдение: в заказной разработке опаснее всего продавать проект по «голой» оценке команды и калькулятору без критического пересмотра. На старте это выглядит конкурентно. А потом проект начинает добирать реальность через переработки, срывы сроков, падение маржинальности и конфликты ожиданий.

Калькулятор может быть инструментом. Но он не должен подменять управленческое мышление.

Коллеги, а как вы с этим работаете: доверяете процентным коэффициентам или тоже чаще пересчитываете трудозатраты вручную?