“Vjerujemo jedno drugome. Na primjer, uopće nemamo plaće” - dugi intervju s Timom Listerom, autorom Peoplewarea

“Vjerujemo jedno drugome. Na primjer, uopće nemamo plaće” - dugi intervju s Timom Listerom, autorom Peoplewarea

Tim Lister - koautor knjiga

  • „Ljudski faktor. Uspješni projekti i timovi" (izvorna knjiga se zove "Peopleware")
  • "Valcer s medvjedima: Upravljanje rizikom u softverskim projektima"
  • “Zaluđeni adrenalinom i zombificirani šablonima. Obrasci ponašanja projektnih timova"

Sve ove knjige su klasici u svom području i napisane su u suradnji s kolegama u Atlantic Systems Guild. U Rusiji su njegovi kolege najpoznatiji - Tom DeMarco и Peter Hruschka, koji je također napisao mnoga poznata djela.

Tim ima 40 godina iskustva u razvoju softvera; 1975. (nitko od onih koji su napisali ovaj habrapost nije rođen ove godine), Tim je već bio izvršni potpredsjednik Yourdon Inc. Sada provodi svoje vrijeme savjetujući se, podučavajući i pišući, uz povremene posjete s izvješćima konferencije diljem svijeta.

Posebno za Habr napravili smo intervju s Timom Listerom. On će otvoriti DevOops 2019 konferenciju, a mi imamo puno pitanja, o knjigama i više. Razgovor vode Mikhail Družhinin i Oleg Chirukhin iz programskog odbora konferencije.

Michael: Možete li reći nekoliko riječi o tome čime se sada bavite?

Tim: Ja sam šef Atlantic Systems Guilda. U Cehu nas je šest, zovemo se principali. Tri u SAD-u i tri u Europi - zato se Ceh zove Atlantic. Toliko smo godina zajedno da ih jednostavno ne možete nabrojati. Svi mi imamo svoje posebnosti. Radim s klijentima zadnje desetljeće ili više. Moji projekti ne uključuju samo upravljanje, već i postavljanje zahtjeva, planiranje projekta i evaluaciju. Čini se da projekti koji započnu loše obično loše završe. Stoga vrijedi paziti da sve aktivnosti budu doista dobro osmišljene i usklađene, da su ideje kreatora spojene. Vrijedno je razmisliti o tome što radite i zašto. Koje strategije koristiti da biste doveli projekt do kraja.

Dugi niz godina savjetujem klijente na razne načine. Zanimljiv je primjer tvrtke koja proizvodi robote za operacije koljena i kukova. Kirurg ne operira potpuno samostalno, već koristi robota. Sigurnost je ovdje, iskreno govoreći, važna. Ali kada pokušate razgovarati o zahtjevima s ljudima koji su usredotočeni na rješavanje problema... Zvučat će čudno, ali u SAD-u postoji FDA (Federal Drug Administration), koja licencira proizvode poput ovih robota. Prije nego što bilo što prodate i upotrijebite na živim ljudima, morate dobiti licencu. Jedan od uvjeta je da pokažete svoje zahtjeve, koji su testovi, kako ste ih testirali, kakvi su rezultati testova. Ako promijenite zahtjeve, tada morate ponovno i ponovno prolaziti cijeli ovaj ogroman proces testiranja. Naši klijenti uspjeli su u svoje zahtjeve uvrstiti vizualni dizajn aplikacija. Imali su snimke zaslona izravno kao dio zahtjeva. Moramo ih izvući i objasniti da uglavnom svi ti programi ne znaju ništa o koljenima i kukovima, svim tim stvarima s kamerom itd. Moramo prepisati dokumente sa zahtjevima tako da se nikad ne mijenjaju, osim ako se ne promijene neki stvarno važni temeljni uvjeti. Ako vizualni dizajn nije u zahtjevima, ažuriranje proizvoda bit će mnogo brže. Naš posao je pronaći te elemente koji se bave operacijama koljena, kuka, leđa, izvući ih u posebne dokumente i reći da će to biti temeljni zahtjevi. Napravimo izoliranu skupinu zahtjeva o operacijama koljena. To će nam omogućiti da izgradimo stabilniji skup zahtjeva. Govorit ćemo o cjelokupnoj liniji proizvoda, a ne o konkretnim robotima.

Učinjeno je puno posla, ali su ipak stigli do mjesta na kojima su prethodno provodili tjedne i mjesece ponavljanih testova bez smisla i potrebe, jer se njihovi zahtjevi opisani na papiru nisu poklapali sa stvarnim zahtjevima za koje su sustavi izgrađeni. FDA im je svaki put rekla: vaši zahtjevi su se promijenili, sada morate provjeriti sve ispočetka. Potpune ponovne provjere cijelog proizvoda ubijale su poduzeće.

Dakle, postoje tako divni zadaci kada se nađete na samom početku nečeg zanimljivog, a prve radnje određuju daljnja pravila igre. Ako se uvjerite da ova rana aktivnost počne dobro funkcionirati i s menadžerske i s tehničke točke gledišta, postoji šansa da ćete završiti s izvrsnim projektom. Ali ako je ovaj dio skrenuo s tračnica i pošao negdje krivo, ako ne možete pronaći temeljne dogovore... ne, nije da će vaš projekt nužno propasti. Ali više nećete moći reći: “Bilo nam je super, sve smo napravili stvarno učinkovito.” To su stvari koje radim u komunikaciji s klijentima.

Michael: Odnosno, pokrenete projekte, napravite neku vrstu kickoffa i provjerite idu li tračnice u dobrom smjeru?

Tim: Također imamo ideje kako sastaviti sve dijelove slagalice: koje vještine su nam potrebne, kada su točno potrebne, kako izgleda jezgra tima i druge takve fundamentalne stvari. Trebamo li stalno zaposlene ili možemo zaposliti nekoga na pola radnog vremena? Planiranje, upravljanje. Pitanja poput: Što je najvažnije za ovaj projekt? Kako to postići? Što znamo o ovom proizvodu ili projektu, koji su rizici i gdje su nepoznanice, kako ćemo se sa svime time nositi? Naravno, u ovom trenutku netko počne vikati “A agile?!” U redu, svi ste fleksibilni, ali što onda? Kako točno izgleda projekt, kako ćete ga izvesti na način koji odgovara projektu? Ne možete samo reći da se "naš pristup proteže na sve, mi smo Scrum tim!" Ovo je besmislica i glupost. Gdje ćeš dalje, zašto bi to trebalo raditi, gdje je smisao? Učim svoje klijente razmišljati o svim tim pitanjima.

19 godina agila

