Декомпозиція та shaping: як зробити роботу обмеженою

Коли команда отримує великий запит, перша спокуса — роздати завдання за файлами: одна людина бере базу даних, інша API (Application Programming Interface — програмний інтерфейс взаємодії), третя інтерфейс. Такий перелік ще не пояснює, яку зміну побачить користувач, що лишається невідомим і де проходить межа завершеної роботи.

У цьому розділі декомпозиція означає поділ роботи так, щоб зменшити невизначеність і дати команді перевірювані результати. Перед нею shaping (формування рішення до його прийняття в роботу) уточнює проблему, загальний спосіб її розв’язати, обсяг, небезпечні невідомі та те, що свідомо не робимо. Це не повна інструкція кожного кліка і не математичне доведення строку.

ШІ (AI) може допомогти сформулювати й упорядкувати роботу. Але згенерований план не є схваленням власника продукту.

Приклади нижче навчальні. Клієнти, команда студії, дані, строки й результати вигадані, якщо окремо не сказано про справжній публічний GitHub issue. Умовний строк у прикладі — межа для розмови, а не прогноз продуктивності чи оцінка конкретної команди.

Після розділу читач може:

• відрізнити результат для користувача від переліку технічних виходів;
• пройти від сирої ідеї до достатньо визначеного pitch (короткого опису потенційної ставки) з рамками й відкритими питаннями;
• розрізнити appetite (обсяг часу, який команда готова вкласти) та estimate (оцінку очікуваної роботи);
• помічати надмірні, надто дрібні й приховано залежні задачі;
• показати межі, залежності, критерії результату й невідоме агенту до створення задач.

18.1. Почніть із результату, а не з кількості квитків

Output — те, що команда випускає: екран, endpoint, міграцію, документ чи агентний інструмент. Outcome — зміна, яка стає можливою для користувача або бізнесу. Екран може з’явитися, але користувач усе ще телефонує, щоб змінити бронювання; тоді output є, а бажаного outcome немає.

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

Не вигадуйте ціль на кшталт «скоротити дзвінки на 40%», якщо команда не відрізняє запити про час від інших і не знає базового обсягу. Спершу визначте, як рахувати саме такі звернення відносно активних бронювань, з чим порівнювати результат і які події не включати.

Опис outcome корисний, коли називає користувача, ситуацію і спостережуваний наслідок. «Покращити досвід» і «додати кабінет» не дають критерію, за яким можна відкинути невдалу реалізацію.

Марті Кейґан у статті The Four Big Risks називає чотири ризики: цінність для клієнта, зручність, технічну здійсненність і життєздатність для бізнесу. Це запитання для discovery (з’ясування проблеми та перевірки варіантів), а не чотири обов’язкові Jira-квитки. Для кабінету треба з’ясувати, чи клієнтові справді потрібен перегляд; чи може він знайти й прочитати його; чи здатна система показати актуальний запис; чи не створює доступ і підтримка неприпустимого ризику або витрат. Можуть виявитися інші суттєві ризики, а сам перелік не доводить, що ідея варта розробки.

Коли це розбиття не потрібне. Якщо production-сервіс уже падає й команда має перевірений playbook відновлення, спершу відновлюють сервіс, а не запускають тривалу product-discovery сесію. Якщо зміна — виправити очевидну помилку в підписі, що не впливає на безпеку чи контракт, для неї може вистачити короткого завдання з точним очікуваним результатом. Глибина формування має відповідати ризику, вартості й незворотності рішення.

Повний простий розбір. Власник студії каже: «Нам потрібен клієнтський кабінет». Це назва можливого рішення, не сформульована потреба. У розмові з’ясовується, що клієнти телефонують, аби перевірити час бронювання. Команда уточнює, які саме клієнти, коли це трапляється, що вони бачать тепер і яка помилка має найбільшу ціну. Перший корисний результат може бути скромним: клієнт відкриває підтвердження і бачить актуальний час свого найближчого бронювання. Ще не вирішено, чи потрібні зміна часу, документи, оплата або чат.

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

18.2. Рівні роботи — корисна карта, не обов’язкова ієрархія Jira

Розмова часто переходить між п’ятьма рівнями:

