Tim Lister - Rekan penulis buku

• “Faktor manusia. Proyek dan tim yang berhasil "(buku asli disebut" Peopleware ")
• "Waltzing with the Bears: Manajemen Risiko dalam Proyek Pengembangan Perangkat Lunak"
• “Luar biasa dengan pola adrenalin dan zombie. Pola Perilaku Tim Proyek

Semua buku-buku ini klasik di bidangnya dan ditulis dengan rekan-rekan dari Atlantic Systems Guild . Di Rusia, rekan-rekannya paling terkenal - Tom Demarco dan Peter Khrushchka , yang juga menulis banyak karya terkenal.

Tim memiliki 40 tahun pengalaman dalam pengembangan perangkat lunak, pada tahun 1975 (tidak ada orang yang menulis hubpost ini lahir tahun ini), Tim sudah menjadi wakil presiden eksekutif Yourdon Inc. Sekarang dia terlibat dalam konsultasi, pelatihan, dan penulisan, dari waktu ke waktu menghadiri konferensi di seluruh dunia dengan laporan .

Khusus untuk Habr, kami melakukan wawancara dengan Tim Lister. Dia akan membuka konferensi DevOops 2019, dan kami telah mengumpulkan banyak pertanyaan, tentang buku dan banyak lagi. Wawancara dilakukan oleh Mikhail Druzhinin dan Oleg Chirukhin dari komite program konferensi.

Michael: Bisakah Anda mengatakan beberapa kata tentang apa yang Anda lakukan sekarang?

Tim: Saya adalah kepala Atlantic Systems Guild. Ada enam dari kita di Persekutuan, kita menyebut diri kita kepala sekolah. Tiga di AS dan tiga di Eropa - itulah mengapa Persekutuan disebut Atlantik. Kami telah bersama selama bertahun-tahun sehingga Anda tidak akan menghitung. Kita semua memiliki spesialisasi sendiri. Dekade terakhir, atau bahkan lebih, saya telah bekerja dengan klien. Proyek saya tidak hanya mencakup manajemen, tetapi juga pengaturan persyaratan, perencanaan proyek, dan evaluasi. Tampaknya proyek yang dimulai dengan buruk biasanya berakhir dengan buruk. Karena itu, Anda harus memastikan bahwa semua kegiatan dipikirkan dengan baik dan disetujui bahwa ide-ide para pencipta digabungkan. Layak untuk mempertimbangkan apa yang Anda lakukan dan mengapa. Strategi apa yang digunakan untuk menyelesaikan proyek.

Selama bertahun-tahun saya telah menasihati klien dalam berbagai cara. Contoh yang menarik adalah perusahaan yang membuat robot untuk operasi pada sendi lutut dan pinggul. Dokter bedah tidak beroperasi sepenuhnya secara independen, tetapi menggunakan robot. Keamanan di sini, terus terang, adalah penting. Tetapi ketika Anda mencoba membahas persyaratan dengan orang-orang yang berfokus pada penyelesaian masalah ... Kedengarannya aneh, tetapi di AS ada FDA (Federal Drug Administration), yang melisensikan produk seperti robot ini. Sebelum Anda menjual dan menggunakan sesuatu pada orang yang masih hidup, Anda perlu mendapatkan lisensi. Salah satu syarat adalah untuk menunjukkan persyaratan Anda, apa tesnya, bagaimana Anda mengujinya, apa hasil tesnya. Jika Anda mengubah persyaratan, maka Anda harus kembali melalui seluruh proses pengujian besar ini berulang kali. Klien kami berhasil memasukkan desain visual aplikasi dalam persyaratan mereka. Mereka mengambil tangkapan layar secara langsung sebagai bagian dari persyaratan. Kita harus menarik mereka keluar dan menjelaskan bahwa sebagian besar semua program ini tidak tahu apa-apa tentang lutut dan pinggul, semua ini dengan kamera, dll. Kita perlu menulis ulang dokumen dengan persyaratan sehingga tidak pernah berubah, kecuali beberapa kondisi fundamental yang sangat penting berubah. Jika tidak ada desain visual dalam persyaratan, memperbarui produk akan jauh lebih cepat. Tugas kita adalah menemukan elemen-elemen yang berhubungan dengan operasi pada lutut, pinggul, punggung, menarik mereka ke dalam dokumen terpisah dan mengatakan bahwa mereka akan menjadi persyaratan mendasar. Mari kita membuat kelompok persyaratan terisolasi tentang operasi lutut. Ini akan membangun seperangkat persyaratan yang lebih kuat. Kami akan berbicara tentang seluruh lini produk, dan bukan tentang contoh robot tertentu.

Banyak pekerjaan telah dilakukan, tetapi mereka tetap pergi ke tempat di mana mereka sebelumnya menghabiskan minggu dan bulan tes berulang tanpa makna dan kebutuhan, karena persyaratan mereka, dijelaskan di atas kertas, tidak sesuai dengan persyaratan nyata di mana sistem dibangun. Setiap kali FDA memberi tahu mereka: persyaratan Anda telah berubah, sekarang Anda perlu memeriksa semuanya dari awal. Pemeriksaan silang penuh atas seluruh produk menewaskan perusahaan.

Jadi, ada tugas yang luar biasa ketika Anda menemukan diri Anda pada awal sesuatu yang menarik, dan tindakan pertama menetapkan aturan lebih lanjut dari permainan. Jika Anda melakukannya baik dari sisi manajerial maupun dari sudut pandang teknis, aktivitas awal ini akan mulai bekerja dengan baik, ada peluang di pintu keluar untuk mendapatkan proyek yang luar biasa. Tetapi jika bagian ini keluar dari rel dan pergi ke suatu tempat yang salah, jika Anda tidak dapat menemukan perjanjian mendasar ... tidak, bukan berarti proyek Anda akan gagal. Tetapi Anda tidak akan bisa mengatakan: "Kami berhasil, kami telah melakukan segalanya dengan sangat efektif." Ini adalah hal-hal yang saya lakukan, berkomunikasi dengan klien.

