Tim Lister - soavtor knjig

• "Človeški faktor. Uspešni projekti in ekipe" (izvirna knjiga se imenuje "Peopleware")
• "Valček z medvedi: obvladovanje tveganja pri programskih projektih"
• »Od adrenalina obnoreli in zombirani od vzorcev. Vzorci obnašanja projektnih skupin"

Vse te knjige so klasike na svojem področju in so jih napisali skupaj s kolegi v Atlantic Systems Guild. V Rusiji so njegovi kolegi najbolj znani - Tom DeMarco и Peter Hruška, ki je napisal tudi mnoga znana dela.

Tim ima 40 let izkušenj z razvojem programske opreme; leta 1975 (nobeden od piscev tega habraposta ni bil rojen letos) je bil Tim že izvršni podpredsednik podjetja Yourdon Inc. Zdaj preživlja svoj čas s svetovanjem, poučevanjem in pisanjem, z občasnimi obiski s poročili konference po vsem svetu.

Posebej za Habr smo naredili intervju s Timom Listerjem. Odprl bo konferenco DevOops 2019 in imamo veliko vprašanj, o knjigah in še več. Intervju vodita Mikhail Druzhinin in Oleg Chirukhin iz programskega odbora konference.

Michael: Lahko poveste nekaj besed o tem, kaj počnete zdaj?

Tim: Sem vodja združenja Atlantic Systems Guild. V Cehu nas je šest, imenujemo se ravnatelji. Trije v ZDA in trije v Evropi - zato se Ceh imenuje Atlantik. Skupaj sva že toliko let, da jih kar ne moreš prešteti. Vsi imamo svoje posebnosti. S strankami delam zadnje desetletje ali več. Moji projekti ne vključujejo le vodenja, ampak tudi postavljanje zahtev, načrtovanje projektov in vrednotenje. Zdi se, da se projekti, ki se začnejo slabo, običajno slabo končajo. Zato velja poskrbeti, da so vse aktivnosti res dobro premišljene in usklajene, da se ideje ustvarjalcev prepletajo. Vredno je razmisliti o tem, kaj počnete in zakaj. Katere strategije uporabiti, da projekt pripeljete do konca.

Strankam že vrsto let svetujem na različne načine. Zanimiv primer je podjetje, ki izdeluje robote za operacijo kolena in kolka. Kirurg ne operira popolnoma samostojno, ampak uporablja robota. Varnost je tu, odkrito povedano, pomembna. Toda ko poskušate razpravljati o zahtevah z ljudmi, ki so osredotočeni na reševanje problemov ... Slišati bo čudno, vendar v ZDA obstaja FDA (Zvezna uprava za zdravila), ki licencira izdelke, kot so ti roboti. Preden karkoli prodaš in uporabiš na živih ljudeh, moraš dobiti licenco. Eden od pogojev je, da pokažete svoje zahteve, kakšni so testi, kako ste jih testirali, kakšni so rezultati testov. Če spremenite zahteve, morate znova in znova skozi ves ta ogromen proces testiranja. Naše stranke so v svoje zahteve uspele vključiti vizualno zasnovo aplikacij. Imeli so posnetke zaslona neposredno kot del zahtev. Moramo jih potegniti ven in razložiti, da vsi ti programi večinoma ne vedo nič o kolenih in kolkih, o vseh teh stvareh s kamero itd. Dokumente z zahtevami moramo prepisati tako, da se nikoli ne spremenijo, razen če se spremenijo nekateri resnično pomembni osnovni pogoji. Če vizualni dizajn ni v zahtevah, bo posodabljanje izdelka veliko hitrejše. Naša naloga je, da poiščemo tiste elemente, ki obravnavajo operacije kolena, kolka, hrbta, jih izvlečemo v posebne dokumente in rečemo, da bodo to temeljne zahteve. Naredimo ločeno skupino zahtev o operacijah kolena. To nam bo omogočilo, da zgradimo bolj stabilen niz zahtev. Govorili bomo o celotni liniji izdelkov in ne o določenih robotih.

Opravljenega je bilo veliko dela, a so vseeno prišli do krajev, kjer so prej brez pomena in potrebe preživljali tedne in mesece ponavljajočih se testiranj, ker njihove zahteve, opisane na papirju, niso sovpadale z dejanskimi zahtevami, za katere so bili sistemi zgrajeni. FDA jim je vsakič rekla: vaše zahteve so se spremenile, zdaj morate vse preveriti od začetka. Popolna ponovna preverjanja celotnega izdelka so ubijala podjetje.

Torej, obstajajo tako čudovite naloge, ko se znajdete na samem začetku nečesa zanimivega in že prva dejanja določajo nadaljnja pravila igre. Če se prepričate, da bo ta zgodnja dejavnost začela dobro delovati tako z vodstvenega kot s tehničnega vidika, obstaja možnost, da boste končali z odličnim projektom. Če pa je ta del zašel iz tira in šel nekam narobe, če ne najdete temeljnih dogovorov ... ne, ni nujno, da bo vaš projekt propadel. A ne boste več mogli reči: "Super nam je šlo, vse smo naredili res učinkovito." To so stvari, ki jih počnem pri komunikaciji s strankami.

Michael: Se pravi, zaženete projekte, naredite nekakšen začetni udarec in preverite, ali tirnice peljejo v pravo smer?

Tim: Imamo tudi ideje, kako sestaviti vse dele sestavljanke: katere veščine potrebujemo, kdaj točno jih potrebujemo, kako izgleda jedro ekipe in druge podobne temeljne stvari. Ali potrebujemo zaposlene za polni delovni čas ali lahko zaposlimo nekoga za krajši delovni čas? Načrtovanje, vodenje. Vprašanja, kot so: Kaj je najpomembnejše za ta projekt? Kako to doseči? Kaj vemo o tem izdelku ali projektu, kakšna so tveganja in kje so neznanke, kako se bomo z vsem tem spopadli? Seveda v tem trenutku nekdo začne vpiti "Kaj pa agile?!" V redu, vsi ste prilagodljivi, ampak kaj potem? Kako natančno izgleda projekt, kako ga boste izpeljali na način, ki ustreza projektu? Ne morete kar reči, da "naš pristop sega do česarkoli, mi smo ekipa Scrum!" To je nesmisel in neumnost. Kam boš šel naprej, zakaj bi delovalo, kje je smisel? Svoje stranke učim razmišljati o vseh teh vprašanjih.

19 let agila

Michael: V Agileu ljudje pogosto poskušajo ne definirati ničesar vnaprej, ampak se odločiti čim pozneje, češ: preveliki smo, ne bom razmišljal o celotni arhitekturi. Ne bom razmišljal o kupih drugih stvareh, namesto tega bom stranki takoj dostavil nekaj, kar deluje.