Michael: U Agileu se ljudi često trude ne definirati ništa unaprijed, nego odluke donositi što kasnije, govoreći: preveliki smo, neću razmišljati o cjelokupnoj arhitekturi. Neću razmišljati o hrpi drugih stvari; umjesto toga, kupcu ću odmah isporučiti nešto što radi.

Tim: Mislim da agilne metodologije, počevši od Agilni manifest 2001. otvorio je oči industriji. Ali s druge strane, ništa nije savršeno. Ja sam za iterativni razvoj. Iteracija ima puno smisla u većini projekata. Ali pitanje o kojem trebate razmisliti je: kada je proizvod vani i u upotrebi, koliko dugo traje? Je li ovo proizvod koji će trajati šest mjeseci prije nego što bude zamijenjen nečim drugim? Ili je ovo proizvod koji će raditi mnogo, mnogo godina? Naravno, neću imenovati imena, ali... U New Yorku i njegovoj financijskoj zajednici, najtemeljniji sustavi su vrlo stari. Ovo je odlično. Gledate ih i mislite, kad biste se barem mogli vratiti u prošlost, u 1994., i reći programerima: “Došao sam iz budućnosti, iz 2019. godine. Samo razvijajte ovaj sustav onoliko dugo koliko vam je potrebno. Učinite ga proširivim, razmislite o arhitekturi. Zatim će se poboljšavati više od dvadeset i pet godina. Ako još malo odgodite razvoj, u velikoj shemi stvari nitko neće primijetiti!” Kada stvari procjenjujete dugoročno, morate uzeti u obzir koliko će to ukupno koštati. Ponekad se dobro osmišljena arhitektura doista isplati, a ponekad ne. Trebamo se osvrnuti oko sebe i zapitati se: jesmo li u pravoj situaciji za takvu odluku?

Dakle, ideja tipa “Mi smo za agile, kupac će nam sam reći što želi dobiti” – super je naivna. Kupci niti ne znaju što žele, a još više ne znaju što bi mogli dobiti. Neki će početi navoditi povijesne primjere kao argumente, to sam već vidio. Ali tehnički napredni ljudi to obično ne govore. Kažu: "2019. je, ovo su prilike koje imamo i možemo potpuno promijeniti način na koji gledamo na te stvari!" Umjesto da oponašate postojeća rješenja, učinite ih malo ljepšima i počešljanijima, ponekad morate izaći i reći: "Hajdemo u potpunosti izmisliti ono što ovdje pokušavamo učiniti!"

I ne mislim da većina kupaca može razmišljati o problemu na taj način. Oni vide samo ono što već imaju, to je sve. Nakon čega dolaze sa zahtjevima poput “ajmo ovo malo pojednostaviti,” ili što već obično kažu. Ali mi nismo konobari ni konobarice pa možemo primiti narudžbu koliko god glupa ispala i onda je ispeći u kuhinji. Mi smo njihovi vodiči. Moramo im otvoriti oči i reći: hej, imamo nove prilike! Shvaćate li da stvarno možemo promijeniti način na koji se ovaj dio vašeg poslovanja obavlja? Jedan od problema s Agileom je taj što uklanja svijest o tome što je prilika, što je problem, što uopće trebamo učiniti, koje su dostupne tehnologije najprikladnije za ovu konkretnu situaciju.

Možda sam ovdje previše skeptičan: u agilnoj zajednici događa se mnogo prekrasnih stvari. Ali imam problem što ljudi umjesto definiranja projekta počnu dizati ruke. Ja bih tu pitao – što radimo, kako ćemo? I uvijek nekako magično ispadne da bi klijent trebao znati bolje od svih. Ali klijent zna najbolje tek kada bira između stvari koje je netko već napravio. Ako želim kupiti auto i znam koliki je moj obiteljski budžet, onda ću brzo odabrati auto koji odgovara mom stilu života. Ovdje ja sve znam bolje od svih! Ali imajte na umu da je netko već napravio automobile. Nemam pojma kako izmisliti novi auto, nisam stručnjak. Kada izrađujemo proizvode po narudžbi ili posebne proizvode, moramo uzeti u obzir glas kupca, ali to više nije jedini glas.

Oleg: Spomenuli ste Agile Manifesto. Moramo li ga nekako ažurirati ili revidirati uzimajući u obzir moderno razumijevanje problema?

Tim: Ne bih ga dirao. Mislim da je to sjajan povijesni dokument. Mislim, on je ono što jest. Puni 19 godina, star je, ali u svoje vrijeme napravio je revoluciju. Ono što je dobro napravio je to što je izazvao reakciju i ljudi su počeli šaputati o njemu. Vi, najvjerojatnije, 2001. još niste radili u branši, ali tada su svi radili po procesima. Institut za softversko inženjerstvo, pet razina modela kompletnosti softvera (CMMI). Ne znam govore li vam takve legende duboke antike nešto, ali tada je to bio proboj. U početku su ljudi vjerovali da će problemi nestati sami od sebe ako su procesi ispravno postavljeni. A onda dolazi Manifest i kaže: "Ne, ne, ne - temeljit ćemo se na ljudima, a ne na procesima." Mi smo majstori razvoja softvera. Shvaćamo da je idealan proces fatamorgana; on se ne događa. Previše je idiosinkrazije u projektima, ideja o jednom savršenom procesu za sve projekte nema smisla. Problemi su previše složeni da bi se tvrdilo da za sve postoji samo jedno rješenje (zdravo, nirvana).

Ne usuđujem se gledati u budućnost, ali reći ću da su ljudi sada počeli više razmišljati o projektima. Mislim da je Agile Manifest vrlo dobar u iskakanju i kaže: "Hej! Vi ste na brodu i vi sami vozite ovaj brod. Morat ćete donijeti odluku - nećemo predložiti univerzalni recept za sve situacije. Vi ste posada broda i ako ste dovoljno dobri, možete pronaći put do cilja. Bilo je drugih brodova prije vas, a bit će i drugih brodova nakon vas, ali svejedno, u određenom smislu, vaše je putovanje jedinstveno.” Nešto kao to! To je način razmišljanja. Za mene nema ništa novo pod suncem, ljudi su već plovili i plovit će opet, ali za vas je ovo vaše glavno putovanje i neću vam reći što će vam se točno dogoditi. Morate imati vještine koordiniranog rada u timu, a ako ih zaista imate, sve će vam uspjeti i doći ćete kamo ste htjeli.

Peopleware: 30 godina kasnije

Oleg: Je li Peopleware bio revolucija kao i Manifest?