Michael: Yaitu, Anda meluncurkan proyek, melakukan semacam kickoff dan memeriksa apakah rel mengarah ke arah yang benar?

Tim: Kami juga memiliki ide tentang bagaimana menyatukan semua bagian dari mosaik: keterampilan apa yang kami butuhkan, kapan tepatnya dibutuhkan, seperti apa inti tim itu dan hal-hal mendasar lainnya. Apakah kita membutuhkan karyawan penuh waktu atau bisakah kita merekrut seseorang paruh waktu. Perencanaan, manajemen. Pertanyaan seperti: apa yang paling penting untuk proyek khusus ini? Bagaimana cara mencapai ini? Apa yang kita ketahui tentang produk atau proyek ini, apa risikonya dan di mana tidak diketahui, bagaimana kita akan menghadapi semua ini? Tentu saja, seseorang pada saat ini mulai berteriak "Tapi bagaimana dengan gesit?!". Ya, Anda semua fleksibel, tapi terus kenapa? Seperti apa persisnya proyek itu, bagaimana Anda akan mengeluarkannya agar sesuai dengan proyek? Anda tidak bisa hanya mengatakan bahwa "pendekatan kami ditarik oleh apa pun, kami adalah tim scrum!" Ini omong kosong dan omong kosong. Ke mana Anda akan pergi selanjutnya, mengapa harus menghasilkan, ke mana intinya? Saya mengajar klien saya untuk merenungkan semua masalah ini.

19 tahun ajail

Michael: Di Ajail, orang sering mencoba untuk tidak menentukan apa pun sebelumnya, tetapi membuat keputusan selambat mungkin, mengatakan: kita terlalu besar, saya tidak akan berpikir tentang arsitektur umum. Saya tidak akan memikirkan banyak hal lain, sebaliknya, saat ini saya akan memasok sesuatu kepada pelanggan.

Tim: Saya pikir metodologi lincah, dimulai dengan Agile Manifesto pada tahun 2001, telah membuka mata industri ini. Tetapi, di sisi lain, tidak ada yang sempurna. Saya sepenuhnya berada di sisi pengembangan berulang. Iterasi sangat masuk akal di sebagian besar proyek. Tetapi Anda perlu memikirkan pertanyaan itu: setelah produk keluar dan mulai digunakan, berapa lama umurnya? Apakah ini produk yang akan bertahan enam bulan, dan kemudian akan digantikan oleh yang lain? Atau apakah produk seperti itu akan berfungsi selama bertahun-tahun? Tentu saja, saya tidak akan menyebutkan nama, tapi ... Di New York dan komunitas pemodalnya, sistem yang paling mendasar sudah sangat tua. Ini luar biasa. Anda melihat mereka dan berpikir bahwa Anda akan kembali ke masa lalu, pada tahun 1994, dan memberi tahu para pengembang: “Saya datang dari masa depan, mulai tahun 2019. Cukup rancang sistem ini sebanyak yang Anda butuhkan. Buat itu bisa diperluas, pikirkan arsitektur. Kemudian akan ditingkatkan selama lebih dari dua puluh lima tahun. Jika Anda menunda pengembangan sedikit lebih lama - tidak ada yang akan melihat ini pada skala sejarah! " Ketika Anda mengevaluasi hal-hal dalam jangka panjang, Anda perlu mempertimbangkan berapa biayanya secara keseluruhan. Terkadang arsitektur yang dirancang dengan baik benar-benar layak, dan kadang tidak. Anda perlu melihat-lihat dan bertanya pada diri sendiri pertanyaan: apakah kita berada dalam situasi yang cocok untuk solusi seperti itu?

Jadi ide seperti "Kami adalah untuk tangkas, pelanggan itu sendiri akan memberi tahu kami apa yang ingin ia terima" - itu supernatif. Lagi pula, pelanggan bahkan tidak tahu apa yang mereka inginkan, dan terlebih lagi mereka tidak tahu apa yang bisa mereka dapatkan. Beberapa akan mulai mengutip contoh-contoh sejarah sebagai argumen, saya sudah melihat ini. Tetapi orang-orang yang secara teknis maju biasanya tidak mengatakan itu. Mereka berkata: "Sekarang adalah tahun 2019, kami memiliki kesempatan seperti itu, dan kami dapat sepenuhnya mengubah pandangan kami tentang hal-hal seperti itu!" Alih-alih meniru solusi yang ada, menjadikannya sedikit lebih indah dan disisir, kadang-kadang Anda perlu keluar dan berkata: "Mari kita sepenuhnya menemukan kembali apa yang kita coba lakukan di sini!"

Dan saya tidak berpikir bahwa sebagian besar pelanggan dapat memikirkan masalah dengan cara ini. Mereka hanya melihat apa yang sudah mereka miliki, dan hanya itu. Kemudian mereka datang dengan permintaan seperti "mari kita membuatnya sedikit lebih mudah," atau apa pun yang biasanya mereka katakan. Tapi kami bukan pelayan dan pelayan yang memesan, tidak peduli seberapa bodoh hasilnya, dan kemudian memanggangnya di dapur. Kami adalah pemandu mereka. Kita harus membuka mata mereka dan berkata: hei, di sini kita memiliki peluang baru! Apakah Anda menyadari bahwa kami benar-benar dapat mengubah cara bagian bisnis Anda dilakukan? Salah satu masalah adjayl adalah bahwa ia menjauh dari kesadaran tentang apa yang merupakan peluang, apa masalah, apa yang perlu kita lakukan, teknologi mana yang paling cocok untuk situasi khusus ini.

