Seminggu menghentikan pekerjaan roadmap dan fokus memperbaiki bug

 (lalitm.com)
20 poin oleh GN⁺ 2025-11-25 | 2 komentar | Bagikan ke WhatsApp
  • Organisasi dengan sekitar 45 engineer menghentikan roadmap, desain, dan rapat selama seminggu tiap kuartal untuk menjalankan ‘pekan Fixit’, dengan fokus menyelesaikan bug kecil dan masalah produktivitas
  • Pada Fixit kali ini, 189 bug diperbaiki, 40 orang berpartisipasi, dengan median 4 issue per orang dan maksimum 12 bug yang ditutup
  • Motivasi dan semangat tim ditingkatkan lewat aturan penyelesaian dalam 2 hari, sistem poin dan leaderboard, serta hadiah kaus
  • Pemanfaatan alat AI mempercepat penelusuran kode dan usulan perbaikan, sekaligus mengurangi beban perpindahan konteks
  • Fixit dinilai berkontribusi pada peningkatan kualitas produk dan kekompakan tim, serta menghidupkan kembali kesenangan menyelesaikan masalah kecil

Konsep dan cara kerja Fixit

  • Fixit adalah pekan perbaikan bug intensif yang berlangsung selama satu minggu tiap kuartal, dengan menghentikan sepenuhnya pekerjaan roadmap, desain, dan rapat reguler
    • Para engineer memperbaiki error kecil atau faktor penurun produktivitas yang selama ini mengganggu pengguna dan developer
    • Contoh: pesan error yang tidak jelas selama 2 tahun, glitch saat scroll dan zoom dipakai bersamaan, keterlambatan CI akibat pengujian yang lambat
  • Ada dua aturan
    • Tidak ada bug yang boleh memakan waktu lebih dari 2 hari
    • Pekerjaan difokuskan pada peningkatan bagi pengguna akhir atau produktivitas developer
  • Mereka menjalankan sistem poin dan leaderboard untuk memvisualisasikan partisipasi, dan memberikan hadiah kaus untuk berbagai kategori seperti ‘perbaikan bug pertama’ dan ‘perbaikan bug paling menjengkelkan’

Hasil Fixit

  • Hasil Fixit kali ini
    • 189 bug diperbaiki, 40 orang berpartisipasi, median 4 per orang, maksimum 12
  • Contoh utama
    • Permintaan fitur Perfetto yang didaftarkan pada 2021 di issue ini diimplementasikan hanya dalam satu hari, sehingga meningkatkan pengalaman pengguna
    • Perbaikan GitHub Action mengurangi jumlah klik yang dibutuhkan developer UI untuk mengakses build
    • Penyediaan versi terintegrasi SDK mempermudah integrasi ke proyek, dan diimplementasikan dalam sekitar 1 jam
    Iklan

Dampak Fixit

  • Dari sisi produk: detail dan kematangan

    • Ciri produk yang baik adalah perhatian pada detail dan konsistensi
    • Fixit menjadi kesempatan untuk meningkatkan kualitas produk satu tingkat lebih tinggi dengan menghilangkan gangguan kecil yang mungkin tidak selalu disadari langsung oleh pengguna

  • Dari sisi individu: kepuasan yang berpusat pada eksekusi

    • Ini menghadirkan kembali rasa pencapaian instan seperti di awal karier: “menemukan masalah → memperbaiki → merilis”
    • Selama Fixit, fokus beralih dari ‘apa yang akan dibuat’ ke ‘bagaimana cara memperbaikinya’, sehingga rasa pencapaian terakumulasi dalam siklus singkat

  • Dari sisi tim: semangat dan kolaborasi yang lebih kuat

    • Empat puluh orang di dua zona waktu memperbaiki bug secara bersamaan, sehingga energi seluruh organisasi meningkat
      • Terjadi interaksi aktif di ruang chat, seperti berbagi perbaikan secara real-time, mengunggah tangkapan layar, dan menampilkan demo
    • Setiap pagi mereka membagikan jumlah perbaikan, jumlah peserta, dan peringkat leaderboard untuk memperkuat motivasi