Tim: Peopleware... Tom i ja smo napisali ovu knjigu, ali nismo mislili da će se dogoditi ovako. Nekako je to odjekivalo s idejama mnogih ljudi. Ovo je bila prva knjiga koja je rekla: razvoj softvera je vrlo intenzivna ljudska aktivnost. Unatoč našoj tehničkoj prirodi, mi smo također zajednica ljudi koji grade nešto veliko, čak ogromno, vrlo složeno. Takve stvari nitko ne može stvoriti sam, zar ne? Tako je ideja "tima" postala vrlo važna. I to ne samo sa stajališta upravljanja, već i za tehničke ljude koji su se okupili kako bi riješili zaista složene duboke probleme s hrpom nepoznanica. Za mene osobno, ovo je bio veliki test inteligencije tijekom moje karijere. I tu treba znati reći: da, ovaj problem je više nego što sam mogu riješiti, ali zajedno možemo pronaći elegantno rješenje na koje možemo biti ponosni. I mislim da je ta ideja najviše odjeknula. Ideja da dio vremena radimo sami, dio vremena kao dio grupe, a često odluku donosi grupa. Grupno rješavanje problema brzo je postalo važna značajka složenih projekata.

Unatoč činjenici da je Tim održao ogroman broj predavanja, vrlo malo njih je objavljeno na YouTubeu. Možete pogledati izvještaj “Povratak Peoplewarea” iz 2007. godine. Kvaliteta, naravno, ostavlja mnogo za željeti.

Michael: Je li se što promijenilo u proteklih 30 godina otkako je knjiga objavljena?

Tim: Na ovo možete gledati iz mnogo različitih kutova. Sociološki gledano... nekada davno, u jednostavnijim vremenima, ti i tvoj tim sjedili ste u istom uredu. Mogli biste biti blizu svaki dan, zajedno piti kavu i razgovarati o poslu. Ono što se doista promijenilo je da timovi sada mogu biti raspoređeni geografski, u različitim zemljama i vremenskim zonama, ali i dalje rade na istom problemu, a to dodaje potpuno novi sloj složenosti. Ovo možda zvuči staromodno, ali ne postoji ništa poput komunikacije licem u lice gdje ste svi zajedno, radite zajedno, i možete prići kolegi i reći, vidi što sam otkrio, kako ti se ovo sviđa? Razgovori licem u lice omogućuju brzi način prelaska na neformalnu komunikaciju i mislim da bi se to trebalo svidjeti i agilnim entuzijastima. A brine me i to što je u stvarnosti svijet ispao jako malen, sad je sav prekriven raspodijeljenim timovima i sve je to jako složeno.

Svi živimo u DevOps-u

Michael: Čak i sa stajališta programskog odbora konferencije, imamo ljude u Kaliforniji, u New Yorku, Europi, Rusiji... u Singapuru još nema nikoga. Razlika u zemljopisu je prilično velika, a ljudi se počinju sve više širiti. Ako govorimo o razvoju, možete li nam reći nešto više o devopsu i rušenju barijera između timova? Postoji koncept da svi sjede u svojim bunkerima, a sada se bunkeri ruše, što mislite o toj analogiji?

Tim: Čini mi se da je u svjetlu nedavnih tehnoloških otkrića devops od velike važnosti. Prije ste imali timove developera i administratora, radili su, radili, radili i u jednom trenutku se pojavila stvar s kojom možete doći do admina i to izbaciti u produkciju. I tu je počeo razgovor o bunkeru, jer admini su nekakvi saveznici, barem ne neprijatelji, ali s njima se pričalo tek kad je sve bilo spremno za produkciju. Jeste li im otišli s nečim i rekli: pogledajte kakvu aplikaciju imamo, ali možete li pokrenuti ovu aplikaciju? A sada se cijeli koncept dostave promijenio na bolje. Mislim, postojala je ideja da možete brzo progurati promjene. Proizvode možemo ažurirati u hodu. Uvijek se nasmiješim kada se Firefox na mom prijenosnom računalu pojavi i kaže, hej, ažurirali smo vaš Firefox u pozadini, i čim budete imali minutu, možete li kliknuti ovdje i mi ćemo vam dati najnovije izdanje. A ja sam rekao: "O da, dušo!" Dok sam spavao, radili su na tome da mi isporuče novo izdanje direktno na moje računalo. Ovo je divno, nevjerojatno.

Ali ovdje je poteškoća: imate ovu značajku s ažuriranjem softvera, ali integracija ljudi je puno teža. Ono što želim reći na uvodnom govoru DevOopsa je da sada imamo mnogo više igrača nego što smo ikada imali. Ako samo pomislite na sve uključene u samo jedan tim…. Zamišljali ste to kao tim, a to je mnogo više od običnog tima programera. To su testeri, voditelji projekata i hrpa drugih ljudi. I svatko ima svoje poglede na svijet. Voditelji proizvoda potpuno su različiti od voditelja projekata. Admini imaju svoje zadatke. Postaje prilično težak problem uskladiti sve sudionike kako bi i dalje bili svjesni onoga što se događa i ne poludjeli. Potrebno je razdvojiti zadatke grupe i zadatke koji se odnose na sve. Ovo je vrlo težak zadatak. S druge strane, mislim da je sve puno bolje nego što je bilo prije mnogo godina. Upravo je to put na kojem ljudi rastu i uče se ispravno ponašati. Kada radite integraciju, shvaćate da ne bi trebalo biti podzemnog razvoja, tako da u zadnjem trenutku softver ne ispuzi poput utičnice u kutiji: kao, pogledajte što smo ovdje napravili! Ideja je da ćete moći napraviti integraciju i razvoj, a na kraju ćete se razviti na uredan i iterativan način. Sve ovo mi puno znači. To omogućuje stvaranje veće vrijednosti za korisnike sustava i za vašeg klijenta.

Michael: Cjelokupna ideja devopsa je isporučiti značajne razvoje što je ranije moguće. Vidim da se svijet sve više počeo ubrzavati. Kako se prilagoditi takvim ubrzanjima? Prije deset godina ovo nije postojalo!

Tim: Naravno, svi žele sve više i više funkcionalnosti. Nema potrebe za pomicanjem, samo nagomilajte više. Ponekad čak morate usporiti za sljedeće inkrementalno ažuriranje kako biste donijeli bilo što korisno - i to je potpuno normalno.

Ideja da trebate trčati, trčati, trčati nije najbolja. Malo je vjerojatno da itko želi tako živjeti svoj život. Volio bih da ritam isporuka određuje vlastiti ritam projekta. Ako samo proizvedete niz malih, relativno besmislenih stvari, sve to ne znači ništa. Umjesto bezumnog pokušaja objavljivanja stvari što je prije moguće, ono o čemu vrijedi razgovarati s vodećim programerima i voditeljima proizvoda i projekata jest strategija. Ima li ovo uopće smisla?

Uzorci i antiuzorci

Oleg: Obično se govori o uzorcima i antipatternima, a to je razlika između života i smrti projekata. A sada, devops upada u naše živote. Ima li neke svoje obrasce i anti-šablone koji mogu ubiti projekt na licu mjesta?