Mungkin saya bertindak terlalu jauh dengan skeptisisme: banyak hal indah terjadi di komunitas yang gesit. Tapi saya punya masalah dengan fakta bahwa alih-alih mendefinisikan sebuah proyek, orang-orang mulai mengangkat bahu. Saya akan bertanya di sini - apa yang kita lakukan, bagaimana kita akan melakukan ini? Dan dalam beberapa cara ajaib selalu ternyata bahwa klien ini harus tahu yang terbaik. Tetapi klien mengetahui yang terbaik dari semuanya hanya ketika dia memilih dari hal-hal yang sudah dibangun oleh seseorang. Jika saya ingin membeli mobil dan saya tahu ukuran anggaran keluarga, maka saya akan segera mengambil mobil yang sesuai dengan gaya hidup saya. Di sini saya tahu segalanya lebih baik daripada siapa pun! Tapi, tolong, perhatikan bahwa seseorang telah membuat mesin. Cara membuat mobil baru, saya tidak tahu, saya bukan ahli. Saat kami membuat custom atau beberapa produk khusus, suara pelanggan harus diperhitungkan, tetapi ini bukan satu-satunya suara.

Oleg: Anda menyebut Agile Manifesto. Apakah kita perlu memperbarui atau merevisinya dengan mempertimbangkan pemahaman terkini tentang masalah ini?

Tim: Saya tidak akan menyentuhnya. Saya pikir ini adalah dokumen sejarah yang hebat. Maksudku, dia memang seperti itu. Dia berusia 19 tahun, dia sudah tua, tetapi pada suatu waktu dia membuat revolusi. Apa yang dia lakukan dengan baik adalah meluncurkan reaksi, mereka mulai berbisik tentang dia. Kemungkinan besar, Anda tidak bekerja di industri pada tahun 2001, tetapi kemudian semua bekerja pada proses. Institut Rekayasa Perangkat Lunak, lima tingkatan model CMP. Saya tidak tahu apakah legenda zaman kuno itu memberi tahu Anda sesuatu yang mendalam, tetapi kemudian itu merupakan terobosan. Pada awalnya, orang percaya bahwa jika proses dibangun dengan benar, maka masalah itu sendiri akan menguap. Dan kemudian Manifesto muncul dan berkata: "Tidak, tidak, tidak - kita akan didasarkan pada orang, bukan pada proses." Kami adalah master pengembangan perangkat lunak. Kami memahami bahwa proses yang ideal adalah fatamorgana, tidak. Ada terlalu banyak keanehan dalam proyek, gagasan tentang satu proses tanpa cacat untuk semua proyek tidak masuk akal. Masalahnya terlalu kompleks untuk mengklaim bahwa solusi tunggal telah ditemukan untuk semuanya (hai, nirwana).

Saya tidak berasumsi untuk melihat ke masa depan, tetapi saya akan mengatakan bahwa orang-orang sekarang mulai berpikir lebih banyak tentang proyek. Saya pikir Agile Manifesto sangat baik, dia melompat maju dan berkata: "Hei! Anda berada di atas kapal, dan Anda sendiri yang memimpin kapal ini. Anda harus mengambil keputusan - kami tidak akan meminta resep universal untuk semua situasi. Anda adalah kru kapal, dan jika Anda cukup baik, Anda dapat menemukan jalan menuju tujuan. Ada kapal-kapal lain sebelum Anda, dan kapal-kapal lain akan mengejar Anda, tetapi bagaimanapun, dalam perjalanan tertentu, perjalanan Anda unik. ” Sesuatu seperti itu! Ini cara berpikir. Bagi saya, tidak ada yang baru di bawah bulan, orang-orang berlayar lebih awal dan akan berenang lagi, tetapi bagi Anda ini adalah perjalanan utama Anda, dan saya tidak akan memberi tahu Anda dengan pasti apa yang akan terjadi pada Anda. Anda harus memiliki keterampilan kerja tim yang terkoordinasi, dan jika memang benar, semuanya akan berhasil dan Anda akan datang ke tempat yang Anda inginkan.

Peopleware: 30 tahun kemudian

Oleg: Peopleware juga sebuah revolusi, seperti Manifesto?

Tim: Peopleware ... Tom dan saya menulis buku ini, tetapi tidak berpikir bahwa semuanya akan terjadi. Entah bagaimana, itu selaras dengan ide-ide banyak orang. Ini adalah buku pertama yang mengatakan: pengembangan perangkat lunak adalah aktivitas yang sangat intensif bagi manusia. Terlepas dari sifat teknis kami, kami juga merupakan komunitas orang yang membangun sesuatu yang besar, bahkan besar, sangat kompleks. Tidak ada yang bisa membuat hal seperti itu sendirian, bukan? Jadi ide "tim" telah menjadi sangat penting. Dan tidak hanya dari sudut pandang manajemen, tetapi juga untuk orang-orang dari gudang teknis yang datang bersama-sama untuk memecahkan masalah yang sangat kompleks dengan banyak yang tidak diketahui. Bagi saya pribadi, sepanjang karier saya ini merupakan ujian kecerdasan yang sangat besar. Dan di sini Anda harus bisa mengatakan: ya, masalah ini lebih dari yang saya bisa tangani sendiri, tetapi bersama-sama kita dapat menemukan solusi elegan yang bisa kita banggakan. Dan saya berpikir bahwa ide khusus ini paling cocok. Idenya adalah bahwa kita bekerja sebagian dari waktu kita sendiri, bagian dari kelompok, dan seringkali keputusan dibuat oleh kelompok. Pemecahan masalah kelompok dengan cepat menjadi fitur penting dari proyek yang kompleks.

Terlepas dari kenyataan bahwa Tim memiliki sejumlah besar laporan, ada sangat sedikit dari mereka yang diposting di YouTube. Anda dapat melihat laporan The Return of Peopleware 2007. Kualitas, tentu saja, menyisakan banyak yang diinginkan.

Michael: Apakah ada yang berubah dalam 30 tahun terakhir sejak rilis buku?

