Obchod ako zjednocujúca metafora - každý je vlastne živnostník

Keď som mal raz znovu pocit, aký je legislatívny systém zložitý, ako je veľa zákonov, ako sa vzájomne odkazujú, ako sú ľudia nútení robiť to a ono, ako sú mnohé veci zabetónované v nejakom stave, ktorý možno nevyhovuje všetkým, načo tu máme odbory, zákonník práce, veď to všetko je len kúpa a predaj hodnôt, prečo tu máme x dávok a takých a hentakých odvodov, keď to celé je len o tom, zabezpečiť dôstojnú existenciu a nič viac; či to musí to byť celé také komplikované, napadlo ma zamyslieť sa nad minimálnou legislatívou. Z nižšieuvedeného je asi jasné, že som fanúšikom minimálnych, flexibilných systémov, nie veľkých, zložitých a ťažkopádnych.

Najprv uvediem, že nie som právnik, ani som právo neštudoval. Mám z toho teda výhodu, že na túto problematiku môžem mať pohľad nezaťažený tým, že by som bol profesionál v odbore. A priznám, pokojne ho môžete nazvat aj naivným; nijako sa istej naivite nebudem brániť, naopak, skôr o ňu, v rámci nabúrania stereotypov, budem usilovať. Ani ekonomiku som neštudoval. Mojím odborom je programovanie – a zdá sa mi, že sa výroba softwaru od výroby legislatívy až tak nelíši. V oboch prípadoch je nutné vyrobiť fungujúci systém, ktorý má čo najmenej chýb, pričom vo väčšine prípadov nie je konkrétne jasné, čo chceme, a tak dodáme to, o čom si myslíme, že je dobré, a zákazník s tým aj tak spokojný nebude, lebo chcel niečo iné. Ďalšou podobnosťou je, že mnohé dôsledky našich (dizajnových, či softwaru alebo zákonov) rozhodnutí sa ukážu až v praxi, a potom nie jednoduché ich narýchlo dodatočne opravovať.

Trochu sa rozhovorím o tom, ako sa robí software, keďže odtiaľ budem čerpať inšpiráviu na svoje analógie. Dlhé roky bol v programovaní nalinkovaný tzv. Waterfall systém. V podstate ide o to, že výroba softwaru bol rozdelená do fáz: fáza analýzy, v ktorej analytici zisťovali, čo zákazník chce a potom z toho robili predlhé správy, diagramy a štruktúrovaný zoznam požiadaviek pre programátorov. Pravidlom bolo, že sa nikdy od zákazníka nedozvedeli, čo naozaj chce. U osvieteného zákazníka im možno bolo dovolené prehovoriť aj s ľuďmi, ktorý systém naozaj budú používať (ľudia na pobočkách, vo výrobe atď.), a tam dostali užitočné podnety, ale myslím si (sám som nikdy pravým analytikom nebol), že je to len akademická teória. V skutočnosti hovorili len s nejakým manažérom, ktorý opakoval stále to isté, a tak sa dozvedeli zúfale málo. Na takomto základe potom pripravili svoje analýzy a podpísala sa zmluva. Potom nasledovala fáza implementácie – to programátori, na základe vstupov od analytikov, vytvorili nejaký program, o ktorom si mysleli, že robí, to čo má, a že nemá chyby. To už sa zväčša v reáli blížil čas odovzdania, ak už nebol prekročený. Ďalšou fázou bolo testovanie – to zasa testeri produkt skúšali, aby zistili, či naozaj funguje. Napokon bola fáza dodania k zákazníkovi a nakoniec fáza údržby už nasadeného systému. Tento systém sa vyznačuje tým, že cena za zmenu prudko rastie s časom – urobiť zmenu vo fáza analýzy je ešte pomerne lacné, ale vo fáze implementácie už o dosť drahšie, vo fáze testovania ešte viac atď. Ak sa vo fáze dodania ukázalo, že je nutné urobiť zmenu (väčšiu, ktorá by si vyžiadala zmenu v dizajne systému), tak si všetci trhali vlasy. V podstate totiž bolo treba celý proces absolvovať nanovo. Tak teraz už viete, prečo sa dodáva(lo) tak veľa softwaru neskoro, a ešte k tomu chybného.

