Оценка сроков проекта разработки через карту рисков

Три года назад я отвечал на вопрос «сколько это займёт?» одинаково: открывал Trello, декомпозировал на задачи, ставил story points. Потом суммировал, умножал на velocity, называл срок.

В 40% случаев я горел.

Не потому что плохо декомпозировал. А потому что в legacy-проекте с чужим API задачи — это не главная переменная. Главная переменная — риск.

Теперь я отвечаю иначе. Сначала называю три вещи, которые могут всё сломать. Потом — срок. Клиенты, которых это пугает, — не мои клиенты.

Почему story points дают ложную уверенность

Story points работают, когда у команды есть stable velocity. Когда вы месяц за месяцем знаете: 30 points = 2 недели работы. Это честный инструмент для продуктовой команды с устойчивым бэклогом.

На клиентском проекте с Bitrix-бэком velocity нет. Есть первый спринт и незнакомый код. REST API, у которого нет документации. Хостинг, который не тот, что был на звонке. Каталог из 28 000 SKU с историей импортов из 1С.

Когда ты ставишь 5 points на задачу «получить каталог через API» — ты оцениваешь усилие в идеальных условиях. Ты не закладываешь, что API вернёт 14 разных структур в зависимости от типа товара и что пагинация через offset сломается на 10 000+ записях.

Story points измеряют работу. Риски измеряются отдельно.

Три категории, которые ломают любую оценку

Я проверяю три вещи на каждом проекте до того, как называть срок.

Первое — интеграционный риск. Что мы получаем от внешней системы и насколько ей доверяем? Если бэкенд — Bitrix без документации, я закладываю два-четыре дня только на разведку: Catalog Probe, как я это называю. Прощупать структуру ответов, проверить edge-кейсы, найти узкие места до того, как на них наткнёмся в работе.

Второе — инфраструктурный риск. Какой хостинг, есть ли CI/CD, как сейчас деплоится сайт? Я видел проекты, где «деплой» — FTP и молитва. Настройка нормального pipeline может стоить неделю, которую никто не считал.

Третье — риск требований. Если на вопрос «как работают скидки в каталоге?» клиент отвечает «ну, это сложно» — значит, мы потеряем время на уточнения в середине проекта, а не в начале. Это не повод отказываться от проекта. Это повод посчитать цену неопределённости отдельно.

Как выглядит карта рисков для реального проекта

Пример — headless-перенос для магазина с 28 000 SKU. Next.js + Bitrix. Срок по задачам: 8 недель.

Карта рисков перед стартом выглядела так:

REST API Bitrix: структура неизвестна, документации нет → 3 дня Catalog Probe, буфер +4 дня к интеграции
Каталог: 28 000 SKU, импорт из 1С с историей → риск грязных данных → +2 дня на data-cleansing
Хостинг: шаред, без SSH → нужен переезд → +3 дня инфра
Требования по фильтрам: «как в старом сайте» → неопределённость → +2 дня на UX-согласование

Итого буфер: 11 рабочих дней к изначальным 8 неделям. Я назвал 10,5 недель.

Мы уложились за 10 недель и 2 дня. API действительно вернул 14 разных структур. Catalog Probe обнаружил это на третий день, не на третьей неделе.

Разница в том, что я не ждал, пока риск превратится в проблему. Я заплатил за разведку заранее.

Буфер — это не страховка, это цена неопределённости

Когда я называю буфер клиенту, он иногда слышит «вы берёте запас на свои ошибки». Нет.

Буфер — это стоимость информации, которой у нас пока нет. На знакомом проекте со своим бэком и командой с velocity у меня не будет буфера в 20%. На чужом legacy с незнакомым API — будет.

Это как смета на ремонт. Опытный прораб, который ведёт дом впервые, заложит 15% на «вскрытие стен». Не потому что плохо работает. Потому что стены ещё не вскрыты.

Если клиент не принимает этот аргумент — значит, он ожидает идеальных условий там, где их нет. Это разговор, который лучше иметь до договора, а не после.

Разговор с клиентом: как объяснять, не говоря «мы не знаем»

«Мы не знаем» — плохая формулировка. Она звучит как некомпетентность.

«У нас есть три неизвестные, и вот что мы делаем с каждой» — звучит как контроль.

Я объясняю риски конкретно: «API не документирован — мы тратим 3 дня, чтобы убедиться в структуре, прежде чем строить на ней интеграцию. Это не откладывает старт, это снижает вероятность переделок в середине».

Клиент слышит не «мы боимся» — он слышит «мы управляем рисками». Разница в том, кто контролирует ситуацию.

Проекты, где клиент принял этот подход, — заканчивались в срок или раньше. Проекты, где я соглашался с «давайте без буфера, разберёмся по ходу» — горели в 70% случаев. Не преувеличиваю.

Что изменилось за год

С тех пор как я перешёл на оценку через карту рисков, у меня стало меньше разговоров о переносах и больше разговоров о результате. Клиенты, которые прошли Catalog Probe вместе со мной, понимают, почему срок такой. Они видели данные.

Story points я не выбросил. На внутренних задачах, где стек знаком и команда стабильна, они работают. Но первый вопрос на новом клиентском проекте теперь не «сколько это в points?» — а «что здесь может сломать всё?».

Этот вопрос занимает полчаса. И экономит неделю переделок.

*Внутренние ссылки: Я отказался от $40K-контракта — там тоже было решение на основе риска, не страха. Я перестал закрывать тикеты — стал закрывать риски — о том, что риск-мышление меняет не только оценку, но и ведение проекта.*