Tim: Mislim, da agilne metodologije, začenši s Agilni manifest leta 2001 industriji odprl oči. A po drugi strani nič ni popolno. Jaz sem za iterativni razvoj. Iteracija je v večini projektov zelo smiselna. Toda vprašanje, o katerem morate razmišljati, je: kako dolgo traja izdelek, ko je izdelek v uporabi? Ali je to izdelek, ki bo zdržal šest mesecev, preden ga bo nadomestilo kaj drugega? Ali pa je to izdelek, ki bo deloval še mnogo let? Seveda ne bom imenoval imen, ampak ... V New Yorku in njegovi finančni skupnosti so najbolj temeljni sistemi zelo stari. To je neverjetno. Pogledate jih in pomislite, če bi se le lahko vrnili v preteklost, v leto 1994, in povedali razvijalcem: »Prišel sem iz prihodnosti, iz leta 2019. Samo razvijajte ta sistem toliko časa, kot ga potrebujete. Naj bo razširljiv, razmislite o arhitekturi. Nato ga bodo izboljševali več kot petindvajset let. Če še malo odložiš razvoj, v veliki shemi stvari ne bo nihče opazil!« Ko stvari ocenjujete na dolgi rok, morate upoštevati, koliko bo to skupaj stalo. Včasih je dobro zasnovana arhitektura res vredna, včasih pa ne. Ozreti se moramo okoli sebe in se vprašati: ali smo v pravi situaciji za takšno odločitev?

Torej ideja, kot je "Mi smo za agile, stranka nam bo sama povedala, kaj želi dobiti" - je super naivna. Kupci sploh ne vedo, kaj hočejo, še bolj pa ne vedo, kaj bi lahko dobili. Nekateri bodo začeli navajati zgodovinske primere kot argumente, to sem že videl. Toda tehnično napredni ljudje tega običajno ne rečejo. Pravijo: "Leto 2019 je, to so priložnosti, ki jih imamo, in popolnoma lahko spremenimo pogled na te stvari!" Namesto da posnemate obstoječe rešitve in jih naredite nekoliko lepše in bolj počesane, je včasih treba iti ven in reči: "Popolnoma na novo odkrijmo, kar poskušamo narediti tukaj!"

In mislim, da večina strank ne more razmišljati o problemu na tak način. Vidijo samo tisto, kar že imajo, to je vse. Potem pridejo s prošnjami, kot je "naredimo to malo poenostavljeno," ali karkoli že običajno rečejo. Nismo pa natakarji ali natakarice, da lahko sprejmemo naročilo, ne glede na to, kako neumno izpade, in ga potem spečemo v kuhinji. Mi smo njihovi vodniki. Moramo jim odpreti oči in reči: hej, tu imamo nove priložnosti! Se zavedate, da lahko resnično spremenimo način izvajanja tega dela vašega poslovanja? Ena od težav z Agile je, da odstrani zavedanje o tem, kaj je priložnost, kaj je problem, kaj sploh moramo storiti, katere razpoložljive tehnologije so najbolj primerne za to posebno situacijo.

Morda sem tukaj preveč skeptičen: v agilni skupnosti se dogaja veliko čudovitih stvari. Imam pa problem, da ljudje namesto definiranja projekta začnejo dvigovati roke. Tukaj bi vprašal – kaj delamo, kako bomo? In nekako čudežno se vedno izkaže, da bi stranka morala vedeti bolje kot kdorkoli. Stranka pa ve najbolje šele, ko izbira med stvarmi, ki jih je nekdo že zgradil. Če želim kupiti avto in poznam velikost svojega družinskega proračuna, potem bom hitro izbral avto, ki bo ustrezal mojemu življenjskemu slogu. Tukaj vem vse bolje kot kdorkoli! Vendar upoštevajte, da je nekdo že naredil avtomobile. Nimam pojma, kako izumiti nov avto, nisem strokovnjak. Ko izdelujemo izdelke po meri ali posebne izdelke, je treba upoštevati glas stranke, ki pa ni več edini glas.

Oleg: Omenili ste agilni manifest. Ali ga moramo nekako posodobiti ali popraviti ob upoštevanju sodobnega razumevanja vprašanja?

Tim: Ne bi se ga dotaknil. Mislim, da je odličen zgodovinski dokument. Mislim, on je, kar je. Star je 19 let, je star, a v svojem času je naredil revolucijo. Dobro mu je uspelo, da je sprožil reakcijo in ljudje so začeli šepetati o njem. Leta 2001 verjetno še niste delali v panogi, takrat pa so vsi delali po procesih. Software Engineering Institute, pet stopenj modela popolnosti programske opreme (CMMI). Ne vem, ali vam takšne legende globoke antike kaj povedo, ampak takrat je bil preboj. Sprva so ljudje verjeli, da če bodo procesi pravilno nastavljeni, bodo težave izginile same od sebe. In potem pride Manifest in pravi: "Ne, ne, ne – temeljili bomo na ljudeh, ne na procesih." Smo mojstri razvoja programske opreme. Zavedamo se, da je idealen proces fatamorgana; ne zgodi se. V projektih je preveč idiosinkrazije, ideja o enem samem popolnem procesu za vse projekte nima nobenega smisla. Problemi so preveč zapleteni, da bi lahko trdili, da obstaja samo ena rešitev za vse (zdravo, nirvana).

Ne upam se ozreti v prihodnost, vendar bom rekel, da so ljudje zdaj začeli več razmišljati o projektih. Mislim, da Agile Manifesto zelo dobro skoči in reče: »Hej! Ste na ladji in sami vozite to ladjo. Odločiti se boste morali - ne bomo predlagali univerzalnega recepta za vse situacije. Vi ste posadka ladje in če ste dovolj dobri, lahko najdete pot do svojega cilja. Pred vami so bile druge ladje in za vami bodo druge ladje, a vseeno je v nekem smislu vaše potovanje edinstveno.« Nekaj ​​takega! To je način razmišljanja. Zame ni nič novega pod soncem, ljudje so že jadrali in bodo še pluli, za vas pa je to vaša glavna pot in ne bom vam povedal, kaj točno se vam bo zgodilo. Imeti moraš veščine usklajenega dela v timu, in če jih res imaš, se bo vse izšlo in prišel boš, kamor si želel.

Peopleware: 30 let pozneje

Oleg: Je bil Peopleware tako revolucija kot Manifest?

Tim: Peopleware... S Tomom sva napisala to knjigo, vendar si nisva mislila, da se bo zgodilo takole. Nekako je odmevalo z idejami mnogih ljudi. To je bila prva knjiga, ki je rekla: razvoj programske opreme je človeško intenzivna dejavnost. Kljub tehnični naravi smo tudi skupnost ljudi, ki gradijo nekaj velikega, celo ogromnega, zelo kompleksnega. Nihče ne more ustvariti takih stvari sam, kajne? Tako je ideja o "ekipi" postala zelo pomembna. In ne le z vidika menedžmenta, ampak tudi za tehnične ljudi, ki so se združili, da bi rešili res zapletene globoke probleme s kupom neznank. Zame osebno je bil to velik test inteligence v moji karieri. In tukaj je treba znati reči: ja, ta problem je več, kot ga lahko sam rešim, a skupaj lahko najdemo elegantno rešitev, na katero smo lahko ponosni. In mislim, da je bila ta ideja najbolj odmevna. Ideja, da delamo del časa sami, del časa v skupini, pogosto pa je odločitev sprejeta v skupini. Skupinsko reševanje problemov je hitro postalo pomembna značilnost kompleksnih projektov.

