Tim Lister - pengarang bersama buku
- "Faktor manusia. Projek dan Pasukan yang Berjaya" (buku asal dipanggil "Peopleware")
- "Waltzing with the Bears: Menguruskan Risiko dalam Projek Perisian"
- “Gila adrenalin dan zombi dengan corak. Corak tingkah laku pasukan projek"
Semua buku ini adalah klasik dalam bidang mereka dan ditulis bersama-sama dengan rakan sekerja dalam . Di Rusia, rakan sekerjanya paling terkenal - и , yang juga menulis banyak karya terkenal.
Tim mempunyai 40 tahun pengalaman dalam pembangunan perisian; pada tahun 1975 (tiada seorang pun daripada mereka yang menulis habrapost ini dilahirkan tahun ini), Tim sudah pun menjadi naib presiden eksekutif Yourdon Inc. Dia kini menghabiskan masanya untuk berunding, mengajar, dan menulis, dengan melawat sekali-sekala persidangan di seluruh dunia.
Kami melakukan temu bual dengan Tim Lister khas untuk Habr. Dia akan membuka persidangan DevOops 2019, dan kami mempunyai banyak soalan, tentang buku dan banyak lagi. Temu bual dikendalikan oleh Mikhail Druzhinin dan Oleg Chirukhin daripada jawatankuasa program persidangan.
Michael: Bolehkah anda mengatakan beberapa perkataan tentang apa yang anda lakukan sekarang?
Tim: Saya ketua Persatuan Sistem Atlantik. Kami berenam dalam Guild, kami memanggil diri kami pengetua. Tiga di AS dan tiga di Eropah - itulah sebabnya Guild dipanggil Atlantik. Kami telah bersama selama bertahun-tahun sehingga anda tidak dapat menghitungnya. Kita semua ada kepakaran masing-masing. Saya telah bekerja dengan pelanggan selama sedekad yang lalu atau lebih. Projek saya termasuk bukan sahaja pengurusan, tetapi juga penetapan keperluan, perancangan projek dan penilaian. Nampaknya projek yang bermula dengan buruk biasanya berakhir dengan buruk. Oleh itu, adalah wajar untuk memastikan bahawa semua aktiviti benar-benar difikirkan dengan baik dan diselaraskan, bahawa idea pencipta digabungkan. Perlu difikirkan tentang apa yang anda lakukan dan mengapa. Apakah strategi yang perlu digunakan untuk menyiapkan projek tersebut.
Saya telah menasihati klien dalam pelbagai cara selama bertahun-tahun. Contoh yang menarik ialah syarikat yang membuat robot untuk pembedahan lutut dan pinggul. Pakar bedah tidak beroperasi sepenuhnya secara bebas, tetapi menggunakan robot. Keselamatan di sini, terus terang bercakap, adalah penting. Tetapi apabila anda cuba membincangkan keperluan dengan orang yang tertumpu pada penyelesaian masalah... Ia akan kedengaran pelik, tetapi di USA ada (Pentadbiran Dadah Persekutuan), yang melesenkan produk seperti robot ini. Sebelum anda menjual apa-apa dan menggunakannya pada orang yang masih hidup, anda perlu mendapatkan lesen. Salah satu syarat adalah untuk menunjukkan keperluan anda, apakah ujian itu, bagaimana anda mengujinya, apakah keputusan ujian. Jika anda menukar keperluan, maka anda perlu melalui keseluruhan proses ujian besar ini lagi dan lagi. Pelanggan kami berjaya memasukkan reka bentuk visual aplikasi dalam keperluan mereka. Mereka mempunyai tangkapan skrin secara langsung sebagai sebahagian daripada keperluan. Kami perlu menariknya keluar dan menjelaskan bahawa sebahagian besar semua program ini tidak tahu apa-apa tentang lutut dan pinggul, semua perkara ini dengan kamera, dsb. Kita perlu menulis semula dokumen keperluan supaya ia tidak pernah berubah, melainkan beberapa keadaan asas yang benar-benar penting berubah. Jika reka bentuk visual tiada dalam keperluan, mengemas kini produk akan menjadi lebih cepat. Tugas kami ialah mencari elemen-elemen yang berurusan dengan operasi pada lutut, pinggul, belakang, tarik mereka keluar ke dalam dokumen yang berasingan dan katakan bahawa ini akan menjadi keperluan asas. Mari kita buat kumpulan terpencil keperluan tentang operasi lutut. Ini akan membolehkan kami membina set keperluan yang lebih stabil. Kami akan bercakap tentang keseluruhan barisan produk, dan bukan tentang robot tertentu.
Banyak kerja telah dilakukan, tetapi mereka masih sampai ke tempat di mana sebelum ini mereka menghabiskan berminggu-minggu dan berbulan-bulan ujian berulang tanpa makna atau keperluan, kerana keperluan mereka yang diterangkan di atas kertas tidak bertepatan dengan keperluan sebenar yang mana sistem itu dibina. FDA memberitahu mereka setiap kali: keperluan anda telah berubah, kini anda perlu menyemak semuanya dari awal. Semakan semula lengkap keseluruhan produk telah membunuh perusahaan.
Oleh itu, terdapat tugas yang menarik apabila anda mendapati diri anda pada permulaan sesuatu yang menarik, dan tindakan pertama menetapkan peraturan permainan selanjutnya. Jika anda memastikan bahawa aktiviti awal ini mula berfungsi dengan baik dari sudut pengurusan dan teknikal, ada kemungkinan anda akan mendapat projek yang hebat. Tetapi jika bahagian ini telah keluar dari landasan dan pergi ke suatu tempat yang salah, jika anda tidak dapat mencari perjanjian asas... tidak, bukan projek anda semestinya akan gagal. Tetapi anda tidak lagi dapat berkata: "Kami melakukan yang terbaik, kami melakukan segala-galanya dengan sangat berkesan." Ini adalah perkara yang saya lakukan semasa berkomunikasi dengan pelanggan.
Michael: Iaitu, anda melancarkan projek, melakukan beberapa jenis sepak mula dan periksa sama ada rel sedang menuju ke arah yang betul?
Tim: Kami juga mempunyai idea tentang cara menyatukan semua kepingan teka-teki: apakah kemahiran yang kami perlukan, bila betul-betul ia diperlukan, bagaimana rupa teras pasukan dan perkara asas yang lain. Adakah kita memerlukan pekerja sepenuh masa atau bolehkah kita mengupah seseorang secara sambilan? Perancangan, pengurusan. Soalan seperti: Apakah yang paling penting untuk projek tertentu ini? Bagaimana untuk mencapai ini? Apa yang kita tahu tentang produk atau projek ini, apakah risiko dan di mana perkara yang tidak diketahui itu terletak, bagaimana kita akan menangani semua ini? Sudah tentu, pada masa ini seseorang mula menjerit "Bagaimana dengan tangkas?!" Okay, anda semua fleksibel, tetapi bagaimana? Apakah sebenarnya rupa projek itu, bagaimana anda akan mengeluarkannya dengan cara yang sesuai dengan projek itu? Anda tidak boleh hanya mengatakan bahawa "pendekatan kami menjangkau apa sahaja, kami adalah pasukan Scrum!" Ini karut dan karut. Ke mana anda akan pergi seterusnya, mengapa ia harus berfungsi, di mana tujuannya? Saya mengajar pelanggan saya untuk memikirkan semua soalan ini.
19 tahun tangkas
Michael: Dalam Agile, orang sering cuba untuk tidak menentukan apa-apa terlebih dahulu, tetapi untuk membuat keputusan selewat mungkin, dengan berkata: kami terlalu besar, saya tidak akan memikirkan keseluruhan seni bina. Saya tidak akan memikirkan banyak perkara lain; sebaliknya, saya akan menyampaikan sesuatu yang berkesan kepada pelanggan sekarang.
Tim: Saya berpendapat bahawa metodologi tangkas, bermula dengan pada tahun 2001, membuka mata industri. Tetapi sebaliknya, tiada yang sempurna. Saya semua untuk pembangunan berulang. Lelaran sangat masuk akal dalam kebanyakan projek. Tetapi persoalan yang perlu anda fikirkan ialah: setelah produk keluar dan digunakan, berapa lama ia bertahan? Adakah ini produk yang akan bertahan enam bulan sebelum digantikan dengan yang lain? Atau adakah ini produk yang akan berfungsi selama bertahun-tahun? Sudah tentu, saya tidak akan menamakan nama, tetapi... Di New York dan komuniti kewangannya, sistem yang paling asas adalah sangat lama. Ini luar biasa. Anda melihat mereka dan berfikir, jika anda boleh kembali ke masa lalu, ke tahun 1994, dan memberitahu pemaju: "Saya datang dari masa depan, dari 2019. Hanya membangunkan sistem ini selama yang anda perlukan. Jadikan ia boleh dikembangkan, fikirkan tentang seni bina. Ia kemudiannya akan ditambah baik selama lebih daripada dua puluh lima tahun. Jika anda menangguhkan pembangunan sedikit lebih lama, dalam skema besar perkara tiada siapa yang akan perasan!” Apabila anda menganggarkan perkara dalam jangka panjang, anda perlu mempertimbangkan jumlah kos keseluruhannya. Kadang-kadang seni bina yang direka dengan baik sangat berbaloi, dan kadang-kadang tidak. Kita perlu melihat sekeliling dan bertanya kepada diri sendiri: adakah kita berada dalam situasi yang betul untuk keputusan sedemikian?
Jadi idea seperti "Kami untuk tangkas, pelanggan sendiri akan memberitahu kami apa yang dia mahu dapatkan" - ia sangat naif. Pelanggan tidak tahu apa yang mereka mahukan, dan lebih-lebih lagi mereka tidak tahu apa yang mereka boleh dapatkan. Sesetengah orang akan mula memetik contoh sejarah sebagai hujah, saya telah melihat ini. Tetapi orang yang maju dari segi teknikal biasanya tidak berkata demikian. Mereka berkata: "Ini tahun 2019, ini adalah peluang yang kami ada, dan kami boleh mengubah sepenuhnya cara kami melihat perkara ini!" Daripada meniru penyelesaian sedia ada, menjadikannya lebih cantik dan lebih cantik, kadangkala anda perlu keluar dan berkata: "Mari kita cipta semula sepenuhnya apa yang kita cuba lakukan di sini!"
Dan saya tidak fikir kebanyakan pelanggan boleh memikirkan masalah seperti itu. Mereka hanya melihat apa yang mereka sudah ada, itu sahaja. Selepas itu mereka datang dengan permintaan seperti "mari jadikan ini lebih mudah," atau apa sahaja yang biasa mereka katakan. Tetapi kami bukan pelayan atau pelayan, jadi kami boleh mengambil pesanan tidak kira betapa bodohnya ia ternyata dan kemudian membakarnya di dapur. Kami adalah pembimbing mereka. Kita perlu membuka mata mereka dan berkata: hei, kami mempunyai peluang baharu di sini! Adakah anda sedar bahawa kami benar-benar boleh mengubah cara bahagian perniagaan anda ini dilakukan? Salah satu masalah dengan Agile ialah ia menghilangkan kesedaran tentang apa itu peluang, apa itu masalah, apa yang perlu kita lakukan, apakah teknologi yang ada yang paling sesuai untuk situasi tertentu ini.
Mungkin saya terlalu skeptikal di sini: terdapat banyak perkara menarik berlaku dalam komuniti tangkas. Tetapi saya mempunyai masalah dengan fakta bahawa bukannya menentukan projek, orang mula muntah. Saya akan bertanya di sini - apa yang kita lakukan, bagaimana kita akan melakukannya? Dan entah bagaimana secara ajaib ia sentiasa ternyata bahawa pelanggan harus tahu lebih baik daripada sesiapa sahaja. Tetapi pelanggan tahu yang terbaik hanya apabila dia memilih daripada perkara yang telah dibina oleh seseorang. Jika saya ingin membeli kereta dan saya tahu saiz bajet keluarga saya, maka saya akan segera memilih kereta yang sesuai dengan gaya hidup saya. Di sini saya tahu segala-galanya lebih baik daripada sesiapa pun! Tetapi sila ambil perhatian bahawa seseorang telah membuat kereta itu. Saya tidak tahu cara mencipta kereta baru, saya bukan pakar. Apabila kami mencipta produk tersuai atau istimewa, suara pelanggan mesti diambil kira, tetapi ini bukan lagi satu-satunya suara.
Oleg: Anda menyebut Manifesto Agile. Adakah kita perlu mengemas kini atau menyemaknya dengan mengambil kira pemahaman moden tentang isu tersebut?
Tim: Saya tidak akan menyentuhnya. Saya fikir ia adalah dokumen sejarah yang hebat. Maksud saya, dia adalah apa adanya. Dia berusia 19 tahun, dia sudah tua, tetapi pada zamannya dia membuat revolusi. Apa yang dia lakukan dengan baik ialah dia mencetuskan reaksi dan orang ramai mula berbisik tentang dia. Anda, kemungkinan besar, belum bekerja dalam industri pada tahun 2001, tetapi kemudian semua orang bekerja mengikut proses. Institut Kejuruteraan Perisian, lima peringkat model kesempurnaan perisian (CMMI). Saya tidak tahu sama ada legenda kuno yang mendalam memberitahu anda sesuatu, tetapi kemudian ia adalah satu kejayaan. Pada mulanya, orang percaya bahawa jika proses itu disediakan dengan betul, maka masalah akan hilang dengan sendirinya. Dan kemudian Manifesto datang dan berkata: "Tidak, tidak, tidak - kami akan berdasarkan orang, bukan proses." Kami mahir dalam pembangunan perisian. Kami faham bahawa proses yang ideal adalah fatamorgana; ia tidak berlaku. Terdapat terlalu banyak keanehan dalam projek, idea satu proses yang sempurna untuk semua projek tidak masuk akal. Masalahnya terlalu kompleks untuk mendakwa bahawa hanya ada satu penyelesaian untuk segala-galanya (hello, nirwana).
Saya tidak menganggap untuk melihat masa depan, tetapi saya akan mengatakan bahawa orang kini telah mula memikirkan lebih lanjut tentang projek. Saya rasa Manifesto Agile sangat bagus untuk melompat keluar dan berkata, “Hei! Anda berada di atas kapal, dan anda sendiri memandu kapal ini. Anda perlu membuat keputusan - kami tidak akan mencadangkan resipi universal untuk semua keadaan. Anda adalah krew kapal, dan jika anda cukup baik, anda boleh mencari jalan ke matlamat. Terdapat kapal lain sebelum anda, dan akan ada kapal lain selepas anda, tetapi masih, dalam erti kata lain, perjalanan anda adalah unik. Sesuatu seperti itu! Ia satu cara berfikir. Bagi saya, tidak ada yang baru di bawah matahari, orang telah belayar sebelum ini dan akan belayar lagi, tetapi bagi anda ini adalah perjalanan utama anda, dan saya tidak akan memberitahu anda apa sebenarnya yang akan berlaku kepada anda. Anda mesti mempunyai kemahiran kerja yang diselaraskan dalam satu pasukan, dan jika anda benar-benar memilikinya, semuanya akan berjalan lancar dan anda akan mendapat tempat yang anda inginkan.
Peopleware: 30 tahun kemudian
Oleg: Adakah Peopleware merupakan revolusi dan juga Manifesto?
Tim: Peopleware... Tom dan saya menulis buku ini, tetapi kami tidak sangka ia akan berlaku seperti ini. Entah bagaimana ia bergema dengan banyak idea orang. Ini adalah buku pertama yang mengatakan: pembangunan perisian adalah aktiviti yang sangat intensif manusia. Walaupun sifat teknikal kami, kami juga merupakan komuniti orang yang membina sesuatu yang besar, malah besar, sangat kompleks. Tiada siapa yang boleh mencipta perkara sedemikian seorang diri, bukan? Jadi idea "pasukan" menjadi sangat penting. Dan bukan sahaja dari sudut pengurusan, tetapi juga untuk orang teknikal yang berkumpul untuk menyelesaikan masalah mendalam yang sangat kompleks dengan sekumpulan perkara yang tidak diketahui. Bagi saya secara peribadi, ini telah menjadi ujian besar kecerdasan sepanjang kerjaya saya. Dan di sini anda perlu boleh mengatakan: ya, masalah ini lebih daripada yang saya boleh tangani sendiri, tetapi bersama-sama kita boleh mencari penyelesaian yang elegan yang boleh kita banggakan. Dan saya rasa idea inilah yang paling bergema. Idea bahawa kita bekerja sebahagian daripada masa sendiri, sebahagian daripada masa sebagai sebahagian daripada kumpulan, dan selalunya keputusan dibuat oleh kumpulan. Penyelesaian masalah kumpulan telah menjadi ciri penting projek yang kompleks dengan cepat.
Walaupun fakta bahawa Tim telah memberikan sejumlah besar ceramah, sangat sedikit daripada mereka disiarkan di YouTube. Anda boleh melihat laporan "The Return of Peopleware" dari 2007. Kualiti, tentu saja, meninggalkan banyak yang diinginkan.
Michael: Adakah apa-apa yang berubah dalam tempoh 30 tahun yang lalu sejak buku itu diterbitkan?
Tim: Anda boleh melihat ini dari pelbagai sudut. Dari segi sosiologi... suatu ketika dahulu, dalam masa yang lebih mudah, anda dan pasukan anda duduk di pejabat yang sama. Anda boleh rapat setiap hari, minum kopi bersama-sama dan membincangkan kerja. Apa yang benar-benar berubah ialah pasukan kini boleh diedarkan secara geografi, di negara dan zon waktu yang berbeza, tetapi mereka masih mengusahakan masalah yang sama, dan ini menambah lapisan kerumitan yang baharu. Ini mungkin kedengaran lama, tetapi tiada apa-apa seperti komunikasi bersemuka di mana anda semua bersama-sama, bekerja bersama-sama, dan anda boleh berjalan ke rakan sekerja dan berkata, lihat apa yang saya temui, bagaimana anda menyukai ini? Perbualan bersemuka menyediakan cara pantas untuk beralih kepada komunikasi tidak formal, dan saya fikir peminat tangkas juga harus menyukainya. Dan saya juga bimbang kerana pada hakikatnya dunia telah menjadi sangat kecil, dan kini semuanya diliputi oleh pasukan yang diedarkan, dan semuanya sangat kompleks.
Kita semua tinggal di DevOps
Michael: Malah dari sudut pandangan jawatankuasa program persidangan, kita mempunyai orang di California, di New York, Eropah, Rusia ... belum ada sesiapa di Singapura. Perbezaan dalam geografi agak besar, dan orang ramai mula merebak dengan lebih banyak lagi. Jika kita bercakap tentang pembangunan, bolehkah anda memberitahu kami lebih lanjut tentang devops dan memecahkan halangan antara pasukan? Terdapat konsep bahawa semua orang duduk di kubu mereka, dan kini kubu itu runtuh, apa pendapat anda tentang analogi ini?
Tim: Nampaknya saya memandangkan penemuan teknologi baru-baru ini, devops adalah sangat penting. Sebelum ini, anda mempunyai pasukan pembangun dan pentadbir, mereka bekerja, bekerja, bekerja, dan pada satu ketika sesuatu muncul yang anda boleh datang kepada pentadbir dan melancarkannya untuk pengeluaran. Dan di sini perbualan tentang bunker bermula, kerana pentadbir adalah sejenis sekutu, bukan musuh, sekurang-kurangnya, tetapi anda bercakap dengan mereka hanya apabila semuanya sudah bersedia untuk pergi ke produksi. Adakah anda pergi kepada mereka dengan sesuatu dan berkata: lihat apakah aplikasi yang kami ada, tetapi bolehkah anda melancarkan aplikasi ini? Dan kini keseluruhan konsep penyampaian telah berubah menjadi lebih baik. Maksud saya, terdapat idea bahawa anda boleh meneruskan perubahan dengan cepat. Kami boleh mengemas kini produk dengan cepat. Saya sentiasa tersenyum apabila Firefox pada komputer riba saya muncul dan berkata, hey, kami telah mengemas kini Firefox anda di latar belakang, dan sebaik sahaja anda mempunyai masa seminit, bolehkah anda mengklik di sini dan kami akan memberikan anda keluaran terkini. Dan saya seperti, "Oh ya, sayang!" Semasa saya tidur, mereka sedang berusaha untuk menyampaikan keluaran baharu kepada saya terus pada komputer saya. Ini hebat, luar biasa.
Tetapi inilah kesukarannya: anda mempunyai ciri ini dengan mengemas kini perisian, tetapi menyepadukan orang adalah lebih sukar. Apa yang saya ingin suarakan pada ucaptama DevOops ialah kami kini mempunyai lebih ramai pemain berbanding yang pernah kami miliki. Jika anda hanya memikirkan semua orang yang terlibat dalam satu pasukan sahaja…. Anda menganggapnya sebagai satu pasukan, dan ia lebih daripada sekadar pasukan pengaturcara. Ini adalah penguji, pengurus projek dan sekumpulan orang lain. Dan setiap orang mempunyai pandangan mereka sendiri tentang dunia. Pengurus produk berbeza sama sekali daripada pengurus projek. Admin ada tugasan sendiri. Ia menjadi masalah yang agak sukar untuk menyelaraskan semua peserta supaya terus menyedari apa yang berlaku dan tidak menjadi gila. Adalah perlu untuk mengasingkan tugas kumpulan dan tugas yang dikenakan kepada semua orang. Ini adalah tugas yang sangat sukar. Sebaliknya, saya rasa semuanya jauh lebih baik daripada beberapa tahun yang lalu. Ini betul-betul jalan di mana orang berkembang dan belajar untuk berkelakuan dengan betul. Apabila anda melakukan penyepaduan, anda faham bahawa tidak sepatutnya ada pembangunan bawah tanah, supaya pada saat terakhir perisian itu tidak merangkak keluar seperti jack-in-the-box: seperti, lihat apa yang kami lakukan di sini! Ideanya ialah anda akan dapat melakukan penyepaduan dan pembangunan, dan pada akhirnya anda akan melancarkan dengan cara yang kemas dan berulang. Semua ini amat bermakna bagi saya. Ini memungkinkan untuk mencipta lebih banyak nilai untuk pengguna sistem dan untuk pelanggan anda.
Michael: Keseluruhan idea devops adalah untuk menyampaikan perkembangan yang bermakna seawal mungkin. Saya melihat bahawa dunia telah mula mempercepatkan lebih dan lebih. Bagaimana untuk menyesuaikan diri dengan pecutan sedemikian? Sepuluh tahun yang lalu ini tidak wujud!
Tim: Sudah tentu, semua orang mahukan lebih banyak fungsi. Tidak perlu bergerak, tumpukan lebih banyak lagi. Kadangkala anda juga perlu memperlahankan untuk kemas kini tambahan seterusnya untuk membawa apa-apa yang berguna - dan itu adalah perkara biasa.
Idea bahawa anda perlu berlari, berlari, berlari bukanlah yang terbaik. Tidak mungkin sesiapa mahu menjalani kehidupan mereka seperti itu. Saya ingin irama penghantaran untuk menetapkan rentak projek itu sendiri. Jika anda hanya menghasilkan aliran perkara kecil yang tidak bermakna, semuanya tidak bermakna. Daripada cuba melepaskan perkara seawal mungkin secara tidak sengaja, perkara yang patut dibincangkan dengan pembangun utama dan pengurus produk dan projek ialah strategi. Adakah ini masuk akal?
Corak dan anticorak
Oleg: Anda biasanya bercakap tentang corak dan antipattern, dan ini adalah perbezaan antara kehidupan dan kematian projek. Dan sekarang, devops menerpa ke dalam hidup kita. Adakah ia mempunyai corak dan anti-corak sendiri yang boleh membunuh projek itu di tempat kejadian?
Tim: Corak dan anti-corak berlaku sepanjang masa. Sesuatu untuk dibincangkan. Nah, ada perkara ini yang kami panggil "perkara berkilat." Orang ramai sangat menyukai teknologi baru. Mereka hanya terpukau dengan kilauan segala yang kelihatan keren dan bergaya, dan mereka berhenti bertanya soalan: adakah ia perlu? Apa yang akan kita capai? Adakah perkara ini boleh dipercayai, adakah ia masuk akal? Saya sering melihat orang, kononnya, pada teknologi canggih. Mereka dipukau dengan apa yang berlaku di dunia. Tetapi jika anda melihat lebih dekat apa perkara berguna yang mereka lakukan, selalunya tiada apa-apa yang berguna!
Kami hanya berbincang dengan rakan-rakan kami bahawa tahun ini adalah tahun ulang tahun, lima puluh tahun sejak orang mendarat di bulan. Ini adalah pada tahun 1969. Teknologi yang membantu orang ramai sampai ke sana bukanlah teknologi 1969, tetapi 1960 atau 62, kerana NASA mahu menggunakan hanya apa yang mempunyai bukti kebolehpercayaan yang baik. Jadi anda melihatnya dan faham - ya, dan ia adalah benar! Sekarang, tidak, tidak, tetapi anda menghadapi masalah dengan teknologi hanya kerana segala-galanya ditolak terlalu keras, dijual dari semua retakan. Orang ramai menjerit dari mana-mana: "Lihat, apa yang berlaku, ini adalah perkara terbaru, perkara yang paling indah di dunia, sesuai untuk semua orang!" Baiklah, itu sahaja... selalunya semua ini menjadi tipu daya, dan kemudian semuanya perlu dibuang. Mungkin ini semua kerana saya sudah tua dan melihat perkara sedemikian dengan penuh keraguan, apabila orang kehabisan dan mengatakan bahawa mereka telah menemui Satu-satunya Cara Paling Betul untuk Mencipta Teknologi Terbaik. Pada masa ini, satu suara terbangun di dalam diri saya yang berkata: "Kekacauan!"
Michael: Sesungguhnya, berapa kerap kita telah mendengar tentang peluru perak seterusnya?
Tim: Betul, dan ini adalah perkara biasa! Sebagai contoh... nampaknya ini sudah menjadi bahan jenaka di seluruh dunia, tetapi di sini orang sering bercakap tentang teknologi blockchain. Dan mereka sebenarnya masuk akal dalam situasi tertentu! Apabila anda benar-benar memerlukan bukti yang boleh dipercayai tentang peristiwa, bahawa sistem berfungsi dan tiada siapa yang menipu kami, apabila anda menghadapi masalah keselamatan dan semua perkara itu bercampur-campur - blockchain masuk akal. Tetapi apabila mereka mengatakan bahawa Blockchain kini akan menyapu seluruh dunia, menyapu bersih segala-galanya dalam laluannya? Bermimpi lagi! Ini adalah teknologi yang sangat mahal dan kompleks. Secara teknikalnya kompleks dan memakan masa. Termasuk secara algoritma semata-mata, setiap kali anda perlu mengira semula matematik, dengan sedikit perubahan... dan ini adalah idea yang bagus - tetapi hanya untuk kes tertentu. Seluruh hidup dan kerjaya saya adalah mengenai perkara ini: idea yang menarik dalam situasi yang sangat spesifik. Adalah sangat penting untuk memahami dengan tepat keadaan anda.
Michael: Ya, "persoalan kehidupan, alam semesta dan segala-galanya" utama: adakah teknologi atau pendekatan ini sesuai untuk situasi anda atau tidak?
Tim: Soalan ini sudah boleh dibincangkan dengan kumpulan teknologi. Mungkin juga membawa beberapa perunding. Lihat projek itu dan faham - adakah kita kini akan melakukan sesuatu yang betul dan berguna, lebih baik daripada sebelumnya? Mungkin ia sesuai, mungkin tidak. Tetapi yang paling penting, jangan membuat keputusan sedemikian secara lalai, semata-mata kerana seseorang berkata: “Kami sangat memerlukan blockchain! Saya baru sahaja membaca tentang dia dalam majalah di dalam pesawat!” Serius? Bukan kelakar pun.
"jurutera devops" mitos
Oleg: Sekarang semua orang sedang melaksanakan devops. Seseorang membaca tentang devops di Internet, dan esok kekosongan lain muncul di tapak pengambilan. "jurutera devops". Di sini saya ingin menarik perhatian anda: adakah anda fikir istilah ini, "devops engineer," mempunyai hak untuk hidup? Terdapat pendapat bahawa devops adalah budaya, dan ada sesuatu yang tidak sesuai di sini.
Tim: begitu-begitu. Biarkan mereka segera memberikan penjelasan tentang istilah ini. Sesuatu untuk menjadikannya unik. Sehingga mereka membuktikan bahawa terdapat beberapa kombinasi unik kemahiran di sebalik kekosongan seperti ini, saya tidak akan membelinya! Maksud saya, kita ada jawatan, "devops engineer," tajuk yang menarik, ya, apa seterusnya? Tajuk pekerjaan secara amnya adalah perkara yang sangat menarik. Katakan "pembangun" - apakah itu? Organisasi yang berbeza bermakna perkara yang sama sekali berbeza. Di sesetengah syarikat, pengaturcara berkualiti tinggi menulis ujian yang lebih masuk akal daripada ujian yang ditulis oleh penguji profesional khas di syarikat lain. Jadi apa, adakah mereka kini pengaturcara atau penguji?
Ya, kami mempunyai jawatan, tetapi jika anda bertanya soalan cukup lama, akhirnya ternyata kami semua adalah penyelesai masalah. Kami adalah pencari penyelesaian, dan ada yang mempunyai beberapa kemahiran teknikal dan ada yang mempunyai kemahiran yang berbeza. Jika anda tinggal dalam persekitaran di mana DevOps telah menembusi, anda terlibat dalam penyepaduan pembangunan dan pentadbiran, dan aktiviti ini mempunyai beberapa tujuan yang agak penting. Tetapi jika anda ditanya apa sebenarnya yang anda lakukan dan apa yang anda bertanggungjawab, ternyata orang telah melakukan semua perkara ini sejak dahulu lagi. "Saya bertanggungjawab untuk seni bina", "Saya bertanggungjawab untuk pangkalan data" dan sebagainya, apa sahaja, anda lihat - semua ini sebelum "devops".
Apabila seseorang memberitahu saya jawatan mereka, saya tidak begitu mendengar. Adalah lebih baik untuk membiarkan dia memberitahu anda perkara yang sebenarnya dia bertanggungjawab, ini akan membolehkan kami memahami isu ini dengan lebih baik. Contoh kegemaran saya ialah apabila seseorang mendakwa sebagai "pengurus projek". Apa? Ia tidak bermakna apa-apa, saya masih tidak tahu apa yang anda lakukan. Seorang pengurus projek boleh menjadi pembangun, ketua pasukan yang terdiri daripada empat orang, menulis kod, melakukan kerja, yang telah menjadi ketua pasukan, yang orang sendiri mengenali antara mereka sebagai pemimpin. Dan juga, pengurus projek boleh menjadi pengurus yang menguruskan enam ratus orang dalam projek, mengurus pengurus lain, bertanggungjawab untuk merangka jadual dan merancang belanjawan, itu sahaja. Ini adalah dua dunia yang sama sekali berbeza! Tetapi tajuk kerja mereka bunyinya sama.
Mari kita ubah ini sedikit berbeza. Apa yang anda benar-benar mahir, mempunyai banyak pengalaman, adakah anda mempunyai bakat? Apa yang anda akan bertanggungjawab kerana anda fikir anda boleh mengendalikan tugas itu? Dan di sini seseorang akan mula menafikan dengan serta-merta: tidak, tidak, tidak, saya tidak mempunyai keinginan untuk berurusan dengan sumber projek sama sekali, ini bukan perniagaan saya, saya seorang lelaki teknikal dan saya memahami kebolehgunaan dan antara muka pengguna, saya tidak mahu menguruskan tentera orang sama sekali, biarkan saya pergi bekerja lebih baik.
Lagipun, saya penyokong besar pendekatan di mana pemisahan kemahiran seperti ini berfungsi dengan baik. Di mana juruteknik boleh mengembangkan kerjaya mereka sejauh yang mereka mahu. Walau bagaimanapun, saya masih melihat organisasi di mana juruteknik mengadu: Saya perlu pergi ke pengurusan projek kerana itulah satu-satunya cara dalam syarikat ini. Kadang-kadang ini membawa kepada hasil yang mengerikan. Juruteknik terbaik bukanlah pengurus yang baik sama sekali, dan pengurus terbaik tidak dapat mengendalikan teknologi. Mari kita jujur tentang ini.
Saya melihat banyak permintaan untuk ini sekarang. Jika anda seorang juruteknik, syarikat anda boleh membantu anda, tetapi tidak kira, anda perlu, benar-benar perlu mencari laluan kerjaya anda sendiri kerana teknologi sentiasa berubah dan anda perlu mencipta semula diri anda dengannya! Dalam masa dua puluh tahun sahaja, teknologi boleh berubah sekurang-kurangnya lima kali. Teknologi adalah sesuatu yang pelik...
"Pakar dalam Segala-galanya"
Michael: Bagaimanakah orang boleh menghadapi perubahan teknologi yang begitu pantas? Kerumitan mereka semakin meningkat, bilangan mereka semakin meningkat, jumlah komunikasi antara orang juga semakin meningkat, dan ternyata anda tidak boleh menjadi "pakar dalam segala-galanya."
Tim: Betul! Jika anda bekerja dalam teknologi, ya, anda pasti perlu memilih sesuatu yang khusus dan mendalaminya. Sesetengah teknologi yang organisasi anda dapati berguna (dan mungkin sebenarnya berguna). Dan jika anda tidak lagi berminat dengannya - saya tidak akan pernah percaya bahawa saya akan mengatakan ini - baik, mungkin anda perlu berpindah ke beberapa organisasi lain di mana teknologinya lebih menarik atau lebih mudah untuk dipelajari.
Tetapi secara umum, ya, anda betul. Teknologi berkembang dalam semua arah sekaligus; tiada siapa yang boleh berkata "Saya pakar teknologi dalam semua teknologi yang wujud." Sebaliknya, terdapat orang span yang benar-benar menyerap pengetahuan teknologi dan gila mengenainya. Saya telah melihat beberapa orang seperti itu, mereka benar-benar bernafas dan menjalaninya, ia berguna dan menarik untuk bercakap dengan mereka. Mereka mengkaji bukan sahaja apa yang berlaku di dalam organisasi, tetapi secara umum, mereka bercakap mengenainya, mereka juga ahli teknologi yang sangat keren, mereka sangat sedar dan bertujuan. Mereka hanya cuba untuk kekal di puncak gelombang, tanpa mengira apa tugas utama mereka, kerana minat mereka adalah pergerakan Teknologi, promosi teknologi. Sekiranya anda tiba-tiba bertemu dengan orang seperti itu, anda harus pergi makan tengah hari dengannya dan membincangkan pelbagai perkara menarik semasa makan tengah hari. Saya fikir mana-mana organisasi memerlukan sekurang-kurangnya beberapa orang seperti itu.
Risiko dan ketidakpastian
Michael: Jurutera yang dihormati, ya. Jom sentuh pengurusan risiko sementara ada masa. Kami memulakan temu bual ini dengan perbincangan mengenai perisian perubatan, di mana kesilapan boleh membawa kepada akibat yang teruk. Kemudian kami bercakap tentang Program Lunar, di mana kos kesilapan adalah berjuta-juta dolar, dan mungkin beberapa nyawa manusia. Tetapi sekarang saya melihat pergerakan yang bertentangan dalam industri, orang tidak memikirkan risiko, tidak cuba meramalkannya, tidak memerhatikannya.
Oleg: Bergerak cepat dan pecahkan barang!
Michael: Ya, bergerak cepat, memecahkan perkara, lebih banyak perkara, sehingga anda mati kerana sesuatu. Dari sudut pandangan anda, bagaimanakah purata pembangun harus mendekati pengurusan risiko pembelajaran sekarang?
Tim: Mari kita gariskan di sini antara dua perkara: risiko dan ketidakpastian. Ini adalah perkara yang berbeza. Ketidakpastian berlaku apabila anda tidak mempunyai data yang mencukupi pada bila-bila masa tertentu untuk mendapatkan jawapan yang pasti. Sebagai contoh, pada peringkat awal projek, jika seseorang bertanya kepada anda "bila anda akan menyelesaikan kerja", jika anda seorang yang jujur, anda akan berkata, "Saya tidak tahu." Anda hanya tidak tahu, dan tidak mengapa. Anda belum lagi mengkaji masalah dan tidak biasa dengan pasukan, anda tidak tahu kemahiran mereka, dan sebagainya. Ini adalah ketidakpastian.
Risiko timbul apabila masalah yang berpotensi sudah dapat dikenal pasti. Perkara seperti ini boleh berlaku, kebarangkaliannya lebih besar daripada sifar, tetapi kurang daripada seratus peratus, di suatu tempat di antaranya. Disebabkan itu, apa sahaja boleh berlaku, daripada kelewatan dan kerja yang tidak perlu, malah kepada hasil yang membawa maut untuk projek itu. Hasilnya, apabila anda berkata - kawan-kawan, mari kita lipat payung kita dan tinggalkan pantai, kita tidak akan pernah menyelesaikannya, semuanya sudah berakhir, titik. Kami membuat andaian bahawa perkara ini akan berfungsi, tetapi ia tidak berfungsi sama sekali, sudah tiba masanya untuk berhenti. Ini adalah situasi.
Selalunya, masalah paling mudah untuk diselesaikan apabila ia telah muncul, apabila masalah itu berlaku sekarang. Tetapi apabila masalah berada di hadapan anda, anda tidak melakukan pengurusan risiko—anda sedang melakukan penyelesaian masalah, pengurusan krisis. Jika anda seorang pembangun atau pengurus utama, anda mesti tertanya-tanya apa yang boleh berlaku yang boleh menyebabkan kelewatan, masa terbuang, kos yang tidak perlu atau keruntuhan keseluruhan projek? Apa yang akan membuatkan kita berhenti dan mula semula? Apabila semua perkara ini berjaya, apa yang akan kita lakukan dengannya? Terdapat jawapan mudah yang sah untuk kebanyakan situasi: jangan lari daripada risiko, lakukannya. Lihat bagaimana anda boleh menyelesaikan situasi berisiko, mengurangkannya kepada tiada, mengubahnya daripada masalah kepada sesuatu yang lain. Daripada berkata: baik, kami akan menyelesaikan masalah apabila ia timbul.
Ketidakpastian dan risiko harus berada di barisan hadapan dalam semua perkara yang anda hadapi. Anda boleh mengambil rancangan projek, melihat risiko kritikal tertentu lebih awal daripada masa dan berkata: kita perlu menangani perkara ini sekarang, kerana jika mana-mana perkara ini salah, tiada perkara lain yang penting. Anda tidak perlu risau tentang keindahan alas meja di atas meja jika tidak jelas sama ada anda boleh memasak makan malam. Mula-mula anda perlu mengenal pasti semua risiko menyediakan makan malam yang lazat, berurusan dengan mereka, dan kemudian fikirkan semua perkara lain yang tidak menimbulkan ancaman sebenar.
Sekali lagi, apakah yang menjadikan projek anda unik? Mari lihat apa yang boleh menyebabkan projek kami terkeluar dari landasan. Apakah yang boleh kita lakukan untuk meminimumkan kemungkinan ini berlaku? Biasanya anda tidak boleh hanya meneutralkan mereka 100% dan mengisytiharkan dengan hati nurani yang bersih: "Itu sahaja, ini bukan lagi masalah, risiko telah diselesaikan!" Bagi saya ini adalah tanda tingkah laku orang dewasa. Ini adalah perbezaan antara kanak-kanak dan orang dewasa - kanak-kanak berfikir bahawa mereka adalah abadi, tiada apa yang boleh berlaku, semuanya akan baik-baik saja! Pada masa yang sama, orang dewasa melihat bagaimana kanak-kanak berusia tiga tahun melompat di taman permainan, mengikuti pergerakan dengan mata mereka dan berkata kepada diri mereka sendiri: "ooh-ooh, ooh-ooh." Saya berdiri berhampiran dan bersedia untuk menangkap apabila kanak-kanak itu jatuh.
Sebaliknya, sebab saya sangat menyukai perniagaan ini adalah kerana ia berisiko. Kami melakukan sesuatu, dan perkara itu berisiko. Mereka memerlukan pendekatan dewasa. Semangat sahaja tidak akan menyelesaikan masalah anda!
Pemikiran kejuruteraan dewasa
Michael: Contoh dengan kanak-kanak adalah baik. Jika saya seorang jurutera biasa, maka saya gembira menjadi seorang kanak-kanak. Tetapi bagaimana anda bergerak ke arah pemikiran yang lebih dewasa?
Tim: Salah satu idea yang berfungsi sama baik dengan sama ada pemula atau pembangun yang mapan ialah konsep konteks. Apa yang kita lakukan, apa yang akan kita capai. Apakah yang penting dalam projek ini? Tidak kira siapa anda dalam projek ini, sama ada anda seorang pelatih atau ketua arkitek, semua orang memerlukan konteks. Kita perlu membuat semua orang berfikir pada skala yang lebih besar daripada karya mereka sendiri. "Saya membuat karya saya, dan selagi karya saya berfungsi, saya gembira." Tidak dan tidak lagi. Ia sentiasa berbaloi (tanpa bersikap kasar!) untuk mengingatkan orang ramai tentang konteks tempat mereka bekerja. Apa yang kita semua cuba capai bersama. Idea bahawa anda boleh menjadi kanak-kanak selagi semuanya baik-baik saja dengan bahagian projek anda - tolong, jangan lakukan itu. Jika kita melepasi garisan penamat sama sekali, kita hanya akan menyeberanginya bersama-sama. Anda tidak keseorangan, kami semua bersama. Jika semua orang dalam projek itu, baik tua dan muda, mula bercakap tentang apa sebenarnya yang penting untuk projek itu, mengapa syarikat melabur wang dalam apa yang kita semua cuba capai... kebanyakan mereka akan berasa lebih baik kerana mereka akan melihat bagaimana kerja mereka berkorelasi dengan kerja orang lain. Di satu pihak, saya memahami bahagian yang saya bertanggungjawab secara peribadi. Tetapi untuk menyelesaikan kerja kita memerlukan semua orang lain juga. Dan jika anda benar-benar rasa anda sudah selesai, kami sentiasa mempunyai kerja untuk dilakukan dalam projek itu!
Oleg: Secara relatifnya, jika anda bekerja mengikut Kanban, apabila anda menghadapi kesesakan beberapa ujian, anda boleh berhenti daripada apa yang anda lakukan di sana (contohnya, pengaturcaraan) dan pergi membantu penguji.
Tim: Tepat sekali. Saya fikir juruteknik terbaik, jika anda melihat dengan teliti, mereka adalah pengurus mereka sendiri. Bagaimana saya boleh merumuskan ini...
Oleg: Hidup anda adalah projek anda, yang anda uruskan.
Tim: Tepat sekali! Maksud saya, anda bertanggungjawab, anda memahami isu itu, dan anda berhubung dengan orang apabila anda melihat bahawa keputusan anda boleh menjejaskan kerja mereka, perkara seperti itu. Ia bukan tentang hanya duduk di meja anda, melakukan kerja anda, dan tidak menyedari apa yang berlaku di sekeliling anda. Tidak tidak tidak. Ngomong-ngomong, salah satu perkara terbaik tentang Agile ialah mereka mencadangkan pecut pendek, kerana dengan cara ini keadaan semua peserta dapat dilihat dengan jelas, mereka dapat melihat semuanya bersama-sama. Kami bercakap tentang satu sama lain setiap hari.
Bagaimana untuk masuk ke dalam pengurusan risiko
Oleg: Adakah terdapat struktur pengetahuan formal dalam bidang ini? Sebagai contoh, saya seorang pembangun Java dan ingin memahami pengurusan risiko tanpa menjadi pengurus projek sebenar melalui pendidikan. Saya mungkin akan membaca "Berapa Kos Projek Perisian" McConnell dahulu, dan kemudian apa? Apakah langkah pertama?
Tim: Yang pertama adalah untuk mula berkomunikasi dengan orang dalam projek. Ini memberikan peningkatan segera dalam budaya komunikasi dengan rakan sekerja. Kita perlu bermula dengan membuka semuanya secara lalai, bukannya menyembunyikannya. Katakanlah: ini adalah perkara yang mengganggu saya, ini adalah perkara yang membuat saya terjaga pada waktu malam, saya bangun pada waktu malam hari ini dan seperti: Tuhanku, saya perlu memikirkan perkara ini! Adakah orang lain melihat perkara yang sama? Sebagai satu kumpulan, patutkah kita bertindak balas terhadap masalah yang berpotensi ini? Anda perlu dapat menyokong perbincangan mengenai topik ini. Tiada formula yang disediakan terlebih dahulu untuk kami bekerja. Ini bukan tentang membuat hamburger, ini semua tentang orang. "Membuat burger keju, menjual burger keju" bukanlah perkara kami sama sekali, dan itulah sebabnya saya sangat menyukai pekerjaan ini. Saya suka apabila semua yang pengurus lakukan dahulu kini menjadi hak milik pasukan.
Oleg: Anda telah bercakap dalam buku dan temu bual tentang cara orang lebih mementingkan kebahagiaan daripada nombor pada graf. Sebaliknya, apabila anda memberitahu pasukan: kami berpindah ke devops, dan kini pengaturcara mesti sentiasa berkomunikasi, ini mungkin jauh di luar zon selesanya. Dan pada masa ini dia mungkin, katakan, sangat tidak berpuas hati. Apa yang perlu dilakukan dalam keadaan ini?
Tim: Saya tidak pasti apa yang perlu dilakukan. Jika pembangun terlalu terpencil, mereka tidak nampak mengapa kerja itu dilakukan pada mulanya, mereka hanya melihat bahagian kerja mereka, dan mereka perlu masuk ke dalam apa yang saya panggil "konteks." Dia perlu memikirkan bagaimana segala-galanya disambungkan bersama. Dan sudah tentu, saya tidak bermaksud pembentangan rasmi atau apa-apa seperti itu. Saya bercakap tentang hakikat bahawa anda perlu berkomunikasi dengan rakan sekerja tentang kerja secara keseluruhan, dan bukan hanya tentang bahagian kerja yang anda bertanggungjawab. Di sinilah anda boleh mula membincangkan idea, perjanjian bersama untuk menjadikan kerja anda sesuai bersama dengan baik, dan cara menangani masalah biasa bersama-sama.
Untuk membantu mereka menyesuaikan diri, mereka sering mahu menghantar juruteknik ke latihan, dan mereka membincangkan latihan. Seorang kawan saya suka mengatakan bahawa latihan adalah untuk anjing. Ada latihan untuk orang. Salah satu perkara terbaik tentang pembelajaran sebagai pembangun ialah berinteraksi dengan rakan sebaya anda. Jika seseorang benar-benar mahir dalam sesuatu, anda harus melihat mereka bekerja atau bercakap dengan mereka tentang kerja mereka atau sesuatu. Beberapa Kent Beck konvensional sentiasa bercakap tentang pengaturcaraan yang melampau. Ia lucu kerana XP adalah idea yang mudah, tetapi ia menyebabkan banyak masalah. Bagi sesetengah orang, melakukan XP adalah seperti dipaksa untuk berbogel di hadapan rakan-rakan. Mereka akan melihat apa yang saya lakukan! Mereka adalah rakan sekerja saya, mereka bukan sahaja akan melihat, tetapi juga memahami! Dahsyat! Sesetengah orang mula menjadi sangat gementar. Tetapi apabila anda menyedari bahawa ini adalah cara terbaik untuk belajar, semuanya berubah. Anda bekerja rapat dengan orang lain, dan sesetengah orang memahami topik itu lebih baik daripada anda.
Michael: Tetapi semua ini memaksa anda untuk keluar dari zon selesa anda. Sebagai seorang jurutera, anda perlu keluar dari zon selesa anda dan berkomunikasi. Sebagai penyelesai masalah, anda perlu sentiasa meletakkan diri anda dalam kedudukan yang lemah dan berfikir tentang apa yang boleh berlaku. Jenis kerja ini sememangnya direka bentuk untuk menjadi gangguan. Anda secara sedar meletakkan diri anda dalam situasi yang tertekan. Selalunya orang lari dari mereka, orang suka jadi anak riang.
Tim: Apa yang boleh dilakukan, anda boleh keluar dan secara terbuka berkata: “Semuanya baik-baik saja, saya boleh mengatasinya! Bukan saya seorang sahaja yang berasa tidak selesa. Mari kita bincangkan pelbagai perkara yang tidak selesa, bersama-sama, sebagai satu pasukan!” Ini adalah masalah biasa kita, kita mesti menanganinya, anda tahu? Saya fikir pemaju genius yang unik adalah seperti mamot, mereka hilang. Dan kepentingan mereka sangat terhad. Jika anda tidak boleh berkomunikasi, anda tidak boleh mengambil bahagian dengan baik. Oleh itu, bercakap sahaja. Jujur dan terbuka. Saya sangat menyesal bahawa ini tidak menyenangkan bagi seseorang. Bolehkah anda bayangkan, bertahun-tahun yang lalu terdapat satu kajian yang menurutnya ketakutan utama di Amerika Syarikat bukanlah kematian, tetapi rasa apa? Takut bercakap awam! Ini bermakna di suatu tempat ada orang yang lebih suka mati daripada mengucapkan pujian dengan kuat. Dan saya rasa cukup untuk anda mempunyai beberapa kemahiran asas, bergantung pada apa yang anda lakukan. Kemahiran bercakap, kemahiran menulis - tetapi hanya sebanyak yang benar-benar diperlukan dalam kerja anda. Jika anda bekerja sebagai penganalisis, tetapi tidak boleh membaca, menulis atau bercakap, maka, malangnya, anda tidak akan ada kaitan dalam projek saya!
Harga komunikasi
Oleg: Bukankah menggaji pekerja yang keluar seperti itu lebih mahal atas pelbagai sebab? Lagipun, mereka sentiasa bersembang dan bukannya bekerja!
Tim: Saya maksudkan teras pasukan, dan bukan hanya semua orang. Jika anda mempunyai seseorang yang benar-benar hebat dalam menala pangkalan data, suka menala pangkalan data, dan akan terus menala pangkalan data anda sepanjang hayatnya dan itu sahaja, hebat, teruskan. Tetapi saya bercakap tentang orang yang ingin hidup dalam projek itu sendiri. Teras pasukan, bertujuan untuk membangunkan projek. Mereka ini benar-benar perlu sentiasa berkomunikasi antara satu sama lain. Dan terutamanya pada permulaan projek, apabila anda membincangkan risiko, cara untuk mencapai matlamat global dan sebagainya.
Michael: Ini terpakai kepada semua orang yang terlibat dalam projek, tanpa mengira pengkhususan, kemahiran atau cara bekerja. Anda semua berminat dengan kejayaan projek tersebut.
Tim: Ya, anda merasakan bahawa anda cukup terlibat dalam projek itu, bahawa tugas anda adalah untuk membantu projek itu menjadi kenyataan. Sama ada anda seorang pengaturcara, penganalisis, pereka bentuk antara muka, sesiapa sahaja. Inilah sebab saya datang bekerja setiap pagi dan inilah yang kami lakukan. Kami bertanggungjawab untuk semua orang ini, tanpa mengira kemahiran mereka. Ini adalah sekumpulan orang yang mempunyai perbualan dewasa.
Oleg: Malah, bercakap tentang pekerja yang suka bercakap, saya cuba meniru bantahan orang, terutamanya pengurus, yang diminta untuk beralih kepada devops, kepada wawasan dunia yang baru ini. Dan anda, sebagai perunding, harus sedar tentang bantahan ini lebih baik daripada saya, sebagai pemaju! Kongsi apa yang paling membimbangkan pengurus?
Tim: Pengurus? Hm. Selalunya, pengurus berada di bawah tekanan daripada masalah, berhadapan dengan keperluan untuk segera melepaskan sesuatu dan membuat penghantaran, dan sebagainya. Mereka melihat bagaimana kita sentiasa berbincang dan berhujah tentang sesuatu, dan mereka melihatnya seperti ini: perbualan, perbualan, perbualan... Apakah perbualan lain? Kembali bekerja! Kerana bercakap tidak terasa seperti bekerja kepada mereka. Anda tidak menulis kod, tidak menguji perisian, nampaknya tidak melakukan apa-apa - mengapa tidak menghantar anda melakukan sesuatu? Lagipun, penghantaran pun dah masuk sebulan!
Michael: Pergi tulis beberapa kod!
Tim: Ia seolah-olah saya bahawa mereka tidak bimbang tentang kerja, tetapi tentang kekurangan penglihatan kemajuan. Untuk menjadikannya kelihatan seperti kita semakin hampir kepada kejayaan, mereka perlu melihat kita menekan butang pada papan kekunci. Sepanjang hari dari pagi hingga petang. Ini masalah nombor satu.
Oleg: Misha, awak sedang memikirkan sesuatu.
Michael: Maaf, saya tersesat dan teringat semula. Semua ini mengingatkan saya tentang perhimpunan menarik yang berlaku semalam... Terdapat terlalu banyak perhimpunan semalam... Dan semuanya kedengaran sangat biasa!
Hidup tanpa gaji
Tim: Dengan cara ini, sama sekali tidak perlu untuk menganjurkan "perhimpunan" untuk komunikasi. Maksud saya, perbincangan yang paling berguna antara pembangun berlaku apabila mereka hanya bercakap antara satu sama lain. Anda berjalan masuk pada waktu pagi dengan secawan kopi, dan terdapat lima orang berkumpul dan berang membincangkan sesuatu yang teknikal. Bagi saya, jika saya pengurus projek ini, lebih baik senyum sahaja dan pergi ke suatu tempat tentang perniagaan saya, biarkan mereka membincangkannya. Mereka sudah terlibat sebanyak mungkin. Ini adalah petanda yang baik.
Oleg: Ngomong-ngomong, dalam buku anda, anda mempunyai banyak nota tentang apa yang baik dan apa yang buruk. Adakah anda menggunakan mana-mana daripada mereka sendiri? Secara relatifnya, kini anda mempunyai sebuah syarikat, dan syarikat yang berstruktur dengan cara yang sangat tidak lazim...
Tim: Tidak lazim, tetapi peranti ini sangat sesuai dengan kami. Kami sudah lama mengenali antara satu sama lain. Kami percaya antara satu sama lain, kami sangat mempercayai satu sama lain sebelum kami menjadi pasangan. Dan sebagai contoh, kami tidak mempunyai gaji langsung. Kami hanya bekerja, dan sebagai contoh, jika saya memperoleh wang daripada pelanggan saya, maka semua wang itu pergi kepada saya. Selepas itu, kami membayar yuran keahlian kepada organisasi, dan ini cukup untuk menyokong syarikat itu sendiri. Selain itu, kita semua pakar dalam perkara yang berbeza. Sebagai contoh, saya bekerja dengan akauntan, mengisi penyata cukai, melakukan segala macam perkara pentadbiran untuk syarikat, dan tiada siapa yang membayar saya untuknya. James dan Tom bekerja di laman web kami dan tiada siapa yang membayar mereka sama ada. Selagi anda membayar yuran anda, tiada siapa yang akan berfikir untuk memberitahu anda apa yang perlu anda lakukan. Sebagai contoh, Tom kini bekerja lebih kurang daripada yang pernah dia lakukan. Sekarang dia mempunyai minat lain; dia melakukan beberapa perkara bukan untuk Guild. Tetapi selagi dia membayar yurannya, tiada siapa yang akan datang kepadanya dan berkata, "Hei, Tom, pergi kerja!" Sangat mudah untuk berurusan dengan rakan sekerja apabila tiada wang di antara anda. Dan kini hubungan kami adalah salah satu idea asas berhubung dengan kepakaran yang berbeza. Ia berfungsi dan ia berfungsi dengan baik.
Nasihat terbaik
Michael: Kembali kepada "nasihat terbaik," adakah terdapat apa-apa yang anda beritahu pelanggan anda berulang kali? Terdapat idea tentang 80/20, dan beberapa nasihat mungkin diulang lebih kerap.
Tim: Saya pernah berfikir bahawa jika anda menulis buku seperti Waltzing with Bears, ia akan mengubah perjalanan sejarah dan orang akan berhenti, tetapi... Nah, lihat, syarikat sering berpura-pura bahawa semuanya baik-baik saja dengan mereka. Sebaik sahaja sesuatu yang buruk berlaku, ia adalah satu kejutan dan kejutan untuk mereka. "Lihat, kami menguji sistem, dan ia tidak melepasi sebarang ujian sistem, dan ini adalah tiga bulan lagi kerja tidak berjadual, bagaimana ini boleh berlaku? Siapa tahu? Apa yang boleh berlaku? Serius, adakah anda percaya ini?
Saya cuba menjelaskan bahawa anda tidak perlu terlalu marah tentang keadaan semasa. Kita perlu membincangkannya, benar-benar memahami apa yang boleh berlaku, dan bagaimana untuk mengelakkan perkara sedemikian daripada berlaku pada masa hadapan. Jika masalah muncul, bagaimana kita akan melawannya, bagaimana kita akan mengatasinya?
Bagi saya, ini semua kelihatan menakutkan. Orang ramai menghadapi masalah yang rumit dan menyusahkan dan terus berpura-pura bahawa jika mereka hanya menyilangkan jari mereka dan berharap untuk yang terbaik, yang "terbaik" sebenarnya akan berlaku. Tidak, ia tidak berfungsi seperti itu.
Amalkan pengurusan risiko!
Michael: Pada pendapat anda, berapa banyak organisasi yang terlibat dalam pengurusan risiko?
Tim: Apa yang membuat saya marah ialah orang hanya menulis risiko, melihat senarai yang terhasil dan pergi bekerja. Malah, mengenal pasti risiko untuk mereka adalah pengurusan risiko. Tetapi bagi saya ini terdengar seperti alasan untuk bertanya: okey, ada senarai, apa sebenarnya yang akan anda ubah? Anda perlu menukar urutan tindakan standard anda dengan mengambil kira risiko ini. Sekiranya terdapat bahagian kerja yang paling sukar, anda perlu menanganinya, dan kemudian beralih kepada sesuatu yang lebih mudah. Dalam larian pecut pertama, mulakan menyelesaikan masalah yang kompleks. Ini sudah kelihatan seperti pengurusan risiko. Tetapi biasanya orang tidak boleh mengatakan apa yang mereka berubah selepas menyusun senarai risiko.
Michael: Namun, berapa banyak syarikat ini terlibat dalam pengurusan risiko, lima peratus?
Tim: Malangnya, saya tidak suka untuk mengatakan ini, tetapi ini adalah bahagian yang sangat tidak penting. Tetapi lebih daripada lima, kerana terdapat projek yang sangat besar, dan mereka tidak boleh wujud jika mereka tidak melakukan sekurang-kurangnya sesuatu. Katakan sahaja bahawa saya akan sangat terkejut jika ia sekurang-kurangnya 25%. Projek kecil biasanya menjawab soalan sedemikian dengan cara ini: jika masalah itu memberi kesan kepada kami, maka kami akan menyelesaikannya. Kemudian mereka berjaya mendapat masalah dan terlibat dalam pengurusan masalah dan pengurusan krisis. Apabila anda cuba menyelesaikan masalah dan masalah itu tidak diselesaikan, selamat datang ke pengurusan krisis.
Ya, saya sering mendengar, "kami akan menyelesaikan masalah apabila ia timbul." Pasti kita akan melakukannya? Adakah kita benar-benar akan membuat keputusan?
Oleg: Anda boleh melakukannya secara naif dan hanya menulis invarian penting ke dalam piagam projek, dan jika invarian pecah, mulakan semula projek. Ia ternyata sangat piembucky.
Michael: Ya, ia berlaku kepada saya bahawa apabila risiko dicetuskan, projek itu hanya ditakrifkan semula. Bagus, bingo, masalah selesai, jangan risau lagi!
Tim: Jom tekan butang reset! Tidak, ia tidak berfungsi seperti itu.
Ucaptama di DevOops 2019
Michael: Kita sampai kepada soalan terakhir wawancara ini. Anda akan datang ke DevOops seterusnya dengan ucaptama, bolehkah anda membuka tirai kerahsiaan tentang perkara yang akan anda beritahu?
Tim: Kini, enam daripada mereka sedang menulis buku tentang budaya kerja, peraturan organisasi yang tidak dinyatakan. Budaya ditentukan oleh nilai teras organisasi. Biasanya orang tidak perasan perkara ini, tetapi setelah bekerja dalam perundingan selama bertahun-tahun, kami sudah biasa menyedarinya. Anda memasuki sebuah syarikat, dan dalam beberapa minit anda mula merasakan apa yang sedang berlaku. Kami memanggil ini "rasa". Kadang-kadang bau ini sangat baik, dan kadang-kadang ia, oops. Perkara sangat berbeza untuk organisasi yang berbeza.
Michael: Saya juga, telah bekerja dalam perundingan selama bertahun-tahun dan memahami dengan baik apa yang anda perkatakan.
Tim: Sebenarnya, salah satu perkara yang patut dibincangkan pada ucaptama ialah tidak semuanya ditentukan oleh syarikat. Anda dan pasukan anda, sebagai komuniti, mempunyai budaya pasukan anda sendiri. Ini mungkin keseluruhan syarikat, atau jabatan berasingan, pasukan berasingan. Tetapi sebelum anda berkata, inilah yang kami percaya, inilah yang penting... Anda tidak boleh mengubah budaya sebelum nilai dan kepercayaan di sebalik tindakan tertentu difahami. Tingkah laku mudah diperhatikan, tetapi mencari kepercayaan adalah sukar. DevOps hanyalah contoh yang bagus tentang bagaimana keadaan menjadi semakin kompleks. Interaksi hanya menjadi lebih kompleks, mereka tidak menjadi lebih bersih atau lebih jelas sama sekali, jadi anda harus berfikir tentang apa yang anda percayai dan perkara yang disenyapkan oleh semua orang di sekeliling anda.
Jika anda ingin mencapai hasil yang cepat, berikut ialah topik yang bagus untuk anda: pernahkah anda melihat syarikat yang tiada siapa yang berkata "Saya tidak tahu"? Terdapat tempat di mana anda benar-benar menyeksa seseorang sehingga dia mengakui bahawa dia tidak mengetahui sesuatu. Semua orang tahu segala-galanya, semua orang adalah seorang yang terpelajar yang luar biasa. Anda mendekati mana-mana orang, dan dia perlu segera menjawab soalan itu. Daripada berkata "Saya tidak tahu." Hooray, mereka mengupah sekumpulan orang terpelajar! Dan dalam sesetengah budaya, secara amnya sangat berbahaya untuk mengatakan "Saya tidak tahu"; ia boleh dianggap sebagai tanda kelemahan. Terdapat juga organisasi di mana, sebaliknya, semua orang boleh berkata "Saya tidak tahu." Di sana ia benar-benar sah, dan jika seseorang mula menyampah sebagai jawapan kepada soalan, adalah perkara biasa untuk menjawab: "Anda tidak tahu apa yang anda cakapkan, bukan?" dan menjadikan semuanya sebagai gurauan.
Sebaik-baiknya, anda ingin mempunyai pekerjaan di mana anda boleh sentiasa gembira. Ia tidak akan mudah, tidak setiap hari cerah dan menyenangkan, kadang-kadang anda perlu bekerja keras, tetapi apabila anda mula mengambil stok, ia akan menjadi: wow, ini adalah tempat yang sangat indah, saya berasa seronok bekerja di sini, baik dari segi emosi mahupun intelek. Dan terdapat syarikat di mana anda pergi sebagai perunding dan serta-merta menyedari bahawa anda tidak tahan selama tiga bulan dan akan melarikan diri dalam ketakutan. Inilah yang saya ingin bincangkan dalam laporan itu.
Tim Lister akan tiba dengan ucaptama ke persidangan DevOops 2019, yang akan berlangsung pada 29-30 Oktober 2019 di St. Petersburg. Anda boleh membeli tiket . Kami sedang menunggu anda di DevOops!
Sumber: www.habr.com