Tim Lister - coautor de cărți
- "Factorul uman. Proiecte și echipe de succes” (cartea originală se numește „Peopleware”)
- „Valsând cu urșii: gestionarea riscului în proiectele software”
- „Nebun de adrenalină și zombificat de tipare. Tipare de comportament ale echipelor de proiect”
Toate aceste cărți sunt clasice în domeniul lor și au fost scrise împreună cu colegii din . În Rusia, colegii săi sunt cei mai faimoși - и , care a scris și multe lucrări celebre.
Tim are 40 de ani de experiență în dezvoltarea de software în 1975 (niciunul dintre cei care au scris acest habrapost nu s-a născut anul acesta), Tim era deja vicepreședinte executiv al Yourdon Inc. Acum își petrece timpul consultând, predând și scriind, cu vizite ocazionale la conferințe din întreaga lume.
Am făcut un interviu cu Tim Lister special pentru Habr. El va deschide conferința DevOops 2019 și avem o mulțime de întrebări, despre cărți și multe altele. Interviul este condus de Mihail Druzhinin și Oleg Chirukhin din cadrul comitetului de program al conferinței.
Michael: Poți spune câteva cuvinte despre ceea ce faci acum?
Tim: Sunt șeful Breslei Sistemelor Atlantice. Suntem șase în breaslă, ne numim directori. Trei în SUA și trei în Europa - de aceea Guild se numește Atlantic. Suntem împreună de atâția ani încât nu-i poți număra. Toți avem specialitățile noastre. Lucrez cu clienți în ultimul deceniu sau mai mult. Proiectele mele includ nu numai management, ci și stabilirea cerințelor, planificarea proiectelor și evaluarea. Se pare că proiectele care încep prost de obicei se termină prost. Prin urmare, merită să vă asigurați că toate activitățile sunt cu adevărat bine gândite și coordonate, că ideile creatorilor sunt combinate. Merită să te gândești la ce faci și de ce. Ce strategii să folosiți pentru a duce proiectul la finalizare.
Am consiliat clienții într-o varietate de moduri de mulți ani. Un exemplu interesant este o companie care produce roboți pentru chirurgia genunchiului și șoldului. Chirurgul nu operează complet independent, ci folosește un robot. Siguranța aici, sincer vorbind, este importantă. Dar când încerci să discuti despre cerințe cu oameni care sunt concentrați pe rezolvarea problemelor... Va suna ciudat, dar în SUA există (Federal Drug Administration), care licențiază produse precum acești roboți. Înainte de a vinde ceva și de a-l folosi pe oameni vii, trebuie să obțineți o licență. Una dintre condiții este să vă arătați cerințele, care sunt testele, cum le-ați testat, care sunt rezultatele testelor. Dacă modificați cerințele, atunci trebuie să treceți prin acest proces uriaș de testare din nou și din nou. Clienții noștri au reușit să includă designul vizual al aplicațiilor în cerințele lor. Aveau capturi de ecran direct ca parte a cerințelor. Trebuie să le scoatem și să explicăm că, în cea mai mare parte, toate aceste programe nu știu nimic despre genunchi și șolduri, toate aceste lucruri cu camera foto etc. Trebuie să rescriem documentele de cerințe, astfel încât acestea să nu se schimbe niciodată, cu excepția cazului în care unele condiții de bază cu adevărat importante se schimbă. Dacă designul vizual nu este în cerințe, actualizarea produsului va fi mult mai rapidă. Treaba noastră este să găsim acele elemente care se ocupă de operațiile la genunchi, șolduri, spate, să le scoatem în documente separate și să spunem că acestea vor fi cerințele fundamentale. Să facem un grup izolat de cerințe despre operațiile la genunchi. Acest lucru ne va permite să construim un set mai stabil de cerințe. Vom vorbi despre întreaga linie de produse, și nu despre roboți anumiți.
S-a lucrat mult, dar au ajuns totuși în locuri în care anterior au petrecut săptămâni și luni de teste repetate fără sens sau nevoie, deoarece cerințele lor descrise pe hârtie nu coincideau cu cerințele reale pentru care au fost construite sistemele. FDA le-a spus de fiecare dată: cerințele dumneavoastră s-au schimbat, acum trebuie să verificați totul de la zero. Verificările complete ale întregului produs distrugeau întreprinderea.
Deci, există sarcini atât de minunate când te găsești chiar la începutul a ceva interesant, iar primele acțiuni stabilesc regulile ulterioare ale jocului. Dacă te asiguri că această activitate timpurie începe să funcționeze bine atât din punct de vedere managerial, cât și din punct de vedere tehnic, există șansa să ajungi cu un proiect grozav. Dar dacă această parte a dispărut și a greșit undeva, dacă nu poți găsi acordurile fundamentale... nu, nu înseamnă că proiectul tău va eșua neapărat. Dar nu vei mai putea spune: „Ne-am descurcat grozav, am făcut totul foarte eficient.” Acestea sunt lucrurile pe care le fac atunci când comunic cu clienții.
Michael: Adică lansați proiecte, faceți un fel de kickoff și verificați dacă șinele se îndreaptă în direcția corectă?
Tim: Avem, de asemenea, idei despre cum să punem toate piesele puzzle-ului împreună: de ce abilități avem nevoie, când exact ele sunt necesare, cum arată nucleul echipei și alte astfel de lucruri fundamentale. Avem nevoie de angajați cu normă întreagă sau putem angaja pe cineva cu normă parțială? Planificare, management. Întrebări precum: Ce este cel mai important pentru acest proiect anume? Cum să realizezi acest lucru? Ce știm despre acest produs sau proiect, care sunt riscurile și unde se află necunoscutele, cum vom face față tuturor acestor lucruri? Desigur, în acest moment cineva începe să strige „Ce zici de agil?!” Bine, sunteți cu toții flexibili, dar și ce? Cum arată exact proiectul, cum îl vei scoate într-un mod care se potrivește proiectului? Nu poți spune doar că „abordarea noastră se întinde la orice, suntem o echipă Scrum!” Aceasta este o prostie și o prostie. Unde vei merge mai departe, de ce ar trebui să funcționeze, unde este rostul? Îmi învăț clienții să se gândească la toate aceste întrebări.
19 ani de agilitate
Michael: În Agile, oamenii încearcă adesea să nu definească nimic în avans, ci să ia decizii cât mai târziu posibil, spunând: suntem prea mari, nu mă voi gândi la arhitectura generală. În schimb, nu mă voi gândi la o grămadă de alte lucruri, voi livra ceva care funcționează chiar acum.
Tim: Cred că metodologiile agile, începând cu în 2001, a deschis ochii industriei. Dar, pe de altă parte, nimic nu este perfect. Sunt pentru dezvoltarea iterativă. Iterația are foarte mult sens în majoritatea proiectelor. Dar întrebarea la care trebuie să te gândești este: odată ce produsul este scos și este utilizat, cât durează? Este acesta un produs care va dura șase luni înainte de a fi înlocuit cu altceva? Sau este acesta un produs care va funcționa mulți, mulți ani? Desigur, nu voi da nume, dar... În New York și comunitatea sa financiară, cele mai fundamentale sisteme sunt foarte vechi. Acest lucru este uimitor. Te uiți la ei și te gândești, dacă te-ai putea întoarce în timp, până în 1994 și le spui dezvoltatorilor: „Am venit din viitor, din 2019. Doar dezvoltați acest sistem atâta timp cât aveți nevoie. Faceți-l extensibil, gândiți-vă la arhitectură. Apoi va fi îmbunătățit pentru mai bine de douăzeci și cinci de ani. Dacă mai întârzi puțin dezvoltarea, în marea schemă a lucrurilor nimeni nu va observa!” Când estimați lucrurile pe termen lung, trebuie să luați în considerare cât va costa în total. Uneori, arhitectura bine concepută merită cu adevărat, iar uneori nu este. Trebuie să privim în jur și să ne întrebăm: suntem în situația potrivită pentru o astfel de decizie?
Deci o idee de genul „Suntem pentru agile, clientul însuși ne va spune ce vrea să obțină” - este super naivă. Clienții nici măcar nu știu ce vor și cu atât mai mult nu știu ce ar putea obține. Unii oameni vor începe să citeze exemple istorice drept argumente, am văzut deja asta. Dar oamenii avansati din punct de vedere tehnic nu spun de obicei asta. Ei spun: „Este 2019, acestea sunt oportunitățile pe care le avem și putem schimba complet modul în care privim aceste lucruri!” În loc să mimezi soluțiile existente, făcându-le puțin mai frumoase și mai pieptănate, uneori trebuie să ieși și să spui: „Hai să reinventăm complet ceea ce încercăm să facem aici!”
Și nu cred că majoritatea clienților se pot gândi la problemă în acest fel. Ei văd doar ceea ce au deja, asta-i tot. După care vin cu solicitări de genul „hai să simplificăm acest lucru” sau orice spun ei de obicei. Dar nu suntem chelneri sau chelnerițe, așa că putem lua o comandă oricât de stupidă ar fi și apoi o coacem în bucătărie. Noi suntem ghizii lor. Trebuie să le deschidem ochii și să spunem: hei, avem noi oportunități aici! Îți dai seama că putem schimba cu adevărat modul în care se desfășoară această parte a afacerii tale? Una dintre problemele cu Agile este că înlătură conștientizarea a ceea ce este o oportunitate, ce este o problemă, ce trebuie chiar să facem, ce tehnologii disponibile sunt cele mai potrivite pentru această situație particulară.
Poate că sunt prea sceptic aici: se întâmplă o mulțime de lucruri minunate în comunitatea agilă. Dar am o problemă cu faptul că în loc să definească un proiect, oamenii încep să ridice mâinile. Aș întreba aici - ce facem, cum o vom face? Și cumva, în mod magic, se dovedește întotdeauna că clientul ar trebui să știe mai bine decât oricine. Dar clientul știe cel mai bine doar atunci când alege dintre lucruri deja construite de cineva. Dacă vreau să cumpăr o mașină și știu dimensiunea bugetului familiei mele, atunci voi alege rapid o mașină care se potrivește stilului meu de viață. Aici știu totul mai bine decât oricine! Dar vă rugăm să rețineți că cineva a făcut deja mașinile. Habar n-am cum să inventez o mașină nouă, nu sunt un expert. Atunci când creăm produse personalizate sau speciale, trebuie luată în considerare vocea clientului, dar aceasta nu mai este singura voce.
Oleg: Ați menționat Manifestul Agile. Trebuie să o actualizăm sau să o revizuim cumva ținând cont de înțelegerea modernă a problemei?
Tim: Nu l-as atinge. Cred că este un document istoric grozav. Adică, el este ceea ce este. El împlinește 19 ani, este bătrân, dar la vremea lui a făcut o revoluție. Ceea ce a făcut bine a fost că a declanșat o reacție și oamenii au început să șoptească despre el. Cel mai probabil, nu lucrați încă în industrie în 2001, dar apoi toată lumea a lucrat conform proceselor. Institutul de Inginerie Software, cinci niveluri ale modelului de completitudine software (CMMI). Nu știu dacă astfel de legende ale antichității profunde vă spun ceva, dar atunci a fost o descoperire. La început, oamenii au crezut că, dacă procesele sunt configurate corect, atunci problemele vor dispărea de la sine. Și apoi vine Manifestul și spune: „Nu, nu, nu – ne vom baza pe oameni, nu pe procese.” Suntem maeștri în dezvoltarea software-ului. Înțelegem că procesul ideal este un miraj; Există prea multă idiosincrazie în proiecte, ideea unui singur proces perfect pentru toate proiectele nu are niciun sens. Problemele sunt prea complexe pentru a pretinde că există o singură soluție la toate (bună ziua, nirvana).
Nu mă gândesc să privesc în viitor, dar voi spune că acum oamenii au început să se gândească mai mult la proiecte. Cred că Manifestul Agile este foarte bun să sară afară și să spună: „Hei! Ești pe o navă și tu însuți conduci această navă. Va trebui să iei o decizie - nu vom sugera o rețetă universală pentru toate situațiile. Sunteți echipajul navei și, dacă sunteți suficient de bun, puteți găsi o cale către obiectiv. Au fost alte nave înaintea ta și vor mai fi și alte nave după tine, dar totuși, într-un fel, călătoria ta este unică.” Ceva de genul! Este un mod de a gândi. Pentru mine, nu este nimic nou sub soare, oamenii au navigat înainte și vor naviga din nou, dar pentru tine aceasta este călătoria ta principală și nu-ți voi spune exact ce se va întâmpla cu tine. Trebuie să ai abilități de lucru coordonat în echipă, iar dacă le ai cu adevărat, totul va merge și vei ajunge unde ți-ai dorit.
Peopleware: 30 de ani mai târziu
Oleg: A fost Peopleware o revoluție la fel ca și Manifestul?
Tim: Peopleware... Tom și cu mine am scris această carte, dar nu ne-am gândit că se va întâmpla așa. Cumva a rezonat cu ideile multor oameni. Aceasta a fost prima carte care spunea: dezvoltarea de software este o activitate foarte intensivă în oameni. În ciuda naturii noastre tehnice, suntem și o comunitate de oameni care construiesc ceva mare, chiar uriaș, foarte complex. Nimeni nu poate crea astfel de lucruri singur, nu? Așa că ideea de „echipă” a devenit foarte importantă. Și nu doar din punct de vedere al managementului, ci și pentru oamenii tehnici care s-au reunit pentru a rezolva probleme profunde cu adevărat complexe cu o grămadă de necunoscute. Pentru mine personal, acesta a fost un test uriaș de inteligență de-a lungul carierei mele. Și aici trebuie să poți spune: da, această problemă este mai mult decât pot face față singur, dar împreună putem găsi o soluție elegantă cu care să fim mândri. Și cred că această idee a fost cea care a rezonat cel mai mult. Ideea că lucrăm o parte din timp pe cont propriu, o parte din timp ca parte a unui grup și adesea decizia este luată de grup. Rezolvarea problemelor de grup a devenit rapid o caracteristică importantă a proiectelor complexe.
În ciuda faptului că Tim a susținut un număr mare de discuții, foarte puține dintre ele sunt postate pe YouTube. Puteți consulta raportul „The Return of Peopleware” din 2007. Calitatea, desigur, lasă mult de dorit.
Michael: S-a schimbat ceva în ultimii 30 de ani de la publicarea cărții?
Tim: Puteți privi acest lucru din multe unghiuri diferite. Sociologic vorbind... cândva, în vremuri mai simple, tu și echipa ta ați stat în același birou. Ați putea fi aproape în fiecare zi, să beți cafea împreună și să discutați despre muncă. Ceea ce s-a schimbat cu adevărat este că acum echipele pot fi distribuite geografic, în diferite țări și fusuri orare, dar totuși lucrează la aceeași problemă, iar acest lucru adaugă un nivel cu totul nou de complexitate. Poate că sună vechi, dar nu există nimic ca o comunicare față în față în care sunteți cu toții împreună, lucrând împreună și puteți merge la un coleg și vă puteți spune: uite ce am descoperit, cum îți place asta? Conversațiile față în față oferă o modalitate rapidă de trecere la comunicarea informală și cred că și pasionaților agile ar trebui să le placă. Și sunt, de asemenea, îngrijorat pentru că în realitate lumea s-a dovedit a fi foarte mică, iar acum totul este acoperit cu echipe distribuite și totul este foarte complex.
Toți trăim în DevOps
Michael: Chiar și din punctul de vedere al comitetului de program al conferinței, avem oameni în California, în New York, Europa, Rusia... încă nu este nimeni în Singapore. Diferența de geografie este destul de mare, iar oamenii încep să se răspândească și mai mult. Dacă vorbim despre dezvoltare, ne puteți spune mai multe despre devop-uri și despre distrugerea barierelor dintre echipe? Există un concept conform căruia toată lumea stă în buncărele lor, iar acum buncărele se prăbușesc, ce părere aveți despre această analogie?
Tim: Mi se pare că, în lumina descoperirilor tehnologice recente, devops-ul este de mare importanță. Anterior, aveai echipe de dezvoltatori și administratori, au lucrat, au lucrat, au lucrat și, la un moment dat, a apărut un lucru cu care puteai să vii la admini și să-l lansezi pentru producție. Și aici a început conversația despre buncăr, pentru că adminii sunt un fel de aliați, nu dușmani, cel puțin, dar ai vorbit cu ei doar când totul era gata să treacă în producție. Te-ai dus la ei cu ceva și ai spus: uite ce aplicație avem, dar ai putea să lansezi această aplicație? Și acum întregul concept de livrare s-a schimbat în bine. Adică, a existat ideea că ai putea trece rapid la schimbări. Putem actualiza produsele din mers. Zâmbesc mereu când apare Firefox de pe laptopul meu și îmi spune, hei, ți-am actualizat Firefox în fundal și, de îndată ce ai un minut, te deranjează să dai clic aici și îți vom oferi cea mai recentă versiune. Și am spus: „Oh, da, iubito!” În timp ce dormeam, ei lucrau să-mi livreze o nouă versiune chiar pe computerul meu. Acesta este minunat, incredibil.
Dar aici este dificultatea: aveți această funcție cu actualizarea software-ului, dar integrarea oamenilor este mult mai dificilă. Ceea ce vreau să spun la prezentarea DevOops este că acum avem mult mai mulți jucători decât am avut vreodată. Dacă te gândești doar la toți cei implicați într-o singură echipă... Te-ai gândit la asta ca la o echipă și este mult mai mult decât o simplă echipă de programatori. Aceștia sunt testeri, manageri de proiect și o grămadă de alți oameni. Și fiecare are propriile păreri despre lume. Managerii de produs sunt complet diferiti de managerii de proiect. Administratorii au propriile lor sarcini. Devine o problemă destul de dificilă să coordonezi toți participanții pentru a continua să fii conștient de ceea ce se întâmplă și să nu înnebunești. Este necesar să se separe sarcinile grupului și sarcinile care se aplică tuturor. Aceasta este o sarcină foarte dificilă. Pe de altă parte, cred că totul este mult mai bine decât era acum mulți ani. Acesta este exact drumul pe care oamenii cresc și învață să se comporte corect. Când faci integrare, înțelegi că nu ar trebui să existe o dezvoltare subterană, astfel încât în ultimul moment software-ul să nu se târască ca un jack-in-the-box: uite ce am făcut aici! Ideea este că vei putea să faci integrare și dezvoltare, iar la final te vei rula într-un mod îngrijit și iterativ. Toate acestea înseamnă foarte mult pentru mine. Acest lucru face posibilă crearea mai multă valoare pentru utilizatorii sistemului și pentru clientul dumneavoastră.
Michael: Întreaga idee a devops este să furnizeze dezvoltări semnificative cât mai devreme posibil. Văd că lumea a început să se accelereze din ce în ce mai mult. Cum să te adaptezi la astfel de accelerații? Acum zece ani asta nu exista!
Tim: Desigur, toată lumea își dorește din ce în ce mai multă funcționalitate. Nu este nevoie să te miști, doar adună mai multe. Uneori chiar trebuie să încetinești pentru următoarea actualizare incrementală pentru a aduce ceva util - și asta este complet normal.
Ideea că trebuie să alergi, să alergi, să alergi nu este cea mai bună. Este puțin probabil ca cineva să-și dorească să-și trăiască viața așa. Aș dori ca ritmul livrărilor să stabilească propriul ritm al proiectului. Dacă doar produceți un flux de lucruri mici, relativ lipsite de sens, totul nu are sens. În loc să încerci fără minte să lansezi lucrurile cât mai devreme posibil, ceea ce merită discutat cu dezvoltatorii principali și cu managerii de produs și de proiect este strategia. Are sens asta?
Modele și antimodeluri
Oleg: De obicei vorbești despre tipare și antipattern, iar aceasta este diferența dintre viața și moartea proiectelor. Și acum, devops-ul iese în viețile noastre. Are vreunul dintre propriile modele și anti-modele care pot ucide proiectul pe loc?
Tim: Modelele și anti-modelele apar tot timpul. Ceva despre care să vorbim. Ei bine, există acest lucru pe care îl numim „lucruri strălucitoare”. Oamenilor le place foarte mult noile tehnologii. Sunt pur și simplu fascinați de strălucirea a tot ceea ce arată cool și elegant și nu mai pun întrebări: este chiar necesar? Ce vom realiza? Este acest lucru de încredere, are vreun sens? Văd adesea oameni, ca să spunem așa, la vârf de tehnologie. Sunt hipnotizați de ceea ce se întâmplă în lume. Dar dacă te uiți mai atent la ce lucruri utile fac, de multe ori pur și simplu nu este nimic util!
Tocmai discutam cu tovarășii noștri că anul acesta este un an aniversar, cincizeci de ani de când oamenii au aterizat pe Lună. Asta a fost în 1969. Tehnologia care a ajutat oamenii să ajungă acolo nu este nici măcar tehnologia 1969, ci mai degrabă 1960 sau 62, pentru că NASA a vrut să folosească doar ceea ce avea dovezi bune de fiabilitate. Și așa te uiți la asta și înțelegi - da, și erau adevărate! Acum, nu, nu, dar intri în probleme cu tehnologia pur și simplu pentru că totul este împins prea tare, vândut din toate crapaturile. Oamenii strigă de pretutindeni: „Uite, ce lucru, acesta este cel mai nou lucru, cel mai frumos lucru din lume, potrivit pentru absolut toată lumea!” Ei bine, asta este... de obicei, toate acestea se dovedesc a fi doar o momeală, apoi trebuie aruncate. Poate că totul se datorează faptului că sunt deja un bătrân și mă uit la astfel de lucruri cu mult scepticism, atunci când oamenii ies din ea și spun că au găsit singura și cea mai corectă modalitate de a crea cele mai bune tehnologii. În acest moment, în mine se trezește o voce care spune: „Ce mizerie!”
Michael: Într-adevăr, cât de des am auzit despre următorul glonț de argint?
Tim: Exact, și acesta este cursul obișnuit al lucrurilor! De exemplu... se pare că asta a devenit deja o glumă în toată lumea, dar aici se vorbește adesea despre tehnologia blockchain. Și chiar au sens în anumite situații! Când chiar ai nevoie de dovezi sigure ale evenimentelor, că sistemul funcționează și că nimeni nu ne-a înșelat, când ai probleme de securitate și toate chestiile astea amestecate - blockchain-ul are sens. Dar când spun că Blockchain-ul va mătura acum întreaga lume, ștergând totul în cale? Viseaza mai mult! Aceasta este o tehnologie foarte costisitoare și complexă. Tehnic complex și consumator de timp. Inclusiv pur algoritmic, de fiecare dată când trebuie să recalculezi matematica, cu cele mai mici modificări... și aceasta este o idee grozavă - dar numai pentru anumite cazuri. Toată viața și cariera mea au fost despre asta: idei interesante în situații foarte specifice. Este foarte important să înțelegeți exact care este situația dvs.
Michael: Da, principala „întrebare a vieții, a universului și a tot”: această tehnologie sau abordare este potrivită sau nu pentru situația ta?
Tim: Această întrebare poate fi deja discutată cu grupul de tehnologie. Poate chiar aduceți un consultant. Aruncă o privire la proiect și înțelege - vom face acum ceva corect și util, mai bine decât înainte? Poate se va potrivi, poate nu. Dar, cel mai important, nu luați o astfel de decizie în mod implicit, pur și simplu pentru că cineva a scapat: „Avem nevoie disperată de un blockchain! Tocmai am citit despre el într-o revistă din avion!” Serios? Nici măcar nu e amuzant.
Miticul „inginer devops”
Oleg: Acum toată lumea implementează devops. Cineva citește despre devops pe internet, iar mâine apare un alt post vacant pe un site de recrutare. "inginer devops". Aici aș dori să vă atrag atenția: credeți că acest termen, „inginer devops”, are dreptul la viață? Există o părere că devops este o cultură și ceva nu se adaugă aici.
Tim: Asa si asa. Lasă-i apoi să dea imediat o explicație pentru acest termen. Ceva care să-l facă unic. Până nu vor dovedi că există o combinație unică de aptitudini în spatele unui post vacant ca acesta, nu îl voi cumpăra! Adică, avem un titlu de post, „inginer devops”, un titlu interesant, da, ce urmează? Titlurile postului sunt, în general, un lucru foarte interesant. Să spunem „dezvoltator” – ce este oricum? Organizații diferite înseamnă lucruri complet diferite. În unele companii, programatorii de înaltă calitate scriu teste care au mai mult sens decât testele scrise de testeri profesioniști speciali din alte companii. Deci ce, acum sunt programatori sau testeri?
Da, avem titluri de post, dar dacă pui întrebări suficient de mult, în cele din urmă se dovedește că toți rezolvăm probleme. Suntem în căutarea de soluții, iar unii au unele abilități tehnice, iar alții au altele diferite. Dacă locuiți într-un mediu în care DevOps a pătruns, sunteți implicat în integrarea dezvoltării și administrării, iar această activitate are un scop destul de important. Dar dacă ești întrebat ce anume faci și de ce ești responsabil, se dovedește că oamenii au făcut toate aceste lucruri din timpuri imemoriale. „Sunt responsabil pentru arhitectură”, „Sunt responsabil pentru bazele de date” și așa mai departe, orice vedeți, toate acestea erau înainte de „devops”.
Când cineva îmi spune titlul postului, nu prea ascult. Este mai bine să-l lăsați să vă spună de ce este de fapt responsabil, acest lucru ne va permite să înțelegem mult mai bine problema. Exemplul meu preferat este atunci când o persoană pretinde că este „manager de proiect”. Ce? Nu înseamnă nimic, încă nu știu ce faci. Un manager de proiect poate fi un dezvoltator, liderul unei echipe de patru oameni, care scrie cod, lucrează, care a devenit lider de echipă, pe care oamenii înșiși îl recunosc între ei ca lider. Și, de asemenea, un manager de proiect poate fi un manager care gestionează șase sute de oameni într-un proiect, gestionează alți manageri, este responsabil pentru întocmirea programelor și planificarea bugetelor, atât. Acestea sunt două lumi complet diferite! Dar titlul postului lor sună la fel.
Să întoarcem lucrurile puțin diferit. La ce te pricepi cu adevărat, ai multă experiență, ai talent? Pentru ce vă veți asumă responsabilitatea pentru că credeți că vă puteți ocupa de sarcina? Și aici cineva va începe imediat să nege: nu, nu, nu, nu vreau deloc să mă ocup de resursele proiectului, nu este treaba mea, sunt un tip tehnic și înțeleg utilitatea și interfețele cu utilizatorul, nu Vreau să conduc armate de oameni, lasă-mă mai bine să mă duc la muncă.
Și apropo, sunt un mare susținător al unei abordări în care acest tip de separare a competențelor funcționează bine. Unde tehnicienii își pot dezvolta cariera atât cât doresc. Cu toate acestea, văd în continuare organizații în care tehnicienii se plâng: va trebui să intru în managementul proiectelor pentru că doar așa este în această companie. Uneori, acest lucru duce la rezultate teribile. Cei mai buni tehnicieni nu sunt deloc buni manageri, iar cei mai buni manageri nu se pot descurca cu tehnologia. Să fim sinceri în privința asta.
Văd multă cerere pentru asta acum. Dacă ești un profesionist, compania ta te poate ajuta, dar, indiferent, ai nevoie, într-adevăr trebuie să-ți găsești propriul drum în carieră, deoarece tehnologia se schimbă în continuare și trebuie să te reinventezi odată cu ea! În doar douăzeci de ani, tehnologiile se pot schimba de cel puțin cinci ori. Tehnologia este un lucru ciudat...
„Experți în orice”
Michael: Cum pot oamenii să facă față unei asemenea viteze de schimbare a tehnologiei? Complexitatea lor crește, numărul lor crește, cantitatea totală de comunicare între oameni crește și ea și se dovedește că nu poți deveni un „expert în toate”.
Tim: Dreapta! Dacă lucrezi în tehnologie, da, trebuie neapărat să alegi ceva specific și să aprofundezi în el. O tehnologie pe care organizația dvs. o consideră utilă (și poate că va fi de fapt utilă). Și dacă nu te mai interesează - nu aș fi crezut niciodată că aș spune asta - ei bine, poate ar trebui să te muți într-o altă organizație unde tehnologia este mai interesantă sau mai convenabilă de studiat.
Dar, în general, da, ai dreptate. Tehnologiile cresc în toate direcțiile deodată, nimeni nu poate spune „Sunt un tehnolog expert în toate tehnologiile care există”. Pe de altă parte, există oameni bureți care absorb literalmente cunoștințele tehnologice și sunt înnebuniți după asta. Am văzut câțiva astfel de oameni, ei respiră și trăiesc, este util și interesant să vorbesc cu ei. Ei studiază nu numai ceea ce se întâmplă în interiorul organizației, ci, în general, vorbesc despre asta, sunt și tehnologi foarte cool, sunt foarte conștienți și intenționați. Ei încearcă doar să rămână pe creasta valului, indiferent care este meseria lor principală, pentru că pasiunea lor este mișcarea Tehnologiei, promovarea tehnologiei. Dacă întâlnești dintr-o dată o astfel de persoană, ar trebui să mergi la prânz cu el și să discuti diverse lucruri interesante la prânz. Cred că orice organizație are nevoie de cel puțin câțiva astfel de oameni.
Riscuri și incertitudine
Michael: Onorați ingineri, da. Să ne referim la managementul riscurilor cât timp avem timp. Am început acest interviu cu o discuție despre software-ul medical, unde erorile pot duce la consecințe grave. Apoi am vorbit despre Programul Lunar, unde costul unei erori este de milioane de dolari și, posibil, mai multe vieți umane. Dar acum văd mișcarea opusă în industrie, oamenii nu se gândesc la riscuri, nu încearcă să le prezică, nici măcar nu le observă.
Oleg: Mișcă-te repede și sparge lucruri!
Michael: Da, mișcă-te repede, sparge lucruri, din ce în ce mai multe, până mori de ceva. Din punctul dumneavoastră de vedere, cum ar trebui să abordeze dezvoltatorul mediu acum managementul riscului de învățare?
Tim: Să tragem aici o linie între două lucruri: riscuri și incertitudine. Acestea sunt lucruri diferite. Incertitudinea apare atunci când nu aveți suficiente date la un moment dat pentru a ajunge la un răspuns definitiv. De exemplu, în stadiul incipient al unui proiect, dacă cineva vă întreabă „când veți termina munca”, dacă sunteți o persoană destul de sinceră, veți spune: „Habar n-am”. Doar că nu știi, și asta e în regulă. Încă nu ați studiat problemele și nu sunteți familiarizat cu echipa, nu le cunoașteți abilitățile și așa mai departe. Aceasta este incertitudinea.
Riscurile apar atunci când pot fi deja identificate probleme potențiale. Se pot întâmpla astfel de lucruri, probabilitatea sa este mai mare decât zero, dar mai mică de o sută la sută, undeva la mijloc. Din această cauză, orice se poate întâmpla, de la întârzieri și lucrări inutile, dar chiar și până la un rezultat fatal pentru proiect. Rezultatul, când spuneți - băieți, să ne pliăm umbrelele și să plecăm de la plajă, nu o vom termina niciodată, totul s-a terminat, punct. Am presupus că acest lucru va funcționa, dar nu funcționează deloc, este timpul să ne oprim. Acestea sunt situațiile.
Adesea, problemele sunt cel mai ușor de rezolvat atunci când au apărut deja, când problema se întâmplă chiar acum. Dar atunci când o problemă este chiar în fața ta, nu faci management al riscului, ci rezolvi probleme, gestionezi crize. Dacă sunteți un dezvoltator sau manager principal, trebuie să vă întrebați ce s-ar putea întâmpla care ar duce la întârzieri, timp pierdut, costuri inutile sau prăbușirea întregului proiect? Ce ne va face să ne oprim și să o luăm de la capăt? Când toate aceste lucruri vor funcționa, ce vom face cu ele? Există un răspuns simplu care este valabil pentru majoritatea situațiilor: nu fugi de riscuri, lucrează la ele. Vezi cum poți să rezolvi o situație riscantă, să o reduci la nimic, să o transformi dintr-o problemă în altceva. În loc să spunem: ei bine, vom rezolva problemele pe măsură ce vor apărea.
Incertitudinea și riscul ar trebui să fie în fruntea a tot ceea ce ai de-a face. Puteți să luați un plan de proiect, să vă uitați la anumite riscuri critice din timp și să spuneți: trebuie să ne ocupăm de asta acum, pentru că dacă oricare dintre acestea nu merge bine, nimic altceva nu va conta. Nu ar trebui să vă faceți griji cu privire la frumusețea feței de masă de pe masă dacă nu este clar dacă puteți găti cina. Mai întâi trebuie să identificați toate riscurile pregătirii unei cine delicioase, să vă ocupați de ele și abia apoi să vă gândiți la toate celelalte lucruri care nu reprezintă o amenințare reală.
Din nou, ce face proiectul tău unic? Să vedem ce poate face proiectul nostru să iasă de la sine. Ce putem face pentru a minimiza probabilitatea ca acest lucru să se întâmple? De obicei, nu poți să le neutralizezi 100% și să declari cu conștiința curată: „Asta este, aceasta nu mai este o problemă, riscul s-a rezolvat!” Pentru mine, acesta este un semn de comportament adult. Aceasta este diferența dintre un copil și un adult - copiii cred că sunt nemuritori, că nimic nu poate merge prost, totul va fi bine! În același timp, adulții urmăresc cum copiii de trei ani sar pe locul de joacă, urmăresc mișcările cu ochii și își spun: „ooh-ooh, ooh-ooh”. Stau în apropiere și mă pregătesc să prind când copilul cade.
Pe de altă parte, motivul pentru care îmi place atât de mult această afacere este că este riscantă. Facem lucruri, iar acele lucruri sunt riscante. Ei necesită o abordare adultă. Numai entuziasmul nu vă va rezolva problemele!
Gândirea inginerească pentru adulți
Michael: Exemplul cu copiii este bun. Dacă sunt un inginer obișnuit, atunci sunt încântat să fiu un copil. Dar cum te îndrepți către o gândire mai adultă?
Tim: Una dintre ideile care funcționează la fel de bine fie cu un începător, fie cu un dezvoltator consacrat este conceptul de context. Ce facem, ce vom realiza. Ce este cu adevărat important în acest proiect? Nu contează cine ești în acest proiect, fie că ești stagiar sau arhitect șef, toată lumea are nevoie de context. Trebuie să-i facem pe toți să gândească la o scară mai mare decât propriile lucrări. „Îmi fac piesa și, atâta timp cât piesa mea funcționează, sunt fericit.” Nu și nu din nou. Merită întotdeauna (fără a fi nepoliticos!) să le reamintești oamenilor de contextul în care lucrează. Ceea ce încercăm cu toții să realizăm împreună. Idei că poți fi copil atâta timp cât totul este în regulă cu partea ta din proiect - te rog, nu face asta. Dacă trecem deloc linia de sosire, o vom trece doar împreună. Nu ești singur, suntem cu toții împreună. Dacă toți oamenii din proiect, atât bătrâni cât și tineri, au început să vorbească despre ce anume este important pentru proiect, de ce compania investește bani în ceea ce încercăm cu toții să realizăm... majoritatea se vor simți mult mai bine pentru că vor vedea cum munca lor se corelează cu munca tuturor celorlalți. Pe de o parte, înțeleg piesa pentru care sunt personal responsabil. Dar pentru a termina treaba avem nevoie și de toți ceilalți oameni. Și dacă chiar crezi că ai terminat, avem întotdeauna de lucru în proiect!
Oleg: Relativ vorbind, dacă lucrezi conform Kanban, când te lovești de blocajul unor teste, poți renunța la ceea ce făceai acolo (de exemplu, programare) și mergi să ajuți testerii.
Tim: Exact. Cred că cei mai buni tehnicieni, dacă te uiți cu atenție la ei, sunt un fel de propriii lor manageri. Cum pot formula asta...
Oleg: Viața ta este proiectul tău, pe care îl gestionezi.
Tim: Exact! Adică îți asumi responsabilitatea, înțelegi problema și intri în contact cu oamenii când vezi că deciziile tale le pot afecta munca, lucruri de genul ăsta. Nu este vorba doar să stai la birou, să-ți faci treaba și să nu-ți dai seama măcar de ce se întâmplă în jurul tău. Nu Nu NU. Apropo, unul dintre cele mai bune lucruri despre Agile este că au propus sprinturi scurte, pentru că astfel starea de fapt a tuturor participanților este clar observabilă, ei pot vedea totul împreună. Vorbim unul despre celălalt în fiecare zi.
Cum să intri în managementul riscului
Oleg: Există vreo structură formală de cunoștințe în acest domeniu? De exemplu, sunt un dezvoltator Java și vreau să înțeleg managementul riscurilor fără a deveni un adevărat manager de proiect prin educație. Probabil că voi citi mai întâi „Cât costă un proiect software” al lui McConnell, apoi ce? Care sunt primii pași?
Tim: Primul este să începeți să comunicați cu oamenii din proiect. Acest lucru asigură o îmbunătățire imediată a culturii de comunicare cu colegii. Trebuie să începem prin a deschide totul în mod implicit, în loc să îl ascundem. Spune: acestea sunt lucrurile care mă deranjează, acestea sunt lucrurile care mă țin noaptea, m-am trezit noaptea astăzi și am spus: Doamne, trebuie să mă gândesc la asta! Alții văd același lucru? Ca grup, ar trebui să răspundem la aceste probleme potențiale? Trebuie să fiți capabil să susțineți o discuție pe aceste subiecte. Nu există o formulă pregătită în prealabil prin care să lucrăm. Nu este vorba de a face hamburgeri, ci de oameni. „Faceți un cheeseburger, vindeți un cheeseburger” nu este deloc lucrul nostru și de aceea îmi place atât de mult această meserie. Îmi place când tot ceea ce făceau managerii înainte devine acum proprietatea echipei.
Oleg: Ați vorbit în cărți și interviuri despre felul în care oamenilor le pasă mai mult de fericire decât de cifrele de pe un grafic. Pe de altă parte, când îi spui echipei: trecem la devop-uri, iar acum programatorul trebuie să comunice constant, acest lucru poate fi mult în afara zonei sale de confort. Și în acest moment el poate, să spunem, să fie profund nefericit. Ce să faci în această situație?
Tim: Nu sunt sigur exact ce să fac. Dacă un dezvoltator este prea izolat, ei nu văd de ce se face munca în primul rând, se uită doar la partea sa din muncă și trebuie să intre în ceea ce eu numesc „context”. Trebuie să-și dea seama cum totul este conectat. Și, desigur, nu mă refer la prezentări formale sau ceva de genul acesta. Vorbesc despre faptul că trebuie să comunici cu colegii despre munca în ansamblu, și nu doar despre partea din ea pentru care ești responsabil. Aici puteți începe să discutați idei, acorduri comune pentru a face munca dvs. să se potrivească bine și cum să abordați împreună o problemă comună.
Pentru a-i ajuta să se adapteze, adesea doresc să trimită tehnicieni la antrenament și discută despre antrenament. Un prieten de-al meu îi place să spună că dresajul este pentru câini. Există pregătire pentru oameni. Unul dintre cele mai bune lucruri despre învățarea ca dezvoltator este interacțiunea cu colegii tăi. Dacă cineva este cu adevărat bun la ceva, ar trebui să-l vezi cum lucrează sau să vorbești cu el despre munca lui sau ceva de genul. Unii Kent Beck convenționali vorbeau în mod constant despre programare extremă. Este amuzant pentru că XP este o idee atât de simplă, dar provoacă atât de multe probleme. Pentru unii, a face XP este ca și cum ai fi forțat să te dezbraci în fața prietenilor. Vor vedea ce fac! Sunt colegii mei, nu numai că vor vedea, dar și vor înțelege! Teribil! Unii oameni încep să devină foarte nervoși. Dar când realizezi că acesta este cel mai bun mod de a învăța, totul se schimbă. Lucrezi îndeaproape cu oamenii, iar unii oameni înțeleg subiectul mult mai bine decât tine.
Michael: Dar toate acestea te obligă să ieși din zona ta de confort. Ca inginer, trebuie să ieși din zona ta de confort și să comunici. Ca rezolvator de probleme, trebuie să te pui constant într-o poziție slabă și să te gândești la ce ar putea merge prost. Acest tip de muncă este în mod inerent conceput pentru a fi o pacoste. Te pui în mod conștient în situații stresante. De obicei oamenii fug de ei, oamenilor le place să fie copii fericiți.
Tim: Ce se poate face, poți să ieși și să spui deschis: „Totul este în regulă, mă descurc! Nu sunt singurul care se simte inconfortabil. Să discutăm diverse lucruri incomode, toți împreună, ca o echipă!” Acestea sunt problemele noastre comune, trebuie să ne ocupăm de ele, știi? Cred că dezvoltatorii geniali idiosincratici sunt ca niște mamuți, au dispărut. Și semnificația lor este foarte limitată. Dacă nu poți comunica, nu poți participa bine. Prin urmare, doar vorbește. Fii sincer și deschis. Îmi pare foarte rău că acest lucru este neplăcut pentru cineva. Vă puteți imagina, cu mulți ani în urmă a existat un studiu conform căruia principala frică în Statele Unite nu este moartea, dar ghiciți ce? Frica de a vorbi în public! Asta înseamnă că undeva există oameni care preferă să moară decât să spună un compliment cu voce tare. Și cred că este suficient să ai niște abilități de bază, în funcție de ceea ce faci. Abilități de vorbire, abilități de scris - dar doar atât cât este cu adevărat necesar în munca ta. Dacă lucrezi ca analist, dar nu poți citi, scrie și vorbi, atunci, din păcate, nu vei avea ce face în proiectele mele!
Pretul comunicarii
Oleg: Nu este mai scumpă angajarea unor astfel de angajați plecați din diverse motive? La urma urmei, ei vorbesc constant în loc să lucreze!
Tim: Mă refeream la miezul echipei, și nu doar la toată lumea. Dacă ai pe cineva care se pricepe cu adevărat la reglarea bazelor de date, iubește reglarea bazelor de date și va continua să-ți ajusteze bazele de date pentru tot restul vieții și gata, cool, ține-o tot așa. Dar vorbesc despre oameni care vor să trăiască în proiectul în sine. Nucleul echipei, care vizează dezvoltarea proiectului. Acești oameni chiar trebuie să comunice în mod constant între ei. Și mai ales la începutul proiectului, când discutați despre riscuri, modalități de atingere a obiectivelor globale și altele asemenea.
Michael: Acest lucru se aplică tuturor celor implicați în proiect, indiferent de specializare, abilități sau modalități de lucru. Sunteți cu toții interesați de succesul proiectului.
Tim: Da, simți că ești suficient de cufundat în proiect, că sarcina ta este să ajuți proiectul să devină realitate. Fie că ești programator, analist, designer de interfețe, oricine. Acesta este motivul pentru care vin la serviciu în fiecare dimineață și asta facem. Suntem responsabili pentru toți acești oameni, indiferent de aptitudinile lor. Acesta este un grup de oameni care au conversații cu adulți.
Oleg: De fapt, vorbind despre angajații vorbăreți, am încercat să simulez obiecțiile oamenilor, în special ale managerilor, cărora li se cere să treacă la devop-uri, la această viziune cu totul nouă asupra lumii. Iar dumneavoastră, în calitate de consultanți, ar trebui să fiți conștienți de aceste obiecții mult mai bine decât mine, ca dezvoltator! Împărtășește ce îi îngrijorează cel mai mult pe manageri?
Tim: Managerii? Hm. Cel mai adesea, managerii sunt sub presiunea problemelor, se confruntă cu nevoia de a elibera urgent ceva și de a face o livrare și altele asemenea. Ei urmăresc cum discutăm și ne certăm în mod constant despre ceva și ei văd așa: conversații, conversații, conversații... Ce alte conversații? Treci inapoi la munca! Pentru că pentru ei să vorbești nu e un lucru. Nu scrii cod, nu testezi software, nu pari să faci nimic - de ce să nu te trimiți să faci ceva? La urma urmei, livrarea este deja într-o lună!
Michael: Du-te și scrie niște cod!
Tim: Mi se pare că nu sunt îngrijorați de muncă, ci de lipsa de vizibilitate a progresului. Pentru a face să pară că ne apropiem de succes, trebuie să ne vadă apăsând butoanele de pe tastatură. Toată ziua de dimineața până seara. Aceasta este problema numărul unu.
Oleg: Misha, te gândești la ceva.
Michael: Scuze, m-am pierdut pe gânduri și am prins un flashback. Toate acestea mi-au adus aminte de un miting interesant care a avut loc ieri... Au fost prea multe mitinguri ieri... Și totul sună foarte familiar!
Viață fără salarii
Tim: Apropo, nu este deloc necesar să se organizeze „mitinguri” pentru comunicare. Adică, cele mai utile discuții între dezvoltatori au loc atunci când doar vorbesc între ei. Intri dimineața cu o ceașcă de cafea și sunt cinci oameni strânși și discută cu furie ceva tehnic. Pentru mine, dacă sunt managerul acestui proiect, este mai bine să zâmbesc și să mă duc undeva despre afacerea mea, să-i las să discute. Sunt deja implicați pe cât posibil. Acesta este un semn bun.
Oleg: Apropo, în cartea ta ai o grămadă de note despre ce este bine și ce este rău. Îți folosești chiar unul dintre ele? Relativ vorbind, acum aveți o companie și una care este structurată într-un mod foarte neortodox...
Tim: Neortodox, dar acest dispozitiv ni se potrivește perfect. Ne cunoaștem de mult timp. Avem încredere unul în altul, ne-am avut multă încredere unul în altul înainte de a deveni parteneri. Și de exemplu, nu avem salarii deloc. Noi doar muncim și, de exemplu, dacă am câștigat bani de la clienții mei, atunci toți banii mergeau la mine. După aceea, plătim cotizații de membru organizației, iar acest lucru este suficient pentru a susține compania însăși. În plus, toți suntem specializați în lucruri diferite. De exemplu, lucrez cu contabili, completez declarații fiscale, fac tot felul de lucruri administrative pentru companie și nu mă plătește nimeni pentru asta. James și Tom lucrează pe site-ul nostru și nici nu îi plătește nimeni. Atâta timp cât îți plătești cotizațiile, nimeni nu se va gândi să-ți spună ce trebuie să faci. De exemplu, Tom lucrează acum mult mai puțin decât a făcut cândva. Acum are alte interese, el face unele lucruri nu pentru Breasla. Dar atâta timp cât își plătește cotizațiile, nimeni nu se va apropia de el și îi va spune: „Hei, Tom, du-te la muncă!” Este foarte ușor să ai de-a face cu colegii atunci când nu sunt bani între voi. Și acum relația noastră este una dintre ideile fundamentale în raport cu diferitele specialități. Funcționează și funcționează foarte bine.
Cel mai bun sfat
Michael: Revenind la „cel mai bun sfat”, există ceva ce le spui clienților tăi din nou și din nou? Există o idee despre 80/20, iar unele sfaturi se repetă probabil mai des.
Tim: M-am gândit odată că dacă ai scrie o carte precum Valsul cu urșii, s-ar schimba cursul istoriei și oamenii s-ar opri, dar... Ei bine, uite, companiile pretind adesea că totul este în regulă cu ei. De îndată ce se întâmplă ceva rău, este un șoc și o surpriză pentru ei. „Uite, am testat sistemul și nu trece nicio testare a sistemului, iar acestea sunt încă trei luni de lucru neprogramat, cum s-ar putea întâmpla asta? Cine stia? Ce ar putea merge prost? Serios, crezi asta?
Încerc să-ți explic că nu ar trebui să te enervezi prea mult din cauza situației actuale. Trebuie să vorbim, să înțelegem cu adevărat ce ar fi putut merge prost și cum să prevenim astfel de lucruri să se întâmple în viitor. Dacă apare o problemă, cum o vom combate, cum o vom reține?
Pentru mine, totul pare înfricoșător. Oamenii se confruntă cu probleme complexe și supărătoare și continuă să pretindă că, dacă își încrucișează degetele și speră la ce este mai bun, „cel mai bun” se va întâmpla cu adevărat. Nu, nu funcționează așa.
Practicați managementul riscului!
Michael: În opinia dumneavoastră, câte organizații se angajează în managementul riscului?
Tim: Ceea ce mă enervează este că oamenii pur și simplu notează riscurile, se uită la lista rezultată și merg la muncă. De fapt, identificarea riscurilor pentru ei este managementul riscului. Dar pentru mine acesta mi se pare un motiv să întreb: bine, există o listă, ce anume vei schimba? Trebuie să modificați secvențele standard de acțiuni ținând cont de aceste riscuri. Dacă există o parte cea mai dificilă a muncii, trebuie să o abordați și abia apoi să treceți la ceva mai simplu. În primele sprinturi, începeți să rezolvați probleme complexe. Aceasta arată deja ca managementul riscului. Dar, de obicei, oamenii nu pot spune ce au schimbat după alcătuirea unei liste de riscuri.
Michael: Și totuși, câte dintre aceste companii sunt implicate în managementul riscului, cinci la sută?
Tim: Din păcate, urăsc să spun asta, dar aceasta este o parte foarte nesemnificativă. Dar mai mult de cinci, pentru că există proiecte cu adevărat mari și pur și simplu nu pot exista dacă nu fac măcar ceva. Să spunem doar că voi fi foarte surprins dacă este de cel puțin 25%. Proiectele mici răspund de obicei la astfel de întrebări astfel: dacă problema ne afectează, atunci o vom rezolva. Apoi se bagă cu succes în probleme și se angajează în gestionarea problemelor și a crizelor. Când încerci să rezolvi o problemă și problema nu este rezolvată, bine ai venit la managementul crizelor.
Da, aud adesea, „vom rezolva problemele pe măsură ce vor apărea”. Sigur vom face? Ne vom decide cu adevărat?
Oleg: Puteți să o faceți naiv și să scrieți pur și simplu invarianți importanți în carta proiectului și, dacă invarianții se sparg, trebuie doar să reporniți proiectul. Se dovedește foarte piembucky.
Michael: Da, mi s-a întâmplat ca atunci când au fost declanșate riscuri, proiectul să fie pur și simplu redefinit. Frumos, bingo, problema rezolvata, nu-ti mai face griji!
Tim: Să apăsăm butonul de resetare! Nu, nu funcționează așa.
Keynote la DevOops 2019
Michael: Ajungem la ultima întrebare a acestui interviu. Vii la următorul DevOops cu o prezentare, ai putea ridica cortina secretului asupra a ceea ce vei spune?
Tim: În acest moment, șase dintre ei scriu o carte despre cultura muncii, regulile nerostite ale organizațiilor. Cultura este determinată de valorile de bază ale organizației. De obicei oamenii nu observă acest lucru, dar lucrând în consultanță de mulți ani, suntem obișnuiți să observăm acest lucru. Intri într-o companie și literalmente în câteva minute începi să simți ce se întâmplă. Numim aceasta „aromă”. Uneori, acest parfum este foarte bun, iar uneori este, ei bine, hopa. Lucrurile sunt foarte diferite pentru diferite organizații.
Michael: Și eu lucrez de ani de zile în consultanță și înțeleg bine despre ce vorbești.
Tim: De fapt, unul dintre lucrurile despre care merită să vorbim la keynote este că nu totul este determinat de companie. Tu și echipa ta, ca comunitate, ai propria ta cultură de echipă. Aceasta ar putea fi întreaga companie, sau un departament separat, o echipă separată. Dar înainte de a spune, iată ce credem noi, iată ce este important... Nu poți schimba o cultură înainte ca valorile și credințele din spatele unor acțiuni specifice să fie înțelese. Comportamentul este ușor de observat, dar căutarea credințelor este dificilă. DevOps este doar un exemplu grozav al modului în care lucrurile devin din ce în ce mai complexe. Interacțiunile devin din ce în ce mai complexe, nu devin mai curate sau mai clare deloc, așa că ar trebui să te gândești la ceea ce crezi și la ce tac toți cei din jurul tău.
Dacă vrei să obții rezultate rapide, iată un subiect bun pentru tine: ai văzut companii în care nimeni nu spune „nu știu”? Există locuri în care torturiți o persoană până când acesta recunoaște că nu știe ceva. Toată lumea știe totul, toată lumea este un erudit incredibil. Te apropii de orice persoană, iar el trebuie să răspundă instantaneu la întrebare. În loc să spui „Nu știu”. Ura, au angajat o grămadă de erudiți! Și în unele culturi este în general foarte periculos să spui „nu știu” poate fi perceput ca un semn de slăbiciune. Există și organizații în care, dimpotrivă, toată lumea poate spune „Nu știu”. Acolo este complet legal, iar dacă cineva începe să facă gunoaie ca răspuns la o întrebare, este complet normal să răspunzi: „Nu știi despre ce vorbești, nu?” și transformă totul într-o glumă.
În mod ideal, ți-ar plăcea să ai un loc de muncă în care să fii fericit în mod constant. Nu va fi ușor, nu fiecare zi este însorită și plăcută, uneori trebuie să muncești din greu, dar când vei începe să faci bilanțul, se va dovedi: wow, acesta este un loc cu adevărat minunat, mă simt bine lucrând aici, atât din punct de vedere emoțional cât și intelectual. Și există companii în care mergi ca consultant și îți dai seama imediat că nu ai putea suporta timp de trei luni și ai fugi îngrozit. Despre asta vreau să vorbesc la raport.
Tim Lister va sosi cu o prezentare la conferința DevOops 2019, care va avea loc în perioada 29-30 octombrie 2019 la Sankt Petersburg. Puteți cumpăra bilete . Vă așteptăm la DevOops!
Sursa: www.habr.com