5 KESALAHAN MINDSET DI INDUSTRI SOFTWARE DEVELOPMENT INDONESIA

By on May 31, 2015
Sedih rasanya setelah membaca ulasan dari mas Joshua 스크람 Partogi yang dimuat di medium.com pasalnya berdasarkan pengalaman dan hasil pengamatannya, Beliau mendeskripsikan sejarah panjang Ilmu Komputer atau Teknik Informatika di Indonesia yang mana kurang lebih sudah 40 tahun cabang ilmu tersebut masuk di Indonesia, namun apa hasilnya? ternyata, tidak banyak kemajuan yang berarti, hal itu disebabkan karena tingkat turnover (pergantian) industri software development di Indonesia masih tergolong tinggi dibandingkan industri lainnya, salah satu contoh kasusnya adalah delivery date dan fitur-fitur yang tidak sesuai perencanaan/permintaan kostumer.
Sangat disayangkan, permasalahan tersebut yang sudah berlangsung selama 40 tahun belakangan, ternyata masih belum bisa merubah cara berpikir dan berperilaku yang pantas dalam software development. Bukankah seharusnya mereka belajar dari sebuah kegagalan?!! Namun seolah – olah hal tersebut tidak berlaku di Indonesia, Ibarat menggunakan kaca mata kuda sehingga, mereka tidak memperhatikan perkembangan dan perubahan di belahan dunia.

A problem can’t be solved from the same state of mind that created it. — Einstein

Pada hari ini, saat kalian sedang membaca artikel ini, di Indonesia ada proyek software development yang sebentar lagi mungkin akan gagal dan pada saat yang bersamaan ada beberapa software developer yang baru bekerja selama kurang dari satu bulan sudah berniat ingin mengundurkan diri, dikarenakan masih banyak manajer dan petinggi perusahaan yang memiliki pola pikir manajemen tahun 1900-an dalam mengelola proyek software development abad 21, karena belum bisa menyesuaikan diri, sehingga inilah alasan mereka perlu diganti. Perilaku tradisional mereka tidak jauh dari pengaruh atasan mereka yang juga berlagak tidak mau tahu. Human Resource Depaterment (HRD) juga termasuk di dalamnya, yang masih saja menggunakan teori kuno. Teori kuno mereka adalah mitos, mungin sebutan yang cocok untuk mereka adalah “partners in crime to demotivate people in the workplace. “
Yang dimaksud mitos dalam artikel ini adalah sebuah pemikiran mengenai pengelolaan software development berdasarkan teori dari jaman kuda yang tidak manusiawi dan sudah tidak relevan lagi di abad 21.
 
 
1. Software Developer = Resource
Di setiap training yang ia jalani, ada saja yang mengkorelasikan software developer sebagai resource.
 
