"The Pareto Principle" Pada Software Engineering

English Version 👇

Dalam dunia pengembangan perangkat lunak, kita seringkali dihadapkan dengan berbagai pilihan yang harus segera dieksekusi dengan tenggat waktu tertentu. Tidak hanya sekedar dihadapkan oleh berbagai pilihan, bahkan dibombardir dengan banyak sekali pilihan. Ini membuat prioritas hanya semu semata. Kelincahan dan fokus Tim kita menjadi terpecah karena harus bergerak ke berbagai arah.

Dalam buku “Essentialism” yang ditulis oleh Greg Mckeown, fokus individu / tim yang terpecah ke berbagai arah digambarkan seperti ini.

Greg menjelaskan bahwa mengerjakan suatu hal “Lebih sedikit lebih baik”. Kita sebagai pemimpin suatu tim pengembang, mempunyai kuasa untuk memutuskan mau dibawa kemana tim tersebut, bagaimana tim ini berjalan dan seberapa cepat. Sebagai pemimpin juga sadar bahwa “Individu di dalam tim kita juga berhak memutuskan mau kemana dan bagaimana mereka akan berjalan”.

Dengan banyaknya backlog dengan berbagai prioritas dan dinamika yang ada di dalam tim kita perlu memikirkan strategi untuk membuat kinerja tim kita tetap baik (productive) dan berjalan secara optimal (perform). Ada banyak cara, salah satunya adalah prinsip pareto “The Pareto Principle” adalah sebuah fenomena dimana 80% hasil berasal dari 20% akibat atau secara sederhananya memberikan 20% effort untuk menghasilkan 80% hasil. Prinsip ini memungkinkan kita sebagai pemimpin (leader) dan tim pengembang untuk lebih fokus untuk meluangkan waktu dan energi untuk berinovasi dan mengerjakan hal-hal yang sangat vital (the vital few)

Sayangnya dalam praktiknya justru terbalik. Tim kita terlalu banyak fokus dan prioritas (80% effort) namun memberikan hasil yang sedikit (20% result/outcomes). Dalam sebuah publikasi The Developer Coefficient yang diterbitkan oleh Stripe pada tahun 2018 menunjukan bahwa developer meluangkan waktu mereka selama 17.3 jam per minggu untuk melakukan debugging, maintenance, refactoring.

Dari hasil publikasi tersebut, developer juga mengaminkan bahwa mereka terlalu banyak berjibaku dengan bad code.

Ketika kita berbicara mengenai bad code, maka tidak jauh dari aktifitas refactoring atau tidy up code yang mana aktifitas ini bersifat endless (tanpa batas). Disamping itu, mereka juga dihadapkan dengan tenggat waktu dari massive product backlog yang harus segera diselesaikan, target OKR dan KPI, supporting, bug fixing dari laporan customer, dan research.

Alhasil di akhir kuartal; 90% Product Backlog terdeliver, 10% sisanya masih tertinggal di dalam Todo List, 60% darinya terdeliver diluar tenggat waktu (delay), Incident Rate meningkat 50% yang artinya terlalu banyak deffect didalam produknya, customer satisfaction menurun 2 point, review Google Play Store menurun dari 4.0 menjadi 3.5. Padahal kita tahu mereka sudah berjuang sampai menyentuh limitnya, namun hasilnya tidak cukup memuaskan.

Dari sini sepertinya saya (dan bahkan anda) sepakat bahwa “Banyak Pekerjaan bukan berarti Produktif”, atau “Overtime bukan berarti menjamin tim kita bisa mencapai tujuan” 

Dalam penerapan The Pareto Principles ini tidaklah mudah, dan pastinya akan