Tim: Obrasci i anti-obrasci događaju se cijelo vrijeme. Nešto za razgovor. Pa, postoji nešto što zovemo "sjajne stvari". Ljudi stvarno, jako vole novu tehnologiju. Jednostavno su hipnotizirani sjajem svega što izgleda cool i stilski i prestaju postavljati pitanja: je li to uopće potrebno? Što ćemo postići? Je li ova stvar pouzdana, ima li smisla? Često vidim ljude, da tako kažem, na vrhuncu tehnologije. Hipnotizirani su onim što se događa u svijetu. Ali ako bolje pogledate što sve korisno rade, često jednostavno nema ničeg korisnog!

Upravo smo razgovarali s našim drugovima da je ova godina obljetnica, pedeset godina otkako su ljudi sletjeli na Mjesec. To je bilo 1969. Tehnologija koja je pomogla ljudima da tamo stignu nije čak ni tehnologija iz 1969., nego prije 1960. ili 62., jer je NASA htjela koristiti samo ono što ima dobre dokaze pouzdanosti. I tako pogledate i shvatite - da, i bile su istinite! Sada, ne, ne, ali upadate u probleme s tehnologijom jednostavno zato što se sve previše forsira, prodaje iz svih pukotina. Ljudi odasvud viču: "Gle, kakva stvar, ovo je nešto najnovije, najljepše na svijetu, za apsolutno svakoga!" E, to je to... obično se sve ovo pokaže samo kao mamac i onda se sve to mora baciti. Možda je to sve zato što sam već star čovjek i gledam na takve stvari s velikom dozom skepse, kad ljudi istrče i kažu da su pronašli jedini, najispravniji način za stvaranje najboljih tehnologija. U tom trenutku u meni se budi glas koji kaže: “Kakav nered!”

Michael: Doista, koliko smo često čuli za sljedeći srebrni metak?

Tim: Upravo tako, i to je uobičajeni tijek stvari! Na primjer... čini se da je ovo već postala šala u svijetu, ali kod nas se često priča o blockchain tehnologiji. I zapravo imaju smisla u određenim situacijama! Kada stvarno trebate pouzdane dokaze o događajima, da sustav radi i da nas nitko nije prevario, kada imate sigurnosnih problema i sve te stvari pomiješane - blockchain ima smisla. Ali kada kažu da će Blockchain sada pomesti cijeli svijet, čisteći sve što mu se nađe na putu? Sanjajte više! Ovo je vrlo skupa i složena tehnologija. Tehnički složeno i dugotrajno. Uključujući i čisto algoritamski, svaki put kad trebate ponovno izračunati matematiku, s najmanjim promjenama... i to je sjajna ideja - ali samo za određene slučajeve. Cijeli moj život i karijera bili su oko toga: zanimljive ideje u vrlo specifičnim situacijama. Vrlo je važno razumjeti točno kakva je vaša situacija.

Michael: Da, glavno "pitanje života, svemira i svega": je li ova tehnologija ili pristup prikladan za vašu situaciju ili ne?

Tim: O ovom pitanju se već može razgovarati s tehnološkom grupom. Možda čak dovesti nekog konzultanta. Pogledajte projekt i shvatite - hoćemo li sada učiniti nešto ispravno i korisno, bolje nego prije? Možda će odgovarati, možda neće. Ali što je najvažnije, nemojte donijeti takvu odluku prema zadanim postavkama, samo zato što je netko izlanuo: “Očajnički nam treba blockchain! Upravo sam čitao o njemu u časopisu u avionu!” Ozbiljno? Nije čak ni smiješno.

Mitski "devops inženjer"

Oleg: Sada svi implementiraju devops. Netko čita o devopsima na internetu, a sutra se na mjestu za zapošljavanje pojavi još jedno slobodno mjesto. "devops inženjer". Ovdje bih vam želio skrenuti pozornost: mislite li da ovaj izraz, "devops inženjer", ima pravo na život? Postoji mišljenje da je devops kultura i tu nešto ne štima.

Tim: Tako tako. Neka onda odmah daju neko objašnjenje ovog pojma. Nešto što ga čini jedinstvenim. Sve dok ne dokažu da postoji neka jedinstvena kombinacija vještina iza ovakvog natječaja, neću ga prihvatiti! Mislim, pa, imamo naziv posla, "devops inženjer", zanimljiv naziv, da, što dalje? Nazivi poslova općenito su vrlo zanimljiva stvar. Recimo "programer" - što je to uopće? Različite organizacije znače potpuno različite stvari. U nekim tvrtkama visokokvalitetni programeri pišu testove koji imaju više smisla od testova koje pišu posebni profesionalni testeri u drugim tvrtkama. Pa što, jesu li oni sada programeri ili testeri?

Da, imamo nazive poslova, ali ako dovoljno dugo postavljate pitanja, na kraju ispadne da svi rješavamo probleme. Mi smo tražitelji rješenja, a neki imaju neke tehničke vještine, a neki imaju drugačije. Ako živite u okruženju u koje je DevOps prodro, bavite se integracijom razvoja i administracije, a ta aktivnost ima neku prilično važnu svrhu. Ali ako vas se pita što točno radite i za što ste odgovorni, ispada da su ljudi sve to radili od pamtivijeka. "Ja sam odgovoran za arhitekturu", "Ja sam odgovoran za baze podataka" i tako dalje, što god, vidite - sve je to bilo prije "devopsa".

Kad mi netko kaže svoj posao, ne slušam ga previše. Bolje je dopustiti mu da vam kaže za što je zapravo odgovoran, to će nam omogućiti da bolje razumijemo problem. Moj omiljeni primjer je kada osoba tvrdi da je "projekt menadžer". Što? Ne znači ništa, još uvijek ne znam što radiš. Project manager može biti developer, vođa tima od četvero ljudi, koji piše kod, radi posao, koji je postao team lead, kojeg ljudi sami među sobom prepoznaju kao vođu. A također, voditelj projekta može biti menadžer koji upravlja šest stotina ljudi na projektu, upravlja drugim menadžerima, odgovoran je za izradu rasporeda i planiranje budžeta, to je sve. To su dva potpuno različita svijeta! Ali naziv njihovog posla zvuči isto.

Okrenimo ovo malo drugačije. U čemu ste stvarno dobri, imate puno iskustva, imate li talenta? Za što ćete preuzeti odgovornost jer mislite da se možete nositi sa zadatkom? I tu će netko odmah početi negirati: ne, ne, ne, ja se uopće nemam volje baviti resursima projekta, to nije moja stvar, ja sam tehnički tip i razumijem se u upotrebljivost i korisnička sučelja, ne uopće želim upravljati vojskama ljudi, bolje me pusti na posao.