Tim: Anda dapat melihatnya dari berbagai sudut. Berbicara secara sosiologis ... sekali, di masa yang lebih sederhana, Anda dan tim berada di kantor yang sama. Anda bisa berada di sana setiap hari, minum kopi bersama, dan mendiskusikan pekerjaan. Apa yang benar-benar berubah adalah bahwa sekarang tim dapat didistribusikan secara geografis, di berbagai negara dan zona waktu, tetapi bagaimanapun mereka sedang mengerjakan tugas yang sama, dan ini menambah lapisan kompleksitas yang sama sekali baru. Ini mungkin terdengar kuno, tetapi tidak ada yang lebih baik dari komunikasi tatap muka, ketika Anda semua berkumpul, bekerja bersama, Anda dapat pergi ke seorang rekan dan berkata: lihat, saya menemukan bagaimana perasaan Anda tentang hal itu? Percakapan tatap muka menyediakan cara cepat untuk bergerak ke arah komunikasi informal, dan saya pikir ini juga menarik bagi para pecinta seks. Dan saya khawatir karena pada kenyataannya dunia ternyata sangat kecil, dan sekarang semuanya diliput oleh tim yang didistribusikan, dan semua ini sangat rumit.

Kita semua hidup di DevOps

Michael: Bahkan dari sudut pandang komite program konferensi, kami memiliki orang-orang di California, di New York, Eropa, Rusia ... di Singapura masih belum ada. Perbedaan dalam geografi cukup besar, dan orang-orang mulai didistribusikan lebih banyak lagi. Jika kita sudah berbicara tentang pengembangan, dapatkah Anda memberi tahu kami lebih banyak tentang devops dan penghancuran rintangan di antara tim? Ada konsep bahwa setiap orang duduk di bunker mereka, dan sekarang bunker itu hancur, bagaimana Anda menyukai analogi ini?

Tim: Bagi saya, dalam terang terobosan teknologi baru-baru ini, devops sangat penting. Sebelumnya, Anda memiliki tim pengembang dan admin, mereka bekerja, bekerja, bekerja, dan pada titik tertentu muncul sesuatu yang dapat Anda gunakan untuk masuk ke admin dan meluncurkannya ke prod. Dan di sini pembicaraan tentang bunker dimulai, karena admin seperti sekutu, bukan musuh, setidaknya, tetapi Anda hanya berbicara dengan mereka ketika semuanya siap untuk mulai dijual. Anda mendatangi mereka dengan sesuatu dan berkata: lihat, apa aplikasi kami, tetapi bisakah Anda meluncurkan aplikasi ini? Dan sekarang seluruh konsep pengiriman telah berubah menjadi lebih baik. Maksud saya, muncul ide bahwa Anda dapat mendorong perubahan dengan cepat. Kami dapat memperbarui produk dengan cepat. Saya selalu tersenyum ketika Firefox muncul di laptop saya dan berkata: hei, kami telah memperbarui Firefox Anda di latar belakang, dan segera setelah Anda punya waktu sebentar, bisakah Anda mengklik di sini dan kami akan memberi Anda rilis baru. Dan saya seperti: "Oh ya, sayang!" Ketika saya sedang tidur, tepat di komputer saya mereka bekerja untuk memasok saya dengan rilis baru. Ini luar biasa, luar biasa.

Tetapi inilah kesulitannya: Anda memiliki fitur ini dengan pembaruan perangkat lunak, tetapi mengintegrasikan orang jauh lebih sulit. Apa yang ingin saya katakan pada DevOops adalah bahwa kita sekarang memiliki lebih banyak pemain daripada sebelumnya. Jika Anda hanya berpikir tentang semua orang yang mengambil bagian dalam pekerjaan hanya satu tim .... Anda menganggapnya sebagai tim, dan itu jauh lebih dari sekadar tim programmer. Ini adalah penguji, manajer proyek, dan sekelompok orang lain. Dan setiap orang memiliki pandangan mereka sendiri tentang dunia. Manajer produk sama sekali berbeda dari manajer proyek. Admin memiliki tugas mereka sendiri. Ini menjadi masalah yang agak sulit untuk mengoordinasikan semua peserta, sehingga terus menyadari apa yang terjadi dan tidak keluar dari kumparan. Penting untuk memisahkan tugas-tugas kelompok dan tugas-tugas yang berkaitan dengan semua. Ini adalah tugas yang sangat sulit. Di sisi lain, saya pikir semua ini telah menjadi jauh lebih baik daripada beberapa tahun yang lalu. Ini persis jalan di mana orang tumbuh dan belajar untuk berperilaku dengan benar. Ketika Anda terlibat dalam integrasi, Anda memahami bahwa seharusnya tidak ada pengembangan bawah tanah, sehingga pada saat terakhir perangkat lunak tidak merangkak keluar dari kotak: seperti, lihat, apa yang telah kami lakukan di sini! Idenya adalah bahwa Anda dapat melakukan integrasi dan pengembangan, dan pada akhirnya Anda akan meluncurkan dengan cara yang rapi dan berulang. Semua ini sangat penting bagi saya. Ini memungkinkan untuk menciptakan nilai lebih bagi pengguna sistem dan untuk klien Anda.

Michael: Seluruh ide Devopse adalah untuk memberikan pekerjaan yang bermakna sedini mungkin. Saya melihat bahwa dunia mulai semakin cepat. Bagaimana cara beradaptasi dengan akselerasi seperti itu? Sepuluh tahun yang lalu, ini bukan!

Tim: Tentu saja, semua orang menginginkan lebih banyak fungsionalitas. Tidak perlu bergerak, hanya tumpukan lebih banyak. Kadang-kadang Anda bahkan harus memperlambat agar pembaruan tambahan berikutnya membawa setidaknya sesuatu yang bermanfaat - dan ini benar-benar normal.

Gagasan bahwa Anda perlu menjalankan-lari-lari bukanlah yang terbaik. Hampir tidak ada yang mau hidup seperti ini. Saya ingin ritme pengiriman untuk mengatur ritme proyek sendiri. Jika Anda hanya menghasilkan aliran hal-hal kecil yang relatif tidak berarti, semua ini secara total tidak masuk akal. Alih-alih tanpa berpikir mencoba untuk merilis sesuatu sedini mungkin, apa yang layak dibahas dengan pengembang terkemuka dan manajer produk dan proyek adalah strateginya. Apakah ini masuk akal?

Pola dan antipattern

Oleg: Anda biasanya berbicara tentang pola dan antipattern, dan ini adalah perbedaan antara hidup dan mati proyek. Dan sekarang, devops menerobos ke dalam hidup kita. Apakah ia memiliki pola dan antiputunya sendiri yang dapat membunuh proyek di tempat?