“Pak, bagaimana jika resource kami terbatas? Apakah Scrum.. ?”
Pertanyaan semacam itu selalu langsung ia potong, karena sangat mengganggu kuping. Menurut Kamus Bahasa Inggris, arti dari kata resource adalah :
resource (n). a place or thing that provides something useful and can be used whenever it is needed.
Dan sayangnya manusia bukanlah a thing (benda) yang bisa diperlakukan seenaknya sendiri. Manusia punya pikiran dan perasaan.
People are NOT Resource
Lini software developmet bukanlah lini produksi sebagaimana yang ada pada pabrik-pabrik. Apa yang dikerjakan oleh programmer tidak sama dengan ada yang dikerjakan buruh pabrik, sebab yang dikerjakan oleh programmer bukanlah pekerjaan masal, code yang mereka ketik bukanlah karangan cerita atau berita, melainkan Algoritma yang memerlukan kecerdasan tingkat tinggi. Pola pikir yang tidak bisa membedakan antara peran buruh dengan paradigma dalam hal ini adalah software developer adalah KESALAHAN BESAR.
Software developer tidak akan mengalami penyusutan, namun sebaliknya seiring dengan waktu mereka akan menjadi semakin pintar karena mereka adalah mereka adalah knowledge worker yang menggunakan otaknya untuk bekerja bukan ototnya. Ilmu yang ada di dalam kepala software developer tidak akan usang, kecuali mereka tidak mau terus menerus belajar dan up-to-date dengan perkembangan jaman lagi. Dan bila mereka semakin pintar, maka software yang mereka kembangkan akan semakin berkualitas tinggi.
Software developer bukanlah resource yang perlu dimanage. When software developers are over-managed, they will under-manage themselves. Mereka adalah manusia. Mereka adalah knowledge worker. Mereka adalah capital investment dimana capital utama mereka adalah pengetahuan.
2. Software development = pekerjaan prediktif
Chaos theory adalah sebuah bidang ilmu yang mempelajari sebuah dinamika sistem yang sangat sensitif terhadap keadaan di awal yang menyebabkan keadaan di akhir tidak dapat diprediksi. Lorenz system adalah salah satu contoh dari chaotic system dan sebagai kontras gravitasi dapat dikatakan sebagai sebuah sistem yang memiliki tingkat kepastian yang tinggi.
Untuk memberikan gambaran sederhana yang bisa diterima masyarakat luas, maka narasumber menceritakan adiknya yang masih SMA dan bekerja paruh waktu di sebuah rumah makan cepat saji (burger). Salah satu kebiasaan rumah makan cepat saji tersebut adalah mencari tenaga kerja dengan latar belakang SMA, dikarenakan gaji harian anak SMA lebih murah dibandingkan seseorang yang sudah berkeluarga. Hal ini tidaklah aneh dan bisa diterima oleh akal sehat, karena proses membuat burger bersifat repetitif dan tidak rumit, bahkan seseorang yang masih duduk di bangku SMA pun dapat diberi pelatihan singkat mengenai pembuatan burger kurang dari sehari. Kalau proses mengembangkan software sama dengan proses membuat burger, mungkin cara berpikir bahwa pengembangan software adalah pekerjaan prediktif dapat diterima.
Sayangnya pekerjaan mengembangkan software bukanlah pekerjaan prediktif seperti membuat burger karena software developer tidak pernah membuat software yang sama lebih dari satu kali. Mengembangkan software bukanlah sebuah proses produksi. Bila kita ambil contoh industri otomotif, kita dapat melihat disana ada sebuah divisi R&D (Research & Development) dan ada bagian factory yang bertugas memproduksi mobil yang didisain oleh divisi R&D. Keahlian orang-orang yang berada di divisi R&D berbeda dengan orang-orang yang berada di factory. Orang-orang yang berada di divisi R&D berisi para inovator yang kreatif berbeda dengan orang-orang yang ada di factory yang cukup mengikuti prosedur standard. Para inovator di divisi R&D tidak pernah mendisain mobil yang sama lebih dari satu kali namun orang-orang yang bekerja di lini produksi dapat membuat tipe mobil yang sama berkali-kali dalam sehari. Bila kita ingin menghubungkan sifat pekerjaan software development, maka lebih cocok untuk dihubungkan dengan divisi R&D daripada dengan lini produksi di pabrik. Software developer adalah inovator, bukan buruh pabrik.
Namun sangat disayangkan sekali banyak manajer proyek yang masih menganggap kalau tipe pekerjaan di software development adalah pekerjaan yang dapat diprediksi dari awal seperti pekerjaan membuat burger. Manajer proyek akan berusaha semaksimal mungkin untuk membuat work breakdown structure (WBS) yang mendekati sempurna supaya proyeknya tidak gagal. Dan ketika proyeknya gagal, di proyek berikutnya mereka akan berusaha untuk menghabiskan lebih banyak waktu untuk membuat WBS-nya semakin mendekati sempurna lagi dan kalau perlu kali ini tambahkan buffer. Cara berpikir seperti ini sangat tidak relevan di software development karena kebanyakan teori manajemen proyek yang dianut manajer proyek banyak dilandaskan oleh teori manajemen proyek konstruksi yang sifatnya memang cenderung prediktif. Proses konstruksi bangunan yang banyak menggunakan teori teknik sipil dan teori fisika membuatnya cenderung prediktif. Kalau saja mengembangkan software didasari oleh rumus-rumus fisika, mungkin kita bisa menggunakan WBS dan kita tidak perlu memiliki software developer yang cerdas, cukup yang sekelas kuli bangunan saja. Andaikan saja manajer proyek ini memiliki kerendahan hati untuk mengakui kalau ilmu manajemen proyek mereka tidak relevan di software development, mungkin lebih banyak software developer saat ini yang bahagia dan tidak menyesali kenapa dirinya adalah seorang software developer.

Coercing people into commitments that didn’t come out of their mouth then blaming them for not meeting those commitments is an abuse.

