Tim Lister – raamatute kaasautor
- "Inimfaktor. Edukad projektid ja meeskonnad" (algse raamatu nimi on "Peopleware")
- "Karudega valss: tarkvaraprojektide riskijuhtimine"
- “Adrenaliinihull ja mustritest zombistunud. Projektimeeskondade käitumismustrid"
Kõik need raamatud on oma ala klassikud ja on kirjutatud koos kolleegidega aastal . Venemaal on tema kolleegid kõige kuulsamad - и , kes kirjutas ka palju kuulsaid teoseid.
Timil on 40-aastane tarkvaraarenduse kogemus, 1975. aastal (ükski selle habraposti kirjutajatest ei sündinud sel aastal) oli Tim juba Yourdon Inc. tegevasepresident. Nüüd veedab ta aega nõu pidades, õpetades ja kirjutades, aeg-ajalt külastades konverentsidel üle maailma.
Tegime Tim Listeriga intervjuu spetsiaalselt Habrile. Ta avab DevOops 2019 konverentsi ja meil on palju küsimusi raamatute ja muu kohta. Intervjuu viivad läbi Mihhail Družinin ja Oleg Tširuhhin konverentsi programmikomiteest.
Michael: Kas saate öelda paar sõna selle kohta, mida te praegu teete?
Tim: Olen Atlantic Systems Guildi juht. Meid on Gildis kuus, me kutsume end direktoriteks. Kolm USA-s ja kolm Euroopas – seepärast nimetatakse gildi Atlandi ookeaniks. Oleme nii palju aastaid koos olnud, et neid lihtsalt ei jõua üles lugeda. Meil kõigil on oma eripärad. Olen töötanud klientidega viimase kümnendi või rohkemgi. Minu projektid ei hõlma mitte ainult juhtimist, vaid ka nõuete seadmist, projektide planeerimist ja hindamist. Tundub, et halvasti alanud projektid lõppevad tavaliselt halvasti. Seetõttu tasub jälgida, et kõik tegevused oleksid tõesti hästi läbi mõeldud ja koordineeritud, et tegijate ideed oleksid kombineeritud. Tasub mõelda, mida sa teed ja miks. Milliseid strateegiaid kasutada projekti lõpuleviimiseks.
Olen aastaid nõustanud kliente mitmel erineval viisil. Huvitav näide on ettevõte, mis toodab põlve- ja puusaoperatsioonide jaoks roboteid. Kirurg ei tegutse täiesti iseseisvalt, vaid kasutab robotit. Ohutus on siin ausalt öeldes oluline. Aga kui proovite arutada nõudeid inimestega, kes on keskendunud probleemide lahendamisele... See kõlab imelikult, aga USA-s on (Föderaalne ravimiamet), mis litsentsib selliseid tooteid nagu need robotid. Enne kui müüte midagi ja kasutate seda elavatel inimestel, peate hankima litsentsi. Üks tingimus on näidata oma nõudeid, millised on testid, kuidas testisid, millised on testi tulemused. Kui muudate nõudeid, peate kogu selle tohutu testimisprotsessi ikka ja jälle läbima. Meie klientidel õnnestus lisada oma nõuete hulka rakenduste visuaalne disain. Neil olid ekraanipildid otse osana nõuetest. Peame need välja tõmbama ja selgitama, et enamasti ei tea kõik need programmid midagi põlvedest ja puusadest, kõigest sellest kaamerast jne. Peame nõuete dokumendid ümber kirjutama nii, et need ei muutuks kunagi, välja arvatud juhul, kui muutuvad mõned tõeliselt olulised alustingimused. Kui visuaalne disain pole nõuetes, on toote värskendamine palju kiirem. Meie ülesanne on leida need elemendid, mis käsitlevad põlve-, puusa-, seljaoperatsioone, tõmmata need eraldi dokumentidesse ja öelda, et need on põhinõuded. Teeme põlveoperatsioonide kohta eraldiseisva nõuete rühma. See võimaldab meil luua stabiilsema nõuete kogumi. Räägime kogu tootesarjast, mitte konkreetsetest robotitest.
Tehti palju tööd, kuid siiski jõuti kohtadesse, kus varem veedeti nädalaid ja kuid mõttetult ja vajaduseta korduvaid katsetusi, sest nende paberil kirjeldatud nõuded ei langenud kokku tegelike nõuetega, mille jaoks süsteemid ehitati. FDA ütles neile iga kord: teie nõuded on muutunud, nüüd peate kõike nullist kontrollima. Kogu toote täielik korduskontroll tappis ettevõtte.
Seega on selliseid imelisi ülesandeid, kui leiate end millegi huvitava alguses ja juba esimesed toimingud määravad edasised mängureeglid. Kui veendute, et see varane tegevus hakkab hästi toimima nii juhtimis- kui ka tehnilisest aspektist, on võimalus, et saate lõpuks suurepärase projekti. Aga kui see osa on rööpast välja läinud ja kuhugi valesti läinud, kui te ei leia põhimõttelisi kokkuleppeid... ei, see ei tähenda, et teie projekt tingimata ebaõnnestub. Kuid te ei saa enam öelda: "Me saime suurepäraselt hakkama, tegime kõike tõeliselt tõhusalt." Need on asjad, mida ma klientidega suheldes teen.
Michael: See tähendab, et käivitate projekte, teete mingi avalööki ja kontrollite, kas rööpad liiguvad õiges suunas?
Tim: Meil on ka ideid, kuidas kõik pusletükid kokku panna: milliseid oskusi vajame, millal neid täpselt vaja läheb, milline näeb välja meeskonna tuumik ja muud sellist põhimõttelist. Kas vajame täiskohaga töötajaid või saame palgata kellegi osalise tööajaga? Planeerimine, juhtimine. Sellised küsimused nagu: Mis on selle konkreetse projekti jaoks kõige olulisem? Kuidas seda saavutada? Mida me selle toote või projekti kohta teame, millised on riskid ja kus peituvad teadmatused, kuidas me selle kõigega toime tuleme? Muidugi hakkab sel hetkel keegi karjuma “Aga agile?!” Olgu, te olete kõik paindlikud, aga mis siis saab? Kuidas projekt täpselt välja näeb, kuidas kavatsete selle projektiga sobival viisil välja võtta? Sa ei saa lihtsalt öelda, et "meie lähenemine ulatub kõigele, me oleme Scrumi meeskond!" See on jama ja jama. Kuhu kavatsete edasi minna, miks see peaks toimima, kus on mõte? Õpetan oma kliente kõigi nende küsimuste üle mõtlema.
19 aastat väledat
Michael: Agile’is püütakse sageli mitte midagi ette defineerida, vaid teha otsuseid võimalikult hilja, öeldes: me oleme liiga suured, ma ei mõtle üldisele arhitektuurile. Ma ei mõtle paljudele muudele asjadele, selle asemel annan kliendile midagi, mis töötab kohe.
Tim: Ma arvan, et agiilsed metoodikad, alustades aastal 2001 avas tööstuse silmad. Kuid teisest küljest pole miski täiuslik. Olen igati korduva arengu poolt. Iteratsioonil on enamiku projektide puhul palju mõtet. Kuid küsimus, millele peate mõtlema, on järgmine: kui toode on väljas ja kasutuses, kui kaua see kestab? Kas see on toode, mis kestab kuus kuud, enne kui millegi muuga asendatakse? Või on see toode, mis töötab palju-palju aastaid? Nimesid ma muidugi ei nimeta, aga... New Yorgis ja selle finantsringkonnas on kõige fundamentaalsemad süsteemid väga vanad. See on hämmastav. Vaatad neid ja mõtled, kui vaid saaksid minna ajas tagasi, aastasse 1994, ja öelda arendajatele: „Ma tulin tulevikust, aastast 2019. Lihtsalt arendage seda süsteemi nii kaua, kui vajate. Tehke see laiendatavaks, mõelge arhitektuurile. Seejärel täiustatakse seda rohkem kui kakskümmend viis aastat. Kui arengut veidi kauem edasi lükata, siis suures plaanis ei pane seda keegi tähele! Kui hindate asju pikemas perspektiivis, peate arvestama, kui palju see kokku maksab. Mõnikord on hästi kavandatud arhitektuur seda tõesti väärt, mõnikord aga mitte. Peame ringi vaatama ja endalt küsima: kas oleme sellise otsuse jaoks õiges olukorras?
Nii et selline idee nagu “Oleme agiilsuse poolt, klient ise ütleb meile, mida ta saada tahab” – see on ülinaiivne. Kliendid isegi ei tea, mida nad tahavad, ja veelgi enam, nad ei tea, mida nad võiksid saada. Mõned inimesed hakkavad argumendina tooma ajaloolisi näiteid, ma olen seda juba näinud. Kuid tehniliselt arenenud inimesed seda tavaliselt ei ütle. Nad ütlevad: "On aasta 2019, need on meie võimalused ja me saame täielikult muuta seda, kuidas me nendesse asjadesse suhtume!" Selle asemel, et jäljendada olemasolevaid lahendusi, muuta need veidi ilusamaks ja kammitumaks, tuleb mõnikord välja minna ja öelda: "Leiutame täielikult uuesti, mida me siin teha proovime!"
Ja ma arvan, et enamik kliente ei suuda probleemile nii mõelda. Nad näevad ainult seda, mis neil juba on, see on kõik. Pärast seda esitavad nad taotlusi, nagu "teeme selle natuke lihtsamaks" või mida iganes nad tavaliselt ütlevad. Aga me ei ole kelnerid ega ettekandjad, nii et saame tellimuse vastu võtta ükskõik kui lollimaks osutub ja siis köögis küpsetada. Meie oleme nende teejuhid. Peame nende silmad avama ja ütlema: hei, meil on siin uued võimalused! Kas mõistate, et me saame tõesti muuta viisi, kuidas seda teie ettevõtte osa tehakse? Üks Agile'i probleeme on see, et see eemaldab teadlikkuse sellest, mis on võimalus, mis on probleem, mida me üldse peame tegema, millised olemasolevad tehnoloogiad sobivad selle konkreetse olukorra jaoks kõige paremini.
Võib-olla olen ma siin liiga skeptiline: agiilses kogukonnas toimub palju imelisi asju. Aga mul on probleem sellega, et projekti defineerimise asemel hakkavad inimesed käega lööma. Küsiks siinkohal - mida me teeme, kuidas me seda tegema hakkame? Ja kuidagi võluväel tuleb alati välja, et klient peaks teadma paremini kui keegi teine. Klient teab aga kõige paremini alles siis, kui ta valib kellegi poolt juba ehitatud asjade hulgast. Kui tahan autot osta ja tean oma pere eelarve suurust, siis valin kiiresti välja oma elustiilile sobiva auto. Siin ma tean kõike paremini kui keegi teine! Kuid pange tähele, et keegi on autod juba valmistanud. Mul pole aimugi, kuidas uut autot leiutada, ma pole ekspert. Tellimus- või eritoodete loomisel tuleb arvestada kliendi häälega, kuid see pole enam ainus hääl.
Oleg: Mainisite Agile Manifesti. Kas me peame seda kuidagi ajakohastama või üle vaatama, võttes arvesse probleemi tänapäevast arusaama?
Tim: Ma ei puudutaks teda. Minu arvates on see suurepärane ajalooline dokument. Ma mõtlen, et ta on see, mis ta on. Ta saab 19-aastaseks, ta on vana, aga tegi omal ajal revolutsiooni. Mida ta tegi hästi, oli see, et ta vallandas reaktsiooni ja inimesed hakkasid temast sosistama. Tõenäoliselt ei töötanud te 2001. aastal veel selles valdkonnas, kuid siis töötasid kõik protsesside järgi. Tarkvaratehnika instituut, tarkvara täielikkuse mudeli (CMMI) viis taset. Ma ei tea, kas sellised sügava antiigi legendid teile midagi räägivad, aga siis oli see läbimurre. Alguses uskusid inimesed, et kui protsessid on õigesti seadistatud, kaovad probleemid iseenesest. Ja siis tuleb Manifest ja ütleb: "Ei, ei, ei – me lähtume inimestest, mitte protsessidest." Oleme tarkvaraarenduse meistrid. Me mõistame, et ideaalne protsess on miraaž, seda ei juhtu. Projektides on liiga palju omapära, idee ühest täiuslikust protsessist kõigi projektide jaoks ei ole mõttekas. Probleemid on liiga keerulised, et väita, et kõigele on ainult üks lahendus (tere, nirvaana).
Ma ei taha tulevikku vaadata, aga ütlen, et nüüdseks on inimesed hakanud rohkem projektidele mõtlema. Ma arvan, et Agile Manifest on väga hea, et hüpata välja ja öelda: "Hei! Olete laeval ja juhite seda laeva ise. Peate tegema otsuse – me ei paku välja universaalset retsepti kõikideks olukordadeks. Olete laeva meeskond ja kui olete piisavalt hea, võite leida tee eesmärgini. Enne teid oli teisi laevu ja pärast teid on teisi laevu, kuid siiski on teie teekond mõnes mõttes ainulaadne. Midagi sellist! See on mõtteviis. Minu jaoks pole midagi uut päikese all, inimesed on varemgi purjetanud ja purjetavad veel, aga sinu jaoks on see sinu peamine teekond ja ma ei ütle sulle, mis sinuga täpselt juhtub. Sul peavad olema meeskonnas koordineeritud töö oskused ja kui sul need tõesti on, siis kõik õnnestub ja jõuad sinna, kuhu tahtsid.
Peopleware: 30 aastat hiljem
Oleg: Kas Peopleware oli nii revolutsioon kui ka manifest?
Tim: Peopleware... Kirjutasime Tomiga selle raamatu, aga me ei uskunud, et see niimoodi juhtub. Kuidagi resoneeris see paljude inimeste ideedega. See oli esimene raamat, mis ütles: tarkvaraarendus on väga inimmahukas tegevus. Vaatamata oma tehnilisele olemusele oleme ka inimeste kogukond, kes ehitab midagi suurt, isegi tohutut, väga keerulist. Keegi ei saa selliseid asju üksi luua, eks? Nii sai "meeskonna" idee väga oluliseks. Ja mitte ainult juhtimise seisukohalt, vaid ka tehnilistele inimestele, kes tulid kokku, et lahendada tõeliselt keerulisi sügavaid probleeme hunniku tundmatutega. Minu jaoks isiklikult on see kogu mu karjääri jooksul olnud tohutu intelligentsuse proovikivi. Ja siin tuleb osata öelda: jah, see probleem on rohkem, kui ma üksinda hakkama saan, kuid üheskoos leiame elegantse lahenduse, mille üle võime uhkust tunda. Ja ma arvan, et just see idee tekitas kõige rohkem vastukaja. Mõte, et me töötame osa ajast üksinda, osa ajast grupi koosseisus ja sageli teeb otsuse grupp. Grupiprobleemide lahendamine on kiiresti muutunud keerukate projektide oluliseks tunnuseks.
Hoolimata asjaolust, et Tim on pidanud tohutult palju kõnesid, postitatakse neist YouTube'i väga vähe. Saate vaadata aruannet “The Return of Peopleware” aastast 2007. Kvaliteet jätab muidugi soovida.
Michael: Kas viimase 30 aasta jooksul pärast raamatu ilmumist on midagi muutunud?
Tim: Saate seda vaadata mitme erineva nurga alt. Sotsioloogiliselt öeldes... kunagi ammu, lihtsamatel aegadel, istusite teie meeskonnaga ühes kontoris. Sa võiksid olla iga päev lähedal, juua koos kohvi ja arutada tööasju. Tegelikult on muutunud see, et meeskondi saab nüüd jaotada geograafiliselt, erinevates riikides ja ajavööndites, kuid siiski tegelevad nad sama probleemiga ja see lisab täiesti uue keerukuse. See võib kõlada vana kooli moodi, kuid pole midagi sellist, nagu näost näkku suhtlemine, kus olete kõik koos, töötate koos ja võite astuda kolleegi juurde ja öelda, et vaadake, mis ma avastasin, kuidas see teile meeldib? Näost näkku vestlused annavad kiire võimaluse mitteametlikule suhtlusele üleminekuks ja ma arvan, et see peaks meeldima ka agiilsetele entusiastidele. Ja ma olen ka mures, sest tegelikkuses on maailm osutunud väga väikeseks ja nüüd on see kõik kaetud hajutatud meeskondadega ja see kõik on väga keeruline.
Me kõik elame DevOpsis
Michael: Isegi konverentsi programmikomitee seisukohalt on meil inimesi Californias, New Yorgis, Euroopas, Venemaal... Singapuris pole veel kedagi. Geograafia erinevus on üsna suur ja inimesed hakkavad veelgi rohkem laiali minema. Kui me räägime arendusest, kas saate meile rohkem rääkida devopidest ja meeskondade vaheliste barjääride lõhkumisest? On kontseptsioon, et kõik istuvad oma punkrites ja nüüd kukuvad punkrid kokku, mida te sellest analoogiast arvate?
Tim: Mulle tundub, et viimaste tehnoloogiliste läbimurrete valguses on devopsil suur tähtsus. Varem olid teil arendajate ja administraatorite meeskonnad, nad töötasid, töötasid, töötasid ja mingil hetkel ilmus asi, millega sai tulla administraatorite juurde ja selle tootmiseks rullida. Ja siit sai alguse jutt punkri üle, sest adminnid on omamoodi liitlased, mitte vähemalt vaenlased, aga sa rääkisid nendega alles siis, kui kõik oli tootmisse minekuks valmis. Kas läksite nende juurde millegagi ja ütlesite: vaadake, milline rakendus meil on, aga kas te saaksite selle rakenduse kasutusele võtta? Ja nüüd on kogu tarnekontseptsioon paremuse poole muutunud. Tähendab, oli idee, et saaksite muudatused kiiresti läbi suruda. Saame tooteid lennult värskendada. Ma naeratan alati, kui minu sülearvutis Firefox hüppab ja ütleb: "Hei, me värskendasime teie Firefoxi taustal ja niipea, kui teil on vähe aega, klõpsate siin ja me edastame teile uusima versiooni. Ja ma ütlesin: "Oh jah, kallis!" Sel ajal, kui ma magasin, töötasid nad selle nimel, et mulle otse minu arvutisse uus versioon edastada. See on imeline, uskumatu.
Kuid siin on raskus: teil on see funktsioon tarkvara värskendamisel, kuid inimeste integreerimine on palju keerulisem. Ma tahan DevOopsi peakõnes öelda, et meil on nüüd palju rohkem mängijaid kui kunagi varem. Kui mõelda vaid kõigile, kes on seotud vaid ühes meeskonnas…. Te pidasite seda meeskonnaks ja see on palju enamat kui lihtsalt programmeerijate meeskond. Need on testijad, projektijuhid ja hunnik teisi inimesi. Ja igaühel on oma vaade maailmale. Tootejuhid on täiesti erinevad projektijuhtidest. Administraatoritel on oma ülesanded. Üsna keeruliseks probleemiks saab kõigi osalejate koordineerimine, et olla jätkuvalt toimuvaga kursis ja mitte hulluks minna. Eraldada tuleb rühma ülesanded ja kõigile kehtivad ülesanded. See on väga raske ülesanne. Teisest küljest arvan, et see kõik on palju parem kui palju aastaid tagasi. Just sellel teel inimesed kasvavad ja õpivad õigesti käituma. Kui teete integratsiooni, saate aru, et maa-alust arendust ei tohiks olla, et tarkvara päris viimasel hetkel välja ei roomaks nagu jack-in-the-box: nagu, vaadake, mis me siin tegime! Idee seisneb selles, et suudate integreerida ja arendada ning lõpuks veerete end korralikult ja iteratiivselt välja. See kõik tähendab mulle palju. See võimaldab luua rohkem väärtust nii süsteemi kasutajatele kui ka oma kliendile.
Michael: Devopsi kogu idee on pakkuda võimalikult varakult sisukaid arendusi. Ma näen, et maailm on hakanud aina rohkem hoogu minema. Kuidas selliste kiirendustega kohaneda? Kümme aastat tagasi seda ei eksisteerinud!
Tim: Muidugi tahavad kõik järjest rohkem funktsionaalsust. Pole vaja liikuda, lihtsalt kuhja juurde. Mõnikord peate isegi järgmise järkjärgulise värskenduse jaoks tempo maha võtma, et midagi kasulikku tuua – ja see on täiesti normaalne.
Mõte, et pead jooksma, jooksma, jooksma, pole just kõige parem. On ebatõenäoline, et keegi tahab oma elu niimoodi elada. Soovin, et tarnete rütm määraks projekti enda rütmi. Kui toodate lihtsalt väikeste, suhteliselt mõttetute asjade voogu, ei anna see kõik tähendust. Selle asemel, et mõistuseta püüda asju võimalikult varakult vabastada, tasub juhtivate arendajate ning toote- ja projektijuhtidega arutada strateegiat. Kas sellel on isegi mõtet?
Mustrid ja antimustrid
Oleg: Tavaliselt räägitakse mustritest ja antimustritest ning see on erinevus projektide elu ja surma vahel. Ja nüüd, devops purskab meie ellu. Kas sellel on oma mustrid ja antimustrid, mis võivad projekti kohapeal tappa?
Tim: Mustrid ja antimustrid juhtuvad kogu aeg. Midagi rääkida. Noh, on see asi, mida me kutsume "säravateks asjadeks". Inimestele meeldib uus tehnoloogia väga-väga. Neid lihtsalt võlub kõige laheda ja stiilse välimuse sära ning nad ei küsi enam küsimusi: kas see on üldse vajalik? Mida me saavutame? Kas see asi on usaldusväärne, kas sellel on mõtet? Tihti näen inimesi nii-öelda tehnika tipptasemel. Neid hüpnotiseerib maailmas toimuv. Aga kui vaadata lähemalt, mida kasulikku nad teevad, siis sageli pole lihtsalt midagi kasulikku!
Arutasime just kaaslastega, et tänavu on juubeliaasta, viiskümmend aastat inimeste Kuule maandumisest. See oli 1969. aastal. Tehnoloogia, mis aitas inimestel sinna jõuda, ei ole isegi mitte 1969. aasta tehnoloogia, vaid pigem 1960. või 62. aasta tehnoloogia, sest NASA tahtis kasutada ainult seda, millel on head tõendid usaldusväärsuse kohta. Ja nii sa vaatad seda ja saad aru – jah, ja need olid tõesed! Nüüd ei, ei, aga sul tekib tehnoloogiaga probleeme lihtsalt sellepärast, et kõike surutakse liiga kõvasti, müüakse kõigist pragudest. Inimesed karjuvad igalt poolt: "Vaata, mis asi, see on kõige uuem, ilusaim asi maailmas, sobib absoluutselt kõigile!" Noh, see on kõik... tavaliselt osutub see kõik lihtsalt peibutusvahendiks ja siis tuleb see kõik ära visata. Võib-olla on see kõik sellepärast, et ma olen juba vana mees ja vaatan sellistesse asjadesse suure skepsisega, kui inimesed otsa saavad ja ütlevad, et nad on leidnud Ainsa ja Kõige õigema viisi parimate tehnoloogiate loomiseks. Sel hetkel ärkab minu sees hääl, mis ütleb: "Milline segadus!"
Michael: Tõepoolest, kui sageli oleme kuulnud järgmisest hõbekuulist?
Tim: Just, ja see on asjade tavaline käik! Näiteks... tundub, et see on juba üle maailma naljaks saanud, aga siin räägitakse tihti plokiahela tehnoloogiast. Ja tegelikult on neil teatud olukordades mõtet! Kui teil on tõesti vaja usaldusväärseid tõendeid sündmuste kohta, et süsteem töötab ja et keegi pole meid petnud, kui teil on turvaprobleeme ja kõik muu segamini, on plokiahel mõistlik. Aga kui nad ütlevad, et Blockchain pühib nüüd üle maailma, pühkides minema kõik oma teel? Unista rohkem! See on väga kallis ja keeruline tehnoloogia. Tehniliselt keeruline ja aeganõudev. Sealhulgas puhtalt algoritmiliselt, iga kord, kui peate matemaatika ümber arvutama, väikseimate muudatustega... ja see on suurepärane idee - kuid ainult teatud juhtudel. Kogu mu elu ja karjäär on seotud sellega: huvitavad ideed väga konkreetsetes olukordades. Väga oluline on täpselt aru saada, milline on teie olukord.
Michael: Jah, peamine "elu, universumi ja kõige muu küsimus": kas see tehnoloogia või lähenemine sobib teie olukorda või mitte?
Tim: Seda küsimust saab juba tehnoloogiarühmaga arutada. Võib-olla tuua isegi mõni konsultant. Heitke pilk projektile ja saage aru – kas teeme nüüd midagi õigesti ja kasulikku, paremini kui varem? Võib-olla sobib, võib-olla mitte. Kuid mis kõige tähtsam, ärge tehke vaikimisi sellist otsust lihtsalt sellepärast, et keegi pahvatas: "Me vajame hädasti plokiahelat! Lugesin temast just lennukis ajakirjast!” Tõsiselt? See pole isegi naljakas.
Müütiline "devopsi insener"
Oleg: Nüüd rakendavad kõik devopsi. Keegi loeb Internetist devopsi kohta ja homme ilmub värbamissaidile veel üks vaba töökoht. "devopsi insener". Siinkohal tahaksin juhtida teie tähelepanu: kas teie arvates on sellel terminil "devopsi insener" õigus elule? Arvatakse, et devops on kultuur ja siin ei klapi midagi.
Tim: Nii nii. Las nad siis kohe seletavad seda terminit. Midagi, mis muudab selle ainulaadseks. Kuni nad ei tõesta, et sellise vaba töökoha taga on mingi ainulaadne oskuste kombinatsioon, ei osta ma seda! Ma mõtlen, et meil on ametinimetus "devopsi insener", huvitav tiitel, jah, mis edasi? Ametinimetused on üldiselt väga huvitav asi. Ütleme "arendaja" – mis see ikkagi on? Erinevad organisatsioonid tähendavad täiesti erinevaid asju. Mõnes ettevõttes kirjutavad kvaliteetsed programmeerijad teste, mis on mõttekamad kui teiste ettevõtete spetsiaalsete professionaalsete testijate kirjutatud testid. Mis siis, kas nad on nüüd programmeerijad või testijad?
Jah, meil on ametinimetused, aga kui piisavalt kaua küsimusi esitada, selgub lõpuks, et me kõik oleme probleemide lahendajad. Oleme lahenduse otsijad ja mõnel on mõned tehnilised oskused ja mõnel teistsugused. Kui elate keskkonnas, kuhu DevOps on tunginud, siis tegelete arenduse ja halduse integreerimisega ning sellel tegevusel on mõni üsna oluline eesmärk. Kui aga küsida, millega sa täpsemalt tegeled ja mille eest vastutad, siis selgub, et inimesed on seda kõike teinud juba ammusest ajast. "Ma vastutan arhitektuuri eest", "Ma vastutan andmebaaside eest" ja nii edasi, mis iganes, näete - kõik see oli enne "devopsi".
Kui keegi ütleb mulle oma ametinimetuse, siis ma eriti ei kuula. Parem on lasta tal öelda, mille eest ta tegelikult vastutab, see võimaldab meil probleemist palju paremini aru saada. Minu lemmiknäide on see, kui inimene väidab end olevat "projektijuht". Mida? See ei tähenda midagi, ma ikka ei tea, mida sa teed. Projektijuht võib olla arendaja, neljaliikmelise meeskonna juht, koodi kirjutav, tööd tegev, kellest on saanud meeskonna juht, keda inimesed ise tunnevad enda seas juhina. Ja ka projektijuht võib olla juht, kes juhib projektis kuutsada inimest, juhib teisi juhte, vastutab ajakavade koostamise ja eelarvete planeerimise eest, see on kõik. Need on kaks täiesti erinevat maailma! Kuid nende ametinimetus kõlab samamoodi.
Pöörame selle natuke teistmoodi. Milles sa oled väga hea, sul on palju kogemusi, kas sul on annet? Mille eest võtate vastutuse, sest arvate, et saate ülesandega hakkama? Ja siin hakkab keegi kohe salgama: ei, ei, ei, mul pole üldse soovi projektiressurssidega tegeleda, see pole minu asi, ma olen tehniline kutt ja saan aru kasutatavusest ja kasutajaliidestest, ma ei saa aru. tahan üldse inimeste armee juhtida, las ma lähen parem tööle.
Ja muide, ma olen selle lähenemisviisi suur pooldaja, mille puhul selline oskuste eraldamine töötab hästi. Kus tehnikud saavad oma karjääri kasvatada nii kaugele, kui tahavad. Siiski näen ikka veel organisatsioone, kus tehnikaspetsialistid kurdavad: ma pean projektijuhtimisega tegelema, sest see on selles ettevõttes ainus võimalus. Mõnikord viib see kohutavate tagajärgedeni. Parimad tehnikamehed ei ole üldse head juhid ja parimad juhid ei saa tehnoloogiaga hakkama. Olgem selles osas ausad.
Ma näen selle järele praegu suurt nõudlust. Kui olete tehnikahuviline, võib teie ettevõte teid aidata, kuid sellest hoolimata peate tõesti leidma oma karjääritee, sest tehnoloogia muutub pidevalt ja koos sellega peate end uuesti leiutama! Vaid kahekümne aastaga võivad tehnoloogiad muutuda vähemalt viis korda. Tehnika on imelik asi...
"Kõige asjatundjad"
Michael: Kuidas saavad inimesed sellise tehnoloogiamuutuse kiirusega toime tulla? Nende keerukus kasvab, nende arv kasvab, kasvab ka inimestevahelise suhtluse kogumaht ja selgub, et "kõige asjatundjaks" ei saa.
Tim: Õige! Kui töötad tehnikavaldkonnas, siis jah, tuleb kindlasti valida midagi konkreetset ja sellesse süveneda. Mõni tehnoloogia, mida teie organisatsioon peab kasulikuks (ja võib-olla on see tegelikult kasulik). Ja kui teid see enam ei huvita - ma poleks kunagi uskunud, et ma seda ütlen - noh, võib-olla peaksite kolima mõnda teise organisatsiooni, kus tehnoloogia on huvitavam või mugavam õppida.
Aga üldiselt on sul õigus jah. Tehnoloogiad arenevad korraga kõigis suundades; keegi ei saa öelda: "Ma olen kõigi olemasolevate tehnoloogiate eksperttehnoloog." Teisest küljest on käsna inimesi, kes sõna otseses mõttes neelavad tehnoloogilisi teadmisi ja on selle järele hullud. Olen näinud paari sellist inimest, nad sõna otseses mõttes hingavad ja elavad seda, nendega on kasulik ja huvitav rääkida. Nad ei uuri mitte ainult organisatsiooni sees toimuvat, vaid üldiselt räägivad sellest, nad on ka väga lahedad tehnoloogid, väga teadlikud ja sihikindlad. Nad lihtsalt püüavad püsida laineharjal, olenemata sellest, mis on nende põhitöö, sest nende kirg on Tehnoloogia liikumine, tehnoloogia propageerimine. Kui sellist inimest ootamatult kohtad, tuleks temaga lõunale minna ja lõuna ajal erinevaid lahedaid asju arutada. Ma arvan, et iga organisatsioon vajab vähemalt paari sellist inimest.
Riskid ja ebakindlus
Michael: Austatud insenerid, jah. Käsitleme riskijuhtimist, kuni meil aega on. Alustasime seda intervjuud aruteluga meditsiinitarkvara üle, kus vead võivad viia kohutavate tagajärgedeni. Seejärel rääkisime Lunari programmist, kus vea hind on miljoneid dollareid ja võib-olla mitu inimelu. Aga praegu näen tööstuses vastupidist liikumist, inimesed ei mõtle riskidele, ei püüa neid ennustada, isegi ei jälgi.
Oleg: Liigu kiiresti ja lõhu asju!
Michael: Jah, liigu kiiresti, lõhu asju, aina rohkem asju, kuni sured millegi kätte. Kuidas peaks keskmine arendaja teie vaatenurgast praegu õppimisriskide juhtimisele lähenema?
Tim: Tõmbame siinkohal piiri kahe asja vahele: riskid ja ebakindlus. Need on erinevad asjad. Ebakindlus tekib siis, kui teil pole mingil ajahetkel piisavalt andmeid, et jõuda lõpliku vastuseni. Näiteks kui keegi küsib projekti väga varajases staadiumis teilt "millal te töö lõpetate", kui olete üsna aus inimene, siis vastate: "Mul pole õrna aimugi." Sa lihtsalt ei tea ja see on okei. Te pole veel probleeme uurinud ega ole meeskonnaga kursis, te ei tea nende oskusi jne. See on ebakindlus.
Riskid tekivad siis, kui võimalikud probleemid on juba tuvastatud. Selline asi võib juhtuda, selle tõenäosus on suurem kui null, aga alla saja protsendi, kuskil vahepeal. Selle tõttu võib juhtuda kõike, alates viivitustest ja ebavajalikust tööst, kuid isegi kuni projektile saatusliku tulemuseni. Tulemuseks on see, et kui ütlete – poisid, paneme vihmavarjud kokku ja lahkume rannast, me ei lõpeta seda kunagi, kõik on läbi, punkt. Eeldasime, et see asi toimib, aga see ei tööta üldse, on aeg lõpetada. Sellised on olukorrad.
Sageli on probleeme kõige lihtsam lahendada siis, kui need on juba esile kerkinud, kui probleem esineb just praegu. Aga kui probleem on teie ees, ei tegele te riskijuhtimisega, vaid tegelete probleemide lahendamise, kriisijuhtimisega. Kui olete juhtivarendaja või juht, mõtlete kindlasti, mis võib juhtuda, mis tooks kaasa viivitusi, ajaraiskamist, tarbetuid kulusid või kogu projekti kokkuvarisemist? Mis paneb meid peatuma ja otsast alustama? Kui kõik need asjad toimivad, mida me nendega peale hakkame? Enamiku olukordade puhul kehtib lihtne vastus: ära põgene riskide eest, vaid tööta nende kallal. Vaadake, kuidas lahendada riskantne olukord, muuta see olematuks, muuta see probleemist millekski muuks. Selle asemel, et öelda: noh, me lahendame probleemid, kui need tekivad.
Ebakindlus ja risk peaksid olema kõiges, millega tegelete, esirinnas. Võite võtta projektiplaani, vaadata teatud kriitilisi riske enne tähtaega ja öelda: me peame sellega kohe tegelema, sest kui midagi sellest valesti läheb, pole muul tähtsust. Ärge muretsege laual oleva laudlina ilu pärast, kui pole selge, kas saate õhtusööki valmistada. Kõigepealt peate tuvastama kõik maitsva õhtusöögi valmistamise riskid, nendega tegelema ja alles seejärel mõtlema kõigile muudele asjadele, mis ei kujuta endast tegelikku ohtu.
Jällegi, mis teeb teie projekti ainulaadseks? Vaatame, mis võib meie projekti rööbastelt minema ajada. Mida saame teha, et selle juhtumise tõenäosust minimeerida? Tavaliselt ei saa te neid lihtsalt 100% neutraliseerida ja puhta südametunnistusega kuulutada: "See on kõik, see pole enam probleem, risk on lahendatud!" Minu jaoks on see täiskasvanu käitumise tunnus. See on lapse ja täiskasvanu erinevus - lapsed arvavad, et nad on surematud, et midagi ei saa valesti minna, kõik saab korda! Samal ajal vaatavad täiskasvanud, kuidas kolmeaastased lapsed mänguväljakul hüppavad, jälgivad silmadega liigutusi ja ütlevad endale: “oi-oi, oi-oi”. Seisan läheduses ja valmistun püüdma, kui laps kukub.
Teisest küljest on põhjus, miks see äri mulle nii väga meeldib, sest see on riskantne. Me teeme asju ja need asjad on riskantsed. Nad nõuavad täiskasvanute lähenemist. Entusiasm üksi ei lahenda teie probleeme!
Täiskasvanute insenerlik mõtlemine
Michael: Eeskuju lastega on hea. Kui ma olen tavaline insener, siis mul on hea meel olla laps. Kuidas aga liikuda täiskasvanulikuma mõtlemise poole?
Tim: Üks ideedest, mis töötab võrdselt hästi nii algaja kui ka väljakujunenud arendaja puhul, on konteksti mõiste. Mida me teeme, mida me saavutame. Mis on selle projekti juures tegelikult oluline? Pole tähtis, kes te selle projekti juures olete, kas olete praktikant või peaarhitekt, kõik vajavad konteksti. Peame panema kõik mõtlema suuremal skaalal kui tema enda töö. "Ma teen oma teose ja seni, kuni mu tükk töötab, olen õnnelik." Ei ja veelkord ei. Alati tasub (olemata ebaviisakas!) inimestele meelde tuletada konteksti, milles nad töötavad. Mida me kõik koos saavutada püüame. Ideed, et saaksite olla laps seni, kuni teie projektiga on kõik korras – palun ärge tehke seda. Kui me üldse finišijoone ületame, siis ületame selle ainult koos. Sa ei ole üksi, me oleme kõik koos. Kui kõik projektis osalejad, nii vanad kui ka noored, hakkaksid rääkima sellest, mis on projekti jaoks täpselt oluline, miks ettevõte investeerib raha sellesse, mida me kõik püüame saavutada... tunneks enamik neist end palju paremini, sest näeb, kuidas nende töö korreleerub kõigi teiste töödega. Ühest küljest saan aru tükist, mille eest ma isiklikult vastutan. Kuid töö lõpetamiseks vajame ka kõiki teisi inimesi. Ja kui te tõesti arvate, et olete lõpetanud, on meil projektiga alati tööd!
Oleg: Suhteliselt võib öelda, et kui töötad Kanbani järgi, võid mõne testimise kitsaskohta tabades lõpetada sealse tegevuse (näiteks programmeerimise) ja minna testijaid aitama.
Tim: Täpselt nii. Ma arvan, et parimad tehnikamehed, kui neid tähelepanelikult vaadata, on nad omamoodi juhid. Kuidas ma saan seda sõnastada...
Oleg: Teie elu on teie projekt, mida juhite.
Tim: Täpselt nii! Ma mõtlen, et võtate vastutuse, saate probleemist aru ja puutute inimestega kokku, kui näete, et teie otsused võivad mõjutada nende tööd, selliseid asju. See ei seisne selles, et istud lihtsalt oma töölaua taga, teed oma tööd ja ei saa isegi aru, mis sinu ümber toimub. Ei ei ei. Muide, üks parimaid asju Agile juures on see, et nad pakkusid välja lühikesed spurdid, sest nii on kõikide osalejate asjade seis selgelt jälgitav, nad näevad kõike koos. Me räägime üksteisest iga päev.
Kuidas riskijuhtimisega tegeleda
Oleg: Kas selles valdkonnas on olemas ametlik teadmiste struktuur? Näiteks olen Java arendaja ja tahan mõista riskijuhtimist, ilma et peaksin hariduselt päris projektijuhiks saama. Tõenäoliselt loen enne McConnelli "Kui palju maksab tarkvaraprojekt" ja mis siis? Millised on esimesed sammud?
Tim: Esimene on alustada inimestega suhtlemist projektis. See parandab koheselt kolleegidega suhtlemise kultuuri. Peame alustama selle peitmise asemel, et vaikimisi kõik välja avada. Ütle: need on asjad, mis mind häirivad, need hoiavad mind öösel üleval, täna ärkasin öösel ja ütlesin: issand, ma pean sellele mõtlema! Kas teised näevad sama asja? Kas peaksime rühmana nendele võimalikele probleemidele reageerima? Peate suutma toetada nendel teemadel toimuvat arutelu. Eelnevalt ettevalmistatud valemit, mille järgi me töötame, ei ole. Asi pole hamburgerite valmistamises, vaid inimestes. “Tegi juustuburgerit, müü juustuburgerit” pole üldse meie asi ja sellepärast ma armastan seda tööd väga. Mulle meeldib, kui kõik, mida juhid varem tegid, muutub nüüd meeskonna omandiks.
Oleg: Olete raamatutes ja intervjuudes rääkinud sellest, kuidas inimesed hoolivad rohkem õnnest kui numbritest graafikul. Teisest küljest, kui ütlete meeskonnale: me liigume devopsi poole ja nüüd peab programmeerija pidevalt suhtlema, võib see olla tema mugavustsoonist kaugel. Ja praegu võib ta, ütleme, olla sügavalt õnnetu. Mida selles olukorras teha?
Tim: Ma ei tea täpselt, mida teha. Kui arendaja on liiga isoleeritud, ei saa ta aru, miks seda tööd üldse tehakse, vaid vaatavad lihtsalt oma osa tööst ja peavad sattuma sellesse, mida ma nimetan "kontekstiks". Ta peab välja mõtlema, kuidas kõik on omavahel seotud. Ja loomulikult ei pea ma silmas ametlikke esitlusi või midagi sellist. Ma räägin sellest, et kolleegidega tuleb suhelda tööst tervikuna, mitte ainult selle osa osas, mille eest vastutad. Siin saate hakata arutama ideid, ühiseid kokkuleppeid, et teie töö hästi sobiks, ja kuidas ühise probleemiga ühiselt tegeleda.
Et aidata neil kohaneda, tahavad nad sageli tehnikainimesi koolitusele saata ja nad arutavad koolitust. Üks mu sõber armastab öelda, et koolitus on koertele. Inimestele on koolitus. Üks parimaid asju arendajana õppimise juures on oma eakaaslastega suhtlemine. Kui keegi on milleski väga hea, peaksite jälgima tema tööd või rääkima temaga tema tööst või muust. Mõni tavapärane Kent Beck rääkis pidevalt ekstreemsest programmeerimisest. See on naljakas, sest XP on nii lihtne idee, kuid see põhjustab palju probleeme. Mõne jaoks on XP tegemine nagu sunnitud end sõprade ees alasti koorima. Nad näevad, mida ma teen! Nad on minu kolleegid, nad mitte ainult ei näe, vaid ka mõistavad! Kohutav! Mõned inimesed hakkavad tõsiselt närvi minema. Kuid kui mõistate, et see on parim viis õppimiseks, muutub kõik. Teete inimestega tihedat koostööd ja mõned inimesed mõistavad seda teemat palju paremini kui teie.
Michael: See kõik aga sunnib mugavustsoonist välja astuma. Insenerina pead sa oma mugavustsoonist välja tulema ja suhtlema. Probleemide lahendajana pead end pidevalt nõrga positsiooni panema ja mõtlema, mis võib valesti minna. Seda tüüpi tööd on oma olemuselt kavandatud häirima. Paned end teadlikult stressirohketesse olukordadesse. Tavaliselt inimesed põgenevad nende eest, inimestele meeldib olla õnnelikud lapsed.
Tim: Mis teha saab, võib välja tulla ja avalikult öelda: “Kõik on korras, saan hakkama! Ma pole ainuke, kes end ebamugavalt tunneb. Arutame kõik koos, meeskonnana erinevaid ebamugavaid asju!” Need on meie ühised probleemid, me peame nendega tegelema, tead? Ma arvan, et idiosünkraatilised geniaalsed arendajad on nagu mammutid, nad kadusid. Ja nende tähtsus on väga piiratud. Kui sa ei oska suhelda, siis ei saa ka hästi osaleda. Seetõttu lihtsalt rääkige. Ole aus ja avatud. Mul on väga kahju, et see kellegi jaoks ebameeldiv on. Kujutate ette, aastaid tagasi oli uuring, mille kohaselt USAs ei ole peamine hirm surm, aga arvake ära? Hirm avaliku esinemise ees! See tähendab, et kuskil on inimesi, kes pigem surevad kui ütlevad valjult komplimendi. Ja ma arvan, et olenevalt sellest, mida teete, piisab, kui teil on mõned põhioskused. Rääkimisoskus, kirjutamisoskus – aga ainult nii palju, kui sinu töös reaalselt vaja läheb. Kui töötate analüütikuna, aga ei oska lugeda, kirjutada ega rääkida, siis kahjuks pole teil minu projektides midagi peale hakata!
Suhtlemise hind
Oleg: Kas selliste lahkuvate töötajate palkamine pole erinevatel põhjustel kallim? Nad ju vestlevad töö asemel pidevalt!
Tim: Ma pidasin silmas meeskonna tuuma ja mitte ainult kõiki. Kui teil on keegi, kes on väga lahe andmebaaside häälestamises, armastab andmebaaside häälestamist ja kavatseb teie andmebaaside häälestamist elu lõpuni jätkata ja kõik, siis lahe, jätkake samamoodi. Aga ma räägin inimestest, kes tahavad projekti enda sees elada. Meeskonna tuumik, mille eesmärk on projekti arendamine. Need inimesed peavad tõesti pidevalt üksteisega suhtlema. Ja eriti projekti alguses, kui arutad riske, võimalusi globaalsete eesmärkide saavutamiseks jms.
Michael: See kehtib kõigi projektiga seotud isikute kohta, olenemata erialast, oskustest või tööviisidest. Olete kõik huvitatud projekti õnnestumisest.
Tim: Jah, tunned, et oled projekti piisavalt süvenenud, et sinu ülesanne on aidata projektil teoks teha. Olenemata sellest, kas olete programmeerija, analüütik, liidese kujundaja või keegi. See on põhjus, miks ma igal hommikul tööle tulen ja seda me teeme. Vastutame kõigi nende inimeste eest, olenemata nende oskustest. See on grupp inimesi, kes vestlevad täiskasvanutega.
Oleg: Tegelikult, rääkides jutukatest töötajatest, püüdsin simuleerida inimeste, eriti juhtide vastuväiteid, kellel palutakse minna üle devopsile, sellele täiesti uuele maailmanägemusele. Ja teie kui konsultandid peaksite nende vastuväidetega palju paremini kursis olema kui mina kui arendaja! Jagage, mis teeb juhtidele kõige rohkem muret?
Tim: Juhid? Hm. Enamasti on juhid probleemide surve all, seisavad silmitsi vajadusega midagi kiiresti vabastada ja tarnida jms. Nad vaatavad, kuidas me pidevalt millegi üle arutame ja vaidleme, ja näevad seda nii: vestlused, vestlused, vestlused... Mis vestlused veel? Tagasi tööle! Sest rääkimine ei tundu neile tööna. Te ei kirjuta koodi, ei testi tarkvara, ei paista midagi tegevat – miks mitte saata teid midagi tegema? Tarne on ju juba kuu aja pärast!
Michael: Mine kirjuta mingi kood!
Tim: Mulle tundub, et nad ei ole mures töö, vaid edusammude vähese nähtavuse pärast. Et tunduks, et oleme edule lähemal, peavad nad nägema, kuidas me klaviatuuril nuppe vajutame. Terve päev hommikust õhtuni. See on probleem number üks.
Oleg: Misha, sa mõtled millegi peale.
Michael: Vabandust, ma läksin mõttesse ja tabasin tagasivaadet. See kõik meenutas mulle eile toimunud huvitavat rallit... Eile oli liiga palju rallisid... Ja see kõik kõlab väga tuttavalt!
Elu ilma palgata
Tim: Muide, suhtlemiseks pole üldse vaja “rallisid” korraldada. Pean silmas seda, et kõige kasulikumad arutelud arendajate vahel toimuvad siis, kui nad lihtsalt omavahel räägivad. Lähed hommikul tassi kohviga sisse ja sinna on kogunenud viis inimest ja arutavad raevukalt tehnilist asja. Minu jaoks, kui ma olen selle projekti juht, on parem lihtsalt naeratada ja minna kuhugi oma asjadega tegelema, lasta neil seda arutada. Nad on juba nii palju kaasatud kui võimalik. See on hea märk.
Oleg: Muide, teie raamatus on hunnik märkmeid selle kohta, mis on hea ja mis on halb. Kas kasutate mõnda neist ka ise? Suhteliselt öeldes on teil nüüd ettevõte, mis on üles ehitatud väga ebatavaliselt...
Tim: Ebatavaline, kuid see seade sobib meile suurepäraselt. Oleme teineteist juba ammu tundnud. Me usaldame üksteist, usaldasime üksteist väga enne, kui partneriks saime. Ja näiteks palka pole meil üldse. Me lihtsalt töötame ja näiteks kui ma teenisin oma klientidelt raha, siis kogu raha läks mulle. Peale seda maksame organisatsioonile liikmemaksu ja sellest piisab ettevõtte enda ülalpidamiseks. Lisaks oleme kõik spetsialiseerunud erinevatele asjadele. Näiteks töötan raamatupidajatega, täidan maksudeklaratsioone, tegelen ettevõttega igasugu administratiivsete asjadega ja keegi ei maksa mulle selle eest. James ja Tom töötavad meie veebisaidil ja ka neile ei maksa keegi. Niikaua kui maksate oma makse, ei mõtle keegi teile öelda, mida peate tegema. Näiteks töötab Tom nüüd palju vähem kui kunagi varem. Nüüd on tal teised huvid; ta teeb mõnda asja mitte gildi heaks. Kuid seni, kuni ta oma makse maksab, ei tule keegi tema juurde ega ütle: "Hei, Tom, mine tööle!" Kolleegidega on väga lihtne läbi saada, kui teie vahel pole raha. Ja nüüd on meie suhe erinevate erialade suhtes üks fundamentaalseid ideid. See töötab ja töötab väga hästi.
Parim nõuanne
Michael: Tulles tagasi "parimate nõuannete" juurde, kas on midagi, mida te oma klientidele ikka ja jälle räägite? Mõte on umbes 80/20 ja mõnda nõuannet korratakse ilmselt sagedamini.
Tim: Kunagi mõtlesin, et kui kirjutaksid sellise raamatu nagu Valss karudega, muudaks see ajaloo kulgu ja inimesed jääksid seisma, aga... No vaata, firmad teevad tihti näo, et nendega on kõik korras. Niipea, kui midagi halba juhtub, on see nende jaoks šokk ja üllatus. "Vaadake, me testisime süsteemi ja see ei läbi ühtegi süsteemitesti ja see on veel kolm kuud plaanivälist tööd, kuidas see juhtuda sai? Kes teadis? Mis võib valesti minna? Tõsiselt, kas sa usud seda?
Püüan selgitada, et praeguse olukorra pärast ei tasu liiga vihaseks saada. Peame selle välja rääkima, mõistma, mis võis valesti minna ja kuidas selliseid asju tulevikus ära hoida. Kui probleem ilmneb, kuidas me sellega võitleme, kuidas me seda ohjeldame?
Minu jaoks tundub see kõik hirmutav. Inimesed tegelevad keeruliste, piinavate probleemidega ja jätkavad teesklemist, et kui nad lihtsalt pöialt hoiavad ja loodavad parimat, juhtub „parim”. Ei, see ei tööta nii.
Harjuta riskijuhtimist!
Michael: Kui paljud organisatsioonid tegelevad teie hinnangul riskijuhtimisega?
Tim: Mind ajab marru see, et inimesed panevad riskid lihtsalt kirja, vaatavad saadud nimekirja ja lähevad tööle. Tegelikult on nende jaoks riskide tuvastamine riskijuhtimine. Kuid minu jaoks kõlab see põhjusena küsida: okei, seal on nimekiri, mida te täpselt muudate? Neid riske arvesse võttes peate muutma oma tavapärast toimingute järjestust. Kui töös on mõni kõige raskem osa, peate sellega tegelema ja alles siis liikuma millegi lihtsama juurde. Esimestel sprintidel asuge lahendama keerulisi probleeme. See näeb juba välja nagu riskijuhtimine. Kuid tavaliselt ei oska inimesed pärast riskide nimekirja koostamist öelda, mida nad muutsid.
Michael: Ja veel, kui paljud neist ettevõtetest on riskijuhtimisega seotud, viis protsenti?
Tim: Kahjuks ei taha ma seda öelda, kuid see on väga ebaoluline osa. Aga rohkem kui viis, sest on tõesti suuri projekte ja neid lihtsalt ei saa eksisteerida, kui nad vähemalt midagi ei tee. Ütleme nii, et ma olen väga üllatunud, kui see on vähemalt 25%. Väikeprojektid vastavad sellistele küsimustele tavaliselt nii: kui probleem puudutab meid, siis me lahendame selle. Siis satuvad nad edukalt hätta ja tegelevad probleemide juhtimise ja kriisijuhtimisega. Kui proovite probleemi lahendada ja probleem ei lahene, siis tere tulemast kriisireguleerimisse.
Jah, ma kuulen sageli: "Me lahendame probleemid, kui need tekivad." Kindlasti teeme? Kas me tõesti otsustame?
Oleg: Saate seda teha naiivselt ja lihtsalt kirjutada olulised invariandid projekti hartasse ja kui invariandid purunevad, siis lihtsalt taaskäivitage projekt. See osutub väga piembucky.
Michael: Jah, minuga juhtus nii, et kui riskid vallandusid, defineeriti projekt lihtsalt ümber. Kena, bingo, probleem lahendatud, ärge enam muretsege!
Tim: Vajutame lähtestamisnuppu! Ei, see ei tööta nii.
2019. aasta DevOopsi peaettekanne
Michael: Jõuame selle intervjuu viimase küsimuseni. Tulete järgmisele DevOopsile peaettekandega. Kas saaksite jutustatava saladuse eesriide kergitada?
Tim: Just praegu kirjutavad kuus neist raamatut töökultuurist, organisatsioonide väljaütlemata reeglitest. Kultuuri määravad organisatsiooni põhiväärtused. Tavaliselt inimesed seda ei märka, kuid olles töötanud aastaid konsultatsiooni alal, oleme harjunud seda märkama. Sisened seltskonda ja sõna otseses mõttes hakkad mõne minuti pärast toimuvat tundma. Me nimetame seda "maitseks". Mõnikord on see lõhn tõesti hea ja mõnikord on see, noh, oih. Erinevate organisatsioonide puhul on asjad väga erinevad.
Michael: Ka mina olen aastaid konsultatsiooni alal töötanud ja saan hästi aru, millest räägid.
Tim: Tegelikult on üks asi, millest peaettekandes rääkida, see, et kõike ei määra ettevõte. Teil ja teie meeskonnal kui kogukonnal on oma meeskonnakultuur. See võib olla kogu ettevõte või eraldi osakond, eraldi meeskond. Aga enne kui ütlesite, siin on see, mida me usume, siin on see, mis on oluline... Kultuuri ei saa muuta enne, kui pole mõistetud konkreetsete tegude taga olevaid väärtusi ja uskumusi. Käitumist on lihtne jälgida, kuid uskumuste otsimine on keeruline. DevOps on lihtsalt suurepärane näide sellest, kuidas asjad muutuvad järjest keerulisemaks. Interaktsioonid muutuvad ainult keerulisemaks, need ei muutu sugugi puhtamaks ega selgemaks, nii et peaksite mõtlema, millesse te usute ja millest kõik teie ümber vaikivad.
Kui soovid saavutada kiireid tulemusi, siis siin on sulle hea teema: kas oled näinud ettevõtteid, kus keegi ei ütle “ma ei tea”? On kohti, kus piinate inimest sõna otseses mõttes, kuni ta tunnistab, et ei tea midagi. Kõik teavad kõike, kõik on uskumatud erudiidid. Lähete ükskõik millisele inimesele ja ta peab küsimusele kohe vastama. Selle asemel, et öelda "ma ei tea". Hurraa, nad palkasid hulga erudite! Ja mõnes kultuuris on üldiselt väga ohtlik öelda "ma ei tea", seda võib tajuda nõrkuse märgina. On ka organisatsioone, kus, vastupidi, võivad kõik öelda "ma ei tea". Seal on see täiesti seaduslik ja kui keegi hakkab küsimuse peale jamama, siis on täiesti normaalne vastata: "Sa ei tea, millest sa räägid, eks?" ja muuda see kõik naljaks.
Ideaalis tahaksid tööd, kus saaksid pidevalt õnnelik olla. See ei saa olema lihtne, iga päev pole päikeseline ja mõnus, vahel on vaja kõvasti tööd teha, aga kui hakkad kokkuvõtteid tegema, siis selgub: vau, see on tõesti imeline koht, tunnen end siin hästi töötades, nii emotsionaalselt kui intellektuaalselt. Ja on ettevõtteid, kus sa lähed konsultandiks ja saad kohe aru, et sa ei suuda seda kolm kuud vastu pidada ja jooksed õudusega minema. Sellest tahan raportis rääkida.
Peaettekandega saabub Tim Lister konverentsile DevOops 2019, mis toimub 29.-30 Peterburis. Pileteid saab osta . Ootame teid DevOopsi!
Allikas: www.habr.com