Syarat agar Fixit berjalan sukses

  • Persiapan sebelumnya

    • Sepanjang tahun, bug diberi tag “good fixit candidate”, lalu pada pekan sebelum Fixit diklasifikasikan menjadi kecil, sedang, besar (0,5 · 1 · 2 hari)
    • Berdasarkan ukuran, tiap bug diberi 1 · 2 · 4 poin, lalu disusun daftar bug prioritas
    • Proses persiapan ini adalah faktor kunci untuk mencegah kekacauan di hari pertama
    Iklan

  • Aturan batas 2 hari

    • Di masa lalu pernah ada bug yang ternyata lebih kompleks dari perkiraan dan menghabiskan seluruh pekan Fixit
    • Setelah itu diperkenalkan prinsip menghentikan pekerjaan dan memindahkannya ke backlog bila melewati 2 hari, dengan tujuan menjaga rasa pencapaian secara berkelanjutan

  • Skala peserta

    • Pada tahap awal dengan 7 orang, hasil tetap ada tetapi belum cukup membangun resonansi di seluruh organisasi
    • Di kisaran 40 orang, massa kritis terbentuk, sehingga energi kolektif dan rasa tenggelam dalam pekerjaan mencapai puncak

  • Gamifikasi

    • Poin dibuat lebih untuk kesenangan daripada akurasi (1/2/4 poin)
    • Pencapaian diakui secara luas: perbaikan pertama, bug paling menjengkelkan, dan kategori lainnya
    • Dipisahkan dari evaluasi kinerja, agar motivasi partisipasi tetap murni
    • Berkat norma sosial dan ukuran tim, hampir tidak ada penyalahgunaan sistem

Peran alat AI

  • AI membantu mengurangi beban perpindahan konteks, yang merupakan tantangan utama dalam Fixit
    • AI dapat dengan cepat menelusuri dan merangkum file terkait, sehingga beban kognitif berkurang
  • Contoh
    Iklan
  • Hasilnya, waktu untuk mencapai titik mulai menjadi lebih singkat, dan dalam beberapa kasus perbaikan bisa langsung dilakukan

Kritik terhadap Fixit dan tanggapannya

  • “Bukankah ini berarti bug biasanya diabaikan?”

    • Sampai batas tertentu memang benar, tetapi ini melengkapi kenyataan bahwa gangguan kecil (papercut bugs) sering tersingkir dari prioritas
    • Fixit adalah cara untuk secara eksplisit menyediakan waktu guna menyelesaikan “masalah kecil tetapi penting”

  • “Bukankah menghentikan pekerjaan roadmap itu pemborosan?”

    • Mengalokasikan 40 orang selama 1 minggu memang besar, tetapi itu terbayar oleh peningkatan kematangan produk dan kepuasan pengguna
    • Efek peningkatan produktivitas seperti percepatan pengujian, pesan error yang lebih jelas, dan workflow yang lebih singkat terus bertahan dalam jangka panjang

  • “Bukankah ini hanya mungkin dilakukan perusahaan besar?”

    • Tim kecil pun bisa mengadaptasinya menjadi ‘Fixit Friday’ atau mini Fixit 2 hari
    • Intinya adalah menyediakan waktu yang terfokus dan terlindungi serta melakukan aktivitas perbaikan bersama

Nilai esensial dari Fixit

  • Tujuan resminya adalah meningkatkan kualitas produk dan produktivitas developer
  • Alasan tidak resminya adalah “kesenangan dalam memperbaiki sesuatu”
  • Fixit dinilai sebagai unsur penting untuk menghidupkan kembali kepuasan dari masa yang lebih sederhana, sekaligus mempertahankan budaya membangun produk dengan teliti

Bacaan terkait

2 komentar

 
t7vonn 2025-11-25

Ini mengingatkan saya pada budaya pitstop di Baemin. Saya dengar sekarang sudah tidak ada.
 
