Project Management
Lean dan Six Sigma di Proyek Software: Cara Memakainya Tanpa Birokrasi
Lean dan Six Sigma bisa membuat proyek aplikasi atau website lebih efisien, asalkan dipakai untuk dua masalah yang berbeda. Lean memangkas waktu tunggu dan pekerjaan yang tidak dipakai siapa pun. Six Sigma membantu menekan cacat yang terus berulang, misalnya bug yang lolos ke produksi setiap kali rilis. Di bawah ini ada tabel tujuh pemborosan dengan contoh proyek sehari-hari, cara menghitung seberapa lambat sebuah perubahan sebenarnya, satu contoh DMAIC lengkap, dan batas kapan kedua metode ini justru berlebihan.
Apa beda Lean dan Six Sigma di proyek software?
Lean berasal dari sistem produksi Toyota. Pertanyaannya sederhana: dari seluruh waktu yang dihabiskan, berapa yang benar-benar menambah nilai bagi pengguna? Sisanya dianggap pemborosan dan dicari cara membuangnya.
Six Sigma diperkenalkan Bill Smith di Motorola pada 1986 (Wikipedia: Six Sigma). Fokusnya variasi dan cacat. Setiap masalah diukur, akar penyebabnya dibuktikan dengan data, lalu prosesnya diubah agar cacat yang sama tidak muncul lagi. Alat kerjanya adalah siklus DMAIC: Define, Measure, Analyze, Improve, Control.
Dalam satu kalimat: Lean menjawab "kenapa lama?", Six Sigma menjawab "kenapa salah terus?". Proyek yang lambat tetapi jarang bermasalah cukup dibenahi dengan Lean. Proyek yang cepat tetapi tiap rilis memicu keluhan pengguna butuh cara berpikir Six Sigma.
Tujuh pemborosan Lean dalam bentuk yang sering kita temui
Mary dan Tom Poppendieck menerjemahkan pemborosan versi pabrik ke dunia software dalam buku Lean Software Development (2003). Daftarnya ada di Wikipedia: Lean software development. Kolom contoh di bawah adalah situasi yang sering kami lihat di proyek aplikasi bisnis di Indonesia.
| Pemborosan | Contoh di proyek | Cara mengukurnya |
|---|---|---|
| Pekerjaan setengah jadi | Lima fitur "90% selesai" menjelang tenggat, belum ada satu pun yang bisa dipakai | Jumlah tugas berstatus dikerjakan pada satu waktu |
| Proses tambahan | Laporan mingguan 12 halaman yang tidak dibaca direksi | Jam per minggu untuk dokumen yang tidak ditindaklanjuti |
| Fitur tambahan | Modul ekspor ke tiga format, padahal tim keuangan hanya memakai Excel | Fitur yang tidak dibuka sebulan setelah rilis |
| Pindah tugas | Satu programmer memegang tiga proyek dan dipanggil rapat tiap dua jam | Jumlah proyek aktif per orang |
| Menunggu | Desain menunggu persetujuan pemilik usaha lewat WhatsApp selama empat hari | Hari dari "siap ditinjau" sampai "disetujui" |
| Serah terima | Kebutuhan dari klien melewati sales, lalu PM, lalu programmer | Jumlah orang di antara pengguna dan pembuat |
| Cacat | Total struk salah karena diskon dan PPN dihitung dalam urutan keliru | Bug per rilis yang ditemukan pengguna |
Dari ketujuh baris itu, "menunggu" biasanya yang paling mahal dan paling jarang tercatat. Tidak ada yang mencatat berapa lama sebuah desain duduk di kotak masuk.
Hitung dulu: berapa persen waktu yang benar-benar dipakai bekerja
Cara paling cepat menemukan pemborosan adalah melacak satu permintaan perubahan dari awal sampai pengguna bisa memakainya. Ambil satu contoh kecil.
Contoh: pemilik kafe minta tombol "pisah tagihan" di aplikasi kasirnya. Rinciannya seperti ini.
| Tahap | Waktu kalender | Waktu kerja aktif |
|---|---|---|
| Menunggu dibahas di rapat mingguan | 3 hari kerja | 0 jam |
| Desain layar dan persetujuan | 4 hari kerja | 1,5 jam |
| Pembuatan dan tes | 1 hari kerja | 4 jam |
| Menunggu jadwal rilis hari Jumat | 1 hari kerja | 0,5 jam |
| Total | 9 hari kerja (72 jam) | 6 jam |
Kerja aktifnya 6 jam dari 72 jam kerja, sekitar 8,3%. Itulah efisiensi alur. Programmer yang bekerja dua kali lebih cepat hanya menghemat tiga jam, sedangkan membuang antrean rapat dan persetujuan bisa memangkas enam hari kerja.
Untuk ukuran baku, program riset DORA (DevOps Research and Assessment) memakai change lead time: waktu dari perubahan kode di-commit sampai berjalan di produksi (dora.dev). Ukuran itu baru mulai menghitung setelah kode ditulis. Bagi pemilik proyek, waktu dari permintaan sampai rilis seperti tabel di atas biasanya lebih jujur.
Six Sigma di software: pakai DMAIC, lupakan angka 3,4
Target klasik Six Sigma adalah 3,4 cacat per sejuta peluang. Angka itu sudah memasukkan asumsi pergeseran 1,5 sigma dalam jangka panjang, asumsi yang oleh ahli statistik Donald Wheeler disebut sewenang-wenang (Wikipedia: Six Sigma).
Di software masalahnya lebih mendasar. Apa itu satu "peluang cacat"? Satu baris kode, satu layar, satu transaksi? Tim yang merilis 15 kali sebulan tidak akan pernah sampai sejuta peluang. Kami tidak menyarankan menghitung level sigma untuk proyek aplikasi bisnis.
Yang tetap berguna adalah disiplin DMAIC: definisikan satu masalah yang bisa diukur, kumpulkan data sebelum menebak penyebab, dan pasang pengendali agar perbaikan tidak luntur. Ukuran cacat yang praktis adalah change fail rate dari DORA, yaitu bagian rilis yang langsung butuh tindakan seperti rollback atau hotfix (dora.dev).
Contoh DMAIC: hotfix setelah rilis aplikasi kasir
Angka di bagian ini ilustrasi, sengaja dibuat bulat agar mudah diikuti.
Define: 5 dari 12 rilis butuh hotfix
Dalam tiga bulan ada 12 rilis aplikasi kasir, dan 5 di antaranya harus ditambal dalam 48 jam. Change fail rate-nya 42%. Targetnya di bawah 15% pada tiga bulan berikutnya.
Measure: catat setiap hotfix di satu spreadsheet
Untuk tiap hotfix, tim menulis modul yang rusak, siapa yang pertama menemukan, dan berapa jam kasir terganggu. Tidak perlu software khusus.
Analyze: empat dari lima berasal dari modul harga
Diskon, PPN, dan pembulatan diubah tanpa tes otomatis. Data ujinya hanya memakai harga bulat seperti Rp20.000, jadi pembulatan Rp50 tidak pernah teruji sebelum sampai ke kasir.
Improve dan Control: tes, peninjau kedua, dan aturan tahan rilis
Modul harga diberi tes otomatis berisi 30 contoh struk nyata, termasuk diskon bertingkat dan pembayaran campuran tunai plus QRIS. Setiap perubahan di modul itu wajib ditinjau orang kedua. Change fail rate lalu ditampilkan per rilis di papan proyek, dan bila dua rilis berturut-turut butuh hotfix, rilis berikutnya ditahan sampai penyebabnya ketemu.
Bila tiga bulan berikutnya hanya 1 dari 10 rilis yang butuh hotfix, change fail rate menjadi 10%. Yang membuat angka itu bertahan adalah langkah Control, bukan semangat tim di minggu pertama.
Kapan Lean dan Six Sigma tidak perlu
Website company profile lima halaman yang dikerjakan tiga minggu tidak butuh DMAIC. Masalahnya terlalu sedikit untuk diukur, dan biaya pencatatannya lebih besar dari manfaatnya. Cukup pastikan tidak ada yang menunggu persetujuan berhari-hari.
Pakai Lean saat keluhan utama adalah "lama". Mulai DMAIC saat cacat yang sama muncul minimal tiga kali, karena di titik itu sudah ada data untuk dianalisis. Sertifikasi green belt atau black belt tidak diperlukan untuk menjalankan keduanya di proyek kecil. Satu spreadsheet dan satu orang yang rajin mencatat sudah cukup untuk memulai.
Metode proyek juga tetap perlu dipilih sendiri, misalnya lewat panduan waterfall vs agile, bersama pemahaman soal tahapan pengembangan aplikasi. Lean dan DMAIC bekerja di dalam alur itu, tidak menggantikannya.
Tiga angka yang bisa Anda minta dari vendor
Anda tidak perlu menguasai statistik untuk memakai cara berpikir ini sebagai pemilik proyek. Minta vendor atau tim internal melaporkan tiga angka setiap akhir bulan.
- Waktu rata-rata dari permintaan disetujui sampai fitur bisa dipakai, dalam hari kerja.
- Jumlah rilis bulan itu, dan berapa yang butuh rollback atau hotfix.
- Jumlah item yang menunggu keputusan dari pihak Anda, beserta umur item tertua.
Angka ketiga sering membuat kaget. Yang kami lihat saat membangun sistem untuk klien, antrean terpanjang justru sering ada di meja pemilik proyek: desain yang belum dikomentari, data produk yang belum dikirim, atau akses server yang belum diberikan. Vendor yang menolak memberi ketiga angka ini sama sekali patut ditanya alasannya.
Cara Zonaku menerapkannya
Saat membangun aplikasi kustom, kami memakai versi ringan dari keduanya. Ruang lingkup disepakati sejak awal, pekerjaan dibagi ke potongan kecil yang bisa didemokan, dan setiap rilis melewati tes otomatis dan manual. Setelah peluncuran, masalah yang muncul dievaluasi sampai ke penyebabnya. Dari sisi pembuat sistem, hal yang paling sering terlupa adalah data uji yang mirip data asli, seperti harga tidak bulat dan nama pelanggan dengan tanda kutip.
Langkah berikutnya: ambil satu permintaan perubahan terakhir di proyek Anda, isi tabel waktu kalender dan waktu kerja seperti contoh di atas, lalu bawa hasilnya ke rapat berikutnya. Bila ingin membahasnya bersama tim kami, hubungi Zonaku.