Aturan 80/20, Proses dan Pragmatisme

Kebanyakan orang telah terkena aturan 80/20 di beberapa titik dalam hidup mereka. Ini banyak digunakan untuk menunjukkan bahwa untuk 20% dari usaha Anda, Anda dapat mencapai 80% dari hasil yang Anda inginkan. Aturan sering dirujuk dalam konteks apakah layak untuk mencoba mendapatkan hasil 100%, pertama kali.

Aturan 80/20 sering tidak sesuai dengan lingkungan yang didorong oleh proses. Di banyak (jika tidak semua) organisasi besar ada proses terdokumentasi untuk mencapai tugas tertentu. Hal ini terutama berlaku dalam departemen TI. Ada proses untuk membangun perangkat keras baru, untuk menginstal perangkat lunak & lainnya & lainnya, untuk mentransfer data dan daftarnya terus berlanjut. Proses, Proses, Proses!

Semua proses ini melayani tujuan yang baik. Pertama, mereka (semoga) dikembangkan dari pengalaman kesalahan dan dicoba, diuji dan dianggap kuat. Kedua, jika mereka diikuti, mereka memastikan konsistensi pekerjaan untuk tugas yang diberikan. Masing-masing adalah alasan yang sangat baik untuk membuat, menerapkan, dan mengikuti proses.

Masalah dengan proses adalah bahwa, bagi sebagian orang, mereka menjadi kitab suci yang tidak akan diselewengkan orang. Selain itu, mereka memberikan penghalang di mana orang dapat bersembunyi dan tidak bertanggung jawab atas tindakan mereka.

Mari kita fokus pada yang pertama. Jika proses diimplementasikan tanpa rute pengecualian yang dapat dicapai/praktis, maka harapan pragmatisme apa pun baru saja tersapu ke dalam lubang hitam. Karena itu kreativitas individu terhambat pada rintangan pertama.

Bayangkan Anda dalam situasi di mana Anda mengelola sebuah proyek. Untuk alasan apapun, Anda berada di belakang jadwal. Anda tidak dapat memundurkan tanggal pengiriman Anda untuk mengkompensasi dan satu-satunya cara Anda untuk menguranginya adalah dengan mengurangi waktu pengiriman Anda. Anda mungkin memiliki sejumlah opsi sehubungan dengan kerja paralel dan/atau lebih banyak sumber daya untuk menyebutkan dua, yang lain mungkin mengambil jalan pintas. Sekarang sebelum Anda lari sambil mengucapkan “manajer proyek koboi” dengan pelan, bacalah sedikit lagi.

Tidak ada yang salah dengan mengambil jalan pintas selama Anda mengidentifikasi risiko yang Anda ambil/buat dalam melakukannya, dan Anda mengelolanya sesuai dengan itu. Anda mengambil pandangan pragmatis tentang bagaimana memenuhi batasan waktu Anda (dalam contoh ini) dan menjadi fleksibel.

Ada beberapa dikotomi di sini;

1. Hampir menurut definisi, proses tidak fleksibel.

2. (umumnya) Organisasi yang memiliki banyak proses tidak mengambil risiko

Dampak negatif dari semua ini adalah ada perusahaan yang menghambat kreativitas ini, berani saya katakan “thinking out of the box” karena karyawan harus patuh pada proses. Selain itu, proyek TI membutuhkan waktu jauh lebih lama dari yang dibutuhkan untuk disampaikan.

Untuk mengakhiri, saya diingatkan untuk bersenang-senang melihat Brent Hoberman berbicara. Dia berbicara tentang implementasi Menit terakhir dan bagaimana, karena hype media besar-besaran, tidak ada pilihan untuk tidak mengirimkan pada tanggal yang dipublikasikan. Ada masalah TI, bug di mana-mana. Tidak masalah, tetap tayangkan, minta pengembang (mungkin banyak dari mereka) bersiap untuk memperbaiki bug dengan cepat dan menempatkan perbaikan secara langsung dan bereaksi dengan cepat. Hebat, saya berharap saya bisa menjadi bagian dari tim. Pasti ada saat-saat yang “menarik”, tetapi juga kepuasan yang luar biasa ketika kesuksesan terwujud.



Aturan 80/20, Proses dan Pragmatisme
Kembali ke Atas