GN⁺ 2025-11-25
Komentar Hacker News

  • Saya suka idenya, tetapi kalimat “bug tidak boleh memakan waktu lebih dari 2 hari” terasa aneh
    Pada praktiknya, hampir mustahil memprediksi berapa lama perbaikan akan memakan waktu sebelum bug itu benar-benar diperbaiki
    Meski begitu, jika tidak memerlukan refactoring besar, saya rasa hampir tidak ada yang butuh lebih dari sehari
    Saya biasanya menangani bug berdasarkan tingkat keparahan atau prioritas. Semakin parah bug-nya, justru sering kali semakin mudah ditemukan
    Begitu penyebabnya ditemukan, perbaikannya biasanya cepat

    • Dulu saya bekerja di perusahaan yang banyak memakai MS SQL Server, dan setiap beberapa bulan muncul Heisenbug yang membuat cluster server berhenti
      Kami menganalisis log selama bertahun-tahun tetapi tidak menemukan penyebabnya, lalu akhirnya menemukan bahwa masalah itu bisa direproduksi 100% dengan kombinasi DB dan commit pada kondisi tertentu
      Setelah menandatangani NDA, kami membuat binary reproduksi minimal dan mengotomatiskannya dengan skrip PowerShell, lalu MS memperbaikinya dalam waktu sebulan
      Secara internal rasanya seperti buffer overflow, tetapi saya tidak yakin
    • Di sebagian besar proyek penuh bug tempat saya pernah bekerja, aturan seperti ini juga ada secara implisit
      Jika saya menghabiskan seminggu penuh hanya memperbaiki bug dan tidak menambah story point di Jira, beberapa manajer akan berdatangan dan bertanya kenapa lajunya lambat
      Jadi pelajaran yang saya ambil adalah, lebih baik menghindari bug yang sulit dan cepat menyerah pada pekerjaan yang tidak menghasilkan poin
    • Jika bekerja di sisi hardware, bug yang sulit direproduksi kadang bisa memakan waktu berbulan-bulan
      Tidak jelas apakah masalahnya ada di kode, compiler, atau hardware, dan bug gabungan yang muncul karena beberapa faktor sekaligus bahkan tidak bisa direproduksi secara terpisah
    • Dalam arsitektur yang saling terkait seperti game, sering ada struktur kompleks di mana event A memicu B tetapi hasilnya berubah tergantung status C
      Dalam kasus seperti ini, ketika solusi sementara yang cepat menumpuk, perbaikan bug yang benar di kemudian hari bisa berubah menjadi rework besar-besaran
    • Ada dua alasan bug tidak kunjung diperbaiki
      1. Penyebabnya tidak jelas sehingga sebagian besar waktu habis untuk menemukannya
      2. Penyebabnya jelas tetapi merupakan kesalahan arsitektural sehingga perbaikannya menjadi proyek besar
        Selain itu, di lingkungan dengan kepercayaan rendah, bahkan bug sepele pun kadang tidak bisa langsung diperbaiki karena prosedur Jira

  • Saat bekerja di Meta, kami mengadakan Fix-it Week setiap kuartal
    Awalnya saya pikir ini berarti kepemimpinan peduli pada kualitas, tetapi pada praktiknya itu adalah masa berlisensi untuk menumpuk utang teknis
    Kami mencoba memperbaiki bug selama seminggu, tetapi karena utangnya sudah telanjur menumpuk, hampir tidak ada yang benar-benar terselesaikan

    • Ini mengingatkan saya pada kebijakan id Software — “kalau melihat bug, langsung perbaiki”
      Kalau tidak, kode baru akan menumpuk di atas bug itu dan menjadi fondasi yang tidak stabil
      Video ceramah John Romero juga menekankan filosofi yang sama
    • Fix-it Week di Meta pada praktiknya adalah minggu refactoring
      Para developer mengerjakan TODO lama yang mereka tinggalkan sambil menambah LOC, dan sebagian bahkan ada yang sengaja menulis kode buruk agar nanti bisa “memperbaikinya” untuk mengakali jumlah diff
    • Seperti yang disebut dalam tulisan aslinya, Fix-it Week adalah minggu yang berfokus pada bug kecil atau peningkatan pengalaman developer
      Artinya, ini adalah waktu untuk menangani masalah yang tidak mendesak tetapi mengganggu
    • Minggu seperti ini justru bisa menjadi pembebasan mental berupa “tidak perlu diperbaiki sekarang, nanti saja saat Fix-it Week”
      Lebih penting bila kepemimpinan menjelaskan prioritas bisnis secara jujur, dan dengan jelas menunjukkan dampak bug terhadap pengguna
    • Jika benar-benar peduli pada kualitas, pendekatan paling realistis adalah meleburkan perbaikan bug secara alami ke dalam pengembangan fitur

  • Saya pernah mengalami lingkaran setan ketika mengembangkan fitur sambil terus-menerus menghadapi respons darurat dan perubahan prioritas
    Akhirnya sistem dipenuhi workaround, dan baik pelanggan maupun developer sama-sama tidak puas
    Dalam situasi seperti ini, rasanya seharusnya lebih baik berhenti sejak awal dan melakukan perbaikan bug yang mendasar

    • Pola seperti ini adalah gejala khas kehancuran organisasi
      Komunikasi terputus, para pemimpin mondar-mandir panik seperti ayam kehilangan kepala sambil hanya memberi perintah
      Developer berubah menjadi pemadam kebakaran untuk semua masalah, dan pada akhirnya satu-satunya solusi adalah pergi
    • Ini jelas merupakan kegagalan kepemimpinan
      Semakin lambat lajunya, semakin panik pemimpinnya lalu sembarangan mengacak proyek, yang akhirnya memperbesar kekacauan dan budaya beracun
    • Untuk menghindari situasi seperti ini, alih-alih selalu berusaha memuaskan pelanggan, dibutuhkan kemampuan mengelola ekspektasi
    • Namun, jika perusahaan masih berada pada tahap mencari PMF (Product-Market Fit), menghabiskan waktu untuk engineering yang sempurna bisa jadi tidak efisien
    • Kesimpulannya, masalahnya bukan pada individu melainkan budaya organisasi yang beracun. Solusinya adalah pergi secepat mungkin

  • Saya selalu bekerja dengan filosofi “perbaikan bug didahulukan”
    Jika fitur yang sudah ada belum berfungsi dengan baik, saya tidak membuat fitur baru
    Dengan begitu, kita bisa menjaga codebase bebas bug dan produktivitas tim juga meningkat

    • Tetapi semakin besar ukuran tim, semakin kuat kecenderungan untuk memprioritaskan pengembangan fitur baru dibanding bug
    • Saya sering ditanya di mana budaya seperti ini bisa diterapkan
      Khususnya di frontend, karena beragam masalah lingkungan, kondisi benar-benar tanpa bug hampir mustahil dicapai
      Selain itu, definisi “bug” sering kabur sehingga kadang fitur yang diinginkan manajer diklasifikasikan sebagai bug
    • Bug juga punya prioritas
      Misalnya, error pada halaman API yang hampir tidak pernah dipakai bisa jadi kurang penting dibanding fitur baru
    • Sistem dengan skala pengguna besar memiliki ribuan bug
      Sebagian besar adalah masalah kecil, sehingga kepemimpinan lebih memilih fitur baru
    • Pada kenyataannya, codebase nol bug yang sempurna itu tidak ada. Percaya bahwa bug tidak ada hanyalah kurangnya kesadaran

  • Saya menjalankan produk SaaS kecil dan memegang prinsip “bug diperbaiki lebih dulu”
    Saya menyelesaikan bug yang dilaporkan pelanggan sebelum fitur baru
    Dengan begitu, jumlah bug baru yang ditemukan makin berkurang, dan perbaikannya juga jadi lebih mudah
    Dari sisi bisnis ini mungkin tidak efisien, tetapi dari sisi kualitas dan kepercayaan pelanggan, ini adalah strategi terbaik
    Pelanggan sangat senang jika bug yang mereka laporkan diperbaiki dalam hitungan jam

    • Namun ada juga rekan yang setuju bahwa prinsip ini sulit diterapkan pada codebase legacy berusia 15 tahun
    • Terkait itu, saya pernah menulis artikel — Fix Bugs or Add New Features

  • Sistem seperti Fix-it Week justru mendorong penundaan perbaikan bug
    Muncul alasan “nanti saja saat Fix-it Week”
    Menurut saya, lebih baik memasukkan waktu maintenance secara eksplisit ke dalam perencanaan kuartal atau sprint
    Dengan begitu, developer punya alasan yang sah untuk segera memperbaiki bug, dan budaya perbaikan berkelanjutan bisa tumbuh
    Fix-it Week sebaiknya dijalankan seperti mini hackathon yang juga mencakup peningkatan kecil atau POC

  • Perusahaan lama saya selalu mengulang siklus yang sama

    1. all-in pada pengembangan fitur → 2) insiden besar pada pelanggan enterprise → 3) semua pengembangan dihentikan lalu masuk minggu perbaikan bug
      Pola seperti ini adalah tanda budaya organisasi yang salah. Jika waktu untuk memperbaiki bug tidak disediakan dalam keseharian, keadaan tidak akan pernah berubah

  • Ini mengingatkan saya pada Joel Test yang pernah diajukan Joel Spolsky
    Pertanyaan kelimanya adalah “Apakah Anda memperbaiki bug sebelum menulis kode baru?”
    Setelah 25 tahun, itu masih menjadi standar yang relevan
    Tautan tulisan asli

  • Saya termasuk yang berpendapat bahwa bug tidak perlu diberi skor atau estimasi ukuran
    Kalau memang harus diberi poin, anggap saja semuanya bernilai 2 dan secara rata-rata itu akan cukup tepat
    Perbaikan bug cukup ditangani dengan metode Kanban, dikerjakan sesuai urutan pentingnya, lalu diselesaikan dalam waktu yang tersedia

  • Saya penulisnya. Senang melihat diskusi yang aktif

    1. Karena kompleksitas bug sulit diprediksi, saya menyarankan agar setelah beberapa jam investigasi, jika cakupannya membesar maka diubah menjadi isu lain
    2. Kami menggunakan istilah internal “bug” bukan hanya untuk error tradisional tetapi juga mencakup permintaan peningkatan fitur
    3. Memang ada risiko Fix-it Week berubah menjadi “tunda sampai saat itu”, tetapi kami menjalankannya khusus untuk bug kecil
      Itu bukan pengganti untuk kebersihan teknis atau penyelesaian isu besar
    • Ada juga umpan balik yang mengatakan tulisannya menarik, sambil bertanya seberapa sering regresi atau error baru muncul akibat perbaikan bug