{"id":41818,"date":"2020-02-16T20:46:08","date_gmt":"2020-02-16T17:46:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/sem-arhetipov-prevrashheniya-po-princzipam-devops"},"modified":"2020-02-16T20:46:08","modified_gmt":"2020-02-16T17:46:08","slug":"sem-arhetipov-prevrashheniya-po-princzipam-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sk\/blog\/sem-arhetipov-prevrashheniya-po-princzipam-devops","title":{"rendered":"Sedem archetypov transform\u00e1cie pod\u013ea princ\u00edpov DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ot\u00e1zka \u201eako implementova\u0165 DevOps vo svojej firme\u201c sa neobjavila len ned\u00e1vno, no kvalitn\u00fdch materi\u00e1lov nie je ve\u013ea. Niekedy sa st\u00e1vate obe\u0165ou reklamy nie ve\u013emi inteligentn\u00fdch konzultantov, ktor\u00ed pred\u00e1vaj\u00fa svoj \u010das bez oh\u013eadu na to, ako. Niekedy s\u00fa to nevhodn\u00e9, ve\u013emi v\u0161eobecn\u00e9 slov\u00e1 o tom, ako ve\u013ek\u00e9 korpor\u00e1cie pl\u00e1vaj\u00fa vesm\u00edrom. Vznik\u00e1 ot\u00e1zka: a \u010do z toho m\u00e1me my? V\u00e1\u017een\u00fd autor, mohli by ste jasne zhrn\u00fa\u0165 svoje my\u0161lienky v zozname?<\/p>\n

Toto v\u0161etko vych\u00e1dza z toho, \u017ee re\u00e1lna prax a pochopenie v\u00fdsledkov transform\u00e1cie kult\u00fary spolo\u010dnosti nie s\u00fa zn\u00e1me. Zmeny v kult\u00fare s\u00fa procesy na dlh\u00e9 trate, ktor\u00fdch v\u00fdsledky sa neprejavia za t\u00fd\u017ede\u0148 ani mesiac. Potrebujeme niekoho dos\u0165 star\u00e9ho, kto za\u017eil, ako sa spolo\u010dnosti formovali a rozpadali v priebehu rokov.<\/p>\n

\"Sedem
\n
\nJohn Willis<\/b> je jedn\u00fdm zo zakladate\u013eov DevOps. John m\u00e1 za sebou desiatky rokov pr\u00e1ce s mno\u017estvom spolo\u010dnost\u00ed. V poslednom \u010dase si John za\u010dal v\u0161\u00edma\u0165 \u0161pecifick\u00e9 vzory, ktor\u00e9 sa objavuj\u00fa v pr\u00e1ci s ka\u017edou z nich. Pomocou t\u00fdchto archetypov vedie spolo\u010dnosti spr\u00e1vnym smerom v DevOps transform\u00e1cii. Viac o t\u00fdchto archetypoch sa dozviete v preklade jeho predn\u00e1\u0161ky z konferencie DevOops 2018.
\n<\/a><\/noindex>
\n

\r\n \"Prehrajte\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

O predn\u00e1\u0161aj\u00facom:<\/b><\/p>\n

M\u00e1 viac ako 35 rokov sk\u00fasenost\u00ed v IT riaden\u00ed, bol zapojen\u00fd do vytvorenia predchodcu OpenCloud v Canonical, z\u00fa\u010dastnil sa 10 startupov, z ktor\u00fdch dva predal spolo\u010dnostiam Dell a Docker. Teraz je Vice President of DevOps and Digital Practices v SJ Technologies.<\/p>\n

Nasleduje rozpr\u00e1vanie z poh\u013eadu Johna.<\/b><\/p>\n

Vol\u00e1m sa John Willis a najjednoduch\u0161ie ma n\u00e1jdete na Twitteri, @botchagalupe<\/a><\/noindex>. Tento pseudonym m\u00e1m aj na Gmaili a GitHube. A na tomto odkazu<\/a><\/noindex> m\u00f4\u017eete n\u00e1js\u0165 videoz\u00e1znamy mojich predn\u00e1\u0161ok a prezent\u00e1cie k nim.<\/p>\n

M\u00e1m mnoho sch\u00f4dz\u00ed s CIO r\u00f4znych ve\u013ek\u00fdch spolo\u010dnost\u00ed. Ve\u013emi \u010dasto sa s\u0165a\u017euj\u00fa, \u017ee nerozumej\u00fa, \u010do to vlastne DevOps je, a v\u0161etci, ktor\u00ed sa im to sna\u017eia vysvetli\u0165, hovoria o nie\u010dom svojom. \u010eal\u0161ia \u010dast\u00e1 s\u0165a\u017enos\u0165 je, \u017ee DevOps nefunguje, aj ke\u010f sa zd\u00e1, \u017ee riaditelia robia v\u0161etko tak, ako im bolo vysvetlen\u00e9. Hovor\u00edme o ve\u013ek\u00fdch spolo\u010dnostiach, ktor\u00e9 maj\u00fa viac ako sto rokov. Po rozhovoroch s nimi som dospel k z\u00e1veru, \u017ee pre mnoh\u00e9 probl\u00e9my s\u00fa najlep\u0161ie nie vysok\u00e9 technol\u00f3gie, ale relat\u00edvne n\u00edzkotechnologick\u00e9 rie\u0161enia. T\u00fd\u017edne som sa iba rozpr\u00e1val s \u013eu\u010fmi z r\u00f4znych oddelen\u00ed. To, \u010do vid\u00edte na prvej fotke v pr\u00edspevku \u2014 to je m\u00f4j posledn\u00fd projekt, miestnos\u0165 vyzerala takto po troch d\u0148och pr\u00e1ce.<\/p>\n

\u010co je to DevOps?<\/h2>\n

\nSkuto\u010dne, ak sa op\u00fdtate 10 r\u00f4znych \u013eud\u00ed, dostanete 10 r\u00f4znych odpoved\u00ed. Ale zauj\u00edmav\u00e9 je, \u017ee v\u0161etky tieto odpovede bud\u00fa spr\u00e1vne. Nespr\u00e1vna odpove\u010f tu nie je. Venoval som sa DevOps celkom hlboko, asi 10 rokov, bol som prv\u00fdm Ameri\u010danom na prvom DevOpsDay. Nepoviem, \u017ee som m\u00fadrej\u0161\u00ed ako v\u0161etci, ktor\u00ed sa zauj\u00edmaj\u00fa o DevOps, ale sotva by sa na\u0161iel niekto, kto by na to str\u00e1vil to\u013eko s\u00edl. Pova\u017eujem DevOps za spojenie \u013eudsk\u00e9ho kapit\u00e1lu a technol\u00f3gie. \u010casto zab\u00fadame na \u013eudsk\u00fd rozmer, aj ke\u010f hovor\u00edme ve\u013ea o r\u00f4znych kult\u00farach. <\/p>\n

\"Sedem
\n
\nTeraz m\u00e1me k dispoz\u00edcii mno\u017estvo \u00fadajov, p\u00e4\u0165 rokov akademick\u00e9ho v\u00fdskumu, overenie te\u00f3ri\u00ed nastaven\u00e9 na priemyselnej \u00farovni. Tieto v\u00fdskumy n\u00e1m hovoria nasledovn\u00e9: ak v organiza\u010dnej kult\u00fare spoj\u00edme niektor\u00e9 behavior\u00e1lne vzorce, m\u00f4\u017eeme dosiahnu\u0165 zr\u00fdchlenie o 2000-n\u00e1sobok. Tomu zr\u00fdchleniu zodpoved\u00e1 rovnak\u00e9 zlep\u0161enie v odolnosti. Toto je kvantitat\u00edvne meranie v\u00fdhody, ktor\u00fa m\u00f4\u017ee DevOps poskytn\u00fa\u0165 akejko\u013evek spolo\u010dnosti. Pred p\u00e1r rokmi som o DevOps hovoril gener\u00e1lnemu riadite\u013eovi spolo\u010dnosti zo zoznamu Fortune 5000. Ke\u010f som sa pripravoval na prezent\u00e1ciu, bol som ve\u013emi nerv\u00f3zny, preto\u017ee som musel za 5 min\u00fat zhrn\u00fa\u0165 svoje mnohoro\u010dn\u00e9 sk\u00fasenosti. <\/p>\n

Nakoniec som predstavil nasledovn\u00e9 defin\u00edcia DevOps<\/b>: je to s\u00fabor prakt\u00edk a vzorcov, ktor\u00e9 umo\u017e\u0148uj\u00fa transformova\u0165 \u013eudsk\u00fd kapit\u00e1l na vysoko v\u00fdkonn\u00fd organiza\u010dn\u00fd kapit\u00e1l. Pr\u00edklad \u2014 sp\u00f4sob, ak\u00fdm Toyota funguje posledn\u00fdch 50 alebo 60 rokov.<\/p>\n

\"Sedem
\n
\n(Tieto sch\u00e9my sa uv\u00e1dzaj\u00fa nie len ako referen\u010dn\u00fd materi\u00e1l, ale ako ilustr\u00e1cia. Ich obsah sa bude l\u00ed\u0161i\u0165 pre ka\u017ed\u00fa nov\u00fa spolo\u010dnos\u0165. Napriek tomu si obr\u00e1zok m\u00f4\u017eete samostatne pozrie\u0165 a zv\u00e4\u010d\u0161i\u0165 na tejto linke.)<\/a><\/noindex><\/i><\/p>\n

Jedna z naj\u00faspe\u0161nej\u0161\u00edch tak\u00fdchto prakt\u00edk je \u2013 mapovanie hodnotov\u00e9ho toku<\/b>. O tom bolo nap\u00edsan\u00fdch nieko\u013eko dobr\u00fdch kn\u00edh, autorom naj\u00faspe\u0161nej\u0161ej z nich je Karen Martin. Ale za posledn\u00fd rok som dospel k n\u00e1zoru, \u017ee aj tento pr\u00edstup je pr\u00edli\u0161 technologicky n\u00e1ro\u010dn\u00fd. Ur\u010dite m\u00e1 mno\u017estvo v\u00fdhod, s\u00e1m som ich ve\u013ea vyu\u017e\u00edval. Ale ke\u010f gener\u00e1lny riadite\u013e sa \u0165a p\u00fdta, pre\u010do jeho spolo\u010dnos\u0165 nem\u00f4\u017ee prejs\u0165 na nov\u00e9 ko\u013eaje, o mapovan\u00ed hodnotov\u00e9ho toku je e\u0161te priskoro hovori\u0165. Existuje mno\u017estvo z\u00e1sadnej\u0161\u00edch ot\u00e1zok, na ktor\u00e9 je potrebn\u00e9 predt\u00fdm n\u00e1js\u0165 odpovede. <\/p>\n

Mysl\u00edm, \u017ee chybou mnoh\u00fdch mojich kolegov je, \u017ee jednoducho poskytn\u00fa spolo\u010dnosti p\u00e4\u0165bodov\u00fd pl\u00e1n a potom sa po pol roku vr\u00e1tia a pozr\u00fa, \u010do sa stalo. Aj s dobr\u00fdm sch\u00e9mou, ako je mapovanie hodnotov\u00e9ho toku, existuj\u00fa povedzme m\u0155tve z\u00f3ny (blind spots). Po stovk\u00e1ch rozhovorov s riadite\u013emi r\u00f4znych spolo\u010dnost\u00ed som vytvoril ur\u010dit\u00fd vzor, ktor\u00fd umo\u017e\u0148uje rozlo\u017ei\u0165 probl\u00e9m na zlo\u017eky, a teraz si po porad\u00ed prejdeme ka\u017ed\u00fa z t\u00fdchto zlo\u017eiek. Predt\u00fdm ne\u017e aplikujem ak\u00e9ko\u013evek technologick\u00e9 rie\u0161enia, pou\u017e\u00edvam tento vzor, a v\u00fdsledkom je, \u017ee v\u0161etky steny s\u00fa pokryt\u00e9 sch\u00e9mami. Ned\u00e1vno som pracoval s jedn\u00fdm podielov\u00fdm fondom a nakoniec som mal 100-150 tak\u00fdchto sch\u00e9m.<\/p>\n

Zl\u00e1 kult\u00fara zje dobr\u00e9 pr\u00edstupy na ra\u0148ajky<\/h2>\n

\nHlavn\u00e1 my\u0161lienka je tak\u00e1: \u017eiadne Lean, Agile, SAFE a DevOps nepom\u00f4\u017eu, ak je zl\u00e1 kult\u00fara organiz\u00e1cie. Je to ako pot\u00e1pa\u0165 sa do h\u013abky bez d\u00fdchacej trubice alebo operova\u0165 bez r\u00f6ntgenov\u00e9ho sn\u00edmku. In\u00fdmi slovami, parafr\u00e1zuj\u00fac Druckera a Deminga: zl\u00e1 organiza\u010dn\u00e1 kult\u00fara pohlt\u00ed ka\u017ed\u00fd dobr\u00fd syst\u00e9m a ani sa nezadus\u00ed. <\/p>\n

Aby sme rie\u0161ili tento hlavn\u00fd probl\u00e9m, je potrebn\u00e9 podnikn\u00fa\u0165 nasleduj\u00face kroky:<\/p>\n

    \n
  1. Zvidite\u013eni\u0165 v\u0161etku pr\u00e1cu:<\/b> mus\u00ed sa urobi\u0165 v\u0161etka pr\u00e1ca vidite\u013enou. Nie v tom zmysle, \u017ee by sa musela nutne zobrazi\u0165 na nejakej obrazovke, ale v tom zmysle, \u017ee ju treba by\u0165 mo\u017en\u00e9 pozorova\u0165.<\/li>\n
  2. Konsolidova\u0165 syst\u00e9my spr\u00e1vy pr\u00e1ce:<\/b> je potrebn\u00e9 konsolidova\u0165 syst\u00e9my mana\u017ementu. V probl\u00e9me \u201ekme\u0148ov\u00e9ho\u201c poznania a poznania in\u0161titucion\u00e1lneho je v 9 z 10 pr\u00edpadov \u00fazkym miestom \u010dlovek. V knihe \u201ePhoenix Project\u201c<\/a><\/noindex> probl\u00e9m bol v jednom jedin\u00fdm \u010dloveku, Brente, kv\u00f4li ktor\u00e9mu projekt me\u0161kal tri roky. A na tak\u00fdch \u201eBrentoch\u201c nar\u00e1\u017eam v\u0161ade. Na odstr\u00e1nenie t\u00fdchto \u00fazkych miest pou\u017e\u00edvam nasleduj\u00face dva body v na\u0161om zozname. <\/li>\n
  3. Metodol\u00f3gia te\u00f3rie obmedzen\u00ed:<\/b> te\u00f3ria obmedzen\u00ed.<\/li>\n
  4. Hacky spolupr\u00e1ce:<\/b> hacky spolupr\u00e1ce. <\/li>\n
  5. Toyota Kata (Coaching Kata<\/a><\/noindex>):<\/b> o Toyota Kata nebudem pr\u00edli\u0161 hovori\u0165. Ak v\u00e1s to zauj\u00edma, na mojom GitHube s\u00fa prezent\u00e1cie<\/a><\/noindex> takmer na ka\u017ed\u00fa z t\u00fdchto t\u00e9m. <\/li>\n
  6. Organiz\u00e1cia orientovan\u00e1 na trh:<\/b> orientovan\u00e1 na trh organiz\u00e1cia.<\/li>\n
  7. Aud\u00edtori shift-left:<\/b> aud\u00edt na za\u010diatku cyklu.<\/li>\n<\/ol>\n

    \"Sedem
    \n
    \nZa\u010d\u00ednam pr\u00e1cu s organiz\u00e1ciou ve\u013emi jednoducho: idem do spolo\u010dnosti a rozpr\u00e1vam sa so zamestnancami. Ako vid\u00edme, \u017eiadne vysok\u00e9 technol\u00f3gie. V\u0161etko, \u010do potrebujem, je ma\u0165 na \u010dom p\u00edsa\u0165. Zhroma\u017e\u010fujem nieko\u013eko t\u00edmov v jednej miestnosti a analyzujem to, \u010do mi povedia, z poh\u013eadu mojich 7 archetypov. A potom im d\u00e1m marker a po\u017eiadam ich, aby nap\u00edsali na tabu\u013eu v\u0161etko, \u010do doteraz hovorili nahlas. Zvy\u010dajne na tak\u00fdchto stretnutiach je jeden \u010dlovek, ktor\u00fd v\u0161etko zapisuje, a v tom najlep\u0161om pr\u00edpade sa mu podar\u00ed zaznamena\u0165 10% diskusie. Pri mojej met\u00f3de sa tento \u00fadaj podar\u00ed zv\u00fd\u0161i\u0165 na asi 40%. <\/p>\n

    \"Sedem
    \n
    \n(Samostatne t\u00fato ilustr\u00e1ciu m\u00f4\u017eeme     pozri na odkaze<\/a><\/noindex>)<\/i><\/p>\n

    M\u00f4j pr\u00edstup je zalo\u017een\u00fd na pr\u00e1ci Williama Schneidera (William Schneider, The Reengineering Alternative<\/a><\/noindex>). V z\u00e1klade pr\u00edstupu le\u017e\u00ed my\u0161lienka, \u017ee ak\u00fako\u013evek organiz\u00e1ciu mo\u017eno rozdeli\u0165 na \u0161tyri \u0161tvorce. T\u00e1to sch\u00e9ma zvy\u010dajne vych\u00e1dza z pr\u00e1ce s t\u00fdmi stovkami in\u00fdch sch\u00e9m, ktor\u00e9 vznikaj\u00fa pri anal\u00fdze organiz\u00e1cie. Predpokladajme, \u017ee m\u00e1me organiz\u00e1ciu s vysokou \u00farov\u0148ou kontroly, ale s n\u00edzkou kompetenciou. To je ve\u013emi ne\u017eiaduci variant: ke\u010f v\u0161etci chodia po \u0161n\u00farkach, ale nikto nevie, \u010do m\u00e1 robi\u0165. <\/p>\n

    Trochu lep\u0161ia mo\u017enos\u0165 s vysokou \u00farov\u0148ou kontroly a kompetencie. Ak m\u00e1 tak\u00e1to spolo\u010dnos\u0165 zisk, mo\u017eno, \u017ee DevOps ani nepotrebuje. Najzauj\u00edmavej\u0161ie je pracova\u0165 so spolo\u010dnos\u0165ou, ktor\u00e1 m\u00e1 vysok\u00fa \u00farove\u0148 kontroly, n\u00edzku kompetenciu a spolupr\u00e1cu, ale z\u00e1rove\u0148 vysok\u00fa \u00farove\u0148 kult\u00fary (cultivation). To znamen\u00e1, \u017ee v spolo\u010dnosti je ve\u013ea \u013eud\u00ed, ktor\u00ed tam radi pracuj\u00fa, a fluktu\u00e1cia pracovn\u00edkov je n\u00edzka. <\/p>\n

    \"Sedem
    \n
    \n(Samostatne t\u00fato ilustr\u00e1ciu m\u00f4\u017eeme     pozri na odkaze<\/a><\/noindex>)<\/i><\/p>\n

    Mysl\u00edm, \u017ee met\u00f3dy so striktne predp\u00edsan\u00fdmi odpor\u00fa\u010daniami v kone\u010dnom d\u00f4sledku br\u00e1nia dosiahnu\u0165 pravdu. Konkr\u00e9tne v value stream mapping je ve\u013ea pravidiel, ako treba \u0161trukt\u00farova\u0165 inform\u00e1cie. V po\u010diato\u010dn\u00fdch f\u00e1zach pr\u00e1ce, o ktor\u00fdch hovor\u00edm, tieto pravidl\u00e1 nikomu nie s\u00fa potrebn\u00e9. Ak \u010dlovek s fixkou v ruke popisuje na tabuli re\u00e1lnu situ\u00e1ciu v spolo\u010dnosti \u2014 to je najlep\u0161\u00ed sp\u00f4sob, ako pochopi\u0165, ako to funguje. Tak\u00e9to inform\u00e1cie sa nedostan\u00fa k riadite\u013eom. V tejto chv\u00edli je hl\u00fape preru\u0161i\u0165 \u010dloveka a poveda\u0165, \u017ee zle nakreslil nejak\u00fa \u0161\u00edpku. V tomto \u0161t\u00e1diu je lep\u0161ie dodr\u017eiava\u0165 jednoduch\u00e9 pravidl\u00e1, napr\u00edklad: viac\u00farov\u0148ov\u00fa abstrakciu je mo\u017en\u00e9 vytvori\u0165 jednoducho pou\u017eit\u00edm farebn\u00fdch fixiek. <\/p>\n

    Opakujem, \u017eiadne vysok\u00e9 technol\u00f3gie. \u010ciernou fixkou sa zobrazuje objekt\u00edvna realita, ako v\u0161etko funguje. \u010cervenou fixkou \u013eudia ozna\u010duj\u00fa, \u010do im na existuj\u00facom stave nevyhovuje. D\u00f4le\u017eit\u00e9 je, \u017ee to p\u00ed\u0161u oni, nie ja. Ke\u010f po stretnut\u00ed idem za riadite\u013eom IT, nenavrhnem zoznam 10 vec\u00ed, ktor\u00e9 treba opravi\u0165. Sna\u017e\u00edm sa n\u00e1js\u0165 s\u00favislosti medzi t\u00fdm, \u010do hovoria \u013eudia zo spolo\u010dnosti, a existuj\u00facimi overen\u00fdmi vzormi. Nakoniec, modrou fixkou s\u00fa navrhovan\u00e9 mo\u017en\u00e9 rie\u0161enia probl\u00e9mu. <\/p>\n

    \"Sedem
    \n
    \n(Samostatne t\u00fato ilustr\u00e1ciu m\u00f4\u017eeme     pozri na odkaze<\/a><\/noindex>)<\/i><\/p>\n

    Pr\u00edklad tak\u00e9hoto pr\u00edstupu je zobrazen\u00fd vy\u0161\u0161ie. Na za\u010diatku tohto roka som pracoval s jednou bankou. Zamestnanci z oddelenia bezpe\u010dnosti boli presved\u010den\u00ed, \u017ee nem\u00f4\u017eu prich\u00e1dza\u0165 na kontroly po\u017eiadaviek a n\u00e1vrhu (design and requirement reviews). <\/p>\n

    \"Sedem
    \n
    \n(Samostatne t\u00fato ilustr\u00e1ciu m\u00f4\u017eeme     pozri na odkaze<\/a><\/noindex>)<\/i><\/p>\n

    Potom sme sa porozpr\u00e1vali s \u013eu\u010fmi z in\u00fdch oddelen\u00ed a zistili sme, \u017ee asi pred 8 rokmi v\u00fdvoj\u00e1ri softv\u00e9ru vyl\u00fa\u010dili zamestnancov bezpe\u010dnosti, preto\u017ee t\u00ed spoma\u013eovali pr\u00e1cu. A potom sa to premenilo na z\u00e1kaz, ktor\u00fd bol vn\u00edman\u00fd ako fakt. Hoci v skuto\u010dnosti \u017eiadny z\u00e1kaz neexistoval. <\/p>\n

    Na\u0161a sch\u00f4dzka prebiehala ve\u013emi zlo\u017eito: po\u010das nie\u010doho okolo troch hod\u00edn sa p\u00e4\u0165 r\u00f4znych t\u00edmov nedok\u00e1zalo dohodn\u00fa\u0165, \u010do sa deje medzi k\u00f3dom a zostaven\u00edm. A to by sa zdalo, \u017ee je to najjednoduch\u0161ia vec. V\u00e4\u010d\u0161ina konzultantov DevOps predpoklad\u00e1, \u017ee je to u\u017e v\u0161etk\u00fdm jasn\u00e9. <\/p>\n

    Potom sa osoba zodpovedn\u00e1 za regul\u00e1ciu IT (IT governance), ktor\u00e1 predt\u00fdm \u0161tyri hodiny ml\u010dala, zrazu o\u017eila, ke\u010f sme pre\u0161li na jeho t\u00e9mu, a zamestnala n\u00e1s e\u0161te na celkom dlh\u00fd \u010das. Na konci som sa ho sp\u00fdtal, \u010do si mysl\u00ed o stretnut\u00ed, a nikdy nezabudnem na jeho odpove\u010f. Povedal: \u201ePredt\u00fdm som si myslel, \u017ee v na\u0161ej banke s\u00fa len dva sp\u00f4soby dodania softv\u00e9ru, a teraz viem, \u017ee ich je dokonca p\u00e4\u0165, a o troch som ani netu\u0161il.\u201c <\/p>\n

    \"Sedem
    \n
    \n(Samostatne t\u00fato ilustr\u00e1ciu m\u00f4\u017eeme     pozri na odkaze<\/a><\/noindex>)<\/i><\/p>\n

    Posledn\u00e9 stretnutie v tejto banke bolo s t\u00edmom, ktor\u00fd sa zaober\u00e1 softv\u00e9rom pre invest\u00edcie. Pr\u00e1ve s n\u00edm sa uk\u00e1zalo, \u017ee je lep\u0161ie p\u00edsa\u0165 sch\u00e9my fixkami na papieri ako na tabuli, a dokonca lep\u0161ie ako na smartboarde. <\/p>\n

    \"Sedem
    \n
    \nFotografie, ktor\u00e9 vid\u00edte, s\u00fa z konferen\u010dnej miestnosti hotela po\u010das \u0161tvrt\u00e9ho d\u0148a na\u0161ej sch\u00f4dzky. Tieto sch\u00e9my sme pou\u017e\u00edvali na identifik\u00e1ciu vzorcov, teda archetypov. <\/p>\n

    Tak\u017ee kladiem ot\u00e1zky zamestnancom, zapisuj\u00fa si odpovede fixkami troch farieb (\u010diernou, \u010dervenou a modrou). Ich odpovede analyzujem z h\u013eadiska archetypov. Teraz si po\u010fme prejs\u0165 v\u0161etky archetypy po poriadku. <\/p>\n

    1. Make All Work Visible: Spr\u00edstupni\u0165 v\u0161etku pr\u00e1cu<\/h3>\n

    \nVo v\u00e4\u010d\u0161ine spolo\u010dnost\u00ed, s ktor\u00fdmi pracujem, je ve\u013emi vysok\u00e9 percento nezn\u00e1mej pr\u00e1ce. Napr\u00edklad, ke\u010f jeden zamestnanec pr\u00edde k druh\u00e9mu a jednoducho ho po\u017eiada, aby nie\u010do urobil. Vo ve\u013ek\u00fdch organiz\u00e1ci\u00e1ch m\u00f4\u017ee by\u0165 60 % nepl\u00e1novanej pr\u00e1ce. A a\u017e 40 % pr\u00e1ce nie je nijako zdokumentovan\u00e9. Keby to bol Boeing, tak by som sa nikdy viac nenast\u00fapil do ich lietadla. Ak je zdokumentovan\u00e1 len polovica pr\u00e1ce, potom nie je jasn\u00e9, \u010di sa t\u00e1 pr\u00e1ca vykon\u00e1va spr\u00e1vne alebo nie. V\u0161etky ostatn\u00e9 met\u00f3dy sa ukazuj\u00fa ako zbyto\u010dn\u00e9 \u2014 nem\u00e1 zmysel pok\u00fa\u0161a\u0165 sa o automatiz\u00e1ciu, preto\u017ee zn\u00e1mych 50 % m\u00f4\u017ee by\u0165 pr\u00e1ve tou najkoordinovanej\u0161ou a najpresnej\u0161ou \u010das\u0165ou pr\u00e1ce, ktorej automatiz\u00e1cia neprinesie ve\u013ek\u00e9 v\u00fdsledky, a v\u0161etko najhor\u0161ie je v nevidite\u013enej polovici. Pri absencii dokument\u00e1cie nie je mo\u017en\u00e9 n\u00e1js\u0165 r\u00f4zne hacky a skryt\u00fa pr\u00e1cu, nezh\u013ead\u00e1 sa \u00fazke miesto, tzv. \u201eBrentovia\u201c, o ktor\u00fdch som u\u017e hovoril. Existuje skvel\u00e1 kniha od Dominiky De Grandis. \u201eMaking Work Visible\u201c<\/a><\/noindex>. Odha\u013euje p\u00e4\u0165 r\u00f4znych \u201e\u00fanikov \u010dasu\u201c<\/b> (thieves of time):<\/p>\n