Tim Lister - co-author ng mga libro
- "Human factor. Mga Matagumpay na Proyekto at Mga Koponan" (ang orihinal na aklat ay tinatawag na "Peopleware")
- "Waltzing with the Bears: Pamamahala ng Risk sa Software Projects"
- “Adrenaline-crazed at zombie sa pamamagitan ng mga pattern. Mga pattern ng pag-uugali ng mga pangkat ng proyekto"
Ang lahat ng mga aklat na ito ay mga klasiko sa kanilang larangan at isinulat kasama ng mga kasamahan sa . Sa Russia, ang kanyang mga kasamahan ay pinakasikat - и , na sumulat din ng maraming sikat na gawa.
Si Tim ay may 40 taong karanasan sa pagbuo ng software; noong 1975 (wala sa mga sumulat ng habrapost na ito ang ipinanganak ngayong taon), si Tim ay naging executive vice president na ng Yourdon Inc. Ginugugol niya ngayon ang kanyang oras sa pagkonsulta, pagtuturo, at pagsusulat, na may paminsan-minsang pagbisita sa mga kumperensya sa buong mundo.
Nagpa-interview kami kay Tim Lister lalo na kay Habr. Magbubukas siya ng kumperensya ng DevOops 2019, at marami kaming tanong, tungkol sa mga libro at higit pa. Ang panayam ay isinasagawa nina Mikhail Druzhinin at Oleg Chirukhin mula sa komite ng programa ng kumperensya.
Michael: Maaari ka bang magsabi ng ilang salita tungkol sa iyong ginagawa ngayon?
Tim: Ako ang pinuno ng Atlantic Systems Guild. Anim kami sa Guild, principal ang tawag namin sa sarili namin. Tatlo sa USA at tatlo sa Europe - kaya tinawag na Atlantic ang Guild. Napakaraming taon na tayong magkasama kaya hindi mo na mabilang. Lahat tayo ay may kanya-kanyang specialty. Nagtatrabaho ako sa mga kliyente sa nakalipas na dekada o higit pa. Kasama sa aking mga proyekto hindi lamang ang pamamahala, kundi pati na rin ang pagtatakda ng mga kinakailangan, pagpaplano ng proyekto, at pagsusuri. Tila ang mga proyektong nagsisimula nang hindi maganda ay karaniwang nagtatapos nang hindi maganda. Samakatuwid, ito ay nagkakahalaga ng pagtiyak na ang lahat ng mga aktibidad ay talagang pinag-isipang mabuti at pinag-ugnay, na ang mga ideya ng mga tagalikha ay pinagsama. Ito ay nagkakahalaga ng pag-iisip tungkol sa kung ano ang iyong ginagawa at kung bakit. Anong mga diskarte ang gagamitin upang makumpleto ang proyekto.
Ako ay nagpapayo sa mga kliyente sa iba't ibang paraan sa loob ng maraming taon. Ang isang kawili-wiling halimbawa ay isang kumpanya na gumagawa ng mga robot para sa pagtitistis sa tuhod at balakang. Ang siruhano ay hindi ganap na nagpapatakbo nang nakapag-iisa, ngunit gumagamit ng isang robot. Ang kaligtasan dito, sa pagsasalita, ay mahalaga. Ngunit kapag sinubukan mong talakayin ang mga kinakailangan sa mga taong nakatuon sa paglutas ng mga problema... Mukhang kakaiba, ngunit sa USA mayroong (Federal Drug Administration), na nagbibigay ng lisensya sa mga produktong tulad ng mga robot na ito. Bago ka magbenta ng anuman at gamitin ito sa mga buhay na tao, kailangan mong kumuha ng lisensya. Isa sa mga kundisyon ay ipakita ang iyong mga kinakailangan, kung ano ang mga pagsubok, kung paano mo sinubukan ang mga ito, kung ano ang mga resulta ng pagsubok. Kung babaguhin mo ang mga kinakailangan, kailangan mong dumaan sa buong proseso ng pagsubok na ito nang paulit-ulit. Nagawa ng aming mga kliyente na isama ang visual na disenyo ng mga application sa kanilang mga kinakailangan. Mayroon silang mga screenshot nang direkta bilang bahagi ng mga kinakailangan. Kailangan nating hilahin ang mga ito at ipaliwanag na karamihan sa lahat ng mga programang ito ay walang alam tungkol sa mga tuhod at balakang, lahat ng mga bagay na ito gamit ang camera, atbp. Kailangan nating muling isulat ang mga dokumentong kinakailangan upang hindi na magbago ang mga ito, maliban na lang kung magbabago ang ilang mahahalagang kondisyon. Kung ang visual na disenyo ay wala sa mga kinakailangan, ang pag-update ng produkto ay magiging mas mabilis. Ang aming trabaho ay hanapin ang mga elementong iyon na nakikitungo sa mga operasyon sa tuhod, balakang, likod, hilahin ang mga ito sa magkahiwalay na mga dokumento at sabihin na ito ang magiging pangunahing mga kinakailangan. Gumawa tayo ng ilang grupo ng mga kinakailangan tungkol sa mga operasyon ng tuhod. Magbibigay-daan ito sa amin na bumuo ng mas matatag na hanay ng mga kinakailangan. Pag-uusapan natin ang buong linya ng produkto, at hindi ang tungkol sa mga partikular na robot.
Napakaraming trabaho ang ginawa, ngunit nakarating pa rin sila sa mga lugar kung saan dati ay gumugol sila ng mga linggo at buwan ng paulit-ulit na mga pagsubok nang walang kahulugan o kailangan, dahil ang kanilang mga kinakailangan na inilarawan sa papel ay hindi nag-tutugma sa mga tunay na kinakailangan kung saan itinayo ang mga sistema. Ang FDA ay nagsabi sa kanila sa bawat oras: ang iyong mga kinakailangan ay nagbago, ngayon kailangan mong suriin ang lahat mula sa simula. Ang kumpletong muling pagsusuri sa buong produkto ay pinapatay ang negosyo.
Kaya, may mga kahanga-hangang gawain kapag nakita mo ang iyong sarili sa pinakadulo simula ng isang bagay na kawili-wili, at ang pinakaunang mga aksyon ay nagtatakda ng karagdagang mga patakaran ng laro. Kung sinisigurado mo na ang maagang aktibidad na ito ay magsisimulang gumana nang maayos mula sa parehong managerial at teknikal na pananaw, may posibilidad na magkaroon ka ng magandang proyekto. Ngunit kung ang bahaging ito ay nawala sa riles at napunta sa isang lugar na mali, kung hindi mo mahanap ang mga pangunahing kasunduan... hindi, hindi iyon ang iyong proyekto ay kinakailangang mabibigo. Ngunit hindi mo na masasabing: "Napakahusay namin, ginawa namin ang lahat nang mabisa." Ito ang mga bagay na ginagawa ko kapag nakikipag-usap sa mga kliyente.
Michael: Iyon ay, naglulunsad ka ng mga proyekto, gumawa ng ilang uri ng kickoff at suriin kung ang mga riles ay patungo sa tamang direksyon?
Tim: Mayroon din kaming mga ideya kung paano pagsasama-samahin ang lahat ng piraso ng puzzle: anong mga kasanayan ang kailangan namin, kung kailan eksaktong kailangan ang mga ito, kung ano ang hitsura ng core ng koponan at iba pang mga pangunahing bagay. Kailangan ba natin ng mga full-time na empleyado o maaari tayong kumuha ng part-time? Pagpaplano, pamamahala. Mga tanong tulad ng: Ano ang pinakamahalaga para sa partikular na proyektong ito? Paano ito makakamit? Ano ang alam natin tungkol sa produktong ito o proyekto, ano ang mga panganib at kung saan ang mga hindi alam, paano natin haharapin ang lahat ng ito? Siyempre, sa sandaling ito ay may nagsimulang sumigaw ng "Paano ang maliksi?!" Okay, flexible kayong lahat, pero ano? Ano nga ba ang hitsura ng proyekto, paano mo ito ilalabas sa paraang nababagay sa proyekto? Hindi mo lang masasabi na "ang aming diskarte ay umaabot sa anumang bagay, kami ay isang koponan ng Scrum!" Ito ay kalokohan at kalokohan. Saan ka susunod na pupunta, bakit ito gagana, saan ang punto? Tinuturuan ko ang aking mga kliyente na isipin ang lahat ng mga tanong na ito.
19 na taon ng maliksi
Michael: Sa Agile, madalas na sinusubukan ng mga tao na huwag tukuyin ang anumang bagay nang maaga, ngunit gumawa ng mga desisyon nang huli hangga't maaari, na nagsasabi: kami ay masyadong malaki, hindi ko iisipin ang pangkalahatang arkitektura. Hindi ko na iisipin ang tungkol sa iba pang mga bagay; sa halip, maghahatid ako ng isang bagay na gumagana sa customer ngayon.
Tim: Sa tingin ko na maliksi pamamaraan, simula sa noong 2001, binuksan ang mga mata ng industriya. Ngunit sa kabilang banda, walang perpekto. Lahat ako ay para sa umuulit na pag-unlad. Ang pag-ulit ay may malaking kahulugan sa karamihan ng mga proyekto. Ngunit ang tanong na kailangan mong pag-isipan ay: kapag ang produkto ay wala na at ginagamit na, gaano ito katagal? Ito ba ay isang produkto na tatagal ng anim na buwan bago palitan ng ibang bagay? O ito ba ay isang produkto na gagana para sa maraming, maraming taon? Siyempre, hindi ko banggitin ang mga pangalan, ngunit... Sa New York at sa financial community nito, ang pinakapangunahing mga sistema ay napakaluma. Ito ay kamangha-manghang. Tinitingnan mo sila at iniisip, kung maaari ka lamang bumalik sa nakaraan, sa 1994, at sabihin sa mga developer: "Nagmula ako sa hinaharap, mula 2019. Paunlarin lamang ang sistemang ito hangga't kailangan mo. Gawin itong napapalawak, isipin ang tungkol sa arkitektura. Pagkatapos ay pagbubutihin ito ng higit sa dalawampu't limang taon. Kung ipagpaliban mo ang pag-unlad ng kaunti pa, sa engrandeng pamamaraan ng mga bagay ay walang makakapansin!" Kapag tinatantya mo ang mga bagay sa loob ng mahabang panahon, kailangan mong isaalang-alang kung magkano ang kabuuang halaga nito. Minsan talagang sulit ang disenyong arkitektura, at kung minsan ay hindi. Kailangan nating tumingin sa paligid at tanungin ang ating sarili: nasa tamang sitwasyon ba tayo para sa gayong desisyon?
Kaya isang ideya tulad ng "Kami ay para sa maliksi, ang customer mismo ang magsasabi sa amin kung ano ang gusto niyang makuha" - ito ay sobrang walang muwang. Ni hindi alam ng mga customer kung ano ang gusto nila, at higit pa kaya hindi nila alam kung ano ang makukuha nila. Ang ilang mga tao ay magsisimulang magbanggit ng mga makasaysayang halimbawa bilang mga argumento, nakita ko na ito. Ngunit ang mga teknikal na advanced na tao ay hindi karaniwang nagsasabi na. Sabi nila: "2019 na, ito ang mga pagkakataon na mayroon tayo, at maaari nating ganap na baguhin ang paraan ng pagtingin natin sa mga bagay na ito!" Sa halip na gayahin ang mga umiiral nang solusyon, gawing mas maganda at mas suklay ang mga ito, minsan kailangan mong lumabas at sabihing: "Lubos nating baguhin ang sinusubukan nating gawin dito!"
At sa palagay ko hindi maiisip ng karamihan sa mga customer ang problema sa ganoong paraan. Nakikita lang nila kung anong meron sila, yun lang. Pagkatapos nito ay may kasama silang mga kahilingan tulad ng "gawin natin itong mas simple," o anumang karaniwang sinasabi nila. Ngunit hindi kami waiter o waitress, kaya maaari kaming kumuha ng isang order kahit gaano katanga ito at pagkatapos ay i-bake ito sa kusina. Kami ang kanilang mga gabay. Kailangan nating buksan ang kanilang mga mata at sabihin: hey, mayroon tayong mga bagong pagkakataon dito! Napagtanto mo ba na talagang mababago namin ang paraan ng paggawa sa bahaging ito ng iyong negosyo? Ang isa sa mga problema sa Agile ay ang pag-aalis ng kamalayan sa kung ano ang isang pagkakataon, kung ano ang isang problema, kung ano ang kailangan nating gawin, kung anong mga magagamit na teknolohiya ang pinakaangkop para sa partikular na sitwasyong ito.
Marahil ay labis akong nag-aalinlangan dito: maraming magagandang bagay na nangyayari sa maliksi na komunidad. Ngunit mayroon akong problema sa katotohanan na sa halip na tukuyin ang isang proyekto, ang mga tao ay nagsisimulang magsuka ng kanilang mga kamay. Itatanong ko dito - ano ang ginagawa natin, paano natin ito gagawin? At kahit papaano magically ito ay palaging lumiliko na ang kliyente ay dapat na mas alam kaysa sa sinuman. Ngunit higit na nakakaalam ang kliyente kapag pumili siya sa mga bagay na binuo na ng isang tao. Kung gusto kong bumili ng kotse at alam ko ang laki ng badyet ng aking pamilya, pagkatapos ay mabilis akong pipili ng kotse na nababagay sa aking pamumuhay. Dito ko alam ang lahat ng mas mahusay kaysa sa sinuman! Ngunit pakitandaan na may nakagawa na ng mga sasakyan. Wala akong ideya kung paano mag-imbento ng bagong kotse, hindi ako eksperto. Kapag gumawa kami ng mga custom o espesyal na produkto, dapat isaalang-alang ang boses ng customer, ngunit hindi na ito ang tanging boses.
Oleg: Nabanggit mo ang Agile Manifesto. Kailangan ba nating i-update o baguhin ito kahit papaano na isinasaalang-alang ang modernong pag-unawa sa isyu?
Tim: Hindi ko siya hahawakan. Sa tingin ko ito ay isang mahusay na makasaysayang dokumento. Ibig kong sabihin, siya ay kung ano siya. Siya ay magiging 19 taong gulang, siya ay matanda na, ngunit sa kanyang panahon ay gumawa siya ng isang rebolusyon. Ang maganda niyang ginawa ay nag-trigger siya ng reaksyon at nagsimulang magbulungan ang mga tao tungkol sa kanya. Ikaw, malamang, ay hindi pa nagtatrabaho sa industriya noong 2001, ngunit pagkatapos ay lahat ay nagtrabaho ayon sa mga proseso. Software Engineering Institute, limang antas ng software completeness model (CMMI). Hindi ko alam kung ang mga alamat ng malalim na sinaunang panahon ay nagsasabi sa iyo ng isang bagay, ngunit pagkatapos ito ay isang pambihirang tagumpay. Sa una, ang mga tao ay naniniwala na kung ang mga proseso ay nai-set up nang tama, ang mga problema ay mawawala sa kanilang sarili. At pagkatapos ay dumating ang Manifesto at nagsasabing: "Hindi, hindi, hindi - tayo ay ibabatay sa mga tao, hindi sa mga proseso." Kami ay mga masters ng software development. Naiintindihan namin na ang perpektong proseso ay isang mirage; hindi ito nangyayari. Napakaraming idiosyncrasy sa mga proyekto, ang ideya ng isang solong perpektong proseso para sa lahat ng mga proyekto ay walang kahulugan. Masyadong masalimuot ang mga problema para sabihin na iisa lang ang solusyon sa lahat (hello, nirvana).
Hindi ko ipinapalagay na tumingin sa hinaharap, ngunit sasabihin ko na ang mga tao ay nagsimulang mag-isip nang higit pa tungkol sa mga proyekto. Sa tingin ko ang Agile Manifesto ay napakahusay sa paglundag at pagsasabing, “Hoy! Nasa barko ka, at ikaw mismo ang nagmamaneho ng barkong ito. Kailangan mong gumawa ng desisyon - hindi kami magmumungkahi ng isang unibersal na recipe para sa lahat ng mga sitwasyon. Ikaw ang tauhan ng barko, at kung ikaw ay sapat na mahusay, maaari kang makahanap ng isang paraan sa iyong layunin. Mayroong iba pang mga barko na nauna sa iyo, at may iba pang mga barko na susunod sa iyo, ngunit gayon pa man, sa isang kahulugan, ang iyong paglalakbay ay kakaiba." May ganyan! Ito ay isang paraan ng pag-iisip. Para sa akin, walang bago sa ilalim ng araw, ang mga tao ay naglayag na noon at muling maglalayag, ngunit para sa iyo ito ang iyong pangunahing paglalakbay, at hindi ko sasabihin sa iyo kung ano ang eksaktong mangyayari sa iyo. Dapat mayroon kang mga kasanayan sa coordinated work sa isang team, at kung mayroon ka talaga, lahat ay gagana at makukuha mo kung saan mo gusto.
Peopleware: Pagkalipas ng 30 taon
Oleg: Ang Peopleware ba ay isang rebolusyon pati na rin ang Manipesto?
Tim: Peopleware... Isinulat namin ni Tom ang aklat na ito, ngunit hindi namin akalain na ganito ang mangyayari. Kahit papaano ay sumasalamin ito sa maraming ideya ng mga tao. Ito ang unang aklat na nagsabing: ang pag-develop ng software ay isang napaka-human-intensive na aktibidad. Sa kabila ng ating teknikal na katangian, tayo rin ay isang komunidad ng mga tao na nagtatayo ng isang bagay na malaki, kahit napakalaki, napakasalimuot. Walang sinuman ang maaaring lumikha ng mga bagay na mag-isa, tama ba? Kaya ang ideya ng "pangkat" ay naging napakahalaga. At hindi lamang mula sa isang punto ng pamamahala, kundi pati na rin para sa mga teknikal na tao na nagsama-sama upang malutas ang talagang kumplikadong malalim na mga problema sa isang grupo ng mga hindi alam. Para sa akin personal, ito ay isang malaking pagsubok ng katalinuhan sa buong karera ko. At dito kailangan mong masabi: oo, ang problemang ito ay higit pa sa kakayanin ko nang mag-isa, ngunit magkasama tayong makakahanap ng isang eleganteng solusyon na maipagmamalaki natin. At sa palagay ko, ang ideyang ito ang pinakatumatak. Ang ideya na gumagawa tayo ng bahagi ng oras sa ating sarili, bahagi ng oras bilang bahagi ng isang grupo, at kadalasan ang desisyon ay ginawa ng grupo. Ang paglutas ng problema ng grupo ay mabilis na naging mahalagang katangian ng mga kumplikadong proyekto.
Sa kabila ng katotohanang nagbigay ng malaking bilang ng mga pag-uusap si Tim, kakaunti sa mga ito ang nai-post sa YouTube. Maaari mong tingnan ang ulat na "The Return of Peopleware" mula 2007. Ang kalidad, siyempre, ay nag-iiwan ng maraming nais.
Michael: May nagbago ba sa nakalipas na 30 taon mula nang mailathala ang aklat?
Tim: Maaari mong tingnan ito mula sa maraming iba't ibang mga anggulo. Sociologically speaking... noong unang panahon, sa mas simpleng panahon, ikaw at ang iyong team ay nakaupo sa iisang opisina. Maaari kayong maging close araw-araw, uminom ng kape nang magkasama at pag-usapan ang trabaho. Ang talagang nagbago ay ang mga koponan ay maaari na ngayong ipamahagi sa heograpiya, sa iba't ibang bansa at time zone, ngunit ginagawa pa rin nila ang parehong problema, at ito ay nagdaragdag ng isang buong bagong layer ng pagiging kumplikado. Ito ay maaaring mukhang old-school, ngunit walang katulad ng harapang komunikasyon kung saan magkasama kayong lahat, nagtutulungan, at maaari kang lumapit sa isang kasamahan at sabihin, tingnan kung ano ang natuklasan ko, paano mo ito nagustuhan? Ang mga harapang pag-uusap ay nagbibigay ng mabilis na paraan upang lumipat sa impormal na komunikasyon, at sa palagay ko ay dapat din itong magustuhan ng mga maliksi na mahilig. At nag-aalala din ako dahil sa katotohanan ang mundo ay naging napakaliit, at ngayon ang lahat ay sakop ng mga ipinamahagi na koponan, at ang lahat ng ito ay napakasalimuot.
Lahat tayo ay nakatira sa DevOps
Michael: Even from the point of view of the conference program committee, meron tayong mga tao sa California, sa New York, Europe, Russia... wala pang tao sa Singapore. Ang pagkakaiba sa heograpiya ay medyo malaki, at ang mga tao ay nagsisimula nang kumalat nang higit pa. Kung pag-uusapan natin ang tungkol sa pag-unlad, maaari mo bang sabihin sa amin ang higit pa tungkol sa mga devop at pagsira ng mga hadlang sa pagitan ng mga koponan? Mayroong isang konsepto na ang lahat ay nakaupo sa kanilang mga bunker, at ngayon ang mga bunker ay gumuho, ano sa palagay mo ang pagkakatulad na ito?
Tim: Para sa akin, sa liwanag ng mga kamakailang teknolohikal na tagumpay, ang mga devop ay may malaking kahalagahan. Dati, mayroon kang mga koponan ng mga developer at administrator, nagtrabaho sila, nagtrabaho, nagtrabaho, at sa isang punto ay may lumitaw na bagay kung saan maaari kang pumunta sa mga admin at ilunsad ito para sa produksyon. At dito nagsimula ang pag-uusap tungkol sa bunker, dahil ang mga admin ay uri ng mga kaalyado, hindi mga kaaway, at least, ngunit nakausap mo lamang sila kapag ang lahat ay handa na upang pumunta sa produksyon. Nagpunta ka ba sa kanila ng isang bagay at sinabing: tingnan kung anong application ang mayroon kami, ngunit maaari mo bang ilunsad ang application na ito? At ngayon ang buong konsepto ng paghahatid ay nagbago para sa mas mahusay. Ibig kong sabihin, nagkaroon ng ideya na maaari mong itulak ang mga pagbabago nang mabilis. Maaari naming i-update ang mga produkto sa mabilisang. Palagi akong nakangiti kapag nag-pop up ang Firefox sa aking laptop at nagsasabing, hey, na-update namin ang iyong Firefox sa background, at sa sandaling magkaroon ka ng isang minuto, mag-click ka ba rito at ibibigay namin sa iyo ang pinakabagong release. At parang, "Oh yeah, baby!" Habang natutulog ako, naghahatid sila sa akin ng bagong release sa mismong computer ko. Ito ay kahanga-hanga, hindi kapani-paniwala.
Ngunit narito ang kahirapan: mayroon kang tampok na ito sa pag-update ng software, ngunit ang pagsasama ng mga tao ay mas mahirap. Ang gusto kong ipahayag sa pangunahing tono ng DevOops ay mayroon na tayong mas maraming manlalaro kaysa dati. Kung iisipin mo lang lahat ng kasali sa isang team lang…. Inisip mo ito bilang isang koponan, at ito ay higit pa sa isang pangkat ng mga programmer. Ito ay mga tagasubok, tagapamahala ng proyekto, at isang grupo ng iba pang mga tao. At lahat ay may kanya-kanyang pananaw sa mundo. Ang mga tagapamahala ng produkto ay ganap na naiiba sa mga tagapamahala ng proyekto. Ang mga admin ay may kanya-kanyang gawain. Nagiging medyo mahirap na problema ang pag-coordinate ng lahat ng kalahok upang patuloy na magkaroon ng kamalayan sa mga nangyayari at hindi mabaliw. Kinakailangang paghiwalayin ang mga gawain ng grupo at mga gawain na naaangkop sa lahat. Ito ay isang napakahirap na gawain. Sa kabilang banda, sa tingin ko ang lahat ng ito ay mas mahusay kaysa sa maraming taon na ang nakalipas. Ito mismo ang daan kung saan lumalaki ang mga tao at natututong kumilos nang tama. Kapag gumawa ka ng integration, naiintindihan mo na dapat walang underground development, para sa pinakahuling sandali ang software ay hindi gumapang palabas na parang jack-in-the-box: parang, tingnan kung ano ang ginawa namin dito! Ang ideya ay magagawa mo ang pagsasama at pag-unlad, at sa huli ay lalabas ka sa maayos at umuulit na paraan. Malaki ang kahulugan ng lahat ng ito sa akin. Ginagawa nitong posible na lumikha ng higit na halaga para sa mga gumagamit ng system at para sa iyong kliyente.
Michael: Ang buong ideya ng devops ay maghatid ng mga makabuluhang pag-unlad sa lalong madaling panahon. Nakikita ko na ang mundo ay nagsimulang bumilis ng higit at higit pa. Paano umangkop sa gayong mga acceleration? Sampung taon na ang nakalipas ay hindi ito umiiral!
Tim: Siyempre, gusto ng lahat ng higit pa at higit pang pag-andar. Hindi na kailangang gumalaw, magtambak pa. Minsan kailangan mo pang magdahan-dahan para sa susunod na incremental na pag-update upang magdala ng anumang kapaki-pakinabang - at iyon ay ganap na normal.
Ang ideya na kailangan mong tumakbo, tumakbo, tumakbo ay hindi ang pinakamahusay. Hindi malamang na may gustong mamuhay ng ganoon. Gusto kong itakda ng ritmo ng mga paghahatid ang sariling ritmo ng proyekto. Kung gumawa ka lamang ng isang stream ng maliliit, medyo walang kahulugan na mga bagay, lahat ng ito ay nagdaragdag ng walang kahulugan. Sa halip na walang pag-iisip na subukang ilabas ang mga bagay nang maaga hangga't maaari, ang dapat pag-usapan sa mga nangungunang developer at mga tagapamahala ng produkto at proyekto ay diskarte. May katuturan ba ito?
Mga pattern at antipattern
Oleg: Karaniwan mong pinag-uusapan ang mga pattern at antipattern, at ito ang pagkakaiba sa pagitan ng buhay at kamatayan ng mga proyekto. At ngayon, ang mga devops ay sumabog sa ating buhay. Mayroon ba itong sariling mga pattern at anti-pattern na maaaring patayin ang proyekto sa lugar?
Tim: Ang mga pattern at anti-pattern ay nangyayari sa lahat ng oras. May pag-uusapan. Well, mayroong isang bagay na tinatawag nating "makintab na bagay." Talagang gusto ng mga tao ang bagong teknolohiya. Natulala lang sila sa ningning ng lahat na mukhang cool at naka-istilong, at huminto sila sa pagtatanong: kailangan pa ba ito? Ano ang ating maaabot? Maaasahan ba ang bagay na ito, may katuturan ba ito? Madalas kong nakikita ang mga tao, wika nga, sa makabagong teknolohiya. Na-hypnotize sila sa mga nangyayari sa mundo. Ngunit kung titingnan mo nang mabuti kung anong mga kapaki-pakinabang na bagay ang ginagawa nila, kadalasan ay walang kapaki-pakinabang!
Napag-usapan lang namin ng mga kasama namin na ang taong ito ay isang taon ng anibersaryo, limampung taon mula nang mapunta ang mga tao sa buwan. Ito ay noong 1969. Ang teknolohiyang tumulong sa mga tao na makarating doon ay hindi kahit na 1969 na teknolohiya, ngunit sa halip ay 1960 o 62, dahil gusto ng NASA na gamitin lamang ang may magandang ebidensya ng pagiging maaasahan. At kaya tingnan mo ito at maunawaan - oo, at totoo sila! Ngayon, hindi, hindi, ngunit nagkakaroon ka ng mga problema sa teknolohiya dahil lamang sa lahat ay itinutulak nang husto, naibenta mula sa lahat ng mga bitak. Ang mga tao ay sumisigaw mula sa lahat ng dako: "Tingnan, anong bagay, ito ang pinakabagong bagay, ang pinakamagandang bagay sa mundo, na angkop para sa ganap na lahat!" Well, iyon nga... kadalasan lahat ng ito ay lumalabas na isang pang-aakit lamang, at pagkatapos ang lahat ng ito ay kailangang itapon. Marahil ang lahat ng ito ay dahil ako ay isang matanda na at tumitingin sa mga ganoong bagay na may malaking pag-aalinlangan, kapag ang mga tao ay naubusan at sinabi na natagpuan nila ang Tanging, Pinaka Tamang Paraan upang Lumikha ng Pinakamahuhusay na Teknolohiya. Sa sandaling ito, isang boses ang nagising sa loob ko na nagsasabing: "Ang gulo!"
Michael: Sa katunayan, gaano kadalas natin narinig ang tungkol sa susunod na pilak na bala?
Tim: Eksakto, at ito ang karaniwang takbo ng mga bagay! Halimbawa... tila naging biro na ito sa buong mundo, ngunit dito madalas pinag-uusapan ng mga tao ang teknolohiya ng blockchain. At talagang may katuturan sila sa ilang mga sitwasyon! Kapag talagang kailangan mo ng maaasahang katibayan ng mga kaganapan, na gumagana ang system at walang nanlinlang sa amin, kapag mayroon kang mga problema sa seguridad at lahat ng bagay na pinaghalo-halo - ang blockchain ay may katuturan. Ngunit kapag sinabi nila na ang Blockchain ay magwawalis na ngayon sa buong mundo, wawalin ang lahat ng bagay sa landas nito? Mangarap pa! Ito ay isang napakamahal at kumplikadong teknolohiya. Sa teknikal na kumplikado at pag-ubos ng oras. Kabilang ang puro algorithmically, sa bawat oras na kailangan mong kalkulahin muli ang matematika, na may kaunting pagbabago... at ito ay isang magandang ideya - ngunit para lamang sa ilang mga kaso. Ang aking buong buhay at karera ay tungkol dito: mga kawili-wiling ideya sa mga partikular na sitwasyon. Napakahalaga na maunawaan nang eksakto kung ano ang iyong sitwasyon.
Michael: Oo, ang pangunahing "tanong ng buhay, sansinukob at lahat ng bagay": angkop ba ang teknolohiya o diskarte na ito para sa iyong sitwasyon o hindi?
Tim: Ang tanong na ito ay maaari nang talakayin sa pangkat ng teknolohiya. Baka magdala pa ng consultant. Tingnan ang proyekto at unawain - gagawa ba tayo ngayon ng tama at kapaki-pakinabang, mas mahusay kaysa dati? Baka magkasya, baka hindi. Ngunit ang pinakamahalaga, huwag gumawa ng ganoong desisyon bilang default, dahil lamang sa isang tao na nag-blur out: “Kami ay lubhang nangangailangan ng isang blockchain! Nabasa ko lang siya sa isang magazine sa eroplano!” Seryoso? Hindi man lang nakakatuwa.
Ang gawa-gawa na "devops engineer"
Oleg: Ngayon lahat ay nagpapatupad ng mga devops. May nagbabasa tungkol sa mga devops sa Internet, at bukas ay lilitaw ang isa pang bakante sa isang recruiting site. "devops engineer". Dito nais kong itawag ang iyong pansin: sa palagay mo ba ay may karapatang mabuhay ang terminong ito, "devops engineer?" Mayroong isang opinyon na ang devops ay isang kultura, at isang bagay ay hindi nagdaragdag dito.
Tim: Kaya-kaya. Hayaan silang magbigay kaagad ng ilang paliwanag sa terminong ito. Isang bagay upang gawin itong kakaiba. Hangga't hindi nila napatunayan na may kakaibang kumbinasyon ng mga kasanayan sa likod ng isang bakanteng tulad nito, hindi ako bibili! I mean, well, meron tayong job title, “devops engineer,” isang interesting na titulo, oo, ano ang susunod? Ang mga titulo ng trabaho sa pangkalahatan ay isang napaka-kawili-wiling bagay. Sabihin nating "developer" - ano pa rin ito? Iba't ibang mga organisasyon ang ibig sabihin ay ganap na magkakaibang mga bagay. Sa ilang kumpanya, ang mga de-kalidad na programmer ay nagsusulat ng mga pagsubok na mas makabuluhan kaysa sa mga pagsusulit na isinulat ng mga espesyal na propesyonal na tagasubok sa ibang mga kumpanya. Kaya ano, sila na ba ay mga programmer o tester?
Oo, mayroon kaming mga titulo sa trabaho, ngunit kung magtatanong ka ng sapat na katagalan, sa huli ay lumalabas na tayong lahat ay mga solver ng problema. Kami ay naghahanap ng solusyon, at ang ilan ay may ilang teknikal na kasanayan at ang ilan ay may iba. Kung nakatira ka sa isang kapaligiran kung saan nakapasok ang DevOps, nakikibahagi ka sa pagsasama ng pag-unlad at pangangasiwa, at ang aktibidad na ito ay may ilang medyo mahalagang layunin. Ngunit kung tatanungin ka kung ano ang eksaktong ginagawa mo at kung ano ang iyong pananagutan, lumalabas na ang lahat ng mga bagay na ito ay ginagawa ng mga tao mula pa noong una. "Ako ang responsable para sa arkitektura", "Ako ay responsable para sa mga database" at iba pa, anuman, nakikita mo - lahat ng ito ay bago ang "devops".
Kapag may nagsabi sa akin ng kanilang job title, hindi ako masyadong nakikinig. Mas mainam na hayaan siyang sabihin sa iyo kung ano talaga ang kanyang pananagutan, magbibigay-daan ito sa amin na mas maunawaan ang isyu. Ang paborito kong halimbawa ay kapag ang isang tao ay nagsasabing siya ay isang "tagapamahala ng proyekto." Ano? It doesn't mean anything, hindi ko pa rin alam ang ginagawa mo. Ang isang tagapamahala ng proyekto ay maaaring maging isang developer, ang pinuno ng isang pangkat ng apat na tao, pagsusulat ng code, paggawa ng trabaho, na naging pinuno ng pangkat, na kinikilala ng mga tao sa kanilang sarili bilang isang pinuno. At gayundin, ang isang tagapamahala ng proyekto ay maaaring maging isang tagapamahala na namamahala ng anim na raang tao sa isang proyekto, namamahala sa iba pang mga tagapamahala, ay may pananagutan sa pagguhit ng mga iskedyul at pagpaplano ng mga badyet, iyon lang. Ito ay dalawang ganap na magkaibang mundo! Ngunit pareho ang kanilang titulo sa trabaho.
Ibahin natin ito nang kaunti. Ano ba talaga ang galing mo, maraming karanasan, may talent ka ba? Ano ang magiging responsibilidad mo dahil sa tingin mo ay kakayanin mo ang gawain? At narito ang isang tao ay agad na magsisimulang tanggihan: hindi, hindi, hindi, wala akong pagnanais na makitungo sa mga mapagkukunan ng proyekto, hindi ko ito negosyo, ako ay isang teknikal na tao at naiintindihan ko ang kakayahang magamit at mga interface ng gumagamit, hindi ko Gusto kong pamahalaan ang hukbo ng mga tao sa lahat, hayaan mo akong mas mahusay na magtrabaho.
At sa pamamagitan ng paraan, ako ay isang malaking tagapagtaguyod ng isang diskarte kung saan ang ganitong uri ng paghihiwalay ng mga kasanayan ay gumagana nang maayos. Kung saan maaaring palaguin ng mga technician ang kanilang mga karera hangga't gusto nila. Gayunpaman, nakakakita pa rin ako ng mga organisasyon kung saan nagrereklamo ang mga techie: Kailangan kong pumunta sa pamamahala ng proyekto dahil iyon lang ang paraan sa kumpanyang ito. Minsan ito ay humahantong sa mga kahila-hilakbot na kinalabasan. Ang pinakamahuhusay na tech ay hindi mahusay na mga tagapamahala, at ang pinakamahuhusay na tagapamahala ay hindi kayang pangasiwaan ang teknolohiya. Maging tapat tayo tungkol dito.
Nakikita ko ngayon ang maraming demand para dito. Kung ikaw ay isang techie, matutulungan ka ng iyong kumpanya, ngunit anuman, kailangan mo, talagang kailangan mong hanapin ang iyong sariling career path dahil patuloy na nagbabago ang teknolohiya at kailangan mong baguhin ang iyong sarili kasama nito! Sa loob lamang ng dalawampung taon, maaaring magbago ang mga teknolohiya ng hindi bababa sa limang beses. Ang teknolohiya ay isang kakaibang bagay...
"Mga Eksperto sa Lahat"
Michael: Paano makakayanan ng mga tao ang ganitong bilis ng pagbabago ng teknolohiya? Ang kanilang pagiging kumplikado ay lumalaki, ang kanilang bilang ay lumalaki, ang kabuuang dami ng komunikasyon sa pagitan ng mga tao ay lumalaki din, at lumalabas na hindi ka maaaring maging isang "eksperto sa lahat."
Tim: Tama! Kung nagtatrabaho ka sa teknolohiya, oo, tiyak na kailangan mong pumili ng isang partikular na bagay at pag-aralan ito. Ang ilang teknolohiya na nakikita ng iyong organisasyon na kapaki-pakinabang (at marahil ay talagang magiging kapaki-pakinabang). At kung hindi ka na interesado dito - hinding-hindi ako maniniwala na sasabihin ko ito - mabuti, marahil ay dapat kang lumipat sa ibang organisasyon kung saan ang teknolohiya ay mas kawili-wili o mas maginhawang pag-aralan.
Ngunit sa pangkalahatan, oo, tama ka. Ang mga teknolohiya ay umuunlad sa lahat ng direksyon nang sabay-sabay; walang makapagsasabing "Ako ay isang dalubhasang technologist sa lahat ng mga teknolohiyang umiiral." Sa kabilang banda, may mga taong espongha na literal na sumisipsip ng kaalaman sa teknolohiya at nababaliw dito. Nakakita ako ng ilang ganoong mga tao, literal silang huminga at nabubuhay, kapaki-pakinabang at kawili-wiling makipag-usap sa kanila. Pinag-aaralan nila hindi lamang kung ano ang nangyayari sa loob ng organisasyon, ngunit sa pangkalahatan, pinag-uusapan nila ito, sila rin ay talagang astig na mga technologist, napaka-conscious at may layunin. Sinusubukan lang nilang manatili sa tuktok ng alon, anuman ang kanilang pangunahing trabaho, dahil ang kanilang hilig ay ang paggalaw ng Teknolohiya, ang pagsulong ng teknolohiya. Kung bigla kang makatagpo ng ganoong tao, dapat kang sumama sa tanghalian at pag-usapan ang iba't ibang mga cool na bagay sa tanghalian. Sa tingin ko ang anumang organisasyon ay nangangailangan ng hindi bababa sa isang pares ng mga ganoong tao.
Mga panganib at kawalan ng katiyakan
Michael: Mga pinarangalan na inhinyero, oo. Ating hawakan ang risk management habang may oras tayo. Sinimulan namin ang panayam na ito sa isang talakayan ng medikal na software, kung saan ang mga pagkakamali ay maaaring humantong sa mga kakila-kilabot na kahihinatnan. Pagkatapos ay pinag-usapan namin ang tungkol sa Lunar Program, kung saan ang halaga ng isang error ay milyun-milyong dolyar, at posibleng ilang buhay ng tao. Ngunit ngayon nakikita ko ang kabaligtaran na kilusan sa industriya, ang mga tao ay hindi nag-iisip tungkol sa mga panganib, huwag subukang hulaan ang mga ito, hindi man lang sila obserbahan.
Oleg: Mabilis na kumilos at basagin ang mga bagay!
Michael: Oo, kumilos nang mabilis, basagin ang mga bagay, parami nang parami, hanggang sa mamatay ka sa isang bagay. Mula sa iyong pananaw, paano dapat lapitan ng karaniwang developer ang pag-aaral ng pamamahala sa peligro ngayon?
Tim: Gumuhit tayo ng linya dito sa pagitan ng dalawang bagay: mga panganib at kawalan ng katiyakan. Ito ay iba't ibang bagay. Ang kawalan ng katiyakan ay nangyayari kapag wala kang sapat na data sa anumang partikular na oras upang makarating sa isang tiyak na sagot. Halimbawa, sa pinakaunang yugto ng isang proyekto, kung may nagtanong sa iyo na "kailan mo matatapos ang trabaho," kung medyo tapat kang tao, sasabihin mo, "Wala akong ideya." Hindi mo lang alam, at ayos lang. Hindi mo pa pinag-aralan ang mga problema at hindi pamilyar sa koponan, hindi mo alam ang kanilang mga kasanayan, at iba pa. Ito ay kawalan ng katiyakan.
Ang mga panganib ay lumitaw kapag ang mga potensyal na problema ay maaari nang matukoy. Ang ganitong uri ng bagay ay maaaring mangyari, ang posibilidad nito ay mas malaki kaysa sa zero, ngunit mas mababa sa isang daang porsyento, sa isang lugar sa pagitan. Dahil dito, maaaring mangyari ang anumang bagay, mula sa mga pagkaantala at hindi kinakailangang trabaho, ngunit maging sa isang nakamamatay na resulta para sa proyekto. Ang kinalabasan, kapag sinabi mong - guys, tiklupin natin ang ating mga payong at umalis tayo sa dalampasigan, hindi na natin ito matatapos, tapos na, period. Ginawa namin ang pag-aakalang gagana ang bagay na ito, ngunit hindi ito gumagana, oras na upang huminto. Ito ang mga sitwasyon.
Kadalasan, ang mga problema ay pinakamadaling lutasin kapag ito ay lumitaw na, kapag ang problema ay nangyayari ngayon. Ngunit kapag ang isang problema ay nasa harap mo mismo, hindi ka gumagawa ng pamamahala sa panganib-gumagawa ka ng paglutas ng problema, pamamahala ng krisis. Kung ikaw ay isang nangungunang developer o manager, malamang na iniisip mo kung ano ang maaaring mangyari na hahantong sa mga pagkaantala, nasayang na oras, hindi kinakailangang gastos, o pagbagsak ng buong proyekto? Ano ang magpapahinto sa atin at magsimulang muli? Kapag ang lahat ng mga bagay na ito ay gumana, ano ang gagawin natin sa kanila? Mayroong isang simpleng sagot na wasto para sa karamihan ng mga sitwasyon: huwag tumakas sa mga panganib, gawin ang mga ito. Tingnan kung paano mo mareresolba ang isang mapanganib na sitwasyon, bawasan ito sa wala, gawing ibang bagay mula sa isang problema. Sa halip na sabihin: mabuti, lulutasin natin ang mga problema habang lumalabas ang mga ito.
Ang kawalan ng katiyakan at panganib ay dapat na nasa unahan ng lahat ng iyong pakikitunguhan. Maaari kang kumuha ng plano ng proyekto, tingnan ang ilang mga kritikal na panganib nang maaga at sabihin: kailangan nating harapin ito ngayon, dahil kung ang alinman sa mga ito ay mali, wala nang iba pang mahalaga. Hindi ka dapat mag-alala tungkol sa kagandahan ng tablecloth sa mesa kung hindi malinaw kung maaari kang magluto ng hapunan. Una kailangan mong kilalanin ang lahat ng mga panganib ng paghahanda ng isang masarap na hapunan, harapin ang mga ito, at pagkatapos ay isipin ang lahat ng iba pang mga bagay na hindi nagdudulot ng tunay na banta.
Muli, ano ang natatangi sa iyong proyekto? Tingnan natin kung ano ang maaaring maging sanhi ng pag-alis ng aming proyekto. Ano ang maaari nating gawin upang mabawasan ang posibilidad na mangyari ito? Kadalasan hindi mo lang sila ma-neutralize ng 100% at ipahayag nang may malinis na budhi: "Iyon na nga, hindi na ito problema, nalutas na ang panganib!" Para sa akin ito ay tanda ng pag-uugali ng may sapat na gulang. Ito ang pagkakaiba sa pagitan ng isang bata at isang may sapat na gulang - iniisip ng mga bata na sila ay imortal, na walang maaaring magkamali, magiging maayos ang lahat! Kasabay nito, pinapanood ng mga matatanda kung paano tumalon ang mga tatlong taong gulang na bata sa palaruan, sinusundan ng kanilang mga mata ang mga galaw at sinasabi sa kanilang sarili: "ooh-ooh, ooh-ooh." Tumayo ako sa malapit at naghahanda para saluhin kapag nahulog ang bata.
Sa kabilang banda, ang dahilan kung bakit gusto ko ang negosyong ito ay dahil ito ay mapanganib. Ginagawa namin ang mga bagay, at ang mga bagay na iyon ay mapanganib. Nangangailangan sila ng pang-adultong diskarte. Ang sigasig lamang ay hindi malulutas ang iyong mga problema!
Pang-adultong pag-iisip sa engineering
Michael: Ang halimbawa sa mga bata ay mabuti. Kung ako ay isang ordinaryong inhinyero, kung gayon nalulugod akong maging isang bata. Ngunit paano ka lilipat patungo sa mas matanda na pag-iisip?
Tim: Ang isa sa mga ideya na gumagana nang pantay-pantay sa alinman sa isang baguhan o isang matatag na developer ay ang konsepto ng konteksto. Kung ano ang ating ginagawa, kung ano ang ating maaabot. Ano ba talaga ang mahalaga sa proyektong ito? Hindi mahalaga kung sino ka sa proyektong ito, kung ikaw ay isang intern o ang punong arkitekto, lahat ay nangangailangan ng konteksto. Kailangan nating mahikayat ang lahat na mag-isip sa mas malaking sukat kaysa sa kanilang sariling mga gawain. "Gumawa ako ng aking piraso, at hangga't gumagana ang aking piraso, masaya ako." Hindi at hindi na naman. Laging sulit (nang walang bastos!) na ipaalala sa mga tao ang konteksto kung saan sila nagtatrabaho. Kung ano ang sinusubukan nating lahat na makamit nang sama-sama. Mga ideya na maaari kang maging isang bata hangga't maayos ang lahat sa iyong piraso ng proyekto - mangyaring, huwag gawin iyon. Kung tatawid man tayo sa finish line, magkakasama lang tayong tatawid. Hindi ka nag-iisa, magkasama tayong lahat. Kung ang lahat ng mga tao sa proyekto, matanda at bata, ay nagsimulang mag-usap tungkol sa kung ano ang eksaktong mahalaga sa proyekto, kung bakit ang kumpanya ay namumuhunan ng pera sa kung ano ang sinusubukan nating lahat na makamit... karamihan sa kanila ay magiging mas mabuti dahil sila makikita kung paano nauugnay ang kanilang trabaho sa gawain ng iba. Sa isang banda, naiintindihan ko ang piraso kung saan ako mismo ang may pananagutan. Ngunit para matapos ang trabaho kailangan din natin ang lahat ng iba pang tao. At kung talagang sa tingin mo ay tapos ka na, palagi kaming may gagawin sa proyekto!
Oleg: Sa medyo pagsasalita, kung nagtatrabaho ka ayon sa Kanban, kapag naabot mo ang bottleneck ng ilang pagsubok, maaari mong ihinto ang iyong ginagawa doon (halimbawa, programming) at tumulong sa mga tester.
Tim: Eksakto. I think the best techies, if you look closely at them, they're kind of their own managers. Paano ko ito mabubuo...
Oleg: Ang iyong buhay ay ang iyong proyekto, na iyong pinamamahalaan.
Tim: Eksakto! Ibig kong sabihin, inaako mo ang responsibilidad, naiintindihan mo ang isyu, at nakikipag-ugnayan ka sa mga tao kapag nakita mo na ang iyong mga desisyon ay maaaring makaapekto sa kanilang trabaho, mga bagay na ganoon. Ito ay hindi tungkol sa pag-upo lamang sa iyong mesa, paggawa ng iyong trabaho, at hindi napagtanto kung ano ang nangyayari sa paligid mo. Hindi hindi Hindi. Sa pamamagitan ng paraan, ang isa sa mga pinakamahusay na bagay tungkol sa Agile ay ang kanilang iminungkahi ng mga maikling sprint, dahil sa ganitong paraan ang estado ng mga gawain ng lahat ng mga kalahok ay malinaw na napapansin, makikita nila ang lahat ng ito nang magkasama. Araw-araw kaming nag-uusap tungkol sa isa't isa.
Paano makapasok sa pamamahala ng peligro
Oleg: Mayroon bang anumang pormal na istraktura ng kaalaman sa lugar na ito? Halimbawa, isa akong Java developer at gustong maunawaan ang pamamahala sa peligro nang hindi nagiging tunay na tagapamahala ng proyekto sa pamamagitan ng edukasyon. Malamang na babasahin ko muna ang "Magkano Gastos ng Software Project" ni McConnell, at pagkatapos ay ano? Ano ang mga unang hakbang?
Tim: Ang una ay magsimulang makipag-usap sa mga tao sa proyekto. Nagbibigay ito ng agarang pagpapabuti sa kultura ng komunikasyon sa mga kasamahan. Kailangan nating magsimula sa pamamagitan ng pagbubukas ng lahat bilang default, sa halip na itago ito. Sabihin: ito ang mga bagay na bumabagabag sa akin, ito ang mga bagay na nagpapanatili sa akin sa gabi, nagising ako sa gabi ngayon at parang: Diyos ko, kailangan kong isipin ito! Nakikita ba ng iba ang parehong bagay? Bilang isang grupo, dapat ba tayong tumugon sa mga potensyal na problemang ito? Kailangan mong suportahan ang isang talakayan sa mga paksang ito. Walang pre-prepared formula kung saan kami nagtatrabaho. Hindi ito tungkol sa paggawa ng mga hamburger, ito ay tungkol sa mga tao. "Gumawa ng cheeseburger, magbenta ng cheeseburger" ay hindi natin bagay, at iyon ang dahilan kung bakit mahal na mahal ko ang trabahong ito. Gusto ko kapag lahat ng ginagawa ng mga manager noon ay pag-aari na ng team.
Oleg: Nakipag-usap ka sa mga aklat at panayam tungkol sa kung paano mas pinapahalagahan ng mga tao ang kaligayahan kaysa sa mga numero sa isang graph. Sa kabilang banda, kapag sinabi mo sa koponan: lilipat kami sa devops, at ngayon ang programmer ay dapat na patuloy na makipag-usap, maaaring malayo ito sa kanyang comfort zone. At sa sandaling ito maaari siyang, sabihin nating, labis na malungkot. Ano ang gagawin sa ganitong sitwasyon?
Tim: Hindi ako sigurado kung ano ang gagawin. Kung ang isang developer ay masyadong nakahiwalay, hindi nila nakikita kung bakit ginagawa ang trabaho sa unang lugar, tinitingnan lang nila ang kanilang bahagi ng trabaho, at kailangan nilang pumasok sa tinatawag kong "konteksto." Kailangan niyang malaman kung paano magkakaugnay ang lahat. And of course, I don’t mean formal presentations or anything like that. Pinag-uusapan ko ang katotohanan na kailangan mong makipag-usap sa mga kasamahan tungkol sa trabaho sa kabuuan, at hindi lamang tungkol sa bahagi nito kung saan ikaw ay responsable. Dito mo masisimulan ang pagtalakay ng mga ideya, mga karaniwang kasunduan para maging maayos ang iyong trabaho, at kung paano haharapin ang isang karaniwang problema nang magkasama.
Upang matulungan silang umangkop, madalas nilang gustong magpadala ng mga techie sa pagsasanay, at tinatalakay nila ang pagsasanay. Gustong sabihin ng isang kaibigan ko na ang pagsasanay ay para sa mga aso. May pagsasanay para sa mga tao. Isa sa mga pinakamagandang bagay tungkol sa pag-aaral bilang isang developer ay ang pakikipag-ugnayan sa iyong mga kapantay. Kung ang isang tao ay talagang mahusay sa isang bagay, dapat mong panoorin silang nagtatrabaho o makipag-usap sa kanila tungkol sa kanilang trabaho o isang bagay. Ang ilang maginoo na Kent Beck ay patuloy na nagsasalita tungkol sa matinding programming. Nakakatuwa dahil ang XP ay isang simpleng ideya, ngunit nagdudulot ito ng napakaraming problema. Para sa ilan, ang paggawa ng XP ay parang pinipilit na maghubad sa harap ng mga kaibigan. Makikita nila ang ginagawa ko! Sila ang aking mga kasamahan, hindi lamang nila makikita, ngunit maiintindihan din! Grabe! Ang ilang mga tao ay nagsisimula nang seryosong kinakabahan. Ngunit kapag napagtanto mo na ito ang pinakahuling paraan upang matuto, nagbabago ang lahat. Malapit kang nakikipagtulungan sa mga tao, at mas naiintindihan ng ilang tao ang paksa kaysa sa iyo.
Michael: Ngunit ang lahat ng ito ay pinipilit kang lumabas sa iyong comfort zone. Bilang isang engineer, kailangan mong lumabas sa iyong comfort zone at makipag-usap. Bilang isang solver ng problema, kailangan mong palaging ilagay ang iyong sarili sa isang mahinang posisyon at isipin kung ano ang maaaring magkamali. Ang ganitong uri ng trabaho ay likas na idinisenyo upang maging isang istorbo. Sinasadya mong ilagay ang iyong sarili sa mga nakababahalang sitwasyon. Kadalasan ang mga tao ay tumatakbo palayo sa kanila, ang mga tao ay gustong maging masayang bata.
Tim: Kung ano ang magagawa, maaari kang lumabas at lantarang sabihin: “Okey na ang lahat, kakayanin ko! Hindi lang ako ang hindi komportable. Pag-usapan natin ang iba't ibang mga bagay na hindi komportable, nang sama-sama, bilang isang koponan!" Ito ang mga karaniwang problema natin, dapat nating harapin ang mga ito, alam mo ba? Sa tingin ko ang mga idiosyncratic genius developer ay parang mga mammoth, nawala sila. At ang kanilang kahalagahan ay napakalimitado. Kung hindi ka makapag-communicate, hindi ka makakasali ng maayos. Samakatuwid, magsalita ka lang. Maging tapat at bukas. Ikinalulungkot ko na ito ay hindi kanais-nais para sa isang tao. Maaari mo bang isipin, maraming taon na ang nakalilipas mayroong isang pag-aaral ayon sa kung saan ang pangunahing takot sa Estados Unidos ay hindi kamatayan, ngunit hulaan mo? Takot sa pagsasalita sa publiko! Nangangahulugan ito na sa isang lugar ay may mga taong mas gugustuhin pang mamatay kaysa magsabi ng papuri nang malakas. At sa palagay ko sapat na para sa iyo na magkaroon ng ilang mga pangunahing kasanayan, depende sa iyong ginagawa. Mga kasanayan sa pagsasalita, mga kasanayan sa pagsulat - ngunit hangga't talagang kailangan sa iyong trabaho. Kung nagtatrabaho ka bilang isang analyst, ngunit hindi marunong magbasa, magsulat o magsalita, kung gayon, sa kasamaang palad, wala kang gagawin sa aking mga proyekto!
Ang presyo ng komunikasyon
Oleg: Hindi ba mas mahal ang pagpapatrabaho sa mga papalabas na empleyado sa iba't ibang dahilan? Tutal, palagi silang nagcha-chat imbes na magtrabaho!
Tim: I mean the core of the team, at hindi lang lahat. Kung mayroon kang isang tao na talagang mahusay sa pag-tune ng mga database, mahilig sa pag-tune ng mga database, at magpapatuloy sa pag-tune ng iyong mga database sa buong buhay niya at iyon lang, cool, panatilihin ito. Ngunit pinag-uusapan ko ang mga taong gustong manirahan sa mismong proyekto. Ang core ng koponan, na naglalayong bumuo ng proyekto. Ang mga taong ito ay talagang kailangang patuloy na makipag-usap sa isa't isa. At lalo na sa simula ng proyekto, kapag tinalakay mo ang mga panganib, mga paraan upang makamit ang mga pandaigdigang layunin at mga katulad nito.
Michael: Nalalapat ito sa lahat ng kasangkot sa proyekto, anuman ang espesyalisasyon, kasanayan, o paraan ng pagtatrabaho. Lahat kayo ay interesado sa tagumpay ng proyekto.
Tim: Oo, sa palagay mo ay sapat ka nang nalulubog sa proyekto, na ang iyong gawain ay tulungan ang proyekto na matupad. Kung ikaw ay isang programmer, analyst, interface designer, kahit sino. Ito ang dahilan kung bakit ako pumapasok sa trabaho tuwing umaga at ito ang ginagawa namin. Kami ay responsable para sa lahat ng mga taong ito, anuman ang kanilang mga kasanayan. Ito ay isang grupo ng mga taong may mga pag-uusap na may sapat na gulang.
Oleg: Sa katunayan, nagsasalita tungkol sa mga madaldal na empleyado, sinubukan kong gayahin ang mga pagtutol ng mga tao, lalo na ang mga tagapamahala, na hinihiling na lumipat sa mga devops, sa buong bagong pananaw na ito ng mundo. At ikaw, bilang mga consultant, ay dapat na magkaroon ng kamalayan sa mga pagtutol na ito nang mas mahusay kaysa sa akin, bilang isang developer! Ibahagi kung ano ang pinaka ikinababahala ng mga tagapamahala?
Tim: Mga manager? Hm. Kadalasan, ang mga tagapamahala ay nasa ilalim ng presyur mula sa mga problema, nahaharap sa pangangailangan na agarang maglabas ng isang bagay at gumawa ng paghahatid, at mga katulad nito. Pinapanood nila kung paano kami patuloy na nag-uusap at nagtatalo tungkol sa isang bagay, at nakikita nila ito tulad nito: mga pag-uusap, pag-uusap, pag-uusap... Ano pang mga pag-uusap? Bumalik sa trabaho! Dahil ang pakikipag-usap ay hindi parang trabaho sa kanila. Hindi ka nagsusulat ng code, hindi sumusubok ng software, tila wala kang ginagawa - bakit hindi ka ipadala upang gumawa ng isang bagay? Pagkatapos ng lahat, ang paghahatid ay nasa isang buwan na!
Michael: Sumulat ng ilang code!
Tim: Tila sa akin na hindi sila nag-aalala tungkol sa trabaho, ngunit tungkol sa kakulangan ng kakayahang makita ng pag-unlad. Upang gawin itong parang papalapit na tayo sa tagumpay, kailangan nilang makita tayo sa pagpindot sa mga button sa keyboard. Buong araw mula umaga hanggang gabi. Ito ang numero unong problema.
Oleg: Misha, may iniisip ka.
Michael: Paumanhin, nawala ako sa pag-iisip at nag-flashback. Ang lahat ng ito ay nagpaalala sa akin ng isang kawili-wiling rally na nangyari kahapon... Napakaraming rally kahapon... At parang pamilyar ang lahat!
Buhay na walang sweldo
Tim: Sa pamamagitan ng paraan, hindi kinakailangan na mag-organisa ng mga "rali" para sa komunikasyon. Ibig kong sabihin, ang mga pinakakapaki-pakinabang na talakayan sa pagitan ng mga developer ay nangyayari kapag nag-uusap lang sila sa isa't isa. Naglalakad ka sa umaga na may dalang isang tasa ng kape, at mayroong limang tao na nagtipon at galit na galit na nag-uusap ng isang bagay na teknikal. Para sa akin, kung ako ang tagapamahala ng proyektong ito, mas mabuting ngumiti na lang at pumunta sa kung saan tungkol sa aking negosyo, hayaan silang pag-usapan ito. Kasali na sila hangga't maaari. Ito ay isang magandang senyales.
Oleg: Sa pamamagitan ng paraan, sa iyong libro mayroon kang isang bungkos ng mga tala tungkol sa kung ano ang mabuti at kung ano ang masama. Ginagamit mo ba ang alinman sa mga ito sa iyong sarili? Sa medyo pagsasalita, mayroon ka na ngayong kumpanya, at isa na nakaayos sa isang napaka-unorthodox na paraan...
Tim: Hindi karaniwan, ngunit ang device na ito ay ganap na nababagay sa amin. Matagal na tayong magkakilala. We trust each other, we trusted each other a lot before we became partners. At halimbawa, wala kaming suweldo. Nagtatrabaho lang kami, at halimbawa, kung kumita ako ng pera mula sa aking mga kliyente, kung gayon ang lahat ng pera ay napunta sa akin. Pagkatapos nito, nagbabayad kami ng mga bayarin sa pagiging miyembro sa organisasyon, at ito ay sapat na upang suportahan ang kumpanya mismo. Dagdag pa, lahat tayo ay dalubhasa sa iba't ibang bagay. Halimbawa, nagtatrabaho ako sa mga accountant, pinupunan ang mga tax return, ginagawa ang lahat ng uri ng mga bagay na administratibo para sa kumpanya, at walang nagbabayad sa akin para dito. Nagtatrabaho sina James at Tom sa aming website at wala ring nagbabayad sa kanila. Hangga't nagbabayad ka ng iyong mga dapat bayaran, walang mag-iisip na sabihin sa iyo kung ano ang kailangan mong gawin. Halimbawa, mas mababa na ngayon ang trabaho ni Tom kaysa dati. Ngayon ay mayroon na siyang ibang mga interes; gumagawa siya ng ilang bagay na hindi para sa Guild. Ngunit hangga't nagbabayad siya ng kanyang mga dapat bayaran, walang lalapit sa kanya at magsasabing, “Hoy, Tom, magtrabaho ka na!” Napakadaling makitungo sa mga kasamahan kapag walang pera sa pagitan mo. At ngayon ang aming relasyon ay isa sa mga pangunahing ideya na may kaugnayan sa iba't ibang mga specialty. Ito ay gumagana at ito ay gumagana nang mahusay.
Pinakamahusay na payo
Michael: Ang pagbabalik sa "pinakamahusay na payo," mayroon ka bang paulit-ulit na sinasabi sa iyong mga kliyente? May ideya tungkol sa 80/20, at ang ilang payo ay malamang na paulit-ulit nang mas madalas.
Tim: Minsan naisip ko na kung magsulat ka ng isang libro tulad ng Waltzing with Bears, mababago nito ang takbo ng kasaysayan at titigil ang mga tao, ngunit... Well, tingnan mo, ang mga kumpanya ay madalas na nagpapanggap na ang lahat ay maayos sa kanila. Sa sandaling may masamang mangyari, ito ay isang pagkabigla at isang sorpresa para sa kanila. "Tingnan, sinubukan namin ang system, at hindi ito pumasa sa anumang mga pagsubok sa system, at ito ay isa pang tatlong buwan ng hindi naka-iskedyul na trabaho, paano ito mangyayari? Sino ang nakakaalam? Ano ang maaaring magkamali? Seryoso, naniniwala ka ba dito?
Sinusubukan kong ipaliwanag na hindi ka dapat masyadong magalit sa kasalukuyang sitwasyon. Kailangan nating pag-usapan ito, talagang maunawaan kung ano ang maaaring naging mali, at kung paano mapipigilan ang mga ganitong bagay na mangyari sa hinaharap. Kung ang isang problema ay lilitaw, paano natin ito lalabanan, paano natin ito itatago?
Para sa akin, mukhang nakakatakot ang lahat. Ang mga tao ay humaharap sa mga masalimuot, nakakainis na mga problema at patuloy na nagkukunwari na kung ikrus lang nila ang kanilang mga daliri at umaasa para sa pinakamahusay, ang "pinakamahusay" ay talagang mangyayari. Hindi, hindi ito gumagana sa ganoong paraan.
Magsanay ng pamamahala sa peligro!
Michael: Sa iyong palagay, ilang organisasyon ang nakikibahagi sa pamamahala sa peligro?
Tim: Ang ikinagalit ko ay ang mga tao ay nagsusulat lamang ng mga panganib, tingnan ang resultang listahan at pumunta sa trabaho. Sa katunayan, ang pagtukoy sa mga panganib para sa kanila ay pamamahala ng panganib. Ngunit para sa akin ito ay tila isang dahilan upang magtanong: okay, mayroong isang listahan, ano ang eksaktong babaguhin mo? Kailangan mong baguhin ang iyong karaniwang mga pagkakasunud-sunod ng mga aksyon na isinasaalang-alang ang mga panganib na ito. Kung mayroong ilang pinakamahirap na bahagi ng trabaho, kailangan mong harapin ito, at pagkatapos ay lumipat sa isang bagay na mas simple. Sa mga unang sprint, simulan ang paglutas ng mga kumplikadong problema. Mukhang risk management na ito. Ngunit kadalasan ay hindi masasabi ng mga tao kung ano ang kanilang binago pagkatapos mag-compile ng isang listahan ng mga panganib.
Michael: Gayunpaman, ilan sa mga kumpanyang ito ang kasangkot sa pamamahala ng peligro, limang porsyento?
Tim: Sa kasamaang palad, ayaw kong sabihin ito, ngunit ito ay ilang hindi gaanong mahalagang bahagi. Ngunit higit sa lima, dahil mayroon talagang malalaking proyekto, at hindi sila maaaring umiral kung hindi nila gagawin ang isang bagay. Sabihin na nating magugulat ako kung 25% man lang. Karaniwang sinasagot ng maliliit na proyekto ang mga ganitong katanungan sa ganitong paraan: kung ang problema ay nakakaapekto sa amin, pagkatapos ay malulutas namin ito. Pagkatapos ay matagumpay nilang napasok ang kanilang mga sarili sa problema at nakikibahagi sa pamamahala ng problema at pamamahala ng krisis. Kapag sinubukan mong lutasin ang isang problema at hindi nalutas ang problema, maligayang pagdating sa pamamahala ng krisis.
Oo, madalas kong marinig, "lulutasin natin ang mga problema habang lumalabas." Tiyak na gagawin namin? Magdedesisyon ba talaga tayo?
Oleg: Magagawa mo ito nang walang muwang at simpleng isulat ang mahahalagang invariant sa charter ng proyekto, at kung masira ang mga invariant, i-restart lang ang proyekto. Napaka piembucky pala.
Michael: Oo, nangyari sa akin na kapag ang mga panganib ay na-trigger, ang proyekto ay muling tinukoy. Maganda, bingo, nalutas ang problema, huwag na mag-alala!
Tim: Pindutin natin ang reset button! Hindi, hindi ito gumagana sa ganoong paraan.
Keynote sa DevOops 2019
Michael: Dumating tayo sa huling tanong ng panayam na ito. Pupunta ka sa susunod na DevOops na may pangunahing tono, maaari mo bang alisin ang kurtina ng lihim sa kung ano ang iyong sasabihin?
Tim: Sa ngayon, anim sa kanila ang nagsusulat ng isang libro tungkol sa kultura ng trabaho, ang hindi sinasabing mga tuntunin ng mga organisasyon. Ang kultura ay tinutukoy ng mga pangunahing halaga ng organisasyon. Kadalasan ay hindi ito napapansin ng mga tao, ngunit dahil nagtrabaho sa pagkonsulta sa loob ng maraming taon, nakasanayan na natin itong mapansin. Pumasok ka sa isang kumpanya, at literal sa loob ng ilang minuto ay sisimulan mong maramdaman kung ano ang nangyayari. Tinatawag namin itong "lasa". Minsan ang pabango na ito ay talagang masarap, at kung minsan ito ay, well, oops. Ang mga bagay ay ibang-iba para sa iba't ibang mga organisasyon.
Michael: Ako rin, ay nagtatrabaho sa pagkonsulta sa loob ng maraming taon at naiintindihan kong mabuti kung ano ang iyong pinag-uusapan.
Tim: Sa totoo lang, isa sa mga bagay na dapat pag-usapan sa pangunahing tono ay hindi lahat ay tinutukoy ng kumpanya. Ikaw at ang iyong koponan, bilang isang komunidad, ay may sarili mong kultura ng pangkat. Ito ay maaaring ang buong kumpanya, o isang hiwalay na departamento, isang hiwalay na koponan. Ngunit bago mo sabihin, narito ang pinaniniwalaan namin, narito ang mahalaga... Hindi mo mababago ang isang kultura bago maunawaan ang mga halaga at paniniwala sa likod ng mga partikular na aksyon. Ang pag-uugali ay madaling obserbahan, ngunit ang paghahanap ng mga paniniwala ay mahirap. Ang DevOps ay isa lamang magandang halimbawa kung paano nagiging mas kumplikado ang mga bagay. Ang mga pakikipag-ugnayan ay nagiging mas kumplikado lamang, ang mga ito ay hindi nagiging mas malinis o mas malinaw, kaya dapat mong isipin kung ano ang iyong pinaniniwalaan at kung ano ang tahimik ng lahat sa iyong paligid.
Kung gusto mong makamit ang mabilis na mga resulta, narito ang isang magandang paksa para sa iyo: nakakita ka na ba ng mga kumpanya kung saan walang nagsasabing "Hindi ko alam"? May mga lugar kung saan literal mong pinahihirapan ang isang tao hanggang sa umamin siya na wala siyang alam. Alam ng lahat ang lahat, lahat ay isang hindi kapani-paniwalang erudite. Lumapit ka sa sinumang tao, at kailangan niyang sagutin kaagad ang tanong. Sa halip na sabihing "Hindi ko alam." Hooray, kumuha sila ng isang grupo ng mga erudites! At sa ilang mga kultura, sa pangkalahatan ay lubhang mapanganib na sabihin ang "Hindi ko alam"; maaari itong isipin bilang isang tanda ng kahinaan. Mayroon ding mga organisasyon kung saan, sa kabaligtaran, lahat ay maaaring magsabi ng "Hindi ko alam." Doon ito ay ganap na legal, at kung ang isang tao ay nagsimulang magbasa-basa bilang tugon sa isang tanong, ganap na normal na sagutin ang: "Hindi mo alam kung ano ang iyong pinag-uusapan, tama ba?" at gawing biro ang lahat.
Sa isip, gusto mong magkaroon ng trabaho kung saan maaari kang palaging masaya. Hindi ito magiging madali, hindi araw-araw ay maaraw at kaaya-aya, kung minsan kailangan mong magtrabaho nang husto, ngunit kapag nagsimula kang mag-stock, ito ay lalabas: wow, ito ay isang talagang kahanga-hangang lugar, pakiramdam ko ay maganda ang pagtatrabaho dito, parehong emosyonal at intelektwal. At may mga kumpanya kung saan ka pupunta bilang isang consultant at agad na napagtanto na hindi mo ito matiis sa loob ng tatlong buwan at tatakas sa takot. Ito ang gusto kong pag-usapan sa ulat.
Darating si Tim Lister na may dalang pangunahing tono sa DevOops 2019 conference, na magaganap sa Oktubre 29-30, 2019 sa St. Petersburg. Maaari kang bumili ng mga tiket . Hinihintay ka namin sa DevOops!
Pinagmulan: www.habr.com