Tim Lister - spoluautor kníh
- „Ľudský faktor. Úspešné projekty a tímy“ (pôvodná kniha sa volá „Peopleware“)
- „Valčík s medveďmi: Riadenie rizika v softvérových projektoch“
- „Adrenalínom pobláznený a zombifikovaný vzormi. Vzorce správania projektových tímov“
Všetky tieto knihy sú klasikou vo svojom odbore a boli napísané spolu s kolegami v r . V Rusku sú jeho kolegovia najznámejší - и , ktorý napísal aj mnoho slávnych diel.
Tim má 40-ročné skúsenosti s vývojom softvéru; v roku 1975 (nikto z tých, ktorí písali tento habrapost, sa tento rok nenarodil), Tim už bol výkonným viceprezidentom spoločnosti Yourdon Inc. Teraz trávi čas konzultáciami, vyučovaním a písaním s občasnými návštevami konferencie po celom svete.
Špeciálne pre Habra sme urobili rozhovor s Timom Listerom. Bude otvárať konferenciu DevOops 2019 a máme veľa otázok o knihách a ďalších. Rozhovor vedú Michail Druzhinin a Oleg Chirukhin z programového výboru konferencie.
Michael: Môžete povedať pár slov o tom, čo teraz robíte?
Tim: Som vedúcim Cechu atlantických systémov. V Ceche je nás šesť, hovoríme si principálovia. Tri v USA a tri v Európe – preto sa Cech nazýva Atlantik. Sme spolu toľko rokov, že ich jednoducho nespočítate. Všetci máme svoje špeciality. S klientmi pracujem posledné desaťročie alebo viac. Moje projekty zahŕňajú nielen riadenie, ale aj stanovovanie požiadaviek, plánovanie projektov a vyhodnocovanie. Zdá sa, že projekty, ktoré sa zle začínajú, väčšinou zle končia. Preto sa oplatí dbať na to, aby boli všetky aktivity naozaj dobre premyslené a zladené, aby sa spojili nápady tvorcov. Stojí za to premýšľať o tom, čo robíte a prečo. Aké stratégie použiť na dokončenie projektu.
Už mnoho rokov poskytujem klientom poradenstvo rôznymi spôsobmi. Zaujímavá je napríklad firma, ktorá vyrába roboty na operácie kolena a bedrového kĺbu. Chirurg neoperuje úplne samostatne, ale využíva robota. Bezpečnosť je tu, úprimne povedané, dôležitá. Ale keď sa pokúsite diskutovať o požiadavkách s ľuďmi, ktorí sú zameraní na riešenie problémov... Bude to znieť zvláštne, ale v USA je (Federal Drug Administration), ktorá licencuje produkty, ako sú tieto roboty. Predtým, ako niečo predáte a použijete na živých ľuďoch, musíte získať licenciu. Jednou z podmienok je ukázať svoje požiadavky, aké sú testy, ako ste ich testovali, aké sú výsledky testov. Ak zmeníte požiadavky, potom musíte celý tento obrovský testovací proces absolvovať znova a znova. Našim klientom sa podarilo zaradiť vizuálny dizajn aplikácií do svojich požiadaviek. Mali screenshoty priamo ako súčasť požiadaviek. Musíme ich vytiahnuť a vysvetliť, že väčšinou všetky tieto programy nevedia nič o kolenách a bokoch, o všetkých týchto veciach s kamerou atď. Musíme prepísať dokumenty požiadaviek tak, aby sa nikdy nezmenili, pokiaľ sa nezmenia niektoré skutočne dôležité základné podmienky. Ak vizuálny dizajn nie je v požiadavkách, aktualizácia produktu bude oveľa rýchlejšia. Našou úlohou je nájsť tie prvky, ktoré sa zaoberajú operáciami kolena, bedier, chrbta, vytiahnuť ich do samostatných dokumentov a povedať, že to budú základné požiadavky. Urobme izolovanú skupinu požiadaviek na operácie kolena. To nám umožní vytvoriť stabilnejší súbor požiadaviek. Budeme hovoriť o celom produktovom rade a nie o konkrétnych robotoch.
Urobilo sa veľa práce, no aj tak sa dostali na miesta, kde predtým trávili týždne a mesiace opakovaných testov bez zmyslu a potreby, pretože ich požiadavky popísané na papieri sa nezhodovali s reálnymi požiadavkami, pre ktoré boli systémy postavené. FDA im zakaždým povedal: vaše požiadavky sa zmenili, teraz musíte všetko skontrolovať od začiatku. Kompletné opätovné kontroly celého produktu zabíjali podnik.
Existujú teda úžasné úlohy, keď sa ocitnete na samom začiatku niečoho zaujímavého a hneď prvé akcie stanovujú ďalšie pravidlá hry. Ak sa uistíte, že táto raná aktivita začne dobre fungovať z manažérskeho aj technického hľadiska, je šanca, že skončíte so skvelým projektom. Ale ak táto časť zišla z koľají a niekde sa pokazila, ak nemôžete nájsť základné dohody... nie, nie je to tak, že váš projekt nevyhnutne zlyhá. Ale už si nebudete môcť povedať: „Zvládli sme to skvele, všetko sme urobili naozaj efektívne.“ Toto sú veci, ktoré robím pri komunikácii s klientmi.
Michael: To znamená, že spustíte projekty, urobíte nejaký výkop a skontrolujete, či koľajnice idú správnym smerom?
Tim: Máme tiež nápady, ako poskladať všetky časti skladačky: aké zručnosti potrebujeme, kedy presne sú potrebné, ako vyzerá jadro tímu a ďalšie také zásadné veci. Potrebujeme zamestnancov na plný úväzok alebo môžeme zamestnať niekoho na čiastočný úväzok? Plánovanie, riadenie. Otázky typu: Čo je najdôležitejšie pre tento konkrétny projekt? Ako to dosiahnuť? Čo vieme o tomto produkte alebo projekte, aké sú riziká a kde sú neznáme, ako sa s tým všetkým vysporiadame? Samozrejme, v tejto chvíli niekto začne kričať „A čo agilný?!“ Dobre, všetci ste flexibilní, ale čo už? Ako presne projekt vyzerá, ako ho potiahnete tak, aby vyhovoval projektu? Nemôžete jednoducho povedať, že „náš prístup sa vzťahuje na čokoľvek, sme Scrum tím!“ To je nezmysel a nezmysel. Kam sa chystáte ísť ďalej, prečo by to malo fungovať, kde je zmysel? Učím svojich klientov premýšľať o všetkých týchto otázkach.
19 rokov agile
Michael: V Agile sa ľudia často snažia nič nedefinovať dopredu, ale rozhodovať sa čo najneskôr, hovoriac: sme príliš veľkí, nebudem premýšľať o celkovej architektúre. Nebudem myslieť na kopu iných vecí, namiesto toho dodám zákazníkovi niečo, čo práve teraz funguje.
Tim: Myslím si, že agilné metodiky počnúc v roku 2001 otvorila tomuto odvetviu oči. Ale na druhej strane, nič nie je dokonalé. Som za iteratívny vývoj. Iterácia má vo väčšine projektov veľký zmysel. Otázka, na ktorú by ste sa však mali zamyslieť, znie: ako dlho vydrží, keď je produkt vonku a v prevádzke? Je to produkt, ktorý vydrží šesť mesiacov, kým ho nahradí niečo iné? Alebo je to produkt, ktorý bude fungovať mnoho, mnoho rokov? Samozrejme, nebudem menovať mená, ale... V New Yorku a jeho finančnej komunite sú najzákladnejšie systémy veľmi staré. To je úžasné. Pozeráte sa na ne a pomyslíte si, keby ste sa mohli vrátiť v čase, do roku 1994, a poviete vývojárom: „Prišiel som z budúcnosti, z roku 2019. Vyvíjajte tento systém tak dlho, ako budete potrebovať. Urobte to rozšíriteľné, myslite na architektúru. Potom sa bude vylepšovať viac ako dvadsaťpäť rokov. Ak odložíte vývoj trochu dlhšie, vo veľkej schéme vecí si to nikto nevšimne!“ Keď odhadujete veci z dlhodobého hľadiska, musíte zvážiť, koľko to bude celkovo stáť. Niekedy dobre navrhnutá architektúra naozaj stojí za to a niekedy nie. Musíme sa poobzerať okolo seba a položiť si otázku: sme v správnej situácii pre takéto rozhodnutie?
Takže myšlienka typu „Sme za agilitu, zákazník nám sám povie, čo chce získať“ – je super naivná. Zákazníci ani nevedia, čo chcú, a ešte viac nevedia, čo by mohli dostať. Niektorí ľudia začnú uvádzať historické príklady ako argumenty, už som to videl. To ale technicky vyspelí ľudia väčšinou nehovoria. Hovoria: „Je rok 2019, toto sú príležitosti, ktoré máme, a môžeme úplne zmeniť spôsob, akým sa na tieto veci pozeráme!“ Namiesto toho, aby ste napodobňovali existujúce riešenia, robili ich o niečo krajšími a učesanejšími, niekedy musíte ísť von a povedať: „Poďme úplne nanovo vynájsť to, o čo sa tu snažíme!“
A nemyslím si, že väčšina zákazníkov dokáže o probléme takto uvažovať. Vidia len to, čo už majú, to je všetko. Potom prichádzajú s prosbami ako „urobme to trochu jednoduchšie“ alebo ako zvyčajne hovoria. Ale nie sme čašníci ani čašníčky, takže objednávku môžeme prijať akokoľvek hlúpo a potom ju upiecť v kuchyni. Sme ich sprievodcami. Musíme im otvoriť oči a povedať: hej, máme tu nové príležitosti! Uvedomujete si, že môžeme skutočne zmeniť spôsob, akým sa táto časť vášho podnikania robí? Jedným z problémov s Agile je, že odstraňuje povedomie o tom, čo je príležitosť, čo je problém, čo vôbec musíme urobiť, aké dostupné technológie sú pre túto konkrétnu situáciu najvhodnejšie.
Možno som tu príliš skeptický: v agilnej komunite sa deje veľa úžasných vecí. Mám ale problém s tým, že ľudia namiesto zadefinovania projektu začnú rozhadzovať rukami. Tu by som sa opýtal - čo robíme, ako to urobíme? A nejako magicky to vždy dopadne tak, že klient by to mal vedieť lepšie ako ktokoľvek iný. Ale klient najlepšie vie, až keď si vyberá z vecí, ktoré už niekto postavil. Ak si chcem kúpiť auto a poznám veľkosť môjho rodinného rozpočtu, tak si rýchlo vyberiem auto, ktoré vyhovuje môjmu životnému štýlu. Tu viem všetko lepšie ako ktokoľvek iný! Upozorňujeme však, že autá už niekto vyrobil. Netuším, ako vymyslieť nové auto, nie som odborník. Keď vytvárame zákazkové alebo špeciálne produkty, treba brať ohľad na hlas zákazníka, no už to nie je jediný hlas.
Oleg: Spomenuli ste Agile Manifesto. Potrebujeme ho nejako aktualizovať alebo revidovať s ohľadom na moderné chápanie problému?
Tim: Nedotkol by som sa ho. Podľa mňa je to skvelý historický dokument. Chcem povedať, že je taký, aký je. Má 19 rokov, je starý, no svojho času urobil revolúciu. Urobil dobre, že vyvolal reakciu a ľudia si o ňom začali šepkať. V roku 2001 ste s najväčšou pravdepodobnosťou ešte nepracovali v tomto odvetví, ale potom všetci pracovali podľa procesov. Software Engineering Institute, päť úrovní modelu úplnosti softvéru (CMMI). Neviem, či vám takéto legendy hlbokého staroveku niečo hovoria, ale vtedy to bol prielom. Ľudia spočiatku verili, že ak sa procesy nastavia správne, problémy samy od seba zmiznú. A potom príde Manifest a hovorí: „Nie, nie, nie – budeme založený na ľuďoch, nie na procesoch.“ Sme majstri vývoja softvéru. Chápeme, že ideálny proces je fatamorgána; to sa nestane. V projektoch je príliš veľa idiosynkrázie, myšlienka jedného dokonalého procesu pre všetky projekty nedáva zmysel. Problémy sú príliš zložité na to, aby sa dalo tvrdiť, že na všetko existuje len jedno riešenie (ahoj, nirvána).
Nepredpokladám, že sa pozerám do budúcnosti, ale poviem, že ľudia teraz začali viac premýšľať o projektoch. Myslím, že Agile Manifesto je veľmi dobrý v tom, že vyskočí a povie: „Hej! Ste na lodi a vy sami riadite túto loď. Budete sa musieť rozhodnúť – univerzálny recept na všetky situácie vám nenavrhneme. Ste posádkou lode a ak ste dostatočne dobrí, môžete nájsť cestu k svojmu cieľu. Pred vami boli iné lode a po vás budú ďalšie lode, ale aj tak je v istom zmysle vaša cesta jedinečná.“ Niečo také! Je to spôsob myslenia. Pre mňa nie je nič nové pod slnkom, ľudia sa už plavili a plaviť budú, ale pre vás je toto vaša hlavná cesta a čo presne sa vám stane, vám nepoviem. Musíte mať schopnosti koordinovanej práce v tíme a ak ich naozaj máte, všetko pôjde a dostanete sa tam, kam ste chceli.
Peopleware: O 30 rokov neskôr
Oleg: Bol Peopleware revolúciou rovnako ako Manifest?
Tim: Peopleware... Tom a ja sme napísali túto knihu, ale nemysleli sme si, že sa to stane takto. Nejako to zarezonovalo s predstavami mnohých ľudí. Toto bola prvá kniha, ktorá hovorila: vývoj softvéru je veľmi náročná na človeka. Napriek našej technickej povahe sme tiež komunita ľudí, ktorí budujú niečo veľké, dokonca obrovské, veľmi zložité. Nikto nemôže vytvoriť také veci sám, však? Takže myšlienka „tímu“ sa stala veľmi dôležitou. A to nielen z pohľadu manažmentu, ale aj pre technických ľudí, ktorí sa spojili, aby riešili naozaj zložité hlboké problémy s kopou neznámych. Pre mňa osobne to bola obrovská skúška inteligencie počas celej mojej kariéry. A tu si treba vedieť povedať: áno, tento problém je viac, než dokážem sám zvládnuť, ale spoločne dokážeme nájsť elegantné riešenie, na ktoré môžeme byť hrdí. A myslím, že práve táto myšlienka zarezonovala najviac. Myšlienka, že časť času pracujeme sami, časť času ako súčasť skupiny a často o tom rozhoduje skupina. Skupinové riešenie problémov sa rýchlo stalo dôležitou súčasťou komplexných projektov.
Napriek tomu, že Tim predniesol obrovské množstvo prednášok, len veľmi málo z nich je zverejnených na YouTube. Môžete si pozrieť správu „Návrat Peopleware“ z roku 2007. Kvalita, samozrejme, ponecháva veľa požiadaviek.
Michael: Zmenilo sa niečo za posledných 30 rokov od vydania knihy?
Tim: Môžete sa na to pozrieť z mnohých rôznych uhlov pohľadu. Sociologicky povedané... kedysi, v jednoduchších časoch, ste so svojím tímom sedeli v jednej kancelárii. Môžete si byť každý deň nablízku, popíjať spolu kávu a diskutovať o práci. Skutočne sa zmenilo to, že tímy môžu byť teraz distribuované geograficky, v rôznych krajinách a časových pásmach, no stále pracujú na rovnakom probléme, čo pridáva úplne novú vrstvu zložitosti. Môže to znieť ako zo starej školy, ale neexistuje nič ako komunikácia tvárou v tvár, kde ste všetci spolu, pracujete spolu a môžete prísť za kolegom a povedať, pozri, čo som objavil, ako sa ti to páči? Osobné rozhovory poskytujú rýchly spôsob prechodu k neformálnej komunikácii a myslím si, že by sa to malo páčiť aj agilným nadšencom. A tiež sa obávam, pretože v skutočnosti sa svet ukázal ako veľmi malý a teraz je celý pokrytý distribuovanými tímami a všetko je veľmi zložité.
Všetci žijeme v DevOps
Michael: Aj z pohľadu programového výboru konferencie máme ľudí v Kalifornii, v New Yorku, Európe, Rusku... v Singapure zatiaľ nikto nie je. Rozdiel v geografii je dosť veľký a ľudia sa začínajú ešte viac rozširovať. Ak hovoríme o vývoji, môžete nám povedať viac o devops a búraní bariér medzi tímami? Existuje predstava, že každý sedí vo svojich bunkroch a teraz sa bunkre rúcajú, čo si myslíte o tomto prirovnaní?
Tim: Zdá sa mi, že vo svetle nedávnych technologických objavov má devops veľký význam. Predtým ste mali tímy vývojárov a administrátorov, pracovali, pracovali, pracovali a v určitom okamihu sa objavila vec, s ktorou ste mohli prísť za administrátormi a rozbehnúť to do produkcie. A tu sa začala konverzácia o bunkri, pretože admini sú tak trochu spojenci, aspoň nie nepriatelia, ale rozprávali ste sa s nimi, až keď bolo všetko pripravené na výrobu. Išli ste za nimi s niečím a povedali: Pozrite, akú aplikáciu máme, ale mohli by ste túto aplikáciu spustiť? A teraz sa celý koncept doručovania zmenil k lepšiemu. Myslím tým, že tu bol nápad, že by ste mohli rýchlo presadiť zmeny. Môžeme aktualizovať produkty za chodu. Vždy sa usmievam, keď sa na mojom notebooku objaví Firefox a povie, hej, aktualizovali sme váš Firefox na pozadí, a akonáhle budete mať chvíľu, môžete kliknúť sem a my vám poskytneme najnovšiu verziu. A ja som povedal: "Ach áno, zlatko!" Kým som spal, pracovali na tom, aby mi doručili nové vydanie priamo do môjho počítača. Toto je úžasné, neuveriteľné.
Ale tu je problém: máte túto funkciu s aktualizáciou softvéru, ale integrácia ľudí je oveľa zložitejšia. To, čo by som chcel povedať na keynote DevOops, je, že teraz máme oveľa viac hráčov, ako sme kedy mali. Ak si len spomeniete na všetkých zúčastnených v jednom tíme... Mysleli ste si to ako tím a je to oveľa viac než len tím programátorov. Sú to testeri, projektoví manažéri a kopa ďalších ľudí. A každý má svoj vlastný pohľad na svet. Produktoví manažéri sú úplne iní ako projektoví manažéri. Správcovia majú svoje vlastné úlohy. Skoordinovať všetkých účastníkov tak, aby si boli vedomí toho, čo sa deje, a nezbláznili sa, sa stáva pomerne zložitým problémom. Je potrebné oddeliť úlohy skupiny a úlohy, ktoré platia pre všetkých. To je veľmi náročná úloha. Na druhej strane si myslím, že je to všetko oveľa lepšie ako pred mnohými rokmi. To je presne tá cesta, na ktorej ľudia rastú a učia sa správať správne. Keď robíte integráciu, chápete, že by nemalo dôjsť k žiadnemu podzemnému vývoju, aby sa softvér na poslednú chvíľu nevyplazil ako jack-in-the-box: ako, pozrite sa, čo sme tu urobili! Myšlienkou je, že budete môcť robiť integráciu a vývoj a na konci sa rozviniete úhľadným a opakovaným spôsobom. Toto všetko pre mňa veľa znamená. To umožňuje vytvoriť väčšiu hodnotu pre používateľov systému a pre vášho klienta.
Michael: Celá myšlienka devops je poskytnúť zmysluplný vývoj čo najskôr. Vidím, že svet sa začal čoraz viac zrýchľovať. Ako sa prispôsobiť takýmto zrýchleniam? Pred desiatimi rokmi toto neexistovalo!
Tim: Samozrejme, každý chce stále viac funkcií. Netreba sa hýbať, stačí nahromadiť ďalšie. Niekedy dokonca musíte spomaliť, aby ďalšia prírastková aktualizácia priniesla niečo užitočné – a to je úplne normálne.
Predstava, že treba bežať, bežať, bežať, nie je najlepšia. Je nepravdepodobné, že by niekto chcel takto žiť svoj život. Bol by som rád, keby rytmus dodávok udával vlastný rytmus projektu. Ak len vytvoríte prúd malých, relatívne nezmyselných vecí, všetko to nedáva zmysel. Namiesto bezmyšlienkovej snahy vydať veci čo najskôr, stojí za to prediskutovať s hlavnými vývojármi a produktovými a projektovými manažérmi stratégia. Má toto vôbec zmysel?
Vzory a antivzory
Oleg: Zvyčajne hovoríte o vzoroch a antivzorcoch a to je rozdiel medzi životom a smrťou projektov. A teraz do našich životov vtrhne devops. Má nejaké vlastné vzory a antivzory, ktoré môžu projekt na mieste zabiť?
Tim: Vzory a anti-vzory sa vyskytujú neustále. Niečo na rozhovor. No, je tu vec, ktorú nazývame „lesklé veci“. Ľudia majú naozaj radi nové technológie. Jednoducho ich očarí lesk všetkého, čo vyzerá cool a štýlovo, a prestanú sa pýtať: je to vôbec potrebné? Čo tým dosiahneme? Je táto vec spoľahlivá, má to nejaký zmysel? Často vidím ľudí, takpovediac, na špičkovej technológii. Sú hypnotizovaní tým, čo sa deje vo svete. Ak sa však bližšie pozriete na to, aké užitočné veci robia, často tam jednoducho nie je nič užitočné!
Práve sme diskutovali so súdruhmi, že tento rok je jubilejný rok, päťdesiat rokov od pristátia ľudí na Mesiaci. Bolo to v roku 1969. Technológia, ktorá pomohla ľuďom dostať sa tam, nie je ani technológia z roku 1969, ale skôr z roku 1960 alebo 62, pretože NASA chcela použiť len to, čo malo dobrý dôkaz o spoľahlivosti. A tak sa na to pozriete a pochopíte - áno, a boli pravdivé! Teraz nie, nie, ale dostávate sa do problémov s technológiou jednoducho preto, že všetko sa príliš tlačí, predáva sa zo všetkých trhlín. Ľudia odvšadiaľ kričia: „Pozri, aká vec, toto je najnovšia vec, najkrajšia vec na svete, vhodná úplne pre každého! No, to je všetko... zvyčajne sa to všetko ukáže ako návnada a potom sa to všetko musí vyhodiť. Možno je to všetko preto, že som už starý muž a pozerám sa na takéto veci s veľkou dávkou skepticizmu, keď ľudia dôjdu a povedia, že našli jediný, najsprávnejší spôsob, ako vytvoriť najlepšie technológie. V tejto chvíli sa vo mne prebúdza hlas, ktorý hovorí: "Aký neporiadok!"
Michael: Naozaj, ako často sme počuli o ďalšej striebornej guľke?
Tim: Presne tak, a toto je obvyklý priebeh vecí! Napríklad... zdá sa, že sa to už stalo vtipom po celom svete, ale tu sa často hovorí o technológii blockchain. A skutočne majú v určitých situáciách zmysel! Keď skutočne potrebujete spoľahlivé dôkazy o udalostiach, o tom, že systém funguje a že nás nikto nepodviedol, keď máte problémy s bezpečnosťou a všetky tieto veci zmiešané dohromady – blockchain dáva zmysel. Ale keď hovoria, že Blockchain sa teraz prevalí celým svetom a zmetie všetko, čo mu stojí v ceste? Snívajte viac! Ide o veľmi nákladnú a zložitú technológiu. Technicky zložité a časovo náročné. Vrátane čisto algoritmicky, zakaždým, keď potrebujete prepočítať matematiku, s najmenšími zmenami... a to je skvelý nápad - ale len pre určité prípady. Celý môj život a kariéra boli o tomto: zaujímavé nápady vo veľmi špecifických situáciách. Je veľmi dôležité presne pochopiť, aká je vaša situácia.
Michael: Áno, hlavná „otázka života, vesmíru a všetkého“: je táto technológia alebo prístup vhodný pre vašu situáciu alebo nie?
Tim: Túto otázku už možno prediskutovať s technologickou skupinou. Možno aj prizvať nejakého konzultanta. Pozrite sa na projekt a pochopte - urobíme teraz niečo správne a užitočné, lepšie ako predtým? Možno to bude pasovať, možno nie. Ale čo je najdôležitejšie, nerobte takéto rozhodnutie štandardne, jednoducho preto, že niekto vyhrkol: „Zúfalo potrebujeme blockchain! Práve som o ňom čítal v časopise v lietadle!“ vážne? Nie je to ani vtipné.
Mýtický „devops inžinier“
Oleg: Teraz každý implementuje devops. Niekto si o devopsoch prečíta na internete a zajtra sa na náborovej stránke objaví ďalšie voľné miesto. "devops inžinier". Tu by som chcel upriamiť vašu pozornosť: myslíte si, že tento výraz „devops inžinier“ má právo na život? Existuje názor, že devops je kultúra a niečo tu nesedí.
Tim: Tak tak. Nech potom hneď podajú nejaké vysvetlenie tohto pojmu. Niečo, čím to bude jedinečné. Kým nepreukážu, že za takýmto voľným miestom je jedinečná kombinácia zručností, nekúpim ho! Myslím, no, máme pracovný názov, „devops engineer“, zaujímavý titul, áno, čo ďalej? Pracovné názvy sú vo všeobecnosti veľmi zaujímavá vec. Povedzme „vývojár“ – čo to vlastne je? Rôzne organizácie znamenajú úplne odlišné veci. V niektorých firmách píšu kvalitní programátori testy, ktoré dávajú väčší zmysel ako testy, ktoré píšu špeciálni profesionálni testeri v iných firmách. Tak čo, sú teraz programátormi alebo testermi?
Áno, máme názvy pracovných pozícií, ale ak kladiete otázky dostatočne dlho, nakoniec sa ukáže, že všetci riešime problémy. Hľadáme riešenia a niektorí majú určité technické zručnosti a iní iné. Ak žijete v prostredí, kam DevOps prenikol, zaoberáte sa integráciou vývoja a správy a táto činnosť má nejaký pomerne dôležitý účel. Ale ak sa vás opýtajú, čo presne robíte a za čo ste zodpovedný, ukáže sa, že ľudia robia všetky tieto veci od nepamäti. „Som zodpovedný za architektúru“, „Som zodpovedný za databázy“ a tak ďalej, ako vidíte – to všetko bolo pred „devops“.
Keď mi niekto povie svoje pracovné zaradenie, veľmi ho nepočúvam. Je lepšie nechať ho, aby vám povedal, za čo je vlastne zodpovedný, umožní nám to oveľa lepšie porozumieť problému. Môj obľúbený príklad je, keď niekto tvrdí, že je „projektový manažér“. Čo? To nič neznamená, stále neviem, čo robíš. Projektový manažér môže byť vývojár, vedúci tímu štyroch ľudí, píšuci kód, vykonávajúci prácu, ktorý sa stal vedúcim tímu, ktorého sami ľudia medzi sebou uznávajú ako lídra. Projektový manažér môže byť tiež manažér, ktorý riadi šesťsto ľudí na projekte, riadi iných manažérov, je zodpovedný za zostavovanie harmonogramov a plánovanie rozpočtov, to je všetko. Toto sú dva úplne odlišné svety! Ale ich pracovný názov znie rovnako.
Otočme to trochu inak. V čom si naozaj dobrý, máš veľa skúseností, máš talent? Za čo prevezmete zodpovednosť, pretože si myslíte, že úlohu zvládnete? A tu niekto hneď začne popierať: nie, nie, nie, vôbec nemám chuť riešiť zdroje projektu, nie je to moja vec, som technický frajer a rozumiem použiteľnosti a používateľským rozhraniam, nie Ak chcete vôbec riadiť armády ľudí, nech radšej idem do práce.
A mimochodom, som veľkým zástancom prístupu, v ktorom takéto oddelenie zručností funguje dobre. Kde môžu technici kariérne rásť, ako len chcú. Stále však vidím organizácie, kde sa technici sťažujú: budem musieť ísť do projektového manažmentu, pretože v tejto spoločnosti je to jediný spôsob. Niekedy to vedie k hrozným výsledkom. Najlepší technici nie sú vôbec dobrí manažéri a najlepší manažéri nevedia narábať s technológiami. Buďme v tomto úprimní.
Teraz po tom vidím veľký dopyt. Ak ste technik, vaša spoločnosť vám môže pomôcť, ale bez ohľadu na to musíte skutočne nájsť svoju vlastnú kariérnu cestu, pretože technológia sa neustále mení a spolu s ňou sa musíte znova objaviť! Len za dvadsať rokov sa technológie môžu zmeniť najmenej päťkrát. Technológia je zvláštna vec...
"Odborníci na všetko"
Michael: Ako sa ľudia dokážu vyrovnať s takou rýchlosťou technologických zmien? Rastie ich komplexnosť, rastie ich počet, rastie aj celkové množstvo komunikácie medzi ľuďmi a ukazuje sa, že sa nemôžete stať „odborníkom na všetko“.
Tim: Správny! Ak pracujete v technike, áno, určite si musíte vybrať niečo konkrétne a ponoriť sa do toho. Niektoré technológie, ktoré vaša organizácia považuje za užitočnú (a možno skutočne užitočná bude). A ak vás to už nezaujíma - nikdy by som neveril, že to poviem - no, možno by ste sa mali presunúť do inej organizácie, kde je technológia zaujímavejšia alebo výhodnejšia na štúdium.
Ale vo všeobecnosti áno, máte pravdu. Technológie rastú vo všetkých smeroch naraz; nikto nemôže povedať: „Som odborník na technológie vo všetkých technológiách, ktoré existujú“. Na druhej strane sú hubári, ktorí technologické poznatky doslova nasávajú a sú do nich blázni. Videl som pár takých ľudí, doslova dýchajú a žijú tým, je užitočné a zaujímavé sa s nimi rozprávať. Študujú nielen to, čo sa deje vo vnútri organizácie, ale vo všeobecnosti o tom hovoria, sú tiež naozaj cool technológovia, sú veľmi uvedomelí a cieľavedomí. Snažia sa zostať na vrchole vlny, bez ohľadu na to, čo je ich hlavnou náplňou práce, pretože ich vášňou je pohyb technológií, propagácia technológií. Ak zrazu stretnete takého človeka, mali by ste s ním ísť na obed a počas obeda prediskutovať rôzne super veci. Myslím si, že každá organizácia potrebuje aspoň pár takýchto ľudí.
Riziká a neistota
Michael: Vážení inžinieri, áno. Dotknime sa riadenia rizík, kým máme čas. Tento rozhovor sme začali diskusiou o medicínskom softvéri, kde chyby môžu viesť k strašným následkom. Potom sme hovorili o Lunárnom programe, kde náklady na chybu predstavujú milióny dolárov a možno aj niekoľko ľudských životov. Teraz však v odvetví vidím opačný pohyb, ľudia o rizikách neuvažujú, nesnažia sa ich predvídať, dokonca ich ani nepozorujú.
Oleg: Pohybujte sa rýchlo a rozbíjajte veci!
Michael: Áno, pohybujte sa rýchlo, rozbíjajte veci, stále viac vecí, až kým na niečo nezomriete. Ako by mal teraz z vášho pohľadu pristupovať bežný vývojár k učeniu sa o riadení rizík?
Tim: Urobme hranicu medzi dvoma vecami: rizikami a neistotou. To sú rôzne veci. Neistota nastáva, keď nemáte dostatok údajov v určitom časovom bode na to, aby ste dospeli k definitívnej odpovedi. Napríklad, ak sa vás vo veľmi ranom štádiu projektu niekto spýta „kedy dokončíte prácu“, ak ste celkom čestný človek, odpoviete: „Nemám potuchy“. Len to nevieš a to je v poriadku. Ešte nemáte naštudovanú problematiku a nie ste oboznámení s tímom, nepoznáte jeho schopnosti a pod. Toto je neistota.
Riziká vznikajú, keď už možno identifikovať potenciálne problémy. Takáto vec sa môže stať, jej pravdepodobnosť je väčšia ako nula, ale menej ako sto percent, niekde medzi. Z tohto dôvodu sa môže stať čokoľvek, od meškania a zbytočnej práce, ale dokonca až po fatálny výsledok pre projekt. Výsledok, keď poviete - chlapi, zložíme dáždniky a odídeme z pláže, nikdy to nedokončíme, je po všetkom, bodka. Predpokladali sme, že táto vec bude fungovať, ale vôbec to nefunguje, je čas prestať. Toto sú situácie.
Problémy sa často najľahšie riešia, keď sa už objavili, keď sa problém deje práve teraz. Ale keď je problém priamo pred vami, nerobíte riadenie rizík – robíte riešenie problémov, krízový manažment. Ak ste vedúci vývojár alebo manažér, určite vás zaujíma, čo by sa mohlo stať, čo by viedlo k oneskoreniam, strate času, zbytočným nákladom alebo kolapsu celého projektu? Čo nás prinúti zastaviť sa a začať odznova? Keď budú všetky tieto veci fungovať, čo s nimi urobíme? Existuje jednoduchá odpoveď, ktorá platí pre väčšinu situácií: neutekajte pred rizikami, pracujte na nich. Pozrite sa, ako môžete vyriešiť rizikovú situáciu, zredukovať ju na nič, zmeniť ju z problému na niečo iné. Namiesto toho, aby sme povedali: dobre, problémy budeme riešiť tak, ako vzniknú.
Neistota a riziko by mali byť v popredí všetkého, čo riešite. Môžete si vziať plán projektu, vopred sa pozrieť na určité kritické riziká a povedať: musíme sa s tým teraz vysporiadať, pretože ak sa niečo z toho pokazí, na ničom inom nebude záležať. Nemali by ste sa obávať o krásu obrusu na stole, ak nie je jasné, či môžete uvariť večeru. Najprv treba identifikovať všetky riziká prípravy chutnej večere, vysporiadať sa s nimi a až potom myslieť na všetky ostatné veci, ktoré reálnu hrozbu nepredstavujú.
Opäť, v čom je váš projekt jedinečný? Pozrime sa, čo môže náš projekt vyviesť z miery. Čo môžeme urobiť, aby sme minimalizovali pravdepodobnosť, že sa to stane? Zvyčajne ich nemôžete len tak na 100% zneškodniť a s čistým svedomím vyhlásiť: „To je ono, toto už nie je problém, riziko sa vyriešilo! Pre mňa je to znak správania dospelých. To je rozdiel medzi dieťaťom a dospelým – deti si myslia, že sú nesmrteľné, že sa nič nemôže pokaziť, všetko bude dobré! Dospelí zároveň sledujú, ako trojročné deti skáču na ihrisku, očami sledujú pohyby a hovoria si: „ooh-ooh, ooh-ooh“. Stojím neďaleko a pripravujem sa zachytiť, keď dieťa spadne.
Na druhej strane dôvod, prečo mám tento biznis tak rád, je ten, že je riskantný. Robíme veci a tie veci sú riskantné. Vyžadujú si dospelý prístup. Samotné nadšenie vaše problémy nevyrieši!
Inžinierske myslenie pre dospelých
Michael: Príklad s deťmi je dobrý. Ak som obyčajný inžinier, potom ma teší, že som dieťa. Ale ako sa posunúť k dospelejšiemu mysleniu?
Tim: Jedným z nápadov, ktorý funguje rovnako dobre pre začiatočníkov aj etablovaných vývojárov, je koncept kontextu. Čo robíme, čo dosiahneme. Čo je na tomto projekte skutočne dôležité? Nezáleží na tom, kto ste na tomto projekte, či ste stážista alebo hlavný architekt, každý potrebuje kontext. Musíme prinútiť každého, aby premýšľal vo väčšom meradle, než je jeho vlastné dielo. "Vyrábam svoje dielo a pokiaľ moje dielo funguje, som šťastný." Nie a ešte raz nie. Vždy stojí za to (bez toho, aby som bol hrubý!) pripomenúť ľuďom kontext, v ktorom pracujú. Čo sa snažíme všetci spoločne dosiahnuť. Nápady, že môžete byť dieťaťom, pokiaľ je s vaším dielom projektu všetko v poriadku – prosím, nerobte to. Ak vôbec prejdeme cieľom, prejdeme ho už len spolu. Nie ste sami, sme všetci spolu. Ak by sa všetci ľudia v projekte, starí aj mladí, začali baviť o tom, čo presne je pre projekt dôležité, prečo spoločnosť investuje peniaze do toho, čo sa všetci snažíme dosiahnuť... väčšina z nich sa bude cítiť oveľa lepšie, pretože uvidí, ako ich práca koreluje s prácou všetkých ostatných. Na jednej strane chápem kus, za ktorý som osobne zodpovedný. Ale na dokončenie práce potrebujeme aj všetkých ostatných ľudí. A ak si naozaj myslíte, že ste skončili, v projekte máme vždy čo robiť!
Oleg: Relatívne povedané, ak pracujete podľa Kanbanu, keď narazíte na úzke hrdlo nejakého testovania, môžete skončiť s tým, čo ste tam robili (napríklad s programovaním) a ísť pomáhať testerom.
Tim: presne tak. Myslím si, že najlepší technici, ak sa na nich pozriete pozorne, sú to takí vlastní manažéri. Ako to môžem sformulovať...
Oleg: Váš život je váš projekt, ktorý riadite.
Tim: presne tak! Myslím tým, že preberáte zodpovednosť, rozumiete problematike a prichádzate do kontaktu s ľuďmi, keď vidíte, že vaše rozhodnutia môžu ovplyvniť ich prácu a podobne. Nie je to o tom, že len sedíte za stolom, robíte si prácu a ani si neuvedomujete, čo sa okolo vás deje. Nie nie nie. Mimochodom, jedna z najlepších vecí na Agile je, že navrhli krátke šprinty, pretože takto je stav vecí všetkých účastníkov jasne pozorovateľný, môžu to vidieť všetko spolu. Hovoríme o sebe každý deň.
Ako sa dostať do riadenia rizík
Oleg: Existuje v tejto oblasti nejaká formálna štruktúra vedomostí? Napríklad som vývojár v jazyku Java a chcem porozumieť riadeniu rizík bez toho, aby som sa stal skutočným projektovým manažérom vzdelaním. Asi si najprv prečítam McConnellovu „Koľko stojí softvérový projekt“ a čo potom? Aké sú prvé kroky?
Tim: Prvým je začať komunikovať s ľuďmi v projekte. To poskytuje okamžité zlepšenie kultúry komunikácie s kolegami. Musíme začať tým, že všetko predvolene otvoríme, namiesto toho, aby sme to skrývali. Povedz: toto sú veci, ktoré ma trápia, toto sú veci, ktoré ma v noci držia hore, dnes som sa v noci zobudil a povedal som si: Bože môj, na toto musím myslieť! Vidia iní to isté? Mali by sme ako skupina reagovať na tieto potenciálne problémy? Musíte byť schopní podporiť diskusiu na tieto témy. Neexistuje žiadny vopred pripravený vzorec, podľa ktorého pracujeme. Nie je to o výrobe hamburgerov, ale o ľuďoch. „Vyrobte cheeseburger, predajte cheeseburger“ vôbec nie je naša vec, a preto túto prácu tak milujem. Páči sa mi, keď sa všetko, čo robili manažéri, teraz stáva majetkom tímu.
Oleg: V knihách a rozhovoroch ste hovorili o tom, ako ľuďom záleží viac na šťastí ako na číslach v grafe. Na druhej strane, keď tímu poviete: prechádzame do devops a teraz musí programátor neustále komunikovať, môže to byť ďaleko mimo jeho komfortnej zóny. A v tejto chvíli môže byť, povedzme, hlboko nešťastný. Čo robiť v tejto situácii?
Tim: Neviem presne, čo mám robiť. Ak je vývojár príliš izolovaný, nevidí dôvod, prečo sa práca robí, len sa pozerá na svoju časť práce a potrebuje sa dostať do toho, čo nazývam „kontext“. Musí prísť na to, ako všetko spolu súvisí. A samozrejme, nemám na mysli formálne prezentácie alebo niečo podobné. Hovorím o tom, že s kolegami potrebujete komunikovať o práci ako celku, a nie len o jej časti, za ktorú zodpovedáte. Tu môžete začať diskutovať o nápadoch, spoločných dohodách, aby vaša práca do seba dobre zapadala, a ako spoločne riešiť spoločný problém.
Aby im pomohli prispôsobiť sa, často chcú poslať technikov na školenie a diskutujú o školení. Môj priateľ rád hovorí, že výcvik je pre psov. Existuje školenie pre ľudí. Jednou z najlepších vecí na učení ako vývojár je interakcia so svojimi rovesníkmi. Ak je niekto v niečom naozaj dobrý, mali by ste ho sledovať pri práci alebo sa s ním porozprávať o jeho práci alebo niečom inom. Nejaký konvenčný Kent Beck neustále hovoril o extrémnom programovaní. Je to smiešne, pretože XP je taká jednoduchá myšlienka, ale spôsobuje toľko problémov. Pre niektorých je robiť XP ako byť nútený vyzliecť sa pred priateľmi. Uvidia, čo robím! Sú to moji kolegovia, nielen uvidia, ale aj pochopia! Strašné! Niektorí ľudia začínajú byť vážne nervózni. Ale keď si uvedomíte, že toto je najlepší spôsob učenia, všetko sa zmení. Úzko spolupracujete s ľuďmi a niektorí ľudia rozumejú téme oveľa lepšie ako vy.
Michael: To všetko vás ale núti vyjsť zo svojej komfortnej zóny. Ako inžinier musíte vyjsť zo svojej komfortnej zóny a komunikovať. Ako riešiteľ problémov sa musíte neustále stavať do slabej pozície a premýšľať o tom, čo sa môže pokaziť. Tento typ práce je vo svojej podstate navrhnutý tak, aby obťažoval. Vedome sa dostávate do stresových situácií. Väčšinou od nich ľudia utekajú, ľudia sú radi šťastnými deťmi.
Tim: Čo sa dá robiť, môžete vyjsť a otvorene povedať: „Všetko je v poriadku, zvládnem to! Nie som jediný, kto sa cíti nepríjemne. Poďme spolu diskutovať o rôznych nepríjemných veciach ako tím!" Toto sú naše bežné problémy, musíme sa s nimi vysporiadať, viete? Myslím, že idiosynkratickí geniálni vývojári sú ako mamuty, zmizli. A ich význam je veľmi obmedzený. Ak neviete komunikovať, nemôžete sa dobre zapojiť. Preto len hovorte. Buďte úprimní a otvorení. Je mi veľmi ľúto, že je to niekomu nepríjemné. Viete si predstaviť, pred mnohými rokmi existovala štúdia, podľa ktorej hlavným strachom v Spojených štátoch nie je smrť, ale hádajte čo? Strach z verejného prejavu! To znamená, že niekde sú ľudia, ktorí radšej zomrú, ako by nahlas vyslovili kompliment. A myslím si, že vám stačí mať nejaké základné zručnosti v závislosti od toho, čo robíte. Schopnosť hovoriť, písať - ale len toľko, koľko je skutočne potrebné vo vašej práci. Ak pracuješ ako analytik, ale nevieš čítať, písať ani hovoriť, tak, žiaľ, nebudeš mať čo robiť v mojich projektoch!
Cena komunikácie
Oleg: Nie je zamestnávanie takýchto odchádzajúcich zamestnancov z rôznych dôvodov drahšie? Koniec koncov, namiesto práce neustále chatujú!
Tim: Mal som na mysli jadro tímu, a nie len každého. Ak máte niekoho, kto je naozaj skvelý v ladení databáz, miluje ladenie databáz a bude pokračovať v ladení vašich databáz po zvyšok svojho života a to je všetko, v pohode, len tak ďalej. Ale hovorím o ľuďoch, ktorí chcú bývať v samotnom projekte. Jadro tímu zamerané na rozvoj projektu. Títo ľudia naozaj potrebujú neustále komunikovať medzi sebou. A to najmä na začiatku projektu, keď rozoberáte riziká, spôsoby dosiahnutia globálnych cieľov a podobne.
Michael: Týka sa to všetkých zúčastnených na projekte, bez ohľadu na špecializáciu, zručnosti alebo spôsoby práce. Všetkých vás zaujíma úspech projektu.
Tim: Áno, máte pocit, že ste dostatočne ponorení do projektu, že vašou úlohou je pomôcť projektu uskutočniť. Či už ste programátor, analytik, dizajnér rozhrania, ktokoľvek. To je dôvod, prečo chodím každé ráno do práce a toto je to, čo robíme. Sme zodpovední za všetkých týchto ľudí bez ohľadu na ich schopnosti. Toto je skupina ľudí, ktorí vedú rozhovory pre dospelých.
Oleg: V skutočnosti, keď hovoríme o zhovorčivých zamestnancoch, snažil som sa simulovať námietky ľudí, najmä manažérov, ktorí sú požiadaní, aby prešli na devops, voči tomuto úplne novému videniu sveta. A vy ako konzultanti by ste si mali tieto námietky uvedomovať oveľa lepšie ako ja ako developer! Podeľte sa o to, čo manažérov najviac znepokojuje?
Tim: manažérov? Hm. Najčastejšie sú manažéri pod tlakom problémov, čelia potrebe súrne niečo uvoľniť a zrealizovať dodávku a podobne. Sledujú, ako neustále o niečom diskutujeme a hádame sa a vidia to takto: rozhovory, rozhovory, rozhovory... Aké ďalšie rozhovory? Vráťte sa do práce! Pretože rozprávanie im nepripadá ako práca. Nepíšete kód, netestujete softvér, zdá sa, že nič nerobíte – prečo vás neposlať niečo urobiť? Veď dodanie je už o mesiac!
Michael: Choď napísať nejaký kód!
Tim: Zdá sa mi, že sa neboja o prácu, ale o nedostatočnú viditeľnosť pokroku. Aby sa zdalo, že sa blížime k úspechu, musia nás vidieť stláčať tlačidlá na klávesnici. Celý deň od rána do večera. Toto je problém číslo jedna.
Oleg: Misha, myslíš na niečo.
Michael: Prepáčte, stratil som sa v myšlienkach a zachytil som spätnú väzbu. Toto všetko mi pripomenulo zaujímavý míting, ktorý sa stal včera... Včera bolo príliš veľa mítingov... A všetko to znie veľmi povedome!
Život bez platov
Tim: Mimochodom, nie je vôbec potrebné organizovať „zhromaždenia“ na komunikáciu. Myslím, že najužitočnejšie diskusie medzi vývojármi sa odohrávajú, keď sa len rozprávajú medzi sebou. Vojdete ráno so šálkou kávy a je tam päť ľudí, ktorí zúrivo diskutujú o niečom technickom. Pre mňa, ak som manažér tohto projektu, je lepšie sa len usmiať a ísť niekam o svojom biznise, nech si to vydiskutujú. Už teraz sú zapojení v maximálnej možnej miere. To je dobré znamenie.
Oleg: Mimochodom, vo svojej knihe máte kopu poznámok o tom, čo je dobré a čo zlé. Používate niektoré z nich aj vy? Relatívne povedané, teraz máte spoločnosť, ktorá je štruktúrovaná veľmi neortodoxným spôsobom...
Tim: Neortodoxné, ale toto zariadenie nám úplne vyhovuje. Poznáme sa už dlho. Dôverujeme si, veľa sme si verili, kým sme sa stali partnermi. A napríklad nemáme vôbec žiadne platy. Len pracujeme a ak som napríklad zarábal od svojich klientov, tak všetky peniaze išli mne. Organizácii potom platíme členské príspevky a to stačí na podporu samotnej spoločnosti. Navyše, každý sa špecializujeme na niečo iné. Ja napríklad robím s účtovníkmi, vypĺňam daňové priznania, robím pre firmu všelijaké administratívne veci a nikto mi za to neplatí. James a Tom pracujú na našom webe a tiež ich nikto neplatí. Kým budete platiť svoje odvody, nikoho nenapadne hovoriť vám, čo musíte urobiť. Napríklad Tom teraz pracuje oveľa menej ako kedysi. Teraz má iné záujmy, niektoré veci robí nie pre Gildu. Ale kým bude platiť svoje poplatky, nikto za ním nepríde a nepovie: "Hej, Tom, choď do práce!" Je veľmi jednoduché jednať s kolegami, keď medzi vami nie sú peniaze. A teraz je náš vzťah jednou zo základných myšlienok vo vzťahu k rôznym špecialitám. Funguje to a funguje to veľmi dobre.
Najlepšia rada
Michael: Vráťme sa k „najlepšej rade“, je niečo, čo hovoríte svojim klientom znova a znova? Existuje predstava o 80/20 a niektoré rady sa zrejme opakujú častejšie.
Tim: Kedysi som si myslel, že keby ste napísali knihu ako Valčík s medveďmi, zmenilo by to chod dejín a ľudia by sa zastavili, ale... No, pozri, firmy sa často tvária, že je u nich všetko v poriadku. Akonáhle sa stane niečo zlé, je to pre nich šok a prekvapenie. „Pozrite, testovali sme systém a neprešiel žiadnymi systémovými testami a toto sú ďalšie tri mesiace neplánovanej práce, ako sa to mohlo stať? Kto vedel? Čo sa môže pokaziť? Vážne, veríš tomu?
Snažím sa vysvetliť, že by ste sa nemali príliš hnevať na súčasnú situáciu. Musíme sa o tom porozprávať, skutočne pochopiť, čo sa mohlo pokaziť a ako zabrániť takýmto veciam v budúcnosti. Ak sa problém objaví, ako s ním budeme bojovať, ako ho obmedzíme?
Pre mňa to všetko vyzerá strašidelne. Ľudia sa zaoberajú zložitými, nepríjemnými problémami a naďalej predstierajú, že ak budú len držať palce a dúfať v to najlepšie, to „najlepšie“ sa skutočne stane. Nie, takto to nefunguje.
Precvičte si riadenie rizík!
Michael: Koľko organizácií sa podľa vás zaoberá riadením rizík?
Tim: Čo ma rozhorčuje je, že ľudia si jednoducho zapíšu riziká, pozrú si výsledný zoznam a idú do práce. V skutočnosti je identifikácia rizík pre nich riadením rizík. Ale toto mi znie ako dôvod opýtať sa: dobre, existuje zoznam, čo presne zmeníte? Musíte zmeniť svoje štandardné postupnosti akcií s prihliadnutím na tieto riziká. Ak existuje nejaká najťažšia časť práce, musíte ju vyriešiť a až potom prejsť na niečo jednoduchšie. V prvých šprintoch začnite riešiť zložité problémy. Toto už vyzerá ako riadenie rizík. Ľudia však zvyčajne nevedia povedať, čo zmenili po zostavení zoznamu rizík.
Michael: A predsa, koľko z týchto spoločností sa podieľa na riadení rizík, päť percent?
Tim: Bohužiaľ, nerád to hovorím, ale toto je veľmi nepodstatná časť. Ale viac ako päť, pretože existujú naozaj veľké projekty a jednoducho nemôžu existovať, ak neurobia aspoň niečo. Povedzme, že budem veľmi prekvapený, ak to bude aspoň 25 %. Malé projekty zvyčajne odpovedajú na takéto otázky takto: ak sa nás problém týka, potom ho vyriešime. Potom sa úspešne dostanú do problémov a zapoja sa do manažmentu problémov a krízového manažmentu. Keď sa pokúšate vyriešiť problém a problém sa nevyrieši, vitajte v krízovom manažmente.
Áno, často počúvam: „Problémy vyriešime hneď, ako nastanú“. Určite budeme? Naozaj sa rozhodneme?
Oleg: Môžete to urobiť naivne a jednoducho zapísať dôležité invarianty do charty projektu a ak sa invarianty pokazia, stačí reštartovať projekt. Ukazuje sa to veľmi piembucké.
Michael: Áno, stalo sa mi, že keď sa spustili riziká, projekt sa jednoducho predefinoval. Pekné, bingo, problém vyriešený, už sa netráp!
Tim: Stlačíme resetovacie tlačidlo! Nie, takto to nefunguje.
Hlavná prednáška na DevOops 2019
Michael: Dostávame sa k poslednej otázke tohto rozhovoru. Prichádzate na ďalší DevOops s kľúčovým prejavom, mohli by ste zdvihnúť oponu tajomstva o tom, čo poviete?
Tim: Práve teraz šiesti z nich píšu knihu o kultúre práce, nevyslovených pravidlách organizácií. Kultúra je určená základnými hodnotami organizácie. Ľudia si to väčšinou nevšimnú, ale keďže sme dlhé roky pracovali v poradenstve, zvykli sme si to všímať. Vstúpite do spoločnosti a doslova v priebehu niekoľkých minút začnete cítiť, čo sa deje. Hovoríme tomu „príchuť“. Niekedy je táto vôňa naozaj dobrá a niekedy je to, no, ups. Veci sú pre rôzne organizácie veľmi odlišné.
Michael: Aj ja sa už roky pohybujem v poradenstve a dobre rozumiem, o čom hovoríte.
Tim: V skutočnosti jedna z vecí, o ktorých stojí za to hovoriť na keynote, je, že nie všetko určuje spoločnosť. Vy a váš tím ako komunita máte svoju vlastnú tímovú kultúru. Môže to byť celá spoločnosť alebo samostatné oddelenie, samostatný tím. Ale predtým, ako ste povedali, tu je to, čomu veríme, tu je to, čo je dôležité... Nemôžete zmeniť kultúru, kým nepochopíte hodnoty a presvedčenia, ktoré stoja za konkrétnymi činmi. Správanie sa dá ľahko pozorovať, ale hľadanie presvedčení je ťažké. DevOps je len skvelým príkladom toho, ako sa veci stávajú čoraz zložitejšími. Interakcie sú len čoraz komplexnejšie, už vôbec nie sú čistejšie a jasnejšie, preto by ste sa mali zamyslieť nad tým, čomu veríte a o čom všetci naokolo mlčia.
Ak chcete dosiahnuť rýchle výsledky, tu je pre vás dobrá téma: videli ste spoločnosti, kde nikto nehovorí „neviem“? Sú miesta, kde človeka doslova mučíte, kým neprizná, že niečo nevie. Každý všetko vie, každý je neskutočne erudovaný. Oslovíte akúkoľvek osobu a on musí okamžite odpovedať na otázku. Namiesto toho, aby ste povedali „neviem“. Hurá, najali partiu erudovaných! A v niektorých kultúrach je všeobecne veľmi nebezpečné povedať „neviem“, možno to vnímať ako prejav slabosti. Sú aj organizácie, v ktorých, naopak, každý môže povedať „neviem“. Tam je to úplne legálne a ak niekto začne v odpovedi na otázku blbnúť, je úplne normálne odpovedať: „Nevieš, o čom hovoríš, však? a premeniť to všetko na vtip.
V ideálnom prípade by ste chceli mať prácu, kde by ste mohli byť neustále šťastní. Nebude to ľahké, nie každý deň je slnečný a príjemný, niekedy treba tvrdo pracovať, ale keď začnete bilancovať, ukáže sa: wow, toto je naozaj úžasné miesto, dobre sa mi tu pracuje, emocionálne aj intelektuálne. A sú spoločnosti, do ktorých idete ako konzultant a okamžite si uvedomíte, že by ste to tri mesiace nevydržali a od hrôzy by ste utiekli. To je to, o čom chcem hovoriť v správe.
Tim Lister príde s hlavným prejavom na konferenciu DevOops 2019, ktorá sa uskutoční 29. – 30. októbra 2019 v Petrohrade. Lístky si môžete kúpiť . Čakáme na vás v DevOops!
Zdroj: hab.com