Waterfall systému, resp. jeho filozofii sa hovorí aj „big up-front design“ - „najprv veľký plán“. Všetko muselo byť pochopené a spracované na začiatku a na základe toho musel byť urobený dokonalý návrh kompletného systému, so všetkým, čo malo tvoriť jeho funkcionalitu. Nefungovalo to, ale všetci to používali – bol v tom aspoň nejaký systém a „keď je to dobré pre veľké firmy, je to dobré aj pre nás“. Po bitke je každý generálom, ale teraz už vieme, k čomu to vedie – k výrobe zbytočne veľkých, „prečačkaných“ systémov, ktoré obsahujú veľa vecí, ktoré nikto nechcel, neobsahujú detaily, ktoré sú naozaj potrebné, ich pridanie by stálo kopu peňazí a navyše sú mnohokrát dodané neskoro a s chybami. Vieme to vďaka tomu, že sa medzitým ukázalo, že existuje aj iná filozofia, ktorá dáva v mnohých prípadoch lepšie výsledky. Vzniklo rozdelenie na nové lightweight (ľahkotonážne) prístupy a staršie heavyweight (ťažkotonážne).

Ľahkotonážna filozofia je opakom big up-front design prístupu. Jej heslom je „embrace change“ - doslova „objím (prijmi) zmenu“. Pri tomto prístupe nie je snaha vyrobiť dokonalý plán dopredu, toho sa držať a vyhýbať sa každej zmene, ale naopak, nevyrábať si dokonalé dlhodobé plány, prijať skutočnosť neustálej zmeny požiadaviek (na základe spätnej väzby) a miesto výroby dokonalého systému vyrábať systém, ktorý spĺňa len to, čo sa zadefinuje ako aktuálna priorita. Dôraz je kladený na opačné hodnoty – najdôležitejšie je, aby bol systém minimálny, teda robil len to, čo sa po ňom chce a nič viac a robil to najjednoduchším (aj keď možno z hľadiska budúcej funkcionality nie tým ideálnym) možným spôsobom. Toto sú však iba nástroje na dosiahnutie toho hlavného – totiž aby bol systém pripravený na zmeny, inak sa to asi povie flexibilný. Na to treba aby bol minimálny a jednoduchý. Táto filozofia funguje v krátkych cykloch (2-4 týždne, čo silne kontrastuje s ťažkotonážnymi kontraktami na niekoľko kvartálov až rokov). Keď potom príde spätná väzba, čo sa má aktuálne pridať / ubrať / upraviť v novom cykle, nikto si vlasy netrhá – so zmenami sa naopak ráta. „Dokonalosť“ sa dosahuje v štádiu, keď už prípadné ďalšie zmeny nestoja zákazníkovi za to, aby ich zaplatil. V konečnom dôsledku dostane systém, ktorý je omnoho bližšie jeho požiadavkám, a často aj skôr a s menej chybami. Je to teda iba priblíženie sa k dokonalosti, ale také, ktoré je považované za dosť dobré.

Teda vrátiac sa k téme, došiel som k tomu, že výrobou a obchodovaním s hodnotami, teda vlastne ekonomickým pohľadom, sa dá popísať celé daňové a pracovné právo. Zvlášť som v tej chvíli pociťoval potrebu maximálne flexibilného pracovného práva – až na úroveň, že keď sa s niekým ráno dohodnem, že mu dnes pomôžem s tým a tým a večer mi za to dá toľko a toľko, že by to bolo úplne ok. Tak som vlastne došiel k tomu, že zrušme celý inštitút zamestnanca, každý je automaticky živnostníkom so všetkými živnosťami na ktoré má kvalifikáciu a predáva svoju prácu (alebo aj iný tovar, keď má). A keď je vlastne každý živnostník, nemusíme ho volať živnostník, ale človek.

Predstavme si tieto jednoduché pravidlá: Osoba je buď človek (má ľudské práva) inštitúcia (spoločenstvo osôb; má inštitucionálne práva). Osoba vyrába hodnoty. Tieto sú hmotné (výrobky) nehmotné (služby). Osoby si medzi sebou po vzájomnej dohode hodnoty vymieňajú.

Verím, že toto je minimálny systém, ktorý v zásade dokáže postihnúť celú mašinériu práva aj ekonomiky – od ekonomických vecí, ako je maloobchod, veľkoobchod, cez živnostenský stav a inštitúty zamestnanca a zamestnávateľa, až po zdravotníctvo, školstvo a dokonca by sa za hodnotu, poskytovanú v takejto výmene dala označiť aj bezpečnosť, spravodlivosť a právny štát. Povedal som v zásade, je jasné, že a) je pomerne veľa detailov, ktoré by potrebovali doladiť a b) riskujem, že budem označený za cynického technokrata, ktorý hodnoty zdravia a ľudskej dôstojnosti znižuje na tovar.

