Kebanyakan orang telah terkena aturan 80/20 di beberapa titik dalam hidup mereka. Ini banyak digunakan untuk menunjukkan bahwa dengan 20% dari usaha Anda, Anda dapat mencapai 80% dari hasil yang Anda inginkan. Aturan tersebut sering dirujuk dalam konteks apakah layak untuk mencoba mendapatkan hasil 100%, pertama kali.
Aturan 80/20 sering tidak sesuai dengan lingkungan yang digerakkan oleh proses. Di banyak (jika tidak semua) organisasi besar ada proses terdokumentasi untuk mencapai tugas tertentu. Ini terutama berlaku di 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 (mudah-mudahan) 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 bagus untuk menulis, menerapkan, dan mematuhi proses.
Masalah dengan proses adalah, bagi sebagian orang, mereka menjadi kitab suci yang darinya orang tidak akan menyimpang. 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 telah tersapu ke dalam lubang hitam. Karena itu kreativitas individu tertahan pada rintangan pertama.
Bayangkan Anda dalam situasi di mana Anda mengelola sebuah proyek. Untuk alasan apa pun, Anda terlambat dari jadwal. Anda tidak dapat memundurkan tanggal pengiriman Anda untuk memberi kompensasi sehingga satu-satunya cara Anda untuk mitigasi 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 untuk mengambil jalan pintas. Sekarang sebelum Anda mengucapkan “manajer proyek koboi” pelan-pelan, baca lebih lanjut.
Tidak ada yang salah dengan mengambil jalan pintas selama Anda mengidentifikasi risiko yang Anda ambil/ciptakan saat melakukannya, dan Anda mengelolanya sesuai dengan itu. Anda mengambil pandangan pragmatis tentang cara memenuhi batasan waktu Anda (dalam contoh ini) dan bersikap 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 kreatifitas ini, berani saya katakan “think out of the box” karena karyawan harus berpegang pada proses. Selain itu, proyek TI memakan waktu lebih lama dari yang seharusnya.
Sebagai penutup, saya diingatkan akan kesenangan melihat Brent Hoberman berbicara. Dia berbicara tentang implementasi Menit Terakhir dan bagaimana, karena hype media yang masif, tidak ada pilihan untuk tidak mengirimkannya pada tanggal yang dipublikasikan. Ada masalah IT, bug dimana-mana. Tidak masalah, tetap tayangkan, minta pengembang (mungkin banyak dari mereka) berbaris siap untuk memperbaiki bug dengan cepat dan menjalankan perbaikan dan bereaksi dengan cepat. Hebat, saya berharap bisa menjadi bagian dari tim. Pasti ada saat-saat yang “menarik”, tetapi juga kepuasan yang luar biasa ketika kesuksesan terwujud.