5 kontradiksi dalam ekosistem software development Indonesia
cognitive dissonance (n): psychological conflict resulting from incongruous beliefs and attitudes held simultaneously
cognitive dissonance (n): is the mental stress (discomfort) experienced by a person who simultaneously holds two or more contradictory beliefs, ideas, or values; when performing an action that contradicts one of those beliefs, ideas, or values; or when confronted with new information that contradicts one of the beliefs, ideas, and values
Saya agak kesulitan mencari arti kata cognitive dissonance dalam bahasa Indonesia. Cognitive dissonance seperti kontradiksi di dalam batin seseorang karena apa yang dia lakukan sering kali tidak sesuai dengan apa yang dia percayai. Cognitive dissonance sering sekali terjadi dalam software development. Menurut wikipedia, cognitive dissonance merupakan salah satu gangguan jiwa. Sepanjang artikel ini saya akan menggunakan kontradiksi sebagai kata ganti cognitive dissonance untuk menyederhanakan.
Harapan pimpinan perusahaan, manajer dan kostumer yang menggunakan jasa software developer seringkali bertolak-belakang dengan apa yang dia percayai. Kenapa cognitive dissonance bisa terjadi dalam software development? Singkat kata, karena banyak orang hingga hari ini masih mengganggap software development sama seperti proyek konstruksi bangunan.
Tarik-menarik di dalam batin kita pada saat berada dalam konteks software development sering sekali terjadi. Perilaku kita sering kali tidak menggambarkan apa yang kita harapkan, perilaku kita lebih sering ketarik ke kutub apa yang kita percayai. Energi untuk tetap bertahan dengan apa yang kita percayai lebih kuat dibandingkan energi untuk meninggalkan kepercayaan lama agar bisa mencapai harapan. Ketika kepercayaan kita lebih kuat daripada keinginan kita, akhirnya kita terperangkap dalam sebuah dogma. Our own belief sometimes becomes an obstacle to reach what we hoped for. Dogma yang akhirnya membuat kita memandang bahwa harapan kita ternyata hanyalah sebuah fatamorgana. Sungguh ironis bukan?
Dalam ekosistem software development cognitive dissonance seringkali terjadi. Akhirnya kita terperangkap dalam dogma kita sendiri, harapan kita yang begitu tinggi akhirnya kita pandang sebagai sebuah utopia saja.
1. Kita ingin prediktabilitas tetapi kita ingin adaptabilitas
A guarantee in this life: Change! Flexibility is better than predictability!
― Evinda Lepins
Perencanaan yang kita buat seringkali berdasarkan informasi yang terbatas mengenai masa depan, kita mengira dengan semakin lama kita membuat perencanaan masa depan tidak ikut bergerak dan kepastian akan semakin bisa kita dapatkan. Kita membuat perencanaan berdasarkan asumsi naif kita mengenai masa lalu, kita mengira sejarah akan terulang lagi secara persis, kita mengira masa depan adalah ekstrapolasi dari masa lalu. Mungkin juga kita bisa seperti ini karena tidak pernah memperhatikan guru sejarah sewaktu dulu sekolah.
Kita merasa tidak nyaman dengan ketidak-pastian oleh karena itu kita menginginkan estimasi yang akurat dari software developer, kita merasa terkhianati apabila delivery tidak sesuai estimasi yang telah mereka berikan, namun seringkali kita juga yang sering kali membuat delivery menjadi terlambat lewat pembuatan keputusan yang lama dikarenakan perdebatan politik di perusahaan maupun dengan banyaknya gangguan dan selipan pekerjaan sepanjang development.
Sebuah kontradiksi terjadi ketika kita ingin agar nilai kontrak proyek bernilai tetap dengan fixed deadline dan fixed scope tetapi di satu sisi kita ingin ada fleksibilitas untuk merubah-rubah ruang lingkup pekerjaan sepanjang development. Keinginan kita untuk bisa adaptable dengan masa depan sudah merupakan bentuk manifestasi kalau sebenarnya kita tidak tahu apa yang kita mau. Tetapi kita terlalu sombong untuk mengakui kalau kita sebenarnya tidak tahu apa yang kita mau, kita mau meletakkan kebodohan di pihak software developer dengan mengatakan mereka tidak bisa deliver software sesuai yang kita mau. Kita tahu ketika kita tidak tahu apa yang kita mau maka nilai kontraknya juga harus fleksibel atau tidak bisa dikunci. Karena kita tidak mau rugi, kita meletakkan kerugian di sisi developer dengan banyak lembur. Hehehe. Keren kan cara berpikirnya?
Dalam hukum alam, air selalu mengalir ke titik yang lebih rendah. Dalam hukum alam kita tidak berusaha untuk mendorong air di sungai untuk mengalir ke atas karena kalau kita melakukan hal tersebut kita bisa dikatakan banyak orang sebagai orang gila. Bahkan fisikawan pun tidak berusaha untuk melakukan itu, mereka membiarkan alam bekerja sebagaimana mestinya. Permasalahan terjadi ketika kita berusaha membuat masa depan menjadi pasti padahal kita tahu kepastian hampir sudah tidak ada lagi di abad 21. Mungkin karena tidak ada yang menganggap kita gila bila membuat masa depan menjadi pasti makanya kita tetap melakukannya hingga hari ini. Hehehe.
Kontradiksi mengharapkan kepastian namun realitanya sering meminta perubahan di sepanjang proyek seringkali menyusahkan hidup software developer dan merupakan kontradiksi terbesar dalam software development hingga hari ini. Software developer jadi seringkali harus lembur karena ada perubahan mendekati akhir proyek namun kostumer tetap ingin nilai kontraknya tetap, bahkan kostumer yang ganas juga akan memberikan denda kepada vendor yang tidak bisa deliver sesuai estimasi. Dan karena si bos juga tidak mau rugi, si developer disuruh lembur agar mereka saja yang rugi.
2. Kita ingin tim yang self-managed tetapi kita ingin tetap memiliki kontrol terhadap tim
Managers love empowerment in theory, but the command-and-control model is what they trust and know best.
— Chris Argyris
Banyak pimpinan perusahaan yang mengatakan ke saya kalau mereka mengimpikan sebuah tim yang bisa self-managed. Namun orang yang mengatakan hal ini seringkali tidak serius dengan omongannya sendiri. Realitanya pimpinan perusahaan seperti ini memiliki perilaku yang kontradiktif dengan apa yang mereka impikan, mereka tidak menyediakan sebuah lingkungan kerja dimana orang-orang di perusahaan mereka bisa self-managed.
Sebagai pimpinan perusahaan kita seringkali meng-override keputusan yang dibuat oleh pekerja kita yang akhirnya seringkali membuat orang-orang di perusahaan menjadi trauma untuk self-manage membuat keputusan karena ia tahu keputusannya akan di-override lagi. Hal ini bukan hanya terjadi di korporat, tetapi juga di startup-startup yang punya banyak ayunan dan punya lapangan mini-golf. Di startup-startup keputusan Product Manajer seringkali di override oleh para petinggi perusahaan dan investor. Self-management tidak akan terjadi apabila kita selalu override keputusan orang-orang. Daripada memberikan instruksi dengan model top-down, sebagai pimpinan perusahaan lebih baik bila kita berusaha menjual ide kita ke orang-orang di perusahaan agar mereka bisa mengambil ownership terhadap pekerjaan yang akan mereka lakukan.
Sebagai pimpinan perusahaan kita suka micro-manage software developer yang tentu saja kontradiktif dengan harapan kita agar software developer bisa self-manage. Kita tidak memberikan ruang kreatifitas untuk mereka. Kita menciptakan sebuah lingkungan kerja dimana orang-orang akan memandang bahwa Bos selalu benar dan akhirnya orang-orang pun memiliki perilaku “Asal Bapak Senang”. Self-managed team tidak akan terjadi apabila kita masih melakukan micromanagement. Kalau kita ingin tim yang self-managed kita harus berani untuk melepaskan kontrol dan memberikan kontrol kepada orang-orang. Bila kita sebagai pimpinan perusahaan terbiasa mendapatkan apapun yang kita inginkan dalam bisnis kita dengan tangan besi, maka akan sangat sulit bagi kita untuk bisa memberikan kontrol kepada orang-orang kita sendiri dan menerima cara berpikir ini.
Selain micro-management dan keputusan orang-orang yang seringkali di-override, lingkungan yang saling menyalahkan juga seringkali membuat orang tidak berani untuk self-managed karena mereka tahu ketika keputusan yang mereka buat hanya akan disalahkan, mereka akan malas untuk self-managed ke depannya. KPI (Key Performance Indicator) juga sering membuat orang takut untuk self-managed. Saya pernah masuk ke dalam perusahaan di mana setiap pegawai KPI-nya hanya untuk memperbaiki masalah di departemen dia saja, ketika ada permasalahan di departemen lain yang ia bisa selesaikan ia cenderung acuh karena ia takut disalahkan oleh pimpinannya.
3. Kita ingin software berkualitas tanpa investasi terhadap kualitas
If you’re afraid to change something it is clearly poorly designed.
— Martin Fowler
Rekor mencatat bahwa harga tas termahal di dunia bernilai seharga USD 3.8 juta. Dengan uang sekian banyak bayangkan berapa banyak Ferari yang bisa anda beli, padahal ini cuma sebuah tas! Yang membuat tas ini mahal bukan saja bahannya yang terdiri dari emas dan berlian tetapi juga kualitas orang-orang di belakangnya dan waktu yang dihabiskan untuk membuatnya. Untuk satu tas ini waktu yang dihabiskan adalah 8800 jam atau 366 hari yang melibatkan 10 orang craftsman. Produk berkualitas membutuhkan waktu lama dan membutuhkan craftsmanship.
Sayangnya di Indonesia software development tidak dipandang sebagai craftmanship tetapi sebagai pekerjaan pabrikan. Hal ini bisa kita lihat bagaimana perilaku korporasi yang berlomba-lomba memotong budget IT, mencari software developer semurah mungkin bukan yang memiliki software craftmanship. Tidak jarang ada kita menemukan korporasi yang berusaha mengurangi software developer agar dapat menurunkan biaya operasional, padahal mereka lebih sering menambah manajer sampai tingkatan birokrasi di perusahaan menjadi berlapis-lapis. Kontradiksi terjadi karena perusahaan bukannya menurunkan biaya operasional dengan memecat manajer-manajer dengan gaji tertinggi tetapi justru memecat software developer dengan gaji yang relatif lebih rendah. Universitas di Indonesia pun akhir-akhir ini semakin banyak yang bodong yang tidak lebih dari pabrik software developer dan tidak peduli menanamkan mindset craftmanship ke mahasiswanya.
Software developer diharapkan untuk menghasilkan software berkualitas tetapi kontradiksinya mereka tidak boleh untuk memiliki atensi yang tinggi terhadap craftmanship. Kita tidak mengijinkan test engineer atau programmer menulis test automation karena hal tersebut dianggap mahal, lama untuk dibuat dan terlalu sulit untuk dilakukan oleh programmer pas-pasan. Oh bahkan kita lebih memilih merekrut seorang click tester, kalau bisa semurah mungkin, daripada seorang test engineer yang memiliki craftmanship dalam menuliskan test automation. Test engineer atau programmer yang memiliki craftmanship dalam menulis test automation dianggap terlalu mahal dan terlalu langka di pasar kerja. So we settle for less and at the same time still have a wishful thinking that we can still deliver high quality products fast. Kontradiktif bukan? Hehehe.
Kontradiksi berikutnya adalah kita lebih memilih memenuhi deadline walaupun dengan konsekuensi software tidak dikembangkan dengan benar. Kita terjebak dalam cara berpikir deadline driven development (DDD) daripada quality driven development. Dan kita masih sering sekali bingung kenapa software perusahaan kita sering bermasalah di lingkungan produksi dan butuh waktu lama untuk membenerkan bugs. Hehehe. Setiap kali saya menawarkan solusinya adalah test automation dan code refactoring, banyak pimpinan perusahaan yang berusaha menutup matanya karena mereka tahu hal tersebut mahal untuk dilakukan, mereka lebih memilih menerima kemahalan dari kode jorok dan tidak adanya test automation. Karena dengan demikian pimpinan perusahaan dan kostumer jadi bisa lebih sering menyalahkan software developer deh akibat kode jorok yang susah di-maintain. Pokoknya software developer harus selalu salah. Kalau meminta software developer lembur kan tidak perlu keluar biaya tambahan, kalau mengambil waktu untuk membersihkan kode jorok kan akan memakan biaya. Canggih kan cara berpikirnya? Hehehe. Itulah cognitive dissonance.
4. Kita ingin rockstar software developer tanpa investasi ke coaching
We have stars in every position. We have people who do great work and help everyone around them do great work too.
— Reed Hastings (CEO Netflix)
Setiap kali saya menjelaskan mekanisme Scrum, tidak sedikit yang langsung berkomentar: “Wah berarti Scrum perlu software developer dengan kualitas tinggi dong ya? Bisa tidak Scrum digunakan dengan kualitas software developer pas-pasan?”. Beginilah kalau Universitas sudah mengajarkan doktrin kalau software developer adalah pekerjaan rendahan, banyak pelaku bisnis software development di Indonesia yang terjebak dalam kubangan berpikir kalau software bagus bisa dihasilkan oleh software developer pas-pasan. Ada alasan kenapa banyak tas-tas mahal dibuat di daerah Italia bukan di daerah China, karena di daerah Italia banyak craftsman tas yang gajinya tidak murah. Tidak ada jalan keluar lain untuk harapan yang satu ini selain memberikan coaching kepada software developer.
Great software are made by great software developers. Seorang pelari cepat seperti Usain Bolt perlu latihan dan dilatih secara terus menerus agar dia dapat menjadi jawara dunia. Sama halnya dengan di dunia software development, untuk menghasilkan software developer canggih kita harus investasi untuk melatih mereka secara kontinu. Tetapi kita tidak mau investasi ke peran coach dan aktifitas coaching karena model kepemimpinan top-down lebih mudah dan lebih murah untuk dilakukan. Hehehe.
Masyarakat Indonesia lebih menghargai seseorang karena kepintarannya bukan karena kemampuannya dalam mengeluarkan potensi tersembunyi seseorang. Oleh karena itu peran coach dianggap lebih bernilai rendah dibandingkan seorang pimpinan bertangan-besi yang bisa memberikan perintah dan instruksi seenak udelnya kepada anak buah. Bahkan di banyak perusahaan Jakarta yang sudah memiliki Scrum Master pun, Scrum Master tersebut seringkali tidak didengarkan oleh senior management. Lebih baik perusahaan itu merekrut sekretaris saja daripada seorang Scrum Master kalau pada akhirnya Scrum Master tidak pernah didengar oleh senior management.
Di dalam budaya masyarakat Indonesia, memerintah dan menyalah-nyalahin seseorang itu lebih mudah dilakukan daripada memberikan coaching. Lihat saja mulai dari pemerintahan sampai ke jalan raya dan sampai ke ruang rapat, kita sebagai bangsa Indonesia lebih suka menyalahkan seseorang daripada mencoba mencari tahu apa permasalahan yang dihadapi oleh orang tersebut sehingga dia melakukan kesalahan. Hehehe. Entahlah, mungkin karena selama 3 abad kita dijajah VOC dan 3 dekade hidup dalam orde baru oleh karena itu mentalitas para pemimpin perusahaan banyak yang otoriter seperti itu.
5. Kita ingin ada perubahan tanpa melakukan perubahan
Humans are allergic to change. They love to say, “We’ve always done it this way.” I try to fight that. That’s why I have a clock on my wall that runs counter-clockwise.
— Grace Hopper
Kontradiksi terakhir berhubungan empat kontradiksi sebelumnya. Pimpinan perusahaan dan kostumer ingin adanya perubahan dalam software development di perusahaannya, software yang lebih berkualitas, software developer yang rockstar, dsb, tetapi kenyataannya berapa banyak pimpinan perusahaan yang benar-benar membuat perubahan terhadap empat kontradiksi di atas? Kebanyakan memelihara status quo untuk menjaga aman jabatannya. Atau mereka juga merasa gengsi apabila harus menjadi pemimpin yang melayani (servant leader). Pimpinan perusahaan dan manajer yang diharapkan bisa membuat perubahan karena political power yang mereka miliki justru lebih sering menghambat perubahan dengan menutup mata tidak melakukan apapun, seolah mereka tidak peduli dengan kesengsaraan software developer.
Sebuah perusahaan ternama di Jakarta yang sudah merekrut banyak Scrum Master dengan harapan mereka dapat membuat perubahan di perusahaan tersebut ternyata seringkali aksi Scrum Master dalam membuat perubahan di perusahaan dihalang-halangin oleh pimpinan perusahaan.
Masalah di ekosistem software development Indonesia cukup sistemik. Our will to leave the current beliefs needs to be stronger than our current beliefs if we really want change. Komunitas software development perlu lebih lagi melipat-gandakan gerakan dalam membuat perubahan. Manajer dan pimpinan perusahaan yang memiliki otoritas dan kekuatan politik lebih tinggi harus mulai peduli dan turut terlibat dengan kegiatan komunitas dengan tema membuat perubahan di ekosistem software development. Kalau tidak ya begini-begini aja deh nasib software developer.
Untuk software developer di Indonesia harus memiliki nyali untuk menyebarkan artikel ini bukan hanya ke komunitas software developer saja tetapi juga ke kostumernya dan pimpinan perusahaannya kalau ingin ada perubahan. Selain itu kita bisa membuat konferensi yang menekankan profesionalisme dalam software development di kota kita masing-masing seperti yang dimulai oleh teman-teman di Bandung dan mengundang manajernya dan kostumernya ke konferensi tersebut. Software developer juga bisa masuk ke kampus-kampus untuk mengedukasi mahasiswa dan dosen mengenai cara pandang software development yang semestinya agar doktrin yang salah tidak semakin menurun ke generasi berikutnya seperti yang dilakukan oleh teman-teman di Malang. Software developer juga bisa mengadakan acara Coding Dojo untuk belajar software craftmanship seperti yang dilakukan oleh teman-teman di Yogyakarta. Untuk yang mengerjakan proyek di pemerintah dapat mengedukasi para pejabat di pemerintahan mengenai software development atau mengundang mereka ke konferensi software development yang diadakan di kota masing-masing.
You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete.
― R. Buckminster Fuller
Kita seringkali meminta jalan keluar untuk menuju harapan kita. Meninggalkan kepercayaan lama kita anggap bukan merupakan sebuah jalan keluar. Kita terjebak dalam pola pikir bahwa untuk mencapai harapan baru kita masih bisa menggunakan model berpikir lama. Kita memegang erat kepercayaan lama kita seolah-olah yang kita percayai itu adalah sebuah kebenaran absolut. Namun itu juga yang seringkali menyebabkan bangsa Indonesia terjebak dalam status quo selama lebih dari 3 dekade terakhir. Perlu sebuah kerendahan-hati dan keberanian untuk meninggalkan apa yang selama ini kita percayai apabila kita menginginkan perubahan di ekosistem software development Indonesia. Terima kasih sudah mau membaca artikel ini sampai akhir.
Suka membaca artikel ini? Jangan lupa untuk menekan tombol 👏🏻 di bawah sebanyak mungkin dan sebarkan artikel ini ke banyak orang sebagai bentuk dukunganmu. Kita hanya perlu sedikit lebih kompak dan lebih berisik dalam menyuarakan isi hati dan pikiran kita untuk dapat melihat perubahan di ekosistem software development Indonesia.
