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.

## 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.