Kljub temu, da je imel Tim ogromno predavanj, jih je le malo objavljenih na YouTubu. Ogledate si lahko poročilo “The Return of Peopleware” iz leta 2007. Kakovost seveda pušča veliko želenega.

Michael: Se je v zadnjih 30 letih, odkar je knjiga izšla, kaj spremenilo?

Tim: Na to lahko pogledate iz več različnih zornih kotov. Sociološko gledano ... nekoč, v bolj preprostih časih, ste s svojo ekipo sedeli v isti pisarni. Lahko bi bila vsak dan blizu, skupaj pila kavo in se pogovarjala o delu. Resnično se je spremenilo to, da so ekipe zdaj lahko porazdeljene geografsko, v različnih državah in časovnih pasovih, vendar še vedno delajo na istem problemu, kar dodaja povsem novo plast kompleksnosti. To se morda sliši starošolsko, vendar ni nič podobnega komunikaciji iz oči v oči, kjer ste vsi skupaj, delate skupaj in lahko stopite do kolega in rečete, poglejte, kaj sem odkril, kako vam je to všeč? Pogovori iz oči v oči omogočajo hiter prehod na neformalno komunikacijo in mislim, da bi to moralo biti všeč tudi agilnim navdušencem. Skrbi me tudi, ker se je v resnici svet izkazal za zelo majhnega in zdaj je ves prekrit z razpršenimi ekipami in je vse zelo kompleksno.

Vsi živimo v DevOps

Michael: Tudi z vidika programskega odbora konference imamo ljudi v Kaliforniji, v New Yorku, Evropi, Rusiji ... v Singapurju še ni nikogar. Geografska razlika je precej velika in ljudje se začnejo še bolj razprševati. Če že govorimo o razvoju, nam lahko poveste kaj več o devopsih in podiranju ovir med ekipami? Obstaja koncept, da vsi sedijo v svojih bunkerjih, zdaj pa se bunkerji podirajo, kaj menite o tej analogiji?

Tim: Zdi se mi, da je devops v luči zadnjih tehnoloških prebojev zelo pomemben. Prej si imel ekipe razvijalcev in administratorjev, ki so delali, delali, delali in na neki točki se je pojavila zadeva, s katero si lahko prišel do administratorjev in jo dal v produkcijo. In tu se je začel pogovor o bunkerju, saj so admini nekakšni zavezniki, ne vsaj sovražniki, vendar si se z njimi pogovarjal šele takrat, ko je bilo vse pripravljeno za produkcijo. Ste šli do njih z nečim in rekli: poglejte, kakšno aplikacijo imamo, a bi lahko to aplikacijo uvedli? In zdaj se je celoten koncept dostave spremenil na bolje. Mislim, obstajala je ideja, da bi lahko hitro potisnil spremembe. Izdelke lahko sproti posodabljamo. Vedno se nasmehnem, ko se pojavi Firefox na mojem prenosnem računalniku in reče, hej, posodobili smo vaš Firefox v ozadju, in takoj, ko boste imeli minuto, lahko kliknete tukaj in dali vam bomo najnovejšo izdajo. In rekel sem si: "O ja, srček!" Medtem ko sem spal, so delali na tem, da bi mi dostavili novo izdajo kar na moj računalnik. To je čudovito, neverjetno.

Toda tukaj je težava: to funkcijo imate pri posodabljanju programske opreme, vendar je integracija ljudi veliko težja. Kar želim povedati na osrednji besedi DevOops, je, da imamo zdaj veliko več igralcev, kot smo jih kdajkoli imeli. Če samo pomislite na vse, ki sodelujejo v samo eni ekipi... O tem ste razmišljali kot o ekipi, ki je veliko več kot le ekipa programerjev. To so preizkuševalci, vodje projektov in kup drugih ljudi. In vsak ima svoje poglede na svet. Produktni vodje so popolnoma drugačni od projektnih vodij. Administratorji imajo svoje naloge. Precej težak problem postane uskladiti vse udeležence, da se še naprej zavedajo, kaj se dogaja, in ne ponorijo. Ločiti je treba naloge skupine in naloge, ki veljajo za vse. To je zelo težka naloga. Po drugi strani pa mislim, da je vse veliko bolje, kot je bilo pred mnogimi leti. Prav to je pot, na kateri ljudje rastejo in se učijo pravilnega vedenja. Ko izvajate integracijo, razumete, da ne bi smelo biti podtalnega razvoja, tako da programska oprema v zadnjem trenutku ne prileze ven kot jack-in-the-box: kot, poglejte, kaj smo naredili tukaj! Ideja je, da boste lahko izvajali integracijo in razvoj, na koncu pa se boste uvedli na čist in ponavljajoč se način. Vse to mi veliko pomeni. To omogoča ustvarjanje več vrednosti za uporabnike sistema in za vašo stranko.

Michael: Celotna zamisel devopsa je zagotoviti pomemben razvoj čim prej. Vidim, da se je svet začel vedno bolj pospeševati. Kako se prilagoditi takim pospeškom? Pred desetimi leti tega ni bilo!

Tim: Seveda si vsi želijo več in več funkcionalnosti. Ni vam treba premikati, samo nakopičite več. Včasih morate celo upočasniti, da naslednja postopna posodobitev prinese kaj uporabnega - in to je povsem normalno.

Ideja, da morate teči, teči, teči, ni najboljša. Malo verjetno je, da si kdo želi tako živeti. Želel bi, da bi ritem dobav določal ritem projekta. Če proizvedete le niz majhnih, razmeroma nesmiselnih stvari, vse skupaj nima pomena. Namesto da bi brezglavo poskušali izdati stvari čim prej, se je vredno pogovoriti z vodilnimi razvijalci ter vodji izdelkov in projektov o strategiji. Je to sploh smiselno?

Vzorci in antivzorci

Oleg: Običajno govorite o vzorcih in antivzorcih in to je razlika med življenjem in smrtjo projektov. In zdaj v naša življenja vdre devops. Ali ima kakšne svoje vzorce in antivzorce, ki lahko projekt ubijejo na mestu?