Рівень	Питання	Навчальний приклад
Напрям або бізнес-мета	Для чого команда робить цю зміну?	Менше ручного обслуговування вже створених бронювань
Можливість користувача	Що користувач зможе зробити?	Побачити своє бронювання й обрати інший вільний час
Обмежена зміна	Яка частина можливості має ясний край?	Перенести одне своє майбутнє бронювання в доступний слот
Технічна задача	Який технічний результат потрібно отримати або перевірити?	Визначити, чи постачальник календаря підтримує атомарну перевірку слота
Крок виконання	Яка наступна дія в узгодженій задачі?	Додати поле expected_version до запиту зміни бронювання

Поширені слова можна приблизно зіставити з картою, але не вважати універсальними Jira-рівнями: epic часто об’єднує роботу навколо напряму або великої можливості; feature часто називає користувацьку можливість чи її частину; task — обмежену зміну або технічний результат; implementation step — конкретну наступну дію всередині задачі. У різних командах ці слова позначають різний масштаб, а крок виконання може бути пунктом чекліста, а не окремим issue. Наприклад, «самообслуговування для клієнтів» може бути epic, перегляд майбутнього бронювання — feature, зміна одного майбутнього бронювання — task, а додавання expected_version до запиту — implementation step.

Це поняттєві рівні, не правило на кшталт «кожен epic обов’язково має три feature та по п’ять tasks». У різних командах issue types називаються ієрархічно по-різному; іноді технічна робота є самостійно цінним результатом. Перевірка резервного відновлення, міграція вразливої бібліотеки чи зменшення витрат на обчислення можуть бути важливими, навіть якщо клієнт не отримує нового екрана.

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

18.3. Що саме формує shaping

У Shape Up, системі Райана Сінґера та Basecamp, сформована робота має три властивості:

• Rough — навмисно груба. Вона показує напрям і важливі рішення, але не фіксує кольори, назви кожної змінної та всі варіанти інтерфейсу до того, як виконавець побачить реальні умови.
• Solved — обдумана на потрібному рівні. Основні елементи рішення вже узгоджуються між собою; значні видимі суперечності й запитання, здатні заблокувати команду, опрацьовані або явно винесені в перевірку.
• Bounded — обмежена. Визначено, що входить, де зупинитися і чого не буде в цій версії.

«Грубо» не означає «ідея в одному реченні, хай команда сама розбереться». «Вирішено» не означає «сценарій кожного поля та помилки назавжди зафіксований». Межа залишає виконавцям місце для професійного рішення в рамках узгодженого результату. Такий pitch має бути достатньо зрозумілим людині, якої не було на попередніх розмовах.

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

У книжці Сінґера чотири кроки shaping ведуть від меж до елементів рішення, опрацювання rabbit holes (ризиків і невивчених деталей, здатних зірвати план) і письмового pitch. Ми адаптуємо цю послідовність до невеликої студії та роботи з агентом. Інструменти Basecamp, приватний «shaping track» і шеститижневі цикли не стають автоматичною політикою для іншої команди.

18.4. Appetite — не estimate і не прихована обіцянка

Appetite — скільки ресурсів ми готові вкласти в цю проблему; estimate — скільки роботи чи часу наразі очікуємо за певних припущень. Перше обмежує вибір рішення, друге є невизначеним прогнозом. Жодне не гарантує дату.

Поняття	Що фіксує	Приклад фрази	Чого не обіцяє
Appetite	Прийнятну межу зусиль або календарного часу для цієї можливості	«Розглянемо мале рішення, на яке ми готові відвести до одного узгодженого короткого циклу»	Що всі запитані функції влізуть у межу
Estimate	Поточний прогноз з базою та невідомими	«За наявного доступу до календаря нам видається ймовірною така тривалість; інтеграцію треба перевірити»	Що прогноз не зміниться після нових фактів
Зобов’язання	Рішення відповідального власника виділити команду чи строк на конкретний scope	«Після перегляду pitch погоджено саме цей результат і його виключення»	Що невідомі зникли або ризик дорівнює нулю

У підході fixed time, variable scope команда тримає межу інвестиції, скорочуючи менш цінні функції, щоб зберегти цілісний результат. Це не дозвіл урізати безпеку, необхідну якість чи законні вимоги: звузьте функціональність, оберіть інше рішення або відмовтеся від ставки. Сінґер наводить для малих ставок один-два тижні, а для великих — цикл до шести тижнів своєї Basecamp-команди. Це опис їхньої практики, а не норма для A1, універсальний розмір задачі чи оцінка агента. Інша команда може розглядати години, дні, місяць, квартал або спершу попросити короткий аналіз.

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

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

