— Ну тут работы дня на три, макс, — уверенно сказал ведущий разработчик, поправив очки.
Я кивнул, записал в таск-трекере «3 дня», а внутренний голос тихо засмеялся и поставил мысленную заметку: «ждём через неделю, если повезёт».
Знакомая ситуация? Мы все через это проходили. Эксперты искренне верят в свои оценки, но почему-то реальность постоянно вносит коррективы. И дело не в злом умысле или некомпетентности. Дело в том, как устроено наше мышление.
Но в последнее время меня стал мучить вопрос: мы в 2024 году управляем проектами с помощью Jira, Slack, AI-ассистентов, но оценка сроков до сих пор работает по принципу «спроси у самого опытного и умножь на полтора». Почему мы не можем применить здесь те же технологии, которые используем для написания кода и генерации текстов?
Я решил провести эксперимент.
Почему эксперты ошибаются (спойлер: они не виноваты)
Давай сразу договоримся: я не собираюсь обесценивать экспертизу. Без неё никуда. Но у человеческой оценки есть системная проблема, которая описана даже в PMBOK.
Когда эксперт оценивает задачу, он находится в плену когнитивных искажений:
- Оптимистическое искажение — мы склонны думать, что наша любимая работа пойдёт как по маслу.
- Фокус на «чистом времени» — разработчик считает часы, которые будет писать код, но забывает про согласования, коммуникацию, отвлечения на прод и утренние стендапы.
- Игнорирование «серой зоны» — задачи, которые кажутся типовыми, часто таят в себе подводные камни, о которых эксперт просто не думает в момент оценки.
PMBOK предлагает использовать трёхточечную оценку (оптимистичную, пессимистичную и наиболее вероятную). Но на практике эксперты чаще всего дают только оптимистичную. Потому что хочется быстрее начать, порадовать заказчика или просто не выглядеть пессимистом.
И тут я подумал: а что, если привлечь того, у кого нет этих искажений? Того, кто не хочет никому понравиться и не боится показаться скучным.
Эксперимент: нейросеть в роли оценщика
Я выбрал задачу из текущего спринта. Средней сложности: доработка существующего функционала с изменениями в бэкенде и фронтенде. Всё как мы любим.
Шаг 1. Собрал данные
Чтобы нейросеть могла дать адекватную оценку, ей нужен контекст. Я выгрузил из Jira историю по похожим задачам за последние полгода: описание, фактические трудозатраты, количество задействованных специалистов, этапы согласования.
Шаг 2. Подготовил промпт
Промпт — это 80% успеха. Я не просто спросил «сколько дней», а описал:
- WBS (структуру работ) — разбил задачу на подзадачи.
- Исторические данные — среднее время выполнения аналогичных подзадач.
- Риски — возможные блокировки, зависимости от других команд, согласования с заказчиком.
- Команду — кто будет делать, какой у них уровень, есть ли параллельные задачи.
Шаг 3. Запустил оценку
Использовал локальный GPT, но можно любой аналог. Главное — чётко сформулировать, что я хочу получить не просто цифру, а распределение вероятностей: с какой вероятностью задача займёт X дней, а с какой — Y.
Нейросеть выдала: «Оптимистичная оценка — 5 дней, наиболее вероятная — 7.5 дней, пессимистичная — 11 дней. Основной риск — задержки в коммуникации с заказчиком на этапе приёмки».
Шаг 4. Сравнил с экспертом
Наш ведущий разработчик (тот самый, с очками) оценил ту же задачу в 3 дня. Оптимистично, да.
Мой внутренний циник, воспитанный годами проектного управления, сказал: «Ну давай умножим на 1.5, потом ещё на 1.5 — получится 7–8 дней». Примерно как нейросеть, но без обоснования.
Что получилось в итоге
Задачу сдали за 9 дней.
Нейросеть ошиблась. Эксперт ошибся. Но ошиблись они по-разному.
Ошибка эксперта — классическая: он не учёл, что после разработки придётся три дня согласовывать изменения с заказчиком, потому что у того сломался человек, который должен был принимать работу. Эксперт считал код, а не бюрократию.
Ошибка нейросети — другая: она заложила риск на коммуникацию, но не смогла предсказать, что именно сломается и на сколько. Зато она честно предупредила: «есть риск увеличения срока из-за внешних факторов». И дала распределение вероятностей, а не просто цифру.
Главный вывод (и тут важный концептуальный поворот)
Этот эксперимент не про то, что нейросети лучше людей. Пока нет. И, наверное, никогда не будет в чистом виде.
Это про смену методологии оценки.
Когда я готовил данные для нейросети, мне пришлось:
1. Детально расписать WBS — разбить задачу на подзадачи до уровня, который обычно мы пропускаем.
2. Собрать исторические данные — а для этого навести порядок в Jira, чтобы там лежали реальные трудозатраты, а не «галочки для отчёта».
3. Формализовать риски — прописать их явно, а не держать в голове.
И это оказалось самым ценным. Нейросеть выступила не как замена эксперту, а как внешний аудитор, который заставил нас навести порядок в процессах.
В PMBOK есть понятие «зрелость процессов». Так вот, чтобы нейросеть дала адекватную оценку, процессы должны быть достаточно зрелыми, чтобы по ним можно было собрать данные. И это, на мой взгляд, идеальная роль ИИ в управлении проектами: не угадывать за нас, а заставлять нас быть аккуратнее и системнее.
Есть старая притча про Принстонского профессора, который на экзамене всегда ставил тройки, потому что не знал студентов и судил объективно. Нейросеть в оценке сроков — такой же «принстонский профессор». Ей всё равно, кто просит. Ей нужны данные.
Что дальше?
Я не перестал верить экспертам. Но теперь я верю им иначе.
Я знаю, что их оценки — это отправная точка. А финальная цифра рождается на стыке их опыта и данных, которые мы собираем и обрабатываем. Иногда руками, иногда с помощью LLM.