Tim: Vzorci in anti-vzorci se pojavljajo ves čas. Nekaj ​​za pogovor. No, obstaja stvar, ki ji pravimo "svetleče stvari." Ljudje imajo res, zelo radi nove tehnologije. Enostavno so očarani nad sijajem vsega, kar je videti kul in elegantno, in nehajo postavljati vprašanja: ali je to sploh potrebno? Kaj bomo dosegli? Je ta stvar zanesljiva, ali ima smisel? Pogosto vidim ljudi, tako rekoč, na samem vrhu tehnologije. Hipnotizirani so nad tem, kar se dogaja v svetu. A če pobliže pogledate, kaj koristnega počnejo, pogosto preprosto ni nič koristnega!

S tovariši smo ravno razpravljali o tem, da je letos obletnica, petdeset let od pristanka ljudi na Luni. To je bilo leta 1969. Tehnologija, ki je ljudem pomagala priti do tja, niti ni tehnologija iz leta 1969, temveč iz leta 1960 ali 62, ker je NASA želela uporabiti le tisto, kar je imelo dobre dokaze o zanesljivosti. In tako pogledate in razumete - ja, in bile so resnične! Zdaj, ne, ne, ampak naletiš na težave s tehnologijo preprosto zato, ker je vse preveč nagnjeno, prodano na vse pretege. Ljudje od vsepovsod kričijo: "Glej, kakšna stvar, to je najnovejša stvar, najlepša stvar na svetu, primerna za čisto vse!" No, to je to ... običajno se vse to izkaže le za vabo, potem pa je treba vse skupaj zavreči. Morda zato, ker sem že star človek in z veliko mero skepse gledam na take stvari, ko ljudi zmanjka in rečejo, da so našli edini, najbolj pravilen način za ustvarjanje najboljših tehnologij. V tem trenutku se v meni prebudi glas, ki pravi: "Kakšna zmešnjava!"

Michael: Dejansko, kako pogosto smo slišali za naslednjo srebrno kroglo?

Tim: Točno tako, in to je običajen potek stvari! Na primer ... zdi se, da je to po svetu že postala šala, pri nas pa se pogosto govori o tehnologiji blockchain. In v določenih situacijah so dejansko smiselne! Ko res potrebujete zanesljive dokaze o dogodkih, da sistem deluje in da nas nihče ni zavedel, ko imate varnostne težave in vse skupaj pomešano - blockchain ima smisel. Toda ko pravijo, da bo Blockchain zdaj pometel po svetu in pometel vse na svoji poti? Sanjaj več! To je zelo draga in zapletena tehnologija. Tehnično zapleteno in dolgotrajno. Vključno čisto algoritemsko, vsakič, ko je treba matematiko preračunati, z najmanjšimi spremembami ... in to je odlična ideja - vendar le za določene primere. Vse moje življenje in kariera sta bila o tem: zanimive ideje v zelo specifičnih situacijah. Zelo pomembno je, da natančno razumete, kakšna je vaša situacija.

Michael: Da, glavno »vprašanje življenja, vesolja in vsega«: ali je ta tehnologija ali pristop primeren za vašo situacijo ali ne?

Tim: O tem vprašanju je že mogoče razpravljati s tehnološko skupino. Morda celo privabi kakšnega svetovalca. Oglejte si projekt in razumejte - bomo zdaj naredili nekaj pravega in koristnega, boljšega kot prej? Mogoče bo ustrezalo, morda ne. Najpomembneje pa je, da se takšne odločitve ne odločite privzeto, preprosto zato, ker je nekdo izdavil: »Obupno potrebujemo blockchain! Pravkar sem prebral o njem v reviji na letalu!« Resno? Sploh ni smešno.

Mitski »devops inženir«

Oleg: Zdaj vsi izvajajo devops. Nekdo bere o devopsih na internetu, jutri pa se na spletnem mestu za zaposlovanje pojavi novo prosto delovno mesto. "devops inženir". Tu bi vas rad opozoril: ali menite, da ima ta izraz »devops inženir« pravico do življenja? Obstaja mnenje, da je devops kultura, in tukaj nekaj ne štima.

Tim: Tako tako. Naj potem takoj podajo kakšno razlago tega izraza. Nekaj, kar naredi edinstveno. Dokler ne dokažejo, da za takim prostim delovnim mestom stoji neka edinstvena kombinacija veščin, ga ne bom kupil! Mislim, no, imamo naziv delovnega mesta, "devops inženir," zanimiv naziv, ja, kaj pa potem? Nazivi delovnih mest so na splošno zelo zanimiva stvar. Recimo "razvijalec" - kaj sploh je to? Različne organizacije pomenijo popolnoma različne stvari. V nekaterih podjetjih visokokakovostni programerji pišejo teste, ki so bolj smiselni kot testi, ki jih pišejo posebni profesionalni preizkuševalci v drugih podjetjih. Pa kaj, so zdaj programerji ali testerji?

Da, imamo nazive delovnih mest, a če dovolj dolgo sprašujete, se sčasoma izkaže, da vsi rešujemo probleme. Smo iskalci rešitev in nekateri imamo nekaj tehničnih znanj, drugi pa drugačna. Če živite v okolju, kamor je prodrl DevOps, se ukvarjate z integracijo razvoja in administracije in ta dejavnost ima nek dokaj pomemben namen. A če te vprašajo, kaj točno delaš in za kaj si odgovoren, se izkaže, da so ljudje vse to počeli že od nekdaj. "Odgovoren sem za arhitekturo", "Odgovoren sem za baze podatkov" in tako naprej, karkoli, vidite - vse to je bilo pred "devopsom".

Ko mi nekdo pove naziv svojega delovnega mesta, res ne poslušam preveč. Bolje je, da mu dovolite, da vam pove, za kaj je dejansko odgovoren, tako bomo veliko bolje razumeli zadevo. Moj najljubši primer je, ko oseba trdi, da je "vodja projekta". Kaj? Nič ne pomeni, še vedno ne vem, kaj počneš. Vodja projekta je lahko razvijalec, vodja ekipe štirih ljudi, ki piše kodo, opravlja delo, ki je postal team lead, ki ga ljudje sami med seboj prepoznavajo kot vodjo. In tudi vodja projekta je lahko vodja, ki vodi šeststo ljudi na projektu, vodi druge managerje, je odgovoren za pripravo urnikov in načrtovanje proračunov, to je vse. To sta dva popolnoma različna svetova! Toda naziv njihovega delovnega mesta zveni enako.

Obrnimo tole malo drugače. V čem ste res dobri, imate veliko izkušenj, imate talent? Za kaj boste prevzeli odgovornost, ker mislite, da ste kos nalogi? In tukaj bo nekdo takoj začel zanikati: ne, ne, ne, sploh se nimam želje ukvarjati s projektnimi viri, to ni moja stvar, sem tehnični tip in razumem uporabnost in uporabniške vmesnike, ne sploh želim upravljati z vojskami ljudi, naj grem raje v službo.