18.5. Звузьте проблему та перевірте, чи є що формувати

Сире прохання підказує бажане рішення, але ще не доводить, що воно розв’яже проблему. Уточніть:

1. Хто саме стикається з проблемою, у який момент і що ця людина робить зараз?
2. Що не спрацьовує, як часто, для кого та з якою спостережуваною ціною?
3. Які наявні засоби, обмеження чи рішення треба зберегти?
4. Які дані покажуть, що проблема справді зменшилася?

У главі Set Boundaries Сінґер розповідає, як запит на складніші правила дозволів після дослідження привів Basecamp до меншого рішення: попередити користувача про наслідки архівації, а не будувати розгалужену систему ролей. Також запит про «календар» звузили до конкретного питання про вільні проміжки часу. Це приклади з досвіду автора, а не доказ, що за будь-яким великим запитом ховається маленьке рішення.

Якщо симптом реальний, але спосіб його зменшення невідомий, це не «легка задача реалізації». Спершу потрібне discovery — дослідницька перевірка, результатом якої можуть бути спостереження, короткий технічний прототип, тест інтеграції, порівняння варіантів або обґрунтоване рішення не продовжувати. Не закривайте невідоме формулюванням «додати кабінет», доки немає пояснення, чому запропонована форма має спрацювати.

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

18.6. Pitch як міст між проблемою і виконанням

Для потенційно великої зміни письмовий pitch стисло містить п’ять частин. У главі Write the Pitch Сінґер описує цей формат як спосіб показати проблему, межу інвестиції, рішення, ризики та свідомі виключення, щоб люди могли оцінити потенційну ставку:

1. Проблема: конкретний випадок і базовий стан, який не працює.
2. Appetite: межа уваги, яку власник готовий витратити, та її причина.
3. Рішення: основні елементи досить конкретно, щоб їх можна було оцінити.
4. Rabbit holes: припущення, взаємозалежності й рішення, що можуть змінити шанси вкластися.
5. No-gos: можливі, але навмисно виключені випадки.

Це не вимога щоразу створювати окремий формальний документ. Для малого виправлення вистачить абзацу у задачі. Але якщо рішення обговорюють люди без спільного контексту, pitch допомагає порівняти problem і solution та зрозуміти ціну компромісу.

Замість «додати графік у кабінет» pitch має назвати зміну для клієнта, межу першої версії, ризики й виключення. У прикладі в 18.14 сторінка показує одне майбутнє бронювання; перенесення залежить від перевірки календаря, а цільову метрику встановлять лише після базового вимірювання.

Приклад до/після. «Додати графік у кабінет» не каже, яку дію графік змінює й що вважатимемо успіхом. Сформульована версія може звучати так: «Клієнт, який отримав підтверджене бронювання, має сам перевірити найближчий час без дзвінка. За погодженої обмеженої версії сторінка показує одне майбутнє бронювання з часовим поясом; перенесення часу окремо проходить оцінку після перевірки календаря. Ми вимірюємо кількість звернень саме про час; вихідний рівень треба встановити до оголошення числової цілі. У цій версії не робимо повний профіль і керування оплатою».

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

18.7. Знайдіть rabbit holes і перевірте шлях у деталях

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

Питання	Що перевірити
Хто має доступ?	Власник запису, роль і серверна перевірка, а не лише прихована кнопка
Звідки береться час?	Часова зона, джерело істини й перетворення між сервісами
Що стається під час конфлікту?	Два клієнти обирають останній вільний слот майже одночасно
Що відбувається з повідомленням?	Відповідь про успіх і лист можуть розійтися; коли фіксується бронювання та чи є надійний повтор
Чи є платний наслідок?	Перенесення може змінити тариф, аванс або правило повернення; де зафіксоване бізнес-рішення

Повний розбір одного rabbit hole: гонка за останній слот. Прототип читає календар, перевіряє вільний час, а тоді створює подію. Між перевіркою і записом інший клієнт може забрати той самий слот. Якщо інтеграція не має блокування чи атомарного створення, команда не може вважати цю послідовність гарантією від дубля. Дослідіть, чи можна створити подію й обробити конфлікт у джерелі; чи потрібна локальна резервна таблиця з транзакцією; або чи варто обмежити першу версію внутрішніми слотами, для яких уже є інваріант. Результат дослідження — рішення з конкретною гарантією та відомим залишковим ризиком. Якщо доступу до постачальника ще не дали, відповідь чесно лишається невизначеною: план реалізації не підмінює доказ.

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

