Zasady Fabryki

{{>toc}}

**Strona nadrzędna:** [[Wiki|Zasady Fabryki]]

Źródło: `ZasadyRealizacji\slad-rozwoju-metody-jako-know-how.md` w drzewie FB. Wiki jest kopią do czytania – zmiany nanosimy w pliku źródłowym, nie tutaj.

---

Ustalone 2026-08-23 przy przeglądzie modelu wyceny VCN. Zasada dotyczy wszystkich projektów: co zostaje w warstwie FB, a co trafia do klienta.

## Teza

**Rejestr decyzji projektowych jest elementem metodyki, nie dokumentacji klienta.** Klient kupuje działający system i wymagania, które ma spełnić – nie zapis tego, jak dochodziliśmy do sposobu ich formułowania.

Daty i numery wersji niosą osobną informację: **pokazują, jak rozwijały się poszczególne elementy metody**. Ciąg „v01 → v02 → v03" wraz z uzasadnieniami zmian to opis drogi, a nie stanu. Droga jest tym, co odróżnia FB od konkurencji, która ma dostęp do tych samych norm.

## Dlaczego to się zmieniło teraz

Do niedawna odtworzenie metody z rozproszonych artefaktów wymagało pracy analityka przez wiele dni i i tak dawało wynik przybliżony. **Inżynieria wsteczna z udziałem AI zmienia ten rachunek**: model dostaje komplet dokumentów z datami i wersjami, odtwarza kolejność decyzji, rekonstruuje uzasadnienia i wyprowadza regułę ogólną. To, co było kosztowne, stało się tanie i szybkie.

W języku modelu interpreterów: **daty i wersje są interpreterem**. Same dokumenty to dane; dopiero uporządkowane w czasie i opatrzone uzasadnieniem zmian stają się wiedzą o metodzie. Rozdzielenie interpretera od danych jest tu tym samym zabezpieczeniem, co przy pseudonimizacji.

## Podział warstw

<table style="width:100%">

<tr><th style="width:20%">Warstwa</th><th style="width:35%">Co zawiera</th><th style="width:45%">Kto widzi</th></tr>

<tr><td><strong>Metodyka FB</strong></td><td>rejestr decyzji, uzasadnienia, historia wersji, warianty odrzucone, statystyki z wdrożeń</td><td>wyłącznie FB</td></tr>

<tr><td><strong>Dokumentacja klienta</strong></td><td>polityki, procedury, instrukcje, rejestry – w brzmieniu obowiązującym</td><td>klient, audytor klienta</td></tr>

<tr><td><strong>Ślad dowodowy klienta</strong></td><td>decyzje klienta: zatwierdzenia, akceptacje ryzyka, odstępstwa, daty</td><td>klient, audytor klienta</td></tr>

</table>

Trzecia warstwa bywa mylona z pierwszą, a to różne rzeczy: **audyt wymaga śladu decyzji klienta, nie śladu ewolucji naszej metody**. Klient ma udowodnić, że jego zarząd coś zatwierdził – nie że my zmienialiśmy zdanie o modelu wyceny trzy razy w ciągu miesiąca.

## Reguły redakcyjne dla dokumentów przekazywanych klientowi

Z dokumentu klienckiego usuwa się:

- sekcje typu „zmiany względem wersji poprzedniej" i uzasadnienia zmian,

- identyfikatory decyzji projektowych (D-xx) oraz odesłania do rejestru decyzji,

- ścieżki do plików źródłowych w drzewie FB,