Tim: Pola dan antipattern terjadi sepanjang waktu. Apa yang harus dibicarakan. Nah, ada hal yang kita sebut "benda mengkilap." Orang-orang sangat, sangat menyukai teknologi baru. Mereka hanya tersihir oleh kecemerlangan segala sesuatu yang terlihat keren dan bergaya, dan berhenti bertanya: apakah itu perlu? Apa yang akan kita capai? Apakah benda ini dapat diandalkan, apakah masuk akal? Saya sering melihat orang, katakanlah, di garis depan teknologi. Mereka terpesona oleh apa yang terjadi di dunia. Tetapi jika Anda melihat lebih dekat, apa yang mereka lakukan - seringkali, tidak ada yang berguna!

, – , , . 1969. , – 1969 , 1960 62, NASA , . – , ! -, , , . : «, , , , !». - … , . , , , , , . , : « !».

: , ?

: , ! … , , -. ! , , , – . , , ? ! . , . , , … – . : . , .

: , « , »: ?

: . - . – - , , ? , – . , , - : « ! !». Benarkah? .

«-»

: . - , «-» . : , , «-», ? , – , - .

: -. - . - , . , , , ! , , «-», , , ? – . , «» — , ? . - , , , . , ?

, , , , – . , - , - – . , DevOps, , - . , , , . « », « » , , – «».

- , , . , , . – , « ». ? , , . - , , , , , . , - , , , , . ! - .

- -. , , ? , , ? - : --, , , , , .

, , . , . , , : , . , . , . .

. – , , , , , , ! - . – …

« »

: ? , , , – « ».

: ! – , - . - , ( , ). – , – , - , .

, . , « - , ». , -, , . , , . , , , , , . , , , – , . , . , .

: , . , , . , . , – , – . , , , .

: Move fast and break things!

: , , , – -. , ?

: : . . , - , . , , - , « », , : « ». , . , , . – .

, . , , , - . - , , . , – , , , , . , , , . .

, , . , – , . , , , , , ? ? , ? , : , . , , , - . : , .

, . , : , , - , . , , . , , , .

, ? , . , . 100%, : «, , !». . – , , , ! , , , : « – , – ». , - .

, , – . , . . !

: . , . ?

: , , – . , . - ? , , , , . , , . « , – ». . ( !) , . . , , – , . , . , . , , , , , , … , , . , , . . , , , !

: , , - , (, ) .

Tim: Benar. Saya pikir teknisi terbaik, jika Anda perhatikan mereka, mereka seperti manajer bagi diri mereka sendiri. Bagaimana memformulasikannya ...

Oleg: Hidup Anda adalah proyek yang Anda kelola.

Tim: Benar! Maksud saya, Anda bertanggung jawab, Anda memahami masalah ini, dan Anda berhubungan dengan orang-orang ketika Anda melihat bahwa keputusan Anda dapat memengaruhi pekerjaan mereka, semuanya dalam semangat itu. Ini bukan tentang hanya duduk di meja, melakukan pekerjaan Anda, dan bahkan tidak tahu apa yang terjadi di sekitar. Tidak, tidak, tidak. Ngomong-ngomong, salah satu hal terbaik di Agile adalah mereka menyarankan sprint pendek, karena keadaan semua peserta diamati dengan baik, mereka bisa menonton semuanya bersama-sama. Setiap hari kita berbicara tentang satu sama lain.

Cara masuk ke manajemen risiko

Oleg: Apakah ada struktur pengetahuan formal di bidang ini? Misalnya, saya adalah pengembang Java dan ingin memahami manajemen risiko tanpa menjadi manajer proyek pendidikan nyata. Mungkin, pertama saya membaca "Berapa proyek perangkat lunak" oleh McConnell, dan kemudian apa? Apa langkah pertama?

Tim: Yang pertama adalah mulai berkomunikasi dengan orang-orang di proyek. Ini memberikan peningkatan instan dalam budaya komunikasi dengan rekan kerja. Anda harus memulai dengan membuka semuanya secara default, alih-alih menyembunyikannya. Katakanlah: ini adalah hal-hal yang mengganggu saya, ini adalah hal-hal yang membuat saya tetap terjaga di malam hari, hari ini saya bangun di malam hari dan seperti ini: para dewa, ini harus dipertimbangkan! Apakah yang lain melihat hal yang sama? Sebagai kelompok, haruskah kita menanggapi potensi masalah ini? Anda harus dapat mempertahankan diskusi tentang topik ini. Tidak ada formula yang sudah disiapkan sebelumnya dimana kami bekerja. Ini bukan produksi hamburger, ini semua tentang manusia. “Membuat cheeseburger - menjual cheeseburger” - ini bukan tentang kita sama sekali, dan itulah sebabnya saya sangat menyukai pekerjaan ini. Saya suka ketika segala sesuatu yang manajer lakukan sebelumnya, sekarang menjadi milik tim.

Oleg: Anda memberi tahu dalam buku-buku dan wawancara bahwa orang-orang lebih khawatir tentang kebahagiaan daripada tentang angka-angka pada grafik. Di sisi lain, ketika Anda memberi tahu tim: kami beralih ke devops, dan sekarang programmer harus terus berkomunikasi, ini mungkin jauh melampaui zona kenyamanannya. Dan pada saat ini, dia dapat, katakan saja, sangat tidak bahagia. Apa yang harus dilakukan dalam situasi ini?

Tim: Saya tidak yakin apa yang harus saya lakukan. Jika pengembang terlalu terisolasi, dia tidak melihat mengapa pekerjaan dilakukan sama sekali, dia hanya melihat bagian pekerjaannya, dan dia perlu menyelidiki apa yang saya sebut “konteks”. Dia perlu mencari tahu bagaimana semuanya saling berhubungan. Dan tentu saja, saya tidak bermaksud presentasi formal atau semacamnya. Saya mengatakan bahwa Anda perlu berkomunikasi dengan rekan kerja tentang pekerjaan secara keseluruhan, dan bukan hanya tentang bagian pekerjaan yang menjadi tanggung jawab Anda. Dan pada saat ini, Anda dapat mulai mendiskusikan ide, kesepakatan umum, sehingga pekerjaan Anda berjalan dengan baik, dan bagaimana bersandar pada masalah bersama.