18.8. Визначте, що не входить

No-go — свідома межа, а не забутий критерій приймання. Вона не дає виконавцю додати розумне, але непогоджене розширення. У прикладі межі для історії та фінансових правил обмежують функції, а не обов’язкові гарантії якості.

У першій версії входить	Поки не входить	Чому
Перегляд одного найближчого підтвердженого бронювання	Історія за всі роки й експорт	Не збільшуємо обсяг даних і вимоги до зберігання до перевірки потреби
Перенесення одного бронювання на інший вільний слот, якщо інтеграція це підтримує	Повернення коштів і зміна тарифу	Потрібні окремі фінансові правила та узгодження з платіжною системою
Перевірка власника на сервері	Адміністративне редагування будь-якого запису	Це інша роль і ризик доступу
Підтвердження нового часу визначеним каналом	Чат, вкладення, профіль і маркетингові сповіщення	Це додаткові продукти й персональні дані, не частина базового сценарію

Чіткий no-go не скасовує мінімальну потрібну якість: наприклад, команда не виключає приватність, логування помилок чи відновлення після часткового збою лише тому, що в короткому pitch вони не описані. Не виводьте конкретні вимоги безпеки з рядка «не входить»; їх визначають політики, ризики й інші глави курсу.

18.9. Технічна задача може бути цінністю, але не лише назвою файлу

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

Порівняйте два формулювання:

• «Додати таблицю й endpoint для кабінету» визначає деталі реалізації, але не стан, який можна перевірити для користувача.
• «Авторизований клієнт бачить актуальний час одного свого майбутнього бронювання; запит із чужим ідентифікатором не розкриває запис» визначає поведінку та важливий негативний випадок.

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

18.10. Як розпізнати задачу, яку можна виконати й прийняти

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

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

Зрозуміла обмежена задача відповідає на потрібну глибину на такі питання:

1. Навіщо: який результат або ризик вона зачіпає?
2. Для кого і де: який користувач, процес чи компонент є межою?
3. Що змінюється: яке спостережуване правило буде іншим?
4. Що не змінюється: які суміжні гарантії або потоки не можна ненавмисно зламати?
5. Передумови: на яких рішеннях, дозволах, середовищах чи інших задачах вона залежить?
6. Критерій: яке свідчення дозволить сказати «готово»?
7. Невідоме: що перевірити окремо, і який вибір залежить від відповіді?
8. Передавання: хто приймає результат і де лишаться рішення та відкриті питання?

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

18.11. Не діліть продукт за шарами коду, якщо користувачу потрібен цілісний сценарій

Запит «перенести бронювання» можна розкласти за шарами: створити таблицю, змінити сервер, додати endpoint, побудувати екран, надіслати лист. Окремий шар не дає клієнту завершеного результату: інтерфейс може спиратися на непідтриманий контракт, а лист — повідомити про зміну, якої ще не збережено.

Сценарне розбиття збирає дані, правило й відповідь навколо цілого результату: клієнт бачить власне бронювання, обирає доступний час, а після конфлікту зберігає старий запис і пробує знову. Доставка email може затриматися, але не повинна робити збережений стан бронювання некоректним. Такий поділ швидше перевіряє повний потік, але не робить частини незалежними: вони можуть спиратися на дозвіл календаря, спільну авторизацію чи ще не ухвалену політику перенесення. Називайте ці залежності прямо. Докладніше про вертикальні зрізи — у главі 19.

Завершене порівняння. Великий запит «перенести бронювання» можна розкласти по горизонтальних шарах:

1. створити таблицю перенесень;
2. змінити сервер;
3. додати endpoint;
4. побудувати екран;
5. надіслати лист.

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

Інше розбиття йде за поведінкою:

1. Показати власне найближче бронювання. Споживач бачить реальні дані з перевіркою власника.
2. Обрати доступний час і побачити конфлікт. Дані, правило слота й повідомлення працюють разом у малому сценарії.
3. Підтвердити перенесення та отримати новий стан. Фіксація, захист від конкуренції й зрозуміла відповідь з’єднані в одну поведінку.
4. Додати додаткове повідомлення лише за погодженим правилом. Якщо доставлення email окреме й може затриматися, статус бронювання все одно має бути коректним.

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

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

