Tim Lister - co-penulis buku
- "Faktor manungsa. Proyek lan Tim sing Sukses" (buku asli diarani "Peopleware")
- "Waltzing with the Bears: Managing Risk in Software Projects"
- "Adrenalin-crazed lan zombified dening pola. Pola prilaku tim proyek"
Kabeh buku iki klasik ing lapangan lan ditulis bebarengan karo kolega ing . Ing Rusia, kolega paling misuwur - и , sing uga nulis akeh karya misuwur.
Tim duwe pengalaman 40 taun ing pangembangan piranti lunak; ing taun 1975 (ora ana sing nulis habrapost iki sing lair taun iki), Tim wis dadi wakil presiden eksekutif Yourdon Inc. Dheweke saiki ngentekake wektu kanggo konsultasi, mulang, lan nulis, kanthi kadang-kadang ngunjungi konferensi ing saindhenging donya.
Kita nindakake wawancara karo Tim Lister utamane kanggo Habr. Dheweke bakal mbukak konferensi DevOops 2019, lan kita duwe akeh pitakonan, babagan buku lan liya-liyane. Wawancara ditindakake dening Mikhail Druzhinin lan Oleg Chirukhin saka panitia program konferensi.
Michael: Apa sampeyan bisa ngomong sawetara tembung babagan apa sing sampeyan lakoni saiki?
Tim: Aku kepala Atlantic Systems Guild. Ana enem kita ing Guild, kita nyebut dhéwé kepala sekolah. Telu ing AS lan telu ing Eropa - mulane Guild diarani Atlantik. Kita wis bebarengan nganti pirang-pirang taun nganti sampeyan ora bisa ngetung. Kita kabeh duwe spesialisasi dhewe. Aku wis nggarap klien sajrone dekade kepungkur utawa luwih. Proyekku kalebu ora mung manajemen, nanging uga setelan syarat, perencanaan proyek, lan evaluasi. Iku misale jek sing proyèk sing miwiti kurang biasane rampung miskin. Pramila prayoginipun supados sedaya kagiyatan menika leres-leres dipunpikir lan dipun koordinasi, supados ide-ide para pangripta dipungabungaken. Sampeyan kudu mikir babagan apa sing sampeyan lakoni lan apa sebabe. Sastranegara apa sing digunakake kanggo ngrampungake proyek kasebut.
Aku wis konseling klien ing macem-macem cara kanggo akèh taun. Conto sing menarik yaiku perusahaan sing nggawe robot kanggo operasi lutut lan pinggul. Dokter bedah ora nindakake operasi kanthi mandiri, nanging nggunakake robot. Safety ing kene, terus terang, penting. Nanging nalika sampeyan nyoba kanggo ngrembug syarat karo wong sing fokus kanggo ngrampungake masalah ... Iku bakal muni aneh, nanging ing Amerika Serikat ana (Federal Drug Administration), sing menehi lisensi produk kaya robot iki. Sadurunge adol apa-apa lan digunakake kanggo wong urip, sampeyan kudu njaluk lisensi. Salah sawijining syarat yaiku nuduhake syarat sampeyan, apa tes kasebut, kepiye sampeyan nguji, apa asil tes kasebut. Yen sampeyan ngganti syarat, sampeyan kudu ngliwati proses tes sing gedhe iki maneh lan maneh. Klien kita bisa nyakup desain visual aplikasi ing syarate. Dheweke duwe gambar langsung minangka bagean saka syarat. Kita kudu narik metu lan nerangake manawa umume kabeh program iki ora ngerti apa-apa babagan dhengkul lan pinggul, kabeh iki nganggo kamera, lsp. Kita kudu nulis maneh dokumen syarat supaya ora owah, kajaba sawetara kahanan dhasar sing penting banget. Yen desain visual ora ana ing syarat, nganyari produk bakal luwih cepet. Tugas kita yaiku nemokake unsur-unsur sing ana hubungane karo operasi ing dhengkul, pinggul, punggung, narik metu menyang dokumen sing kapisah lan ujar manawa iki bakal dadi syarat dhasar. Ayo nggawe klompok syarat sing terisolasi babagan operasi lutut. Iki bakal ngidini kita mbangun syarat sing luwih stabil. Kita bakal ngomong babagan kabeh baris produk, lan ora babagan robot tartamtu.
Akeh karya wis rampung, nanging isih padha teka ing panggonan ngendi sadurunge padha ngginakaken minggu lan sasi saka tes bola-bali tanpa makna utawa perlu, amarga syarat sing diterangake ing kertas ora pas karo syarat nyata kanggo kang sistem dibangun. FDA ngandhani saben wektu: syarat sampeyan wis diganti, saiki sampeyan kudu mriksa kabeh saka awal. Rechecks lengkap kabeh produk mateni perusahaan.
Dadi, ana tugas sing apik banget nalika sampeyan nemokake dhewe ing awal sing menarik, lan tumindak sing pisanan nyetel aturan game kasebut. Yen sampeyan mesthekake yen kegiatan awal iki wiwit bisa digunakake kanthi apik saka sudut pandang manajerial lan teknis, ana kemungkinan sampeyan bakal entuk proyek sing apik. Nanging yen bagean iki wis metu saka ril lan musna nang endi wae salah, yen sampeyan ora bisa nemokake persetujuan dhasar ... ora, iku ora proyek sampeyan mesthi bakal gagal. Nanging sampeyan ora bakal bisa ngomong maneh: "Kita nindakake kanthi apik, kita nindakake kabeh kanthi efektif." Iki minangka perkara sing daklakoni nalika sesambungan karo klien.
Michael: Yaiku, sampeyan miwiti proyek, nindakake sawetara jinis kickoff lan priksa manawa rel kasebut mlaku ing arah sing bener?
Tim: Kita uga duwe ide babagan carane nggabungake kabeh potongan teka-teki: katrampilan apa sing dibutuhake, kapan pancen dibutuhake, apa inti saka tim kasebut lan perkara dhasar liyane. Apa kita butuh karyawan full-time utawa bisa nyewa wong paruh wektu? Perencanaan, manajemen. Pitakonan kaya: Apa sing paling penting kanggo proyek tartamtu iki? Kepiye carane entuk iki? Apa sing kita ngerti babagan produk utawa proyek iki, apa risiko lan ing endi sing ora dingerteni, kepiye carane ngatasi kabeh iki? Mesthi wae, ing wektu iki ana wong sing nguwuh-uwuh "Kepriye tangkas?!" Oke, sampeyan kabeh fleksibel, nanging apa? Apa persis kaya proyek kasebut, kepiye carane sampeyan bakal nindakake kanthi cara sing cocog karo proyek kasebut? Sampeyan ora bisa mung ngomong yen "pendekatan kita babagan apa wae, kita tim Scrum!" Iki omong kosong lan omong kosong. Terus arep menyang endi, kok kudu bisa, titik endi? Aku mulang klienku mikir babagan kabeh pitakonan kasebut.
19 taun tangkas
Michael: Ing Agile, wong asring nyoba ora nemtokake apa-apa ing advance, nanging kanggo nggawe pancasan minangka pungkasan sabisa, ngandika: kita amba banget, Aku ora bakal mikir bab arsitektur sakabèhé. Aku ora bakal mikir babagan akeh perkara liyane; tinimbang, aku bakal ngirim barang sing bisa digunakake kanggo pelanggan saiki.
Tim: Aku sing metodologi tangkas, miwiti karo ing 2001, kabuka mata industri. Nanging ing sisih liya, ora ana sing sampurna. Aku kabeh kanggo pangembangan iteratif. Pengulangan ndadekake akeh pangertèn ing umume proyek. Nanging pitakonan sing kudu dipikirake yaiku: yen produk wis metu lan digunakake, suwene suwene? Apa iki produk sing bakal tahan nem sasi sadurunge diganti karo liyane? Utawa iki produk sing bakal bisa kanggo akeh, akeh taun? Mesthi wae, aku ora bakal menehi jeneng, nanging ... Ing New York lan komunitas finansial, sistem paling dhasar wis lawas banget. Iki apik tenan. Sampeyan ndeleng wong-wong mau lan mikir, yen sampeyan bisa bali ing wektu, menyang 1994, lan ngandhani pangembang: "Aku teka saka mangsa ngarep, saka 2019. Mung gawe sistem iki kanggo anggere sampeyan perlu. Nggawe expandable, mikir babagan arsitektur. Banjur bakal didandani luwih saka rong puluh lima taun. Yen sampeyan nundha pembangunan luwih suwe, ing rencana gedhe, ora ana sing bakal weruh! Nalika sampeyan ngira-ngira prekara-prekara ing jangka panjang, sampeyan kudu nimbang sepira regane total. Kadhangkala arsitektur sing dirancang kanthi apik pancen pantes, lan kadhangkala ora. Kita kudu nggoleki lan takon dhéwé: apa kita ana ing kahanan sing bener kanggo keputusan kasebut?
Dadi gagasan kaya "We are agile, customer dhewe bakal ngandhani apa sing dikarepake" - iku super naif. Pelanggan malah ora ngerti apa sing dikarepake, lan luwih-luwih dheweke ora ngerti apa sing bisa ditampa. Sawetara wong bakal miwiti nyebut conto sajarah minangka bantahan, aku wis weruh iki. Nanging wong sing teknis maju ora biasane ngomong. Dheweke ujar: "Iki taun 2019, iki minangka kesempatan sing kita duwe, lan kita bisa ngganti cara kita ndeleng perkara kasebut!" Tinimbang niru solusi sing wis ana, nggawe dheweke luwih ayu lan luwih apik, kadhangkala sampeyan kudu metu lan ujar: "Ayo ngrampungake apa sing lagi ditindakake ing kene!"
Lan aku ora mikir umume pelanggan bisa mikir babagan masalah kasebut. Dheweke mung ndeleng apa sing wis ana, kabeh iku. Sawisé iku padha teka karo panjalukan kaya "ayo nggawe iki sethitik prasaja,"Utawa apa wae sing biasane ngomong. Nanging kita dudu pelayan utawa pelayan, mula kita bisa njupuk pesenan ora preduli sepira bodho kasebut banjur dipanggang ing pawon. Kita dadi panuntune. Kita kudu mbukak mata lan ngomong: hey, kita duwe kesempatan anyar ing kene! Apa sampeyan ngerti yen kita bisa ngganti cara bisnis sampeyan rampung? Salah sawijining masalah karo Agile yaiku mbusak kesadaran babagan apa kesempatan, apa masalah, apa sing kudu ditindakake, apa teknologi sing kasedhiya sing paling cocog kanggo kahanan tartamtu iki.
Mbokmenawa aku kebacut mamang ing kene: ana akeh kedadeyan sing apik banget ing komunitas sing lincah. Nanging aku duwe masalah karo kasunyatan sing tinimbang nemtokake proyek, wong wiwit mbuwang tangan. Aku bakal takon ing kene - apa sing kita lakoni, kepiye carane? Lan piye wae ajaib, mesthine klien kudu ngerti luwih apik tinimbang sapa wae. Nanging klien paling ngerti mung nalika dheweke milih saka barang sing wis dibangun dening wong. Yen aku pengin tuku mobil lan ngerti ukuran anggaran kulawarga, aku bakal cepet milih mobil sing cocog karo gaya uripku. Ing kene aku ngerti kabeh luwih apik tinimbang sapa wae! Nanging elinga yen ana wong sing wis nggawe mobil kasebut. Aku ora ngerti carane nggawe mobil anyar, aku ora ahli. Nalika nggawe produk khusus utawa khusus, swara pelanggan kudu dianggep, nanging iki ora mung siji-sijine swara.
Oleg: Sampeyan kasebut Manifesto Agile. Apa kita kudu nganyari utawa mbenakake kanthi nganggep pemahaman modern babagan masalah kasebut?
Tim: Aku ora bakal ndemek dheweke. Aku iki dokumen sajarah gedhe. Maksudku, dheweke iku apa. Dheweke umure 19 taun, umure wis tuwa, nanging ing jamane dheweke nggawe revolusi. Apa sing ditindakake kanthi apik yaiku dheweke nyebabake reaksi lan wong-wong mulai bisik-bisik babagan dheweke. Sampeyan, paling mungkin, durung kerja ing industri ing taun 2001, nanging banjur kabeh wong kerja miturut proses. Software Engineering Institute, limang tingkat saka model kelengkapan piranti lunak (CMMI). Aku ora ngerti yen legenda kuno kasebut ngandhani apa-apa, nanging banjur dadi terobosan. Kaping pisanan, wong percaya yen proses wis disetel kanthi bener, mula masalah kasebut bakal nguap dhewe. Lan banjur Manifesto teka lan ujar: "Ora, ora, ora - kita bakal adhedhasar wong, dudu proses." Kita minangka master pangembangan piranti lunak. Kita ngerti yen proses becik iku fatamorgana, ora kelakon. Ana kakehan idiosyncrasy ing proyèk, idea saka siji proses sampurna kanggo kabeh proyek ora nggawe raos. Masalah sing rumit banget kanggo ngaku yen mung ana siji solusi kanggo kabeh (halo, nirwana).
Aku ora nganggep ndeleng masa depan, nanging aku bakal ujar manawa wong saiki wis mulai mikir babagan proyek. Aku rumangsa Manifesto Agile apik banget kanggo mlumpat lan ujar, "Hei! Sampeyan ana ing kapal, lan sampeyan dhewe nyopir kapal iki. Sampeyan kudu nggawe keputusan - kita ora bakal menehi saran resep universal kanggo kabeh kahanan. Sampeyan kru kapal, lan yen sampeyan cukup apik, sampeyan bisa nemokake cara kanggo goal. Ana kapal liyane sadurunge sampeyan, lan bakal ana kapal liyane sawise sampeyan, nanging isih, ing pangertèn, lelampahan sampeyan unik. Mergo ngono! Iku cara mikir. Kanggo kula, ora ana sing anyar ing sangisore srengéngé, wong wis lelayaran sadurunge lan bakal lelayaran maneh, nanging kanggo sampeyan iki minangka lelampahan utama, lan aku ora bakal ngandhani apa sing bakal kelakon karo sampeyan. Sampeyan kudu duwe katrampilan kerja sing terkoordinasi ing tim, lan yen sampeyan pancene duwe, kabeh bakal bisa ditindakake lan sampeyan bakal entuk apa sing dikarepake.
Peopleware: 30 taun sabanjure
Oleg: Apa Peopleware minangka revolusi uga Manifesto?
Tim: Peopleware... Aku lan Tom nulis buku iki, nanging ora ngira yen bakal kelakon kaya iki. Piye wae, iku resonate karo akeh gagasan wong. Iki minangka buku pisanan sing ujar: pangembangan piranti lunak minangka kegiatan intensif manungsa. Senadyan sifat teknis kita, kita uga minangka komunitas wong sing mbangun barang sing gedhe, malah ageng, rumit banget. Ora ana sing bisa nggawe barang kaya ngono dhewe, ta? Dadi, gagasan "tim" dadi penting banget. Lan ora mung saka sudut pandang manajemen, nanging uga kanggo wong teknis sing teka bebarengan kanggo ngrampungake masalah jero sing rumit banget karo akeh sing ora dingerteni. Kanggo kula pribadi, iki minangka tes intelijen sing gedhe sajrone karirku. Lan ing kene sampeyan kudu bisa ngomong: ya, masalah iki luwih saka aku dhewe, nanging bebarengan kita bisa nemokake solusi elegan sing bisa kita bangga. Lan aku iki idea sing paling resonated. Ing idea sing kita bisa bagean wektu dhewe, bagéan saka wektu minangka bagéan saka grup, lan asring kaputusan digawe dening grup. Pemecahan masalah klompok kanthi cepet dadi fitur penting proyek kompleks.
Senadyan kasunyatan manawa Tim wis menehi akeh rembugan, mung sawetara sing dikirim ing YouTube. Sampeyan bisa ndeleng laporan "The Return of Peopleware" saka 2007. Kualitas, mesthi, ninggalake akeh sing dikarepake.
Michael: Apa ana owah-owahan sajrone 30 taun kepungkur wiwit buku kasebut diterbitake?
Tim: Sampeyan bisa ndeleng iki saka macem-macem sudhut. Secara sosiologis... biyen, ing wektu sing luwih prasaja, sampeyan lan tim sampeyan lungguh ing kantor sing padha. Sampeyan bisa cedhak saben dina, ngombe kopi bareng lan ngrembug babagan kerja. Apa sing wis owah tenan yaiku tim saiki bisa disebarake sacara geografis, ing macem-macem negara lan zona wektu, nanging isih padha nggarap masalah sing padha, lan iki nambah kerumitan lapisan anyar. Iki bisa uga muni lawas-sekolah, nanging ana apa-apa kaya komunikasi pasuryan-kanggo-pasuryan ngendi sampeyan kabeh bebarengan, makarya bebarengan, lan sampeyan bisa lumaku nganti rowange lan ngomong, katon apa aku katutup, carane kowe kaya iki? Obrolan adhep-adhepan nyedhiyakake cara sing cepet kanggo transisi menyang komunikasi ora resmi, lan aku mikir para penggemar tangkas uga seneng. Lan aku uga kuwatir amarga ing kasunyatan donya wis dadi cilik banget, lan saiki kabeh wis dijamin karo tim mbagekke, lan iku kabeh banget Komplek.
Kita kabeh manggon ing DevOps
Michael: Malah saka sudut pandang panitia program konferensi, kita duwe wong ing California, ing New York, Eropa, Rusia ... durung ana wong ing Singapura. Bentenipun geografi cukup gedhe, lan wong-wong wiwit nyebar luwih akeh. Yen kita ngomong babagan pembangunan, sampeyan bisa ngomong babagan devops lan ngilangi alangan ing antarane tim? Ana konsep sing saben wong lungguh ing bunkers, lan saiki bunkers ambruk, apa sampeyan mikir analogi iki?
Tim: Iku misale jek kula sing ing cahya saka terobosan teknologi anyar, devops wigati banget. Sadurunge, sampeyan duwe tim pangembang lan pangurus, padha makarya, makarya, makarya, lan ing sawetara titik ana bab sing bisa teka menyang admins lan muter metu kanggo produksi. Lan ing kene obrolan babagan bunker diwiwiti, amarga para admin minangka sekutu, dudu mungsuh, paling ora, nanging sampeyan mung ngobrol nalika kabeh wis siyap kanggo produksi. Apa sampeyan pindhah menyang wong-wong mau karo soko lan ngandika: katon apa aplikasi kita duwe, nanging sampeyan bisa muter metu aplikasi iki? Lan saiki kabeh konsep pangiriman wis diganti dadi luwih apik. Maksudku, ana gagasan iki supaya sampeyan bisa ngowahi kanthi cepet. Kita bisa nganyari produk kanthi cepet. Aku tansah eseman nalika Firefox ing laptop njedhul munggah lan ngandika, hey, kita wis nganyari Firefox ing latar mburi, lan sanalika sampeyan duwe menit, sampeyan kepikiran ngeklik kene lan kita bakal menehi release paling anyar. Lan aku kaya, "Oh ya, bayi!" Nalika aku lagi turu, dheweke lagi nggarap rilis anyar ing komputerku. Iki apik tenan, luar biasa.
Nanging iki kangelan: sampeyan duwe fitur iki karo nganyari piranti lunak, nanging nggabungake wong luwih angel. Apa sing dakkarepake ing intine DevOops yaiku saiki kita duwe pemain luwih akeh tinimbang sing nate kita lakoni. Yen sampeyan mung mikir babagan kabeh wong sing melu mung siji tim…. Sampeyan dianggep minangka tim, lan iku luwih saka mung tim programer. Iki minangka penguji, manajer proyek, lan akeh wong liya. Lan saben wong duwe pandangan dhewe babagan jagad iki. Manajer produk beda banget karo manajer proyek. Admin duwe tugas dhewe-dhewe. Dadi masalah sing rada angel kanggo koordinasi kabeh peserta supaya terus ngerti apa sing kedadeyan lan ora dadi edan. Sampeyan kudu misahake tugas klompok lan tugas sing ditrapake kanggo saben wong. Iki tugas sing angel banget. Ing sisih liya, aku rumangsa luwih apik tinimbang pirang-pirang taun kepungkur. Iki minangka dalan sing tuwuh lan sinau tumindak kanthi bener. Yen sampeyan nindakake integrasi, sampeyan ngerti manawa ora ana pangembangan lemah, supaya ing wektu pungkasan piranti lunak ora nyusup kaya jack-in-the-box: kaya, deleng apa sing ditindakake ing kene! Ide iki yaiku sampeyan bakal bisa nindakake integrasi lan pangembangan, lan ing pungkasan sampeyan bakal muter kanthi cara sing rapi lan iteratif. Kabeh iki tegese banget kanggo aku. Iki ndadekake iku bisa kanggo nggawe luwih Nilai kanggo pangguna saka sistem lan kanggo klien.
Michael: Ide kabeh devops yaiku ngirim pangembangan sing migunani sakcepete. Aku weruh sing donya wis wiwit nyepetake liyane lan liyane. Kepiye cara adaptasi karo percepatan kasebut? Sepuluh taun kepungkur iki ora ana!
Tim: Mesthine, kabeh wong pengin luwih akeh fungsi. Ora perlu ngalih, mung numpuk liyane. Kadhangkala sampeyan kudu alon-alon kanggo nganyari tambahan sabanjure kanggo nggawa apa-apa sing migunani - lan iku pancen normal.
Gagasan yen sampeyan kudu mlayu, mlayu, mlayu dudu sing paling apik. Ora mungkin ana wong sing pengin urip kaya ngono. Aku pengin irama pangiriman kanggo nyetel irama proyek dhewe. Yen sampeyan mung ngasilake aliran barang-barang cilik sing ora ana gunane, kabeh ora ana artine. Tinimbang nyoba ngluncurake barang-barang sakcepete, apa sing kudu dirembug karo pangembang utama lan manajer produk lan proyek yaiku strategi. Apa iki malah nggawe pangertèn?
Pola lan antipola
Oleg: Sampeyan biasane ngomong babagan pola lan antipattern, lan iki bedane antarane urip lan mati proyek. Lan saiki, devops bursts menyang gesang kita. Apa duwe pola lan anti-pola dhewe sing bisa mateni proyek kasebut ing papan kasebut?
Tim: Pola lan anti-pola kedadeyan kabeh wektu. Soko kanggo ngomong bab. Nah, ana sing diarani "barang mengkilat." Wong pancene seneng teknologi anyar. Dheweke mung kaget karo kabeh sing katon apik lan apik, lan dheweke mandheg takon: apa perlu? Apa sing arep kita gayuh? Apa iki bisa dipercaya, apa ana gunane? Aku kerep ndeleng wong, supaya bisa ngomong, ing pinggiran nglereni teknologi. Dheweke dihipnotis dening apa sing kedadeyan ing jagad iki. Nanging yen sampeyan ndeleng kanthi cetha babagan apa sing migunani, asring ora ana sing migunani!
Kita mung rembugan karo kanca-kanca yen taun iki minangka ulang taun, seket taun wiwit wong ndharat ing rembulan. Iki ana ing 1969. Teknologi sing mbantu wong teka ing kana dudu teknologi 1969, nanging 1960 utawa 62, amarga NASA mung pengin nggunakake apa sing nduweni bukti linuwih. Lan sampeyan ndeleng lan ngerti - ya, lan padha bener! Saiki, ora, ora, nanging sampeyan nemu masalah karo teknologi mung amarga kabeh di-push banget hard, didol saka kabeh retak. Wong-wong padha bengok-bengok saka ngendi-endi: "Lah, apa, iki sing paling anyar, sing paling apik ing donya, cocog kanggo kabeh wong!" Lha yo ngono... biasane kabeh iki mung dadi umpan, banjur kabeh kudu dibuwang. Mbok menawa kabeh iki amarga aku wis tuwa lan ndeleng perkara kasebut kanthi skeptisisme sing gedhe, nalika wong-wong kehabisan lan ujar manawa dheweke wis nemokake Mung, Cara Paling Bener kanggo Nggawe Teknologi Paling Apik. Ing wayahe iki, ana swara tangi ing njeroku sing ujar: "Kekacoan!"
Michael: Pancen, sepira kerepe kita krungu babagan peluru perak sabanjure?
Tim: Persis, lan iki mesthi wae! Contone ... misale jek iki wis dadi lelucon ing saindhenging donya, nanging ing kene wong asring ngomong babagan teknologi blockchain. Lan padha bener nggawe pangertèn ing kahanan tartamtu! Yen sampeyan pancene mbutuhake bukti sing bisa dipercaya babagan acara, manawa sistem kasebut bisa digunakake lan ora ana sing ngapusi kita, yen sampeyan duwe masalah keamanan lan kabeh barang sing dicampur bebarengan - blockchain ndadekake akal. Nanging nalika ujar manawa Blockchain saiki bakal nyapu ing saindenging jagad, nyapu kabeh sing ana ing dalane? Ngimpi liyane! Iki minangka teknologi sing larang banget lan rumit. Teknis rumit lan akeh wektu. Kalebu murni algoritma, saben-saben sampeyan kudu ngetung maneh matématika, kanthi owah-owahan sing paling sithik ... lan iki minangka ide sing apik - nanging mung kanggo kasus tartamtu. Kabeh urip lan karirku babagan iki: ide sing menarik ing kahanan sing spesifik. Penting banget kanggo ngerti persis apa kahanan sampeyan.
Michael: Ya, "pitakonan urip, alam semesta lan kabeh" utama: apa teknologi utawa pendekatan iki cocok kanggo kahanan sampeyan utawa ora?
Tim: Pitakonan iki wis bisa dirembug karo klompok teknologi. Mungkin malah nggawa sawetara konsultan. Deleng proyek kasebut lan mangertos - apa kita saiki bakal nindakake sing bener lan migunani, luwih apik tinimbang sadurunge? Mungkin bakal pas, bisa uga ora. Nanging sing paling penting, aja nggawe keputusan kasebut kanthi standar, mung amarga ana wong sing ngomong: "Kita butuh blokir! Aku mung maca babagan dheweke ing majalah ing pesawat!” Serius? Iku malah ora lucu.
Mitos "devops engineer"
Oleg: Saiki kabeh wong ngleksanakake devops. Ana sing maca babagan devops ing Internet, lan sesuk ana lowongan liyane ing situs recruiting. "devops engineer". Ing kene aku pengin narik kawigaten sampeyan: apa sampeyan mikir istilah iki, "devops engineer," duwe hak kanggo urip? Ana panemu yen devops minangka budaya, lan ana sing ora ana ing kene.
Tim: Dadi-dadi. Ayo padha langsung menehi sawetara panjelasan babagan istilah iki. Soko kanggo nggawe unik. Nganti padha mbuktekaken sing ana sawetara kombinasi unik saka skills konco lowongan kaya iki, Aku ora bakal tuku! Maksudku, uga, kita duwe judhul proyek, "devops engineer," judhul menarik, ya, apa sabanjure? Judhul proyek umume minangka perkara sing menarik. Ayo ngomong "pangembang" - apa iku? Organisasi sing beda-beda tegese beda banget. Ing sawetara perusahaan, programer berkualitas tinggi nulis tes sing luwih penting tinimbang tes sing ditulis dening penguji profesional khusus ing perusahaan liyane. Dadi apa, saiki programer utawa penguji?
Ya, kita duwe judhul proyek, nanging yen sampeyan takon pitakon sing cukup suwe, pungkasane, kita kabeh dadi pemecah masalah. We are golek solusi, lan sawetara duwe sawetara skills technical lan sawetara duwe beda. Yen sampeyan manggon ing lingkungan sing wis nembus DevOps, sampeyan melu integrasi pembangunan lan administrasi, lan kegiatan iki nduweni tujuan sing cukup penting. Nanging yen sampeyan ditakoni apa sing sampeyan lakoni lan tanggung jawab sampeyan, pranyata wong-wong wis nindakake kabeh iki wiwit jaman biyen. "Aku tanggung jawab kanggo arsitektur", "Aku tanggung jawab kanggo database" lan liya-liyane, apa wae, sampeyan ndeleng - kabeh iki sadurunge "devops".
Yen ana wong sing ngandhani jabatane, aku ora ngrungokake. Iku luwih apik kanggo menehi pitutur marang kowe apa kang bener tanggung jawab kanggo, iki bakal ngidini kita kanggo ngerti masalah luwih. Conto sing paling disenengi yaiku nalika ana wong sing ngaku dadi "manajer proyek." opo? Ora ana maksud apa-apa, aku isih ora ngerti apa sing sampeyan lakoni. Manajer proyek bisa dadi pangembang, pimpinan tim papat wong, nulis kode, nindakake karya, sing wis dadi pimpinan tim, sing diakoni dening wong liya minangka pimpinan. Lan uga, manajer proyek bisa dadi manajer sing ngatur nem atus wong ing sawijining proyek, ngatur manajer liyane, tanggung jawab kanggo nggawe jadwal lan ngrencanakake anggaran, kabeh iku. Iki rong donya temen beda! Nanging judhul proyek padha muni.
Ayo dadi ngowahi iki rada beda. Apa sampeyan pancene apik, duwe pengalaman akeh, apa sampeyan duwe bakat? Apa sing bakal sampeyan tanggung jawab amarga sampeyan mikir sampeyan bisa nangani tugas kasebut? Lan ing kene wong bakal langsung nolak: ora, ora, ora, aku ora duwe kepinginan kanggo ngatasi sumber daya proyek, dudu bisnisku, aku wong lanang teknis lan aku ngerti kegunaan lan antarmuka pangguna, aku ora ngerti. pengin ngatur tentara wong ing kabeh, mugi kula pindhah menyang karya.
Lan omong-omong, aku dadi panyengkuyung gedhe saka pendekatan sing pemisahan katrampilan iki bisa digunakake. Ing endi teknisi bisa tuwuh karir nganti tekan sing dikarepake. Nanging, aku isih ndeleng organisasi sing para teknisi ngeluh: Aku kudu melu manajemen proyek amarga mung siji-sijine cara ing perusahaan iki. Kadhangkala iki ndadékaké kanggo asil elek. Teknisi paling apik dudu manajer sing apik, lan manajer sing paling apik ora bisa nangani teknologi. Ayo dadi jujur babagan iki.
Aku ndeleng akeh panjaluk iki saiki. Yen sampeyan teknisi, perusahaan sampeyan bisa nulungi sampeyan, nanging preduli, sampeyan kudu golek dalan karir dhewe amarga teknologi terus ganti lan sampeyan kudu nggawe maneh dhewe! Mung rong puluh taun, teknologi bisa diganti paling ora kaping lima. Teknologi iku aneh ...
"Pakar ing Kabeh"
Michael: Kepiye carane wong bisa ngatasi owah-owahan teknologi kaya ngono? Kerumitan saya tambah akeh, jumlahe saya tambah, jumlah komunikasi antarane wong uga saya tambah, lan ternyata sampeyan ora bisa dadi "ahli ing kabeh."
Tim: Bener! Yen sampeyan kerja ing teknologi, ya, sampeyan kudu milih sing spesifik lan nyinaoni. Sawetara teknologi sing ditemokake organisasi sampeyan migunani (lan bisa uga migunani). Lan yen sampeyan ora kasengsem maneh - aku ora bakal percaya yen aku bakal ngomong iki - uga, bisa uga sampeyan kudu pindhah menyang sawetara organisasi liyane sing teknologi luwih menarik utawa luwih trep kanggo sinau.
Nanging ing umum, ya, sampeyan bener. Teknologi berkembang ing kabeh arah bebarengan; ora ana sing bisa ngomong "Aku ahli teknologi ing kabeh teknologi sing ana." Ing tangan liyane, ana wong karang sing secara harfiah nyerep kawruh teknologi lan edan babagan iki. Aku wis ndeleng saperangan saka wong kuwi, padha secara harfiah ambegan lan manggon, iku migunani lan menarik kanggo ngomong karo wong-wong mau. Dheweke ora mung nyinaoni apa sing kedadeyan ing njero organisasi, nanging umume, dheweke ngomong babagan iki, dheweke uga ahli teknologi sing apik banget, dheweke sadar lan duwe tujuan. Padha mung nyoba kanggo tetep ing puncak gelombang, preduli saka apa proyek utama, amarga passion iku gerakan Teknologi, promosi teknologi. Yen dumadakan ketemu wong kuwi, sampeyan kudu nedha awan karo wong lan ngrembug macem-macem kelangan ing nedha awan. Aku mikir organisasi apa wae mbutuhake paling ora sawetara wong kaya ngono.
Resiko lan kahanan sing durung mesthi
Michael: Insinyur sing diajeni, ya. Ayo ndemek manajemen risiko nalika kita duwe wektu. Kita miwiti wawancara iki kanthi diskusi babagan piranti lunak medis, ing ngendi kesalahan bisa nyebabake akibat sing ala. Banjur kita ngomong babagan Program Lunar, ing ngendi biaya kesalahan jutaan dolar, lan bisa uga sawetara nyawa manungsa. Nanging saiki aku weruh gerakan ngelawan ing industri, wong ora mikir bab risiko, ora nyoba kanggo prédhiksi wong, malah ora mirsani wong.
Oleg: Pindhah cepet lan break samubarang!
Michael: Ya, obah cepet, rusak barang, liyane lan liyane, nganti sampeyan mati saka soko. Saka sudut pandang sampeyan, kepiye cara pangembang rata-rata sinau manajemen risiko saiki?
Tim: Ayo dadi garis ing antarane rong perkara: risiko lan kahanan sing durung mesthi. Iki macem-macem. Ora mesthi kedadeyan nalika sampeyan ora duwe data sing cukup ing wektu tartamtu kanggo entuk jawaban sing pasti. Contone, ing tahap awal proyek, yen ana wong sing takon "kapan sampeyan bakal ngrampungake karya", yen sampeyan jujur banget, sampeyan bakal kandha, "Aku ora ngerti." Sampeyan mung ora ngerti, lan ora apa-apa. Sampeyan durung sinau masalah lan ora kenal karo tim, sampeyan ora ngerti katrampilane, lan liya-liyane. Iki kahanan sing durung mesthi.
Resiko muncul nalika masalah potensial wis bisa diidentifikasi. Iki jenis bisa kelakon, kemungkinan iku luwih saka nul, nanging kurang saka satus persen, nang endi wae ing antarane. Amarga iku, apa wae bisa kelakon, saka telat lan karya rasah, nanging malah kanggo asil fatal kanggo project. Asil, nalika sampeyan ngomong - wong, ayo melu payung lan ninggalake pantai, kita ora bakal rampung, kabeh wis rampung, titik. We digawe Panyangka sing bab iki bakal bisa, nanging ora bisa ing kabeh, iku wektu kanggo mungkasi. Iki kahanan.
Asring, masalah paling gampang ditanggulangi nalika wis muncul, nalika masalah wis kedadeyan saiki. Nanging nalika ana masalah ana ing ngarep sampeyan, sampeyan ora nindakake manajemen risiko-sampeyan lagi ngrampungake masalah, manajemen krisis. Yen sampeyan minangka pangembang utawa manajer utama, sampeyan kudu mikir apa sing bisa kedadeyan sing bakal nyebabake telat, wektu sing boros, biaya sing ora perlu, utawa ambruk kabeh proyek? Apa sing bakal nggawe kita mandheg lan miwiti maneh? Nalika kabeh iki bisa ditindakake, apa sing bakal kita lakoni? Ana jawaban prasaja sing bener kanggo umume kahanan: aja mlayu saka risiko, kerjane. Waca carane sampeyan bisa mutusake masalah kahanan sing beboyo, nyuda dadi apa-apa, nguripake saka masalah menyang liyane. Tinimbang ngomong: uga, kita bakal ngatasi masalah nalika muncul.
Kahanan sing durung mesthi lan risiko kudu ana ing ngarep kabeh sing sampeyan lakoni. Sampeyan bisa njupuk rencana proyek, ndeleng risiko kritis tartamtu sadurunge lan ujar: kita kudu ngatasi iki saiki, amarga yen ana sing salah, ora ana sing penting. Sampeyan ora kudu kuwatir babagan kaendahan taplak meja ing meja yen ora jelas yen sampeyan bisa masak nedha bengi. Pisanan sampeyan kudu ngenali kabeh risiko nyiyapake nedha bengi éca, menehi hasil karo wong-wong mau, lan mung banjur mikir bab kabeh liyane sing ora nuduhke ancaman nyata.
Maneh, apa sing nggawe proyek sampeyan unik? Ayo ndeleng apa sing bisa nggawe proyek kita metu saka rel. Apa sing bisa ditindakake kanggo nyuda kemungkinan kedadeyan kasebut? Biasane sampeyan ora mung bisa netralake 100% lan nyatakake kanthi ati nurani sing resik: "Iki, iki ora dadi masalah maneh, risiko wis rampung!" Kanggo kula iki minangka tandha prilaku diwasa. Iki prabédan antarane bocah lan wong diwasa - bocah-bocah mikir yen dheweke ora bisa mati, ora ana sing salah, kabeh bakal apik! Ing wektu sing padha, wong diwasa nonton carane bocah-bocah umur telung taun mlumpat ing papan dolanan, tindakake obahe kanthi mripate lan ngomong dhewe: "ooh-ooh, ooh-ooh." Aku ngadeg ing cedhak lan siyap-siyap nyekel nalika bocah tiba.
Ing sisih liya, sebabe aku seneng banget karo bisnis iki amarga beboyo. Kita nindakake samubarang, lan iku beboyo. Padha mbutuhake pendekatan diwasa. Semangat mung ora bakal ngrampungake masalah sampeyan!
Pemikiran teknik diwasa
Michael: Conto karo bocah-bocah iku apik. Yen aku dadi insinyur biasa, aku seneng dadi bocah. Nanging kepiye sampeyan pindhah menyang pikiran sing luwih diwasa?
Tim: Salah sawijining gagasan sing bisa digunakake kanthi apik karo pamula utawa pangembang sing mapan yaiku konsep konteks. Apa sing kita lakoni, apa sing bakal kita gayuh. Apa sing penting banget ing proyek iki? Ora preduli sapa sampeyan ing proyek iki, apa sampeyan intern utawa kepala arsitek, kabeh wong butuh konteks. Kita kudu nggawe saben wong mikir kanthi skala sing luwih gedhe tinimbang karyane dhewe. "Aku nggawe potonganku, lan anggere potonganku bisa digunakake, aku seneng." Ora lan ora maneh. Iku tansah worth (tanpa kang ora sopan!) kanggo ngelingake wong ing konteks kang padha makarya. Apa kita kabeh nyoba kanggo entuk bebarengan. Gagasan yen sampeyan bisa dadi bocah anggere kabeh apik karo proyek sampeyan - mangga, aja nglakoni. Yen kita ngliwati garis finish, kita mung bakal nyabrang bebarengan. Sampeyan ora piyambak, kita kabeh bebarengan. Yen kabeh wong ing proyek kasebut, tuwa lan enom, wiwit ngomong babagan apa sing penting banget kanggo proyek kasebut, kenapa perusahaan nandur modal dhuwit kanggo apa sing bakal ditindakake ... bakal weruh kepriye hubungane karo karyane wong liya. Ing tangan siji, aku ngerti potongan sing aku tanggung jawab. Nanging kanggo ngrampungake tugas, kita uga butuh kabeh wong liya. Lan yen sampeyan pancene mikir wis rampung, kita mesthi duwe karya sing kudu ditindakake ing proyek kasebut!
Oleg: Relatif, yen sampeyan kerja miturut Kanban, nalika sampeyan ngalami bottleneck saka sawetara tes, sampeyan bisa mandheg saka apa sing ditindakake ing kana (contone, program) lan nulungi para penguji.
Tim: Persis. Aku mikir teknisi sing paling apik, yen sampeyan ndeleng kanthi teliti, dheweke pancen manajer dhewe. Kepiye carane aku bisa ngrumusake iki ...
Oleg: Urip sampeyan minangka proyek sampeyan, sing sampeyan atur.
Tim: Persis! Maksudku, sampeyan njupuk tanggung jawab, sampeyan ngerti masalah kasebut, lan sampeyan bisa kontak karo wong nalika sampeyan ndeleng keputusan sampeyan bisa mengaruhi karyane, kaya ngono. Ora mung lungguh ing meja, nindakake pakaryan, lan ora ngerti apa sing kedadeyan ing sekitar sampeyan. Ora ora ora. Miturut cara, salah siji sing paling apik babagan Agile yaiku dheweke ngusulake sprint cendhak, amarga kanthi cara iki kahanan kabeh peserta bisa diamati kanthi jelas, bisa ndeleng kabeh bebarengan. Kita ngomong bab saben liyane saben dina.
Carane njaluk menyang Manajemen resiko
Oleg: Apa ana struktur kawruh formal ing wilayah iki? Contone, aku dadi pangembang Jawa lan pengin ngerti manajemen risiko tanpa dadi manajer proyek nyata kanthi pendidikan. Aku mbokmenawa bakal maca McConnell "Pinten Biaya Proyek Perangkat Lunak" dhisik, banjur apa? Apa langkah pisanan?
Tim: Pisanan yaiku miwiti komunikasi karo wong ing proyek kasebut. Iki nyedhiyakake paningkatan langsung ing budaya komunikasi karo kolega. Kita kudu miwiti kanthi mbukak kabeh kanthi standar, tinimbang ndhelikake. Kandhaa: iki sing dadi ganggu aku, iki sing njalari aku ing wayah bengi, aku tangi ing wayah bengi lan kaya: Dhuh Allah, aku kudu mikir babagan iki! Apa wong liya ndeleng perkara sing padha? Minangka klompok, apa kita kudu nanggapi masalah potensial kasebut? Sampeyan kudu bisa ndhukung diskusi babagan topik kasebut. Ora ana rumus sing wis disiapake sing bisa digunakake. Iki dudu babagan nggawe hamburger, nanging kabeh babagan wong. "Digawe cheeseburger a, ngedol cheeseburger" ora bab kita ing kabeh, lan mulane aku tresna proyek iki dadi luwih. Aku seneng yen kabeh sing ditindakake manajer saiki dadi properti tim.
Oleg: Sampeyan wis ngomong ing buku lan wawancara babagan carane wong luwih peduli babagan rasa seneng tinimbang angka ing grafik. Ing tangan liyane, nalika sampeyan marang tim: kita pindhah menyang devops, lan saiki programmer kudu terus komunikasi, iki bisa uga adoh njaba zona comfort. Lan ing wektu iki, dheweke bisa uga ora seneng banget. Apa sing kudu ditindakake ing kahanan iki?
Tim: Aku ora yakin persis apa sing kudu dilakoni. Yen pangembang banget diisolasi, padha ora weruh apa karya wis rampung ing Panggonan pisanan, padha mung katon ing bagean saka karya, lan padha kudu njaluk menyang apa aku nelpon "konteks." Dheweke kudu ngerti carane kabeh disambungake bebarengan. Lan mesthi, aku ora ateges presentasi formal utawa liya-liyane. Aku ngomong bab kasunyatan sing kudu komunikasi karo kolega bab karya minangka kabèh, lan ora mung bab bagean sing tanggung jawab. Iki ngendi sampeyan bisa miwiti ngrembug gagasan, persetujuan umum kanggo nggawe karya cocok bebarengan, lan carane nyegat masalah umum bebarengan.
Kanggo mbantu dheweke adaptasi, dheweke kerep pengin ngirim teknisi menyang latihan, lan dheweke ngrembug babagan latihan. Kancaku seneng ngomong yen latihan kanggo asu. Ana latihan kanggo wong. Salah sawijining perkara sing paling apik babagan sinau minangka pangembang yaiku sesambungan karo kanca-kanca. Yen ana wong sing apik banget, sampeyan kudu nonton dheweke kerja utawa ngomong karo dheweke babagan pakaryan utawa apa wae. Sawetara Kent Beck konvensional terus-terusan ngomong babagan program ekstrem. Iku lucu amarga XP minangka gagasan prasaja, nanging nyebabake akeh masalah. Kanggo sawetara, nindakake XP kaya dipeksa telanjang ing ngarepe kanca. Dheweke bakal weruh apa sing daklakoni! Dheweke kanca-kancaku, dheweke ora mung bakal weruh, nanging uga ngerti! nggegirisi! Sawetara wong mulai gemeter banget. Nanging yen sampeyan ngerti yen iki minangka cara paling apik kanggo sinau, kabeh bakal owah. Sampeyan makarya kanthi rapet karo wong, lan sawetara wong ngerti topik kasebut luwih apik tinimbang sampeyan.
Michael: Nanging kabeh iki meksa sampeyan metu saka zona nyaman. Minangka insinyur, sampeyan kudu metu saka zona nyaman lan komunikasi. Minangka pemecah masalah, sampeyan kudu terus-terusan nyelehake awake dhewe ing posisi sing ringkih lan mikir babagan apa sing bisa salah. Jinis karya iki sipate dirancang kanggo dadi gangguan. Sampeyan kanthi sengaja nyelehake dhewe ing kahanan stres. Biasane wong mlayu, wong seneng dadi bocah sing seneng.
Tim: Apa sing bisa ditindakake, sampeyan bisa metu lan ngomong kanthi terang: "Kabeh ora apa-apa, aku bisa ngatasi! Ora mung aku sing ngrasa ora kepenak. Ayo ngrembug macem-macem perkara sing ora nyenengake, kabeh bebarengan, minangka tim! Iki minangka masalah umum, kita kudu ngatasi, sampeyan ngerti? Aku pangembang genius idiosyncratic kaya mammoths, padha ilang. Lan pinunjul banget winates. Yen sampeyan ora bisa komunikasi, sampeyan ora bisa melu kanthi apik. Mulane, mung ngomong. Jujur lan mbukak. Aku banget nuwun sing iki ora nyenengake kanggo wong. Apa sampeyan bisa mbayangno, pirang-pirang taun kepungkur ana panaliten miturut sing wedi utama ing Amerika Serikat ora pati, nanging guess apa? Wedi ngomong umum! Iki tegese nang endi wae ana wong sing luwih seneng mati tinimbang ngucapake pujian kanthi banter. Lan aku iku cukup kanggo sampeyan duwe sawetara skills dhasar, gumantung apa apa. Katrampilan ngomong, katrampilan nulis - nanging mung kaya sing dibutuhake ing karya sampeyan. Yen sampeyan kerja minangka analis, nanging ora bisa maca, nulis utawa ngomong, banjur, sayangé, sampeyan ora bakal duwe apa-apa ing proyekku!
Rega komunikasi
Oleg: Apa ora makaryakke karyawan metu kuwi luwih larang kanggo macem-macem alasan? Sawise kabeh, dheweke terus-terusan ngobrol tinimbang nggarap!
Tim: Maksudku inti saka tim, lan ora mung saben wong. Yen sampeyan duwe wong sing pancene keren ing tuning database, tresna tuning database, lan bakal terus tuning database kanggo liyane urip lan iku, kelangan, tetep munggah. Nanging aku ngomong babagan wong sing pengin manggon ing proyek kasebut. Inti tim, ngarahake ngembangake proyek kasebut. Wong-wong iki pancen kudu terus-terusan komunikasi karo saben liyane. Lan utamane ing wiwitan proyek, nalika sampeyan ngrembug babagan risiko, cara kanggo nggayuh tujuan global lan liya-liyane.
Michael: Iki ditrapake kanggo kabeh wong sing melu proyek, preduli saka spesialisasi, katrampilan, utawa cara kerja. Sampeyan kabeh kasengsem ing sukses project.
Tim: Ya, sampeyan rumangsa wis cukup nyemplungake proyek kasebut, yen tugas sampeyan yaiku mbantu proyek kasebut dadi kenyataan. Apa sampeyan programmer, analis, desainer antarmuka, sapa wae. Iki sebabe aku teka kerja saben esuk lan iki sing ditindakake. Kita tanggung jawab kanggo kabeh wong iki, preduli saka skills. Iki minangka klompok wong sing ngobrol karo wong diwasa.
Oleg: Nyatane, ngandika bab karyawan talkative, Aku nyoba kanggo simulasi bantahan wong, utamané Managers, sing dijaluk kanggo ngalih menyang devops, kanggo sesanti anyar iki donya. Lan sampeyan, minangka konsultan, kudu ngerti bantahan kasebut luwih apik tinimbang aku, minangka pangembang! Nuduhake apa sing paling kuwatir para manajer?
Tim: Manajer? Hm. Paling asring, manajer ngalami tekanan saka masalah, ngadhepi kebutuhan kanggo ngeculake barang kanthi cepet lan ngirim kiriman, lan liya-liyane. Padha nonton carane kita terus-terusan ngrembug lan mbantah babagan apa wae, lan padha ndeleng kaya iki: obrolan, obrolan, obrolan ... Apa obrolan liyane? Balik kerja! Amarga omong-omongan kuwi ora krasa kerjane. Sampeyan ora nulis kode, ora nyoba piranti lunak, kayane ora nindakake apa-apa - kenapa ora ngirim sampeyan nindakake? Sawise kabeh, pangiriman wis ing sasi!
Michael: Ayo nulis sawetara kode!
Tim: Iku misale jek kula sing padha ora kuwatir bab karya, nanging lack of visibilitas kemajuan. Supaya katon kaya kita nyedhaki sukses, dheweke kudu ndeleng kita mencet tombol ing keyboard. Sedina muput saka esuk nganti sore. Iki masalah nomer siji.
Oleg: Misha, sampeyan lagi mikir babagan.
Michael: Nuwun sewu, aku kesasar lan kejiret flashback. Kabeh iki ngelingake aku babagan rapat umum sing menarik sing kedadeyan wingi ... Ana akeh banget rally wingi ... Lan kabeh muni banget!
Urip tanpa gaji
Tim: Miturut cara, ora perlu kanggo ngatur "rallies" kanggo komunikasi. Maksudku, diskusi sing paling migunani ing antarane pangembang kedadeyan nalika mung ngobrol. Sampeyan lumaku ing esuk karo tuwung saka warung, lan ana wong lima padha kumpul lan furiously ngrembug bab technical. Kanggo kula, yen aku dadi manajer proyek iki, luwih becik mung mesem lan lunga menyang ngendi wae babagan bisnisku, ayo padha ngrembug. Padha wis melu sabisa. Iki minangka tandha apik.
Oleg: Miturut cara, ing buku sampeyan duwe akeh cathetan babagan apa sing apik lan sing ala. Apa sampeyan nggunakake salah siji saka wong-wong mau dhewe? Relatif ngandika, saiki sampeyan duwe perusahaan, lan siji sing kabentuk ing cara banget unorthodox ...
Tim: Unorthodox, nanging piranti iki cocog karo kita. Kita wis kenal suwe. Kita dipercaya saben liyane, kita dipercaya banget sadurunge kita dadi partner. Contone, kita ora duwe gaji. Kita mung bisa, lan contone, yen aku entuk dhuwit saka klien, banjur kabeh dhuwit menyang kula. Sawise iku, kita mbayar biaya anggota kanggo organisasi, lan iki cukup kanggo ndhukung perusahaan kasebut. Kajaba iku, kita kabeh duwe spesialisasi ing macem-macem perkara. Contone, aku kerja karo akuntan, ngisi pengembalian pajak, nindakake kabeh perkara administratif kanggo perusahaan, lan ora ana sing mbayar. James lan Tom nggarap situs web kita lan ora ana sing mbayar. Anggere sampeyan mbayar iuran, ora ana sing bakal ngandhani apa sing kudu sampeyan lakoni. Contone, Tom saiki kerjane luwih sithik tinimbang biyen. Saiki dheweke duwe kapentingan liyane; dheweke nindakake sawetara perkara sing ora kanggo Guild. Nanging salawasé mbayar utangé, ora ana sing marani dhèwèké lan kandha, ”He, Tom, ayo kerja!” Gampang banget kanggo menehi hasil karo kolega nalika ora ana dhuwit ing antarane sampeyan. Lan saiki hubungan kita minangka salah sawijining ide dhasar sing ana hubungane karo spesialisasi sing beda. Kerjane lan kerjane apik banget.
Saran paling apik
Michael: Mbalik maneh menyang "saran sing paling apik," apa ana sing sampeyan pitutur marang klien bola-bali? Ana idea bab 80/20, lan sawetara saran mbokmenawa bola luwih asring.
Tim: Aku tau mikir yen sampeyan nulis buku kaya Waltzing karo Bears, iku bakal ngganti dalan sajarah lan wong bakal mandheg, nanging ... Inggih, katon, perusahaan asring ndalang sing kabeh iku apik karo wong-wong mau. Sanalika ana kedadeyan sing ala, dheweke kaget lan kaget. "Deleng, kita nyoba sistem kasebut, lan ora lulus tes sistem, lan iki telung wulan kerja sing ora dijadwalake, kepiye kedadeyan kasebut? Sapa sing ngerti? Apa bisa salah? Serius, apa sampeyan percaya iki?
Aku nyoba nerangake yen sampeyan ora kudu nesu banget babagan kahanan saiki. Kita kudu ngomong, ngerti apa sing bisa salah, lan carane nyegah kedadeyan kasebut ing mangsa ngarep. Yen masalah katon, kepiye cara kita nglawan, kepiye cara ngatasi?
Kanggo kula, kabeh iki katon medeni. Wong-wong ngadhepi masalah sing rumit lan ngganggu lan terus pura-pura yen mung nyabrang driji lan ngarep-arep sing paling apik, "paling apik" bakal kelakon. Ora, ora bisa kaya ngono.
Praktek manajemen risiko!
Michael: Miturut pendapat sampeyan, pira organisasi sing melu manajemen risiko?
Tim: Sing nggumunake yaiku wong mung nulis risiko, ndeleng dhaptar asil lan kerja. Nyatane, ngenali risiko kanggo wong-wong mau yaiku manajemen risiko. Nanging kanggo kula iki muni kaya alesan kanggo takon: oke, ana dhaftar, apa persis sampeyan bakal ngganti? Sampeyan kudu ngganti urutan tumindak standar kanthi njupuk risiko kasebut. Yen ana sawetara bagean paling angel saka karya, sampeyan kudu nyegat iku, lan mung banjur pindhah menyang soko prasaja. Ing sprints pisanan, miwiti ngrampungake masalah rumit. Iki wis katon kaya manajemen risiko. Nanging biasane wong ora bisa ngomong apa sing diganti sawise nyusun dhaptar risiko.
Michael: Nanging, pira perusahaan kasebut melu manajemen risiko, limang persen?
Tim: Sayange, aku sengit ngomong iki, nanging iki minangka bagean sing ora pati penting. Nanging luwih saka limang, amarga ana proyek gedhe banget, lan mung ora bisa ana yen ora nindakake apa-apa. Ayo ngomong yen aku bakal kaget banget yen paling sethithik 25%. Proyek cilik biasane mangsuli pitakon kaya mangkene: yen masalah kasebut mengaruhi kita, mula kita bakal ngrampungake. Banjur dheweke kasil ngalami masalah lan melu manajemen masalah lan manajemen krisis. Nalika sampeyan nyoba kanggo ngatasi masalah lan masalah ora ditanggulangi, welcome kanggo manajemen krisis.
Ya, aku kerep krungu, "kita bakal ngrampungake masalah nalika muncul." Mesthi kita bakal? Apa kita bakal mutusake?
Oleg: Sampeyan bisa nindakake iku naively lan mung nulis invariants penting menyang charter project, lan yen invariants break, mung miwiti maneh project. Pranyata metu banget piembucky.
Michael: Ya, aku kedaden yen nalika risiko dipicu, proyek kasebut mung ditetepake maneh. Nice, bingo, masalah ditanggulangi, aja padha sumelang maneh!
Tim: Ayo pencet tombol reset! Ora, ora bisa kaya ngono.
Intine ing DevOops 2019
Michael: Kita teka menyang pitakonan pungkasan wawancara iki. Sampeyan bakal teka ing DevOops sabanjure kanthi intine, apa sampeyan bisa mbukak sandiworo rahasia babagan apa sing bakal sampeyan ucapake?
Tim: Saiki, enem wong nulis buku babagan budaya kerja, aturan organisasi sing ora diucapake. Budaya ditemtokake dening nilai-nilai inti organisasi. Biasane wong ora sok dong mirsani iki, nanging wis makarya ing consulting kanggo akèh taun, kita wis digunakake kanggo sok dong mirsani iku. Sampeyan ngetik perusahaan, lan secara harfiah ing sawetara menit sampeyan wiwit aran apa mengkono. Kita nyebut iki "rasa". Kadhangkala wangi iki pancen apik, lan kadhangkala uga, oops. Iku beda banget kanggo organisasi sing beda-beda.
Michael: Aku uga wis pirang-pirang taun kerja konsultasi lan ngerti apa sing sampeyan gunakake.
Tim: Bener, salah sawijining perkara sing kudu diomongake ing intine yaiku ora kabeh ditemtokake dening perusahaan. Sampeyan lan tim sampeyan, minangka komunitas, duwe budaya tim dhewe. Iki bisa dadi kabeh perusahaan, utawa departemen sing kapisah, tim sing kapisah. Nanging sadurunge sampeyan ngomong, iki sing kita yakini, iki sing penting ... Sampeyan ora bisa ngganti budaya sadurunge nilai lan kapercayan ing mburi tumindak tartamtu dingerteni. Tingkah laku iku gampang diamati, nanging nggoleki kapercayan iku angel. DevOps mung minangka conto sing apik babagan kedadeyane dadi luwih rumit. Interaksi mung dadi luwih rumit, ora dadi luwih resik utawa luwih jelas, mula sampeyan kudu mikir babagan apa sing sampeyan yakini lan apa wae sing ora ana ing sekitar sampeyan.
Yen sampeyan pengin entuk asil cepet, iki topik sing apik kanggo sampeyan: apa sampeyan ndeleng perusahaan sing ora ana sing ngomong "Aku ora ngerti"? Ana panggonan ing ngendi sampeyan secara harfiah nyiksa wong nganti dheweke ngakoni yen dheweke ora ngerti apa-apa. Saben uwong ngerti kabeh, kabeh wong minangka erudite sing luar biasa. Sampeyan nyedhaki sapa wae, lan dheweke kudu langsung mangsuli pitakon kasebut. Tinimbang ngomong "Aku ora ngerti." Hooray, padha nyewa Bunch saka erudites! Lan ing sawetara budaya umume mbebayani banget kanggo ngomong "Aku ora ngerti"; bisa dianggep minangka tandha kelemahane. Ana uga organisasi sing, sebaliknya, saben wong bisa ngomong "Aku ora ngerti." Ing kana iku pancen sah, lan yen ana wong sing wiwit mbuwang sampah kanggo nanggepi pitakonan, mesthine normal kanggo mangsuli: "Sampeyan ora ngerti apa sing sampeyan gunakake, ta?" lan ngowahi kabeh dadi guyon.
Saenipun, sampeyan pengin duwe proyek ing ngendi sampeyan bisa seneng kabeh wektu. Ora bakal gampang, ora saben dina cerah lan nyenengake, kadhangkala kudu kerja keras, nanging yen sampeyan miwiti nyiyapake, bakal dadi: wah, iki pancen apik banget, aku seneng kerja ing kene, loro emosional lan intelektual. Lan ana perusahaan sing dadi konsultan lan langsung ngerti yen sampeyan ora tahan suwene telung sasi lan bakal mlayu kanthi medeni. Iki sing arep dakkandhakake ing laporan kasebut.
Tim Lister bakal teka kanthi intine menyang konferensi DevOops 2019, sing bakal ditindakake ing 29-30 Oktober 2019 ing St. Sampeyan bisa tuku tiket . Kita nunggu sampeyan ing DevOops!
Source: www.habr.com