My Architect, część 6: strona człowieka — WBS, Building Blocks i User Story Map

Pięć części serii o My Architect było o agencie: pamięć, storage, model, cykl pracy, dystrybucja. Czytelnik ma prawo zapytać: a po co to narzędzie człowiekowi, poza przyglądaniem się agentowi? Odpowiadam w pierwszej osobie, bo nie zaczynałem tego projektu dla agenta. Zaczynałem go dla siebie.

Nawyk myślenia blokami

Jestem architektem ze szkołą TOGAF i mam zawodowe skrzywienie: każdy system widzę najpierw jako zestaw building blocks. Nie „listę zadań", tylko bloki: pipeline płatności, autoryzacja, raportowanie, integracja z dostawcą. Bloki mają granice, odpowiedzialność i powiązania, a dopiero potem przychodzi praca, którą trzeba wykonać.

WBS w My Architect pasuje do tego nawyku jeden do jednego. Górne poziomy drzewa to właśnie building blocks: duże części systemu, nazwane jak encje. Poziom niżej — feature'y wewnątrz bloku, w liściach — konkretne stories. Linter nazw, o którym pisałem w części 3, to tu nie kosmetyka, tylko ta właśnie dyscyplina: drzewo, w którym węzły nazywają się „Payment pipeline" i „Session storage", czyta się jak schemat architektury, a nie jak protokół z zebrania.

WBS jako lustro

Główna wartość WBS to dla mnie nawet nie planowanie, a refleksja. Rozkładasz swój projekt w drzewo — i widzisz go w całości, ze wszystkimi dziurami. O, blok z trzema poziomami szczegółowości, bo został przemyślany. A tu blok z jednego węzła bez dzieci: jeszcze tam nie zaglądałem i drzewo uczciwie to pokazuje. Żadnej metodologii — po prostu obrazek, na którym pustkę widać gołym okiem.

Bez pozowania: na zrzucie sam My Architect, zaplanowany w samym sobie.

Tam też, do drzewa, trafiają wymagania w momencie, gdy o nich pomyślałem. Patrzę na blok autoryzacji, przypominam sobie o limicie czasu odpowiedzi — wieszam NFR prosto na bloku, nie odchodząc od kanwy. Dalej działa dziedziczenie: każda story wewnątrz bloku zobaczy to wymaganie, w tym agent, kiedy weźmie ją do pracy. Myśl, która wcześniej żyła w notatce na telefonie, w dziesięć sekund stała się częścią modelu.

USM do priorytetyzacji

WBS odpowiada na pytanie „z czego składa się system", ale milczy o tym, co robić najpierw. Do tego służy druga projekcja tego samego modelu — User Story Map: w poziomie backbone, główne aktywności produktu, w pionie — pasy release'ów.

USM projektu demo: backbone w poziomie, release'y MVP → V1.1 → V2.0 w pionie. Na kartach widać nawet, że agent właśnie pracuje, a jedno zadanie jest zablokowane.

Priorytetyzacja jest tu fizyczna: bierzesz kartę, przeciągasz z R2 do R1 — gotowe. Nie „ustawić pole priority w tickecie", tylko dosłownie przysunąć pracę bliżej. Koszyk unplanned na dole to uczciwa lista wszystkiego, co w ogóle nie zostało zaplanowane, a jego rozmiar otrzeźwia lepiej niż jakikolwiek raport. Kiedy planuję następny release, spędzam w USM jakieś dwadzieścia minut: przesuwam karty, patrzę, jak zapełniają się pasy, i wychodzę z planem, którego nie trzeba nigdzie przenosić — on już jest w modelu.

Obrazek, który działa

A teraz najważniejsze, po co to wszystko powstało. Rysowałem WBS i story mapy na długo przed tym projektem — w Miro, w draw.io, na tablicach. Wszystkie te obrazki łączy jeden los: warsztat się skończył i diagram zaczął się starzeć. Po miesiącu kłamie, po trzech — wstyd go pokazać.

W My Architect diagram to właśnie model, który wykonuje agent. Te same węzły, które przesuwałem na kanwie, to backlog: agent bierze liście przez get_next_task, zmienia statusy, zamyka bloki kaskadowo. Przeciągnąłem story do innego release'u — agent w następnej sesji weźmie inną pracę. Agent zamknął zadanie — u mnie na kanwie węzeł poszarzał, jeszcze w trakcie jego sesji.

Diagram, którego nikt nie wykonuje, to życzenie. Diagram, według którego pracuje agent, to plan.

Dlatego się nie starzeje: nie ma jak. Każda rozbieżność między obrazkiem a kodem to rozbieżność między backlogiem agenta a kodem, a na to jest reconcile z części 4.

Mój prawdziwy cykl

Wygląda to tak. Rano — /my-architect:progress: procenty po release'ach, co w toku, co następne. Jeśli nazbierały się pomysły — dziesięć minut na kanwie: nowe węzły do właściwych bloków, parę wymagań, coś przeskoczyło między release'ami. Potem pracuje agent, a ja zajmuję się swoimi sprawami i czasem zerkam, jak drzewo zielenieje. Wieczorem — rzut oka na USM: co się zamknęło, co się zablokowało i dlaczego.

Przestałem być dyspozytorem, który opowiada agentowi kontekst. Pozostałem architektem: myślę blokami, ustawiam priorytety, zapisuję wymagania. Wykonanie to nie moja praca — i po raz pierwszy naprawdę tak jest.

Wypróbujcie i dajcie mi znać

My Architect jest otwarty na my-architect.app: konto, token, dwie komendy w Claude Code — instalację opisałem w części 5. Najbardziej zależy mi teraz na feedbacku od dwóch typów ludzi: architektów z własnymi nawykami dekompozycji i tych, którzy ganiają agentów w długich projektach. Co niewygodne, czego brakuje, gdzie model kłóci się z waszą praktyką — napiszcie, to wpływa na roadmapę bezpośrednio.