- Tim engineering sering mendapat tekanan untuk "merilis lebih banyak fitur lebih cepat"
- Namun, jika terlalu banyak pekerjaan dikerjakan secara bersamaan, produktivitas justru menurun
- "Rahasia untuk merilis lebih banyak justru adalah melakukan lebih sedikit" -
Less is More
Prinsip inti
- Memvisualisasikan semua pekerjaan
- Mendefinisikan pekerjaan dalam unit kecil
- Membatasi pekerjaan yang sedang berlangsung
- Mengalokasikan sumber daya sesuai kapasitas
- Bonus: menyisakan ruang longgar untuk hal-hal yang tak terduga
# Memvisualisasikan semua pekerjaan
- Dengan memvisualisasikan pekerjaan, tim bisa melihat realitas secara langsung
- Jika semua pekerjaan terlihat dalam satu pandangan, ada keuntungan berikut
- Dapat menetapkan prioritas dengan jelas
- Dapat menghentikan atau menjeda pekerjaan yang tidak perlu
- Tim dapat fokus menyelesaikan pekerjaan yang sudah dimulai
- Tujuannya bukan melacak semua pekerjaan selamanya → melainkan memahami kondisi nyata dengan jelas dan membuat keputusan yang lebih baik
# Mendefinisikan pekerjaan dalam unit kecil
- Jika pekerjaan terlalu besar, energi tim terkuras dan kemajuan menjadi tidak jelas
- Batasi ukuran pekerjaan menjadi sekitar 1–2 minggu
- Developer dapat menjaga motivasi melalui pencapaian jangka pendek
- Bisa menerima umpan balik dengan cepat dan segera melakukan perbaikan
- Keuntungan unit kerja kecil
- Code review menjadi lebih mudah
- Berbagi pengetahuan terjadi secara alami
- Kolaborasi antar anggota tim menjadi lebih kuat
- Risiko deployment menurun
- Mengurangi ukuran unit kerja akan mempercepat laju kerja → tim bisa menjaga momentum tanpa kewalahan oleh fitur yang kompleks
# Membatasi pekerjaan yang sedang berlangsung
- Menangani banyak fitur sekaligus justru menurunkan produktivitas
- Ada biaya perpindahan konteks → butuh hingga 23 menit untuk beradaptasi ke pekerjaan baru
- Semakin banyak pekerjaan yang sedang berlangsung, semakin besar kemungkinan muncul masalah berikut
- Kualitas menurun
- Bug bertambah
- Moral tim turun
- Tanda kelebihan beban di level tim
- Lebih dari 4 pekerjaan per developer
- Waktu penyelesaian lebih lama dari perkiraan
- Fitur yang sedang dikerjakan lebih banyak daripada fitur yang selesai
- Tanda kelebihan beban di level individu
- Konsentrasi menurun
- Waktu respons code review meningkat
- Sulit menjelaskan prioritas dalam rapat status
# Mengalokasikan sumber daya sesuai kapasitas
- Pendekatan "satu developer menangani satu fitur" tidak efisien
- Fokuskan sumber daya tim pada pekerjaan yang paling penting
- Kolaborasi menguat → kecepatan pemecahan masalah meningkat
- Kualitas kode meningkat → peer review real-time menjadi aktif
- Kecepatan penyelesaian pekerjaan meningkat
- Para developer bisa memperoleh pemahaman yang lebih mendalam melalui kolaborasi
- Perlu mendorong hasil di tingkat tim → fokus pada kinerja tim, bukan kinerja individu
# Menyisakan ruang longgar
- Beroperasi pada kapasitas 100% justru menurunkan hasil
- Pekerjaan tak terduga tidak bisa dihindari → yang tidak pasti hanyalah kapan itu terjadi
- Masalah yang muncul jika tidak ada ruang longgar
- Tim bekerja secara reaktif
- Kualitas menurun
- Inovasi berkurang
- Utang teknis meningkat
- Jika ada ruang longgar, manfaatnya antara lain
- Dapat merespons masalah tak terduga dengan fleksibel
- Memungkinkan pemecahan masalah yang kreatif
- Menjaga kualitas tetap tinggi
- Menjaga ritme kerja yang berkelanjutan
- Ruang longgar yang tepat sekitar 20% → dapat disesuaikan menurut karakteristik tim
Ringkasan strategi inti
- Visualisasikan pekerjaan → agar bisa melihat realitas dengan jelas
- Definisikan pekerjaan dalam unit kecil → menjaga momentum
- Batasi pekerjaan yang sedang berlangsung → meningkatkan fokus
- Alokasikan sumber daya sesuai kapasitas → fokus sesuai prioritas
- Sisakan ruang longgar → menjaga fleksibilitas
Kesimpulan
- Untuk melakukan lebih banyak pekerjaan, dibutuhkan strategi melakukan lebih sedikit
- Kinerja tim diukur bukan dari berapa banyak fitur yang ditangani secara bersamaan, melainkan dari seberapa efektif nilai diberikan kepada pelanggan
- Peran pemimpin bukan menambahkan lebih banyak pekerjaan ke tim, tetapi menghilangkan pekerjaan yang tidak perlu
12 komentar
Cerita serupa juga muncul di buku <The Phoenix Project> yang sudah beberapa kali disebut di GeekNews. Semakin mendekati kapasitas 100%, waktu respons akan bertambah secara eksponensial.
Oh. Pembahasan itu juga muncul di buku Goal!
<The Phoenix Project>sendiri memang ditulis sebagai versi IT dari<The Goal>.Wah........ terima kasih!!
Kami berusaha menyisakan 80% untuk pekerjaan dan 20% sebagai ruang longgar, tetapi setiap kali tetap bingung harus memakai patokan apa.. Kadang juga terpikir apakah sebaiknya dihitung hanya berdasarkan waktu saja.
Jadi, saya memang mengosongkan Jumat sore sepenuhnya untuk waktu pengembangan pribadi!
Kalau dipecah menjadi task sekecil ini, pemimpin yang memegang gambaran besar jadi punya wewenang yang besar. Para engineer yang bekerja bersama justru kehilangan motivasi dan menjadi berpikir, "sebenarnya kita ini menuju ke mana?" Ini salah satu kelemahan paling khas dari agile berbasis sprint.
Tulisan ini rasanya terlalu ditulis hanya dari sudut pandang pemimpin, persis seperti judulnya.
Momentum engineer juga sangat dipengaruhi oleh ke arah mana pemimpin mengibarkan benderanya. Perlu dipikirkan lebih jauh juga tentang bagaimana cara menunjukkan nilai seperti apa yang ingin diberikan kepada pelanggan, serta apa output dan delivery outcome di setiap sprint. Tentu ini soft skill yang sulit, jadi memang jarang melihat pemimpin yang benar-benar melakukannya dengan baik, dan tulisan tentang ini juga tidak banyak.
Saya sangat setuju dengan komentar ini. Ada/sempat ada risiko terjadinya micromanagement pada bagian teknis. Memang tidak mudah.
Bukankah kuncinya adalah membagikan gambaran besar, memastikan semua orang memahaminya, lalu memecah pekerjaan menjadi tugas-tugas kecil??
Jika dibagi menjadi 1–2 minggu, tampaknya secara alami hanya orang-orang tertentu yang akan mengetahui gambaran tentang satu fitur. Seperti perbedaan antara proses dan thread. Produktivitas ditingkatkan dengan membatasi fokus.
Bahkan jika gambaran itu dibagikan, ini memang berangkat dari asumsi bahwa orang akan mempertanyakannya, tetapi tampaknya saya juga secara alami membuat asumsi bahwa saya tidak bisa mengikuti bagaimana gambaran besarnya dilacak sesuai arah yang sedikit demi sedikit berubah di setiap sprint planning.
Saya sepenuhnya setuju dengan poin yang diajukan dalam tulisan ini, sekaligus setuju dengan masalah yang Anda sampaikan.
Ini juga merupakan poin yang benar-benar sedang saya pikirkan.
Memang berbeda di tiap squad, tetapi jika anggota tim dilibatkan secara aktif dalam sprint planning, masalah yang Anda sebutkan itu tidak benar-benar muncul. Sambil membagikan konteks proyek dan situasi yang berubah di setiap sprint agar mereka bisa cukup menyadari perubahan pekerjaan, saya juga meminta agar pekerjaan dibagi dan dipecah dengan sangat rinci.
Seperti yang Anda katakan, dari sisi pengelolaan, kalau memikirkan progres, pengukuran kecepatan kerja, penanganan situasi tak terduga, dan biaya peluang ketika isi pekerjaan tidak berjalan sesuai maksud, pada akhirnya memang pekerjaan perlu dipecah kecil-kecil agar bisa berjalan dengan baik.
Tulisan serupa terus berulang, tetapi keserakahan manusia tak ada habisnya dan kita mengulangi kesalahan yang sama.
Beban CPU komputer 100% bukanlah kondisi normal,
tetapi untuk beban kerja manusia, malah muncul kesimpulan bahwa kita harus bekerja lebih keras..