# Проект описан. Что вы закончите на этой неделе?

Canonical: https://specscore.md/ru/articles/weekly-delivery/

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

## Выберите результат для пользователя, а не набор задач

Возьмите один критерий приёмки и превратите его в короткую демонстрацию. Для импорта CSV «реализовать парсер» описывает работу. «Пользователь загружает корректный файл, видит записи и получает понятную ошибку для некорректной строки» описывает проверяемый результат. Сохраните сценарий ошибки: убрать его ради срока — значит изменить обещание.

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

## Планируйте по реальному календарю

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

Перечислите зависимости вне вашего контроля. У «ждём доступ к продакшену» должны быть ответственный и срок принятия решения. Если в среду доступа ещё нет, решите, полезна ли локальная демонстрация. Назовите результат честно: локальное демо не доказывает готовность к продакшену. Не меняйте определение успеха незаметно в пятницу.

## Ограничьте работу агентов; оставьте решение за собой

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

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

## Сначала доказательства, затем рассказ

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

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

## Невыполненное обязательство требует нового решения

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

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

## Пять строк для еженедельного разбора

- Результат: что пользователь сможет сделать к дате разбора?
- Доказательство: какой критерий и какая демонстрация это подтвердят?
- Время: когда я буду реализовывать, тестировать и проверять?
- Ограничение: что я откладываю и какая зависимость требует решения?
- Разбор: кто посмотрит результат, когда и какое решение последует?

## Добавьте к своим решениям человеческий взгляд

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

[Узнать о CommittedMe](https://committedme.com/ru/for/builders/?utm_source=specscore&utm_medium=ecosystem_referral&utm_campaign=committedme_cross_promotion&utm_content=article_footer)

Уже обучаете разработчиков на YouTube, TikTok, Instagram или в блоге? Объяснение компромиссов и тестов помогает заметить собственные предположения. Вопросы другого человека могут помогать вам учиться, пока он движется вперёд. Если вам близок такой разговор, прочитайте о роли наставника.

[Прочитать о роли наставника](https://committedme.com/ru/become-a-mentor/?utm_source=specscore&utm_medium=ecosystem_referral&utm_campaign=committedme_cross_promotion&utm_content=article_mentor)

CommittedMe — ещё один продукт нашей экосистемы. Статья описывает практику разбора и не подразумевает техническую интеграцию со SpecScore.

## Сделайте результат проверяемым

[Как писать проверяемые критерии приёмки](https://specscore.md/ru/articles/acceptance-criteria/)