- statystyki i stany pośrednie prac („78 aktywów, 23 propozycje podniesienia"),

- nazwy wariantów odrzuconych i ślady sporów metodycznych.

Zostaje: **numer wydania, data zatwierdzenia, właściciel dokumentu** – tyle, ile potrzeba do nadzoru nad dokumentacją, i ani zdania więcej o historii.

To nie jest ukrywanie czegokolwiek przed klientem. Klient dostaje wszystko, co dotyczy jego systemu; nie dostaje warsztatu, którym ten system zbudowano.

## Kanon tworzenia dokumentów (rozszerzenie 2026-08-24)

Redakcja nie jest czynnością **przed wysyłką** – jest **sposobem pisania**. Dokument powstaje od razu jako suchy dokument dla odbiorcy; wersja z warsztatem nie istnieje w obiegu klienckim w ogóle. Powód praktyczny: redakcja robiona na końcu zawsze coś przepuszcza, a przy pośpiechu wypada pierwsza.

**Nagłówek dokumentu klienckiego zawiera wyłącznie:** tytuł, strony (klient, FB), **datę opracowania**. Nic więcej – żadnego opisu, co dokument realizuje, z czego wynika, jaką decyzję wykonuje ani co się w nim zmieniło.

Do dokumentu klienckiego **nie wchodzą**:

<table style="width:100%">

<tr><th style="width:30%">Element</th><th style="width:70%">Dlaczego</th></tr>

<tr><td>nazwy naszych plików roboczych (<code>2026-08-19_*.md</code> itp.)</td><td>ujawniają strukturę warsztatu i kolejność prac</td></tr>

<tr><td>noty „wykonuje decyzję z…", „na podstawie ustalenia z…"</td><td>pokazują ścieżkę dojścia, czyli metodę</td></tr>

<tr><td>sekcje zmian i aktualizacji, historia wersji</td><td>genealogia dokumentu</td></tr>

<tr><td>nazwy własne narzędzi metodycznych (MPK, Typ A/B, WJ w materiale nieszkoleniowym)</td><td>nazwy elementów metody FB</td></tr>

<tr><td>statystyki naszej pracy („91 pozycji elementarnych", „28 % braków")</td><td>miara nakładu i sposobu liczenia</td></tr>

<tr><td>sekcja „Źródła" z wykazem naszych opracowań</td><td>mapa dorobku</td></tr>

<tr><td>komentarze redakcyjne i miejsca „[do potwierdzenia z Gregiem]"</td><td>ślad wewnętrznej niepewności</td></tr>

</table>

Zostaje wszystko, co dotyczy **systemu klienta**: wymagania, statusy, podstawy prawne, artefakty, pozycje do potwierdzenia po stronie klienta, terminy.

**Test przed oddaniem dokumentu, jedno pytanie:** czy z tego dokumentu da się odtworzyć, *jak pracujemy* – a nie tylko *co ustaliliśmy*? Jeżeli tak, wraca do redakcji.

Precedens: dokumenty VCN z sierpnia 2026 niosły nagłówki z odesłaniami do plików roboczych i not o zmianach; poprawiane są przy najbliższej edycji, nie hurtowo.

### Odpowiedź na pytanie „dlaczego tak"

Usunięcie genealogii z dokumentu **nie oznacza, że nie umiemy jej pokazać** – oznacza, że nie wysyłamy jej z góry, każdemu i w komplecie. Na pytanie o powód rozstrzygnięcia sięga się do **rejestru decyzji autora** i wskazuje przyjętą podstawę: przepis, normę albo rozstrzygnięcie metodyczne.

Dwa rejestry, których nie wolno mylić:

<table style="width:100%">

<tr><th style="width:25%">Rejestr</th><th style="width:25%">Czyj</th><th style="width:25%">Co zawiera</th><th style="width:25%">Kiedy pokazywany</th></tr>

<tr><td><strong>Rejestr decyzji autora</strong></td><td>FB – warstwa metodyki</td><td>rozstrzygnięcia metodyczne i ich podstawy; dlaczego przyjęto taką konstrukcję</td><td>na żądanie, punktowo – odpowiedź na konkretne pytanie</td></tr>

<tr><td><strong>Rejestr decyzji Zarządu</strong></td><td>klient – ślad dowodowy</td><td>zatwierdzenia, akceptacje ryzyka, odstępstwa, daty</td><td>zawsze dostępny klientowi i jego audytorowi</td></tr>

</table>

Odpowiedź brzmi więc: „**podstawą było X**", a nie „oto historia naszych przemyśleń". Klient dostaje uzasadnienie decyzji, która go dotyczy – nie zapis drogi, którą metoda do niej doszła. To także chroni przed wciąganiem w spór o warsztat zamiast o rozstrzygnięcie.

### Ta sama zasada działa w audycie

W raporcie audytowym nie umieszcza się **druków roboczych** – wypełnionych formularzy wywiadu, kart oceny dokumentu, arkuszy próby. Do raportu wchodzi **treść dowodu**: co stwierdzono, na czym się to opiera, jakie wymaganie zostało naruszone albo spełnione. Druk zostaje w aktach audytu u audytora.

Powód jest dokładnie ten sam co przy dokumentacji wdrożeniowej: druk pokazuje **jak badamy**, treść dowodu pokazuje **co ustaliliśmy**. Pierwsze jest warsztatem, drugie jest produktem.

Gdy na spotkaniu zamykającym albo w korespondencji pada pytanie, skąd wniosek – audytor sięga do akt i pokazuje konkretną podstawę: zapis z wywiadu, oznaczony dokument, wynik badania. **Nie dlatego, że musiał to załączyć – dlatego, że to ma.** Zdolność wykazania na żądanie jest mocniejsza niż wysłanie wszystkiego z góry: dowodzi kontroli nad materiałem, a nie tylko jego posiadania.

Wspólna reguła dla obu ról FB:

<table style="width:100%">

<tr><th style="width:20%">Warstwa</th><th style="width:35%">Audyt</th><th style="width:45%">Wdrożenie</th></tr>

<tr><td><strong>Produkt dla odbiorcy</strong></td><td>ustalenie z treścią dowodu i wymaganiem</td><td>dokument systemu w brzmieniu obowiązującym</td></tr>

<tr><td><strong>Warsztat u nas</strong></td><td>druki, karty oceny, arkusze próby, notatki</td><td>rejestr decyzji autora, wersje robocze, uzasadnienia zmian</td></tr>

<tr><td><strong>Na żądanie</strong></td><td>wskazanie konkretnej podstawy ustalenia</td><td>wskazanie podstawy rozstrzygnięcia</td></tr>

</table>

Konsekwencja, którą warto znać: skoro warsztat ma być pokazywalny na żądanie, **musi być prowadzony porządnie** – akta audytu i rejestr decyzji nie są notatnikiem, tylko materiałem dowodowym drugiej linii.

### Dlaczego ta zasada jest wykonalna dopiero teraz

Symetria warta odnotowania: **ta sama technologia obniżyła koszt po obu stronach**. Odtworzenie cudzej metody z rozproszonych artefaktów stało się tanie – i dlatego pilnujemy warstw. Ale prowadzenie własnego rejestru decyzji też stało się tanie – i dlatego reguła „warsztat u nas, do pokazania na żądanie" przestała być obietnicą.

Wcześniej rejestr przegrywał z terminami: spisanie rozstrzygnięcia wraz z podstawą i kontekstem zajmowało porównywalnie tyle, co samo rozstrzygnięcie, więc powstawał po fakcie albo wcale. Zapis prowadzony na bieżąco w trakcie pracy zmienia rachunek – i dopiero to czyni zasadę operacyjną, a nie deklaratywną. Zasada, która wymaga heroizmu, żeby ją utrzymać, jest niespójnością czekającą na ujawnienie.

## Zastosowanie

- **Wiki kliencka** (projekt `<klient>`) powstaje z osobnego renderu, a nie przez kopię wersji roboczej – w roboczej zostają nagłówki, zmiany i źródła. Format do opracowania; do tego czasu wiki kliencka nie powstaje.

- **Dokumenty docx wysyłane klientowi** – redakcja według listy powyżej przed wysyłką, nie po.

- **Prezentacje i szkolenia** – przykłady z wdrożeń bez nazw i dat własnych wersji metodyki.

- **Materiały publiczne** (artykuły, LinkedIn) – teza tak, genealogia nie.

## Napięcie, o którym warto pamiętać

Ta zasada stoi w napięciu z zasadą dowodowej rzetelności: im mniej śladu, tym trudniej wykazać, że coś powstało w określony sposób. Rozstrzygnięcie: **ślad istnieje i jest kompletny – tylko w warstwie FB**. Nie kasujemy historii, przenosimy ją tam, gdzie jej miejsce.