Untuk beradaptasi, teknisi seringkali juga ingin mengirim mereka ke pelatihan, mendiskusikan pelatihan. Seorang teman saya suka mengatakan bahwa pelatihan adalah untuk anjing. Ada pelatihan untuk orang-orang. Salah satu hal terbaik untuk diajarkan pengembang adalah berkomunikasi dengan kolega. Jika seseorang benar-benar berhasil dalam sesuatu, Anda harus melihat bagaimana dia bekerja, atau berdiskusi dengannya, atau sesuatu seperti itu. Beberapa kondisional Kent Beck terus-menerus berbicara tentang pemrograman ekstrem. Ini lucu, karena XP adalah ide yang sangat sederhana, tetapi menyebabkan begitu banyak masalah. Bagi seseorang, melakukan XP seolah dipaksa untuk menelanjangi telanjang di depan teman-teman. Mereka akan melihat apa yang saya lakukan! Mereka adalah kolega saya, mereka tidak hanya akan melihat, tetapi juga mengerti! Mengerikan Seseorang mulai gelisah. Tetapi ketika Anda menyadari bahwa ini adalah cara terbaik untuk belajar, semuanya berubah. Anda bekerja sama dengan orang-orang, dan beberapa orang memahami topik itu jauh lebih baik daripada Anda.

Michael: Tapi semua ini membuat Anda meninggalkan zona nyaman Anda. Sebagai seorang insinyur, Anda harus keluar dari zona nyaman Anda, berkomunikasi. Sebagai orang yang memecahkan masalah, Anda harus terus-menerus menempatkan diri Anda dalam posisi yang lemah dan mempertimbangkan apa yang salah. Pekerjaan semacam itu pada dasarnya dirancang untuk merepotkan. Anda secara sadar menempatkan diri Anda dalam situasi stres. Biasanya, orang lari dari mereka, orang suka menjadi anak yang bahagia.

Tim: Apa yang bisa dilakukan, Anda bisa keluar dan secara terbuka mengatakan: “Semuanya beres, saya bisa mengatasinya! Saya tidak sendirian dalam ketidaknyamanan. Mari kita bahas berbagai hal yang tidak nyaman, bersama-sama, sebagai sebuah tim! ” Ini adalah masalah kita bersama, kita harus menghadapinya, mengerti? Saya pikir para pengembang brilian istimewa - mereka seperti mammoth, mereka menghilang. Ya, dan mereka memiliki nilai yang sangat terbatas. Jika Anda tidak dapat berkomunikasi, Anda tidak dapat berpartisipasi secara normal. Karena itu, katakan saja. Jujur dan terbuka. Saya sangat menyesal bahwa seseorang tidak menyenangkan. Bayangkan, bertahun-tahun yang lalu ada penelitian yang menyatakan bahwa ketakutan utama di AS bukanlah kematian, tetapi coba tebak? Takut berbicara di depan umum! Jadi, di suatu tempat ada orang yang lebih mungkin meninggal daripada mengatakan pujian dengan keras. Dan Anda, saya pikir, hanya memiliki beberapa keterampilan dasar, tergantung pada apa yang Anda lakukan. Keterampilan percakapan, keterampilan menulis - tetapi sebanyak itu benar-benar diperlukan dalam pekerjaan Anda. Jika Anda bekerja sebagai analis, tetapi Anda tidak dapat membaca, menulis, dan berbicara, maka sayangnya Anda tidak akan melakukan apa pun di proyek saya!

Harga komunikasi

Oleg: Apakah penggunaan karyawan yang keluar seperti itu lebih mahal karena berbagai alasan? Pada akhirnya, mereka berbicara terus-menerus alih-alih bekerja!

Tim: Saya memikirkan inti dari tim, dan umumnya tidak semua berturut-turut. Jika Anda memiliki seorang spesialis yang benar-benar membuat basis data Anda keren, suka mengatur basis data Anda dan akan terus membuat basis data Anda selama sisa hidup Anda, dan itu semua keren, teruskan. Tapi saya berbicara tentang orang yang ingin hidup dalam proyek itu sendiri. Inti dari tim, bertujuan mengembangkan proyek. Orang-orang ini benar-benar perlu berkomunikasi secara konstan satu sama lain. Dan terutama pada awal proyek, ketika Anda membahas risiko, cara untuk mencapai tujuan global, dan sejenisnya.

Michael: Ini berlaku untuk semua orang yang terlibat dalam proyek, terlepas dari spesialisasi, keterampilan, cara bekerja. Anda semua tertarik pada keberhasilan proyek.

Tim: Ya, Anda merasa sangat tenggelam dalam proyek ini, bahwa tugas Anda adalah membantu proyek menjadi kenyataan. Jadilah Anda seorang programmer, analis, perancang antarmuka, siapa pun. Inilah alasan mengapa saya datang bekerja setiap pagi, dan inilah yang kami lakukan. Kami bertanggung jawab untuk semua orang ini, terlepas dari keterampilan mereka. Ini adalah sekelompok orang yang melakukan percakapan orang dewasa.

Oleg: Sebenarnya, berbicara tentang karyawan yang banyak bicara, saya mencoba untuk mensimulasikan keberatan orang, khususnya, manajer yang ditawari untuk beralih ke devops, ke seluruh visi dunia yang baru ini. Dan bagi Anda, sebagai konsultan, keberatan ini harus diketahui lebih baik daripada saya sebagai pengembang! Bagikan apa yang paling diperhatikan manajer?

