Cara Meluncurkan Proyek di Big Tech

Mengapa peluncuran (shipping) itu sulit

• Banyak orang keliru mengira bahwa ‘peluncuran’ adalah hal yang mudah, tetapi kondisi dasarnya justru sering berupa peluncuran yang tertunda atau dibatalkan, atau muncul masalah karena tingkat kematangannya rendah.
• Menulis semua kode atau menyelesaikan semua tiket Jira tidak otomatis berarti produk akan diluncurkan. Agar bisa diluncurkan, seseorang harus mengambil peran sebagai pemimpin.
• Peluncuran harus menjadi prioritas tertinggi. Jika terlalu berfokus pada pengalaman pengguna (UX), peluncuran justru bisa tertunda.
• Untuk meluncurkan proyek dengan sukses, diperlukan pemimpin teknis atau DRI (Directly Responsible Individual). Tim yang memiliki engineer yang mengambil peran ini memiliki peluang sukses yang lebih tinggi.

Apa itu ‘peluncuran’?

• Banyak engineer menganggap ‘peluncuran’ sekadar sebagai deployment kode atau aktivasi fitur, tetapi di perusahaan teknologi besar definisinya berbeda.
• Peluncuran terjadi ketika orang-orang penting di perusahaan percaya bahwa sesuatu itu ‘sudah diluncurkan’. Jika VP atau CEO tidak puas, maka meskipun kodenya sudah di-deploy, itu belum benar-benar ‘diluncurkan’.
• Jika proyek meraih sukses besar di kalangan pengguna atau menghasilkan pendapatan, itu adalah peluncuran. Namun, bahkan jika respons pengguna kurang baik, selama kepemimpinan puas, itu tetap dianggap sudah diluncurkan.

Pentingnya komunikasi

• Anda harus memahami dengan jelas apa tujuan proyek tersebut. Bergantung pada tujuannya, cara bekerja dan strategi komunikasi akan berbeda.
• Kepemimpinan perusahaan hampir tidak mengetahui detail teknis proyek. Karena itu, untuk menjaga kepercayaan, estimasi yang akurat, penyelesaian masalah, dan pembaruan yang tepat sangatlah penting.
• Cara menjaga kepercayaan:
• Akan lebih menguntungkan jika Anda memiliki pengalaman peluncuran sukses di masa lalu.
• Anda harus menunjukkan sikap yang percaya diri.
• Anda harus berkomunikasi secara profesional dan ringkas seperti mission control NASA.
• Anda harus secara proaktif memberikan informasi melalui thread pembaruan harian atau mingguan.

Menyelesaikan masalah deployment produksi

• Sebagian besar masalah muncul dari detail yang tidak terduga. Misalnya, ada masalah ukuran blok Memcached, kesalahan prediksi traffic, atau isu data pengguna sensitif.
• Untuk menyelesaikan masalah dengan cepat, diperlukan pemahaman teknis yang mendalam terhadap sistem.
• Anda harus dapat merespons cepat terhadap masalah yang diperkirakan akan muncul, dan mampu menjelaskan dengan jelas apakah masalah tersebut serius atau tidak.

Bisakah diluncurkan sekarang juga?

• Penting untuk bertanya pada diri sendiri apakah sesuatu bisa diluncurkan sekarang juga. Jika tidak, Anda harus memikirkan apa yang perlu diubah agar itu memungkinkan.
• Gunakan feature flag dan environment staging agar Anda bisa mendapatkan feedback secepat mungkin.
• Menjelang peluncuran, kurangi pekerjaan teknis dan bersiaplah agar bisa merespons dengan cepat saat masalah muncul.

Ringkasan

• Pekerjaan peluncuran sangat sulit dan harus dijadikan prioritas tertinggi.
• Makna peluncuran bukan sekadar deployment, melainkan apakah tim kepemimpinan merasa puas.
• Mendapatkan kepercayaan dari tim kepemimpinan adalah kunci peluncuran yang sukses.
• Penting untuk memiliki rencana cadangan agar bisa mengantisipasi dan menangani masalah.
• Menjelang peluncuran, Anda harus mengurangi pekerjaan pengembangan dan bisa fokus pada penyelesaian masalah.
• Anda harus selalu mengajukan pertanyaan, “Bisakah ini diluncurkan sekarang juga?”
• Singkirkan rasa takut dan miliki keberanian.

[GN⁺]

Komentar Hacker News

• Pengamatan bahwa "shipping" adalah konstruksi sosial di dalam perusahaan terasa mengesankan. Sesuatu dianggap selesai ketika orang-orang penting percaya proyek itu telah selesai
• Artikel ini bukan tentang deployment software, melainkan tentang memuaskan eksekutif. Jika pengguna membencinya dan pasar menertawakannya, tetapi eksekutif menyukainya, maka itu dianggap shipped
• Seperti kemenangan menyelesaikan semua masalah dalam olahraga, dalam software shipping menyelesaikan semua masalah. Tidak ada produk yang sempurna, tetapi jika dirilis lebih awal, pengguna bisa merasa puas
• Dalam beberapa kasus, engineer yang menyelesaikan masalah mendapat lebih banyak pengakuan daripada yang mencegah masalah. Kita berusaha mencegah masalah, tetapi para pemimpin kadang tidak menyadarinya
• Di perusahaan besar, "shipping" harus dipahami dalam konteks yang lebih besar, bukan sekadar mewujudkan fitur. Sebagian orang mungkin menyebutnya tidak etis, tetapi di perusahaan besar ini semacam "permainan"
• Sudah banyak proyek yang di-ship, tetapi tanpa contoh konkret sulit untuk dipercaya. Jika disertakan contoh proyek nyata, isinya akan lebih mudah dipahami
• Artikel ini adalah spam blog promosi diri
• Ini sesuai dengan pengalaman, tetapi kurang nasihat yang praktis. Diperlukan contoh konkret tentang cara mendapatkan pengakuan dari kepemimpinan
• Berbeda dengan pengalaman di perusahaan besar. Bahkan tanpa dukungan eksekutif, jika umpan balik pengguna atau metrik positif, itu dianggap sukses. Proyek kecil pun bisa bernilai
• Klaimnya perlu dikuantifikasi dan dijelaskan secara kualitatif agar bisa dipercaya. "Shipping di big tech" adalah pernyataan yang terlalu luas dan memerlukan penjelasan yang lebih spesifik

[signaling]

Saya mengutip pendapat yang mengesankan.

"Sebagian orang hanya ingin membangun wilayah teknis untuk diri mereka sendiri, atau ingin mendapat pujian dari orang yang berada di atas mereka di hierarki mana pun. Beginilah permainan dijalankan. Memainkan permainan ini pada akhirnya akan berujung pada kematian organisasi, dan inilah alasan mengapa sejak awal kita memiliki siklus hidup perusahaan. Pada akhirnya, orang-orang seperti ini merusak organisasi dari dalam, lalu menyingkirkan orang-orang yang benar-benar punya pendapat atau yang benar-benar dioptimalkan untuk menyelesaikan pekerjaan."

"Cara untuk menang dalam permainan adalah dengan tidak memainkannya"