{"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\/cs\/blog\/sem-arhetipov-prevrashheniya-po-princzipam-devops","title":{"rendered":"Sedm archetyp\u016f transformace podle princip\u016f DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ot\u00e1zka \u201ejak zav\u00e9st DevOps\u201c se diskutuje u\u017e n\u011bkolik let, ale dobr\u00fdch materi\u00e1l\u016f nen\u00ed p\u0159\u00edli\u0161. N\u011bkdy se stanete ob\u011bt\u00ed reklamy m\u00e9n\u011b chytr\u00fdch consultant\u016f, kte\u0159\u00ed pot\u0159ebuj\u00ed prodat sv\u016fj \u010das, a\u0165 u\u017e to dopadne jakkoliv. N\u011bkdy to jsou mlhav\u00e1, velmi obecn\u00e1 slova o tom, jak megakorporace pluj\u00ed vesm\u00edrem. Vznik\u00e1 ot\u00e1zka: co z toho pro n\u00e1s? V\u00e1\u017een\u00ed autore, m\u016f\u017eete srozumiteln\u011b sepsat sv\u00e9 my\u0161lenky?<\/p>\n

To v\u0161e vypl\u00fdv\u00e1 z toho, \u017ee re\u00e1ln\u00e9 praxe a porozum\u011bn\u00ed v\u00fdsledk\u016fm transformace firemn\u00ed kultury nen\u00ed tak moc. Zm\u011bny v kultu\u0159e jsou dlouhodob\u00e9 z\u00e1le\u017eitosti, jejich\u017e v\u00fdsledky se neprojev\u00ed za t\u00fdden nebo m\u011bs\u00edc. Pot\u0159ebujeme n\u011bkoho dostate\u010dn\u011b zku\u0161en\u00e9ho, kdo za\u017eil, jak se firmy zakl\u00e1daly a rozpadaly v pr\u016fb\u011bhu mnoha let.<\/p>\n

\"Sedm
\n
\nJohn Willis<\/b> \u2014 jeden ze zakladatel\u016f DevOps. John m\u00e1 za sebou des\u00edtky let pr\u00e1ce s velk\u00fdm mno\u017estv\u00edm firem. V posledn\u00ed dob\u011b si John za\u010dal v\u0161\u00edmat specifick\u00fdch vzorc\u016f, kter\u00e9 se v pr\u00e1ci s ka\u017edou z nich objevuj\u00ed. Pou\u017e\u00edvaj\u00edc\u00ed tyto archetypy, John nasm\u011brov\u00e1v\u00e1 firmy na spr\u00e1vnou cestu DevOps transformace. V\u00edce o t\u011bchto archetypech naleznete v p\u0159ekladu jeho p\u0159edn\u00e1\u0161ky z konference DevOops 2018.
\n<\/a><\/noindex>
\n

\r\n \"P\u0159ehr\u00e1t\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

O p\u0159edn\u00e1\u0161ej\u00edc\u00edm:<\/b><\/p>\n

V\u00edce ne\u017e 35 let v IT managementu, pod\u00edlel se na zakl\u00e1d\u00e1n\u00ed p\u0159edch\u016fdce OpenCloud v Canonical, z\u00fa\u010dastnil se 10 startup\u016f, z nich\u017e dva prodal Dell a Docker. Nyn\u00ed je Vice President of DevOps and Digital Practices ve SJ Technologies.<\/p>\n

D\u00e1le \u2014 vypr\u00e1v\u011bn\u00ed z pohledu Johna.<\/b><\/p>\n

Jmenuji se John Willis a nejl\u00e9pe m\u011b najdete na Twitteru, @botchagalupe<\/a><\/noindex>. Ten sam\u00fd pseudonym m\u00e1m na Gmailu a GitHubu. A na tomto odkazu<\/a><\/noindex> m\u016f\u017eete naj\u00edt videonahr\u00e1vky m\u00fdch p\u0159edn\u00e1\u0161ek a k nim prezentace.<\/p>\n

M\u00e1m mnoho sch\u016fzek s CIO r\u016fzn\u00fdch velk\u00fdch spole\u010dnost\u00ed. Velmi \u010dasto si st\u011b\u017euj\u00ed, \u017ee nech\u00e1pou, co je to DevOps, a ti, kdo se to sna\u017e\u00ed vysv\u011btlit, mluv\u00ed o n\u011b\u010dem sv\u00e9m. Dal\u0161\u00ed \u010dastou st\u00ed\u017enost\u00ed je, \u017ee DevOps nefunguje, i kdy\u017e \u0159editel\u00e9 \u00fadajn\u011b d\u011blaj\u00ed v\u0161e, jak bylo vysv\u011btleno. Jedn\u00e1 se o velk\u00e9 spole\u010dnosti, kter\u00e9 existuj\u00ed v\u00edce ne\u017e sto let. Po rozhovorech s nimi jsem dosp\u011bl k z\u00e1v\u011bru, \u017ee pro mnoho probl\u00e9m\u016f jsou lep\u0161\u00ed nevysoce technologick\u00e1, ale relativn\u011b n\u00edzkot\u0435\u0445\u043d\u043e\u043b\u043e\u0433ick\u00e1 \u0159e\u0161en\u00ed. M\u011bs\u00edce jsem se prost\u011b bavil s lidmi z r\u016fzn\u00fdch odd\u011blen\u00ed. To, co vid\u00edte na prvn\u00ed obr\u00e1zku v p\u0159\u00edsp\u011bvku, je m\u016fj posledn\u00ed projekt, m\u00edstnost tak vypadala po t\u0159ech dnech pr\u00e1ce.<\/p>\n

Co je DevOps?<\/h2>\n

\nOpravdu, pokud se zept\u00e1te 10 r\u016fzn\u00fdch lid\u00ed, daj\u00ed v\u00e1m 10 r\u016fzn\u00fdch odpov\u011bd\u00ed. Ale co je zaj\u00edmav\u00e9: v\u0161echny tyto odpov\u011bdi budou spr\u00e1vn\u00e9. Nespr\u00e1vn\u00e1 odpov\u011b\u010f zde neexistuje. DevOps se v\u011bnuji pom\u011brn\u011b hluboce, asi 10 let, byl jsem prvn\u00edm Ameri\u010danem na prvn\u00edm DevOpsDays. Ne\u0159eknu, \u017ee jsem chyt\u0159ej\u0161\u00ed ne\u017e ti, kdo se zab\u00fdvaj\u00ed DevOps, ale st\u011b\u017e\u00ed existuje n\u011bkdo, kdo na to vynalo\u017eil tolik \u00fasil\u00ed. Domn\u00edv\u00e1m se, \u017ee DevOps vznik\u00e1, kdy\u017e se spoj\u00ed lidsk\u00fd kapit\u00e1l a technologie. \u010casto zapom\u00edn\u00e1me na lidsk\u00fd rozm\u011br, i kdy\u017e mluv\u00edme o r\u016fzn\u00fdch kultur\u00e1ch. <\/p>\n

\"Sedm
\n
\nNyn\u00ed m\u00e1me mnoho dat, p\u011bt let akademick\u00e9ho v\u00fdzkumu, teorie ov\u011b\u0159en\u00e9 v pr\u016fmyslov\u00fdch m\u011b\u0159\u00edtk\u00e1ch. Tento v\u00fdzkum n\u00e1m \u0159\u00edk\u00e1 n\u00e1sleduj\u00edc\u00ed: pokud v organiza\u010dn\u00ed kultu\u0159e spoj\u00edte ur\u010dit\u00e9 behavior\u00e1ln\u00ed vzory, m\u016f\u017eete dos\u00e1hnout zrychlen\u00ed a\u017e 2000kr\u00e1t. Tomu zrychlen\u00ed odpov\u00edd\u00e1 stejn\u00e9 zlep\u0161en\u00ed v odolnosti. To je kvantitativn\u00ed m\u011b\u0159en\u00ed v\u00fdhody, kterou m\u016f\u017ee DevOps poskytnout jak\u00e9koli spole\u010dnosti. P\u0159ed n\u011bkolika lety jsem vypr\u00e1v\u011bl o DevOps gener\u00e1ln\u00edmu \u0159editeli spole\u010dnosti z seznamu Fortune 5000. Kdy\u017e jsem se p\u0159ipravoval na prezentaci, byl jsem velmi nerv\u00f3zn\u00ed, proto\u017ee jsem pot\u0159eboval b\u011bhem 5 minut shrnout sv\u00e9 mnohalet\u00e9 zku\u0161enosti. <\/p>\n

Nakonec jsem uvedl n\u00e1sleduj\u00edc\u00ed definici DevOps<\/b>: je to soubor praktik a vzor\u016f, kter\u00e9 umo\u017e\u0148uj\u00ed prom\u011bnit lidsk\u00fd kapit\u00e1l v vysoce v\u00fdkonn\u00fd organiza\u010dn\u00ed kapit\u00e1l. P\u0159\u00edkladem je to, jak posledn\u00edch 50 nebo 60 let funguje Toyota.<\/p>\n

\"Sedm
\n
\n(Tyto sch\u00e9mata jsou uv\u00e1d\u011bna ne jako referen\u010dn\u00ed materi\u00e1l, ale jako ilustrace. Jejich obsah se bude li\u0161it pro ka\u017edou novou spole\u010dnost. Nicm\u00e9n\u011b obr\u00e1zek si lze prohl\u00e9dnout a zv\u011bt\u0161it) na tomto odkazu.)<\/a><\/noindex><\/i><\/p>\n

Jedna z nej\u00fasp\u011b\u0161n\u011bj\u0161\u00edch takov\u00fdch praktik \u2014 mapov\u00e1n\u00ed hodnotov\u00e9ho toku<\/b>. O tom bylo naps\u00e1no n\u011bkolik dobr\u00fdch knih, autorem nej\u00fasp\u011b\u0161n\u011bj\u0161\u00ed z nich je Karen Martin. Ale za posledn\u00ed rok jsem dosp\u011bl k z\u00e1v\u011bru, \u017ee i tento p\u0159\u00edstup je p\u0159\u00edli\u0161 vysoce technologick\u00fd. Ur\u010dit\u011b m\u00e1 spoustu v\u00fdhod, hodn\u011b jsem jich pou\u017e\u00edval. Ale kdy\u017e se gener\u00e1ln\u00ed \u0159editel pt\u00e1, pro\u010d jeho spole\u010dnost nem\u016f\u017ee p\u0159ej\u00edt na nov\u00e9 koleje, o mapov\u00e1n\u00ed hodnotov\u00e9ho toku je je\u0161t\u011b brzy mluvit. Existuje spousta podstatn\u011b fundament\u00e1ln\u011bj\u0161\u00edch ot\u00e1zek, na kter\u00e9 je t\u0159eba nejprve naj\u00edt odpov\u011bdi. <\/p>\n

Mysl\u00edm, \u017ee chybou mnoha m\u00fdch koleg\u016f je, \u017ee prost\u011b daj\u00ed spole\u010dnosti n\u00e1vod v p\u011bti bodech a pak se vr\u00e1t\u00ed za \u0161est m\u011bs\u00edc\u016f a pod\u00edvaj\u00ed se, co se stalo. I dobr\u00e9 sch\u00e9ma jako mapov\u00e1n\u00ed hodnotov\u00e9ho toku m\u00e1, \u0159ekn\u011bme, mrtv\u00e9 z\u00f3ny (blind spots). Po stovk\u00e1ch rozhovor\u016f s \u0159editeli r\u016fzn\u00fdch spole\u010dnost\u00ed jsem si vytvo\u0159il ur\u010dit\u00fd vzor, kter\u00fd umo\u017e\u0148uje rozlo\u017eit probl\u00e9m na sou\u010d\u00e1sti, a nyn\u00ed si postupn\u011b probereme ka\u017edou z t\u011bchto sou\u010d\u00e1st\u00ed. Ne\u017e pou\u017eiji jak\u00e1koli technologick\u00e1 \u0159e\u0161en\u00ed, pou\u017eiji tento vzor, a v\u00fdsledkem je, \u017ee m\u00e1m v\u0161echny st\u011bny pokryt\u00e9 sch\u00e9maty. Ned\u00e1vno jsem pracoval s jedn\u00edm vz\u00e1jemn\u00fdm fondem, a m\u011bl jsem nakonec 100-150 takov\u00fdch sch\u00e9mat.<\/p>\n

\u0160patn\u00e1 kultura sn\u00ed dobr\u00e9 p\u0159\u00edstupy k sn\u00eddani<\/h2>\n

\nHlavn\u00ed my\u0161lenka je takov\u00e1: \u017e\u00e1dn\u00e9 Lean, Agile, SAFE a DevOps nepomohou, pokud je sama kultura organizace \u0161patn\u00e1. Je to jako pot\u00e1p\u011bt se do hloubky bez kysl\u00edkov\u00e9ho p\u0159\u00edstroje nebo prov\u00e1d\u011bt operaci bez rentgenov\u00e9ho sn\u00edmku. Jin\u00fdmi slovy, parafr\u00e1zuj\u00edce Druckera a Deminga: \u0161patn\u00e1 organiza\u010dn\u00ed kultura pohlt\u00ed jak\u00fdkoli dobr\u00fd syst\u00e9m a nezadus\u00ed se. <\/p>\n

Abychom vy\u0159e\u0161ili tento hlavn\u00ed probl\u00e9m, je t\u0159eba podniknout n\u00e1sleduj\u00edc\u00ed kroky:<\/p>\n

    \n
  1. Zviditeln\u011bte ve\u0161kerou pr\u00e1ci:<\/b> je t\u0159eba u\u010dinit ve\u0161kerou pr\u00e1ci viditelnou. Ne v tom smyslu, \u017ee by se nutn\u011b musela zobrazovat na n\u011bjak\u00e9 obrazovce, ale v tom smyslu, \u017ee by m\u011bla b\u00fdt pozorovateln\u00e1.<\/li>\n
  2. Konsolidujte syst\u00e9my \u0159\u00edzen\u00ed pr\u00e1ce:<\/b> je nutn\u00e9 konsolidovat syst\u00e9my managementu. V probl\u00e9mu \u201ekmenov\u00fdch\u201c znalost\u00ed a institucion\u00e1ln\u00edch znalost\u00ed je v 9 p\u0159\u00edpadech z 10 \u00fazk\u00fdm m\u00edstem lidsk\u00fd faktor. V knize \u201ePhoenix Project\u201c<\/a><\/noindex> byl probl\u00e9m v jednom jedin\u00e9m \u010dlov\u011bku, Brentu, kv\u016fli kter\u00e9mu projekt zaost\u00e1val o t\u0159i roky. A na takov\u00e9 \u201eBrenty\u201c nar\u00e1\u017e\u00edm v\u0161ude. K \u0159e\u0161en\u00ed t\u011bchto \u00fazk\u00fdch m\u00edst pou\u017e\u00edv\u00e1m n\u00e1sleduj\u00edc\u00ed dva body ze na\u0161eho seznamu. <\/li>\n
  3. Metodologie Teorie omezen\u00ed:<\/b> teorie omezen\u00ed.<\/li>\n
  4. Zlep\u0161en\u00ed spolupr\u00e1ce:<\/b> hacky spolupr\u00e1ce. <\/li>\n
  5. Toyota Kata (Coaching Kata<\/a><\/noindex>):<\/b> o Toyota Kata nebudu dlouze hovo\u0159it. Pokud v\u00e1s to zaj\u00edm\u00e1, na m\u00e9m githubu jsou prezentace<\/a><\/noindex> t\u00e9m\u011b\u0159 o ka\u017ed\u00e9m z t\u011bchto t\u00e9mat. <\/li>\n
  6. Organizace orientovan\u00e1 na trh:<\/b> tr\u017en\u011b orientovan\u00e1 organizace.<\/li>\n
  7. Shift-left audito\u0159i:<\/b> audit v ran\u00fdch f\u00e1z\u00edch cyklu.<\/li>\n<\/ol>\n

    \"Sedm
    \n
    \nPr\u00e1ci s organizac\u00ed za\u010d\u00edn\u00e1m velmi jednodu\u0161e: jdu do spole\u010dnosti a rozhoduji se s zam\u011bstnanci. Jak vid\u00edme, \u017e\u00e1dn\u00e9 vysok\u00e9 technologie. V\u0161e, co pot\u0159ebujete, je m\u00edt na \u010dem ps\u00e1t. Shroma\u017e\u010fuji n\u011bkolik t\u00fdm\u016f v jedn\u00e9 m\u00edstnosti a analyzuji to, co mi \u0159\u00edkaj\u00ed, z pohledu sv\u00fdch 7 archetyp\u016f. A pak jim d\u00e1m sami fixu a po\u017e\u00e1d\u00e1m je, aby v kostce napsali na tabuli v\u0161e, co dosud \u0159\u00edkali nahlas. Obvykle na takov\u00fdch sch\u016fzk\u00e1ch je jeden \u010dlov\u011bk, kter\u00fd v\u0161e zapisuje, a v tom nejlep\u0161\u00edm p\u0159\u00edpad\u011b se mu poda\u0159\u00ed zapsat 10 % diskuze. P\u0159i m\u00e9 metod\u011b se tento \u00fadaj poda\u0159\u00ed zv\u00fd\u0161it na cca 40%. <\/p>\n

    \"Sedm
    \n
    \n(Tento obr\u00e1zek si lze     prohl\u00e9dnout na odkazu<\/a><\/noindex>)<\/i><\/p>\n

    M\u016fj p\u0159\u00edstup je zalo\u017een na pr\u00e1ci Williama Schneidera (William Schneider, The Reengineering Alternative<\/a><\/noindex>). Z\u00e1kladem p\u0159\u00edstupu je my\u0161lenka, \u017ee jakoukoli organizaci lze rozlo\u017eit na \u010dty\u0159i \u010dtverce. Tato sch\u00e9ma b\u00fdv\u00e1 obvykle v\u00fdsledkem pr\u00e1ce s t\u011bmi stovkami dal\u0161\u00edch sch\u00e9mat, kter\u00e9 se objev\u00ed p\u0159i anal\u00fdze organizace. P\u0159edstavme si organizaci s vysokou \u00farovn\u00ed kontroly, ale s n\u00edzkou kompetenc\u00ed. To je krajn\u011b ne\u017e\u00e1douc\u00ed varianta: kdy\u017e v\u0161ichni chod\u00ed jako ve strun\u011b, ale nikdo nev\u00ed, co m\u00e1 d\u011blat. <\/p>\n

    O n\u011bco lep\u0161\u00ed varianta s vysokou \u00farovn\u00ed kontroly a kompetence. Pokud m\u00e1 takov\u00e1 spole\u010dnost zisk, mo\u017en\u00e1 DevOps ani nepot\u0159ebuje. Nejd\u016fle\u017eit\u011bj\u0161\u00ed je spolupracovat se spole\u010dnost\u00ed, kter\u00e1 m\u00e1 vysokou \u00farove\u0148 kontroly, n\u00edzkou kompetenci a spolupr\u00e1ci, ale z\u00e1rove\u0148 vysokou \u00farove\u0148 kultury (cultivation). To znamen\u00e1, \u017ee ve spole\u010dnosti je mnoho lid\u00ed, kter\u00fdm se tam l\u00edb\u00ed pracovat, a fluktuace pracovn\u00ed s\u00edly je n\u00edzk\u00e1. <\/p>\n

    \"Sedm
    \n
    \n(Tento obr\u00e1zek si lze     prohl\u00e9dnout na odkazu<\/a><\/noindex>)<\/i><\/p>\n

    Mysl\u00edm si, \u017ee metody s pevn\u011b stanoven\u00fdmi doporu\u010den\u00edmi nakonec br\u00e1n\u00ed dos\u00e1hnout pravdy. Zejm\u00e9na ve value stream mappingu existuje mnoho pravidel o tom, jak by m\u011bly b\u00fdt informace strukturov\u00e1ny. V ran\u00fdch f\u00e1z\u00edch pr\u00e1ce, o kter\u00fdch te\u010f mluv\u00edm, tato pravidla nikomu nejsou pot\u0159eba. Pokud \u010dlov\u011bk s markerem v ruce popisuje na tabuli skute\u010dnou situaci ve firm\u011b \u2014 to je nejlep\u0161\u00ed zp\u016fsob, jak se dostat do obrazu. Takov\u00e9 informace se k \u0159editel\u016fm nedostanou. V tuto chv\u00edli je hloup\u00e9 p\u0159eru\u0161ovat \u010dlov\u011bka a \u0159\u00edkat mu, \u017ee \u0161patn\u011b nakreslil n\u011bjakou \u0161ipku. V t\u00e9to f\u00e1zi je lep\u0161\u00ed dodr\u017eovat jednoduch\u00e1 pravidla, nap\u0159\u00edklad: v\u00edcestup\u0148ovou abstrakci lze vytvo\u0159it prost\u00fdm pou\u017eit\u00edm r\u016fznobarevn\u00fdch marker\u016f. <\/p>\n

    Opakuji, \u017e\u00e1dn\u00e9 vysok\u00e9 technologie. \u010cern\u00fdm markerem se zn\u00e1zor\u0148uje objektivn\u00ed realita, jak to v\u0161echno funguje. \u010cerven\u00fdm markerem lid\u00e9 ozna\u010duj\u00ed, co se jim na sou\u010dasn\u00e9m stavu nel\u00edb\u00ed. D\u016fle\u017eit\u00e9 je, \u017ee to p\u00ed\u0161\u00ed oni, a ne j\u00e1. Kdy\u017e po sch\u016fzi jdu za \u0159editelem IT, nenavrhuji seznam 10 v\u011bc\u00ed, kter\u00e9 je t\u0159eba opravit. Sna\u017e\u00edm se naj\u00edt souvislosti mezi t\u00edm, co \u0159\u00edkaj\u00ed lid\u00e9 ve firm\u011b, a existuj\u00edc\u00edmi ov\u011b\u0159en\u00fdmi vzorci. Nakonec modr\u00fdm markerem navrhuji mo\u017en\u00e1 \u0159e\u0161en\u00ed probl\u00e9mu. <\/p>\n

    \"Sedm
    \n
    \n(Tento obr\u00e1zek si lze     prohl\u00e9dnout na odkazu<\/a><\/noindex>)<\/i><\/p>\n

    P\u0159\u00edklad takov\u00e9ho p\u0159\u00edstupu je nyn\u00ed zn\u00e1zorn\u011bn v\u00fd\u0161e. Na za\u010d\u00e1tku tohoto roku jsem pracoval s jednou bankou. Zam\u011bstnanci odd\u011blen\u00ed bezpe\u010dnosti byli p\u0159esv\u011bd\u010deni, \u017ee nemohou p\u0159ich\u00e1zet na kontroly po\u017eadavk\u016f a n\u00e1vrh\u016f (design and requirement reviews). <\/p>\n

    \"Sedm
    \n
    \n(Tento obr\u00e1zek si lze     prohl\u00e9dnout na odkazu<\/a><\/noindex>)<\/i><\/p>\n

    A pak jsme mluvili s lidmi z jin\u00fdch odd\u011blen\u00ed a zjistili jsme, \u017ee p\u0159ibli\u017en\u011b p\u0159ed 8 lety vyhodili pracovn\u00edky bezpe\u010dnosti, proto\u017ee zpomalovali pr\u00e1ci. A pak se to zm\u011bnilo v z\u00e1kaz, kter\u00fd byl vn\u00edm\u00e1n jako danost. A\u010dkoli ve skute\u010dnosti \u017e\u00e1dn\u00fd z\u00e1kaz neexistoval. <\/p>\n

    Na\u0161e setk\u00e1n\u00ed prob\u00edhalo velmi zmaten\u011b: b\u011bhem asi t\u0159\u00ed hodin p\u011bt r\u016fzn\u00fdch t\u00fdm\u016f nebylo schopno mi vysv\u011btlit, co se d\u011bje mezi k\u00f3dem a sestaven\u00edm. A to se zd\u00e1 b\u00fdt ta nejjednodu\u0161\u0161\u00ed v\u011bc. V\u011bt\u0161ina konzultant\u016f DevOps p\u0159edpokl\u00e1d\u00e1, \u017ee je to ji\u017e v\u0161em zn\u00e1mo. <\/p>\n

    Pak se \u010dlov\u011bk zodpov\u011bdn\u00fd za IT governance, kter\u00fd ml\u010del \u010dty\u0159i hodiny, najednou o\u017eil, kdy\u017e jsme p\u0159i\u0161li na jeho t\u00e9ma, a zabrali n\u00e1m je\u0161t\u011b na velmi dlouhou dobu. Na konci jsem se ho zeptal, co si o setk\u00e1n\u00ed mysl\u00ed, a nikdy nezapomenu na jeho odpov\u011b\u010f. \u0158ekl: \u201eD\u0159\u00edve jsem si myslel, \u017ee v na\u0161\u00ed bance jsou pouze dva zp\u016fsoby dod\u00e1n\u00ed softwaru, a te\u010f v\u00edm, \u017ee jich je celkem p\u011bt, a o t\u0159ech jsem ani nep\u0159edpokl\u00e1dal.\u201c <\/p>\n

    \"Sedm
    \n
    \n(Tento obr\u00e1zek si lze     prohl\u00e9dnout na odkazu<\/a><\/noindex>)<\/i><\/p>\n

    Posledn\u00ed setk\u00e1n\u00ed v t\u00e9to bance bylo s t\u00fdmem, kter\u00fd se zab\u00fdv\u00e1 softwarem pro investice. Pr\u00e1v\u011b s n\u00edm se uk\u00e1zalo, \u017ee je lep\u0161\u00ed ps\u00e1t sch\u00e9mata fixem na pap\u00edr ne\u017e na tabuli, a dokonce l\u00e9pe ne\u017e na smartboardu. <\/p>\n

    \"Sedm
    \n
    \nFotografie, kter\u00e9 vid\u00edte, ukazuj\u00ed, jak vypadala konferen\u010dn\u00ed m\u00edstnost hotelu \u010dtvrt\u00fd den na\u0161eho setk\u00e1n\u00ed. A tato sch\u00e9mata jsme pou\u017e\u00edvali k vyhled\u00e1v\u00e1n\u00ed vzorc\u016f, tedy archetyp\u016f. <\/p>\n

    Tak\u017ee pokl\u00e1d\u00e1m ot\u00e1zky zam\u011bstnanc\u016fm, oni zapisuj\u00ed odpov\u011bdi fixy t\u0159ech barev (\u010dern\u00e9, \u010derven\u00e9 a modr\u00e9). Jejich odpov\u011bdi analyzuji z hlediska archetyp\u016f. Te\u010f si poj\u010fme probrat v\u0161echny archetypy postupn\u011b. <\/p>\n

    1. Make All Work Visible: Ud\u011blejte pr\u00e1ci viditelnou<\/h3>\n

    \nVe v\u011bt\u0161in\u011b firem, se kter\u00fdmi pracuji, je velmi vysok\u00e9 procento nezn\u00e1m\u00e9 pr\u00e1ce. Nap\u0159\u00edklad kdy\u017e jeden zam\u011bstnanec p\u0159ijde k druh\u00e9mu a prost\u011b po\u017e\u00e1d\u00e1 o n\u011bco ud\u011blat. V velk\u00fdch organizac\u00edch m\u016f\u017ee b\u00fdt a\u017e 60 % nepl\u00e1novan\u00e9 pr\u00e1ce. A a\u017e 40 % pr\u00e1ce nen\u00ed nijak zdokumentov\u00e1no. Kdyby to byl Boeing, nikdy bych se znovu nenastoupil do jejich letadla. Pokud je zdokumentov\u00e1na pouze polovina prac\u00ed, nen\u00ed jasn\u00e9, zda je tato pr\u00e1ce vykon\u00e1v\u00e1na spr\u00e1vn\u011b \u010di nikoli. V\u0161echny ostatn\u00ed metody se ukazuj\u00ed jako zbyte\u010dn\u00e9 \u2014 nem\u00e1 \u017e\u00e1dn\u00fd smysl se pokou\u0161et n\u011bco automatizovat, proto\u017ee zn\u00e1m\u00fdch 50 % m\u016f\u017ee b\u00fdt pr\u00e1v\u011b tou nejorganizovan\u011bj\u0161\u00ed a nejp\u0159ehledn\u011bj\u0161\u00ed \u010d\u00e1st\u00ed pr\u00e1ce, jej\u00ed\u017e automatizace nep\u0159inese velk\u00e9 v\u00fdsledky, zat\u00edmco to nejhor\u0161\u00ed je v neviditeln\u00e9 \u010d\u00e1sti. Bez dokumentace nen\u00ed mo\u017en\u00e9 naj\u00edt r\u016fzn\u00e9 hacks a skrytou pr\u00e1ci, nenaleznou se \u00fazk\u00e1 m\u00edsta, ti \u201eBrentov\u00e9\u201c, o kter\u00fdch jsem ji\u017e mluvil. Existuje skv\u011bl\u00e1 kniha od Dominiky De Grandis. \u201eMaking Work Visible\u201c<\/a><\/noindex>. Ta odhaluje p\u011bt r\u016fzn\u00fdch \u201e\u00fanik\u016f \u010dasu\u201c<\/b> (thieves of time):<\/p>\n