18.12. Не дробіть роботу до вартості координації

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

Ознаки, що варто переглянути дроблення:

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

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

Фредерік Брукс у The Mythical Man-Month застерігає від уявлення, ніби будь-який обсяг можна безкоштовно поділити на однакові людино-місяці. Людино-місяць — груба одиниця обліку, ніби одна людина весь місяць виконує частину роботи; таке додавання має сенс лише коли частини достатньо незалежні й не вимагають додаткового навчання чи узгодження. Видавничий опис ювілейного видання пов’язує управлінські проблеми великих проєктів із поділом праці, а зміст називає окрему главу про комунікацію. Це підказка перевірити залежності, не формула для прогнозу сучасної команди чи агента: чи справді нова межа усуває залежність, чи лише додає передачу між власниками?

У пізнішому есеї No Silver Bullet Брукс розрізняє сутнісну складність задуму й випадкові труднощі його представлення та реалізації. Автоматизація може зменшити частину роботи з кодом, але не означає, що продуктову проблему вже вирішено: агент не може вивести з назв файлів, чи власник схвалив правило скасування або прийнятну ціну помилки.

18.13. Три різні результати: вирішити, дослідити, реалізувати

Невідома поведінка або непогоджене бізнес-правило — не простий підпункт реалізації. Розділіть:

Робота	Коли потрібна	Що передає далі
Discovery / формування	Незрозумілі проблема, користувач або бажаний outcome	Вибір проблеми та спостереження, що його підтримують або спростовують
Spike (обмежена технічна розвідка)	Є ціль, але невідома здійсненність чи обмеження інтеграції	Відтворюваний висновок, відомі межі та рекомендований наступний крок
Рішення власника	Вибір належить бізнесу, продукту чи відповідальному за ризик	Явне правило з обґрунтуванням та власником рішення
Реалізація	Межі та значущі правила достатньо відомі	Перевірювана зміна, що вкладається в погоджену поведінку
Експлуатаційна дія	Підтримка, відновлення або спостережуваність потрібні і після випуску	Інструкція, сигнал, відповідальний чи підтверджений шлях відновлення

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

18.14. Повний приклад shaping: від «зробити клієнтський кабінет» до плану

Початковий запит і спостереження

Запит власниці вигаданої студії: «Зробімо клієнтський кабінет, щоб мені менше телефонували». Це напрям, не готовий pitch. Розмова виявляє конкретну ситуацію: частина клієнтів не пам’ятає часу наступного бронювання і телефонує в робочий час; інша частина телефонує, щоб перенести візит. Наявний календар веде зовнішній постачальник, права доступу клієнта до нього ще невідомі. Студія поки не рахує ці два види дзвінків окремо.

Формулювання проблеми й результату

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

Чернетка pitch

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

Appetite. Власниця обирає обмежену першу версію, якщо її можна побудувати без нової повної CRM (Customer Relationship Management — системи керування відносинами з клієнтами) і після короткої перевірки інтеграції. Умовно команда розглядає малий цикл; це рішення про бажану інвестицію, не передбачення строку.

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

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

No-gos. Немає профілю з повною історією, скасування з поверненням коштів, платежів, обміну повідомленнями, адміністрування персоналу та зміни бронювання за телефоном іншої людини. Поки не встановлено, чи перенесення підтримує джерело істини, ця дія не вважається погодженою обіцянкою.

Розбиття після перевірки невідомих

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

1. Підтвердити шлях даних і доступу. Результат: джерело істини назване; команда може отримати актуальне бронювання конкретного поточного клієнта; негативний випадок із чужим записом не повертає його дані. Якщо такого доступу немає, реалізація чекає на дозвіл або змінене рішення.
2. Дати клієнтові переглянути один майбутній запис. Результат: підтверджений час показаний з визначеним часовим поясом; при відсутності запису сторінка не вигадує його й дає зрозумілий наступний крок. Цей зріз сам по собі вже перевіряє основну потребу перегляду.
3. Додати безпечне перенесення лише після підтвердження інтеграції. Результат: у межах погодженого правила вибору сервер резервує доступний слот; конфлікт не скасовує старе бронювання; клієнт бачить фактичний кінцевий стан.
4. Дізнатися, чи змінився результат. Результат: визначено, як зіставити звернення «уточнити час» до і після доступу до сторінки, а також які обмеження має порівняння. Метрика не повинна заохочувати приховувати дзвінки, які потрібні для складної допомоги.

