Software developer selalu salah
If you want to Wow your customers, first you must Wow your software developers who will Wow the customer.
— Tom Peters
Kalau kamu adalah software developer, apakah kamu merasa kalau dunia serasa tidak adil karena kamu seringkali disalahkan bahkan untuk masalah yang berada di luar kendali kamu? Kenapa software developer seringkali disalahkan? Untuk menjawab pertanyaan tersebut kita harus terlebih dahulu belajar sejarah. Sekitar 100 tahun lalu dari artikel ini ditulis prinsip-prinsip dari Scientific Management buah karya dari Frederick Taylow menjadi popular dan digunakan di banyak perusahaan. Teori dari Scientific Management ini masih banyak dipakai oleh banyak perusahaan-perusahaan di Indonesia hingga hari ini. Bahkan teori manajemen yang diajarkan di bangku kuliah banyak didasari oleh prinsip Scientific Management. Kita akan lihat kalau di tahun 2017 ini teori dan prinsip Scientific Management ini sudah tidak relevan lagi dengan era digital. Salah satu pakar yang menganggap teori ini tidak relevan lagi adalah Peter Drucker yang banyak menentang teori dan prinsip Scientific Management di era pertengahan abad 20.
Ok sekarang mari kita lihat gambaran besar dari Scientific Management dan melihat kenapa model ini sudah tidak relevan dengan era digital. Teori Scientific Management membagi perusahaan menjadi dua bagian besar yakni: manajemen dan pekerja. Dalam Scientific Management, manajer berada di lapisan atas dan si pemikir yang memikirkan aturan dan kebijakan dalam perusahaan agar pekerjaan bisa selesai dengan cepat, siapa yang akan mengerjakan pekerjaan tertentu dan siapa yang paling bagus kerjanya. Posisi manajemen dipandang jauh lebih superior dibandingkan posisi si pekerja. Manajemen adalah orang-orang pintar yang terpilih untuk mengatur pekerja. Di sisi lain pekerja adalah orang-orang yang bekerja mengikuti aturan dan kebijakan yang sudah dibuat oleh manajemen. Harap diingat kalau Scientific Management pada mulanya banyak digunakan di pabrik dan pekerja mengacu pada para buruh pabrik. Di dalam model ini pekerja adalah pihak yang inferior karena pekerja cuma berfungsi mengikuti apapun yang sudah diperintahkan oleh manajemen. Dalam Scientific Management pekerja dipandang cuma sebagai resource. Dalam Scientific Management batasannya sangat jelas, manajemen tidak ikut proaktif memproduksi barang dan di sisi lain pekerja tidak perlu berpikir.
Berikut kira-kira gambaran dari Scientific Management.
Dalam Scientific Management, struktur perusahaan dibentuk seperti piramida dimana orang-orang yang berada diatas adalah yang membuat keputusan dan yang berada di lapisan paling bawah adalah orang-orang yang menghasilkan produksi. Dan model ini orang-orang yang berada di lapisan paling bawah tidak perlu berpikir karena pemikiran dan keputusan dibuat oleh orang-orang yang berada di atas. Sebagai pembuat keputusan, orang-orang yang berada di atas tidak pernah salah karena manajemen dianggap sebagai orang-orang pintar sehingga orang-orang di bawah sebagai pekerja harus menanggung kesalahan tersebut.
Ok sebelum kita lanjut, sekarang saya mau tanya ke kalian, apakah ada yang salah dengan model ini? Mayoritas orang yang saya tanyakan pertanyaan ini merasa tidak ada yang salah dengan model Scientific Management ini. Ketika kita sudah mengenal model yang sama selama seratus tahun lebih maka kita tidak merasa ada yang salah dengan model tersebut. Ketika hampir semua orang di Republik ini menggunakan model kerja seperti ini kita merasa tidak ada yang salah dengan model ini. Ketika teori ini adalah satu-satunya teori yang diajarkan di bangku kuliah, maka kita merasa tidak ada yang salah dengan model ini. Sampai ada seseorang yang mengatakan kalau selama ini yang kita lakukan sudah tidak sesuai dengan perkembangan jaman mungkin kita baru sadar kalau ada yang salah dengan model ini.
Leadership is adapting the work environment so everyone can contribute to solving the problems.
Rancangan struktur organisasi dari Scientific Management secara umum tidak berpihak kepada para pekerja. Pekerja dipandang sebagai orang yang tidak tahu apapun mengenai bagaimana bekerja secara produktif. Dalam kata lain, pekerja dipandang sebagai individu yang bodoh. Ketika pekerja melakukan kesalahan, yang salah adalah pekerja itu sendiri karena mereka tidak mengikuti instruksi detail dari manajemen. Dalam kondisi apapun instruksi dari manajemen tidak pernah salah karena manajemen memang dipandang sebagai seseorang yang superior. Dalam Scientific Management, apabila pekerja bekerja 100% sesuai instruksi dari manajemen secara religius, maka kesalahan tidak akan pernah terjadi.
Dari kaca mata Scientific Management: Software developers are not empowered to make decisions, bahkan termasuk tools yang akan mereka gunakan untuk menyelesaikan masalah. Pembuat keputusan hanya ada di lapisan atas struktur organisasi. Tetapi ketika keputusan yang dibuat ternyata tidak menghasilkan sesuai ekspektasi, karena manajemen sebagai pembuat keputusan juga memiliki political power, mereka juga dengan sangat mudah untuk mencari kambing hitam / scapegoat. Biasanya cara yang paling mudah untuk mencari kambing hitam adalah dengan menunjuk software developer. Karena memang secara struktur software developer berada di hirarki paling bawah di perusahaan. Ya mungkin setingkat lebih tinggi di atas office boy lah. Sudah ngerti kenapa di banyak universitas mahasiswa didoktrin kalau setelah lulus jangan terlalu lama menjadi software developer dan kenapa banyak software developer yang hingga hari ini meratapi nasibnya sebagai software developer kan?
In a modern organisation, everybody knows the root cause of a problem is not a person.
Dalam software development, software developer tidak selalu salah. Sistem korporasi yang merupakan turunan dari Scientific Management seringkali menjadi penyebab masalah atau kesalahan. Yang disalahkan dan dirubah harusnya adalah sistem korporasinya bukan software developernya. Mari kita lihat beberapa masalah yang bukan merupakan kesalahan software developer dan kenapa software developer bisa dipandang sebagai sumber kesalahan.
1. Bos dan kostumer selalu benar
Kalau kamu adalah software developer, sudah tahu kan alur cerita seperti ini:
- Manajemen meminta estimasi ke software developer;
- Lalu estimasi tersebut dijadikan deadline oleh manajemen;
- Software developer mulai bekerja semaksimal mungkin;
- Kostumer minta perubahan, tetapi deadline-nya tidak berubah;
Dari sini ada dua kemungkinan lanjutan ceritanya:
Kasus 1: Software developer lembur supaya deadline tercapai. Setelah deadline tersebut tercapai eeeh banyak bugs bermunculan di lingkungan. Software developer disalahkan karena dianggap tidak becus develop software.
Kasus 2: Software developer lembur tetapi deadline tetap tidak tercapai.
Tanggal rilis terpaksa jadi mundur. Software developer disalahkan karena dianggap tidak komitmen dengan estimasinya.
Tetapi dari runutan ceritanya, pernahkah kamu bertanya kenapa manajemen ataupun kostumer tidak pernah salah?
- Kenapa manajemen tidak salah ketika mereka mengkonversikan estimasi menjadi deadline? Sejak kapan estimasi adalah deadline? Setidaknya menurut kamus, estimasi bukan deadline. Estimasi ya cuma estimasi. Kenapa manajemen tidak pernah salah ketika mengkonversikan estimasi menjadi deadline?
- Kostumer tidak tahu apa yang dia mau sejak awal dan ingin bisa berubah pikiran di tengah proyek tetapi tetap menginginkan deadline agar tidak berubah. Dalam ilmu psikologi hal ini dinamakan cognitive dissonance. Kenapa kostumer tidak pernah salah ketika mereka memiliki cognitive dissonance?
Di dunia startup yang punya banyak ayunan pun keadaannya juga tidak jauh lebih baik. Di startup peran kostumer itu dipegang oleh Product Manager. Terkadang Product Manager tidak tahu produk yang dia kelola mau dibawa ke mana sehingga seringkali permintaannya berubah-rubah yang menyebabkan waktu software developer yang tersita untuk lembur. Terkadang Product Manager yang bersangkutan tidak benar-benar menjalani perannya sebagai seorang Product Manager dan kerjaannya cuma mengikuti apapun yang diminta oleh HiPPo (Highest Political Power) tanpa bisa mengatakan TIDAK.
Customer adalah Raja dan Bos selalu benar yang merupakan warisan dari sistem berpikir Scientific Management adalah alasan kenapa software developer tidak lain yang merupakan sumber segala macam kesalahan. Tidak perlu memiliki visi, karena kita bisa merubah-rubah keinginan kita, kalau tetapi tidak bisa selesai sesuai deadline, kita bisa salahkan software developer. Model Scientific Management mendukung sistem senioritas dimana yang lebih senior atau yang memiliki kekuatan politik lebih tinggi selalu menang.
2. Bad sales
An organisation will never be fully capable unless it’s fully human.
— Gary Hamel
Kalau kamu adalah software developer yang kerja di vendor, sudah tahu kan alur cerita seperti ini:
- Sales datang ke kantor kostumer untuk jualan;
- Kostumer: program kamu bisa begini begitu ga?;
- Sales: Bisa Pak.
- Kostumer: berapa lama bisa selesai?;
- Sales: Sebulan juga bisa Pak (sambil mengumbarkan janji-janji surga lainnya kepada kostumer agar sales bisa di-closing);
- Catatan: Tidak ada satu software developer pun yang dimintai pendapatnya dan terlibat dalam pembicaraan di atas.
Ketika sales mendapatkan kostumer yang tidak realistis dalam memberikan ruang lingkup pekerjaan dan deadline apakah sales pernah disalahkan? Tentu saja tidak. Justru bos akan menganggap dia sebagai pahlawan yang sudah membawa masuk revenue ke dalam perusahaan. Ketika proyek tidak realistis sudah masuk perusahaan, cerita selanjutnya ya deritanya para software developer bukan menjadi tanggung-jawab sales lagi. Karena key performance indicator (KPI) orang sales adalah mencari kostumer sebanyak mungkin untuk meningkatkan revenue perusahaan, terlepas apakah kostumernya realistis atau tidak. Sistem KPI turunan dari Scientific Management seperti ini sangat tidak berpihak kepada software developer.
Scientific Management yang mengajarkan manajemen untuk memisahkan departemen berdasarkan fungsi dan memberikan key performance indicator (KPI) untuk masing-masing departemen tersebut. Hingga hari ini kita tidak melihat ada yang salah dengan model ini. Tetapi seringkali model ini menyebabkan tidak adanya pandangan secara holistik dan adanya persaingan dan ketidak-pedulian antar departemen. Masing-masing departemen hanya peduli dengan KPI-nya masing-masing terlepas apakah KPI tersebut dapat menyebabkan tidak adanya keselarasan (alignment) dengan departemen lain.
3. Tools atau vendor yang salah
Kalau kamu adalah software developer yang kerja di end-user ataupun di pemerintahan, pasti sudah tahu kan alur cerita seperti ini:
- IT meminta vendor untuk membuat proof of concept;
- IT sudah mendapatkan vendor yang sesuai;
- Procurement lalu membuka tender proyek ke para vendor;
- Procurement ternyata memilih vendor lain yang lebih murah dan pandai membuat karangan indah di proposal walaupun vendor tersebut tidak sesuai dengan pilihan yang sudah dibuat IT;
Procurement memiliki key performance indicator (KPI) untuk mencari vendor dengan harga termurah. Proses procurement di banyak korporasi kalau boleh jujur sangat scuks, tidak relevan dengan konteks software development. Banyak orang procurement yang tidak tahu apapun tentang software development. Mereka berpikir satuan kerja software development bisa dipukul-rata seperti di dunia konstruksi bangunan. Mereka pikir semua software developer sama bagusnya sama seperti kuli bangunan yang sudah menjadi komoditas. Mereka hanya memilih vendor berdasarkan apa yang ditulis vendor di atas kertas. Akhirnya celah ini seringkali dimanfaatkan oleh para vendor ketika mengikuti proses tender dengan fokus membuat karangan indah pada proposal asal mereka bisa lolos tender.
- Ketika proyek menjadi telat karena ternyata integrasi antar sistem dari vendor terpilih ke sistem yang sudah ada menjadi kompleks atau membutuhkan learning curve yang lebih tinggi, apakah procurement disalahkan? Tentu saja tidak.
- Ketika proyek menjadi telat karena ternyata vendor terpilih sangat politis dan berbelit-belit dan ternyata tidak bisa deliver, apakah procurement pernah disalahkan? Tentu saja tidak.
- Ketika proyek ternyata menjadi lebih mahal dari perencanaan mula-mula karena vendor terpilih memberikan harga yang cukup fantastis untuk setiap change request, apakah procurement pernah disalahkan? Tentu saja tidak.
Ketika proyek gagal karena procurement salah memilih vendor atau memilih tools, ujung-ujungnya yang disalahkan adalah software developernya. Procurement aman dari kesalahan karena mereka sudah memenuhi KPI-nya yakni memilih vendor atau tools dengan harga semurah mungkin. Terlepas mereka memilih vendor atau tools yang salah sudah merupakah deritanya software developer.
Sistem KPI antar departemen di banyak perusahaan seringkali bentrok dan tidak mengarahkan antar departemen mencapai satu visi yang sama. Karena goal dari Scientific Management adalah efisiensi bukan alignment antar departemen. Model Scientific Management membentuk silo organisation yang hanya peduli dengan KPI-nya masing-masing.
Selain sistem KPI yang scuks, sistem procurement dan sistem tender proyek untuk proyek software development di banyak perusahaan dan di pemerintahan scuks dan perlu direvolusi. Sistem procurement ini scuks karena:
- Menganggap semua software developer sama.
- Hanya melihat kulitnya atau tampilan luar saja, tidak menyadari kalau tida semua sistem memiliki codebase yang sama.
- Secara umum menganggap proyek software development bisa disamakan dengan proyek konstruksi jembatan layang.
We invented management, we can re-invent it.
— John Seddon
Contoh-contoh di atas cuma sebagian kasus dimana software developer seringkali disalahkan padahal yang salah adalah bobroknya sistem korporasi. Sebagai manajemen dan kostumer, kita harus menyadari kalau kita juga tidak sempurna, kita sering membuat keputusan yang salah, kita tidak tahu apa yang kita mau. Sistem manajemen yang kita gunakan telah membuat orang-orang antar departemen hanya memikirkan kepentingannya masing-masing. Sangatlah egois kita sebagai manusia kalau semua kesalahan itu harus ditanggung oleh software developer. Kita harus berani dan rendah hati untuk merubah sistem manajemen dogma lama turunan dari Scientific Management yang tidak mendukung kolaborasi yang menyebabkan pihak software developer selalu kalah di perusahaan kita. Jaman sudah berubah, oleh karena itu cara kita mengelola software developer juga harus relevan dengan jaman dimana kita hidup saat ini.
Software developer di abad 21 ini sudah semestinya dipandang sebagai partner atau konsultan dalam mencapai goal dari perusahaan bukan sebagai seseorang yang dipandang rendah seperti buruh pabrik atau kuli bangunan, bukan menjadi kambing hitam setiap kali ada masalah. Realitanya software developer adalah orang cerdas, mereka berpikir menggunakan logika, oleh karena itu kita harus memperlakukan mereka sebagai orang pintar bukan sebagai kuli bangunan. Dogma yang memandang software developer adalah pekerjaan rendahan harus dibuang jauh-jauh ke lautan yang dalam.
Di tulisan berikutnya saya akan menuliskan bagaimana ekosistem software development yang ideal dan bagaimana kita bersama bisa membawa perubahan dan membentuk ekosistem yang ideal tersebut.
Apakah kamu termasuk salah satu software developer yang sering disalahkan di perusahaan? Ingin membuat perubahan di ekosistem software development Indonesia? Jangan lupa untuk menekan tombol 👏🏻 di bawah sebanyak mungkin agar lebih banyak orang di Indonesia dapat melihat artikel ini dan ekosistem software development di Indonesia bisa menjadi jauh lebih baik. Sebarkan artikel ini di sosial media ataupun email list / slack room. Artikel ini adalah sekelumit pemikiran saya untuk buku saya yang kedua.