Usput, veliki sam zagovornik pristupa u kojem ova vrsta odvajanja vještina dobro funkcionira. Gdje tehničari mogu razvijati svoje karijere koliko žele. Međutim, još uvijek vidim organizacije u kojima se tehničari žale: morat ću ići u projektni menadžment jer je to jedini način u ovoj tvrtki. Ponekad to dovodi do užasnih ishoda. Najbolji tehničari uopće nisu dobri menadžeri, a najbolji menadžeri se ne mogu nositi s tehnologijom. Budimo iskreni u vezi ovoga.

Sada vidim veliku potražnju za ovim. Ako ste stručnjak za tehnologiju, vaša vam tvrtka može pomoći, ali bez obzira na to, trebate, stvarno morate pronaći svoj vlastiti put u karijeri jer se tehnologija neprestano mijenja i vi morate iznova izumiti sebe zajedno s njom! U samo dvadeset godina tehnologije se mogu promijeniti najmanje pet puta. Tehnologija je čudna stvar...

"Stručnjaci za sve"

Michael: Kako se ljudi mogu nositi s takvom brzinom tehnoloških promjena? Njihova kompleksnost raste, njihov broj raste, ukupna količina komunikacije među ljudima također raste, a ispada da se ne može postati “stručnjak za sve”.

Tim: Pravo! Ako se bavite tehnologijom, da, svakako trebate odabrati nešto specifično i udubiti se u to. Neka tehnologija koju vaša organizacija smatra korisnom (i možda će zaista biti korisna). A ako vas to više ne zanima - nikada ne bih vjerovao da ću ovo reći - pa, možda biste se trebali preseliti u neku drugu organizaciju gdje je tehnologija zanimljivija ili praktičnija za proučavanje.

Ali općenito, da, u pravu ste. Tehnologije rastu u svim smjerovima odjednom; nitko ne može reći "Ja sam stručnjak tehnolog za sve tehnologije koje postoje." S druge strane, postoje spužvari koji doslovno upijaju tehnološka znanja i ludi su za njima. Vidio sam par takvih ljudi, doslovno to dišu i žive, s njima je korisno i zanimljivo razgovarati. Proučavaju ne samo ono što se događa unutar organizacije, nego općenito govore o tome, također su stvarno cool tehnolozi, vrlo su svjesni i svrhoviti. Oni samo pokušavaju ostati na vrhuncu vala, bez obzira na to što im je glavni posao, jer njihova je strast kretanje tehnologije, promicanje tehnologije. Ako iznenada sretnete takvu osobu, trebali biste otići s njim na ručak i za ručkom razgovarati o raznim cool stvarima. Mislim da svaka organizacija treba barem par takvih ljudi.

Rizici i neizvjesnost

Michael: Poštovani inženjeri, da. Dotaknimo se upravljanja rizikom dok imamo vremena. Ovaj intervju započeli smo raspravom o medicinskom softveru, gdje pogreške mogu dovesti do strašnih posljedica. Zatim smo razgovarali o Lunarnom programu, gdje je cijena pogreške milijune dolara, a moguće i nekoliko ljudskih života. Ali sada vidim suprotno kretanje u industriji, ljudi ne razmišljaju o rizicima, ne pokušavaju ih predvidjeti, čak ih niti ne promatraju.

Oleg: Brzo se kreći i razbijaj stvari!

Michael: Da, kreći se brzo, lomi stvari, sve više i više stvari, dok ne umreš od nečega. S vašeg stajališta, kako bi prosječni programer sada trebao pristupiti upravljanju rizikom učenja?

Tim: Povucimo crtu između dvije stvari: rizika i neizvjesnosti. To su različite stvari. Nesigurnost se javlja kada u bilo kojem trenutku nemate dovoljno podataka da biste došli do konačnog odgovora. Na primjer, u vrlo ranoj fazi projekta, ako vas netko pita "kada ćete završiti posao", ako ste prilično iskrena osoba, reći ćete: "Nemam pojma." Jednostavno ne znaš, i to je u redu. Još niste proučili probleme i niste upoznati s timom, ne poznajete njihove vještine i tako dalje. Ovo je neizvjesnost.

Rizici nastaju kada se potencijalni problemi već mogu identificirati. Takvo što se može dogoditi, vjerojatnost je veća od nule, ali manja od sto posto, negdje između. Zbog toga se može dogoditi svašta, od kašnjenja i nepotrebnog rada, pa čak i do kobnog ishoda za projekt. Ishod, kad kažete - ljudi, ajmo sklopiti suncobrane i otići s plaže, nikad je nećemo završiti, sve je gotovo i točka. Pretpostavljali smo da će ova stvar funkcionirati, ali nikako ne funkcionira, vrijeme je da prestanemo. Ovo su situacije.

Često je probleme najlakše riješiti kada su se već pojavili, kada se problem događa upravo sada. Ali kada je problem točno ispred vas, ne bavite se upravljanjem rizikom - bavite se rješavanjem problema, upravljanjem kriznim situacijama. Ako ste glavni programer ili menadžer, sigurno se pitate što bi se moglo dogoditi što bi dovelo do kašnjenja, izgubljenog vremena, nepotrebnih troškova ili propasti cijelog projekta? Što će nas natjerati da stanemo i počnemo ispočetka? Kad sve te stvari prorade, što ćemo s njima? Postoji jednostavan odgovor koji vrijedi za većinu situacija: ne bježite od rizika, radite na njima. Pogledajte kako možete riješiti rizičnu situaciju, svesti je na ništa, pretvoriti je iz problema u nešto drugo. Umjesto da kažemo: dobro, rješavat ćemo probleme kako budu nastajali.

Neizvjesnost i rizik trebali bi biti u prvom planu svega čime se bavite. Možete uzeti plan projekta, pogledati određene kritične rizike unaprijed i reći: moramo se pozabaviti ovim sada, jer ako bilo što od ovoga pođe po zlu, ništa drugo neće biti važno. Ne biste trebali brinuti o ljepoti stolnjaka na stolu ako nije jasno možete li kuhati večeru. Najprije treba identificirati sve rizike pripreme ukusne večere, nositi se s njima, a tek onda razmišljati o svim ostalim stvarima koje ne predstavljaju stvarnu prijetnju.

Opet, što vaš projekt čini jedinstvenim? Pogledajmo što može učiniti da naš projekt nestane. Što možemo učiniti da smanjimo vjerojatnost da se to dogodi? Obično ih ne možete jednostavno neutralizirati 100% i mirne savjesti izjaviti: "To je to, to više nije problem, rizik je nestao!" Za mene je to znak odraslog ponašanja. To je razlika između djeteta i odrasle osobe - djeca misle da su besmrtna, da ništa ne može poći po zlu, sve će biti dobro! Pritom odrasli promatraju kako trogodišnja djeca skakuću po igralištu, pogledom prate pokrete i govore sebi: „oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooh Stojim u blizini i spremam se uhvatiti kad dijete padne.