Ці назви не означають автоматично чотири Jira issue і не розподіляють людей. Перша може стати spike, а якщо інтеграція вже достатньо вивчена — передумова для другого зрізу. Друга і третя мають різні бізнесові гарантії, тому є природними окремими межами. Четверте може виконуватися одночасно із запуском за узгодженою аналітичною схемою, а не блокувати кожне збереження бронювання.

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

18.15. Повний приклад невідомої залежності: платіжний постачальник

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

Сирий варіант. «Реалізувати перенесення платежу» не називає підтримуваної операції, власника бізнес-правила, повторів і спостережуваного завершення. Агент, прочитавши тільки цю назву, може вигадати endpoint або трактувати тайм-аут як відмову.

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

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

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

18.16. Реальна декомпозиція у GitHub: що вона показує і чого не доводить

Публічний epic assimp #6097 «Requested 3D formats», відкритий у квітні 2025 року, збирає запити про нові тривимірні формати файлів (3D — three-dimensional, тривимірний) і додаткові схеми або версії підтриманих форматів. Переглянута 23 вересня 2026 року картка показувала 21 із 57 пов’язаних підзадач виконаними. Тіло називає epic журналом запитів, дає окремі дочірні issues на конкретні формати й описує зв’язок PR (Pull Request — запиту на включення змін до основної гілки) із закриттям конкретного issue. Воно також лишає питання ліцензування явним: для одного запитаного формату вказані обмеження власницької ліцензії.

Цей справжній приклад добре показує, навіщо батьківська картка може агрегувати багато малих, окремо адресованих запитів: допоможний проект має видимість колекції, тоді як реалізація конкретного формату має свій issue. Позначка epic та лічильник підзадач не доводять, що кожна дитина однакова за розміром, що прийнято рішення підтримувати кожний формат або що користувацький результат усієї колекції вже досягнуто. Зафіксований стан 21/57 є лише станом сторінки на дату перегляду, він змінюється.

У власній книзі Basecamp рекомендує shaping до ставки; офіційна документація GitHub пояснює технічне представлення ієрархії issue та підзадач. Це різні призначення: GitHub дає змогу показати зв’язок робіт, але сам не вирішує, чи правильно сформульована проблема, чи дозволена межа, або чи не створила команда більше задач, ніж може координувати.

18.17. Короткий робочий процес декомпозиції з агентом

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

1. Прочитати контекст. Переглянути сам запит, чинний код або процес, сусідні рішення та джерело обмежень. Зафіксувати, яких доступів бракує.
2. Перефразувати outcome та обмеження. Хто має отримати яку спостережувану зміну? Чого не можна порушити? Що явно поза межами?
3. Відокремити відоме від припущень. Для кожного невідомого назвати свідчення, потрібне для вибору. Відкрите питання — не прийняте рішення.
4. Запропонувати shaping-варіанти. Показати меншу придатну версію, більш повну версію, їхню користь, ризики і те, що в кожній свідомо виключено.
5. Позначити залежності й точки зупинки. Наприклад, інтеграція календаря потрібна до перенесення; без серверної перевірки власника перегляд не готовий.
6. Визначити критерій завершення кожної частини. Пояснити, як людина з контекстом перевірить реальний результат, а не лише наявність зміненого файла.
7. Попросити рішення там, де воно належить власнику. Не вигадувати політику повернення грошей, доступи, ставку або дозвіл на зміну продукту.
8. Лише тоді відобразити узгоджену роботу в tracker. Не створювати десятки квитків автоматично до підтвердження меж. Після створення залишити посилання на pitch, залежності, джерела й відкриті ризики.

Малий приклад. Для запиту «оновити сторінку допомоги» агент помічає, що є одна застаріла назва кнопки, знаходить чинний інтерфейс і додає короткий результат та спосіб перевірити його. Не створює epic лише тому, що продуктова задача обов’язково має кілька рівнів.

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

Офіційний опис довгих задач Codex показує цілі, обмеження, етапи й критерії перевірки; документація Claude Code описує параметр --permission-mode plan. Це функції конкретних продуктів і версій, а не однакова гарантія для різних агентів. Їхня здатність бачити файли, запускати процеси чи створювати tracker-об’єкти залежить від інструментів, конфігурації й доступу. План є виходом для перевірки та корекції: він не підтверджує правильність змісту, не надає повноважень і не робить дані користувача доступними.