In mimogrede, sem velik zagovornik pristopa, pri katerem tovrstno ločevanje veščin dobro deluje. Kjer lahko tehniki razvijejo svojo kariero, kolikor želijo. Še vedno pa vidim organizacije, kjer se tehniki pritožujejo: moral bom iti v projektni menedžment, ker je to edini način v tem podjetju. Včasih to vodi do groznih rezultatov. Najboljši tehniki sploh niso dobri menedžerji in najboljši menedžerji ne obvladajo tehnologije. Bodimo iskreni glede tega.

Zdaj vidim veliko povpraševanje po tem. Če ste strokovnjak za tehnologijo, vam lahko vaše podjetje pomaga, a ne glede na to, morate, resnično morate najti svojo lastno poklicno pot, saj se tehnologija nenehno spreminja in skupaj z njo se morate na novo odkriti! V samo dvajsetih letih se lahko tehnologije spremenijo vsaj petkrat. Tehnologija je čudna reč...

"Strokovnjaki za vse"

Michael: Kako se lahko ljudje spopadamo s tako hitrostjo tehnoloških sprememb? Njihova kompleksnost je vse večja, njihovo število narašča, skupna količina komunikacije med ljudmi narašča in izkaže se, da ne moreš postati »strokovnjak za vse«.

Tim: Prav! Če se ukvarjaš s tehnologijo, ja, vsekakor moraš izbrati nekaj specifičnega in se v to poglobiti. Neka tehnologija, ki se zdi vaši organizaciji uporabna (in morda bo dejansko uporabna). In če vas to ne zanima več - nikoli ne bi verjel, da bom to rekel - no, morda bi se morali preseliti v kakšno drugo organizacijo, kjer je tehnologija bolj zanimiva ali primernejša za študij.

Ampak na splošno ja, imaš prav. Tehnologije rastejo v vse smeri hkrati, nihče ne more reči "sem strokovnjak tehnolog za vse tehnologije, ki obstajajo." Na drugi strani pa so gobice, ki dobesedno vpijajo tehnološko znanje in so nori nanj. Videl sem nekaj takih ljudi, dobesedno dihajo in živijo, z njimi se je koristno in zanimivo pogovarjati. Ne preučujejo le dogajanja znotraj organizacije, ampak na splošno govorijo o tem, so tudi res kul tehnologi, so zelo zavestni in namenski. Samo poskušajo ostati na grebenu vala, ne glede na to, kaj je njihova glavna naloga, saj je njihova strast gibanje tehnologije, promocija tehnologije. Če nenadoma srečate takšno osebo, pojdite z njim na kosilo in se med kosilom pogovarjajte o različnih kul stvareh. Mislim, da vsaka organizacija potrebuje vsaj nekaj takih ljudi.

Tveganja in negotovost

Michael: Spoštovani inženirji, da. Dotaknimo se obvladovanja tveganj, dokler imamo čas. Ta intervju smo začeli z razpravo o medicinski programski opremi, kjer lahko napake povzročijo hude posledice. Nato smo govorili o lunarnem programu, kjer je cena napake milijone dolarjev in morda več človeških življenj. Zdaj pa opažam nasprotno gibanje v panogi, ljudje ne razmišljajo o tveganjih, jih ne poskušajo predvideti, niti jih ne opazujejo.

Oleg: Hitro se premikajte in zlomite stvari!

Michael: Da, premikaj se hitro, lomi stvari, vedno več stvari, dokler zaradi nečesa ne umreš. Kako naj se z vašega vidika zdaj povprečen razvijalec loti učenja obvladovanja tveganj?

Tim: Tu potegnemo črto med dvema stvarema: tveganjem in negotovostjo. To so različne stvari. Negotovost se pojavi, ko v danem trenutku nimate dovolj podatkov, da bi prišli do dokončnega odgovora. Na primer, če vas nekdo v zelo zgodnji fazi projekta vpraša, "kdaj boste končali delo", če ste dokaj poštena oseba, boste rekli: "Nimam pojma." Samo ne veš, in to je v redu. Še niste preučili problemov in ne poznate ekipe, ne poznate njihovih veščin itd. To je negotovost.

Tveganja se pojavijo, ko je morebitne težave že mogoče prepoznati. Kaj takega se lahko zgodi, verjetnost je večja od nič, a manjša od sto odstotkov, nekje vmes. Zaradi nje se lahko zgodi karkoli, od zamud in nepotrebnega dela, pa tudi do usodnega izida za projekt. Rezultat, ko rečeš - fantje, zložimo senčnike in gremo s plaže, nikoli je ne bomo dokončali, vsega je konec in pika. Predvidevali smo, da bo zadeva delovala, a nikakor ne deluje, čas je, da se ustavimo. To so situacije.

Pogosto je težave najlažje rešiti, ko se že pojavijo, ko se težava dogaja prav zdaj. Ko pa je problem tik pred vami, ne upravljate tveganja – ukvarjate se z reševanjem problemov, kriznim upravljanjem. Če ste vodilni razvijalec ali vodja, se zagotovo sprašujete, kaj bi se lahko zgodilo, da bi prišlo do zamud, izgubljenega časa, nepotrebnih stroškov ali propada celotnega projekta? Kaj nas bo prisililo, da se ustavimo in začnemo znova? Ko bodo vse te stvari delovale, kaj bomo naredili z njimi? Obstaja preprost odgovor, ki velja za večino situacij: ne bežite pred tveganji, delajte na njih. Poglejte, kako lahko rešite tvegano situacijo, jo zmanjšate na nič, spremenite iz problema v nekaj drugega. Namesto da bi rekli: dobro, probleme bomo reševali, ko bodo nastali.

Negotovost in tveganje naj bosta v ospredju vsega, s čimer se ukvarjate. Lahko naredite projektni načrt, si vnaprej ogledate določena kritična tveganja in rečete: s tem se moramo ukvarjati zdaj, kajti če bo karkoli od tega šlo narobe, nič drugega ne bo pomembno. Ne bi smeli skrbeti za lepoto prta na mizi, če ni jasno, ali lahko skuhate večerjo. Najprej je treba prepoznati vsa tveganja priprave okusne večerje, se z njimi spopasti in šele nato razmišljati o vseh drugih stvareh, ki ne predstavljajo prave grožnje.

Še enkrat, kaj naredi vaš projekt edinstven? Poglejmo, kaj lahko povzroči, da naš projekt zaide s tira. Kaj lahko storimo, da zmanjšamo verjetnost, da se to zgodi? Običajno jih ne morete kar 100% nevtralizirati in mirne vesti izjaviti: "To je to, to ni več problem, tveganje je odpravljeno!" Zame je to znak odraslega vedenja. To je razlika med otrokom in odraslim - otroci mislijo, da so nesmrtni, da nič ne more biti narobe, vse bo dobro! Obenem odrasli opazujejo, kako triletni otroci skačejo po igrišču, z očmi spremljajo gibanje in si rečejo: "ooooooooooooooooooooooooooo Stojim zraven in se pripravljam, da ujamem, kdaj bo otrok padel.

