Slad rozwoju metody know how » Historia » Rewizja 1
Rewizja 1/2
| Następne »
Greg K, 2026-08-23 20:29
Publikacja ze stagingu FB (2026-08-23)
- Spis treści
- Teza
- Dlaczego to się zmieniło teraz
- Podział warstw
- Reguły redakcyjne dla dokumentów przekazywanych klientowi
- Zastosowanie
- Napięcie, o którym warto pamiętać
Strona nadrzędna: 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¶
| Warstwa | Co zawiera | Kto widzi |
|---|---|---|
| Metodyka FB | rejestr decyzji, uzasadnienia, historia wersji, warianty odrzucone, statystyki z wdrożeń | wyłącznie FB |
| Dokumentacja klienta | polityki, procedury, instrukcje, rejestry – w brzmieniu obowiązującym | klient, audytor klienta |
| Ślad dowodowy klienta | decyzje klienta: zatwierdzenia, akceptacje ryzyka, odstępstwa, daty | klient, audytor klienta |
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.