Ak však pominiem tón, ktorým by toto obvinenie bolo na moju adresu vyslovené, v podstate trafilo klinec po hlavičke – snažím sa povedať, že všetko, o čom je právny štát a ekonomika, je výmena hodnôt medzi ľuďmi a vnesenie akéhosi poriadku do toho všetkého. Počnúc tým, že zabiť druhého je zlé a asi sa tomu do istej miery má brániť a následne trestať, až po povinnosť písať na hračky „nevhodné do 3 rokov, obsahuje malé časti, možnosť udusenia / prehltnutia“, a to aj keď sú to evidentne hračky určené pre deti menšie. Medzitým je celá obrovská a komplikovaná legislatíva.

Cieľom tohto myšlienkového experimentu je porozmýšľať o vytvorení ľahotonážnej legislatívy. Tá by mala sa mala viac blížiť ideálu, byť otvorenejšia zmenám, a mala by obsahovať menej chýb. To za to stojí, nie?

Prvý krok by bol masívny refaktoring(1) - nahradenie celej existujúcej legislatívy novou, ktorej prvé tri paragrafy by boli tie vyššie uvedené a ostatné by len v ich rámci kopírovali ducha (tj. čo sa tým má dosiahnuť) ale nie literu (tj. ako je to naformulované). Takto by sme mali inú legislatívu, ktorá by prinášala rovnaké efekty, ale bola by celá písaná v duchu „sme osoby a obchodujeme s hodnotami“. Jedenapoltý krok by mala byť istá reflexia. Po tomto preformulovaní by sme totiž na de facto tú istú legislatívu mali zásadne odlišný pohľad. Tento, ako predpokladám, by ukázal, nakoľko bola tá stará legislatíva zbytočne komplikovná, a v mnohom aj nelogická, či možno by sa to dalo nazvať aj pomýlená.

Druhý krok by bol zjednodušenie tejto novej legislatívy, využijúc výsledky predchádzajúcej reflexie. Osobne si myslím, že týchto „druhých krokov“, asi spolu s reflexiami pred každým z nich, by bolo viacej, bola by ich celá séria. Po prvom zjednodušení by sa totiž ukázali ďalšie pochybenia alebo aspoň formálne omyly či zbytočnosti, ktoré spočiatku, kvôli veľkej kvantite, zložitosti a vzájomnej prepojenosti vidieť neboli. Čo by viedlo k ďalšej reflexii a zjednodušeniu. A to by sa opakovalo niekoľkokrát. Viem, o čom hovorím – v zložitých „špagetových(2)“ systémoch refaktoring prináša možnosti ďalšieho zjednodušenia, zjednodušenie prináša vhľad na možnosti ďalšieho refaktoringu, až kým sa nedosiahne dizajn dostatočne jednoduchý, aby sa už nedal viac zjednodušiť. A to je cieľ – dosiahnuť minimálny systém, ktorý naše požiadavky spĺňa najjednoduchším spôsobom. A možno, keby sme videli, čo to vlastne máme za podivný systém, a čo vlastne reálne prináša, prehodnotili by sme aj požiadavky a navrhli si lepšie. Nabudúce sa pokúsim, náznakovo, o prvý krok.

(1) Celková zmena v dizajne, či lokálnejšia alebo globálna, ktorá nepridáva funkcionalitu, ale zvyšuje kvalitu samotného zdrojového kódu programu – zrozumiteľnosť, jednoduchosť, modularitu atď.

(2) Tzv. „spaghetti code“ – systém vyrobený bez neustáleho tlaku po jednoduchosti a minimálnosti často skonči tak, že jednotlivé časti systému čoraz viac závisia jedna na druhej, všetko je vzájomne prepletené a každá drobná zmena sa môže prejaviť na úplne prekvapivom mieste niekde inde. Pripomína to tanier špagiet. V špagetových systémoch vzniká strach z refaktoringu („čo si sa do toho babral,  fungovalo to“). Tým sa „zabetónuje“ aktuálny, hoci možno nevhodný, dizajn a každá následná zmena je namáhavejšia a prináša viacej možností vniesť chybu. Opačný systém sa nazýva „ravioli code“.