S druge strane, razlog zašto toliko volim ovaj posao je taj što je riskantan. Radimo stvari, a te stvari su riskantne. Oni zahtijevaju pristup odrasle osobe. Sam entuzijazam neće riješiti vaše probleme!

Inženjersko razmišljanje odraslih

Michael: Primjer s djecom je dobar. Ako sam običan inženjer, onda mi je drago što sam dijete. Ali kako krenuti prema odraslijem razmišljanju?

Tim: Jedna od ideja koja podjednako dobro funkcionira i kod početnika i kod etabliranog programera je koncept konteksta. Što radimo, što ćemo postići. Što je zapravo važno u ovom projektu? Nije važno tko ste na ovom projektu, jeste li pripravnik ili glavni arhitekt, svima je potreban kontekst. Moramo natjerati svakoga da razmišlja na širem planu od vlastitih djela. "Ja radim svoj dio, i sve dok moj dio radi, sretan sam." Ne i opet ne. Uvijek je vrijedno (bez nepristojnosti!) podsjetiti ljude na kontekst u kojem rade. Ono što svi zajedno pokušavamo postići. Ideje da možeš biti dijete sve dok je sve u redu s tvojim dijelom projekta - molim te, nemoj to raditi. Ako uopće prođemo kroz cilj, proći ćemo ga samo zajedno. Niste sami, svi smo zajedno. Kada bi svi ljudi u projektu, i stari i mladi, počeli pričati o tome što je točno važno za projekt, zašto tvrtka ulaže novac u ono što svi mi pokušavamo postići... većina njih će se osjećati puno bolje jer vidjet će kako je njihov rad u korelaciji s radom svih ostalih. S jedne strane, razumijem komad za koji sam osobno odgovoran. Ali da završimo posao potrebni su nam i svi ostali ljudi. A ako stvarno mislite da ste gotovi, uvijek imamo posla u projektu!

Oleg: Relativno govoreći, ako radite po Kanbanu, kada naletite na usko grlo nekog testiranja, možete odustati od onoga što ste tamo radili (npr. programirati) i otići pomoći testerima.

Tim: Točno. Mislim da su najbolji tehničari, ako ih bolje pogledate, sami sebi menadžeri. Kako da ovo formuliram...

Oleg: Vaš život je vaš projekt, kojim vi upravljate.

Tim: Točno! Mislim, preuzimaš odgovornost, razumiješ problem i dolaziš u kontakt s ljudima kada vidiš da tvoje odluke mogu utjecati na njihov rad, takve stvari. Ne radi se samo o tome da sjedite za svojim stolom, radite svoj posao, a da uopće ne shvaćate što se događa oko vas. Ne ne ne. Inače, jedna od najboljih stvari kod Agilea je što su predložili kratke sprinteve, jer se na taj način jasno vidi stanje svih sudionika, oni to sve zajedno vide. Pričamo jedno o drugom svaki dan.

Kako ući u upravljanje rizikom

Oleg: Postoji li formalna struktura znanja u ovom području? Na primjer, ja sam Java programer i želim razumjeti upravljanje rizikom, a da ne postanem pravi voditelj projekta po obrazovanju. Vjerojatno ću prvo pročitati McConnellov "How Much Does a Software Project Cost" i što onda? Koji su prvi koraci?

Tim: Prvi je započeti komunikaciju s ljudima u projektu. Time se trenutno poboljšava kultura komunikacije s kolegama. Moramo započeti s otvaranjem svega prema zadanim postavkama, umjesto skrivanja. Reci: to su stvari koje me muče, to su stvari zbog kojih ne spavam noću, danas sam se probudio noću i rekao sam: moj Bože, moram razmisliti o ovome! Vide li i drugi to isto? Trebamo li kao grupa odgovoriti na te potencijalne probleme? Morate biti u mogućnosti podržati raspravu o ovim temama. Ne postoji unaprijed pripremljena formula po kojoj radimo. Ne radi se o pravljenju hamburgera, već o ljudima. “Napravio čizburger, prodaj čizburger” uopće nije naša stvar i zato toliko volim ovaj posao. Volim kada sve što su menadžeri radili sada postane vlasništvo tima.

Oleg: U knjigama i intervjuima govorili ste o tome kako je ljudima više stalo do sreće nego do brojeva na grafikonu. S druge strane, kada timu kažete: prelazimo na devops, a sada programer mora stalno komunicirati, to može biti daleko izvan njegove zone komfora. I u ovom trenutku može, recimo, biti duboko nesretan. Što učiniti u ovoj situaciji?

Tim: Nisam siguran što točno učiniti. Ako je programer previše izoliran, oni uopće ne vide zašto se posao obavlja, oni samo gledaju svoj dio posla i trebaju ući u ono što ja zovem "kontekst". Mora shvatiti kako je sve povezano. I naravno, ne mislim na formalne prezentacije ili nešto slično. Govorim o tome da s kolegama treba komunicirati o poslu u cjelini, a ne samo o onom dijelu za koji ste odgovorni. Ovo je mjesto gdje možete početi raspravljati o idejama, zajedničkim dogovorima kako bi se vaš posao dobro uklopio i kako zajedno riješiti zajednički problem.

Kako bi im pomogli u prilagodbi, često žele poslati tehničare na obuku i razgovaraju o obuci. Jedan moj prijatelj voli reći da je dresura za pse. Postoji obuka za ljude. Jedna od najboljih stvari kod učenja kao programera je interakcija s kolegama. Ako je netko stvarno dobar u nečemu, trebali biste ga gledati kako radi ili razgovarati s njim o njegovom poslu ili tako nešto. Neki konvencionalni Kent Beck stalno je govorio o ekstremnom programiranju. Smiješno je jer je XP tako jednostavna ideja, ali uzrokuje toliko problema. Za neke je obavljanje XP-a kao da ste prisiljeni skinuti se goli pred prijateljima. Vidjet će oni što radim! Oni su moji kolege, oni će ne samo vidjeti, nego i razumjeti! Strašno! Neki ljudi počinju biti ozbiljno nervozni. Ali kada shvatite da je to najbolji način učenja, sve se mijenja. Blisko surađujete s ljudima, a neki ljudi razumiju temu puno bolje od vas.

Michael: Ali sve vas to tjera da izađete iz svoje zone komfora. Kao inženjer, morate izaći iz svoje zone udobnosti i komunicirati. Kao osoba koja rješava probleme, morate se stalno stavljati u slabu poziciju i razmišljati o tome što bi moglo poći po zlu. Ova vrsta posla je inherentno osmišljena da bude smetnja. Svjesno se dovodite u stresne situacije. Obično ljudi bježe od njih, ljudi vole biti sretna djeca.