Po drugi strani pa mi je ta posel tako všeč, ker je tvegan. Delamo stvari in te stvari so tvegane. Potrebujejo pristop odraslih. Samo entuziazem ne bo rešil vaših težav!

Inženirsko razmišljanje odraslih

Michael: Zgled z otroki je dober. Če sem navaden inženir, potem sem vesel, da sem otrok. Toda kako se premakniti k bolj odraslemu razmišljanju?

Tim: Ena od idej, ki enako dobro deluje tako pri začetniku kot pri uveljavljenem razvijalcu, je koncept konteksta. Kaj delamo, kaj bomo dosegli. Kaj je res pomembno pri tem projektu? Ni pomembno, kdo ste pri tem projektu, ali ste pripravnik ali glavni arhitekt, vsi potrebujejo kontekst. Vse moramo pripraviti do tega, da razmišljajo širše kot o svojih delih dela. "Ustvarjam svoj del in dokler moj del deluje, sem srečen." Ne in še enkrat ne. Vedno je vredno (ne da bi bili nesramni!) ljudi spomniti na kontekst, v katerem delajo. Kar skušamo vsi skupaj doseči. Zamisli, da si lahko otrok, dokler je s tvojim delom projekta vse v redu – prosim, ne počni tega. Če bomo ciljno črto sploh prečkali, jo bomo prečkali le skupaj. Niste sami, vsi smo skupaj. Če bi se vsi ljudje v projektu, tako stari kot mladi, začeli pogovarjati o tem, kaj točno je pomembno za projekt, zakaj podjetje vlaga denar v to, kar vsi skušamo doseči ... se bo večina počutila veliko bolje, ker bodo videli, kako je njihovo delo povezano z delom vseh ostalih. Po eni strani razumem komad, za katerega sem osebno odgovoren. Toda za dokončanje dela potrebujemo tudi vse druge ljudi. In če res mislite, da ste končali, nas v projektu vedno čaka delo!

Oleg: Relativno gledano, če delaš po Kanbanu, ko naletiš na ozko grlo nekega testiranja, lahko nehaš s tem, kar si tam počel (na primer programiranje) in greš pomagat testerjem.

Tim: Točno tako. Mislim, da so najboljši tehniki, če jih natančno pogledate, nekakšni sami sebi menedžerji. Kako naj to formuliram...

Oleg: Vaše življenje je vaš projekt, ki ga upravljate.

Tim: točno tako! Mislim, prevzameš odgovornost, razumeš problematiko in prideš v stik z ljudmi, ko vidiš, da lahko tvoje odločitve vplivajo na njihovo delo, take stvari. Ne gre za to, da samo sedite za svojo mizo, opravljate svoje delo in se sploh ne zavedate, kaj se dogaja okoli vas. Ne ne ne. Mimogrede, ena najboljših stvari pri Agileu je ta, da so predlagali kratke sprinte, ker je tako jasno opazno stanje vseh udeležencev, vidijo vse skupaj. Vsak dan se pogovarjava drug o drugem.

Kako vstopiti v upravljanje tveganj

Oleg: Ali obstaja kakšna formalna struktura znanja na tem področju? Na primer, jaz sem razvijalec Java in želim razumeti obvladovanje tveganj, ne da bi po izobrazbi postal pravi projektni vodja. Verjetno bom najprej prebral McConnellov "How Much Does a Software Project Cost" in kaj potem? Kakšni so prvi koraki?

Tim: Prvi je, da začnete komunicirati z ljudmi v projektu. To zagotavlja takojšnje izboljšanje kulture komunikacije s sodelavci. Začeti moramo tako, da vse privzeto odpremo, namesto da skrijemo. Reci: to so stvari, ki me motijo, to so stvari, zaradi katerih ponoči ne morem spati, danes sem se ponoči zbudil in si rekel: moj bog, o tem moram razmišljati! Ali drugi vidijo isto? Ali bi se morali kot skupina odzvati na te morebitne težave? Morate biti sposobni podpreti razpravo o teh temah. Vnaprej pripravljene formule, po kateri delamo, ni. Ne gre za pripravo hamburgerjev, ampak za ljudi. »Naredil burger s sirom, prodal burger s sirom« sploh ni naša stvar in zato mi je to delo tako všeč. Všeč mi je, ko vse, kar so delali menedžerji, zdaj postane last ekipe.

Oleg: V knjigah in intervjujih ste govorili o tem, da je ljudem bolj mar za srečo kot za številke na grafu. Po drugi strani pa, ko poveš ekipi: prehajamo na devops in zdaj mora programer nenehno komunicirati, je to morda daleč izven njegove cone udobja. In v tem trenutku je lahko, recimo, globoko nesrečen. Kaj storiti v tej situaciji?

Tim: Ne vem točno, kaj naj naredim. Če je razvijalec preveč izoliran, sploh ne vidi, zakaj je delo opravljeno, gleda le na svoj del dela in mora priti v to, čemur jaz pravim "kontekst". Ugotoviti mora, kako je vse skupaj povezano. In seveda ne mislim na formalne predstavitve ali kaj podobnega. Govorim o tem, da je treba s sodelavci komunicirati o delu kot celoti, ne le o delu, za katerega ste odgovorni. Tukaj lahko začnete razpravljati o idejah, skupnih dogovorih, da bo vaše delo dobro usklajeno, in o tem, kako skupaj rešiti skupno težavo.

Da bi jim pomagali pri prilagajanju, pogosto želijo poslati tehnike na usposabljanje in se pogovarjajo o usposabljanju. Moj prijatelj rad reče, da je šolanje za pse. Obstaja usposabljanje za ljudi. Ena najboljših stvari pri učenju kot razvijalec je interakcija z vrstniki. Če je nekdo v nečem res dober, ga morate opazovati pri delu ali se z njim pogovarjati o njegovem delu ali kaj podobnega. Neki konvencionalni Kent Beck je nenehno govoril o ekstremnem programiranju. Smešno je, ker je XP tako preprosta ideja, vendar povzroča toliko težav. Za nekatere je izvajanje XP kot bi bili prisiljeni sleči se goli pred prijatelji. Bodo videli, kaj počnem! So moji kolegi, ne bodo samo videli, ampak tudi razumeli! Grozno! Nekateri ljudje začnejo postajati resno živčni. A ko ugotoviš, da je to ultimativni način učenja, se vse spremeni. Tesno sodelujete z ljudmi in nekateri razumejo temo veliko bolje kot vi.

Michael: A vse to te prisili, da stopiš iz cone udobja. Kot inženir moraš izstopiti iz cone udobja in komunicirati. Kot reševalec problemov se morate nenehno postavljati v šibek položaj in razmišljati, kaj bi lahko šlo narobe. Ta vrsta dela je sama po sebi zasnovana tako, da je nadloga. Zavestno se spravljate v stresne situacije. Običajno ljudje bežijo od njih, ljudje so radi veseli otroci.

