← Назад в блог

Я перестал считать часы. Вот как я оцениваю проекты теперь

Когда клиент спрашивает «сколько это стоит?», стандартный ответ — считать часы. Умножить на ставку. Прибавить 20% буфер. Написать число.

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

Почему оценка в часах — это оценка не того

Hofstadter's Law звучит так: «Всё занимает дольше, чем ожидаешь — даже если учитываешь Hofstadter's Law». Это не про прокрастинацию. Это про то, что неопределённость в проектах нельзя устранить, добавив буфер.

Часы — это стоимость при условии, что всё пойдёт по плану. Но планы проектов с legacy-кодом не выполняются. Не потому что разработчики медленно работают, а потому что часть работы не видна до тех пор, пока не начнёшь копать.

В одном проекте мы оценили интеграцию Bitrix с внешней 1С в 40 часов. По факту вышло 130. Нет, не потому что «разработчик не умел». А потому что API 1С оказался задокументирован в формате «как нам удобно», а не как обещано. Это не было видно на пресейле. Это риск.

Часы — это ответ на вопрос «как долго?». Риск — это ответ на вопрос «что может пойти не так?». Это разные вопросы.

Три типа риска, о которых не спрашивают на пресейле

Я делю риски на три блока.

Первый — технический. Насколько хорошо я понимаю кодовую базу? Есть ли документация? Насколько предсказуемы внешние API?

Второй — организационный. Кто принимает решения у клиента? Один человек или комитет? Бывало ли, что клиент «пропадал» на две недели в середине задачи?

Третий — scope. Мы оба одинаково понимаем, что входит в работу? У клиента есть список требований или только «концепция»?

Эти три блока я смотрю до того, как беру калькулятор.

Мой чеклист: девять вопросов до цифры в коммерческом предложении

Вот вопросы, которые я задаю на пресейле перед любой оценкой стоимости IT-проекта — или про себя, или прямо клиенту:

  1. Есть ли у меня доступ к коду до оценки, или я оцениваю «по описанию»?
  2. Работал ли кто-то с этим кодом за последние 6 месяцев, или он «стоит»?
  3. Есть ли внешние интеграции с закрытым или плохо задокументированным API?
  4. Кто будет принимать финальное решение по ТЗ на стороне клиента?
  5. Есть ли хардовый дедлайн — или «желательно побыстрее»?
  6. Это greenfield или рефакторинг существующего?
  7. Клиент уже работал с разработчиками на этом проекте? Чем закончилось?
  8. Есть ли тесты, или я первый кто об этом думает?
  9. Что произойдёт с бизнесом, если мы выйдем за дедлайн на три недели?

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

Что бывает, когда пропускаешь чеклист

Два года назад я получил запрос: добавить на Bitrix-сайт личный кабинет с фильтрацией заказов. Задача казалась понятной. Я дал оценку сразу, без вопросов.

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

Проект занял в 2.8 раза дольше, чем я оценил. Клиент остался доволен результатом, но раздражён сроками. Я остался раздражён собой — потому что риск был видим, просто я не смотрел.

Если бы я задал вопрос 2 из чеклиста, я бы узнал, что код «стоит» с прошлого квартала, и задал бы дополнительные вопросы. Оценка была бы другой.

Красный, жёлтый, зелёный

После чеклиста я присваиваю проекту или крупной задаче цвет:

Зелёный — хорошо понимаю что делать, технический риск низкий, клиент понимает scope. Оцениваю в часах с небольшим буфером.

Жёлтый — есть 1–2 неизвестных. Оцениваю в диапазоне (минимум/максимум), явно называю что именно неизвестно и когда это прояснится.

Красный — слишком много непредсказуемого. Предлагаю discovery-фазу (платную) вместо оценки всего проекта. Или отказываюсь.

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

Отказался от $40K-контракта именно потому, что проект был красным: предложение переписать Bitrix-монолит без понимания, что реально тормозит. Подробнее в том посте.

AI-инструменты сломали старые формулы

В 2023 году AI-ассистенты начали реально менять скорость на некоторых задачах. Типичный случай: задача, которая раньше стоила 20 часов рутинного кода, теперь стоит 6. Но это не значит, что весь проект стал в 3 раза дешевле.

Парадокс: там где AI ускоряет написание кода — QA-хвост остаётся или увеличивается. Потому что AI пишет уверенно, но не всегда правильно. Я видел, как задача «написать интеграцию с API», оценённая через старую формулу в 15 часов, с AI-ускорением заняла 5 часов кода и 10 часов проверок.

Вывод: AI меняет распределение, но не убирает риск. Чеклист стал важнее, не менее важным.

Когда я отказываюсь на этапе оценки

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

  • Клиент не может ответить на вопрос «кто принимает решения по ТЗ»
  • «У нас есть ТЗ» — а при прочтении это список желаний без приоритетов
  • Предыдущий подрядчик «пропал», и клиент не понимает почему
  • Проект уже начинали и остановили — без чёткого объяснения почему

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

Считать часы — это не ошибка. Это просто последний шаг, а не первый. Сначала — риск. Потом — цвет. Потом — часы.

Если на вашем проекте сейчас кто-то нервно считает часы, не спросив ни одного из девяти вопросов — стоит остановиться. Лучше задержаться на пресейле, чем объяснять клиенту, почему дедлайн сдвинулся.

Смежная история про конкретный риск, от которого я ушёл: как я закрываю риски, а не тикеты.