Tim: Što se može, možete izaći i otvoreno reći: “Sve je u redu, mogu ja to! Nisam jedini koji se osjeća neugodno. Raspravljajmo o raznim neugodnim stvarima, svi zajedno, timski!” To su naši zajednički problemi, moramo se nositi s njima, znaš? Mislim da su idiosinkratični genijalni programeri poput mamuta, nestali su. A njihov značaj je vrlo ograničen. Ako ne možete komunicirati, ne možete dobro sudjelovati. Zato, samo govori. Budite iskreni i otvoreni. Jako mi je žao što je ovo nekome neugodno. Možete li zamisliti, prije mnogo godina postojala je studija prema kojoj glavni strah u Sjedinjenim Državama nije smrt, ali pogodite što? Strah od javnog nastupa! To znači da negdje postoje ljudi koji bi radije umrli nego rekli kompliment naglas. I mislim da je dovoljno da imate neke osnovne vještine, ovisno o tome čime se bavite. Govorne vještine, vještine pisanja – ali samo onoliko koliko vam je stvarno potrebno u poslu. Ako radite kao analitičar, ali ne znate čitati, pisati ili govoriti, tada, nažalost, nećete imati što raditi u mojim projektima!

Cijena komunikacije

Oleg: Nije li zapošljavanje takvih zaposlenika na odlasku iz raznih razloga skuplje? Uostalom, oni stalno čavrljaju umjesto da rade!

Tim: Mislio sam na jezgru ekipe, a ne na sve. Ako imate nekoga tko je stvarno super u podešavanju baza podataka, voli podešavati baze podataka i nastavit će podešavati vaše baze podataka do kraja života i to je to, super, samo tako nastavite. Ali ja govorim o ljudima koji žele živjeti u samom projektu. Jezgra tima usmjerena na razvoj projekta. Ovi ljudi stvarno trebaju stalno komunicirati jedni s drugima. A posebno na početku projekta, kada razgovarate o rizicima, načinima postizanja globalnih ciljeva i slično.

Michael: To se odnosi na sve uključene u projekt, bez obzira na specijalizaciju, vještine ili način rada. Svi ste zainteresirani za uspjeh projekta.

Tim: Da, osjećate da ste dovoljno uronjeni u projekt, da je vaš zadatak pomoći da se projekt ostvari. Bilo da ste programer, analitičar, dizajner sučelja, bilo tko. To je razlog zašto svako jutro dolazim na posao i to je ono što radimo. Mi smo odgovorni za sve te ljude, bez obzira na njihove vještine. Ovo je skupina ljudi koji vode razgovore za odrasle.

Oleg: Zapravo, govoreći o pričljivim zaposlenicima, pokušao sam simulirati prigovore ljudi, posebno menadžera, od kojih se traži da prijeđu na devops, na tu potpuno novu viziju svijeta. A vi, kao konzultanti, trebali biste biti svjesni ovih prigovora puno bolje od mene, kao programera! Podijelite što najviše brine menadžere?

Tim: Menadžeri? Hm. Najčešće su menadžeri pod pritiskom problema, suočeni s potrebom da nešto hitno otpuste i izvrše isporuku i slično. Gledaju kako stalno raspravljamo i svađamo se oko nečega, a vide to ovako: razgovori, razgovori, razgovori... Kakvi još razgovori? Vrati se na posao! Jer im razgovor ne djeluje kao posao. Ne pišete kod, ne testirate softver, čini se da ništa ne radite - zašto vas ne pošalju da nešto učinite? Uostalom, isporuka je već za mjesec dana!

Michael: Idi napiši neki kod!

Tim: Čini mi se da ih ne brine posao, nego nevidljivost napretka. Da bi se činilo da smo sve bliže uspjehu, moraju nas vidjeti kako pritiskamo gumbe na tipkovnici. Cijeli dan od jutra do večeri. Ovo je problem broj jedan.

Oleg: Misha, razmišljaš o nečemu.

Michael: Oprostite, izgubio sam se u mislima i uhvatio flashback. Sve me to podsjetilo na jedan zanimljiv skup koji se dogodio jučer... Jučer je bilo previše skupova... I sve to zvuči vrlo poznato!

Život bez plaća

Tim: Usput, uopće nije potrebno organizirati "skupove" za komunikaciju. Mislim, najkorisnije rasprave između programera događaju se kada samo razgovaraju jedni s drugima. Uđete ujutro sa šalicom kave, a petero ljudi se okupilo i bijesno raspravlja o nečem tehničkom. Za mene, ako sam ja voditelj ovog projekta, bolje je da se samo nasmiješim i odem nekamo svojim poslom, neka oni razgovaraju o tome. Već su uključeni koliko god je to moguće. Ovo je dobar znak.

Oleg: Inače, u svojoj knjizi imate hrpu bilješki o tome što je dobro, a što loše. Koristite li i sami neke od njih? Relativno govoreći, sada imate tvrtku, i to jednu koja je strukturirana na vrlo neortodoksan način...

Tim: Neortodoksno, ali ovaj uređaj nam savršeno odgovara. Dugo se poznajemo. Vjerujemo jedno drugome, puno smo vjerovali jedno drugom prije nego smo postali partneri. A na primjer, nemamo nikakve plaće. Mi samo radimo, a na primjer, ako sam zaradio od svojih klijenata, onda je sav novac otišao meni. Nakon toga plaćamo članarinu organizaciji, a to je dovoljno za uzdržavanje same tvrtke. Osim toga, svi smo specijalizirani za različite stvari. Recimo, radim s računovođama, ispunjavam porezne prijave, radim svakakve administrativne poslove za tvrtku, a nitko me za to ne plaća. James i Tom rade na našoj web stranici i nitko ih također ne plaća. Sve dok plaćate svoje obveze, nitko neće pomisliti govoriti vam što trebate učiniti. Na primjer, Tom sada radi mnogo manje nego nekada. Sada ima druge interese; radi neke stvari ne za ceh. Ali sve dok plaća svoje obveze, nitko mu neće prići i reći: "Hej, Tome, idi na posao!" Vrlo je lako izaći na kraj s kolegama kada između vas nema novca. I sada je naš odnos jedna od temeljnih ideja u odnosu na različite specijalnosti. Djeluje i to jako dobro.

Najbolji savjet

Michael: Da se vratimo na "najbolji savjet", postoji li nešto što uvijek iznova govorite svojim klijentima? Postoji ideja o 80/20, a neki se savjeti vjerojatno češće ponavljaju.