Tim: Kaj se da, lahko stopite ven in odkrito rečete: »Vse je v redu, zmorem! Nisem edini, ki se počuti neprijetno. Razpravljajmo o različnih neprijetnih stvareh, vsi skupaj, kot ekipa!« To so naše skupne težave, z njimi se moramo spopasti, veš? Mislim, da so idiosinkratični genialni razvijalci kot mamuti, izginili so. In njihov pomen je zelo omejen. Če ne znaš komunicirati, ne moreš dobro sodelovati. Zato samo govori. Bodite iskreni in odprti. Zelo mi je žal, da je to nekomu neprijetno. Si predstavljate, pred mnogimi leti je bila študija, po kateri glavni strah v ZDA ni smrt, ampak uganite kaj? Strah pred javnim nastopanjem! To pomeni, da nekje obstajajo ljudje, ki bi raje umrli, kot da bi na glas rekli kompliment. In mislim, da je dovolj, da imate nekaj osnovnih veščin, odvisno od tega, kaj počnete. Govorne sposobnosti, pisne veščine – a le toliko, kolikor jih resnično potrebujete pri svojem delu. Če delate kot analitik, vendar ne znate brati, pisati ali govoriti, potem na žalost ne boste imeli kaj početi v mojih projektih!

Cena komunikacije

Oleg: Ali ni zaposlovanje takih odhajajočih sodelavcev zaradi različnih razlogov dražje? Konec koncev nenehno klepetajo, namesto da bi delali!

Tim: Mislil sem na jedro ekipe in ne na vse. Če imate nekoga, ki je res kul pri nastavljanju podatkovnih baz, obožuje uglaševanje podatkovnih baz in bo še naprej nastavljal vaše baze podatkov do konca svojega življenja in to je to, kul, kar tako naprej. Ampak govorim o ljudeh, ki želijo živeti v samem projektu. Jedro ekipe, usmerjeno v razvoj projekta. Ti ljudje morajo res nenehno komunicirati med seboj. In še posebej na začetku projekta, ko se pogovarjate o tveganjih, načinih doseganja globalnih ciljev in podobno.

Michael: To velja za vse, ki sodelujejo pri projektu, ne glede na specializacijo, veščine ali način dela. Vsi ste zainteresirani za uspeh projekta.

Tim: Da, čutite, da ste dovolj vpeti v projekt, da je vaša naloga pomagati projektu uresničiti. Ne glede na to, ali ste programer, analitik, oblikovalec vmesnikov, kdorkoli. To je razlog, da vsako jutro pridem v službo in to počnemo. Odgovorni smo za vse te ljudi, ne glede na njihovo znanje. To je skupina ljudi, ki se pogovarjajo za odrasle.

Oleg: Pravzaprav, ko sem govoril o zgovornih zaposlenih, sem poskušal simulirati ugovore ljudi, zlasti menedžerjev, od katerih se zahteva, da preidejo na devops, na to popolnoma novo vizijo sveta. In vi kot svetovalci bi se morali teh ugovorov zavedati veliko bolje kot jaz kot razvijalec! Delite, kaj menedžerje najbolj skrbi?

Tim: Vodje? Hm. Najpogosteje so menedžerji pod pritiskom težav, soočeni s potrebo po nujnem sproščanju in dobavi in ​​podobno. Gledajo, kako nenehno razpravljamo in se prepiramo o nečem, in to vidijo takole: pogovori, pogovori, pogovori ... Kakšni drugi pogovori? Nazaj na delo! Ker se jim pogovor ne zdi delo. Ne pišete kode, ne preizkušate programske opreme, zdi se, da ne delate ničesar - zakaj vas ne bi poslali, da nekaj naredite? Navsezadnje je dostava že čez en mesec!

Michael: Pojdi napiši kodo!

Tim: Zdi se mi, da jih ne skrbi delo, ampak nevidnost napredka. Da se zdi, da smo bližje uspehu, nas morajo videti, kako pritiskamo gumbe na tipkovnici. Ves dan od jutra do večera. To je problem številka ena.

Oleg: Miša, o nečem razmišljaš.

Michael: Oprostite, izgubil sem se v mislih in ujel preblisk. Vse to me je spomnilo na zanimiv shod, ki se je zgodil včeraj... Včeraj je bilo shodov preveč... In vse skupaj zveni zelo znano!

Življenje brez plač

Tim: Mimogrede, za komunikacijo sploh ni potrebno organizirati "shodov". Mislim, najbolj koristne razprave med razvijalci se zgodijo, ko se le pogovarjajo drug z drugim. Zjutraj vstopiš s skodelico kave, pa je zbranih pet ljudi, ki besno razpravljajo o nečem tehničnem. Zame, če sem vodja tega projekta, je bolje, da se samo nasmehnem in grem nekam glede svojega posla, naj se o tem pogovorijo. So že vključeni, kolikor se da. To je dober znak.

Oleg: Mimogrede, v svoji knjigi imate kup zapiskov o tem, kaj je dobro in kaj slabo. Ali tudi sami uporabljate katero od njih? Relativno gledano, zdaj imate podjetje, ki je strukturirano na zelo neortodoksen način ...

Tim: Neortodoksno, vendar nam ta naprava popolnoma ustreza. Poznamo se že dolgo. Zaupava si, zelo sva si zaupala, preden sva postala partnerja. In na primer sploh nimamo plač. Samo delamo in na primer, če sem zaslužil denar od svojih strank, potem je ves denar šel meni. Nato organizaciji plačamo članarino, to pa je dovolj za vzdrževanje podjetja. Poleg tega smo vsi specializirani za različne stvari. Na primer, delam z računovodji, izpolnjujem davčne napovedi, delam vse mogoče administrativne zadeve za podjetje, pa me nihče ne plača za to. James in Tom delata na naši spletni strani in ju tudi nihče ne plača. Dokler boste plačevali svoje obveznosti, vam nihče ne bo pomislil, da bi vam rekel, kaj morate storiti. Na primer, Tom zdaj dela veliko manj kot nekoč. Zdaj ima druge interese; nekatere stvari počne ne za ceh. Toda dokler bo plačeval svoje obveznosti, nihče ne bo prišel do njega in mu rekel: "Hej, Tom, pojdi delat!" Zelo enostavno se je sprijazniti s kolegi, ko med vama ni denarja. In zdaj je naš odnos ena temeljnih idej v zvezi z različnimi specialnostmi. Deluje in deluje zelo dobro.

Najboljši nasvet

Michael: Če se vrnem k »najboljšemu nasvetu«, ali svojim strankam vedno znova poveste kaj? Obstaja ideja o 80/20, nekateri nasveti pa se verjetno pogosteje ponavljajo.

