Player Unknown’s Bug: Bisakah kita berkembang dengan mencatat masalah yang penyebabnya tidak diketahui?
(engineering.ab180.co)Melalui halaman isu yang dibuat secara kebetulan, saya ingin berbagi cerita tentang bagaimana tim meningkatkan rasa aman secara psikologis dan memperbanyak berbagi informasi untuk membangun organisasi dan layanan yang lebih kokoh.
Saat melakukan pengembangan, kita sering bertemu masalah yang penyebabnya tidak diketahui.
Khususnya web frontend dipengaruhi oleh banyak faktor eksternal selain kondisi server dan semacamnya, seperti jenis atau versi browser, extension Chrome, dan lain-lain.
Jika kita tidak mengetahui penyebab masalah, atau jika penyebab masalah bukan berasal dari kita, tiba-tiba muncul pertanyaan apakah hanya dengan postmortem kita bisa membangun struktur yang kuat (apakah itu tidak kurang?).
Latar belakang
Pernah ada kasus ketika saya menerima laporan isu yang penyebabnya tidak diketahui, dan butuh 9 jam sampai isu tersebut ditutup.
Baru setelah mengalokasikan 4 jam untuk debugging isu, saya mengetahui bahwa penyebab masalah bukan ada pada kode internal atau infrastruktur, melainkan terjadi karena bug pada Chrome Extension milik pengguna.
Sulit untuk mengetahui di mana letak penyebab masalahnya, tetapi yang membuat saya kesal pada diri sendiri adalah fakta bahwa butuh 4~5 jam penuh hanya untuk memahami bahwa penyebabnya ada di luar.
Saya membuat halaman di Notion bernama ‘Player Unknown’s Bug(PUB)’, lalu sambil diliputi kemarahan saya merapikan hal-hal yang sudah dicoba saat menangani isu, hal-hal yang disayangkan, dan apa yang sebaiknya dilengkapi.
Menetap sebagai budaya, lalu berkembang
Sambil melakukan retrospektif, kami membicarakan penyebab isu, hal-hal tambahan yang diketahui saat menelusurinya, serta titik-titik di mana kami salah menilai. Anggota tim menunjukkan pertanyaan yang mereka miliki dan poin-poin yang sebaiknya diperbaiki, lalu kami mengumpulkan semuanya untuk menetapkan proses penanganan insiden.
Hal yang bagus dari proses ini adalah anggota tim berempati pada kesulitan yang saya rasakan selama menangani isu, dan ada kesenangan tersendiri dalam membagikan hal-hal baru yang saya pelajari. Selain itu, kami membuat checklist sehingga ketika situasi serupa datang, kami bisa memahami masalah lebih cepat. Setelah dibicarakan di tim, ini diadopsi sebagai budaya resmi.
Organisasi pengembangan AB180 pada dasarnya menjalankan ‘postmortem’. Jika postmortem internal perusahaan berpusat pada Resolution dan Action Items, maka tujuan PUB adalah Lesson Learn, membentuk rasa aman secara psikologis terkait penanganan isu, dan merapikan faktor-faktor yang perlu diperiksa lebih dulu pada masalah yang tidak diketahui.
Budaya berbagi informasi secara sukarela
Setelah menetap di tim, isu-isu yang ditangani anggota tim lain juga mulai menumpuk satu per satu.
Saat melakukan retrospektif, waktu untuk membicarakan hal-hal yang sebelumnya tidak diketahui dan menggali lebih dalam mulai berjalan seperti 'sesi berbagi pengetahuan' yang kecil tetapi sukarela.
Untuk sedikit memperbesar budaya ini, kami mengelola channel Slack tempat hal-hal yang dipelajari dan diketahui dibagikan dari waktu ke waktu. Sampai sekarang, ini masih berjalan dengan baik.
Lesson Learn
- Kita perlu meningkatkan rasa aman secara psikologis seluruh tim yang menangani insiden, dan untuk itu kita harus lebih banyak berbicara.
- Jika tidak, masalah akan berulang, dan di dalam organisasi akan mengakar pemikiran bahwa ‘masalah = sesuatu yang tidak boleh dibicarakan’.
- Melalui berbagi informasi, kita dapat membangun rasa aman secara psikologis dalam organisasi, bahkan meningkatkannya.
- Dan budaya berbagi informasi seperti ini mungkin bisa dimulai dari sesuatu yang ternyata tidak sebesar yang dibayangkan.
5 komentar
Sebaliknya, hari ini saya pulang kerja setelah seharian dibuat pusing oleh sebuah insiden yang penyebabnya tampak sangat jelas berasal dari faktor eksternal tertentu, tetapi karena kondisi internal rasanya tidak mudah ditangani sehingga saya hanya bisa cemas mondar-mandir, padahal ternyata kasus itu bisa diselesaikan hanya dengan mengubah satu baris di file konfigurasi. Melihat tulisan ini benar-benar sangat membantu.
Anda sudah bekerja keras hari ini. Meski begitu, syukurlah masalahnya berhasil Anda selesaikan. Saya juga kadang teringat masalah-masalah yang saya tulis di atas. Waktu itu memang berat, tetapi sekarang rasanya saya bisa menerimanya dengan lebih ringan dan bahkan menyenangkan.
Bukankah hal sulit yang dialami kunggom hari ini juga bisa dikenang dengan perasaan yang menyenangkan setelah waktu berlalu? hehe
Terima kasih sudah membaca tulisan saya yang masih banyak kekurangannya.
Sebenarnya, baik dulu maupun sekarang, saya tidak pernah menganggap beratnya menangani gangguan itu sebagai sesuatu yang menyenangkan.
Misalnya, gangguan yang saya tangani hari ini kebetulan terjadi pada produk yang di tim kami akses langsung ke server produksinya diblokir, jadi selain pada tahap awal saat kami menemukan gangguan dan mulai memahami gejalanya, serta pada tahap akhir setelah kami susah payah mendapatkan izin akses server, pada dasarnya kami tidak punya pilihan selain merasa relatif tidak berdaya. Ketika tim kami meminta agar tindakan tertentu dilakukan, tim operasional server menolaknya karena alasan di pihak mereka. Tentu saja rasa tidak berdaya seperti itu tidak bisa diterima dengan gembira.
Jadi, saat menulis dokumen postmortem sampai sebelum pulang kerja, yang saya rasakan rasanya lebih dekat ke, "Kalau perlu karena saking kesalnya pun, mulai berikutnya saya tidak akan mengulangi kesalahan seperti ini lagi!"
Mendengar apa yang Anda sampaikan, saya merasa Anda pasti sudah melalui masa yang sangat berat. Seperti yang Anda katakan, dengan tidak mengulangi kesalahan yang sama, kita memang hanya bisa membaik sedikit demi sedikit... terisak
Sebenarnya produk tersebut adalah produk legacy yang sudah cukup tua, saya juga belum lama menerima serah terimanya, dan begitu saya menerimanya langsung ada permintaan perubahan fitur sehingga saya memang sempat memodifikasi kode baru-baru ini, tetapi itu sama sekali tidak berkaitan dengan bagian yang menyebabkan gangguan hari ini. Jadi bagian yang benar-benar menjadi masalah bukanlah sesuatu yang saya tulis sendiri, tetapi kalau saja saya mengenal produk itu lebih dalam, saya mungkin bisa menyelesaikan masalahnya lebih cepat. Itu yang sangat disayangkan.
Dan sejak awal, dugaan penyebab yang mula-mula saya yakini setelah memastikan situasi gangguan total itu sebenarnya hanya setengah benar. Saya rasa keyakinan terhadap dugaan itulah yang justru menjadi kesalahan terbesar hari ini.