Hal ini semakin diperparah lagi oleh salesman yang memberikan janji palsu kepada klien hanya agar dia mendapatkan proyek dari kostumernya. Si salesman akan mendapatkan bonus dari perusahaan karena sudah menggolkan proyek, sedangkan software developer harus menderita karena deadline yang dijanjikan oleh salesman kepada kostumer sering kali tidak masuk akal. Bukankah ini adalah proses pemanipulasian yang sangat kejam? Banyak salesman di perusahaan software yang berpikir kalau membuat software sama seperti membuat mi instan goreng telur. Dan jangan salahkan bila software yang dikembangkan oleh software developer menjadi berkualitas rendah.
Software developers don’t work effectively when they’re pushed into a no-win situation.
 
Untuk tipe pekerjaan yang memiliki banyak ketidakpastian seperti software development, metode empiris lebih tepat untuk digunakan. Manajer proyek yang mengira kalau tipe pekerjaan software development sifatnya prediktif kemungkinan tidak pernah terlibat atau sudah lama tidak terlibat dalam software development atau memang timnya mengembangkan software sederhana dengan teknologi sederhana yang jumlah penggunanya hanya satu orang.
3. Sukses = On-Time, On-Budget dan On-Scope
Di awal tahun ini, dalam sebuah perjalanan pulang dari outing kantor dimana saya pada waktu itu menjadi trainer untuk tim di perusahaan tersebut, menuju Jakarta salah seorang dari peserta outing mendapatkan sebuah pesan singkat dari atasannya yang isinya kira-kira adalah:
“Jangan lupa ya John, target kita tahun ini adalah Always On”.
 
Pemikiran yang menekankan kalau sukses adalah On-Time, On-Budget dan On-Scope berasal dari teori manajemen proyek tradisional. Tiga kriteria sukses ini seringkali disebut dengan Project Management Iron Triangle. Kalau tipe proyek atau tipe pekerjaan yang dilakukan adalah prediktif seperti membuat burger maka pemikiran ini dapat diterima oleh akal sehat. Namun mengembangkan software tidak sama dengan membangun sebuah mall.
Solusinya adalah lembur
Di banyak perusahaan di Indonesia, overtime sering kali dijadikan solusi agar software yang telah dijanjikan oleh pihak manajemen ke kostumer bisa selesai tepat waktu. Seolah-olah kalau software yang sedang dikembangkan tersebut tidak selesai tepat waktu maka dunia akan kiamat. Namun dilihat dari sisi manapun juga, lembur sangatlah tidak efektif.

 “Overtime” will always be followed by an equal period of “undertime” where people trying to catch up with their lives.

Setiap jam software developer lembur, setiap jam juga mereka akan kehilangan waktu dengan keluarga dan teman-temannya. Semakin banyak mereka lembur, semakin mereka tidak memiliki kehidupan. Lembur adalah sebuah solusi jangka pendek namun dampak jangka panjangnya lebih menyakitkan.
Kualitas tidak penting
Berdasarkan kamus perusahaan, definisi dari lembur adalah penambahan waktu untuk meningkatkan kuantitas pekerjaan bukan untuk meningkatkan kualitas software yang sedang dikembangkan. Bagi manajemen, men-deliver software lebih cepat walaupun dengan kualitas yang rendah itu lebih penting karena mereka beranggapan bahwa nantinya masih ada waktu di Post Implementation Review (PIR) atau User Acceptance Test (UAT) untuk memperbaiki software. Namun liciknya adalah manajemen akan tetap melaporkan kepada stakeholder dan kostumer kalau proyeknya sudah diselesaikan dengan sukses karena mereka sudah memenuhi kriteria on-time, on-scope dan on-budget, walaupun dengan kualitas rendah.
Menganggap bahwa software berkualitas rendah yang diselesaikan sesuai waktu, ruang lingkup pekerjaan dan dana yang ditetapkan sebagai sebuah kriteria kesuksesan bagaikan sebuah ilusi. Software development adalah sebuah seni, menulis kode yang bagus memerlukan kehati-hatian ekstra dan waktu yang relatif lebih lama dibandingkan menulis kode serabutan. Kode yang berkualitas rendah akan semakin memperlambat penambahan fitur baru dan semakin meningkatkan biaya untuk maintenance software di jangka panjang. Saya sudah sering melihat software developer yang mengundurkan diri dari sebuah perusahaan karena software yang ia kelola berkualitas rendah.
4. Produktifitas = kuantitas waktu bekerja
      Kualitas waktu tinggi = kualitas software tinggi
 
