„Uzavřít subsystém“ tak, aby přežil organizaci kolem něj

Implementovaný subsystém (dílčí projektový výstup) přežije personální chaos jen tehdy, když splní následující podmínky.

1) Má jasné hranice

• co je uvnitř (zodpovědnost subsystému),
• co je vně (zodpovědnost organizace),
• co je rozhraní (vstupy/výstupy).

Je to podobné situaci, kdy ve firmě existuje „sklad“ a „účetnictví“: mohou být propojené, ale musí být jasné, kde končí jedna realita a začíná druhá.

2) Má „kontrakty“ místo zvyklostí

Kontrakt = něco, co se dá zkontrolovat:

• formát dat,
• pravidla validace,
• význam polí,
• časování,
• stavy dokladů.

Zvyk = něco, co existuje jen v hlavách lidí.

3) Je testovatelný bez konkrétních lidí

Pokud subsystém nelze ověřit bez „Lenky z účtárny“, není uzavřený.

Uzavřený subsystém má:

• kontrolní sadu (minimálně scénáře / příklady),
• kontrolní reporty,
• jasně definované signály „OK/NOT OK“.

4) Má minimální počet míst, kde se dá obejít

• čím víc bypassů, tím víc se rozjede „každej po svým“,
• čím méně bypassů, tím víc se systém stává „pravidlem světa“.

5) Architektura reality vs architektura souvislostí

Jde o blízké pojmy, jen z jiného úhlu pohledu:

• Architektura souvislostí = síť vztahů, dopadů, návazností (co s čím souvisí a co se stane, když sáhnu sem),
• Architektura reality = z této sítě se vytáhnou „tvrdé“ vrstvy: procesy, stavy, odpovědnosti, pravomoci, a udělá se z nich provozní pravda.

Jedno je mapa, druhé je „dopravní řád“, podle kterého se skutečně jezdí:

1. vymyslet a vědět (mentální model),
2. otestovat model dokumenty (proklepnout realitu),
3. teprve potom implementovat do SW.

Podstatné je, že dokumenty nejsou „byrokracie“, ale simulátor budoucí reality.