Tim: Nekoč sem mislil, da če bi napisal knjigo, kot je Valček z medvedi, bi to spremenilo tok zgodovine in bi se ljudje ustavili, ampak ... No, poglejte, podjetja se velikokrat pretvarjajo, da je z njimi vse v redu. Takoj, ko se zgodi nekaj slabega, je to za njih šok in presenečenje. »Poglejte, testirali smo sistem in ne prestane nobenih sistemskih testov, to pa so še trije meseci nenačrtovanega dela, kako se je to lahko zgodilo? Kdo je vedel? Kaj bi lahko šlo narobe? Resno, ali verjameš temu?

Poskušam razložiti, da se ne bi smeli preveč jeziti zaradi trenutne situacije. O tem se moramo pogovoriti, resnično razumeti, kaj bi lahko šlo narobe, in kako preprečiti, da bi se takšne stvari dogajale v prihodnosti. Če se težava vendarle pojavi, kako se bomo z njo borili, kako jo bomo zajezili?

Meni se vse to zdi strašljivo. Ljudje se ukvarjajo z zapletenimi, mučnimi težavami in se še naprej pretvarjajo, da se bo »najboljše« dejansko zgodilo, če le držijo pesti in upajo na najboljše. Ne, ne gre tako.

Vadite obvladovanje tveganj!

Michael: Koliko organizacij se po vašem mnenju ukvarja z obvladovanjem tveganj?

Tim: Jezi me, da si ljudje preprosto zapišejo tveganja, pogledajo nastali seznam in se lotijo ​​dela. Pravzaprav je prepoznavanje tveganj zanje obvladovanje tveganj. Ampak meni se to zdi razlog, da se vprašam: v redu, obstaja seznam, kaj točno boste spremenili? Ob upoštevanju teh tveganj morate spremeniti svoja standardna zaporedja dejanj. Če obstaja najtežji del dela, se ga morate lotiti in šele nato preiti na nekaj preprostejšega. V prvih sprintih začnite reševati kompleksne probleme. To že izgleda kot obvladovanje tveganj. Toda običajno ljudje ne morejo reči, kaj so spremenili, potem ko so sestavili seznam tveganj.

Michael: Pa vendar, koliko teh podjetij se ukvarja z upravljanjem tveganj, pet odstotkov?

Tim: Na žalost tega ne želim reči, vendar je to zelo nepomemben del. Ampak več kot pet, ker so res veliki projekti in preprosto ne morejo obstajati, če vsaj nečesa ne naredijo. Naj povem, da bom zelo presenečen, če bo vsaj 25%. Majhni projekti običajno na takšna vprašanja odgovarjajo takole: če nas problem prizadene, ga bomo rešili. Potem se uspešno spravijo v težave in se lotijo ​​obvladovanja problemov in kriznega upravljanja. Ko poskušate rešiti problem, pa problem ni rešen, dobrodošli v kriznem upravljanju.

Da, pogosto slišim, "težave bomo reševali, ko se bodo pojavile." Zagotovo bomo? Se bomo res odločili?

Oleg: To lahko storite naivno in preprosto zapišete pomembne invariante v listino projekta, in če se invariante pokvarijo, preprosto znova zaženite projekt. Izpade zelo piembucky.

Michael: Da, zgodilo se mi je, da so ob sproženih tveganjih projekt preprosto redefinirali. Bravo, bingo, problem rešen, ne skrbi več!

Tim: Pritisnimo gumb za ponastavitev! Ne, ne gre tako.

Osrednja beseda na DevOops 2019

Michael: Prišli smo do zadnjega vprašanja tega intervjuja. Na naslednji DevOops prihajate z osrednjo besedo, ali bi lahko dvignili zaveso skrivnosti, kaj boste povedali?

Tim: Prav zdaj jih šest piše knjigo o kulturi dela, neizrečenih pravilih organizacij. Kulturo določajo temeljne vrednote organizacije. Običajno ljudje tega ne opazimo, vendar smo zaradi dolgoletnega dela v svetovanju navajeni tega opaziti. Vstopite v podjetje in dobesedno v nekaj minutah začnete čutiti, kaj se dogaja. Temu pravimo "okus". Včasih je ta vonj res dober, včasih pa, no, ups. Stvari so zelo različne za različne organizacije.

Michael: Tudi jaz že leta delam v svetovanju in dobro razumem o čem govorite.

Tim: Pravzaprav je ena od stvari, o kateri je vredno govoriti na osrednjem govoru, ta, da ni vse odvisno od podjetja. Vi in vaša ekipa imate kot skupnost svojo timsko kulturo. To je lahko celotno podjetje ali ločen oddelek, ločena ekipa. Toda preden ste rekli, to je tisto, kar verjamemo, to je tisto, kar je pomembno ... Ne morete spremeniti kulture, dokler ne razumete vrednot in prepričanj, ki stojijo za določenimi dejanji. Vedenje je lahko opazovati, težko pa je iskanje prepričanj. DevOps je le odličen primer, kako stvari postajajo vse bolj zapletene. Interakcije postajajo samo še kompleksnejše, nič bolj čiste in jasne, zato se je treba zamisliti, v kaj verjameš in o čem vsi okoli tebe molčijo.

Če želite doseči hitre rezultate, je tukaj dobra tema za vas: ste videli podjetja, kjer nihče ne reče "ne vem"? Obstajajo kraji, kjer človeka dobesedno mučiš, dokler ne prizna, da nečesa ne ve. Vsi vedo vse, vsi so neverjetni eruditi. Približate se kateri koli osebi in ta mora takoj odgovoriti na vprašanje. Namesto da rečete "ne vem." Hura, najeli so kup eruditov! In v nekaterih kulturah je na splošno zelo nevarno reči "ne vem"; to se lahko dojema kot znak šibkosti. Obstajajo tudi organizacije, v katerih lahko, nasprotno, vsakdo reče "ne vem." Tam je to popolnoma legalno in če nekdo začne begati na vprašanje, je povsem normalno, da odgovori: "Ne veš, kaj govoriš, kajne?" in vse skupaj obrniti na šalo.

V idealnem primeru bi radi imeli službo, v kateri bi bili lahko ves čas srečni. Ne bo lahko, ni vsak dan sončen in prijeten, včasih se je treba potruditi, a ko začneš delati bilanco, se bo izkazalo: vau, to je res čudovit kraj, dobro se počutim, ko delam tukaj, tako čustveno kot intelektualno. In so podjetja, kamor greš kot svetovalec in takoj ugotoviš, da ne bi zdržal tri mesece in bi zgrožen pobegnil. To je tisto, o čemer želim govoriti v poročilu.

Tim Lister bo prišel z glavnim govorom "Liki, skupnost in kultura: pomembni dejavniki za blaginjo"na konferenco DevOops 2019, ki bo potekala od 29. do 30. oktobra 2019 v St. Lahko kupite vstopnice na uradni spletni strani. Čakamo vas na DevOops!

Vir: www.habr.com