Lean Management Pada Software Engineering, Belajar dari Toyota
Pada software engineering, pasti pernah atau mungkin sering dengan kondisi: timeline mepet, perubahan dari sisi client, kejar-kejaran antara mengerjakan fitur dan memperbaiki bug, atau mungkin yang lebih ekstrim yaitu fixing satu bug malah memunculkan bug lain. Kalau hal ini terdengar akrab, kemungkinan masalahnya bukan pada seberapa keras tim bekerja, melainkan pada sistem kerjanya.
Di sinilah Lean Management relevan. Pendekatan yang lahir di lantai pabrik Toyota sang raksasa otomotif, ternyata juga bisa diterapkan untuk software engineering, karena masalah intinya sama yaitu bagaimana menghasilkan sesuatu yang bernilai, cepat, dan berkualitas dengan sumber daya terbatas.
Apa itu Lean Management
Lean Management adalah cara berpikir untuk memaksimalkan nilai bagi pelanggan sambil membuang pemborosan (waste). Akarnya ada di Toyota Production System (TPS), yang dikembangkan Taiichi Ohno pasca Perang Dunia II. Saat itu Toyota kekurangan modal dan tidak mampu meniru produksi massal ala Ford, sehingga mereka harus efisien sejak awal.
TPS berdiri di atas dua pilar:
- Just-in-Time: kerjakan hanya yang dibutuhkan, saat dibutuhkan, dalam jumlah kecil.
- Jidoka: hentikan proses begitu ada cacat, agar cacat tidak diteruskan ke tahap berikutnya.
Dari sana lahir lima prinsip Lean:
- Value: tentukan nilai dari sudut pandang pelanggan.
- Value Stream: petakan semua langkah proses, lalu pisahkan yang menambah nilai dari yang tidak.
- Flow: buat alur kerja mengalir tanpa hambatan atau antrean.
- Pull: produksi dipicu oleh permintaan nyata, bukan perkiraan.
- Perfection: perbaikan terus-menerus tanpa akhir.
Waste pada Software Engineering
Mary dan Tom Poppendieck pada bukunya Lean Software Development, memetakan pemborosan pada Toyota ke software engineer dari beberapa aspek seperti dibawah ini:
| Aspek | Toyota | Software Engineering |
|---|---|---|
| Inventory | Stok berlebih | Pekerjaan setengah jadi: Banyak fitur "in progress", kode belum di-deploy |
| Overproduction | Memproduksi lebih banyak atau lebih cepat dari kebutuhan. Ini dianggap pemborosan terburuk. | Fitur berlebih: Fitur "jaga-jaga" yang tidak pernah dipakai |
| Overprocessing | Pekerjaan melebihi yang dibutuhkan pelanggan | Relearning: Mempelajari ulang kode yang tidak terdokumentasi |
| Transportation | Perpindahan material yang tidak perlu | Handoff: Konteks hilang saat estafet PM → BA → developer → QA |
| Waiting | Menunggu proses, bahan, atau keputusan | Delay: Menunggu approval, review, atau akses |
| Motion | Gerakan pekerja yang tidak efisien | Task switching: Satu developer mengerjakan banyak task atau dipecah ke banyak proyek di satu waktu |
| Defects | Cacat yang menyebabkan pengerjaan ulang | Defect: Bug, salah tafsir requirement, revisi UAT |
Dari beberapa aspek diatas, yang paling sering di sepelekan oleh developer maupun tim project adalah task switching dan relearning karena keduanya tidak bisa dilihat oleh mata, melainkan diam-diam memakan kapasitas tim tanpa pernah muncul di laporan.
Kualitas di sumber: pelajaran dari Jidoka
Di pabrik Toyota, setiap pekerja boleh menarik tali andon untuk menghentikan production line begitu melihat cacat, kemudian manager dan pekerja lain membahas dan memperbaiki saat itu juga sebelum production line berjalan kembali. Kedengarannya memperlambat, tapi cacat yang ditemukan di sumber masalah menujukkan cost lebih murah daripada meneruskan pekerjaan dan berpotensi penumpukan menjadikan cost jauh lebih mahal. Cost disini artinya bisa banyak hal dari pemborosan bahan baku, tenaga, dan lain-lain.
Maka, inspeksi atau monitoring berkala merupakan hal yang tidak bisa dianggap remeh atau enteng. Menurut Shigeo Shingo, salah satu engineer Toyota saat itu, membedakan inspeksi atau monitoring menjadi tiga:
- Judgment inspection: memisahkan yang bagus dan yang cacat setelah dibuat.
- Informative inspection: cacat ditemukan, lalu informasinya dikirim balik ke sumber.
- Source inspection: memeriksa kondisi penyebab kesalahan sebelum kesalahan terjadi.
Pada software engineering, umumnya hanya mengandalkan Judgement inspection yaitu pengetesan oleh QA dan UAT di akhir development. Akibatnya bug ditemukan terlambat dan developer harus mengingat semua konteks terkait bug yg dilaporkan, ekstrimnya perbaikan dilakukan sambil terburu-buru. Dari sinilah lahir lingkaran "fixing satu, produce bug baru".
Informative inspection akan berfokus pada apa yang terjadi setelah bug ditemukan. Tentu seharusnya di fix, namun tidak berhenti disitu melainkan perlu ada pembahasan kenapa bug bisa lolos sehingga proses di hulu bisa diubah sesegera mungkin.
Pada Source inspection tim melakukan analisa kebutuhan terlebih dahulu sebelum development dilakuka, misalnya membuat checklist analisa dampak, peta dampak antar fitur, task yang jelas dan sudah dipahami oleh seluruh tim developer, code review, dan lain-lain. Menurut kalian, apalagi yang bisa dilakukan sebagai mekanisme pencegah kesalahan?
Praktik yang bisa langsung dicoba
- Petakan value stream. Ambil satu proyek yang sudah selesai, lalu catat waktu aktif dan waktu tunggu di setiap tahap, dari requirement sampai go-live.
- Batasi WIP (work in progress). Ini praktik dengan dampak terbesar. Semakin banyak pekerjaan yang dimulai bersamaan, semakin lambat semuanya selesai. Prinsipnya: stop starting, start finishing.
- Kerjakan dalam batch kecil. Serahkan requirement per fitur, lakukan demo dan UAT bertahap. Perubahan dari klien jadi jauh lebih murah.
- Buat standard work. Template requirement, Definition of Ready, dan Definition of Done. Standar bukan untuk mengekang, tetapi titik awal yang bisa diperbaiki seiring berjalan waktu.
- Ukur flow, bukan kesibukan. Pantau lead time, cycle time, throughput, dan rework rate. Gunakan untuk memperbaiki sistem, bukan menilai individu.
- Biasakan Kaizen. Retrospektif yang menghasilkan satu eksperimen perbaikan konkret, bukan sekadar daftar keluhan.
Hindari Hal Berikut
- Menganggap Lean sebagai kumpulan alat. Menggunakan Kanban atau Sprint tanpa membatasi WIP dan tanpa budaya perbaikan, hanya akan menghasilkan papan yang ramai.
- Mengejar utilisasi 100%. Tim yang selalu "penuh" justru membuat antrean memanjang. Sisakan ruang untuk menangani masalah.
- Mencari siapa yang salah. Ketika bug muncul, pertanyaannya bukan "siapa yang membuat kesalahan?", tetapi _"kenapa sistem kita membiarkannya lolos?".
Penutup
Lean Management bukan metodologi yang bisa digunakan dan implementasi dalam semalam. Melainkan kebiasaan untuk terus bertanya: apakah aktivitas ini memberi nilai bagi pelanggan?, dan di mana pekerjaan kita tertahan?.
Toyota menyebut dua fondasinya continuous improvement dan respect for people. Keduanya sama pentingnya di software engineering. Mulailah dari satu tim dan satu masalah nyata. Petakan, perbaiki sedikit, ukur, lalu ulangi.