Tim: Manajer? Hm Paling sering, manajer berada di bawah tekanan masalah, sebelum kebutuhan untuk segera melepaskan sesuatu dan melakukan pengiriman dan sejenisnya. Mereka menyaksikan kita terus-menerus berdiskusi dan berdebat, dan mereka melihatnya seperti ini: percakapan, percakapan, percakapan ... Apa percakapan lain? Kembali bekerja! Karena percakapan sepertinya tidak seperti pekerjaan. Anda tidak menulis kode, tidak menguji perangkat lunak, tampaknya tidak melakukan apa pun - mengapa tidak mengirim Anda untuk melakukan bisnis? Lagi pula, pengiriman sudah dalam sebulan!

Michael: Pergi tulis kode!

Tim: Tampak bagi saya bahwa mereka tidak khawatir tentang pekerjaan, tetapi tentang kurangnya visibilitas untuk bergerak maju. Agar mereka berpikir bahwa kita sedang mendekati kesuksesan, mereka perlu melihat bagaimana kita menekan tombol pada keyboard. Sepanjang hari dari pagi hingga sore. Ini adalah masalah nomor satu.

Oleg: Misha, kamu sudah memikirkan sesuatu.

Michael: Maaf, saya pikir, saya menangkap kilas balik. Semua ini mengingatkan saya pada satu reli menarik yang terjadi kemarin ... Kemarin ada terlalu banyak aksi unjuk rasa ... Dan semua ini terdengar sangat akrab!

Hidup tanpa gaji

Tim: Ngomong-ngomong, tidak perlu mengatur "rapat" untuk komunikasi. Maksud saya, diskusi paling berguna antara pengembang terjadi ketika mereka hanya berbicara satu sama lain. Anda datang di pagi hari dengan secangkir kopi, dan di sana kami berlima berkumpul dan mendiskusikan sesuatu yang sangat teknis. Bagi saya, jika saya adalah manajer proyek ini, lebih baik hanya tersenyum dan pergi ke suatu tempat tentang bisnis Anda, biarkan mereka berdiskusi. Mereka sudah terlibat sebanyak mungkin. Ini pertanda baik.

Oleg: Ngomong-ngomong, di sini Anda memiliki banyak catatan di buku Anda tentang apa yang baik dan apa yang buruk. Apakah Anda menggunakan salah satu dari mereka sendiri? Secara relatif, di sini Anda memiliki perusahaan sekarang, dan bahkan struktur yang sangat tidak lazim ...

Tim: Tidak lazim, tetapi alat seperti itu bagus untuk kita. Kami saling kenal untuk waktu yang lama. Kami saling percaya, saling percaya sebelum kami menjadi mitra. Dan misalnya, kami tidak punya gaji sama sekali. Kami hanya bekerja, dan misalnya, jika saya mendapat uang dari klien saya, maka uang itu semua jatuh ke tangan saya. Setelah itu, kami membayar biaya keanggotaan kepada organisasi, dan ini cukup untuk mempertahankan perusahaan itu sendiri. Plus, kita semua berspesialisasi dalam berbagai hal. Misalnya, saya bekerja dengan akuntan, mengisi formulir pajak, melakukan semua hal administrasi untuk perusahaan, dan tidak ada yang membayar saya untuk ini. James dan Tom bekerja di situs kami dan tidak ada yang membayar mereka juga. Selama Anda membayar iuran Anda, tidak seorang pun akan berpikir untuk memberi tahu Anda apa yang perlu Anda lakukan. Sebagai contoh, Tom sekarang bekerja jauh lebih sedikit daripada sebelumnya. Sekarang dia memiliki minat lain, sesuatu yang tidak dia lakukan untuk Persekutuan. Tetapi selama dia membayar iurannya, tidak ada yang akan mendatanginya dan berkata: "Hai Tom, ayo, bekerja!" Sangat mudah untuk berurusan dengan kolega ketika tidak ada uang di antara Anda. Dan sekarang hubungan kita adalah salah satu ide dasar, diterapkan pada spesialisasi yang berbeda. Itu bekerja, dan itu bekerja dengan sangat baik.

Saran terbaik

Michael: Kembali ke "saran terbaik", adakah sesuatu yang Anda ulangi kepada pelanggan Anda berulang kali? Ada ide tentang 80/20, dan pasti beberapa saran diulang lebih sering.

Tim: Suatu ketika saya berpikir bahwa jika Anda menulis buku seperti "Waltzing with the Bears", itu akan mengubah arah sejarah dan orang-orang akan berhenti, tetapi ... Begini, sering kali perusahaan berpura-pura bahwa mereka baik-baik saja. Begitu sesuatu yang buruk terjadi, itu mengejutkan dan mengejutkan mereka. “Lihat, kami menguji sistem, dan tidak lulus tes sistem apa pun, dan ini adalah tiga bulan kerja yang luar biasa, bagaimana ini bisa terjadi? Siapa yang tahu Apa yang salah? ” Serius, apakah Anda percaya itu?

Saya mencoba menjelaskan bahwa Anda tidak boleh marah pada situasi saat ini. Anda perlu membahasnya, untuk benar-benar memahami apa yang salah, dan bagaimana mencegah hal-hal seperti itu di masa depan. Namun, jika masalahnya memanifestasikan dirinya, bagaimana kita akan memeranginya, bagaimana mengendalikannya.

Bagi saya, semuanya terlihat menakutkan. Orang-orang menghadapi masalah yang rumit dan tidak menyenangkan, dan terus berpura-pura bahwa jika mereka hanya menyilangkan jari dan berharap untuk yang terbaik, ini "yang terbaik" akan benar-benar terjadi. Tidak, itu tidak berhasil.

Terlibat dalam manajemen risiko!

Michael: Menurut Anda, berapa banyak organisasi yang terlibat dalam manajemen risiko?

Tim: Yang membuat saya jengkel adalah orang-orang hanya menuliskan risiko, melihat daftar hasilnya dan mulai bekerja. Faktanya, mengidentifikasi risiko untuk mereka adalah manajemen risiko. Tetapi bagi saya ini kedengarannya seperti alasan untuk pertanyaan: baik, ada daftar, apa yang sebenarnya akan Anda ubah? Anda perlu mengubah urutan tindakan standar Anda dengan mempertimbangkan risiko ini. Jika ada bagian pekerjaan yang paling sulit, Anda harus melakukannya, dan baru kemudian beralih ke bagian yang lebih sederhana. Pada sprint pertama, mulailah memecahkan masalah yang rumit. Sekarang ini mirip dengan manajemen risiko. Tetapi biasanya orang tidak bisa mengatakan apa yang mereka ubah setelah menyusun daftar risiko.

