Tim Lister - bashkautor i librave
- “Faktori njerëzor. Projekte dhe ekipe të suksesshme" (libri origjinal quhet "Peopleware")
- "Waltzing with the Bears: Menaxhimi i rrezikut në projektet softuerike"
- “Të çmendur nga adrenalina dhe të zombifikuar nga modelet. Modelet e sjelljes së ekipeve të projektit"
Të gjithë këta libra janë klasikë në fushën e tyre dhe janë shkruar së bashku me kolegët në . Në Rusi, kolegët e tij janë më të famshëm - и , i cili gjithashtu shkroi shumë vepra të famshme.
Tim ka 40 vjet përvojë në zhvillimin e softuerit në 1975 (asnjë nga ata që kanë shkruar këtë habrapost nuk ka lindur këtë vit), Tim ishte tashmë nënkryetar ekzekutiv i Yourdon Inc. Tani ai e kalon kohën duke u konsultuar, duke dhënë mësim dhe duke shkruar, me vizita të herëpashershme konferenca në mbarë botën.
Ne bëmë një intervistë me Tim Lister posaçërisht për Habr. Ai do të hapë konferencën DevOops 2019 dhe ne kemi shumë pyetje, rreth librave dhe më shumë. Intervista kryhet nga Mikhail Druzhinin dhe Oleg Chirukhin nga komiteti i programit të konferencës.
Michael: Mund të thoni disa fjalë për atë që po bëni tani?
Tim: Unë jam kreu i Atlantic Systems Guild. Jemi gjashtë veta në Guild, ne e quajmë veten drejtorë. Tre në SHBA dhe tre në Evropë - kjo është arsyeja pse Guild quhet Atlantik. Ne kemi qenë bashkë për kaq shumë vite sa nuk mund t'i numërosh. Të gjithë kemi specialitetet tona. Unë kam punuar me klientë për dekadën e fundit ose më shumë. Projektet e mia përfshijnë jo vetëm menaxhimin, por edhe vendosjen e kërkesave, planifikimin e projektit dhe vlerësimin. Duket se projektet që fillojnë keq zakonisht përfundojnë keq. Prandaj, ia vlen të siguroheni që të gjitha aktivitetet të jenë vërtet të menduara dhe të koordinuara mirë, që idetë e krijuesve të kombinohen. Ia vlen të mendoni se çfarë po bëni dhe pse. Çfarë strategjish duhet përdorur për të përfunduar projektin.
Unë kam këshilluar klientët në mënyra të ndryshme për shumë vite. Një shembull interesant është një kompani që prodhon robotë për kirurgjinë e gjurit dhe ijeve. Kirurgu nuk operon plotësisht në mënyrë të pavarur, por përdor një robot. Siguria këtu, sinqerisht, është e rëndësishme. Por kur përpiqesh të diskutosh kërkesat me njerëz që janë të fokusuar në zgjidhjen e problemeve... Do të tingëllojë e çuditshme, por në SHBA ka (Administrata Federale e Barnave), e cila licencon produkte si këta robotë. Përpara se të shisni diçka dhe ta përdorni për njerëzit e gjallë, duhet të merrni një licencë. Një nga kushtet është të tregoni kërkesat tuaja, cilat janë testet, si i keni testuar, cilat janë rezultatet e testimit. Nëse i ndryshoni kërkesat, atëherë duhet ta kaloni këtë proces të madh testimi përsëri dhe përsëri. Klientët tanë arritën të përfshijnë dizajnin vizual të aplikacioneve në kërkesat e tyre. Ata kishin pamje të ekranit direkt si pjesë e kërkesave. Duhet t'i nxjerrim jashtë dhe të shpjegojmë se në pjesën më të madhe të gjitha këto programe nuk dinë asgjë për gjunjët dhe ijet, të gjitha këto gjëra me kamerën, etj. Ne duhet të rishkruajmë dokumentet e kërkesave në mënyrë që ato të mos ndryshojnë kurrë, përveç nëse ndryshojnë disa kushte themelore vërtet të rëndësishme. Nëse dizajni vizual nuk është në kërkesat, përditësimi i produktit do të jetë shumë më i shpejtë. Detyra jonë është të gjejmë ato elemente që kanë të bëjnë me operacionet në gju, ijet, shpinën, t'i nxjerrim në dokumente të veçanta dhe të themi se këto do të jenë kërkesat themelore. Le të bëjmë një grup të izoluar kërkesash për operacionet e gjurit. Kjo do të na lejojë të ndërtojmë një grup kërkesash më të qëndrueshme. Ne do të flasim për të gjithë linjën e produkteve, dhe jo për robotë specifikë.
U bë shumë punë, por ata arritën ende në vendet ku më parë kalonin javë e muaj të testeve të përsëritura pa kuptim apo nevojë, sepse kërkesat e tyre të përshkruara në letër nuk përputheshin me kërkesat reale për të cilat ishin ndërtuar sistemet. FDA u thoshte çdo herë: kërkesat tuaja kanë ndryshuar, tani duhet të kontrolloni gjithçka nga e para. Rikontrollimet e plota të të gjithë produktit po e vrisnin ndërmarrjen.
Pra, ka detyra kaq të mrekullueshme kur e gjeni veten në fillimin e diçkaje interesante, dhe veprimet e para vendosin rregullat e mëtejshme të lojës. Nëse siguroheni që ky aktivitet i hershëm të fillojë të funksionojë mirë si nga pikëpamja menaxheriale ashtu edhe nga ajo teknike, ka mundësi që të përfundoni me një projekt të madh. Por nëse kjo pjesë ka dalë nga binarët dhe ka shkuar diku keq, nëse nuk mund të gjeni marrëveshjet themelore... jo, nuk është se projekti juaj do të dështojë domosdoshmërisht. Por nuk do të jeni më në gjendje të thoni: "Ne bëmë shkëlqyeshëm, bëmë gjithçka me të vërtetë efektivisht." Këto janë gjërat që bëj kur komunikoj me klientët.
Michael: Kjo do të thotë, ju nisni projekte, bëni një lloj nisjeje dhe kontrolloni që binarët po shkojnë në drejtimin e duhur?
Tim: Ne gjithashtu kemi ide se si t'i bashkojmë të gjitha pjesët e enigmës: çfarë aftësish na nevojiten, kur saktësisht nevojiten ato, si duket thelbi i ekipit dhe gjëra të tjera të tilla themelore. A kemi nevojë për punonjës me kohë të plotë apo mund të punësojmë dikë me kohë të pjesshme? Planifikimi, menaxhimi. Pyetje si: Çfarë është më e rëndësishme për këtë projekt të veçantë? Si të arrihet kjo? Çfarë dimë për këtë produkt apo projekt, cilat janë rreziqet dhe ku qëndrojnë të panjohurat, si do t'i trajtojmë të gjitha këto? Natyrisht, në këtë moment dikush fillon të bërtasë “Po i shkathët?!” Mirë, ju jeni të gjithë fleksibël, por çfarë? Si duket saktësisht projekti, si do ta nxirrni atë në një mënyrë që i përshtatet projektit? Nuk mund të thuash thjesht se "qasja jonë shtrihet në çdo gjë, ne jemi një ekip Scrum!" Kjo është e pakuptimtë dhe e pakuptimtë. Ku do të shkoni më pas, pse duhet të funksionojë, ku është thelbi? Unë i mësoj klientët e mi të mendojnë për të gjitha këto pyetje.
19 vjet i shkathët
Michael: Në Agile, njerëzit shpesh përpiqen të mos përcaktojnë asgjë paraprakisht, por të marrin vendime sa më vonë të jetë e mundur, duke thënë: ne jemi shumë të mëdhenj, nuk do të mendoj për arkitekturën e përgjithshme. Unë nuk do të mendoj për një mori gjërash të tjera në vend të kësaj, unë do t'i dorëzoj klientit diçka që funksionon tani.
Tim: Unë mendoj se metodologjitë e shkathëta, duke filluar me në 2001, hapi sytë e industrisë. Por nga ana tjetër, asgjë nuk është perfekte. Unë jam i gjithi për zhvillimin përsëritës. Përsëritja ka shumë kuptim në shumicën e projekteve. Por pyetja që duhet të mendoni është: pasi produkti të dalë dhe të përdoret, sa kohë zgjat? A është ky një produkt që do të zgjasë gjashtë muaj përpara se të zëvendësohet me diçka tjetër? Apo është ky një produkt që do të funksionojë për shumë e shumë vite? Sigurisht, nuk do të përmend emra, por... Në Nju Jork dhe komunitetin e tij financiar, sistemet më themelore janë shumë të vjetra. Kjo është e mahnitshme. Ti i shikon dhe mendon, sikur të mund të ktheheshe pas në kohë, në vitin 1994 dhe t'u thuash zhvilluesve: “Kam ardhur nga e ardhmja, nga viti 2019. Thjesht zhvilloni këtë sistem për aq kohë sa ju nevojitet. Bëjeni të zgjerueshëm, mendoni për arkitekturën. Më pas do të përmirësohet për më shumë se njëzet e pesë vjet. Nëse e vononi edhe pak zhvillimin, në skemën e madhe të gjërave askush nuk do ta vërë re!” Kur po i vlerësoni gjërat në terma afatgjatë, duhet të merrni parasysh sa do të kushtojë në total. Ndonjëherë arkitektura e projektuar mirë ia vlen vërtet, dhe ndonjëherë jo. Duhet të shikojmë përreth dhe të pyesim veten: a jemi në situatën e duhur për një vendim të tillë?
Pra, një ide si "Ne jemi për të shkathët, vetë klienti do të na tregojë se çfarë dëshiron të marrë" - është super naive. Klientët as nuk e dinë se çfarë duan, dhe aq më tepër ata nuk e dinë se çfarë mund të marrin. Disa njerëz do të fillojnë të citojnë shembuj historikë si argumente, këtë e kam parë tashmë. Por njerëzit teknikisht të avancuar zakonisht nuk e thonë këtë. Ata thonë: “Është viti 2019, këto janë mundësitë që kemi dhe ne mund të ndryshojmë plotësisht mënyrën se si i shikojmë këto gjëra!” Në vend që të imitoni zgjidhjet ekzistuese, t'i bëni ato pak më të bukura dhe më të krehura, ndonjëherë duhet të dilni dhe të thoni: "Le të rishpikim plotësisht atë që po përpiqemi të bëjmë këtu!"
Dhe nuk mendoj se shumica e klientëve mund të mendojnë për problemin në atë mënyrë. Ata shohin vetëm atë që kanë tashmë, kjo është e gjitha. Pas së cilës ata vijnë me kërkesa si "le ta bëjmë këtë pak më të thjeshtë", ose çfarëdo që ata thonë zakonisht. Por ne nuk jemi kamerierë apo kamariere, kështu që mund të marrim një porosi sado budallaqe të dalë dhe pastaj ta pjekim në kuzhinë. Ne jemi udhërrëfyesit e tyre. Ne duhet t'u hapim sytë dhe të themi: hej, ne kemi mundësi të reja këtu! A e kuptoni se ne mund të ndryshojmë vërtet mënyrën se si bëhet kjo pjesë e biznesit tuaj? Një nga problemet me Agile është se ai heq vetëdijen se çfarë është një mundësi, çfarë është një problem, çfarë duhet të bëjmë ne, cilat teknologji të disponueshme janë më të përshtatshmet për këtë situatë të veçantë.
Ndoshta po tregohem tepër skeptik këtu: ka shumë gjëra të mrekullueshme që ndodhin në komunitetin e shkathët. Por unë kam një problem me faktin që në vend që të përcaktojnë një projekt, njerëzit fillojnë të hedhin duart lart. Unë do të pyesja këtu - çfarë po bëjmë, si do ta bëjmë? Dhe disi në mënyrë magjike rezulton gjithmonë se klienti duhet ta dijë më mirë se kushdo. Por klienti e di më mirë vetëm kur zgjedh nga gjërat e ndërtuara tashmë nga dikush. Nëse dua të blej një makinë dhe e di madhësinë e buxhetit tim familjar, atëherë do të zgjedh shpejt një makinë që i përshtatet stilit tim të jetesës. Këtu unë di gjithçka më mirë se kushdo! Por ju lutemi vini re se dikush i ka bërë tashmë makinat. Nuk e kam idenë se si të shpik një makinë të re, nuk jam ekspert. Kur krijojmë produkte me porosi ose speciale duhet të merret parasysh zëri i klientit, por ky nuk është më zëri i vetëm.
Oleg: Ju përmendët Manifestin e Agile. A duhet ta përditësojmë apo rishikojmë disi duke marrë parasysh kuptimin modern të çështjes?
Tim: Nuk do ta prekja. Mendoj se është një dokument i madh historik. Dua të them, ai është ai që është. Bëhet 19 vjeç, është plak, por në kohën e tij bëri revolucion. Ajo që bëri mirë ishte se shkaktoi një reagim dhe njerëzit filluan të pëshpërisnin për të. Ju, me shumë mundësi, nuk keni qenë ende duke punuar në industri në 2001, por atëherë të gjithë kanë punuar sipas proceseve. Instituti i Inxhinierisë Softuerike, pesë nivele të modelit të plotësisë së softuerit (CMMI). Nuk e di nëse legjenda të tilla të lashtësisë së thellë ju tregojnë diçka, por atëherë ishte një zbulim. Në fillim, njerëzit besuan se nëse proceset do të vendoseshin siç duhet, atëherë problemet do të zhdukeshin vetë. Dhe pastaj vjen Manifesti dhe thotë: "Jo, jo, jo - ne do të bazojmë në njerëz, jo në procese". Ne jemi mjeshtër të zhvillimit të softuerit. Ne e kuptojmë se procesi ideal është një mirazh, ai nuk ndodh. Ka shumë idiosinkrasi në projekte, ideja e një procesi të vetëm të përsosur për të gjitha projektet nuk ka kuptim. Problemet janë shumë komplekse për të pretenduar se ka vetëm një zgjidhje për gjithçka (përshëndetje, nirvana).
Nuk supozoj të shikoj në të ardhmen, por do të them se njerëzit tani kanë filluar të mendojnë më shumë për projektet. Unë mendoj se Manifesti i shkathët është shumë i mirë për të kërcyer dhe për të thënë: “Hej! Ju jeni në një anije dhe ju vetë po e drejtoni këtë anije. Ju do të duhet të merrni një vendim - ne nuk do të sugjerojmë një recetë universale për të gjitha situatat. Ju jeni ekuipazhi i anijes dhe nëse jeni mjaft të mirë, mund të gjeni një rrugë drejt qëllimit tuaj. Ka pasur anije të tjera para jush, dhe do të ketë anije të tjera pas jush, por megjithatë, në një farë kuptimi, udhëtimi juaj është unik.” Diçka e tillë! Është një mënyrë të menduari. Për mua, nuk ka asgjë të re nën diell, njerëzit kanë lundruar më parë dhe do të lundrojnë përsëri, por për ju ky është udhëtimi juaj kryesor dhe nuk do t'ju them se çfarë saktësisht do të ndodhë me ju. Ju duhet të keni aftësitë e punës së koordinuar në një ekip dhe nëse i keni ato vërtet, gjithçka do të funksionojë dhe do të arrini atje ku keni dashur.
Peopleware: 30 vjet më vonë
Oleg: A ishte Peopleware një revolucion si dhe Manifesti?
Tim: Peopleware... Tom dhe unë shkruam këtë libër, por nuk e kishim menduar se do të ndodhte kështu. Në një farë mënyre rezononte me idetë e shumë njerëzve. Ky ishte libri i parë që thoshte: zhvillimi i softuerit është një aktivitet shumë intensiv njerëzor. Pavarësisht natyrës sonë teknike, ne jemi gjithashtu një komunitet njerëzish që ndërtojmë diçka të madhe, madje të madhe, shumë komplekse. Askush nuk mund të krijojë gjëra të tilla vetëm, apo jo? Kështu që ideja e "ekipit" u bë shumë e rëndësishme. Dhe jo vetëm nga pikëpamja e menaxhimit, por edhe për njerëzit teknikë që u mblodhën për të zgjidhur probleme vërtet komplekse të thella me një mori të panjohurash. Për mua personalisht, ky ka qenë një test i madh inteligjence gjatë gjithë karrierës sime. Dhe këtu duhet të jeni në gjendje të thoni: po, ky problem është më shumë se sa mund ta përballoj vetë, por së bashku mund të gjejmë një zgjidhje elegante për të cilën mund të krenohemi. Dhe mendoj se ishte kjo ide që rezonoi më shumë. Ideja që ne punojmë një pjesë të kohës vetë, një pjesë të kohës si pjesë e një grupi dhe shpesh vendimin e merr grupi. Zgjidhja e problemeve në grup është bërë shpejt një tipar i rëndësishëm i projekteve komplekse.
Pavarësisht se Tim ka mbajtur një numër të madh bisedash, shumë pak prej tyre janë postuar në YouTube. Ju mund të shikoni raportin "Kthimi i Peopleware" nga 2007. Cilësia, natyrisht, lë shumë për të dëshiruar.
Michael: A ka ndryshuar ndonjë gjë në 30 vitet e fundit që nga botimi i librit?
Tim: Ju mund ta shikoni këtë nga shumë këndvështrime të ndryshme. Sociologjikisht... dikur, në kohë më të thjeshta, ju dhe ekipi juaj uleni në të njëjtën zyrë. Mund të jeni afër çdo ditë, të pini kafe së bashku dhe të diskutoni për punën. Ajo që ka ndryshuar me të vërtetë është se ekipet tani mund të shpërndahen gjeografikisht, në vende dhe zona kohore të ndryshme, por megjithatë ata po punojnë për të njëjtin problem, dhe kjo shton një shtresë krejtësisht të re kompleksiteti. Kjo mund të tingëllojë si e vjetër, por nuk ka asgjë si komunikimi ballë për ballë ku jeni të gjithë bashkë, punoni së bashku, dhe mund të shkoni te një koleg dhe t'i thoni, shikoni çfarë zbulova, si ju pëlqen kjo? Bisedat ballë për ballë ofrojnë një mënyrë të shpejtë për të kaluar në komunikim joformal dhe mendoj se edhe entuziastët e shkathët duhet ta pëlqejnë atë. Dhe unë jam gjithashtu i shqetësuar sepse në realitet bota ka rezultuar shumë e vogël, dhe tani është e gjitha e mbuluar me ekipe të shpërndara, dhe gjithçka është shumë komplekse.
Ne të gjithë jetojmë në DevOps
Michael: Edhe nga këndvështrimi i komitetit të programit të konferencës, ne kemi njerëz në Kaliforni, në Nju Jork, Evropë, Rusi... nuk ka ende njeri në Singapor. Dallimi në gjeografi është mjaft i madh dhe njerëzit kanë filluar të përhapen edhe më shumë. Nëse po flasim për zhvillim, a mund të na thoni më shumë për devops dhe thyerjen e barrierave midis ekipeve? Ekziston një koncept që të gjithë janë ulur në bunkerët e tyre, dhe tani bunkerët po shemben, çfarë mendoni për këtë analogji?
Tim: Më duket se në dritën e përparimeve të fundit teknologjike, devops ka një rëndësi të madhe. Më parë, ju kishit ekipe zhvilluesish dhe administratorësh, ata punonin, punonin, punuan dhe në një moment u shfaq një gjë me të cilën mund të vinit te administratorët dhe ta nxirrnit për prodhim. Dhe këtu filloi biseda për bunkerin, sepse administratorët janë njëfarë aleate, jo armiq, të paktën, por ju biseduat me ta vetëm kur gjithçka ishte gati për të shkuar në prodhim. A shkuat tek ata me diçka dhe u tha: shikoni çfarë aplikacioni kemi, por a mund ta hapni këtë aplikacion? Dhe tani i gjithë koncepti i dorëzimit ka ndryshuar për mirë. Dua të them, ekzistonte kjo ide që ju mund të kaloni shpejt ndryshimet. Ne mund të përditësojmë produktet menjëherë. Unë buzëqesh gjithmonë kur Firefox-i në laptop shfaqet dhe thotë, hej, ne e kemi përditësuar Firefox-in tuaj në sfond, dhe sapo të keni një minutë, a do t'ju shkonte të klikoni këtu dhe ne do t'ju japim versionin më të fundit. Dhe unë thashë: "Oh po, fëmijë!" Ndërsa isha duke fjetur, ata po punonin për të më dhënë një version të ri direkt në kompjuterin tim. Kjo është e mrekullueshme, e pabesueshme.
Por këtu është vështirësia: ju e keni këtë veçori me përditësimin e softuerit, por integrimi i njerëzve është shumë më i vështirë. Ajo që dua të shpreh në fjalimin kryesor të DevOops është se tani kemi shumë më shumë lojtarë sesa kemi pasur ndonjëherë. Nëse mendoni për të gjithë të përfshirë në vetëm një ekip…. E keni menduar si një ekip, dhe është shumë më tepër sesa thjesht një ekip programuesish. Këta janë testues, menaxherë projektesh dhe një mori njerëzish të tjerë. Dhe secili ka pikëpamjet e veta për botën. Menaxherët e produkteve janë krejtësisht të ndryshëm nga menaxherët e projektit. Administratorët kanë detyrat e tyre. Bëhet një problem mjaft i vështirë për të koordinuar të gjithë pjesëmarrësit në mënyrë që të vazhdojnë të jenë të vetëdijshëm për atë që po ndodh dhe të mos çmenden. Është e nevojshme të ndahen detyrat e grupit dhe detyrat që vlejnë për të gjithë. Kjo është një detyrë shumë e vështirë. Nga ana tjetër, mendoj se gjithçka është shumë më mirë se sa ishte shumë vite më parë. Kjo është pikërisht rruga në të cilën njerëzit rriten dhe mësojnë të sillen si duhet. Kur bëni integrimin, kuptoni që nuk duhet të ketë zhvillim nëntokësor, në mënyrë që në momentin e fundit softueri të mos zvarritet si një jack-in-the-box: si, shikoni çfarë bëmë këtu! Ideja është që ju do të jeni në gjendje të bëni integrim dhe zhvillim, dhe në fund do të hapeni në një mënyrë të rregullt dhe përsëritëse. E gjithë kjo do të thotë shumë për mua. Kjo bën të mundur krijimin e më shumë vlerave për përdoruesit e sistemit dhe për klientin tuaj.
Michael: E gjithë ideja e devops është të ofrojë zhvillime domethënëse sa më shpejt që të jetë e mundur. Unë shoh që bota ka filluar të përshpejtohet gjithnjë e më shumë. Si të përshtatemi me përshpejtime të tilla? Dhjetë vjet më parë kjo nuk ekzistonte!
Tim: Sigurisht, të gjithë duan gjithnjë e më shumë funksionalitet. Nuk ka nevojë të lëvizni, thjesht grumbulloni më shumë. Ndonjëherë ju madje duhet të ngadalësoni për përditësimin e radhës në rritje për të sjellë ndonjë gjë të dobishme - dhe kjo është krejtësisht normale.
Ideja që ju duhet të vraponi, vraponi, vraponi nuk është më e mira. Nuk ka gjasa që dikush të dëshirojë ta jetojë jetën e tij kështu. Do të doja që ritmi i dërgesave të vendoste ritmin e vetë projektit. Nëse thjesht prodhoni një rrjedhë gjërash të vogla, relativisht të pakuptimta, të gjitha nuk kanë kuptim. Në vend që të përpiqeni pa mendje t'i lëshoni gjërat sa më shpejt që të jetë e mundur, ajo që ia vlen të diskutohet me zhvilluesit kryesorë dhe menaxherët e produkteve dhe projekteve është strategjia. A ka kuptim kjo?
Modelet dhe antipatternet
Oleg: Zakonisht flisni për modele dhe antimodele, dhe ky është ndryshimi midis jetës dhe vdekjes së projekteve. Dhe tani, shpërthejnë në jetën tonë. A ka ndonjë nga modelet dhe anti-modelet e veta që mund ta vrasin projektin në vend?
Tim: Modelet dhe anti-modelet ndodhin gjatë gjithë kohës. Diçka për të folur. Epo, është kjo gjë që ne e quajmë "gjëra me shkëlqim". Njerëzit me të vërtetë e pëlqejnë shumë teknologjinë e re. Ata thjesht magjepsen nga shkëlqimi i gjithçkaje që duket e lezetshme dhe me stil, dhe nuk bëjnë më pyetje: a është edhe e nevojshme? Çfarë do të arrijmë? A është e besueshme kjo gjë, a ka ndonjë kuptim? Unë shpesh shoh njerëz, si të thuash, në avantazhin e teknologjisë. Ata janë të hipnotizuar nga ajo që po ndodh në botë. Por nëse shikoni më nga afër se çfarë gjërash të dobishme bëjnë, shpesh thjesht nuk ka asgjë të dobishme!
Sapo diskutonim me shokët se ky vit është një përvjetor, pesëdhjetë vjet që kur njerëzit zbritën në hënë. Kjo ishte në vitin 1969. Teknologjia që i ndihmoi njerëzit të arrinin atje nuk është as teknologjia e vitit 1969, por më tepër e vitit 1960 ose 62, sepse NASA donte të përdorte vetëm atë që kishte prova të mira të besueshmërisë. Dhe kështu ju e shikoni atë dhe kuptoni - po, dhe ato ishin të vërteta! Tani, jo, jo, por ju futeni në probleme me teknologjinë thjesht sepse gjithçka shtyhet shumë, shitet nga të gjitha të çarat. Njerëzit bërtasin nga kudo: "Shiko, çfarë gjëje, kjo është gjëja më e re, gjëja më e bukur në botë, e përshtatshme për absolutisht të gjithë!" Epo, kjo është ajo ... zakonisht e gjithë kjo rezulton të jetë vetëm një mashtrim, dhe pastaj e gjitha duhet të hidhet tutje. Ndoshta kjo është e gjitha sepse unë jam tashmë një plak dhe i shikoj këto gjëra me një skepticizëm të madh, kur njerëzit mbarojnë dhe thonë se kanë gjetur mënyrën e vetme, më të saktë për të krijuar teknologjitë më të mira. Në këtë moment, një zë zgjohet brenda meje që thotë: "Çfarë rrëmujë!"
Michael: Në të vërtetë, sa shpesh kemi dëgjuar për plumbin e ardhshëm të argjendtë?
Tim: Pikërisht, dhe kjo është rrjedha e zakonshme e gjërave! Për shembull... duket se kjo tashmë është bërë shaka nëpër botë, por këtu njerëzit shpesh flasin për teknologjinë blockchain. Dhe në fakt kanë kuptim në situata të caktuara! Kur keni vërtet nevojë për prova të besueshme të ngjarjeve, që sistemi funksionon dhe se askush nuk na mashtroi, kur keni probleme sigurie dhe të gjitha ato gjëra të përziera së bashku - blockchain ka kuptim. Por kur thonë se Blockchain tani do të përfshijë botën, duke fshirë gjithçka në rrugën e tij? Ëndërro më shumë! Kjo është një teknologji shumë e shtrenjtë dhe komplekse. Teknikisht komplekse dhe kërkon kohë. Përfshirë thjesht algoritmikisht, çdo herë që ju duhet të rillogaritni matematikën, me ndryshimet më të vogla... dhe kjo është një ide e mrekullueshme - por vetëm për raste të caktuara. E gjithë jeta dhe karriera ime ka qenë rreth kësaj: ide interesante në situata shumë specifike. Është shumë e rëndësishme të kuptoni saktësisht se cila është situata juaj.
Michael: Po, "pyetja kryesore e jetës, universit dhe gjithçkaje": a është kjo teknologji apo qasje e përshtatshme për situatën tuaj apo jo?
Tim: Kjo pyetje tashmë mund të diskutohet me grupin e teknologjisë. Ndoshta edhe sillni ndonjë konsulent. Hidhini një sy projektit dhe kuptoni - a do të bëjmë tani diçka të drejtë dhe të dobishme, më mirë se më parë? Ndoshta do të përshtatet, ndoshta jo. Por më e rëndësishmja, mos e merrni një vendim të tillë si parazgjedhje, thjesht sepse dikush tha: "Ne kemi nevojë dëshpërimisht për një blockchain! Sapo lexova për të në një revistë në aeroplan!” Seriozisht? Nuk është as qesharake.
"Inxhinieri devops" mitik
Oleg: Tani të gjithë po zbatojnë devops. Dikush lexon për devops në internet, dhe nesër një vend tjetër vakant shfaqet në një faqe rekrutimi. "inxhinier i devops". Këtu do të doja të tërhiqja vëmendjen tuaj: a mendoni se ky term, "inxhinier zhvillon", ka të drejtë për jetë? Ekziston një mendim se devops është një kulturë, dhe diçka nuk shtohet këtu.
Tim: Kështu-kaq. Le të japin menjëherë një shpjegim të këtij termi. Diçka për ta bërë atë unike. Derisa të provojnë se ekziston një kombinim unik i aftësive pas një vendi vakant si ky, unë nuk do ta blej atë! Dua të them, mirë, ne kemi një titull pune, "inxhinier devops", një titull interesant, po, çfarë më pas? Titujt e punës janë përgjithësisht një gjë shumë interesante. Le të themi "zhvillues" - çfarë është gjithsesi? Organizata të ndryshme nënkuptojnë gjëra krejtësisht të ndryshme. Në disa kompani, programuesit me cilësi të lartë shkruajnë teste që kanë më shumë kuptim sesa testet e shkruara nga testues profesionistë të veçantë në kompani të tjera. Pra, çfarë, janë ata tani programues apo testues?
Po, ne kemi tituj pune, por nëse bëni pyetje mjaft gjatë, përfundimisht rezulton se ne të gjithë jemi zgjidhës të problemeve. Ne jemi kërkues zgjidhje, dhe disa kanë disa aftësi teknike dhe disa kanë të ndryshme. Nëse jetoni në një mjedis ku DevOps ka depërtuar, jeni të angazhuar në integrimin e zhvillimit dhe administrimit dhe ky aktivitet ka një qëllim mjaft të rëndësishëm. Por nëse pyeteni se çfarë bëni saktësisht dhe për çfarë jeni përgjegjës, rezulton se njerëzit i kanë bërë të gjitha këto gjëra që nga kohra të lashta. "Unë jam përgjegjës për arkitekturën", "Unë jam përgjegjës për bazat e të dhënave" dhe kështu me radhë, sido që të shihni - e gjithë kjo ishte përpara "devops".
Kur dikush më thotë titullin e punës, nuk dëgjoj shumë. Është më mirë ta lini atë t'ju tregojë se për çfarë është në të vërtetë përgjegjës, kjo do të na lejojë ta kuptojmë çështjen shumë më mirë. Shembulli im i preferuar është kur një person pretendon të jetë "menaxher projekti". Çfarë? Nuk do të thotë asgjë, unë ende nuk e di se çfarë bëni. Një menaxher projekti mund të jetë një zhvillues, udhëheqës i një ekipi prej katër personash, duke shkruar kode, duke bërë punë, i cili është bërë drejtues ekipi, të cilin vetë njerëzit e njohin mes tyre si udhëheqës. Dhe gjithashtu, një menaxher projekti mund të jetë një menaxher që menaxhon gjashtëqind njerëz në një projekt, menaxhon menaxherë të tjerë, është përgjegjës për hartimin e planeve dhe planifikimin e buxheteve, kjo është e gjitha. Këto janë dy botë krejtësisht të ndryshme! Por titulli i tyre i punës tingëllon i njëjtë.
Le ta kthejmë këtë pak më ndryshe. Për çfarë jeni vërtet i mirë, keni shumë përvojë, a keni talent? Për çfarë do të merrni përgjegjësi sepse mendoni se mund ta përballoni detyrën? Dhe këtu dikush do të fillojë menjëherë të mohojë: jo, jo, jo, nuk kam dëshirë të merrem fare me burimet e projektit, nuk është puna ime, unë jam një tip teknik dhe e kuptoj përdorshmërinë dhe ndërfaqet e përdoruesit, nuk e kuptoj dua të menaxhoj fare ushtri njerëzish, më lër të shkoj më mirë në punë.
Dhe meqë ra fjala, unë jam një përkrahës i madh i një qasjeje në të cilën kjo lloj ndarje e aftësive funksionon mirë. Ku teknikët mund të rritin karrierën e tyre aq sa duan. Megjithatë, unë ende shoh organizata ku ankohen teknikët: do të më duhet të shkoj në menaxhimin e projektit sepse kjo është e vetmja mënyrë në këtë kompani. Ndonjëherë kjo çon në rezultate të tmerrshme. Teknikët më të mirë nuk janë aspak menaxherë të mirë dhe menaxherët më të mirë nuk mund të përballojnë teknologjinë. Le të jemi të sinqertë për këtë.
Unë shoh shumë kërkesa për këtë tani. Nëse jeni teknik, kompania juaj mund t'ju ndihmojë, por pavarësisht kësaj, ju duhet, me të vërtetë duhet të gjeni rrugën tuaj të karrierës, sepse teknologjia vazhdon të ndryshojë dhe ju duhet të rishpikni veten së bashku me të! Në vetëm njëzet vjet, teknologjitë mund të ndryshojnë të paktën pesë herë. Teknologjia është një gjë e çuditshme...
"Ekspertë për gjithçka"
Michael: Si mund të përballen njerëzit me një shpejtësi të tillë të ndryshimit të teknologjisë? Kompleksiteti i tyre po rritet, numri i tyre po rritet, sasia totale e komunikimit midis njerëzve po rritet gjithashtu dhe rezulton se nuk mund të bëheni "ekspert në gjithçka".
Tim: E drejtë! Nëse punoni në teknologji, po, patjetër që duhet të zgjidhni diçka specifike dhe të thelloheni në të. Disa teknologji që organizata juaj i gjen të dobishme (dhe ndoshta në të vërtetë do të jetë e dobishme). Dhe nëse nuk jeni më të interesuar për të - nuk do ta kisha besuar kurrë se do ta thoja këtë - mirë, ndoshta duhet të kaloni në ndonjë organizatë tjetër ku teknologjia është më interesante ose më e përshtatshme për t'u studiuar.
Por në përgjithësi, po, keni të drejtë. Teknologjitë po rriten në të gjitha drejtimet në të njëjtën kohë, askush nuk mund të thotë "Unë jam një teknolog ekspert në të gjitha teknologjitë që ekzistojnë". Nga ana tjetër, ka njerëz sfungjer që thithin fjalë për fjalë njohuritë teknologjike dhe janë të çmendur pas saj. Unë kam parë disa njerëz të tillë, ata fjalë për fjalë marrin frymë dhe e jetojnë atë, është e dobishme dhe interesante të flasësh me ta. Ata studiojnë jo vetëm atë që po ndodh brenda organizatës, por në përgjithësi, ata flasin për të, ata janë gjithashtu teknologë shumë të lezetshëm, ata janë shumë të ndërgjegjshëm dhe të qëllimshëm. Ata thjesht përpiqen të qëndrojnë në kreshtën e valës, pavarësisht se cila është puna e tyre kryesore, sepse pasioni i tyre është lëvizja e Teknologjisë, promovimi i teknologjisë. Nëse papritmas takoni një person të tillë, duhet të shkoni në drekë me të dhe të diskutoni gjëra të ndryshme të lezetshme gjatë drekës. Unë mendoj se çdo organizatë ka nevojë për të paktën disa njerëz të tillë.
Rreziqet dhe pasiguria
Michael: Inxhinierë të nderuar, po. Le të prekim menaxhimin e rrezikut sa të kemi kohë. Ne e filluam këtë intervistë me një diskutim të softuerit mjekësor, ku gabimet mund të çojnë në pasoja të tmerrshme. Pastaj folëm për Programin Hënor, ku kostoja e një gabimi është miliona dollarë, dhe ndoshta disa jetë njerëzore. Por tani shoh lëvizjen e kundërt në industri, njerëzit nuk mendojnë për rreziqet, nuk përpiqen t'i parashikojnë ato, as nuk i vëzhgojnë ato.
Oleg: Lëvizni shpejt dhe thyeni gjërat!
Michael: Po, lëviz shpejt, thyej gjëra, gjithnjë e më shumë gjëra, derisa të vdesësh nga diçka. Nga këndvështrimi juaj, si duhet t'i qaset një zhvilluesi mesatar të mësojë menaxhimin e rrezikut tani?
Tim: Le të bëjmë një vijë këtu midis dy gjërave: rreziqeve dhe pasigurisë. Këto janë gjëra të ndryshme. Pasiguria ndodh kur nuk keni të dhëna të mjaftueshme në një moment të caktuar kohor për të arritur në një përgjigje përfundimtare. Për shembull, në fazën shumë të hershme të një projekti, nëse dikush ju pyet "kur do ta përfundoni punën", nëse jeni një person mjaft i ndershëm, do të thoni: "Nuk e kam idenë". Ju thjesht nuk e dini, dhe kjo është në rregull. Nuk i keni studiuar ende problemet dhe nuk jeni njohur me ekipin, nuk i njihni aftësitë e tyre, etj. Kjo është pasiguri.
Rreziqet lindin kur problemet e mundshme tashmë mund të identifikohen. Kjo lloj gjëje mund të ndodhë, probabiliteti i saj është më i madh se zero, por më pak se njëqind për qind, diku në mes. Për shkak të saj, çdo gjë mund të ndodhë, nga vonesat dhe puna e panevojshme, por edhe deri në një përfundim fatal për projektin. Rezultati, kur thoni - djema, le të palosim cadrat dhe të largohemi nga plazhi, nuk do ta mbarojmë kurrë, gjithçka ka mbaruar, pika. Ne supozuam se kjo gjë do të funksiononte, por nuk funksionon fare, është koha të ndalemi. Këto janë situatat.
Shpesh, problemet janë më të lehta për t'u zgjidhur kur ato janë shfaqur tashmë, kur problemi po ndodh pikërisht tani. Por kur një problem është pikërisht para jush, ju nuk po bëni menaxhim të rrezikut - po bëni zgjidhjen e problemeve, menaxhimin e krizës. Nëse jeni një zhvillues ose menaxher kryesor, duhet të pyesni veten se çfarë mund të ndodhë që do të çonte në vonesa, humbje kohe, kosto të panevojshme ose në kolaps të të gjithë projektit? Çfarë do të na bëjë të ndalemi dhe të fillojmë nga e para? Kur të gjitha këto gjëra të funksionojnë, çfarë do të bëjmë me to? Ekziston një përgjigje e thjeshtë që vlen për shumicën e situatave: mos u ikni nga rreziqet, punoni me to. Shihni se si mund ta zgjidhni një situatë të rrezikshme, ta reduktoni atë në asgjë, ta ktheni nga një problem në diçka tjetër. Në vend që të themi: mirë, ne do t'i zgjidhim problemet ashtu siç lindin.
Pasiguria dhe rreziku duhet të jenë në krye të gjithçkaje me të cilën përballeni. Ju mund të merrni një plan projekti, të shikoni disa rreziqe kritike përpara kohe dhe të thoni: ne duhet të merremi me këtë tani, sepse nëse ndonjë nga këto shkon keq, asgjë tjetër nuk do të ketë rëndësi. Nuk duhet të shqetësoheni për bukurinë e mbulesës së tavolinës në tavolinë nëse është e paqartë nëse mund të gatuani darkë. Së pari ju duhet të identifikoni të gjitha rreziqet e përgatitjes së një darke të shijshme, të merreni me to dhe vetëm atëherë të mendoni për të gjitha gjërat e tjera që nuk përbëjnë një kërcënim real.
Përsëri, çfarë e bën projektin tuaj unik? Le të shohim se çfarë mund ta bëjë projektin tonë të dalë jashtë binarëve. Çfarë mund të bëjmë për të minimizuar gjasat që kjo të ndodhë? Zakonisht nuk mund t'i neutralizoni 100% dhe të deklaroni me ndërgjegje të pastër: "Kjo është, ky nuk është më problem, rreziku është zgjidhur!" Për mua kjo është një shenjë e sjelljes së të rriturve. Ky është ndryshimi midis një fëmije dhe një të rrituri - fëmijët mendojnë se janë të pavdekshëm, se asgjë nuk mund të shkojë keq, gjithçka do të jetë mirë! Në të njëjtën kohë, të rriturit shikojnë se si fëmijët trevjeçarë kërcejnë në shesh lojërash, ndjekin lëvizjet me sy dhe thonë me vete: "ooh-ooh, ooh-ooh". Unë qëndroj afër dhe bëhem gati të kap kur fëmija të bjerë.
Nga ana tjetër, arsyeja pse më pëlqen kaq shumë ky biznes është sepse është i rrezikshëm. Ne bëjmë gjëra, dhe ato gjëra janë të rrezikshme. Ata kërkojnë një qasje të rritur. Vetëm entuziazmi nuk do t'i zgjidhë problemet tuaja!
Mendimi inxhinierik i të rriturve
Michael: Shembulli me fëmijët është i mirë. Nëse jam një inxhinier i zakonshëm, atëherë jam i kënaqur që jam fëmijë. Por si të lëvizni drejt të menduarit më të rritur?
Tim: Një nga idetë që funksionon po aq mirë me një fillestar ose një zhvillues të themeluar është koncepti i kontekstit. Çfarë po bëjmë, çfarë do të arrijmë. Çfarë është vërtet e rëndësishme në këtë projekt? Nuk ka rëndësi se kush jeni në këtë projekt, nëse jeni praktikant apo kryearkitekt, të gjithë kanë nevojë për kontekst. Ne duhet t'i bëjmë të gjithë të mendojnë në një shkallë më të madhe sesa pjesët e tyre të punës. "Unë e bëj pjesën time dhe për sa kohë që pjesa ime funksionon, unë jam i lumtur." Jo dhe jo përsëri. Gjithmonë ia vlen (pa qenë i vrazhdë!) t'u kujtoni njerëzve kontekstin në të cilin ata punojnë. Ajo që ne të gjithë po përpiqemi të arrijmë së bashku. Idetë se mund të jesh fëmijë për sa kohë që gjithçka është në rregull me pjesën tënde të projektit - të lutem, mos e bëj këtë. Nëse e kalojmë fare vijën e finishit, do ta kalojmë vetëm bashkë. Ju nuk jeni vetëm, ne jemi të gjithë bashkë. Nëse të gjithë njerëzit në projekt, të moshuar dhe të rinj, filluan të flasin për atë që saktësisht është e rëndësishme për projektin, pse kompania po investon para në atë që ne të gjithë po përpiqemi të arrijmë... shumica prej tyre do të ndihen shumë më mirë sepse ata do të shohin se si puna e tyre lidhet me punën e të gjithë të tjerëve. Nga njëra anë, e kuptoj pjesën për të cilën jam personalisht përgjegjës. Por për të përfunduar punën na duhen edhe të gjithë njerëzit e tjerë. Dhe nëse vërtet mendoni se keni mbaruar, ne kemi gjithmonë punë për të bërë në projekt!
Oleg: Relativisht, nëse punoni sipas Kanban, kur arrini në fytin e ngushtë të disa testimeve, mund të hiqni dorë nga ajo që po bënit atje (për shembull, programimi) dhe të shkoni të ndihmoni testuesit.
Tim: Pikërisht. Unë mendoj se teknikët më të mirë, nëse i shikoni nga afër, ata janë disi menaxherët e tyre. Si mund ta formuloj këtë...
Oleg: Jeta juaj është projekti juaj, të cilin ju e menaxhoni.
Tim: Pikërisht! Dua të them, ju merrni përgjegjësi, e kuptoni çështjen dhe vini në kontakt me njerëzit kur shihni se vendimet tuaja mund të ndikojnë në punën e tyre, gjëra të tilla. Nuk ka të bëjë vetëm me uljen në tavolinën tuaj, të bëni punën tuaj dhe madje të mos kuptoni se çfarë po ndodh rreth jush. Jo jo jo. Meqë ra fjala, një nga gjërat më të mira të Agile është se ata propozuan sprinte të shkurtra, sepse në këtë mënyrë gjendja e punëve të të gjithë pjesëmarrësve është qartë e dukshme, ata mund t'i shohin të gjitha së bashku. Ne flasim për njëri-tjetrin çdo ditë.
Si të futeni në menaxhimin e rrezikut
Oleg: A ka ndonjë strukturë formale njohurish në këtë fushë? Për shembull, unë jam një zhvillues Java dhe dua të kuptoj menaxhimin e rrezikut pa u bërë një menaxher i vërtetë i projektit nga arsimi. Me siguri do të lexoj fillimisht "Sa kushton një projekt softuerësh" të McConnell dhe më pas çfarë? Cilat janë hapat e parë?
Tim: E para është të filloni të komunikoni me njerëzit në projekt. Kjo siguron një përmirësim të menjëhershëm në kulturën e komunikimit me kolegët. Ne duhet të fillojmë duke hapur gjithçka si parazgjedhje, në vend që ta fshehim atë. Thuaj: këto janë gjërat që më shqetësojnë, këto janë gjërat që më mbajnë zgjuar natën, sot u zgjova natën dhe thashë: Zoti im, duhet të mendoj për këtë! A shohin të tjerët të njëjtën gjë? Si grup, a duhet t'u përgjigjemi këtyre problemeve të mundshme? Ju duhet të jeni në gjendje të mbështesni një diskutim mbi këto tema. Nuk ka asnjë formulë të përgatitur paraprakisht me të cilën ne punojmë. Nuk bëhet fjalë për të bërë hamburger, por për njerëzit. "Bëj një cheeseburger, shes një cheeseburger" nuk është fare gjëja jonë dhe prandaj e dua shumë këtë punë. Më pëlqen kur gjithçka që bënin menaxherët tani bëhet pronë e ekipit.
Oleg: Ju keni folur në libra dhe intervista se si njerëzit kujdesen më shumë për lumturinë sesa për numrat në grafik. Nga ana tjetër, kur i thoni ekipit: ne po kalojmë në devops, dhe tani programuesi duhet të komunikojë vazhdimisht, kjo mund të jetë shumë jashtë zonës së tij të rehatisë. Dhe në këtë moment ai mund, le të themi, të jetë thellësisht i pakënaqur. Çfarë duhet bërë në këtë situatë?
Tim: Nuk jam i sigurt se çfarë të bëj saktësisht. Nëse një zhvillues është shumë i izoluar, ata nuk e kuptojnë se përse po bëhet puna në radhë të parë, ata thjesht shikojnë pjesën e tyre të punës dhe duhet të futen në atë që unë e quaj "kontekst". Ai duhet të kuptojë se si gjithçka është e lidhur së bashku. Dhe sigurisht, nuk e kam fjalën për prezantime formale apo diçka të tillë. E kam fjalën për faktin që duhet të komunikosh me kolegët për punën në tërësi dhe jo vetëm për pjesën e saj për të cilën je përgjegjës. Këtu mund të filloni të diskutoni idetë, marrëveshjet e përbashkëta për ta bërë punën tuaj të përshtatet mirë së bashku dhe si të trajtoni një problem të përbashkët së bashku.
Për t'i ndihmuar ata të përshtaten, ata shpesh duan të dërgojnë teknikë në trajnim dhe diskutojnë për trajnimin. Një mikut tim i pëlqen të thotë se trajnimi është për qentë. Ka trajnime për njerëzit. Një nga gjërat më të mira të të mësuarit si zhvillues është bashkëveprimi me bashkëmoshatarët tuaj. Nëse dikush është vërtet i mirë në diçka, duhet ta shikoni duke punuar ose të flisni me të për punën e tyre ose diçka tjetër. Disa Kent Beck konvencionale foli vazhdimisht për programim ekstrem. Është qesharake sepse XP është një ide kaq e thjeshtë, por shkakton kaq shumë probleme. Për disa, të bësh XP është si të detyrohesh të zhvishesh lakuriq para miqve. Ata do të shohin se çfarë po bëj! Ata janë kolegët e mi, jo vetëm do të shohin, por edhe do të kuptojnë! E tmerrshme! Disa njerëz kanë filluar të nervozohen seriozisht. Por kur kupton se kjo është mënyra më e mirë për të mësuar, gjithçka ndryshon. Ju punoni ngushtë me njerëzit dhe disa njerëz e kuptojnë temën shumë më mirë se ju.
Michael: Por e gjithë kjo ju detyron të dilni nga zona juaj e rehatisë. Si inxhinier, ju duhet të dilni nga zona juaj e rehatisë dhe të komunikoni. Si zgjidhës problemesh, duhet ta vendosni vazhdimisht veten në një pozicion të dobët dhe të mendoni se çfarë mund të shkojë keq. Kjo lloj pune është krijuar në thelb për të qenë një telash. Me vetëdije e vendosni veten në situata stresuese. Zakonisht njerëzit ikin prej tyre, njerëzve u pëlqen të jenë fëmijë të lumtur.
Tim: Çfarë mund të bëhet, mund të dalësh dhe të thuash hapur: “Gjithçka është në rregull, unë mund ta përballoj! Nuk jam i vetmi që ndihet i pakëndshëm. Le të diskutojmë gjëra të ndryshme të pakëndshme, të gjithë së bashku, si ekip!” Këto janë problemet tona të përbashkëta, ne duhet të merremi me to, e dini? Unë mendoj se zhvilluesit gjenialë idiosinkratikë janë si mamuthët, ata u zhdukën. Dhe rëndësia e tyre është shumë e kufizuar. Nëse nuk mund të komunikosh, nuk mund të marrësh pjesë mirë. Prandaj, vetëm fol. Jini të sinqertë dhe të hapur. Më vjen shumë keq që kjo është e pakëndshme për dikë. Mund ta imagjinoni, shumë vite më parë ka pasur një studim sipas të cilit në Shtetet e Bashkuara frika kryesore nuk është vdekja, por me mend çfarë? Frika nga të folurit në publik! Kjo do të thotë se diku ka njerëz që preferojnë të vdesin sesa të thonë një kompliment me zë të lartë. Dhe mendoj se mjafton që ju të keni disa aftësi bazë, në varësi të asaj që bëni. Aftësitë e të folurit, aftësitë e të shkruarit - por vetëm aq sa nevojitet realisht në punën tuaj. Nëse punoni si analist, por nuk dini të lexoni, shkruani dhe flisni, atëherë, për fat të keq, nuk do të keni çfarë të bëni në projektet e mia!
Çmimi i komunikimit
Oleg: A nuk është më i kushtueshëm punësimi i punonjësve të tillë që largohen për arsye të ndryshme? Në fund të fundit, ata vazhdimisht bisedojnë në vend që të punojnë!
Tim: E kisha fjalën për bërthamën e ekipit, dhe jo vetëm për të gjithë. Nëse keni dikë që është vërtet i mirë në akordimin e bazave të të dhënave, i pëlqen akordimi i bazave të të dhënave dhe do të vazhdojë të akordojë bazat e të dhënave tuaja për pjesën tjetër të jetës së tij dhe kaq, mirë, vazhdo kështu. Por unë po flas për njerëz që duan të jetojnë në vetë projektin. Thelbi i ekipit, që synon zhvillimin e projektit. Këta njerëz me të vërtetë duhet të komunikojnë vazhdimisht me njëri-tjetrin. Dhe veçanërisht në fillim të projektit, kur diskutoni rreziqet, mënyrat për të arritur qëllimet globale dhe të ngjashme.
Michael: Kjo vlen për të gjithë të përfshirë në projekt, pavarësisht nga specializimi, aftësitë ose mënyrat e punës. Të gjithë jeni të interesuar për suksesin e projektit.
Tim: Po, ju mendoni se jeni zhytur mjaftueshëm në projekt, se detyra juaj është të ndihmoni që projekti të realizohet. Pavarësisht nëse jeni programues, analist, projektues i ndërfaqes, kushdo. Kjo është arsyeja që unë vij në punë çdo mëngjes dhe kjo është ajo që ne bëjmë. Ne jemi përgjegjës për të gjithë këta njerëz, pavarësisht nga aftësitë e tyre. Ky është një grup njerëzish që bëjnë biseda me të rriturit.
Oleg: Në fakt, duke folur për punonjësit llafazan, u përpoqa të simuloja kundërshtimet e njerëzve, veçanërisht menaxherëve, të cilëve u kërkohet të kalojnë në devops, ndaj këtij vizioni të ri të botës. Dhe ju, si konsulentë, duhet të jeni të vetëdijshëm për këto kundërshtime shumë më mirë se unë, si zhvillues! Ndani çfarë i shqetëson më shumë menaxherët?
Tim: Menaxherët? Hm. Më shpesh, menaxherët janë nën presion nga problemet, përballen me nevojën për të lëshuar urgjentisht diçka dhe për të bërë një dorëzim, dhe të ngjashme. Ata shikojnë se si diskutojmë dhe debatojmë vazhdimisht për diçka dhe e shohin kështu: biseda, biseda, biseda... Çfarë bisedash të tjera? Kthehu ne pune! Sepse të folurit nuk është punë për ta. Ju nuk shkruani kod, nuk testoni softuer, nuk duket se bëni asgjë - pse të mos ju dërgoni për të bërë diçka? Në fund të fundit, dorëzimi është tashmë në një muaj!
Michael: Shko shkruani një kod!
Tim: Më duket se nuk shqetësohen për punën, por për mungesën e dukshmërisë së progresit. Për ta bërë të duket sikur po i afrohemi suksesit, ata duhet të na shohin duke shtypur butonat në tastierë. Gjithë ditën nga mëngjesi në mbrëmje. Ky është problemi numër një.
Oleg: Misha, po mendon për diçka.
Michael: Më falni, u humba në mendime dhe më kap një rikthim. E gjithë kjo më kujtoi një miting interesant që ndodhi dje... Kishte shumë tubime dje... Dhe gjithçka tingëllon shumë e njohur!
Jeta pa rroga
Tim: Nga rruga, nuk është aspak e nevojshme të organizohen "mitingje" për komunikim. Dua të them, diskutimet më të dobishme midis zhvilluesve ndodhin kur ata thjesht flasin me njëri-tjetrin. Hyn në mëngjes me një filxhan kafe, dhe janë mbledhur pesë njerëz dhe diskutojnë me furi diçka teknike. Për mua, nëse jam menaxher i këtij projekti, është më mirë të buzëqesh dhe të shkoj diku për biznesin tim, le ta diskutojnë. Ata tashmë janë të përfshirë sa më shumë. Kjo është një shenjë e mirë.
Oleg: Meqë ra fjala, në librin tuaj keni një mori shënimesh për atë që është e mirë dhe çfarë është e keqe. A përdorni ndonjë prej tyre vetë? Duke folur relativisht, tani ju keni një kompani dhe një kompani që është e strukturuar në një mënyrë shumë joortodokse...
Tim: Joortodokse, por kjo pajisje na përshtatet shumë. Ne njihemi prej kohësh. Ne i besojmë njëri-tjetrit, i kemi besuar shumë njëri-tjetrit para se të bëheshim partnerë. Dhe për shembull, ne nuk kemi rroga fare. Ne thjesht punojmë, dhe për shembull, nëse fitoja para nga klientët e mi, atëherë të gjitha paratë shkonin tek unë. Pas kësaj, ne i paguajmë anëtarësimin organizatës dhe kjo mjafton për të mbështetur vetë kompaninë. Plus, ne të gjithë jemi të specializuar në gjëra të ndryshme. Për shembull, unë punoj me kontabilistë, plotësoj deklaratat tatimore, bëj lloj-lloj gjërash administrative për kompaninë dhe askush nuk më paguan për këtë. James dhe Tom punojnë në faqen tonë të internetit dhe askush nuk i paguan as ata. Për sa kohë që paguani detyrimet tuaja, askush nuk do të mendojë t'ju tregojë se çfarë duhet të bëni. Për shembull, Tom tani punon shumë më pak se dikur. Tani ai ka interesa të tjera, ai bën disa gjëra jo për Guild. Por për sa kohë që ai paguan detyrimet e tij, askush nuk do t'i afrohet dhe do t'i thotë: "Hej, Tom, shko në punë!" Është shumë e lehtë të merresh me kolegët kur mes jush nuk ka para. Dhe tani marrëdhënia jonë është një nga idetë themelore në lidhje me specialitete të ndryshme. Funksionon dhe funksionon shumë mirë.
Këshilla më e mirë
Michael: Duke iu kthyer "këshillave më të mira", a ka ndonjë gjë që u tregoni klientëve tuaj vazhdimisht? Ekziston një ide rreth 80/20, dhe disa këshilla ndoshta përsëriten më shpesh.
Tim: Dikur mendova se nëse shkruani një libër si Waltzing with Bears, do të ndryshonte rrjedhën e historisë dhe njerëzit do të ndalonin, por... Epo, shikoni, kompanitë shpesh pretendojnë se gjithçka është në rregull me to. Sapo ndodh diçka e keqe, është një tronditje dhe një surprizë për ta. “Shikoni, ne e testuam sistemin dhe ai nuk kalon asnjë test të sistemit, dhe ky është edhe tre muaj punë të paplanifikuar, si mund të ndodhte kjo? Kush e dinte? Çfarë mund të shkojë keq? Seriozisht, a e beson këtë?
Po mundohem t'ju shpjegoj se nuk duhet të zemëroheni shumë për situatën aktuale. Ne duhet ta diskutojmë atë, të kuptojmë vërtet se çfarë mund të ketë shkuar keq dhe si të parandalojmë që gjëra të tilla të ndodhin në të ardhmen. Nëse shfaqet një problem, si do ta luftojmë atë, si do ta frenojmë?
Për mua, e gjithë kjo duket e frikshme. Njerëzit merren me probleme komplekse, shqetësuese dhe vazhdojnë të pretendojnë se nëse thjesht kryqëzojnë gishtat dhe shpresojnë për më të mirën, "më e mira" do të ndodhë në të vërtetë. Jo, nuk funksionon kështu.
Praktikoni menaxhimin e rrezikut!
Michael: Sipas mendimit tuaj, sa organizata angazhohen në menaxhimin e rrezikut?
Tim: Ajo që më zemëron është se njerëzit thjesht shkruajnë rreziqet, shikojnë listën që rezulton dhe shkojnë në punë. Në fakt, identifikimi i rreziqeve për ta është menaxhimi i rrezikut. Por për mua kjo tingëllon si një arsye për të pyetur: në rregull, ka një listë, çfarë saktësisht do të ndryshoni? Ju duhet të ndryshoni sekuencat tuaja standarde të veprimeve duke marrë parasysh këto rreziqe. Nëse ka ndonjë pjesë më të vështirë të punës, duhet ta trajtoni atë dhe vetëm atëherë të kaloni në diçka më të thjeshtë. Në sprintet e para, filloni të zgjidhni probleme komplekse. Kjo tashmë duket si menaxhim i rrezikut. Por zakonisht njerëzit nuk mund të thonë se çfarë kanë ndryshuar pasi kanë përpiluar një listë të rreziqeve.
Michael: E megjithatë, sa prej këtyre kompanive janë të përfshira në menaxhimin e rrezikut, pesë për qind?
Tim: Fatkeqësisht, e urrej ta them këtë, por kjo është një pjesë shumë e parëndësishme. Por më shumë se pesë, sepse ka projekte vërtet të mëdha, dhe ato thjesht nuk mund të ekzistojnë nëse nuk bëjnë të paktën diçka. Le të themi se do të habitem shumë nëse është të paktën 25%. Projektet e vogla zakonisht u përgjigjen pyetjeve të tilla: nëse problemi na prek, atëherë ne do ta zgjidhim atë. Pastaj ata futen me sukses në telashe dhe angazhohen në menaxhimin e problemeve dhe menaxhimin e krizave. Kur përpiqeni të zgjidhni një problem dhe problemi nuk zgjidhet, mirë se vini në menaxhimin e krizës.
Po, shpesh dëgjoj: "Ne do t'i zgjidhim problemet kur ato lindin". Me siguri do ta bëjmë? A do të vendosim vërtet?
Oleg: Ju mund ta bëni atë në mënyrë naive dhe thjesht të shkruani invariante të rëndësishme në statutin e projektit, dhe nëse invariantet prishen, thjesht rinisni projektin. Rezulton shumë piembucky.
Michael: Po, më ka ndodhur që kur lindnin rreziqe, projekti thjesht ripërcaktohej. E bukur, bingo, problemi u zgjidh, mos u shqetëso më!
Tim: Le të shtypim butonin e rivendosjes! Jo, nuk funksionon kështu.
Fjala kryesore në DevOops 2019
Michael: Vijmë tek pyetja e fundit e kësaj interviste. Po vini në DevOops-in e ardhshëm me një fjalim kryesor, a mund të hiqni perden e fshehtësisë mbi atë që do të tregoni?
Tim: Tani për tani, gjashtë prej tyre po shkruajnë një libër për kulturën e punës, rregullat e pathëna të organizatave. Kultura përcaktohet nga vlerat thelbësore të organizatës. Zakonisht njerëzit nuk e vënë re këtë, por pasi kemi punuar në konsulencë për shumë vite, jemi mësuar ta vërejmë. Ju hyni në një kompani dhe fjalë për fjalë brenda pak minutash filloni të ndjeni se çfarë po ndodh. Ne e quajmë këtë "shije". Ndonjëherë kjo aromë është vërtet e mirë, dhe ndonjëherë është, mirë, oops. Gjërat janë shumë të ndryshme për organizata të ndryshme.
Michael: Edhe unë kam vite që punoj në konsulencë dhe e kuptoj mirë se për çfarë po flisni.
Tim: Në fakt, një nga gjërat për të cilat ia vlen të flitet në fjalimin kryesor është se jo gjithçka përcaktohet nga kompania. Ju dhe ekipi juaj, si komunitet, keni kulturën tuaj të ekipit. Kjo mund të jetë e gjithë kompania, ose një departament i veçantë, një ekip i veçantë. Por para se të thoni, ja çfarë besojmë ne, ja çfarë është e rëndësishme... Nuk mund të ndryshoni një kulturë përpara se të kuptohen vlerat dhe besimet pas veprimeve specifike. Sjellja është e lehtë për t'u vëzhguar, por kërkimi i besimeve është i vështirë. DevOps është vetëm një shembull i shkëlqyer se si gjërat po bëhen gjithnjë e më komplekse. Ndërveprimet vetëm sa po bëhen më komplekse, ato nuk po bëhen aspak më të pastra apo më të qarta, ndaj duhet të mendoni për atë që besoni dhe për çfarë heshtin të gjithë rreth jush.
Nëse doni të arrini rezultate të shpejta, këtu është një temë e mirë për ju: a keni parë kompani ku askush nuk thotë "nuk e di"? Ka vende ku ju torturoni fjalë për fjalë një person derisa ai të pranojë se nuk di diçka. Të gjithë dinë gjithçka, të gjithë janë një erudit të jashtëzakonshëm. I afroheni çdo personi dhe ai duhet t'i përgjigjet menjëherë pyetjes. Në vend që të thoni "Nuk e di". Horay, ata punësuan një bandë eruditësh! Dhe në disa kultura është përgjithësisht shumë e rrezikshme të thuash "Nuk e di" mund të perceptohet si një shenjë dobësie. Ka edhe organizata në të cilat, përkundrazi, të gjithë mund të thonë "Unë nuk e di". Atje është plotësisht e ligjshme dhe nëse dikush fillon të zhgënjejë në përgjigje të një pyetjeje, është krejtësisht normale të përgjigjet: "Nuk e dini se për çfarë po flisni, apo jo?" dhe i kthen të gjitha në shaka.
Idealisht, do të dëshironit të kishit një punë ku mund të jeni vazhdimisht të lumtur. Nuk do të jetë e lehtë, jo çdo ditë është me diell dhe e këndshme, ndonjëherë ju duhet të punoni shumë, por kur të filloni të bëni një bilanc, do të dalë: wow, ky është një vend vërtet i mrekullueshëm, ndihem mirë duke punuar këtu, si emocionalisht ashtu edhe intelektualisht. Dhe ka kompani ku ju shkoni si konsulent dhe kuptoni menjëherë se nuk mund të duroni për tre muaj dhe do të ikje i tmerruar. Kjo është ajo për të cilën dua të flas në raport.
Tim Lister do të arrijë me një fjalim kryesor në konferencën DevOops 2019, e cila do të zhvillohet më 29-30 tetor 2019 në Shën Petersburg. Ju mund të blini bileta . Ju presim në DevOops!
Burimi: www.habr.com