18.18. Перевірка сформованої роботи перед передаванням

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

1. зрозуміло, для кого і в якій конкретній ситуації змінюється результат, і чи можна пояснити рішення без домислювання принципової поведінки;
2. погоджені межі зусиль, що входить і не входить, а також гарантії, які залишаються обов’язковими;
3. названі ризики й залежності, свідчення для їх перевірки та точка, де невідоме зупиняє або змінює рішення;
4. кожна незалежна частина має передумови й спостережуваний критерій приймання, а сукупність частин зберігає цілісний перевірюваний сценарій;
5. результат спирається на факти, а не вигадані оцінки, клієнтські дані чи обіцянки агента;
6. виконавець має свободу обрати деталі дизайну й коду в межах погоджених гарантій;
7. відомо, хто ухвалює відкриті бізнесові рішення, приймає результат і де залишаться рішення та питання.

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

Підсумок

Shaping формує грубе, обдумане на потрібному рівні й обмежене рішення; декомпозиція перетворює його на частини, що можна перевірити й пов’язати з результатом користувача. Appetite обмежує інвестицію, estimate прогнозує роботу — це різні речі.

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

Джерела та подальше читання

Основні джерела перевірено 23 вересня 2026 року, а документацію Codex і Claude Code повторно звірено 26 вересня. Джерела підтримують наведені твердження; власні приклади й адаптації позначено окремо.

1. Ryan Singer, Shape Up: Stop Running in Circles and Ship Work that Matters, вебкнига Basecamp; переглянуто 23 вересня 2026 року. Глави 2–6 підтримують опис shaping, appetite, звуження проблеми, ризиків і pitch. Цикли Basecamp наведено як приклад їхньої практики, а не універсальну норму.
2. Marty Cagan, “The Four Big Risks”, Silicon Valley Product Group, 4 грудня 2017 року; переглянуто 23 вересня 2026 року. Пояснює чотири види продуктових ризиків, перетворені в тексті на запитання до прикладу.
3. Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition, Addison-Wesley, 20-те ювілейне видання 1995 року; переглянуто видавничу бібліографію та легальну вибірку сторінок видання. Текст використовує ідею поділу праці як застереження, а не кількісний закон для сучасних команд.
4. Frederick P. Brooks Jr., “No Silver Bullet: Essence and Accidents of Software Engineering”, першодрук у Information Processing ’86; републікація в Computer, том 20, № 4, квітень 1987 року, с. 10–19; переглянуто 23 вересня 2026 року. Прочитаний видавничий уривок. Підтримує розрізнення сутнісної складності задуму та випадкових труднощів його представлення; використання цього розрізнення в агентній декомпозиції є навчальною адаптацією, не твердженням із вимірювання сучасних AI-команд.
5. GitHub Docs: Adding sub-issues, поточна документація GitHub; дата оновлення на сторінці не вказана; переглянуто 23 вересня 2026 року. Пояснює, як issue можуть відображати батьківсько-дочірній зв’язок і прогрес у Projects. Це опис можливостей tracker, а не рекомендація, що будь-яка робота потребує ієрархії.
6. assimp contributors, Epic #6097: Requested 3D formats, публічний GitHub issue, відкритий 11 квітня 2025 року; переглянуто 23 вересня 2026 року. Реальний, мінливий приклад parent issue з дочірніми запитами, окремим робочим процесом і зауваженням про ліцензування. Число 21/57 описує стан сторінки саме під час перегляду й не є оцінкою результату проєкту.
7. Derrick Choi, “Run long horizon tasks with Codex”, OpenAI Developers, 23 лютого 2026 року; переглянуто 26 вересня 2026 року. Публікує досвід автора з описом цілей, обмежень, етапів, критеріїв перевірки та планування довгої задачі Codex. Це приклад конкретного робочого процесу, не незалежний доказ продуктивності будь-якого агента.
8. Anthropic, Claude Code CLI reference (CLI — Command-Line Interface, інтерфейс командного рядка), поточна документація; дата оновлення на сторінці не вказана; переглянуто 26 вересня 2026 року. Вказує, серед інших параметрів, режим --permission-mode plan. Документація підтверджує доступність параметра для Claude Code, а не точність створеного плану чи наявність дозволу на зміну зовнішніх систем.