Статті

Проєкт описано. Що ви завершите цього тижня?

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

Оберіть результат для користувача, а не купу завдань

Візьміть один критерій приймання й перетворіть його на коротку демонстрацію. Для імпорту CSV «реалізувати парсер» описує роботу. «Користувач імпортує коректний файл, бачить записи й отримує зрозумілу помилку для некоректного рядка» описує перевірюваний результат. Збережіть сценарій помилки: прибрати його заради строку означає змінити обіцянку.

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

Плануйте за реальним календарем

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

Перелічіть залежності поза вашим контролем. «Чекаємо на доступ до продакшену» потребує відповідального й часу ухвалення рішення. Якщо в середу доступу ще немає, вирішіть, чи корисна локальна демонстрація. Назвіть результат чесно: локальне демо не доводить готовності до продакшену. Не змінюйте визначення успіху потай у п’ятницю.

Обмежте роботу агентів; залиште рішення за собою

Агент може створити кілька реалізацій, поки ви визначаєте важливу проблему. Тому більше виконаних підзавдань не обов’язково наближає початкову мету. Дайте кожному завданню конкретний критерій, дозволені межі й перелік доказів. За приймання всього користувацького сценарію відповідає людина.

Нову ідею запишіть, не запускаючи її автоматично. Запитайте, яке поточне зобов’язання вона замінить. Можна спробувати залишати лише один результат в очікуванні вашої підсумкової перевірки. Це експеримент із фокусом, а не універсальний закон продуктивності; змініть його, якщо він гальмує корисну роботу.

Спочатку докази, потім розповідь

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

Розрізняйте реалізоване, протестоване та доступне користувачу в потрібному середовищі. Попросіть рецензента знайти спосіб зламати результат. Діліться лише необхідним: часто досить синтетичного прикладу або демонстрації без чутливих даних. Відповідальність за зобов’язання не вимагає розкривати дані клієнтів, секрети чи приватний репозиторій.

Невиконане зобов’язання потребує нового рішення

Якщо демонстрація не вдалася, запишіть найкоротше корисне пояснення: невідома залежність, завеликий обсяг, перервана робота чи хибне припущення. Помилка оцінки не є оцінкою вашого характеру. Оберіть конкретну відповідь: зменшити наступний крок, усунути залежність, змінити підхід або свідомо закрити проєкт.

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

П’ять рядків для щотижневого розбору

  • Результат: що користувач зможе зробити до дати розбору?
  • Доказ: який критерій і яка демонстрація це підтвердять?
  • Час: коли я реалізовуватиму, тестуватиму й перевірятиму?
  • Обмеження: що відкладаю та яка залежність потребує рішення?
  • Розбір: хто перегляне результат, коли та яке рішення буде далі?

Додайте до своїх рішень людський погляд

Використовуйте цю нотатку з людиною, яка запитає, що сталося, та допоможе обміркувати наступний вибір. CommittedMe зосереджується на людському менторстві й відповідальності за зобов’язання. Сторінка для розробників і засновників знайомить із цим підходом. Залиште специфікацію в репозиторії та принесіть мету, яку можна обговорювати без розкриття конфіденційної роботи.

Дізнатися про CommittedMe (англійською) →

CommittedMe — ще один продукт нашої екосистеми. Стаття описує практику розбору й не передбачає технічної інтеграції зі SpecScore.

Як писати перевірювані критерії приймання →

Знайшли помилку в перекладі або маєте ідею як покращити цю сторінку?