Timas Listeris – knygų bendraautoris
- „Žmogiškasis faktorius. Sėkmingi projektai ir komandos“ (originali knyga vadinasi „Peopleware“)
- „Valsas su lokiais: rizikos valdymas programinės įrangos projektuose“
- „Adrenalino pamišęs ir šablonų suzombintas. Projekto komandų elgesio modeliai“
Visos šios knygos yra savo srities klasikos ir parašytos kartu su kolegomis . Rusijoje jo kolegos yra žinomiausi - и , kuris taip pat parašė daug žinomų kūrinių.
Timas turi 40 metų programinės įrangos kūrimo patirtį 1975 m. (nė vienas iš tų, kurie parašė šį habrapostą, negimė šiais metais), Timas jau buvo „Yourdon Inc.“ vykdomasis viceprezidentas. Dabar jis praleidžia laiką konsultuodamas, mokydamas ir rašydamas, retkarčiais apsilankydamas konferencijos visame pasaulyje.
Specialiai Habrui davėme interviu su Timu Listeriu. Jis atidarys „DevOops 2019“ konferenciją, ir mes turime daug klausimų apie knygas ir dar daugiau. Interviu veda Michailas Družininas ir Olegas Čiruchinas iš konferencijos programos komiteto.
Michaelas: Ar galite pasakyti keletą žodžių apie tai, ką dabar darote?
Timas: Aš esu Atlanto sistemų gildijos vadovas. Gildijoje esame šeši, save vadiname vadovais. Trys JAV ir trys Europoje – štai kodėl gildija vadinama Atlantu. Mes tiek metų kartu, kad jų tiesiog nesuskaičiuosi. Mes visi turime savo specialybes. Su klientais dirbu pastarąjį dešimtmetį ar daugiau. Mano projektai apima ne tik valdymą, bet ir reikalavimų nustatymą, projektų planavimą, vertinimą. Atrodo, kad prastai prasidėję projektai dažniausiai prastai baigiasi. Todėl verta pasirūpinti, kad visos veiklos būtų tikrai gerai apgalvotos ir suderintos, kad kūrėjų idėjos būtų derinamos. Verta pagalvoti, ką ir kodėl darai. Kokias strategijas naudoti, kad projektas būtų užbaigtas.
Daugelį metų konsultuoju klientus įvairiais būdais. Įdomus pavyzdys – įmonė, gaminanti robotus kelių ir klubų chirurgijai. Chirurgas neveikia visiškai savarankiškai, o naudojasi robotu. Saugumas čia, atvirai kalbant, yra svarbus. Bet kai bandai aptarti reikalavimus su žmonėmis, kurie yra orientuoti į problemų sprendimą... Nuskambės keistai, bet JAV yra (Federalinė vaistų administracija), kuri licencijuoja tokius produktus kaip šie robotai. Prieš ką nors parduodant ir naudojant gyviems žmonėms, reikia gauti licenciją. Viena iš sąlygų – parodyti savo reikalavimus, kokie yra testai, kaip juos išbandėte, kokie testo rezultatai. Jei pakeisite reikalavimus, turėsite vėl ir vėl pereiti visą šį didžiulį testavimo procesą. Mūsų klientams pavyko į savo reikalavimus įtraukti aplikacijų vizualinį dizainą. Jie turėjo ekrano kopijas tiesiogiai kaip reikalavimų dalį. Turime juos ištraukti ir paaiškinti, kad dažniausiai visos šios programos nieko nežino apie kelius ir klubus, visus šiuos dalykus su fotoaparatu ir pan. Reikalavimų dokumentus turime perrašyti taip, kad jie niekada nesikeistų, nebent pasikeistų kai kurios tikrai svarbios pagrindinės sąlygos. Jei vizualinis dizainas neatitinka reikalavimų, produkto atnaujinimas vyks daug greičiau. Mūsų darbas yra surasti tuos elementus, kuriuose yra kelio, klubų, nugaros operacijos, ištraukti juos į atskirus dokumentus ir pasakyti, kad tai bus esminiai reikalavimai. Sudarykime izoliuotą kelių operacijų reikalavimų grupę. Tai leis mums sukurti stabilesnį reikalavimų rinkinį. Kalbėsime apie visą produktų liniją, o ne apie konkrečius robotus.
Buvo atlikta daug darbų, tačiau jie vis tiek pateko į vietas, kur anksčiau be prasmės ar poreikio praleisdavo savaites ir mėnesius kartotinius bandymus, nes popieriuje aprašyti jų reikalavimai nesutapo su realiais reikalavimais, kuriems buvo kuriamos sistemos. FDA jiems kaskart sakydavo: jūsų reikalavimai pasikeitė, dabar reikia viską patikrinti nuo nulio. Visiškai pakartotinai patikrinus visą produktą, įmonė buvo nužudyta.
Taigi, būna tokių nuostabių užduočių, kai atsiduri pačioje kažko įdomaus pradžioje, o jau pirmieji veiksmai nustato tolimesnes žaidimo taisykles. Jei įsitikinsite, kad ši ankstyva veikla pradės gerai veikti tiek vadybiniu, tiek techniniu požiūriu, yra tikimybė, kad baigsite puikų projektą. Bet jei ši dalis nukrypo nuo bėgių ir kažkur nukrypo, jei nerandate esminių susitarimų... ne, tai nereiškia, kad jūsų projektas būtinai žlugs. Bet nebegalėsite sakyti: „Mums pavyko puikiai, viską padarėme tikrai efektyviai“. Tai yra dalykai, kuriuos darau bendraudama su klientais.
Michaelas: Tai yra, pradedate projektus, darote kažkokį startą ir patikrinate, ar bėgiai eina tinkama kryptimi?
Timas: Taip pat turime idėjų, kaip sujungti visas dėlionės dalis: kokių įgūdžių mums reikia, kada tiksliai jų reikia, kaip atrodo komandos branduolys ir kiti tokie esminiai dalykai. Ar mums reikia visą darbo dieną dirbančių darbuotojų ar galime samdyti ką nors ne visą darbo dieną? Planavimas, valdymas. Tokie klausimai kaip: kas svarbiausia šiam projektui? Kaip tai pasiekti? Ką mes žinome apie šį produktą ar projektą, kokia rizika ir kur slypi nežinomybė, kaip su visa tai susitvarkysime? Žinoma, šią akimirką kažkas pradeda šaukti „O kaip su judriu?“ Gerai, jūs visi lankstūs, bet kas? Kaip tiksliai atrodo projektas, kaip ketinate jį įgyvendinti taip, kad jis atitiktų projektą? Negalite tiesiog pasakyti, kad „mūsų požiūris apima bet ką, mes esame „Scrum“ komanda! Tai nesąmonė ir nesąmonė. Kur ketinate eiti toliau, kodėl tai turėtų veikti, kur yra prasmė? Aš mokau savo klientus galvoti apie visus šiuos klausimus.
19 metų judrus
Michaelas: „Agile“ žmonės dažnai stengiasi nieko neapibrėžti iš anksto, o priimti sprendimus kuo vėliau, sakydami: mes per dideli, negalvosiu apie bendrą architektūrą. Negalvosiu apie daugybę kitų dalykų, o dabar klientui pristatysiu tai, kas veikia.
Timas: Manau, kad judrios metodikos, pradedant nuo 2001 m., atvėrė pramonės akis. Bet, kita vertus, nieko nėra tobulo. Aš esu už pasikartojantį vystymąsi. Daugumoje projektų iteracija yra labai prasminga. Tačiau reikia pagalvoti: kiek laiko jis tarnaus, kai produktas bus išleistas ir naudojamas? Ar tai produktas, kuris veiks šešis mėnesius, kol bus pakeistas kažkuo kitu? O gal tai produktas, kuris veiks daug, daug metų? Žinoma, vardų neįvardinsiu, bet... Niujorke ir jo finansinėje bendruomenėje fundamentaliausios sistemos yra labai senos. Tai yra nuostabu. Žiūri į juos ir galvoji, jei tik galėtum grįžti laiku atgal, į 1994-uosius, ir kūrėjams pasakyti: „Atėjau iš ateities, nuo 2019 m. Tiesiog kurkite šią sistemą tiek, kiek jums reikia. Padarykite jį plečiamą, pagalvokite apie architektūrą. Tada jis bus tobulinamas daugiau nei dvidešimt penkerius metus. Jei atidėliosite vystymąsi šiek tiek ilgiau, didžiojoje dalykų schemoje niekas nepastebės! Kai vertinate dalykus ilgalaikėje perspektyvoje, turite apsvarstyti, kiek tai iš viso kainuos. Kartais gerai suprojektuota architektūra tikrai to verta, o kartais – ne. Turime apsidairyti ir savęs paklausti: ar esame tinkamoje situacijoje tokiam sprendimui?
Taigi tokia idėja kaip „Mes už judrumą, klientas pats pasakys, ką nori gauti“ – tai labai naivu. Klientai net nežino, ko nori, o juo labiau – nežino, ką galėtų gauti. Kai kurie žmonės kaip argumentus ims minėti istorinius pavyzdžius, aš tai jau mačiau. Tačiau techniškai pažengę žmonės taip paprastai nesako. Jie sako: „Tai 2019 m., tai yra mūsų galimybės, ir mes galime visiškai pakeisti požiūrį į šiuos dalykus! Užuot mėgdžiojus esamus sprendimus, darant juos šiek tiek gražesnius ir labiau šukuotus, kartais reikia išeiti ir pasakyti: „Išrasime visiškai iš naujo, ką čia bandome padaryti!
Ir nemanau, kad dauguma klientų gali taip galvoti apie problemą. Jie mato tik tai, ką jau turi, ir viskas. Po to jie ateina su prašymais, pvz., „Padarykime tai šiek tiek paprasčiau“ arba ką jie paprastai sako. Bet mes nesame padavėjos ar padavėjos, todėl galime priimti užsakymą, kad ir kaip kvailai pasirodytų, o paskui iškepti virtuvėje. Mes esame jų vadovai. Turime jiems atmerkti akis ir pasakyti: ei, čia turime naujų galimybių! Ar suprantate, kad mes tikrai galime pakeisti tai, kaip ši jūsų verslo dalis vykdoma? Viena iš „Agile“ problemų yra ta, kad ji pašalina suvokimą, kas yra galimybė, kas yra problema, ką mes netgi turime daryti, kokios turimos technologijos geriausiai tinka šiai konkrečiai situacijai.
Galbūt aš esu pernelyg skeptiškas: judrioje bendruomenėje vyksta daug nuostabių dalykų. Bet turiu problemų dėl to, kad užuot apibrėžę projektą, žmonės pradeda numoti rankomis. Aš čia paklausčiau – ką mes darome, kaip tai darysime? Ir kažkaip stebuklingai visada išeina, kad klientas turėtų žinoti geriau nei bet kas. Tačiau klientas geriausiai žino tik tada, kai renkasi iš jau kažkieno pastatytų daiktų. Jei noriu nusipirkti automobilį ir žinau savo šeimos biudžeto dydį, greitai parinksiu automobilį, atitinkantį mano gyvenimo būdą. Čia aš viską žinau geriau nei bet kas! Tačiau atkreipkite dėmesį, kad kažkas jau pagamino automobilius. Neįsivaizduoju, kaip išrasti naują automobilį, nesu ekspertas. Kai kuriame nestandartinius ar specialius gaminius, reikia atsižvelgti į kliento balsą, tačiau tai jau ne vienintelis balsas.
Olegas: Jūs paminėjote „Agile Manifestą“. Ar turime jį kažkaip atnaujinti ar peržiūrėti atsižvelgiant į šiuolaikinį problemos supratimą?
Timas: Aš jo neliesčiau. Manau, kad tai puikus istorinis dokumentas. Aš turiu galvoje, jis yra toks, koks yra. Jam sukanka 19 metų, jis senas, bet savo laiku padarė revoliuciją. Gerai jis padarė tai, kad jis sukėlė reakciją ir žmonės pradėjo apie jį šnibždėti. Jūs greičiausiai dar nedirbote pramonėje 2001 m., bet tada visi dirbo pagal procesus. Programinės įrangos inžinerijos institutas, penki programinės įrangos išsamumo modelio (CMMI) lygiai. Nežinau, ar tokios gilios senovės legendos jums ką nors byloja, bet tada tai buvo proveržis. Iš pradžių žmonės tikėjo, kad jei procesai bus nustatyti teisingai, problemos išnyks savaime. Ir tada pasirodo Manifestas ir sako: „Ne, ne, ne – mes remsimės žmonėmis, o ne procesais“. Esame programinės įrangos kūrimo meistrai. Mes suprantame, kad idealus procesas yra miražas, jis neįvyksta. Projektuose per daug savitumo, idėja apie vieną tobulą procesą visiems projektams neturi prasmės. Problemos yra pernelyg sudėtingos, kad būtų galima teigti, kad yra tik vienas sprendimas (labas, nirvana).
Nesiimu žvelgti į ateitį, bet pasakysiu, kad dabar žmonės pradėjo daugiau galvoti apie projektus. Manau, kad Agile Manifestas labai gerai iššoka ir sako: „Ei! Jūs esate laive ir pats vairuojate šį laivą. Teks apsispręsti – universalaus recepto visoms situacijoms nepasiūlysime. Jūs esate laivo įgula ir, jei esate pakankamai geras, galite rasti kelią į tikslą. Buvo kiti laivai prieš jus ir bus kiti laivai po jūsų, bet vis tiek tam tikra prasme jūsų kelionė yra unikali. Kažkas panašaus! Tai mąstymo būdas. Man nėra nieko naujo po saule, žmonės plaukiojo anksčiau ir plauks dar kartą, bet jums tai yra pagrindinė kelionė, ir aš nesakysiu, kas tiksliai nutiks. Privalai turėti koordinuoto darbo komandoje įgūdžių, o jeigu juos tikrai turėsi, viskas susitvarkys ir pateksi ten, kur norėjai.
Peopleware: po 30 metų
Olegas: Ar „Peopleware“ buvo revoliucija ir „Manifestas“?
Timas: Peopleware... Mes su Tomu parašėme šią knygą, bet nemanėme, kad taip nutiks. Kažkaip tai atsiliepė daugelio žmonių idėjoms. Tai buvo pirmoji knyga, kurioje buvo pasakyta: programinės įrangos kūrimas yra labai daug žmonių reikalaujanti veikla. Nepaisant mūsų techninio pobūdžio, mes taip pat esame žmonių bendruomenė, kurianti kažką didelio, net didžiulio, labai sudėtingo. Niekas negali sukurti tokių dalykų vienas, tiesa? Taigi „komandos“ idėja tapo labai svarbi. Ir ne tik vadybos požiūriu, bet ir techniniams žmonėms, kurie susirinko išspręsti tikrai sudėtingas gilias problemas su krūva nežinomųjų. Man asmeniškai tai buvo didžiulis intelekto išbandymas per visą mano karjerą. Ir čia reikia mokėti pasakyti: taip, ši problema yra daugiau nei aš pati galiu susitvarkyti, bet kartu galime rasti elegantišką sprendimą, kuriuo galime didžiuotis. Ir manau, kad būtent ši idėja sulaukė didžiausio atgarsio. Idėja, kad dalį laiko dirbame patys, dalį laiko kaip grupės dalis ir dažnai sprendimą priima grupė. Grupinis problemų sprendimas greitai tapo svarbia sudėtingų projektų savybe.
Nepaisant to, kad Timas skaitė daugybę pokalbių, labai nedaug iš jų yra paskelbta „YouTube“. Galite pažiūrėti 2007 m. ataskaitą „The Return of Peopleware“. Kokybė, žinoma, palieka daug norimų rezultatų.
Michaelas: Ar kas nors pasikeitė per pastaruosius 30 metų nuo knygos išleidimo?
Timas: Galite pažvelgti į tai iš daugelio skirtingų kampų. Sociologiškai kalbant... kažkada, paprastesniais laikais, jūs ir jūsų komanda sėdėjote viename kabinete. Galite būti šalia kiekvieną dieną, kartu išgerti kavos ir aptarti darbus. Iš tikrųjų pasikeitė tai, kad komandos dabar gali būti paskirstytos geografiškai, skirtingose šalyse ir laiko juostose, tačiau jos vis tiek dirba su ta pačia problema, o tai suteikia visiškai naują sudėtingumo sluoksnį. Galbūt tai skamba senamadiškai, bet nėra nieko panašaus į bendravimą akis į akį, kai esate visi kartu, dirbate kartu ir galite prieiti prie kolegos ir pasakyti, pažiūrėkite, ką aš atradau, kaip jums tai patinka? Pokalbiai akis į akį suteikia greitą būdą pereiti prie neformalaus bendravimo, ir manau, kad tai turėtų patikti ir judriems entuziastams. Ir aš taip pat nerimauju, nes iš tikrųjų pasaulis pasirodė labai mažas, o dabar jis yra padengtas paskirstytomis komandomis, ir viskas yra labai sudėtinga.
Mes visi gyvename DevOps
Michaelas: Net ir konferencijos programos komiteto požiūriu, turime žmonių Kalifornijoje, Niujorke, Europoje, Rusijoje... Singapūre dar nėra nė vieno. Geografijos skirtumas gana didelis, o žmonės pradeda dar labiau išsiskirstyti. Jei kalbame apie plėtrą, ar galite papasakoti daugiau apie devopus ir kliūčių tarp komandų sunaikinimą? Yra tokia koncepcija, kad visi sėdi savo bunkeriuose, o dabar bunkeriai griūva, ką manote apie šią analogiją?
Timas: Man atrodo, kad atsižvelgiant į naujausius technologinius laimėjimus, devops yra labai svarbus. Anksčiau turėjai kūrėjų ir administratorių komandas, jie dirbo, dirbo, dirbo ir kažkuriuo momentu atsirado daiktas, su kuriuo galėjai ateiti pas administratorius ir išleisti jį gamybai. Ir čia prasidėjo pokalbis apie bunkerį, nes adminai yra savotiški sąjungininkai, bent jau ne priešai, bet su jais kalbėjai tik tada, kai viskas buvo paruošta gamybai. Ar nuėjote pas juos su kažkuo ir pasakėte: pažiūrėkite, kokią programą turime, bet ar galėtumėte šią programą įdiegti? Ir dabar visa pristatymo koncepcija pasikeitė į gerąją pusę. Turiu galvoje, kad buvo mintis, kad galėtumėte greitai įgyvendinti pokyčius. Galime atnaujinti produktus iš karto. Aš visada šypsausi, kai mano nešiojamajame kompiuteryje pasirodo „Firefox“ ir sako: „Ei, mes atnaujinome jūsų „Firefox“ fone ir, kai tik turėsite minutę, spustelėsite čia ir mes jums pateiksime naujausią leidimą. Ir aš sakiau: „O taip, vaikeli! Kol aš miegojau, jie stengėsi pristatyti man naują leidimą tiesiai į mano kompiuterį. Tai nuostabu, neįtikėtina.
Tačiau čia yra sunkumų: jūs turite šią funkciją atnaujindami programinę įrangą, tačiau integruoti žmones yra daug sunkiau. „DevOops“ pagrindiniame pranešime noriu pasakyti, kad dabar turime daug daugiau žaidėjų nei kada nors turėjome. Jei pagalvotumėte tik apie visus, dalyvaujančius tik vienoje komandoje… Jūs galvojote apie tai kaip apie komandą, ir tai yra daug daugiau nei tik programuotojų komanda. Tai yra testuotojai, projektų vadovai ir daugybė kitų žmonių. Ir kiekvienas turi savo požiūrį į pasaulį. Produktų vadovai visiškai skiriasi nuo projektų vadovų. Administratoriai turi savo užduotis. Gana sudėtinga problema tampa koordinuoti visus dalyvius, kad ir toliau žinotume, kas vyksta ir neišprotėtų. Būtina atskirti grupės užduotis ir užduotis, kurios tinka visiems. Tai labai sunki užduotis. Kita vertus, manau, kad viskas daug geriau nei buvo prieš daugelį metų. Būtent tokiu keliu žmonės auga ir mokosi teisingai elgtis. Kai darai integraciją, supranti, kad pogrindinės plėtros neturėtų būti, kad paskutinę akimirką programinė įranga neišlįstų kaip dėklas: pažiūrėk, ką mes čia padarėme! Idėja yra ta, kad galėsite atlikti integraciją ir plėtrą, o pabaigoje tvarkingai ir pakartotinai išriedėsite. Visa tai man reiškia labai daug. Tai leidžia sukurti daugiau vertės sistemos vartotojams ir jūsų klientui.
Michaelas: Visa devops idėja yra kuo anksčiau pateikti prasmingus pokyčius. Matau, kad pasaulis pradėjo vis labiau įsibėgėti. Kaip prisitaikyti prie tokių pagreičių? Prieš dešimt metų to nebuvo!
Timas: Žinoma, visi nori vis daugiau funkcionalumo. Nereikia judėti, tiesiog susikrauti daugiau. Kartais netgi reikia sulėtinti greitį, kol kitą laipsnišką atnaujinimą norite gauti ką nors naudingo – ir tai visiškai normalu.
Idėja, kad reikia bėgti, bėgti, bėgti, nėra pati geriausia. Vargu ar kas nors nori taip gyventi savo gyvenimą. Norėčiau, kad pristatymo ritmas nustatytų projekto ritmą. Jei tik sukuriate mažų, santykinai beprasmių dalykų srautą, visa tai netenka prasmės. Užuot be proto stengęsi viską kuo anksčiau paleisti, verta aptarti su pagrindiniais kūrėjais ir produktų bei projektų vadovais – tai strategija. Ar tai net turi prasmę?
Šablonai ir antipatternai
Olegas: Paprastai kalbate apie modelius ir antipatternus, ir tai yra skirtumas tarp projektų gyvavimo ir mirties. O dabar devops įsiveržia į mūsų gyvenimą. Ar jis turi kokių nors savo modelių ir anti-modelių, kurie gali sunaikinti projektą vietoje?
Timas: Šablonų ir anti-modelių pasitaiko nuolat. Apie ką kalbėti. Na, yra tai, ką mes vadiname „blizgančiais dalykais“. Žmonėms labai labai patinka naujos technologijos. Juos tiesiog užburia blizgesys to, kas atrodo šauniai ir stilingai, ir jie nustoja klausinėti: ar tai išvis būtina? Ką mes pasieksime? Ar šis dalykas yra patikimas, ar jis turi prasmę? Dažnai matau žmones, taip sakant, pažangiausius technologijų srityje. Juos užhipnotizuoja tai, kas vyksta pasaulyje. Bet jei atidžiau pažvelgsite į tai, ką naudingo jie daro, dažnai nieko naudingo nėra!
Kaip tik su bendražygiais diskutavome, kad šiemet jubiliejiniai metai, penkiasdešimt metų nuo žmonių išsilaipinimo Mėnulyje. Tai buvo 1969 m. Technologijos, padėjusios žmonėms ten patekti, yra net ne 1969 m., o veikiau 1960 ar 62 m., nes NASA norėjo naudoti tik tai, kas turi gerų patikimumo įrodymų. Taigi, pažvelgi į tai ir supranti – taip, ir jie buvo tiesa! Dabar ne, ne, bet jūs susiduriate su technologijomis vien dėl to, kad viskas per daug stumdoma, parduodama iš visų plyšių. Žmonės iš visur šaukia: „Žiūrėk, koks daiktas, čia pats naujausias, gražiausias dalykas pasaulyje, tinka absoliučiai visiems! Na, tiek... dažniausiai visa tai pasirodo tik apgaulė, o vėliau visa tai tenka išmesti. Galbūt viskas dėl to, kad aš jau senas žmogus ir į tokius dalykus žiūriu labai skeptiškai, kai žmonės pribėga ir sako, kad rado Vienintelį, teisingiausią būdą sukurti geriausias technologijas. Šiuo metu manyje pabunda balsas, kuris sako: „Kokia netvarka!
Michaelas: Iš tiesų, kaip dažnai girdėjome apie kitą sidabrinę kulką?
Timas: Būtent, ir tai yra įprasta dalykų eiga! Pavyzdžiui... atrodo, kad tai jau tapo pokštu visame pasaulyje, bet čia dažnai kalbama apie blockchain technologiją. Ir jie iš tikrųjų yra prasmingi tam tikrose situacijose! Kai jums tikrai reikia patikimų įrodymų apie įvykius, kad sistema veikia ir kad niekas mūsų neapgavo, kai turite saugumo problemų ir visa tai sumaišyta, blokų grandinė yra prasminga. Bet kai jie sako, kad „Blockchain“ dabar nušluos visą pasaulį ir nušluos viską, kas yra savo kelyje? Svajok daugiau! Tai labai brangi ir sudėtinga technologija. Techniškai sudėtingas ir daug laiko reikalaujantis. Įskaitant grynai algoritmiškai, kiekvieną kartą, kai reikia perskaičiuoti matematiką, su menkiausiais pakeitimais... ir tai yra puiki idėja – bet tik tam tikrais atvejais. Visas mano gyvenimas ir karjera buvo apie tai: įdomios idėjos labai konkrečiose situacijose. Labai svarbu tiksliai suprasti, kokia yra jūsų situacija.
Michaelas: Taip, pagrindinis „gyvenimo, visatos ir visko klausimas“: ar ši technologija ar metodas tinka jūsų situacijai, ar ne?
Timas: Šį klausimą jau galima aptarti su technologijų grupe. Gal net atsivesk kokį konsultantą. Pažvelkite į projektą ir supraskite – ar dabar ką nors padarysime teisingai ir naudingai, geriau nei anksčiau? Gal tiks, o gal ne. Bet svarbiausia, nepriimkite tokio sprendimo pagal nutylėjimą vien todėl, kad kažkas ištarė: „Mums labai reikia blokų grandinės! Ką tik perskaičiau apie jį žurnale lėktuve! Rimtai? Tai net nejuokinga.
Mitinis „devopso inžinierius“
Olegas: Dabar visi diegia devops. Kažkas skaito apie devopus internete, o rytoj įdarbinimo svetainėje atsiranda dar viena laisva vieta. "devops inžinierius". Čia norėčiau atkreipti jūsų dėmesį: ar, jūsų manymu, šis terminas „devops inžinierius“ turi teisę į gyvybę? Yra nuomonė, kad devops yra kultūra, ir kažkas čia nesutampa.
Timas: Taip ir taip. Leiskite jiems iškart pateikti šio termino paaiškinimą. Kažkas, kad jis būtų išskirtinis. Kol jie neįrodys, kad už tokios laisvos vietos slypi kažkoks unikalus įgūdžių derinys, aš jos nepirksiu! Turiu galvoje, kad turime pareigų pavadinimą „devops inžinierius“, įdomų pavadinimą, taip, kas toliau? Pareigybės paprastai yra labai įdomus dalykas. Tarkime „kūrėjas“ – kas tai vis dėlto? Skirtingos organizacijos reiškia visiškai skirtingus dalykus. Kai kuriose įmonėse aukštos kokybės programuotojai rašo testus, kurie yra prasmingesni, nei testai, parašyti specialių profesionalių testuotojų kitose įmonėse. Tai ką, jie dabar programuotojai ar bandytojai?
Taip, turime pareigų pavadinimus, bet jei pakankamai ilgai užduodate klausimus, galiausiai paaiškėja, kad mes visi esame problemų sprendėjai. Mes ieškome sprendimų, kai kurie turi tam tikrų techninių įgūdžių, o kiti – kitokius. Jei gyvenate aplinkoje, į kurią įsiskverbė DevOps, užsiimate kūrimo ir administravimo integravimu, ir ši veikla turi gana svarbų tikslą. Bet jei jūsų paklaus, ką tiksliai veikiate ir už ką esate atsakingas, paaiškėja, kad žmonės visa tai darė nuo neatmenamų laikų. „Aš atsakingas už architektūrą“, „aš atsakingas už duomenų bazes“ ir taip toliau, matai – visa tai buvo prieš „devops“.
Kai kas nors pasako savo pareigas, aš nelabai klausau. Geriau leiskite jam pasakyti, už ką jis iš tikrųjų atsakingas, tai leis mums daug geriau suprasti problemą. Mano mėgstamiausias pavyzdys, kai žmogus teigia esąs „projektų vadovas“. Ką? Tai nieko nereiškia, aš vis dar nežinau, ką tu darai. Projekto vadovas gali būti kūrėjas, keturių žmonių komandos vadovas, rašantis kodą, dirbantis darbą, tapęs komandos lyderiu, kurį patys žmonės atpažįsta tarp savęs kaip lyderį. Be to, projektų vadovas gali būti vadovas, kuris projekte vadovauja šešiems šimtams žmonių, vadovauja kitiems vadovams, yra atsakingas už grafikų sudarymą ir biudžetų planavimą, tai viskas. Tai du visiškai skirtingi pasauliai! Tačiau jų pareigų pavadinimas skamba taip pat.
Apverskime tai šiek tiek kitaip. Ką tu iš tiesų esi geras, turi daug patirties, ar turi talentą? Už ką prisiimsite atsakomybę, nes manote, kad galite susidoroti su užduotimi? Ir čia kažkas tuoj pradės neigti: ne, ne, ne, aš visai nenoriu užsiimti projektų ištekliais, tai ne mano reikalas, aš esu techninis bičiulis ir suprantu naudojimo patogumą bei vartotojo sąsajas, aš nesuprantu. išvis nori valdyti armijas žmonių, leisk man geriau eiti į darbą.
Ir, beje, aš esu didelis šalininkas tokio požiūrio, kuriame toks įgūdžių atskyrimas veikia gerai. Kur technikai gali plėsti savo karjerą tiek, kiek nori. Tačiau vis dar matau organizacijų, kuriose technikos specialistai skundžiasi: turėsiu eiti į projektų valdymą, nes tai vienintelis būdas šioje įmonėje. Kartais tai veda prie baisių pasekmių. Geriausi technikos specialistai nėra geri vadovai, o geriausi vadovai negali susitvarkyti su technologijomis. Būkime sąžiningi šiuo klausimu.
Dabar matau didelę paklausą. Jei esate technikos specialistas, jūsų įmonė gali jums padėti, tačiau, nepaisant to, jums tikrai reikia rasti savo karjeros kelią, nes technologijos nuolat keičiasi ir kartu su jais reikia išradinėti save! Vos per dvidešimt metų technologijos gali pasikeisti bent penkis kartus. Technologijos keistas dalykas...
„Visko ekspertai“
Michaelas: Kaip žmonės gali susidoroti su tokiu technologijų kaitos greičiu? Jų sudėtingumas auga, jų skaičius auga, bendras bendravimo tarp žmonių skaičius taip pat auga, ir pasirodo, kad negali tapti „visko ekspertu“.
Timas: Teisingai! Jei dirbi technologijų srityje, taip, tikrai reikia pasirinkti kažką konkretaus ir į tai įsigilinti. Kai kurios technologijos, kurios jūsų organizacijai atrodo naudingos (ir galbūt iš tikrųjų bus naudingos). O jei tau tai nebeįdomu – niekada nebūčiau patikėjęs, kad taip pasakysiu – na, gal reikėtų pereiti į kokią kitą organizaciją, kur technologija įdomesnė ar patogiau mokytis.
Bet apskritai taip, tu teisus. Technologijos auga visomis kryptimis vienu metu, niekas negali pasakyti: „Aš esu visų egzistuojančių technologijų technologas. Kita vertus, yra kempinės žmonių, kurie tiesiogine prasme įsisavina technologines žinias ir yra dėl jų pamišę. Mačiau porą tokių žmonių, jie tiesiogine prasme kvėpuoja ir tuo gyvena, su jais naudinga ir įdomu pasikalbėti. Jie tiria ne tik tai, kas vyksta organizacijos viduje, bet ir apskritai, apie tai kalba, yra ir tikrai šaunūs technologai, labai sąmoningi ir kryptingi. Jie tiesiog stengiasi išlikti ant bangos keteros, nepaisant to, koks jų pagrindinis darbas, nes jų aistra – Technologijų judėjimas, technologijų propagavimas. Jei netikėtai sutinkate tokį žmogų, turėtumėte eiti su juo papietauti ir per pietus aptarti įvairius šaunius dalykus. Manau, kad bet kuriai organizacijai reikia bent poros tokių žmonių.
Rizika ir netikrumas
Michaelas: Gerbiami inžinieriai, taip. Palieskime rizikos valdymą, kol turėsime laiko. Šį interviu pradėjome aptardami medicininę programinę įrangą, kur klaidos gali sukelti baisių pasekmių. Tada mes kalbėjome apie Mėnulio programą, kur klaidos kaina yra milijonai dolerių ir galbūt keletas žmonių gyvybių. Tačiau dabar matau priešingą judėjimą pramonėje, žmonės negalvoja apie rizikas, nesistengia jų numatyti, net nepastebi.
Olegas: Greitai judėkite ir sulaužykite daiktus!
Michaelas: Taip, judėkite greitai, laužykite daiktus, vis daugiau daiktų, kol nuo kažko numirsite. Kaip, jūsų požiūriu, vidutinis kūrėjas dabar turėtų žiūrėti į mokymosi rizikos valdymą?
Timas: Nubrėžkime liniją tarp dviejų dalykų: rizikos ir netikrumo. Tai skirtingi dalykai. Neaiškumas atsiranda, kai tam tikru momentu neturite pakankamai duomenų, kad gautumėte galutinį atsakymą. Pavyzdžiui, labai ankstyvoje projekto stadijoje, jei kas nors jūsų paklaus „kada baigsi darbą“, jei esate gana sąžiningas žmogus, atsakysite: „Nežinau“. Tu tiesiog nežinai, ir viskas gerai. Jūs dar nenagrinėjote problemų ir nesate susipažinę su komanda, nežinote jų įgūdžių ir pan. Tai yra neapibrėžtumas.
Rizika kyla tada, kai jau galima nustatyti galimas problemas. Toks dalykas gali atsitikti, jo tikimybė yra didesnė už nulį, bet mažesnė nei šimtas procentų, kažkur tarp jų. Dėl to gali nutikti visko – nuo vėlavimų ir nereikalingų darbų, bet net iki lemtingos projekto baigties. Rezultatas, kai sakai – vaikinai, susilankstykime skėčius ir išeikime iš paplūdimio, niekada to nepabaigsime, viskas baigta, taškas. Darėme prielaidą, kad šis dalykas veiks, bet tai visiškai neveikia, laikas sustoti. Tokios situacijos.
Dažnai problemas lengviausia išspręsti tada, kai jos jau išryškėjo, kai problema vyksta būtent dabar. Tačiau kai problema yra priešais jus, jūs nevaldote rizikos – jūs sprendžiate problemas, valdote krizes. Jei esate pagrindinis kūrėjas ar vadovas, tikriausiai susimąstote, kas gali lemti vėlavimus, sugaištą laiką, nereikalingas išlaidas ar viso projekto žlugimą? Kas privers mus sustoti ir pradėti iš naujo? Kai visi šie dalykai veiks, ką su jais darysime? Yra paprastas atsakymas, tinkantis daugeliui situacijų: nebėgkite nuo rizikos, dirbkite su ja. Pažiūrėkite, kaip galite išspręsti rizikingą situaciją, sumažinti ją iki nieko, paversti ją iš problemos kuo nors kitu. Užuot sakę: gerai, mes išspręsime problemas, kai jos iškils.
Neapibrėžtumas ir rizika turėtų būti visų dalykų, su kuriais susiduriate, priešakyje. Galite sudaryti projekto planą, iš anksto pažvelgti į tam tikras kritines rizikas ir pasakyti: mes turime su tuo susidoroti dabar, nes jei kas nors iš to nepavyks, niekas kitas neturės reikšmės. Neturėtumėte jaudintis dėl staltiesės ant stalo grožio, jei neaišku, ar galite gaminti vakarienę. Pirmiausia reikia identifikuoti visas rizikas ruošiant skanią vakarienę, su jais susitvarkyti ir tik tada galvoti apie visus kitus realios grėsmės nekeliančius dalykus.
Vėlgi, kuo jūsų projektas išskirtinis? Pažiūrėkime, kas gali priversti mūsų projektą nuvyti nuo bėgių. Ką galime padaryti, kad sumažintume tikimybę, kad taip nutiks? Paprastai negalite jų tiesiog neutralizuoti 100% ir ramia sąžine pareikšti: „Štai, tai nebėra problema, rizika išnyko! Man tai yra suaugusiųjų elgesio požymis. Tai yra skirtumas tarp vaiko ir suaugusiojo – vaikai mano, kad yra nemirtingi, kad nieko negali nutikti, viskas bus gerai! Tuo pačiu metu suaugusieji stebi, kaip trejų metų vaikai šokinėja žaidimų aikštelėje, akimis seka judesius ir sako sau: „o-oo, oo-oo“. Stoviu šalia ir ruošiuosi gaudyti, kai vaikas nukris.
Kita vertus, šis verslas man taip patinka, nes jis rizikingas. Mes darome dalykus, ir tie dalykai yra rizikingi. Jiems reikalingas suaugusiųjų požiūris. Vien entuziazmas neišspręs jūsų problemų!
Suaugusiųjų inžinerinis mąstymas
Michaelas: Pavyzdys su vaikais geras. Jei esu paprastas inžinierius, tai man malonu būti vaiku. Tačiau kaip pereiti prie suaugusiųjų mąstymo?
Timas: Viena iš idėjų, kuri vienodai gerai tinka tiek pradedančiajam, tiek nusistovėjusiam kūrėjui, yra konteksto samprata. Ką mes darome, ko siekiame. Kas iš tiesų svarbu šiame projekte? Nesvarbu, kas esate šiame projekte, ar esate praktikantas, ar vyriausiasis architektas, kiekvienam reikia konteksto. Turime priversti visus mąstyti didesniu mastu nei savo paties darbai. „Aš kuriu savo kūrinį ir tol, kol mano kūrinys veikia, esu laimingas“. Ne ir dar kartą ne. Visada verta (nebūdami nemandagiai!) priminti žmonėms apie kontekstą, kuriame jie dirba. Ko mes visi kartu stengiamės pasiekti. Idėjos, kad galite būti vaiku tol, kol viskas bus gerai su jūsų projekto dalimi – prašau, nedarykite to. Jei išvis kirsime finišo liniją, ją kirsime tik kartu. Jūs nesate vienas, mes visi kartu. Jei visi projekte dalyvaujantys žmonės, tiek seni, tiek jauni, pradėtų kalbėti apie tai, kas būtent yra svarbu projektui, kodėl įmonė investuoja pinigus į tai, ką mes visi stengiamės pasiekti... dauguma jų jausis daug geriau, nes pamatys, kaip jų darbas koreliuoja su visų kitų darbais. Viena vertus, aš suprantu kūrinį, už kurį esu atsakingas. Tačiau norint užbaigti darbą, mums reikia ir visų kitų žmonių. Ir jei tikrai manote, kad baigėte, mes visada turime ką nuveikti projekte!
Olegas: Santykinai kalbant, jei dirbi pagal Kanban, pataikęs į tam tikro testavimo kliūtį, gali mesti tai, ką ten darei (pavyzdžiui, programavimą) ir eiti padėti testuotojams.
Timas: Būtent. Manau, kad geriausi technikos specialistai, jei atidžiai į juos pažvelgsite, jie yra savotiški vadovai. Kaip aš galiu tai suformuluoti...
Olegas: Jūsų gyvenimas yra jūsų projektas, kurį valdote jūs.
Timas: Būtent! Aš turiu galvoje, kad prisiimate atsakomybę, suprantate problemą ir bendraujate su žmonėmis, kai matote, kad jūsų sprendimai gali turėti įtakos jų darbui ir panašiai. Tai ne tik sėdėjimas prie stalo, darbas ir net nesuvokimas, kas vyksta aplinkui. ne ne ne. Beje, vienas geriausių dalykų „Agile“ yra tai, kad jie pasiūlė trumpus sprintus, nes taip aiškiai matoma visų dalyvių padėtis, jie mato viską kartu. Mes kalbame vienas apie kitą kiekvieną dieną.
Kaip įsitraukti į rizikos valdymą
Olegas: Ar šioje srityje yra kokia nors formali žinių struktūra? Pavyzdžiui, aš esu „Java“ kūrėjas ir noriu suprasti rizikos valdymą, netapdamas tikru projektų vadovu pagal išsilavinimą. Tikriausiai pirmiausia perskaitysiu McConnell knygą „Kiek kainuoja programinės įrangos projektas“, o kas tada? Kokie pirmieji žingsniai?
Timas: Pirmasis – pradėti bendrauti su žmonėmis projekte. Tai iš karto pagerina bendravimo su kolegomis kultūrą. Turime pradėti viską atidaryti pagal numatytuosius nustatymus, o ne slėpti. Sakyk: štai kas mane trikdo, tai mane užmiega naktimis, aš šiandien pabudau naktį ir buvau taip: Dieve, man reikia apie tai pagalvoti! Ar kiti mato tą patį? Ar turėtume, kaip grupė, reaguoti į šias galimas problemas? Turite palaikyti diskusiją šiomis temomis. Nėra iš anksto paruoštos formulės, pagal kurią dirbame. Tai ne apie mėsainių gaminimą, o apie žmones. „Pagamink sūrio mėsainį, parduok sūrio mėsainį“ visai ne mūsų reikalas, todėl man taip patinka šis darbas. Man patinka, kai viskas, ką anksčiau darė vadovai, dabar tampa komandos nuosavybe.
Olegas: Knygose ir interviu kalbėjote apie tai, kad žmonėms labiau rūpi laimė nei skaičiai diagramoje. Kita vertus, kai pasakai komandai: pereiname prie devopso, o dabar programuotojas turi nuolat bendrauti, tai gali būti toli už jo komforto zonos. Ir šiuo metu jis, tarkime, gali būti labai nelaimingas. Ką daryti šioje situacijoje?
Timas: Nesu tikras, ką tiksliai daryti. Jei kūrėjas yra per daug izoliuotas, jis nesuvokia, kodėl iš pradžių atliekamas darbas, tiesiog žiūri į savo darbo dalį ir turi patekti į tai, ką aš vadinu „kontekstu“. Jis turi išsiaiškinti, kaip viskas yra tarpusavyje susiję. Ir, žinoma, aš neturiu omenyje oficialių pristatymų ar panašių dalykų. Kalbu apie tai, kad su kolegomis reikia bendrauti apie darbą kaip visumą, o ne tik apie jo dalį, už kurią esi atsakingas. Čia galite pradėti diskutuoti apie idėjas, bendrus susitarimus, kad jūsų darbas gerai derėtų, ir kaip kartu spręsti bendrą problemą.
Kad padėtų jiems prisitaikyti, jie dažnai nori siųsti technikus į mokymus ir aptaria mokymus. Mano draugas mėgsta sakyti, kad dresūra skirta šunims. Yra mokymai žmonėms. Vienas geriausių dalykų mokantis kaip kūrėjas yra bendravimas su bendraamžiais. Jei kas nors yra tikrai geras, turėtumėte stebėti, kaip jis dirba, arba pasikalbėti su juo apie savo darbą ar ką nors kita. Kai kurie įprasti Kentas Beckas nuolat kalbėjo apie ekstremalų programavimą. Tai juokinga, nes XP yra tokia paprasta idėja, tačiau ji sukelia tiek daug problemų. Kai kuriems XP darymas yra tarsi verčiamas nusirengti prieš draugus. Jie pamatys, ką aš darau! Jie yra mano kolegos, jie ne tik pamatys, bet ir supras! Siaubinga! Kai kurie žmonės pradeda rimtai nervintis. Tačiau kai supranti, kad tai yra geriausias būdas mokytis, viskas pasikeičia. Glaudžiai bendradarbiaujate su žmonėmis, o kai kurie žmonės šią temą supranta daug geriau nei jūs.
Michaelas: Tačiau visa tai verčia išeiti iš komforto zonos. Kaip inžinierius turi išeiti iš komforto zonos ir bendrauti. Kaip problemų sprendėjas, turite nuolat save pastatyti į silpną padėtį ir galvoti, kas gali nutikti. Šio tipo darbai iš prigimties yra sukurti taip, kad trukdytų. Jūs sąmoningai patenkate į stresines situacijas. Dažniausiai žmonės nuo jų bėga, mėgsta būti laimingais vaikais.
Timas: Ką galima padaryti, gali išeiti ir atvirai pasakyti: „Viskas gerai, aš susitvarkysiu! Ne aš viena jaučiuosi nepatogiai. Aptarkime įvairius nepatogius dalykus visi kartu, kaip komanda! Tai yra mūsų bendros problemos, mes turime jas spręsti, žinote? Manau, kad idiosinkratiški genialūs kūrėjai yra kaip mamutai, jie išnyko. Ir jų reikšmė labai ribota. Jei nemokate bendrauti, negalite gerai dalyvauti. Todėl tiesiog kalbėkite. Būkite sąžiningi ir atviri. Labai atsiprašau, kad kažkam tai nemalonu. Įsivaizduojate, prieš daugelį metų buvo atliktas tyrimas, pagal kurį JAV pagrindinė baimė yra ne mirtis, bet spėk ką? Viešo kalbėjimo baimė! Tai reiškia, kad kažkur yra žmonių, kurie mieliau mirtų, nei garsiai pasakytų komplimentą. Ir manau, kad pakanka turėti tam tikrų pagrindinių įgūdžių, priklausomai nuo to, ką darai. Kalbėjimo, rašymo įgūdžiai – bet tik tiek, kiek iš tiesų reikia jūsų darbe. Jei dirbate analitiku, bet negalite skaityti, rašyti ir kalbėti, tada, deja, neturėsite ką veikti mano projektuose!
Bendravimo kaina
Olegas: Ar dėl įvairių priežasčių tokių išeinančių darbuotojų įdarbinimas neapsimoka? Juk jie nuolat plepa, o ne dirba!
Timas: Turėjau omenyje komandos branduolį, o ne tik visus. Jei turite ką nors, kas tikrai puikiai derina duomenų bazes, mėgsta derinti duomenų bazes ir ketina tęsti duomenų bazių derinimą visą likusį gyvenimą ir viskas, šaunu, taip ir toliau. Bet aš kalbu apie žmones, kurie nori gyventi pačiame projekte. Komandos branduolys, kurio tikslas – plėtoti projektą. Šiems žmonėms tikrai reikia nuolat bendrauti tarpusavyje. O ypač projekto pradžioje, kai aptariate rizikas, būdus, kaip pasiekti pasaulinius tikslus ir panašiai.
Michaelas: Tai taikoma visiems, dalyvaujantiems projekte, neatsižvelgiant į specializaciją, įgūdžius ar darbo būdus. Jus visus domina projekto sėkmė.
Timas: Taip, jauti, kad esi pakankamai pasinėręs į projektą, kad tavo užduotis – padėti projektui išsipildyti. Nesvarbu, ar esate programuotojas, analitikas, sąsajos dizaineris, bet kas. Dėl šios priežasties kiekvieną rytą ateinu į darbą ir tai darome. Mes esame atsakingi už visus šiuos žmones, nepaisant jų įgūdžių. Tai grupė žmonių, kurie bendrauja suaugusiems.
Olegas: Tiesą sakant, kalbėdama apie plepius darbuotojus, bandžiau imituoti žmonių, ypač vadovų, kurių prašoma pereiti prie devops, prieštaravimus šiai visiškai naujai pasaulio vizijai. Ir jūs, kaip konsultantai, turėtumėte žinoti šiuos prieštaravimus daug geriau nei aš, kaip kūrėjas! Pasidalinkite, kas vadovams kelia didžiausią nerimą?
Timas: Vadovai? Hm. Dažniausiai vadovai patiria problemų, susiduria su būtinybe skubiai ką nors išleisti ir pristatyti ir panašiai. Jie stebi, kaip mes nuolat dėl kažko diskutuojame ir ginčijamės, o mato taip: pokalbiai, pokalbiai, pokalbiai... Kokie dar pokalbiai? Grįžk prie darbo! Nes kalbėjimas jiems neatrodo kaip darbas. Jūs nerašote kodo, netestuojate programinės įrangos, atrodo, kad nieko nedarote – kodėl gi jūsų nenusiųsti kažko daryti? Juk pristatymas jau po mėnesio!
Michaelas: Eik parašyk kodą!
Timas: Man atrodo, kad jie nerimauja ne dėl darbo, o dėl progreso nematomumo. Kad atrodytų, jog artėjame prie sėkmės, jie turi matyti, kaip spaudžiame klaviatūros mygtukus. Visą dieną nuo ryto iki vakaro. Tai yra problema numeris vienas.
Olegas: Miša, tu apie kažką galvoji.
Michaelas: Atsiprašau, pasiklydau mintyse ir pagavau prisiminimą. Visa tai priminė įdomų vakar įvykusį mitingą... Vakar buvo per daug mitingų... Ir visa tai skamba labai pažįstamai!
Gyvenimas be atlyginimo
Timas: Beje, visai nebūtina organizuoti „mitingus“ bendravimui. Turiu omenyje, kad naudingiausios diskusijos tarp kūrėjų vyksta tada, kai jie tiesiog kalbasi vienas su kitu. Įeini ryte su kavos puodeliu, o ten susirinkę penki žmonės įnirtingai aptarinėja kažką techninio. Man, jei esu šio projekto vadovas, geriau tiesiog nusišypsoti ir eiti kur nors apie savo reikalus, tegul jie tai aptarinėja. Jie jau yra įsitraukę, kiek įmanoma. Tai geras ženklas.
Olegas: Beje, savo knygoje turite krūvą pastabų apie tai, kas yra gerai, o kas blogai. Ar pats naudojate kurį nors iš jų? Santykinai kalbant, dabar jūs turite įmonę, kurios struktūra yra labai neįprasta...
Timas: Neįprasta, bet šis prietaisas mums puikiai tinka. Mes pažįstami jau seniai. Mes pasitikime vienas kitu, labai pasitikėjome vienas kitu prieš tapdami partneriais. O pavyzdžiui, pas mus visai nėra atlyginimų. Mes tiesiog dirbame, o, pavyzdžiui, aš užsidirbdavau pinigų iš savo klientų, tai visi pinigai atitekdavo man. Po to organizacijai mokame nario mokesčius, o to užtenka pačiai įmonei išlaikyti. Be to, mes visi specializuojamės skirtinguose dalykuose. Pavyzdžiui, aš dirbu su buhalteriais, pildau mokesčių deklaracijas, darau visokius įmonės administracinius reikalus, o man už tai niekas nemoka. Jamesas ir Tomas dirba mūsų svetainėje ir jiems taip pat niekas nemoka. Kol mokėsite mokesčius, niekas negalvos jums pasakyti, ką turite padaryti. Pavyzdžiui, Tomas dabar dirba daug mažiau nei anksčiau. Dabar jis turi kitų interesų, kai kuriuos dalykus jis daro ne dėl gildijos. Bet kol jis sumokės rinkliavas, niekas prie jo neprieis ir nesakys: „Ei, Tomai, eik į darbą! Labai lengva bendrauti su kolegomis, kai tarp jūsų nėra pinigų. Ir dabar mūsų santykiai yra viena iš pagrindinių idėjų, susijusių su įvairiomis specialybėmis. Tai veikia ir veikia labai gerai.
Geriausias patarimas
Michaelas: Grįžtant prie „geriausio patarimo“, ar yra ką nors kartoti savo klientams? Yra mintis apie 80/20, o kai kurie patarimai tikriausiai kartojami dažniau.
Timas: Kažkada maniau, kad jei parašysi tokią knygą kaip „Valsas su lokiais“, tai pakeis istorijos eigą ir žmonės sustotų, bet... Na, žiūrėk, įmonės dažnai apsimeta, kad su jomis viskas gerai. Kai tik nutinka kažkas blogo, jiems tai būna šokas ir staigmena. „Žiūrėkite, mes išbandėme sistemą ir ji nepraeina jokių sistemos testų, o tai dar trys mėnesiai neplanuoto darbo, kaip tai galėjo nutikti? Kas žinojo? Kas gali suklysti? Rimtai, ar tu tuo tiki?
Bandau paaiškinti, kad nereikėtų per daug pykti dėl esamos situacijos. Turime tai išsikalbėti, iš tikrųjų suprasti, kas galėjo nutikti ir kaip išvengti tokių dalykų ateityje. Jei iškils problema, kaip su ja kovosime, kaip ją suvaldysime?
Man visa tai atrodo baisu. Žmonės susiduria su sudėtingomis, varginančiomis problemomis ir toliau apsimeta, kad jei tik sukryžia pirštus ir tikisi geriausio, iš tikrųjų atsitiks „geriausia“. Ne, tai neveikia taip.
Praktikuokite rizikos valdymą!
Michaelas: Kiek organizacijų, Jūsų nuomone, užsiima rizikos valdymu?
Timas: Mane piktina tai, kad žmonės paprasčiausiai užsirašo riziką, pasižiūri į gautą sąrašą ir kimba į darbą. Tiesą sakant, rizikos nustatymas jiems yra rizikos valdymas. Bet man tai skamba kaip priežastis paklausti: gerai, yra sąrašas, ką tiksliai pakeisite? Atsižvelgdami į šią riziką, turite pakeisti savo standartinę veiksmų seką. Jei yra kokia nors sunkiausia darbo dalis, reikia ją spręsti ir tik tada pereiti prie paprastesnio. Pirmaisiais sprintais pradėkite spręsti sudėtingas problemas. Tai jau atrodo kaip rizikos valdymas. Tačiau paprastai žmonės negali pasakyti, ką jie pakeitė sudarę rizikos sąrašą.
Michaelas: Ir vis dėlto, kiek iš šių įmonių dalyvauja rizikos valdyme, penki procentai?
Timas: Deja, nekenčiu to sakyti, bet tai labai nereikšminga dalis. Bet daugiau nei penkis, nes yra tikrai didelių projektų, ir jie tiesiog negali egzistuoti, jei bent kažko nedaro. Tarkime, labai nustebsiu, jei bus bent 25 proc. Maži projektai dažniausiai į tokius klausimus atsako taip: jei problema mus paliečia, tai mes ją išspręsime. Tada jie sėkmingai patenka į bėdą ir įsitraukia į problemų valdymą bei krizių valdymą. Kai bandote išspręsti problemą ir problema neišspręsta, sveiki atvykę į krizių valdymą.
Taip, aš dažnai girdžiu: „Mes išspręsime problemas, kai jos iškils“. Tikrai taip? Ar tikrai nuspręsime?
Olegas: Galite tai padaryti naiviai ir tiesiog įrašyti svarbius invariantus į projekto chartiją, o jei invariantai sugenda, tiesiog paleiskite projektą iš naujo. Pasirodo labai piembucky.
Michaelas: Taip, man atsitiko taip, kad atsiradus rizikai, projektas buvo tiesiog iš naujo apibrėžtas. Puiku, bingo, problema išspręsta, daugiau nesijaudinkite!
Timas: Paspauskite atstatymo mygtuką! Ne, tai neveikia taip.
Pagrindinis pranešimas „DevOops 2019“.
Michaelas: Prieiname prie paskutinio šio interviu klausimo. Ateinate į kitą „DevOops“ su pagrindiniu pranešimu. Ar galėtumėte pakelti paslapties uždangą, ką papasakosite?
Timas: Šiuo metu šeši iš jų rašo knygą apie darbo kultūrą, neišpasakytas organizacijų taisykles. Kultūrą lemia pagrindinės organizacijos vertybės. Dažniausiai žmonės to nepastebi, tačiau ilgus metus dirbę konsultavimo srityje esame įpratę tai pastebėti. Įeini į kompaniją ir tiesiogine prasme per kelias minutes pradedi jausti, kas vyksta. Mes tai vadiname „skoniu“. Kartais šis kvapas yra tikrai geras, o kartais - na, oi. Įvairiose organizacijose viskas labai skiriasi.
Michaelas: Aš taip pat daug metų dirbu konsultavimo srityje ir gerai suprantu, apie ką kalbate.
Timas: Tiesą sakant, vienas iš dalykų, apie kurį verta kalbėti pagrindiniame pranešime, yra tai, kad ne viską lemia įmonė. Jūs ir jūsų komanda, kaip bendruomenė, turite savo komandos kultūrą. Tai gali būti visa įmonė arba atskiras skyrius, atskira komanda. Bet prieš jums sakydamas: štai kuo mes tikime, štai kas svarbu... Negalite pakeisti kultūros, kol nesuprantate vertybių ir įsitikinimų, slypinčių už konkrečių veiksmų. Elgesį lengva stebėti, bet sunku ieškoti įsitikinimų. „DevOps“ yra tik puikus pavyzdys, kaip viskas darosi vis sudėtingiau. Sąveika tik komplikuojasi, visiškai netampa švaresnė ir aiškesnė, todėl reikėtų pagalvoti, kuo tikite ir apie ką tyli visi aplinkiniai.
Jei norite pasiekti greitų rezultatų, čia jums gera tema: ar matėte įmonių, kuriose niekas nesako „nežinau“? Yra vietų, kur žmogų kankini tiesiogine to žodžio prasme, kol jis prisipažįsta, kad kažko nežino. Visi viską žino, visi yra neįtikėtini eruditai. Jūs kreipsitės į bet kurį žmogų, ir jis turi akimirksniu atsakyti į klausimą. Užuot sakęs „Aš nežinau“. Oho, jie pasamdė krūvą eruditų! Ir kai kuriose kultūrose paprastai labai pavojinga pasakyti „nežinau“ tai gali būti suvokiama kaip silpnumo ženklas. Taip pat yra organizacijų, kuriose, atvirkščiai, kiekvienas gali pasakyti „aš nežinau“. Ten tai visiškai legalu, o jei atsakydamas į klausimą kas nors pradeda šiukštauti, visiškai normalu atsakyti: „Tu nežinai, apie ką kalbi, tiesa? ir visa tai paversk pokštu.
Idealiu atveju norėtumėte turėti darbą, kuriame galėtumėte būti nuolat laimingi. Lengva nebus, ne kiekviena diena saulėta ir maloni, kartais reikia padirbėti, bet kai pradėsi vertinti, paaiškės: va, čia tikrai nuostabi vieta, jaučiuosi gerai čia dirbdama, tiek emociškai, tiek intelektualiai. O yra įmonių, kur eini kaip konsultantas ir akimirksniu supranti, kad tris mėnesius neištversi ir iš siaubo pabėgsi. Apie tai ir noriu pakalbėti pranešime.
Timas Listeris atvyks su pagrindiniu pranešimu į DevOops 2019 konferenciją, kuri vyks 29 metų spalio 30-2019 dienomis Sankt Peterburge. Galite nusipirkti bilietus . Laukiame jūsų DevOops!
Šaltinis: www.habr.com