Dalam dunia software development, waktu untuk berpikir/melamun adalah sesuatu yang sangat penting karena software berkualitas dibuat oleh knowledge worker yang menggunakan otaknya bukan ototnya. Di mayoritas perusahaan di Indonesia, seorang software developer dikatakan produktif apabila ia duduk dan mengetik kode dalam jangka waktu yang lama. Bahkan ada perusahaan di Indonesia yang mengukur produktifitas programmer berdasarkan jumlah baris kode yang ditulis oleh programmer dalam sehari. Bila software developer sedang melamun atau sedang jalan-jalan di taman, maka mereka dianggap tidak bekerja dan merugikan perusahaan. Bagaimana apabila pada saat mereka melamun mereka sedang memikirkan sebuah algoritma yang dapat membuat kode menjadi lebih efisien dan bersih (clean code)? Bagaimana apabila lamunan tersebut menghasilkan pemikiran yang membuat user experience software menjadi semakin bagus? Software developer itu bagaikan seorang seniman lukis, ketika mereka sedang melamun mereka sebenarnya sedang produktif.
Interupsi tiada henti
Wired-in adalah sebuah keadaan dimana software developer terhubung ke kode yang sedang mereka tulis sama seperti saat seseorang melakukan meditasi tanpa menyadari apa yang telah terjadi di sekitarnya dan berapa banyak waktu yang terlalu ketika ia sedang menulis kode tersebut. Kalau anda adalah seorang software developer, tentunya anda tahu apa yang sedang saya maksud.
For knowledge workers like software developer, being in the flow is important because only when they are in the flow their work goes well.
Sayangnya berdasarkan pengamatan narasumber, software developer sering kali mendapat interupsi yang berlebih, sehingga kualitas waktu yang mereka miliki selama di kantor sangat rendah, karena sudah habis untuk meeting dan teleconference ditambah lagi interupsi tidak penting dari atasan dan kustomer belum lagi proyek yang dikerjakan secara paralel, sehingga waktu mereka untuk coding sangat minim.

The quality of software developer’s time is important, not just its quantity.

Interrupsi membuat kualitas waktu software developer menjadi rendah, dan dengan keadaan tersebut perusahaan masih mengharapkan pekerjaan untuk selesai tepat waktu? Sungguh tidak masuk akal bukan?
Manajemen gaya feodal
Sudut pandang ini berasal dari zaman penjajahan Spanyol abad 17-an, yang menganggap kekayaan bumi berjumlah tetap, sehingga cara mereka memperkaya diri adlah dengan mengambil sebanyak mungkin emas di negara jajahan mereka, hal yang serupa juga dilakukan oleh VOC, namun berbeda dengan Inggris yang berpikir dengan teknologi dan inovasi untuk memperkaya dirinya. Oleh sebab Inggris mengalami rovolusi industri, sedangkan Spanyol mengalami inflasi sebab tidak mampu menjual emasnya.
5. Coach — bukan peran yang dianggap penting

Often the answers to many questions are already within us. We just need the help from someone to bring them out. — Mae Jamison

Orang tidak menjadi lebih hebat karena di-manage, tetapi karena mereka di-coaching. Paradigma software developer harus di-manage berasal dari sudut pandang kalau software developer pada dasarnya tidak bisa diatur, tidak dewasa dan tidak cukup kompeten untuk mengatur diri mereka sendiri, oleh karena itu perlu ada seseorang untuk mengatur mereka. Paradigma software developer harus di-coaching berasal dari sudut pandang kalau software developer itu baik adanya yang memiliki potensi untuk dapat mengelola dirinya sendiri tanpa diperintah di kemudian hari.
Competent adults don’t need to be managed.
Karena software developer dianggap tidak kompeten maka mereka perlu dimanage bagaikan bidak catur oleh orang lain yang dianggap lebih pintar, dalam hal ini manajer proyek dan kadang ditambah beberapa lapisan lagi seperti Technical Leader, System Analyst, Solution Architect dan Business Analyst. Cara berpikir seperti ini secara tidak langsung membuat software developer berada pada hirarki paling bawah struktur organisasi sama seperti kuli bangunan yang berada di hirarki paling bawah.
Performance appraisal tahunan manipulatif

