Как использовать завершённый проект для оценки следующего

Завершённый проект может сделать следующую оценку более обоснованной, но не может сделать её точной заранее. Полезнее спрашивать не «сколько занял прошлый проект?», а «какие части той работы действительно сопоставимы и что изменится сейчас?».

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

1. Выбери сопоставимый завершённый проект

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

Перед тем как переносить наблюдения в новую оценку, сравни:

• Тип результата. Это похожая функция, аудит, правка дизайна, интеграция или исследовательская задача?
• Технический контекст. Ты работаешь в знакомой кодовой базе, с привычным набором инструментов и процессом, или входишь в незнакомую среду?
• Границы объёма. У нового проекта так же определён итог или важные требования ещё открыты?
• Условия проверки. Кто будет принимать работу и сколько циклов согласования или правок можно разумно ожидать?
• Нагрузка на координацию. Будет ли столько же участников, передач между командами или разговоров с клиентом?

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

2. Разложи прошлый проект на фазы

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

Вот простой шаблон ретроспективы:

Фаза	Что показывает запись	Что на неё повлияло	Применима ли она в следующий раз?
Исследование	Вопросы, изучение и определение задачи	Требования были неполными	Возможно, зависит от брифа
Реализация	Работа, которая привела к результату	Знакомые инструменты и стабильная среда	Вероятно, если технический контекст похож
Проверка	Тестирование, проверка и ответы на обратную связь	В проверке участвовали несколько человек	Не предполагай то же число циклов
Правки	Изменения после первой проверки	Решение по объёму приняли поздно	Считай это риском, а не стандартной фазой
Координация	Созвоны, сообщения, передачи и статусы	Внешняя зависимость требовала сопровождения	Включай только при наличии такой зависимости

Таблица намеренно проста. Она нужна, чтобы ты не переносил в новое предложение единый неразобранный блок времени.

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

3. Считай переключения и работу с ИИ контекстом

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

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

Тот же подход нужен для работы с ИИ. Сессия с ИИ-агентом могла помочь в исследовании, реализации, проверке или привести к отброшенному пути. Её длительность, расход токенов или стоимость сами по себе не доказывают ценность результата. Посмотри, какой задаче служила сессия, что произошло после неё и вероятен ли такой же процесс в новом проекте.

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

4. Оформи оценку как документированное суждение

В заметках к оценке держи две колонки: наблюдалось в завершённом проекте и предполагается в новом проекте. Такое разделение не даёт старой записи незаметно превратиться в утверждение о работе, которой ещё не было.

Перед отправкой оценки проверь:

• выбран ли проект, сопоставимый по результату, объёму и техническому контексту;
• разделены ли исследование, реализация, проверка, правки и координация;
• отмечена ли работа, вызванная неопределённостью, переделками или переключениями, вместо того чтобы считать её обычным усилием на выполнение;
• рассмотрена ли работа с ИИ в связи с задачей и результатом, а не как самостоятельный показатель;
• записаны ли допущения, при изменении которых изменится и оценка;
• понятно ли, что включено в оценку и какие изменения потребуют нового обсуждения.

Такая оценка опирается на завершённую работу и учитывает неизвестные условия. Если проект изменится, будет понятно, какие допущения нужно пересмотреть.