Tim Lister - rekan penulis buku
- "Faktor manusia. Proyek dan Tim yang Sukses" (buku aslinya berjudul "Peopleware")
- "Waltzing with the Bears: Mengelola Risiko dalam Proyek Perangkat Lunak"
- “Tergila-gila pada adrenalin dan menjadi zombie karena pola. Pola perilaku tim proyek"
Semua buku ini klasik di bidangnya dan ditulis bersama rekan-rekan di bidangnya . Di Rusia, rekan-rekannya yang paling terkenal - и , yang juga menulis banyak karya terkenal.
Tim mempunyai pengalaman selama 40 tahun dalam pengembangan perangkat lunak; pada tahun 1975 (tidak ada penulis habrapost yang lahir tahun ini), Tim sudah menjadi wakil presiden eksekutif Yourdon Inc. Dia sekarang menghabiskan waktunya sebagai konsultan, mengajar, dan menulis, dengan sesekali berkunjung ke sana konferensi di seluruh dunia.
Kami melakukan wawancara dengan Tim Lister khusus untuk Habr. Dia akan membuka konferensi DevOops 2019, dan kami memiliki banyak pertanyaan, tentang buku dan banyak lagi. Wawancara dilakukan oleh Mikhail Druzhinin dan Oleg Chirukhin dari panitia program konferensi.
Michael: Bisakah Anda menyampaikan beberapa patah kata tentang apa yang Anda lakukan sekarang?
Tim: Saya adalah ketua Atlantic Systems Guild. Ada enam dari kami di Persekutuan, kami menyebut diri kami sebagai kepala sekolah. Tiga di AS dan tiga di Eropa - itulah mengapa Persekutuan ini disebut Atlantik. Kami telah bersama selama bertahun-tahun sehingga Anda tidak dapat menghitungnya. Kita semua memiliki spesialisasi masing-masing. Saya telah bekerja dengan klien selama dekade terakhir atau lebih. Proyek saya tidak hanya mencakup manajemen, tetapi juga pengaturan persyaratan, perencanaan proyek, dan evaluasi. Tampaknya proyek yang dimulai dengan buruk biasanya berakhir dengan buruk. Oleh karena itu, perlu dipastikan bahwa semua kegiatan benar-benar dipikirkan dan dikoordinasikan dengan baik, sehingga ide-ide para pencipta dapat dipadukan. Ada baiknya memikirkan apa yang Anda lakukan dan alasannya. Strategi apa yang digunakan untuk menyelesaikan proyek.
Saya telah menasihati klien dengan berbagai cara selama bertahun-tahun. Contoh yang menarik adalah perusahaan yang membuat robot untuk operasi lutut dan pinggul. Dokter bedah tidak melakukan operasi sepenuhnya secara mandiri, melainkan menggunakan robot. Sejujurnya, keselamatan di sini penting. Namun ketika Anda mencoba mendiskusikan persyaratan dengan orang yang fokus pada pemecahan masalah... Kedengarannya aneh, tetapi di AS ada (Federal Drug Administration), yang melisensikan produk seperti robot ini. Sebelum Anda menjual sesuatu dan menggunakannya pada orang yang masih hidup, Anda perlu mendapatkan lisensi. Salah satu syaratnya adalah menunjukkan kebutuhan Anda, apa saja tesnya, bagaimana Anda mengujinya, apa hasil tesnya. Jika Anda mengubah persyaratan, maka Anda harus melalui proses pengujian besar ini lagi dan lagi. Klien kami berhasil memasukkan desain visual aplikasi ke dalam kebutuhan mereka. Mereka memiliki tangkapan layar secara langsung sebagai bagian dari persyaratan. Kami harus menarik mereka keluar dan menjelaskan bahwa sebagian besar semua program ini tidak tahu apa-apa tentang lutut dan pinggul, semua hal dengan kamera, dll. Kita perlu menulis ulang dokumen persyaratan agar tidak pernah berubah, kecuali beberapa kondisi mendasar yang sangat penting berubah. Jika desain visual tidak memenuhi persyaratan, pembaruan produk akan jauh lebih cepat. Tugas kami adalah menemukan elemen-elemen yang berhubungan dengan operasi pada lutut, pinggul, punggung, memasukkannya ke dalam dokumen terpisah dan mengatakan bahwa ini akan menjadi persyaratan mendasar. Mari kita buat kelompok persyaratan yang terisolasi tentang operasi lutut. Hal ini akan memungkinkan kita membangun serangkaian persyaratan yang lebih stabil. Kami akan berbicara tentang keseluruhan lini produk, dan bukan tentang robot tertentu.
Banyak pekerjaan yang telah dilakukan, namun mereka masih sampai di tempat di mana sebelumnya mereka menghabiskan waktu berminggu-minggu dan berbulan-bulan untuk melakukan pengujian berulang-ulang tanpa arti atau kebutuhan, karena persyaratan mereka yang dijelaskan di atas kertas tidak sesuai dengan persyaratan sebenarnya untuk sistem yang dibangun. FDA selalu memberi tahu mereka: persyaratan Anda telah berubah, sekarang Anda perlu memeriksa semuanya dari awal. Pemeriksaan ulang menyeluruh terhadap keseluruhan produk telah mematikan perusahaan.
Jadi, ada tugas-tugas luar biasa ketika Anda menemukan diri Anda berada di awal sesuatu yang menarik, dan tindakan pertama menentukan aturan permainan selanjutnya. Jika Anda memastikan bahwa aktivitas awal ini mulai berjalan dengan baik baik dari sudut pandang manajerial maupun teknis, ada kemungkinan Anda akan mendapatkan proyek yang hebat. Namun jika bagian ini keluar jalur dan terjadi kesalahan, jika Anda tidak dapat menemukan kesepakatan mendasar... tidak, bukan berarti proyek Anda akan gagal. Namun Anda tidak akan bisa lagi berkata: “Kami melakukannya dengan baik, kami melakukan segalanya dengan sangat efektif.” Ini adalah hal-hal yang saya lakukan ketika berkomunikasi dengan klien.
Michael: Artinya, Anda meluncurkan proyek, melakukan semacam permulaan, dan memeriksa apakah relnya mengarah ke arah yang benar?
Tim: Kami juga mempunyai ide bagaimana menyatukan semua bagian dari teka-teki ini: keterampilan apa yang kami perlukan, kapan tepatnya dibutuhkan, seperti apa inti tim, dan hal-hal mendasar lainnya. Apakah kita memerlukan karyawan penuh waktu atau bisakah kita mempekerjakan seseorang paruh waktu? Perencanaan, manajemen. Pertanyaan seperti: Apa yang paling penting untuk proyek khusus ini? Bagaimana cara mencapainya? Apa yang kita ketahui tentang produk atau proyek ini, apa saja risikonya dan apa yang belum diketahui, bagaimana kita akan menangani semua ini? Tentu saja, saat ini seseorang mulai berteriak “Bagaimana dengan tangkas?!” Oke, Anda semua fleksibel, tapi terus kenapa? Seperti apa sebenarnya proyek tersebut, bagaimana Anda akan melaksanakannya dengan cara yang sesuai dengan proyek tersebut? Anda tidak bisa hanya mengatakan bahwa “pendekatan kami mencakup apa saja, kami adalah tim Scrum!” Ini adalah omong kosong dan omong kosong. Ke mana Anda akan pergi selanjutnya, mengapa harus berhasil, apa gunanya? Saya mengajari klien saya untuk memikirkan semua pertanyaan ini.
19 tahun lincah
Michael: Di Agile, orang sering kali mencoba untuk tidak mendefinisikan apa pun sebelumnya, tetapi membuat keputusan selambat mungkin, dengan mengatakan: kita terlalu besar, saya tidak akan memikirkan arsitektur secara keseluruhan. Saya tidak akan memikirkan banyak hal lainnya; sebaliknya, saya akan memberikan sesuatu yang berhasil kepada pelanggan saat ini.
Tim: Saya pikir metodologi tangkas, dimulai dengan pada tahun 2001, membuka mata industri. Namun di sisi lain, tidak ada yang sempurna. Saya mendukung pengembangan berulang. Iterasi sangat masuk akal di sebagian besar proyek. Namun pertanyaan yang perlu Anda pikirkan adalah: setelah produk keluar dan digunakan, berapa lama produk tersebut akan bertahan? Apakah produk ini akan bertahan enam bulan sebelum digantikan oleh produk lain? Atau apakah ini produk yang akan berfungsi selama bertahun-tahun? Tentu saja, saya tidak akan menyebutkan namanya, tapi... Di New York dan komunitas keuangannya, sistem yang paling mendasar sudah sangat tua. Ini luar biasa. Anda melihatnya dan berpikir, andai saja Anda dapat kembali ke masa lalu, ke tahun 1994, dan memberi tahu para pengembangnya: “Saya datang dari masa depan, dari tahun 2019. Kembangkan saja sistem ini selama Anda membutuhkannya. Jadikan itu bisa diperluas, pikirkan tentang arsitekturnya. Ini kemudian akan ditingkatkan selama lebih dari dua puluh lima tahun. Jika Anda menunda pengembangan sedikit lebih lama, secara keseluruhan tidak akan ada yang menyadarinya!” Saat Anda memperkirakan sesuatu dalam jangka panjang, Anda perlu mempertimbangkan berapa total biayanya. Terkadang arsitektur yang dirancang dengan baik sangat berharga, dan terkadang tidak. Kita perlu melihat sekeliling dan bertanya pada diri sendiri: apakah kita berada dalam situasi yang tepat untuk mengambil keputusan seperti itu?
Jadi gagasan seperti “Kami untuk tangkas, pelanggan sendiri yang akan memberi tahu kami apa yang ingin dia dapatkan” - itu sangat naif. Pelanggan bahkan tidak tahu apa yang mereka inginkan, terlebih lagi mereka tidak tahu apa yang bisa mereka dapatkan. Beberapa orang akan mulai mengutip contoh-contoh sejarah sebagai argumen, saya sudah melihat ini. Namun orang yang sudah mahir secara teknis biasanya tidak mengatakan hal itu. Mereka berkata: “Ini tahun 2019, ini adalah peluang yang kita miliki, dan kita dapat sepenuhnya mengubah cara kita memandang hal-hal ini!” Daripada meniru solusi yang sudah ada, menjadikannya sedikit lebih cantik dan lebih tertata rapi, terkadang Anda perlu keluar dan berkata: “Mari kita temukan kembali apa yang sedang kita coba lakukan di sini!”
Dan menurut saya sebagian besar pelanggan tidak dapat memikirkan masalah ini seperti itu. Mereka hanya melihat apa yang sudah mereka miliki, itu saja. Setelah itu mereka datang dengan permintaan seperti “mari kita buat ini lebih sederhana,” atau apa pun yang biasa mereka katakan. Tapi kami bukan pramusaji atau pramusaji, jadi kami bisa menerima pesanan betapapun bodohnya pesanan itu, lalu memanggangnya di dapur. Kami adalah pemandu mereka. Kita harus membuka mata mereka dan berkata: hei, kita punya peluang baru di sini! Sadarkah Anda bahwa kami benar-benar dapat mengubah cara menjalankan bagian bisnis Anda ini? Salah satu masalah dengan Agile adalah menghilangkan kesadaran akan apa itu peluang, apa masalahnya, apa yang perlu kita lakukan, teknologi apa yang paling cocok untuk situasi tertentu.
Mungkin saya terlalu skeptis di sini: ada banyak hal menakjubkan yang terjadi di komunitas agile. Tapi saya punya masalah dengan kenyataan bahwa alih-alih mendefinisikan sebuah proyek, orang-orang mulai angkat tangan. Saya ingin bertanya di sini - apa yang kita lakukan, bagaimana kita akan melakukannya? Dan entah bagaimana secara ajaib ternyata klien selalu tahu lebih baik dari siapa pun. Tetapi klien mengetahui yang terbaik hanya ketika dia memilih dari hal-hal yang sudah dibangun oleh seseorang. Jika saya ingin membeli mobil dan mengetahui besarnya anggaran keluarga saya, maka saya akan segera memilih mobil yang sesuai dengan gaya hidup saya. Di sini saya tahu segalanya lebih baik dari siapa pun! Namun harap dicatat bahwa seseorang telah membuat mobilnya. Saya tidak tahu cara menciptakan mobil baru, saya bukan ahlinya. Saat kita membuat produk custom atau khusus, suara pelanggan harus diperhitungkan, tapi ini bukan lagi satu-satunya suara.
Oleg: Anda menyebutkan Agile Manifesto. Apakah kita perlu memperbarui atau merevisinya dengan mempertimbangkan pemahaman modern tentang masalah ini?
Tim: Saya tidak akan menyentuhnya. Saya pikir itu adalah dokumen sejarah yang hebat. Maksudku, dia adalah dia apa adanya. Dia menginjak usia 19 tahun, dia sudah tua, namun pada masanya dia melakukan revolusi. Apa yang dia lakukan dengan baik adalah dia memicu reaksi dan orang-orang mulai berbisik-bisik tentang dia. Kemungkinan besar Anda belum bekerja di industri ini pada tahun 2001, tetapi semua orang bekerja sesuai proses. Institut Rekayasa Perangkat Lunak, lima tingkat model kelengkapan perangkat lunak (CMMI). Saya tidak tahu apakah legenda kuno seperti itu memberi tahu Anda sesuatu, tapi kemudian itu adalah sebuah terobosan. Pada awalnya, orang-orang percaya bahwa jika prosesnya diatur dengan benar, maka masalahnya akan hilang dengan sendirinya. Dan kemudian Manifesto muncul dan berkata: “Tidak, tidak, tidak – kita akan didasarkan pada manusia, bukan proses.” Kami adalah ahli pengembangan perangkat lunak. Kami memahami bahwa proses yang ideal adalah sebuah fatamorgana, namun hal itu tidak terjadi. Ada terlalu banyak keanehan dalam proyek, gagasan tentang satu proses sempurna untuk semua proyek tidak masuk akal. Masalahnya terlalu rumit untuk menyatakan bahwa hanya ada satu solusi untuk semuanya (halo, nirwana).
Saya tidak berasumsi untuk melihat masa depan, namun menurut saya orang-orang kini sudah mulai lebih memikirkan proyek. Saya pikir Agile Manifesto sangat baik dalam melompat dan berkata, “Hei! Anda berada di sebuah kapal, dan Anda sendiri yang mengemudikan kapal ini. Anda harus membuat keputusan - kami tidak akan menyarankan resep universal untuk semua situasi. Anda adalah awak kapal, dan jika Anda cukup baik, Anda dapat menemukan jalan menuju tujuan. Ada kapal-kapal lain sebelum Anda, dan akan ada kapal-kapal lain setelah Anda, namun tetap saja, dalam arti tertentu, perjalanan Anda unik.” Sesuatu seperti itu! Itu adalah cara berpikir. Bagi saya, tidak ada yang baru di bawah matahari, orang telah berlayar sebelumnya dan akan berlayar lagi, tetapi bagi Anda ini adalah perjalanan utama Anda, dan saya tidak akan memberi tahu Anda apa yang sebenarnya akan terjadi pada Anda. Anda harus memiliki keterampilan kerja yang terkoordinasi dalam tim, dan jika Anda benar-benar memilikinya, semuanya akan berjalan lancar dan Anda akan mencapai apa yang Anda inginkan.
Peopleware: 30 tahun kemudian
Oleg: Apakah Peopleware merupakan sebuah revolusi dan juga Manifesto?
Tim: Peopleware... Tom dan saya menulis buku ini, tetapi kami tidak mengira akan terjadi seperti ini. Entah bagaimana hal itu selaras dengan ide banyak orang. Ini adalah buku pertama yang mengatakan: pengembangan perangkat lunak adalah aktivitas yang sangat melibatkan manusia. Terlepas dari sifat teknis kami, kami juga merupakan komunitas orang-orang yang membangun sesuatu yang besar, bahkan sangat besar, sangat kompleks. Tidak ada yang bisa menciptakan hal seperti itu sendirian, bukan? Sehingga gagasan “tim” menjadi sangat penting. Dan tidak hanya dari sudut pandang manajemen, tetapi juga dari sudut pandang orang-orang teknis yang bersatu untuk memecahkan masalah mendalam yang sangat kompleks dengan banyak hal yang tidak diketahui. Bagi saya pribadi, ini merupakan ujian kecerdasan yang sangat besar sepanjang karier saya. Dan di sini Anda harus bisa mengatakan: ya, masalah ini lebih dari yang bisa saya tangani sendiri, tapi bersama-sama kita bisa menemukan solusi elegan yang bisa kita banggakan. Dan menurut saya, gagasan inilah yang paling bergema. Gagasan bahwa kita bekerja sebagian waktu sendiri, sebagian waktu sebagai bagian dari kelompok, dan sering kali keputusan dibuat oleh kelompok. Pemecahan masalah kelompok dengan cepat menjadi fitur penting dalam proyek yang kompleks.
Terlepas dari kenyataan bahwa Tim telah memberikan banyak ceramah, sangat sedikit yang diposting di YouTube. Anda dapat melihat laporan “The Return of Peopleware” dari tahun 2007. Kualitasnya, tentu saja, masih menyisakan banyak hal yang diinginkan.
Michael: Apakah ada yang berubah dalam 30 tahun terakhir sejak buku tersebut diterbitkan?
Tim: Anda dapat melihat ini dari berbagai sudut. Secara sosiologis... pada suatu ketika, di masa yang lebih sederhana, Anda dan tim Anda duduk di kantor yang sama. Anda bisa dekat setiap hari, minum kopi bersama, dan berdiskusi tentang pekerjaan. Yang benar-benar berubah adalah tim kini dapat didistribusikan secara geografis, di berbagai negara dan zona waktu, namun mereka masih menangani masalah yang sama, dan hal ini menambah kompleksitas baru. Ini mungkin terdengar kuno, namun tidak ada yang menandingi komunikasi tatap muka di mana Anda semua bersama-sama, bekerja bersama, dan Anda dapat menghampiri rekan kerja dan berkata, lihat apa yang saya temukan, bagaimana Anda menyukainya? Percakapan tatap muka memberikan cara cepat untuk beralih ke komunikasi informal, dan menurut saya para penggemar tangkas juga akan menyukainya. Dan saya juga khawatir karena pada kenyataannya dunia ini menjadi sangat kecil, dan sekarang semuanya ditutupi oleh tim-tim yang terdistribusi, dan semuanya sangat kompleks.
Kita semua hidup di DevOps
Michael: Bahkan dari sudut pandang panitia program konferensi, kami memiliki orang-orang di California, di New York, Eropa, Rusia... belum ada seorang pun di Singapura. Perbedaan geografi cukup besar, dan orang-orang mulai menyebar lebih jauh lagi. Jika kita berbicara tentang pengembangan, bisakah Anda memberi tahu kami lebih banyak tentang devops dan mendobrak hambatan antar tim? Ada konsep bahwa setiap orang sedang duduk di bunkernya masing-masing, dan sekarang bunker tersebut runtuh, apa pendapat Anda tentang analogi ini?
Tim: Menurut saya, mengingat terobosan teknologi terkini, devops sangatlah penting. Sebelumnya, Anda memiliki tim pengembang dan administrator, mereka bekerja, bekerja, bekerja, dan pada titik tertentu muncul sesuatu yang dapat Anda gunakan untuk mendatangi admin dan meluncurkannya untuk produksi. Dan di sini percakapan tentang bunker dimulai, karena admin adalah semacam sekutu, setidaknya bukan musuh, tetapi Anda berbicara dengan mereka hanya ketika semuanya sudah siap untuk diproduksi. Apakah Anda mendatangi mereka dengan sesuatu dan berkata: lihat aplikasi apa yang kami miliki, tetapi bisakah Anda meluncurkan aplikasi ini? Dan sekarang seluruh konsep penyampaian telah berubah menjadi lebih baik. Maksud saya, ada gagasan bahwa Anda dapat melakukan perubahan dengan cepat. Kami dapat memperbarui produk dengan cepat. Saya selalu tersenyum ketika Firefox di laptop saya muncul dan berkata, hei, kami telah memperbarui Firefox Anda di latar belakang, dan segera setelah Anda punya waktu sebentar, maukah Anda mengeklik di sini dan kami akan memberi Anda rilis terbaru. Dan saya seperti, "Oh ya, sayang!" Saat saya sedang tidur, mereka berupaya mengirimkan rilis baru langsung di komputer saya. Ini luar biasa, luar biasa.
Namun inilah kesulitannya: Anda memiliki fitur ini dalam memperbarui perangkat lunak, namun mengintegrasikan orang jauh lebih sulit. Apa yang ingin saya sampaikan pada keynote DevOops adalah bahwa kami sekarang memiliki lebih banyak pemain daripada yang pernah kami miliki. Jika Anda hanya memikirkan semua orang yang terlibat hanya dalam satu tim…. Anda menganggapnya sebagai sebuah tim, dan ini lebih dari sekadar tim pemrogram. Ini adalah penguji, manajer proyek, dan banyak orang lainnya. Dan setiap orang mempunyai pandangannya sendiri terhadap dunia. Manajer produk sangat berbeda dari manajer proyek. Admin punya tugasnya masing-masing. Menjadi masalah yang agak sulit untuk mengkoordinasikan seluruh peserta agar tetap waspada terhadap apa yang terjadi dan tidak menjadi gila. Penting untuk memisahkan tugas kelompok dan tugas yang berlaku untuk semua orang. Ini adalah tugas yang sangat sulit. Di sisi lain, menurut saya semuanya jauh lebih baik dibandingkan beberapa tahun lalu. Inilah jalan di mana orang tumbuh dan belajar berperilaku benar. Ketika Anda melakukan integrasi, Anda memahami bahwa tidak boleh ada pengembangan bawah tanah, sehingga pada saat-saat terakhir perangkat lunak tidak keluar seperti jack-in-the-box: seperti, lihat apa yang kami lakukan di sini! Idenya adalah Anda akan mampu melakukan integrasi dan pengembangan, dan pada akhirnya Anda akan meluncurkannya dengan cara yang rapi dan berulang. Semua ini sangat berarti bagi saya. Hal ini memungkinkan terciptanya nilai lebih bagi pengguna sistem dan klien Anda.
Michael: Seluruh gagasan devops adalah untuk memberikan perkembangan yang berarti sedini mungkin. Saya melihat bahwa dunia sudah mulai semakin cepat. Bagaimana cara beradaptasi dengan akselerasi seperti itu? Sepuluh tahun yang lalu hal ini tidak ada!
Tim: Tentu saja, semua orang menginginkan fungsionalitas yang lebih banyak. Tidak perlu bergerak, cukup tumpuk lebih banyak. Kadang-kadang Anda bahkan harus memperlambat pembaruan tambahan berikutnya untuk memberikan sesuatu yang berguna - dan itu sepenuhnya normal.
Gagasan bahwa Anda perlu lari, lari, lari bukanlah yang terbaik. Tidak mungkin ada orang yang ingin menjalani hidupnya seperti itu. Saya ingin ritme penyampaiannya menentukan ritme proyek itu sendiri. Jika Anda hanya menghasilkan aliran hal-hal kecil yang relatif tidak berarti, semuanya tidak ada artinya. Daripada mencoba merilis sesuatu sedini mungkin tanpa berpikir panjang, hal yang perlu didiskusikan dengan pengembang utama serta manajer produk dan proyek adalah strategi. Apakah ini masuk akal?
Pola dan antipola
Oleg: Anda biasanya berbicara tentang pola dan antipola, dan inilah perbedaan antara hidup dan matinya proyek. Dan sekarang, devosan menyerbu kehidupan kita. Apakah ia mempunyai pola dan anti-pola sendiri yang dapat menghentikan proyek saat itu juga?
Tim: Pola dan anti pola terjadi setiap saat. Sesuatu untuk dibicarakan. Nah, ada hal yang kita sebut "benda berkilau". Orang-orang sangat menyukai teknologi baru. Mereka hanya terpesona oleh kilauan segala sesuatu yang terlihat keren dan bergaya, dan mereka berhenti bertanya: apakah itu perlu? Apa yang akan kita capai? Apakah hal ini dapat diandalkan, apakah masuk akal? Saya sering melihat orang-orang yang memiliki teknologi mutakhir. Mereka terhipnotis dengan apa yang terjadi di dunia. Tetapi jika Anda melihat lebih dekat hal-hal bermanfaat apa yang mereka lakukan, seringkali tidak ada yang berguna!
Kami baru saja berdiskusi dengan rekan-rekan kami bahwa tahun ini adalah tahun peringatan, lima puluh tahun sejak manusia mendarat di bulan. Ini terjadi pada tahun 1969. Teknologi yang membantu manusia sampai ke sana bukanlah teknologi tahun 1969, melainkan tahun 1960 atau 62, karena NASA hanya ingin menggunakan teknologi yang memiliki bukti keandalan yang baik. Jadi Anda melihatnya dan memahami - ya, dan itu benar! Sekarang, tidak, tidak, tetapi Anda mendapat masalah dengan teknologi hanya karena segala sesuatunya didorong terlalu keras, dijual dengan segala cara. Orang-orang berteriak dari mana-mana: “Lihat, benda yang luar biasa ini, ini adalah benda terbaru, benda terindah di dunia, cocok untuk semua orang!” Yasudahlah... biasanya semua ini ternyata hanya umpan, lalu harus dibuang semua. Mungkin itu semua karena saya sudah tua dan melihat hal-hal seperti itu dengan sangat skeptis, ketika orang-orang kehabisan tenaga dan mengatakan bahwa mereka telah menemukan Satu-Satunya, Cara Paling Benar untuk Menciptakan Teknologi Terbaik. Pada saat ini, sebuah suara muncul di dalam diriku yang berkata: “Sungguh kacau!”
Michael: Memangnya, seberapa sering kita mendengar tentang solusi jitu berikutnya?
Tim: Tepat sekali, dan ini adalah hal yang biasa! Misalnya... sepertinya ini sudah menjadi lelucon di seluruh dunia, namun di sini orang sering membicarakan teknologi blockchain. Dan hal tersebut sebenarnya masuk akal dalam situasi tertentu! Ketika Anda benar-benar membutuhkan bukti kejadian yang dapat diandalkan, bahwa sistem berfungsi dan tidak ada yang menipu kita, ketika Anda memiliki masalah keamanan dan semua hal tercampur menjadi satu - blockchain masuk akal. Tapi ketika mereka mengatakan bahwa Blockchain sekarang akan menyapu seluruh dunia, menyapu bersih semua yang dilewatinya? Bermimpilah lebih banyak! Ini adalah teknologi yang sangat mahal dan kompleks. Secara teknis rumit dan memakan waktu. Termasuk murni secara algoritmik, setiap kali Anda perlu menghitung ulang matematika, dengan perubahan sekecil apa pun... dan ini adalah ide bagus - tetapi hanya untuk kasus tertentu. Seluruh hidup dan karier saya adalah tentang hal ini: ide-ide menarik dalam situasi yang sangat spesifik. Sangat penting untuk memahami dengan tepat situasi Anda.
Michael: Ya, “pertanyaan utama tentang kehidupan, alam semesta, dan segalanya”: apakah teknologi atau pendekatan ini cocok untuk situasi Anda atau tidak?
Tim: Pertanyaan ini sudah dapat didiskusikan dengan kelompok teknologi. Mungkin bahkan mendatangkan konsultan. Lihatlah proyeknya dan pahami - akankah kita melakukan sesuatu yang benar dan bermanfaat, lebih baik dari sebelumnya? Mungkin cocok, mungkin juga tidak. Namun yang paling penting, jangan membuat keputusan seperti itu secara default, hanya karena seseorang berkata: “Kami sangat membutuhkan blockchain! Saya baru saja membaca tentang dia di majalah di pesawat!” Dengan serius? Itu bahkan tidak lucu.
“Insinyur devops” yang mistis
Oleg: Sekarang semua orang menerapkan devops. Seseorang membaca tentang devops di Internet, dan besok lowongan lain muncul di situs perekrutan. "insinyur pengembang". Di sini saya ingin menarik perhatian Anda: menurut Anda apakah istilah “insinyur devops” ini memiliki hak untuk hidup? Ada pendapat bahwa devops adalah budaya, dan ada sesuatu yang tidak masuk akal di sini.
Tim: Biasa saja. Biarkan mereka segera memberikan penjelasan tentang istilah ini. Sesuatu yang membuatnya unik. Sampai mereka membuktikan bahwa ada kombinasi keterampilan unik di balik lowongan seperti ini, saya tidak akan membelinya! Maksud saya, kita punya jabatan, "insinyur devops", jabatan yang menarik, ya, selanjutnya apa? Judul pekerjaan umumnya merupakan hal yang sangat menarik. Katakanlah “pengembang” – sebenarnya apa itu? Organisasi yang berbeda memiliki arti yang sangat berbeda. Di beberapa perusahaan, pemrogram berkualitas tinggi menulis tes yang lebih masuk akal dibandingkan tes yang ditulis oleh penguji profesional khusus di perusahaan lain. Jadi, apakah mereka sekarang programmer atau penguji?
Ya, kita punya jabatan, tapi jika Anda bertanya cukup lama, pada akhirnya ternyata kita semua adalah pemecah masalah. Kami adalah pencari solusi, dan beberapa memiliki keterampilan teknis dan beberapa memiliki keterampilan yang berbeda. Jika Anda tinggal di lingkungan di mana DevOps telah melakukan penetrasi, Anda terlibat dalam integrasi pengembangan dan administrasi, dan aktivitas ini memiliki beberapa tujuan yang cukup penting. Namun jika ditanya apa sebenarnya yang Anda lakukan dan apa tanggung jawab Anda, ternyata semua itu sudah dilakukan orang sejak dahulu kala. "Saya bertanggung jawab atas arsitektur", "Saya bertanggung jawab atas database" dan seterusnya, apa pun yang Anda lihat - semua ini terjadi sebelum "devops".
Ketika seseorang memberi tahu saya jabatannya, saya tidak terlalu mendengarkan. Lebih baik biarkan dia memberi tahu Anda apa sebenarnya tanggung jawabnya, ini akan memungkinkan kita memahami masalahnya dengan lebih baik. Contoh favorit saya adalah ketika seseorang mengaku sebagai “manajer proyek”. Apa? Itu tidak berarti apa-apa, saya masih tidak tahu apa yang Anda lakukan. Seorang manajer proyek dapat menjadi seorang pengembang, pemimpin tim yang terdiri dari empat orang, menulis kode, melakukan pekerjaan, yang telah menjadi pemimpin tim, yang orang-orang sendiri akui sebagai pemimpin. Dan juga, seorang manajer proyek bisa menjadi seorang manajer yang mengelola enam ratus orang dalam sebuah proyek, mengelola manajer-manajer lainnya, bertanggung jawab menyusun jadwal dan merencanakan anggaran, itu saja. Ini adalah dua dunia yang sangat berbeda! Tapi jabatan mereka terdengar sama.
Mari kita ubah hal ini sedikit berbeda. Apa yang benar-benar Anda kuasai, punya banyak pengalaman, apakah Anda punya bakat? Tanggung jawab apa yang akan Anda ambil karena Anda merasa mampu menangani tugas tersebut? Dan di sini seseorang akan segera mulai menyangkal: tidak, tidak, tidak, saya sama sekali tidak punya keinginan untuk berurusan dengan sumber daya proyek, itu bukan urusan saya, saya seorang pria teknis dan saya memahami kegunaan dan antarmuka pengguna, saya tidak ingin mengatur pasukan manusia sama sekali, biarkan aku pergi bekerja.
Dan omong-omong, saya adalah pendukung besar pendekatan di mana pemisahan keterampilan semacam ini berfungsi dengan baik. Dimana para teknisi dapat mengembangkan karirnya sejauh yang mereka inginkan. Namun, saya masih melihat organisasi di mana para teknisi mengeluh: Saya harus terjun ke manajemen proyek karena itulah satu-satunya cara di perusahaan ini. Terkadang hal ini membawa akibat yang buruk. Teknisi terbaik bukanlah manajer yang baik sama sekali, dan manajer terbaik tidak bisa menangani teknologi. Jujur saja tentang hal ini.
Saya melihat banyak permintaan untuk ini sekarang. Jika Anda seorang teknisi, perusahaan Anda dapat membantu Anda, namun terlepas dari kebutuhan Anda, Anda harus benar-benar menemukan jalur karier Anda sendiri karena teknologi terus berubah dan Anda perlu mengubah diri Anda seiring dengan itu! Hanya dalam dua puluh tahun, teknologi dapat berubah setidaknya lima kali lipat. Teknologi adalah hal yang aneh...
"Pakar dalam Segalanya"
Michael: Bagaimana manusia dapat menghadapi perubahan teknologi yang begitu cepat? Kompleksitasnya semakin bertambah, jumlah mereka semakin bertambah, jumlah komunikasi antar manusia juga semakin meningkat, dan ternyata Anda tidak bisa menjadi “ahli dalam segala hal”.
Tim: Benar! Jika Anda bekerja di bidang teknologi, ya, Anda pasti perlu memilih sesuatu yang spesifik dan mendalaminya. Beberapa teknologi yang menurut organisasi Anda berguna (dan mungkin akan benar-benar berguna). Dan jika Anda tidak lagi tertarik padanya - saya tidak akan pernah percaya bahwa saya akan mengatakan ini - mungkin Anda harus pindah ke organisasi lain yang teknologinya lebih menarik atau lebih nyaman untuk dipelajari.
Namun secara umum, ya, Anda benar. Teknologi berkembang ke segala arah sekaligus; tidak ada yang bisa mengatakan “Saya adalah ahli teknologi dalam semua teknologi yang ada.” Di sisi lain, ada orang-orang spons yang benar-benar menyerap pengetahuan teknologi dan tergila-gila padanya. Saya telah melihat beberapa orang seperti itu, mereka benar-benar bernafas dan menjalaninya, berbicara dengan mereka berguna dan menarik. Mereka tidak hanya mempelajari apa yang terjadi di dalam organisasi, tetapi secara umum, mereka membicarakannya, mereka juga ahli teknologi yang sangat keren, mereka sangat sadar dan memiliki tujuan. Mereka hanya berusaha untuk tetap berada di puncak gelombang, apapun pekerjaan utama mereka, karena passion mereka adalah pergerakan Teknologi, promosi teknologi. Jika Anda tiba-tiba bertemu dengan orang seperti itu, sebaiknya Anda pergi makan siang bersamanya dan mendiskusikan berbagai hal keren saat makan siang. Saya pikir organisasi mana pun membutuhkan setidaknya beberapa orang seperti itu.
Risiko dan ketidakpastian
Michael: Insinyur yang terhormat, ya. Mari kita bahas manajemen risiko selagi kita punya waktu. Kami memulai wawancara ini dengan diskusi tentang perangkat lunak medis, di mana kesalahan dapat mengakibatkan konsekuensi yang mengerikan. Kemudian kami berbicara tentang Program Bulan, yang kerugian akibat kesalahannya mencapai jutaan dolar, dan mungkin beberapa nyawa manusia. Namun sekarang saya melihat pergerakan sebaliknya di industri ini, masyarakat tidak memikirkan risiko, tidak mencoba memprediksinya, bahkan tidak mengamatinya.
Oleg: Bergerak cepat dan hancurkan semuanya!
Michael: Ya, bergerak cepat, hancurkan barang, semakin banyak barang, sampai mati karena sesuatu. Dari sudut pandang Anda, bagaimana seharusnya pendekatan rata-rata pengembang dalam mempelajari manajemen risiko saat ini?
Tim: Mari kita menarik garis batas antara dua hal: risiko dan ketidakpastian. Ini adalah hal yang berbeda. Ketidakpastian terjadi ketika Anda tidak memiliki cukup data pada suatu waktu tertentu untuk sampai pada jawaban yang pasti. Misalnya, pada tahap awal suatu proyek, jika seseorang bertanya kepada Anda “kapan Anda akan menyelesaikan pekerjaan tersebut”, jika Anda adalah orang yang cukup jujur, Anda akan menjawab, “Saya tidak tahu.” Anda hanya tidak tahu, dan tidak apa-apa. Anda belum mempelajari soal dan belum mengenal tim, belum mengetahui skill mereka, dan sebagainya. Ini adalah ketidakpastian.
Risiko muncul ketika potensi permasalahan sudah dapat diidentifikasi. Hal semacam ini bisa terjadi, kemungkinannya lebih besar dari nol, tetapi kurang dari seratus persen, di antara keduanya. Karenanya, apa pun bisa terjadi, mulai dari penundaan dan pekerjaan yang tidak perlu, bahkan hingga berakibat fatal bagi proyek tersebut. Hasilnya, kalau dibilang - kawan, ayo lipat payung dan tinggalkan pantai, kita tidak akan pernah selesai, semuanya sudah berakhir, titik. Kami berasumsi bahwa hal ini akan berhasil, tetapi tidak berhasil sama sekali, inilah waktunya untuk berhenti. Inilah situasinya.
Seringkali, masalah paling mudah diselesaikan ketika masalah tersebut sudah muncul, ketika masalah sedang terjadi saat ini. Namun ketika sebuah masalah ada di hadapan Anda, Anda tidak melakukan manajemen risiko—Anda melakukan pemecahan masalah, manajemen krisis. Jika Anda seorang pengembang atau manajer utama, Anda pasti bertanya-tanya apa yang bisa terjadi yang dapat menyebabkan penundaan, waktu terbuang, biaya yang tidak perlu, atau gagalnya keseluruhan proyek? Apa yang akan membuat kita berhenti dan memulai kembali? Ketika semua hal ini berhasil, apa yang akan kita lakukan terhadapnya? Ada jawaban sederhana yang berlaku untuk sebagian besar situasi: jangan lari dari risiko, atasi risiko tersebut. Lihat bagaimana Anda dapat menyelesaikan situasi yang berisiko, menguranginya menjadi tidak ada, mengubahnya dari masalah menjadi masalah lain. Daripada mengatakan: baiklah, kami akan menyelesaikan masalah yang muncul.
Ketidakpastian dan risiko harus menjadi prioritas utama dalam segala hal yang Anda hadapi. Anda dapat membuat rencana proyek, melihat risiko-risiko kritis tertentu sebelumnya dan berkata: kita perlu mengatasinya sekarang, karena jika ada yang salah, tidak ada hal lain yang menjadi masalah. Anda tidak perlu khawatir dengan keindahan taplak meja di atas meja jika tidak jelas apakah Anda bisa memasak makan malam. Pertama, Anda perlu mengidentifikasi semua risiko menyiapkan makan malam yang lezat, mengatasinya, dan baru kemudian memikirkan semua hal lain yang tidak menimbulkan ancaman nyata.
Sekali lagi, apa yang membuat proyek Anda unik? Mari kita lihat apa yang bisa membuat proyek kita gagal. Apa yang dapat kita lakukan untuk meminimalkan kemungkinan terjadinya hal ini? Biasanya Anda tidak bisa begitu saja menetralisirnya 100% dan menyatakan dengan hati nurani yang bersih: “Sudah, ini bukan masalah lagi, risikonya sudah teratasi!” Bagi saya ini adalah tanda perilaku orang dewasa. Inilah perbedaan antara anak-anak dan orang dewasa - anak-anak berpikir bahwa mereka abadi, tidak ada yang salah, semuanya akan baik-baik saja! Pada saat yang sama, orang dewasa mengamati bagaimana anak-anak berusia tiga tahun melompat-lompat di taman bermain, mengikuti gerakan dengan mata mereka dan berkata pada diri mereka sendiri: “ooh-ooh, ooh-ooh.” Saya berdiri di dekatnya dan bersiap untuk menangkap ketika anak itu jatuh.
Di sisi lain, alasan saya sangat menyukai bisnis ini adalah karena berisiko. Kami melakukan banyak hal, dan hal itu berisiko. Mereka membutuhkan pendekatan orang dewasa. Antusiasme saja tidak akan menyelesaikan masalah Anda!
Pemikiran rekayasa orang dewasa
Michael: Teladan kepada anak-anak itu baik. Jika saya seorang insinyur biasa, maka saya senang menjadi seorang anak kecil. Namun bagaimana Anda beralih ke pemikiran yang lebih dewasa?
Tim: Salah satu ide yang dapat diterapkan dengan baik baik oleh pemula maupun pengembang mapan adalah konsep konteks. Apa yang kita lakukan, apa yang akan kita capai. Apa yang sebenarnya penting dalam proyek ini? Tidak peduli siapa Anda dalam proyek ini, apakah Anda seorang pekerja magang atau kepala arsitek, semua orang memerlukan konteks. Kita perlu membuat semua orang berpikir dalam skala yang lebih besar daripada karya mereka sendiri. “Saya membuat karya saya, dan selama karya saya berhasil, saya senang.” Tidak dan tidak lagi. Selalu bermanfaat (tanpa bersikap kasar!) untuk mengingatkan orang tentang konteks di mana mereka bekerja. Apa yang kita semua coba capai bersama. Gagasan bahwa Anda bisa menjadi seorang anak kecil selama semuanya baik-baik saja dengan proyek Anda - tolong, jangan lakukan itu. Jika kita melewati garis finis, kita hanya akan melewatinya bersama-sama. Anda tidak sendiri, kita semua bersama. Jika semua orang dalam proyek, baik tua maupun muda, mulai berbicara tentang apa sebenarnya yang penting bagi proyek tersebut, mengapa perusahaan menginvestasikan uang pada apa yang ingin kita capai... kebanyakan dari mereka akan merasa jauh lebih baik karena mereka akan melihat bagaimana pekerjaan mereka berkorelasi dengan pekerjaan orang lain. Di satu sisi, saya memahami bagian yang menjadi tanggung jawab saya secara pribadi. Tapi untuk menyelesaikan pekerjaan ini kami membutuhkan semua orang lain juga. Dan jika Anda benar-benar merasa sudah selesai, kami selalu memiliki pekerjaan yang harus diselesaikan dalam proyek ini!
Oleg: Secara relatif, jika Anda bekerja berdasarkan Kanban, ketika Anda mengalami hambatan dalam beberapa pengujian, Anda dapat menghentikan apa yang Anda lakukan di sana (misalnya, pemrograman) dan membantu para penguji.
Tim: Tepat. Menurut saya teknisi terbaik, jika Anda perhatikan lebih dekat, mereka adalah manajer bagi diri mereka sendiri. Bagaimana saya bisa merumuskan ini...
Oleg: Hidup Anda adalah proyek Anda, yang Anda kelola.
Tim: Tepat! Maksud saya, Anda mengambil tanggung jawab, Anda memahami masalahnya, dan Anda berhubungan dengan orang-orang ketika Anda melihat bahwa keputusan Anda dapat memengaruhi pekerjaan mereka, hal-hal seperti itu. Ini bukan tentang hanya duduk di meja Anda, melakukan pekerjaan Anda, dan bahkan tidak menyadari apa yang terjadi di sekitar Anda. Tidak tidak tidak. Ngomong-ngomong, salah satu hal terbaik tentang Agile adalah mereka mengusulkan sprint pendek, karena dengan cara ini keadaan semua peserta dapat diamati dengan jelas, mereka dapat melihat semuanya bersama-sama. Kami berbicara tentang satu sama lain setiap hari.
Bagaimana cara masuk ke dalam manajemen risiko
Oleg: Apakah ada struktur pengetahuan formal di bidang ini? Misalnya, saya seorang pengembang Java dan ingin memahami manajemen risiko tanpa menjadi manajer proyek sejati melalui pendidikan. Saya mungkin akan membaca "Berapa Biaya Proyek Perangkat Lunak" karya McConnell terlebih dahulu, lalu apa? Apa langkah pertama?
Tim: Yang pertama adalah mulai berkomunikasi dengan orang-orang dalam proyek tersebut. Hal ini memberikan perbaikan langsung dalam budaya komunikasi dengan rekan kerja. Kita harus memulai dengan membuka semuanya secara default, bukan menyembunyikannya. Katakan: ini adalah hal-hal yang mengganggu saya, ini adalah hal-hal yang membuat saya terjaga di malam hari, saya terbangun di malam hari hari ini dan berkata: Ya Tuhan, saya perlu memikirkan hal ini! Apakah orang lain melihat hal yang sama? Sebagai kelompok, haruskah kita menanggapi potensi masalah ini? Anda harus dapat mendukung diskusi tentang topik ini. Tidak ada formula yang telah disiapkan sebelumnya untuk digunakan. Ini bukan tentang membuat hamburger, ini tentang manusia. “Membuat burger keju, menjual burger keju” bukanlah hal yang kami sukai, dan itulah mengapa saya sangat menyukai pekerjaan ini. Saya suka jika semua yang biasa dilakukan manajer kini menjadi milik tim.
Oleg: Anda telah berbicara di buku dan wawancara tentang bagaimana orang lebih peduli pada kebahagiaan daripada angka pada grafik. Di sisi lain, ketika Anda memberi tahu tim: kami pindah ke devops, dan sekarang programmer harus terus berkomunikasi, ini mungkin jauh di luar zona nyamannya. Dan pada saat ini, katakanlah, dia mungkin merasa sangat tidak bahagia. Apa yang harus dilakukan dalam situasi ini?
Tim: Saya tidak yakin apa yang harus saya lakukan. Jika seorang pengembang terlalu terisolasi, mereka tidak mengerti mengapa pekerjaan tersebut dilakukan, mereka hanya melihat bagian pekerjaan mereka, dan mereka perlu masuk ke dalam apa yang saya sebut "konteks". Dia perlu mencari tahu bagaimana semuanya terhubung satu sama lain. Dan tentu saja yang saya maksud bukan presentasi formal atau semacamnya. Saya berbicara tentang fakta bahwa Anda perlu berkomunikasi dengan rekan kerja tentang pekerjaan secara keseluruhan, dan bukan hanya tentang bagian yang menjadi tanggung jawab Anda. Di sinilah Anda dapat mulai mendiskusikan ide-ide, kesepakatan bersama agar pekerjaan Anda selaras, dan cara mengatasi masalah bersama.
Untuk membantu mereka beradaptasi, mereka sering kali ingin mengirimkan teknisi ke pelatihan, dan mereka mendiskusikan pelatihan. Seorang teman saya suka mengatakan bahwa pelatihan itu untuk anjing. Ada pelatihan untuk orang-orang. Salah satu hal terbaik tentang belajar sebagai pengembang adalah berinteraksi dengan rekan-rekan Anda. Jika seseorang benar-benar ahli dalam suatu hal, Anda harus memperhatikan mereka bekerja atau berbicara dengannya tentang pekerjaannya atau sesuatu. Beberapa Kent Beck konvensional terus-menerus berbicara tentang pemrograman ekstrem. Ini lucu karena XP adalah ide yang sederhana, namun menyebabkan banyak masalah. Bagi sebagian orang, melakukan XP seperti dipaksa telanjang di depan teman. Mereka akan melihat apa yang saya lakukan! Mereka adalah rekan-rekan saya, mereka tidak hanya akan melihat, tetapi juga memahami! Sangat buruk! Beberapa orang mulai merasa sangat gugup. Namun ketika Anda menyadari bahwa ini adalah cara terbaik untuk belajar, segalanya berubah. Anda bekerja erat dengan orang-orang, dan beberapa orang memahami topik tersebut jauh lebih baik daripada Anda.
Michael: Namun semua ini memaksa Anda untuk keluar dari zona nyaman. Sebagai seorang insinyur, Anda harus keluar dari zona nyaman dan berkomunikasi. Sebagai pemecah masalah, Anda harus terus-menerus menempatkan diri Anda pada posisi lemah dan memikirkan apa yang salah. Jenis pekerjaan ini pada dasarnya dirancang untuk menimbulkan gangguan. Anda secara sadar menempatkan diri Anda dalam situasi stres. Biasanya orang lari darinya, orang suka jadi anak bahagia.
Tim: Apa yang bisa dilakukan, Anda bisa keluar dan berkata secara terbuka: “Semuanya baik-baik saja, saya bisa mengatasinya! Saya bukan satu-satunya yang merasa tidak nyaman. Mari kita bahas berbagai hal yang tidak nyaman, bersama-sama, sebagai sebuah tim!” Ini adalah masalah kita bersama, kita harus mengatasinya, Anda tahu? Saya pikir pengembang jenius yang istimewa itu seperti mamut, mereka menghilang. Dan signifikansinya sangat terbatas. Jika Anda tidak bisa berkomunikasi, Anda tidak bisa berpartisipasi dengan baik. Oleh karena itu, bicaralah saja. Bersikaplah jujur dan terbuka. Saya sangat menyesal karena ini tidak menyenangkan bagi seseorang. Bisakah Anda bayangkan, bertahun-tahun yang lalu ada sebuah penelitian yang menyatakan bahwa ketakutan utama di Amerika bukanlah kematian, tapi coba tebak? Takut berbicara di depan umum! Artinya di suatu tempat ada orang yang lebih memilih mati daripada mengucapkan pujian dengan lantang. Dan menurut saya, cukup bagi Anda untuk memiliki beberapa keterampilan dasar, tergantung pada apa yang Anda lakukan. Keterampilan berbicara, keterampilan menulis - tetapi hanya sebanyak yang benar-benar dibutuhkan dalam pekerjaan Anda. Jika Anda bekerja sebagai analis, tetapi tidak dapat membaca, menulis, atau berbicara, sayangnya, Anda tidak akan melakukan apa pun dalam proyek saya!
Harga komunikasi
Oleg: Bukankah mempekerjakan karyawan yang keluar lebih mahal karena berbagai alasan? Lagi pula, mereka terus-menerus mengobrol alih-alih bekerja!
Tim: Yang saya maksud adalah inti dari tim, dan bukan hanya semua orang. Jika Anda memiliki seseorang yang benar-benar hebat dalam menyetel basis data, menyukai menyetel basis data, dan akan terus menyetel basis data Anda selama sisa hidupnya dan hanya itu, keren, pertahankan. Tapi yang saya bicarakan adalah orang-orang yang ingin hidup dalam proyek itu sendiri. Inti dari tim, bertujuan untuk mengembangkan proyek. Orang-orang ini benar-benar perlu terus berkomunikasi satu sama lain. Dan terutama di awal proyek, ketika Anda membahas risiko, cara mencapai tujuan global, dan sejenisnya.
Michael: Hal ini berlaku untuk semua orang yang terlibat dalam proyek, terlepas dari spesialisasi, keterampilan, atau cara kerja. Anda semua tertarik dengan keberhasilan proyek ini.
Tim: Ya, Anda merasa cukup tenggelam dalam proyek tersebut, bahwa tugas Anda adalah membantu proyek tersebut menjadi kenyataan. Apakah Anda seorang programmer, analis, perancang antarmuka, siapa pun. Inilah alasan saya datang bekerja setiap pagi dan inilah yang kami lakukan. Kami bertanggung jawab atas semua orang ini, apa pun keahlian mereka. Ini adalah sekelompok orang yang melakukan percakapan dewasa.
Oleg: Faktanya, berbicara tentang karyawan yang banyak bicara, saya mencoba mensimulasikan keberatan orang-orang, terutama para manajer, yang diminta untuk beralih ke devops, terhadap visi dunia yang benar-benar baru ini. Dan Anda, sebagai konsultan, harus lebih menyadari keberatan ini daripada saya, sebagai pengembang! Bagikan apa yang paling mengkhawatirkan para manajer?
Tim: Manajer? Hm. Seringkali, para manajer berada di bawah tekanan masalah, dihadapkan pada kebutuhan untuk segera merilis sesuatu dan melakukan pengiriman, dan sejenisnya. Mereka memperhatikan bagaimana kita terus-menerus berdiskusi dan berdebat tentang sesuatu, dan mereka melihatnya seperti ini: percakapan, percakapan, percakapan... Percakapan apa lagi? Kembali bekerja! Karena berbicara tidak terasa seperti pekerjaan bagi mereka. Anda tidak menulis kode, tidak menguji perangkat lunak, sepertinya tidak melakukan apa pun - mengapa tidak menyuruh Anda melakukan sesuatu? Lagi pula, pengirimannya sudah dalam sebulan!
Michael: Ayo tulis beberapa kode!
Tim: Bagi saya, mereka tidak khawatir tentang pekerjaan, tapi tentang kurangnya visibilitas kemajuan. Untuk membuatnya tampak seperti kita semakin dekat dengan kesuksesan, mereka perlu melihat kita menekan tombol-tombol pada keyboard. Sepanjang hari dari pagi hingga sore hari. Ini adalah masalah nomor satu.
Oleg: Misha, kamu sedang memikirkan sesuatu.
Michael: Maaf, saya sedang melamun dan teringat kilas balik. Semua ini mengingatkan saya pada reli menarik yang terjadi kemarin... Ada terlalu banyak reli kemarin... Dan semuanya terdengar sangat familiar!
Hidup tanpa gaji
Tim: Omong-omong, sama sekali tidak perlu mengadakan “rapat umum” untuk komunikasi. Maksud saya, diskusi paling berguna antar pengembang terjadi ketika mereka hanya berbicara satu sama lain. Anda berjalan di pagi hari dengan secangkir kopi, dan ada lima orang berkumpul dan mendiskusikan sesuatu yang teknis dengan penuh semangat. Bagi saya, jika saya manajer proyek ini, lebih baik tersenyum saja dan pergi ke suatu tempat tentang bisnis saya, biarkan mereka mendiskusikannya. Mereka sudah terlibat semaksimal mungkin. Ini pertanda baik.
Oleg: Ngomong-ngomong, di bukumu, kamu punya banyak catatan tentang apa yang baik dan apa yang buruk. Apakah Anda sendiri yang menggunakannya? Secara relatif, sekarang Anda memiliki sebuah perusahaan, dan perusahaan yang terstruktur dengan cara yang sangat tidak lazim...
Tim: Tidak lazim, tetapi perangkat ini sangat cocok untuk kita. Kami sudah saling kenal sejak lama. Kami percaya satu sama lain, kami sangat percaya satu sama lain sebelum kami menjadi mitra. Misalnya, kami tidak punya gaji sama sekali. Kami hanya bekerja, dan misalnya, jika saya mendapat uang dari klien saya, maka semua uang itu menjadi milik saya. Setelah itu, kami membayar biaya keanggotaan kepada organisasi, dan ini cukup untuk menghidupi perusahaan itu sendiri. Ditambah lagi, kita semua berspesialisasi dalam hal yang berbeda. Misalnya, saya bekerja dengan akuntan, mengisi laporan pajak, melakukan segala macam urusan administratif untuk perusahaan, dan tidak ada yang membayar saya untuk itu. James dan Tom bekerja di situs web kami dan tidak ada yang membayar mereka juga. Selama Anda membayar iuran Anda, tidak ada yang akan berpikir untuk memberi tahu Anda apa yang perlu Anda lakukan. Misalnya, Tom sekarang bekerja jauh lebih sedikit dibandingkan sebelumnya. Sekarang dia punya kepentingan lain; dia melakukan beberapa hal bukan untuk Persekutuan. Namun selama dia membayar iurannya, tidak ada seorang pun yang akan mendatanginya dan berkata, “Hei, Tom, pergilah bekerja!” Sangat mudah untuk berurusan dengan rekan kerja ketika tidak ada uang di antara Anda. Dan sekarang hubungan kami adalah salah satu gagasan mendasar dalam kaitannya dengan spesialisasi yang berbeda. Ini berfungsi dan bekerja dengan sangat baik.
Saran terbaik
Michael: Kembali ke “nasihat terbaik”, adakah hal yang Anda sampaikan kepada klien Anda berulang kali? Ada gagasan tentang 80/20, dan beberapa nasihat mungkin lebih sering diulang.
Tim: Saya pernah berpikir jika Anda menulis buku seperti Waltzing with Bears, itu akan mengubah jalannya sejarah dan orang-orang akan berhenti, tapi... Begini, perusahaan sering kali berpura-pura bahwa semuanya baik-baik saja dengan mereka. Begitu sesuatu yang buruk terjadi, itu merupakan kejutan dan kejutan bagi mereka. “Begini, kami menguji sistemnya, dan tidak lulus pengujian sistem apa pun, dan ini adalah tiga bulan lagi pekerjaan yang tidak terjadwal, bagaimana ini bisa terjadi? Siapa yang tahu? Apa yang salah? Serius, apakah kamu percaya ini?
Saya mencoba menjelaskan bahwa Anda tidak boleh terlalu marah dengan situasi saat ini. Kita perlu membicarakannya, benar-benar memahami apa yang salah, dan bagaimana mencegah hal serupa terjadi di masa depan. Jika suatu masalah muncul, bagaimana kita melawannya, bagaimana kita mengatasinya?
Bagi saya, ini semua tampak menakutkan. Orang-orang menghadapi permasalahan yang rumit dan menjengkelkan dan terus berpura-pura bahwa jika mereka hanya berdoa dan berharap yang terbaik, maka yang “terbaik” akan benar-benar terjadi. Tidak, cara kerjanya tidak seperti itu.
Praktikkan manajemen risiko!
Michael: Menurut Anda, berapa banyak organisasi yang terlibat dalam manajemen risiko?
Tim: Yang membuat saya marah adalah orang-orang hanya menuliskan risiko, melihat daftar yang dihasilkan, dan mulai bekerja. Padahal, mengidentifikasi risiko bagi mereka adalah manajemen risiko. Tapi bagi saya ini sepertinya alasan untuk bertanya: oke, ada daftarnya, apa sebenarnya yang akan Anda ubah? Anda perlu mengubah urutan tindakan standar dengan mempertimbangkan risiko ini. Jika ada bagian pekerjaan yang paling sulit, Anda perlu mengatasinya, dan baru kemudian beralih ke sesuatu yang lebih sederhana. Pada sprint pertama, mulailah memecahkan masalah yang kompleks. Ini sudah terlihat seperti manajemen risiko. Namun biasanya orang tidak bisa mengatakan apa yang mereka ubah setelah menyusun daftar risiko.
Michael: Namun, berapa banyak dari perusahaan-perusahaan ini yang terlibat dalam manajemen risiko, lima persen?
Tim: Sayangnya, saya benci mengatakan ini, tapi ini adalah bagian yang sangat tidak penting. Tapi lebih dari lima, karena ada proyek yang sangat besar, dan proyek tersebut tidak akan ada jika mereka tidak melakukan setidaknya sesuatu. Anggap saja saya akan sangat terkejut jika setidaknya 25%. Proyek-proyek kecil biasanya menjawab pertanyaan-pertanyaan seperti ini: jika masalahnya mempengaruhi kita, maka kita akan menyelesaikannya. Kemudian mereka berhasil mendapatkan masalah dan terlibat dalam manajemen masalah dan manajemen krisis. Ketika Anda mencoba memecahkan suatu masalah dan masalah tersebut tidak terpecahkan, selamat datang di manajemen krisis.
Ya, saya sering mendengar, “kami akan menyelesaikan masalah yang muncul.” Tentunya kita akan melakukannya? Akankah kita benar-benar memutuskan?
Oleg: Anda dapat melakukannya secara naif dan cukup menulis invarian penting ke dalam piagam proyek, dan jika invarian tersebut rusak, mulai ulang saja proyek tersebut. Ternyata sangat piembucky.
Michael: Ya, saya kebetulan ketika risiko dipicu, proyek tersebut didefinisikan ulang. Bagus, bingo, masalah terpecahkan, jangan khawatir lagi!
Tim: Ayo tekan tombol reset! Tidak, cara kerjanya tidak seperti itu.
Pembicara utama di DevOops 2019
Michael: Kita sampai pada pertanyaan terakhir wawancara ini. Anda akan datang ke DevOops berikutnya dengan sebuah keynote, bisakah Anda membuka tirai kerahasiaan tentang apa yang akan Anda sampaikan?
Tim: Saat ini, enam dari mereka sedang menulis buku tentang budaya kerja, aturan-aturan organisasi yang tidak terucapkan. Budaya ditentukan oleh nilai-nilai inti organisasi. Biasanya orang tidak memperhatikan hal ini, tetapi setelah bekerja di bidang konsultasi selama bertahun-tahun, kami terbiasa memperhatikannya. Anda memasuki sebuah perusahaan, dan dalam beberapa menit Anda mulai merasakan apa yang terjadi. Kami menyebutnya "rasa". Terkadang aroma ini sangat enak, dan terkadang, ups. Segalanya sangat berbeda untuk organisasi yang berbeda.
Michael: Saya juga telah bekerja di bidang konsultasi selama bertahun-tahun dan memahami dengan baik apa yang Anda bicarakan.
Tim: Sebenarnya salah satu hal yang patut dibicarakan pada keynote adalah tidak semuanya ditentukan oleh perusahaan. Anda dan tim Anda, sebagai sebuah komunitas, memiliki budaya tim Anda sendiri. Ini bisa berupa seluruh perusahaan, atau departemen terpisah, tim terpisah. Namun sebelum Anda berkata, inilah yang kami yakini, inilah yang penting… Anda tidak dapat mengubah budaya sebelum nilai dan keyakinan di balik tindakan tertentu dipahami. Perilaku mudah diamati, namun mencari keyakinan itu sulit. DevOps hanyalah contoh bagus tentang bagaimana segala sesuatunya menjadi semakin kompleks. Interaksi menjadi semakin kompleks, tidak menjadi lebih bersih atau jelas sama sekali, jadi Anda harus memikirkan tentang apa yang Anda yakini dan apa yang dibungkam oleh semua orang di sekitar Anda.
Jika Anda ingin mencapai hasil yang cepat, inilah topik yang bagus untuk Anda: pernahkah Anda melihat perusahaan di mana tidak ada orang yang mengatakan “Saya tidak tahu”? Ada tempat di mana Anda benar-benar menyiksa seseorang sampai dia mengakui bahwa dia tidak mengetahui sesuatu. Semua orang tahu segalanya, semua orang adalah orang terpelajar yang luar biasa. Anda mendekati siapa pun, dan dia harus langsung menjawab pertanyaan itu. Daripada mengatakan “Saya tidak tahu.” Hore, mereka mempekerjakan sekelompok terpelajar! Dan di beberapa budaya, mengatakan “Saya tidak tahu” biasanya sangat berbahaya; hal ini dapat dianggap sebagai tanda kelemahan. Ada juga organisasi di mana, sebaliknya, setiap orang bisa mengatakan “Saya tidak tahu.” Itu sepenuhnya legal, dan jika seseorang mulai membuang sampah sembarangan saat menjawab sebuah pertanyaan, sangatlah wajar untuk menjawab: "Anda tidak tahu apa yang Anda bicarakan, bukan?" dan mengubah semuanya menjadi lelucon.
Idealnya, Anda ingin memiliki pekerjaan di mana Anda bisa selalu bahagia. Itu tidak akan mudah, tidak setiap hari cerah dan menyenangkan, terkadang Anda perlu bekerja keras, tetapi ketika Anda mulai mengambil stok, hasilnya akan: wow, ini tempat yang sangat indah, saya merasa senang bekerja di sini, baik secara emosional maupun intelektual. Dan ada perusahaan tempat Anda pergi sebagai konsultan dan langsung menyadari bahwa Anda tidak tahan selama tiga bulan dan akan lari ketakutan. Inilah yang ingin saya bicarakan dalam laporan ini.
Tim Lister akan tiba dengan keynote ke konferensi DevOops 2019, yang akan berlangsung pada 29-30 Oktober 2019 di St. Anda dapat membeli tiket . Kami menunggu Anda di DevOops!
Sumber: www.habr.com