Tim: Jednom sam mislio da ako napišete knjigu poput Valcera s medvjedima, to će promijeniti tijek povijesti i ljudi će stati, ali... Pa, gledajte, kompanije se često prave da je s njima sve u redu. Čim se nešto loše dogodi, za njih je to šok i iznenađenje. “Gledajte, testirali smo sustav i ne prolazi nijedan test sustava, a ovo su još tri mjeseca neplanskog rada, kako se to moglo dogoditi? Tko je znao? Što bi moglo poći po zlu? Ozbiljno, vjeruješ li u ovo?

Pokušavam objasniti da se ne biste trebali previše ljutiti zbog trenutne situacije. Moramo razgovarati o tome, stvarno razumjeti što je moglo poći po zlu i kako spriječiti da se takve stvari dogode u budućnosti. Ako se problem pojavi, kako ćemo se boriti protiv njega, kako ćemo ga obuzdati?

Meni sve ovo izgleda zastrašujuće. Ljudi se nose sa složenim, mučnim problemima i nastavljaju se pretvarati da će se "najbolje" stvarno dogoditi ako samo ukrste palčeve i nadaju se najboljem. Ne, to ne ide tako.

Vježbajte upravljanje rizikom!

Michael: Po vašem mišljenju, koliko se organizacija bavi upravljanjem rizicima?

Tim: Ljuti me što ljudi jednostavno zapišu rizike, pogledaju dobivenu listu i krenu na posao. Zapravo, prepoznavanje rizika za njih je upravljanje rizikom. Ali meni ovo zvuči kao razlog za pitanje: dobro, postoji popis, što ćete točno promijeniti? Morate promijeniti svoje standardne redoslijede radnji uzimajući u obzir te rizike. Ako postoji neki najteži dio posla, treba ga se uhvatiti u koštac, pa tek onda prijeći na nešto jednostavnije. U prvim sprintevima počnite rješavati složene probleme. Ovo već izgleda kao upravljanje rizikom. Ali obično ljudi ne mogu reći što su promijenili nakon sastavljanja popisa rizika.

Michael: Pa ipak, koliko je tih tvrtki uključeno u upravljanje rizicima, pet posto?

Tim: Nažalost, mrzim to reći, ali ovo je vrlo beznačajan dio. Ali više od pet, jer postoje stvarno veliki projekti, a oni jednostavno ne mogu postojati ako se barem nešto ne napravi. Recimo samo da ću se jako iznenaditi ako bude barem 25%. Mali projekti obično na takva pitanja odgovaraju ovako: ako nas problem pogađa, onda ćemo ga riješiti. Tada se uspješno uvlače u probleme i bave se upravljanjem problemima i upravljanjem krizama. Kada pokušate riješiti problem, a problem nije riješen, dobrodošli u krizni menadžment.

Da, često čujem, "riješit ćemo probleme kako se pojave." Sigurno hoćemo? Hoćemo li se stvarno odlučiti?

Oleg: Možete to učiniti naivno i jednostavno upisati važne invarijante u projektnu povelju, a ako se invarijante pokvare, samo ponovno pokrenite projekt. Ispada vrlo piembucky.

Michael: Da, dogodilo mi se da kada se pokrenu rizici, projekt se jednostavno redefinira. Bravo, bingo, problem riješen, ne brini više!

Tim: Pritisnimo tipku za resetiranje! Ne, to ne ide tako.

Keynote na DevOops 2019

Michael: Dolazimo do posljednjeg pitanja ovog intervjua. Dolazite na sljedeći DevOops s keynoteom, možete li podići zavjesu tajnosti o onome što ćete ispričati?

Tim: Upravo sada njih šestero piše knjigu o kulturi rada, neizgovorenim pravilima organizacija. Kultura je određena temeljnim vrijednostima organizacije. Obično ljudi to ne primjećuju, ali budući da smo godinama radili u savjetovanju, navikli smo to primjećivati. Uđete u tvrtku i doslovno za nekoliko minuta počnete osjećati što se događa. To zovemo "okus". Ponekad je ovaj miris jako dobar, a ponekad je, pa, ups. Stvari su vrlo različite za različite organizacije.

Michael: I ja se godinama bavim konzaltingom i dobro razumijem o čemu govorite.

Tim: Zapravo, jedna od stvari o kojoj vrijedi govoriti na uvodnoj riječi je da nije sve određeno poduzećem. Vi i vaš tim, kao zajednica, imate vlastitu timsku kulturu. To može biti cijela tvrtka, ili poseban odjel, zasebni tim. Ali prije nego što ste rekli, evo u što vjerujemo, evo što je važno... Ne možete promijeniti kulturu prije nego što se shvate vrijednosti i uvjerenja koja stoje iza određenih postupaka. Lako je promatrati ponašanje, ali teško je tražiti uvjerenja. DevOps je samo izvrstan primjer kako stvari postaju sve složenije. Interakcije postaju samo složenije, ne postaju nimalo čišće i jasnije, pa razmislite o tome u što vjerujete, a o čemu svi oko vas šute.

Ako želite postići brze rezultate, evo dobre teme za vas: jeste li vidjeli tvrtke u kojima nitko ne kaže "ne znam"? Ima mjesta gdje čovjeka doslovno mučiš dok ne prizna da nešto ne zna. Svi sve znaju, svi su nevjerojatni eruditi. Priđete bilo kojoj osobi, a ona mora odmah odgovoriti na pitanje. Umjesto da kažete "Ne znam". Hura, zaposlili hrpu erudita! A u nekim je kulturama općenito vrlo opasno reći "ne znam"; to se može shvatiti kao znak slabosti. Postoje i organizacije u kojima, naprotiv, svatko može reći "ne znam". Tamo je to potpuno legalno, a ako netko počne brbljati na pitanje, sasvim je normalno odgovoriti: “Ne znaš o čemu pričaš, zar ne?” i sve to okrenuti na šalu.

U idealnom slučaju, željeli biste imati posao na kojem biste mogli biti stalno sretni. Neće biti lako, nije svaki dan sunčan i ugodan, ponekad se treba potruditi, ali kad počneš svoditi račune, ispast će: vau, ovo je stvarno divno mjesto, lijepo mi je raditi ovdje, i emocionalno i intelektualno. A ima firmi u koje odeš kao konzultant i odmah shvatiš da ne bi mogao izdržati tri mjeseca i da bi užasnut pobjegao. O tome želim govoriti na izvješću.

Tim Lister će stići s glavnim govorom "Likovi, zajednica i kultura: važni čimbenici za prosperitet"na DevOops 2019 konferenciju koja će se održati od 29. do 30. listopada 2019. u St. Možete kupiti ulaznice na službenoj web stranici. Čekamo vas u DevOopsu!

Izvor: www.habr.com

Dodajte komentar