Rather than have a yearly performance evaluation, how about making course correcting info available all year long?

Ritual tahunan yang dilakukan oleh perusahaan yang bernama performance appraisal diharapkan dapat memotivasi software developer di tahun berikutnya. Namun ini sebenarnya adalah tipu muslihat yang sebenarnya bertujuan untuk memanipulasi motivasi software developer karena sifat performance appraisal yang men-judge kinerja software developer selama satu tahun ke belakang. Men-judge software developer dianggap lebih penting daripada memberikan coaching terus menerus yang dapat memperbesar kapasitas dan kapabilitas software developer. Yang lebih parah lagi kalau kriteria kinerja tinggi software developer yang digunakan pada saat performance appraisal adalah iron triangle — on-time, on-budget dan on-scope — yang tidak masuk akal itu. HRD adalah salah satu pihak yang diharapkan untuk dapat memberikan coaching kepada software developer mengingat banyak dari mereka yang memiliki latar belakang psikologi, namun berapa banyak dari HRD yang paham mengenai Agile Coaching dan memberikan coaching secara aktif kepada software developer di Indonesia? Hampir tidak ada.

“Leadership is the process of creating an environment in which people become empowered.”

Perusahaan sering kali bermimpi untuk mendapatkan software developer yang mature dan self-organising, namun pada saat yang bersamaan perusahaan tidak menempatkan investasi yang cukup untuk sebuah peran yang bertugas untuk mendewasakan software developer. Perusahaan berharap ada sebuah mukjizat dari surga yang dapat mendewasakan software developer dalam sekejap. Walaupun peran seperti Agile Coach dan Scrum Master sudah dirasakan manfaatnya dan dianggap penting di belahan dunia lain, tetapi peran ini belum dianggap penting sama sekali di Indonesia. Kenapa demikian? Karena seorang Agile Coach atau Scrum Master dilihat sebagai seseorang yang lemah dan tidak memiliki otoritas. Orang Indonesia ingin memerintah orang lain, karena hanya dengan demikian ia dipandang sebagai seseorang pemimpin yang hebat dan memiliki otoritas. Top-down approach gaya penjajah lebih digemari oleh perusahaan-perusahaan di Indonesia daripada bottom-up approach yang memaksimalkan collective intelligence.

Top down solutions ignore the knowledge & wisdom that exists throughout an organization.

Seseorang tidak secara otomatis menjadi dewasa, bahkan sampai saat ini pun saya masih memiliki mentor pribadi yang secara terus menurus membantu saya dalam karir saya. Kepemimpinan bukanlah mengenai mengambil semaksimal mungkin dari orang-orang di perusahaan kita namun justru mengenai pelayanan terhadap orang-orang kita. Software developer pada dasarnya adalah orang-orang yang cerdas. Orang cerdas perlu di-coaching agar potensi yang ada di dalam diri mereka dapat dikeluarkan. Bottom up approach dengan model Scrum lebih tepat untuk lingkungan software development yang berisi banyak knowledge worker.
Apabila anda adalah seorang software developer yang menginginkan agar HRD, atasan, manajer proyek, analis bisnis, user, kostumer, sales, marketing memahami bahwa apa yang anda kerjakan sebagai software developer itu kompleks silahkan sebarkan artikel ini. Kalau anda ingin memperbaiki ekosistem software development di Indonesia dan menyelamatkan lebih banyak lagi software developer yang saat ini sedang di-abuse dengan manajemen gaya feodal, silahkan sebarkan artikel ini. Silahkan retweet, share, like, reblog, recommend, repath, sebar ke milis kantor, sebar ke forum diskusi tanpa harus meminta ijin terlebih dahulu dari saya.
Ini adalah peperangan melawan cara berpikir feodal di dalam industri software development di Indonesia yang sudah mencapai tingkat akut. Mari kita bersama memanusiawikan software developer di Indonesia. Bila semakin banyak orang Indonesia yang teredukasi mengenai proses kerja software development yang seharusnya dan bisa keluar dari cara berpikir kuno yang tidak bisa dibuktikan secara ilmiah, maka ekosistem software development di Indonesia akan semakin sehat dan semakin banyak software developer yang menjadi lebih bahagia dan tidak perlu merenungi nasib kenapa dirinya adalah seorang software developer.

About Bingki Parmaza

Leave a Reply