My Architect, частина 6: сторона людини — WBS, Building Blocks і User Story Map
П'ять частин серії про My Architect були про агента: пам'ять, сховище, модель, робочий цикл, дистрибуція. Справедливе запитання читача: а людині цей інструмент навіщо, окрім як спостерігати за агентом? Відповідаю на нього від першої особи, бо починав я цей проєкт не для агента. Я починав його для себе.
Звичка думати блоками
Я архітектор зі школою TOGAF, і в мене профдеформація: будь-яку систему я спершу бачу як набір building blocks. Не «список задач», а блоки: платіжний контур, авторизація, звітність, інтеграція з провайдером. У блоків є межі, відповідальність і зв'язки, і лише потім — робота, яку треба зробити.
WBS у My Architect лягає на цю звичку один в один. Верхні рівні дерева — це і є building blocks: великі частини системи, названі сутностями. Рівнем нижче — фічі всередині блоку, у листках — конкретні історії. Лінтер назв, про який я писав у частині 3, тут не косметика, а та сама дисципліна: дерево, де вузли називаються «Payment pipeline» і «Session storage», читається як архітектурна схема, а не як протокол наради.
WBS як дзеркало
Головна користь WBS для мене навіть не планування, а рефлексія. Розкладаєш свій проєкт у дерево — і бачиш його цілком, з усіма дірами. Ось блок із трьома рівнями деталізації, бо він продуманий. А ось блок з одного вузла без дітей: туди я ще не зазирав, і дерево чесно це показує. Жодної методології — просто картинка, на якій порожнечу видно очима.
Без постановки: на скриншоті сам My Architect, спланований у самому собі.
Туди ж, у дерево, йдуть вимоги в момент, коли про них подумав. Дивлюся на блок авторизації, згадую про ліміт часу відповіді — вішаю NFR прямо на блок, не відходячи від канви. Далі працює спадкування: кожна історія всередині блоку цю вимогу побачить, зокрема й агент, коли візьме її в роботу. Думка, яка раніше жила в нотатці на телефоні, стала частиною моделі за десять секунд.
USM для пріоритизації
WBS відповідає на запитання «з чого складається система», але мовчить про те, що робити першим. Для цього є друга проєкція тієї самої моделі — User Story Map: по горизонталі backbone, основні активності продукту, по вертикалі — релізні смуги.
USM демо-проєкту: backbone по горизонталі, релізи MVP → V1.1 → V2.0 по вертикалі. На картках навіть видно, що агент зараз у роботі, а одна задача заблокована.
Пріоритизація тут фізична: взяв картку, перетягнув із R2 в R1 — готово. Не «проставити поле priority в тікеті», а буквально посунути роботу ближче. Кошик unplanned унизу — чесний список того, що взагалі не розплановано, і його розмір протвережує краще за будь-який звіт. Коли я планую наступний реліз, я проводжу в USM хвилин двадцять: рухаю картки, дивлюся, як наповнюються смуги, і виходжу з планом, який не треба нікуди переносити — він уже в моделі.
Картинка, яка працює
Тепер головне, заради чого все затівалося. Я малював WBS і story map задовго до цього проєкту — в Miro, в draw.io, на дошках. У всіх цих картинок одна доля: воркшоп скінчився, і діаграма почала застарівати. За місяць вона бреше, за три — її соромно показати.
У My Architect діаграма і є моделлю, яку виконує агент. Ті самі вузли, які я рухав на канві, — це беклог: агент бере листки через get_next_task, рухає статуси, закриває блоки каскадом. Перетягнув історію в інший реліз — агент у наступній сесії візьме іншу роботу. Агент закрив задачу — у мене на канві вузол посірів, прямо під час його сесії.
Діаграма, яку ніхто не виконує, — це побажання. Діаграма, за якою працює агент, — це план.
Тому вона й не застаріває: їй нікуди. Будь-яке розходження між картинкою і кодом — це розходження між беклогом агента і кодом, а для цього є reconcile з частини 4.
Мій реальний цикл
Виглядає це так. Зранку — /my-architect:progress: відсотки за релізами, що в роботі, що наступне. Якщо назбиралися ідеї — десять хвилин на канві: нові вузли в потрібні блоки, пара вимог, щось переїхало між релізами. Далі працює агент, а я займаюся своїми справами і час від часу поглядаю, як зеленіє дерево. Увечері — погляд на USM: що закрилося, що заблокувалося і чому.
Я перестав бути диспетчером, який переказує агенту контекст. Я залишився архітектором: думаю блоками, розставляю пріоритети, фіксую вимоги. Виконання — не моя робота, і вперше це справді так.
Спробуйте і розкажіть мені
My Architect відкритий на my-architect.app: акаунт, токен, дві команди в Claude Code — встановлення описано в частині 5. Мені зараз найважливіший зворотний зв'язок від двох типів людей: архітекторів, у яких свої звички декомпозиції, і тих, хто ганяє агентів у довгих проєктах. Що незручно, чого бракує, де модель сперечається з вашою практикою — напишіть, це впливає на роадмап напряму.