Michael: Namun, berapa banyak perusahaan manajemen risiko seperti itu lima persen?

Tim: Sayangnya, tidak menyenangkan bagi saya untuk mengatakan ini, tetapi ini adalah bagian yang sangat tidak penting. Tetapi lebih dari lima, karena memang ada proyek-proyek besar, dan mereka tidak bisa eksis kecuali mereka melakukan setidaknya sesuatu. Anggap saja saya akan sangat terkejut jika setidaknya 25%. Proyek-proyek kecil biasanya menjawab pertanyaan-pertanyaan seperti ini: jika masalah menyentuh kita, maka kita akan menyelesaikannya. Kemudian mereka berhasil terjun ke dalam masalah, dan terlibat dalam manajemen masalah dan manajemen krisis. Ketika Anda mencoba menyelesaikan masalah, tetapi masalahnya tidak terpecahkan - selamat datang di manajemen krisis.

Ya, saya sering mendengar, "kami akan menyelesaikan masalah saat tersedia." Akankah kita benar? Akankah kita memutuskan dengan tepat?

Oleg: Anda dapat melakukannya secara naif dan cukup menulis invarian penting ke dalam piagam proyek, dan jika invarian rusak, cukup restart proyek. Ternyata dengan cara yang sangat pembucco.

Mikhail: Ya, itu terjadi pada saya bahwa ketika risikonya bekerja, proyek itu hanya didefinisikan ulang. Bagus, bingo, masalahnya selesai, tidak ada lagi kekhawatiran!

Tim: Tekan tombol reset! Tidak, itu tidak berhasil.

Keynote at DevOops 2019

Michael: Kami sampai pada pertanyaan terakhir dari wawancara ini. Anda datang ke DevOops berikutnya dengan keynote, bisakah Anda membuka tabir kerahasiaan atas apa yang akan Anda katakan?

Tim: Saat ini, enam dari mereka sedang menulis buku tentang budaya kerja, aturan organisasi yang tak terucapkan. Budaya ditentukan oleh nilai-nilai inti organisasi. Biasanya orang tidak memperhatikan ini, tetapi kami, bekerja dalam konsultasi selama bertahun-tahun, terbiasa memperhatikannya. Anda masuk ke perusahaan, dan hanya beberapa menit kemudian Anda mulai merasakan apa yang terjadi. Kami menyebutnya "aroma." Kadang-kadang aroma ini sangat bagus, dan kadang-kadang, ya, oops. Organisasi yang berbeda memiliki hal yang sangat berbeda.

Michael: Saya juga telah bekerja dalam konsultasi selama bertahun-tahun dan saya mengerti dengan baik apa yang Anda bicarakan.

Tim: Sebenarnya, salah satu hal yang layak dibicarakan dalam keynote adalah bahwa tidak semuanya ditentukan oleh perusahaan. Anda dan tim Anda, sebagai komunitas - Anda memiliki budaya tim sendiri. Ini dapat berupa seluruh perusahaan, atau departemen yang terpisah, tim yang terpisah. Tetapi sebelum Anda mengatakan: itulah yang kami yakini, itu penting ... Anda tidak dapat mengubah budaya Anda sebelum Anda menyadari nilai-nilai dan keyakinan di balik tindakan nyata. Perilaku mudah diamati, dan mencari bujukan sulit. DevOps hanyalah contoh yang bagus tentang bagaimana segala sesuatu menjadi semakin sulit. Interaksi menjadi lebih rumit, mereka tidak menjadi lebih bersih dan lebih mudah dipahami sama sekali, jadi Anda harus berpikir tentang apa yang Anda yakini dan apa yang semua orang di sekitarnya diam.

Jika Anda ingin mencapai hasil yang cepat, inilah topik yang bagus: apakah Anda pernah melihat perusahaan yang tidak ada yang mengatakan "Saya tidak tahu"? Ada tempat-tempat di mana Anda perlu menyiksa seseorang sampai ia mengakui bahwa ia tidak tahu apa-apa. Semua orang tahu segalanya, semua orang ulama luar biasa. Anda mendekati siapa pun, dan dia harus langsung menjawab sesuatu untuk pertanyaan itu. Alih-alih mengatakan "Aku tidak tahu." Hore, mereka menyewa sekelompok ulama! Dan dalam beberapa budaya itu sangat berbahaya untuk mengatakan "Saya tidak tahu", itu dapat dianggap sebagai manifestasi dari kelemahan. Ada organisasi di mana, sebaliknya, semua orang dapat mengatakan "Saya tidak tahu." Itu benar-benar legal di sana, dan jika seseorang yang menanggapi pertanyaan mulai menggosok permainan, sangat normal untuk menjawab: "Anda tidak mengerti apa yang Anda bicarakan, kan?" dan membuatnya menjadi lelucon.

Idealnya, saya ingin memiliki pekerjaan di mana Anda bisa bahagia sepanjang waktu. Itu tidak akan mudah, tidak setiap hari cerah dan menyenangkan, kadang-kadang Anda perlu bekerja keras, tetapi ketika Anda mulai meringkas, ternyata: wow, ini benar-benar tempat yang indah, saya bekerja dengan baik di sini, baik secara emosional maupun intelektual. Dan ada perusahaan yang Anda masuki sebagai konsultan dan langsung menyadari bahwa Anda tidak akan bertahan selama tiga bulan dan akan lari ketakutan. Itulah yang ingin saya bicarakan dalam laporan.

Tim Lister akan tiba dengan Keynote "Karakter, komunitas, dan budaya: Faktor penting untuk kemakmuran" pada konferensi DevOops 2019, yang akan diselenggarakan pada 29-30 Oktober 2019 di St. Petersburg. Tiket dapat dibeli di situs web resmi . Sampai jumpa di DevOops!