Software Developer: bukan mesin yang bisa diukur
Managers who don’t know how to measure what they want, settle for wanting what they can measure.
— Russel Ackoff
Dalam Scrum, satuan ukuran apa yang diberlakukan kepada anggota development team untuk dapat mengetahui kinerja atau produktifitas mereka? Pertanyaan ini sering saya dapatkan dari para pembaca Buku Manajemen Modern dengan Scrum hingga hari ini. Saya sebenarnya bukan pendukung gerakan ukur-mengukur software developer, namun saya menuliskan blog ini hanya agar informasi di sini dapat menjadi titik awal perusahaan yang telah menggunakan Scrum agar bisa kreatif dalam mengeksploitasi semua rahasia di dalam Scrum dan bisa memikirkan kembali apakah gaya manajemen software development di perusahaan mereka selama ini sudah mengarahkan orang-orang ke perilaku yang profesional.
Paradigma kebanyakan manajer adalah kalau semua hal dalam dunia kerja harus bisa diukur namun ini adalah paradigma yang salah karena realitanya tidak semua hal di dalam alam semesta ini bisa diukur. Dan kita pun tidak perlu khawatir apabila tidak semua hal bisa diukur. Namun paradigma kebanyakan pimpinan perusahaan dan manajer adalah lebih baik mengukur walaupun yang diukur dan satuan ukuran yang digunakan tidak tepat.
Di dunia ini ada banyak profesi yang performanya tidak bisa diukur lewat satuan ukuran apapun. Profesi yang melibatkan kreatifitas seperti musisi ataupun yang melibatkan inovasi seperti ilmuwan yang bekerja di laboratorium produktifitasnya tidak bisa diukur. Profesi seperti ahli bedah juga produktifitasnya tidak bisa diukur. Yang lebih penting untuk diukur dari seorang ahli bedah adalah proses dan outcome dari pembedahan (tidak adanya malpraktik dan semua pasien yang dioperasi selamat) bukan produktifitas dan output (jumlah pasien yang dibedah dalam satu satuan waktu tertentu). Bila ahli bedah diukur berdasarkan output, hal tersebut akan mengarahkan mereka ke perilaku yang tidak etis.
Software development adalah pekerjaan yang kompleks, pekerjaan yang melibatkan kreatifitas dan inovasi. Namun masih banyak saja hingga hari ini yang beranggapan kalau software development hanyalah aktifitas menulis kode dan tidak jauh berbeda dengan pekerjaan di assembly-line pabrik. Atau masih banyak juga yang masih beranggapan kalau software development adalah clerical work — sama seperti pekerjaan yang dilakukan oleh akuntan atau human resource officer — yang repetitif dan dapat diprediksi. Kompleksitas dalam software development berada di penerjemahan keinginan kostumer yang ambigu ke dalam kode bersih yang hanya dimengerti oleh mesin dan terintegrasi dengan pekerjaan software developer lainnya — dibutuhkan imajinasi dan kolaborasi yang tinggi untuk dapat melakukan ini.
Satuan ukuran yang diberlakukan oleh kebanyakan perusahaan untuk mengukur produktifitas software developer hingga hari ini adalah:
- Jumlah baris kode yang ditulis dalam satu satuan waktu tertentu. Tidak terlalu banyak perusahaan yang menggunakan satuan ukuran ini, namun beberapa kali saya melihat di job advertising ada beberapa perusahaan yang masih menggunakannya.
- Jumlah defect atau bug dari fitur-fitur yang dikembangkan oleh software developer bersangkutan.
- Waktu yang dihabiskan software developer dalam mengerjakan satu pekerjaan.
- Selesai sesuai deadline yang telah ditentukan oleh manajemen.
- Akurasi dalam memberikan estimasi.
Permasalahan dalam mengukur software developer
Semua satuan ukuran di atas memiliki permasalahan. Secara umum permasalahan dalam mengukur software developer dengan satuan di atas adalah:
1. Mengarahkan software developer ke perilaku yang salah
Once an indicator or other surrogate measure of performance is made a target or incentive for the purpose of driving behavior, it loses the information content that qualifies it to play such a role. — Robert D. Austin
Satuan ukuran ini yang disebutkan di atas biasanya dikaitkan ke kenaikan gaji atau promosi jabatan. Karena dikaitkan dengan sesuatu yang bersifat finansial, tidak jarang satuan ukuran tersebut mengarahkan software developer ke perilaku yang salah. Misalnya:
- Menyebabkan silo antar peran, antar fungsi, antar departemen bahkan dengan kostumer. Satuan ukuran di atas dapat menyebabkan software developer memiliki mindset: “Us vs Them” atau ”It is not my job!”.
- Gaming the number, dimana software developer akan memanipulasi angka-angka dari satuan ukuran di atas hanya agar produktifitas dia bisa kelihatan tinggi di mata pimpinan perusahaan dan manajer. Ingat kita sedang berhadapan dengan software developer yang tidak bodoh.
- Mengambil jalan pintas dengan tidak menulis kode dengan bersih hanya untuk memenuhi deadline.
- Tidak ada sense of ownership (tidak jarang sampai level ignorant) terhadap produk yang dikembangkan karena deadline seringkali ditentukan secara sepihak oleh manajemen tanpa meminta pendapat software developer.
- Tidak proaktif, tidak melakukan apa yang tidak bisa diukur oleh manajemen. Lihat poin berikutnya.
2. Tidak semua hal penting dalam software development bisa diukur
Most of the things that really matter can not be measured so instead we allow the things that can be measured to become what matters to us.
Ada beberapa hal di dunia ini yang tidak bisa diukur. Kebanyakan hal di alam semesta ini yang tidak bisa diukur dan tidak bisa diprediksi berada dalam chaos system. Turbulensi dan terorisme termasuk dalam chaos system. Group dynamics juga merupakan chaos system yang tidak memiliki satuan ukuran yang pasti namun sangat penting dalam software development. Beberapa hal lagi yang sangat penting dalam software development namun tidak bisa diukur:
- Kolaborasi
- Kreatifitas
- Kemandirian / Self-organised / pro-activeness / inisiatif
- Courage
- Open-mindedness
- Developer’s happiness
- Engagement / sense of ownership terhadap produk yang dikembangkan
Karena hal-hal penting ini sulit untuk diukur, akhirnya manajer dan pimpinan perusahaan yang terobsesi dengan ukur-mengukur memilih untuk mengukur hal-hal yang tidak perlu diukur.
3. Tidak semua software developer sama
Variability is the law of life, and as no two faces are the same, so no two bodies are alike, and no two individuals react alike and behave alike under the abnormal conditions which we know as disease.
— William Osler
Tidak ada dua orang manusia yang sama. Tidak ada dua orang manusia yang dilahirkan dengan perilaku dan tingkat intelejensia yang persis sama. Satuan ukuran definitif untuk semua software developer menganggap kalau semua manusia sama dan bisa diukur dengan satuan ukuran dan tolak ukur yang sama. Manusia adalah mahluk Tuhan yang sangat kompleks. Setiap individu harus diperlakukan secara unik.
cult (n):
a situation in which people admire and care about something or someone very much or too much.
Bagi kebanyakan orang, semua masalah di muka bumi ini harus memiliki solusi. Kalau mengukur software developer dan tolak ukurnya memiliki masalah, maka tetap harus ada solusinya — dan seringkali aktifitas ukur-mengukur software developer sampai menjadi sebuah cult atau sesuatu yang disembah di kebanyakan perusahaan. Ini adalah sebuah dogma yang salah karena tidak semua masalah di bumi ini harus memiliki solusi. Contoh sederhana: hingga hari ini belum ada yang tahu solusi dari fenomena cegukan (hiccup) — yang ada hanyalah mitos-mitos untuk mengatasinya. Contoh lain adalah gempa bumi dan tsunami yang tidak memiliki solusi. Apakah kita bisa menghentikan gempa bumi dan tsunami? Terorisme, turbulensi, keserakahan manusia dan maut juga tidak memiliki solusi. Tapi apakah tidak adanya solusi untuk setiap masalah di muka bumi ini merupakan sebuah masalah? Hal ini bukan merupakan sebuah masalah, namun hal ini seharusnya mengajarkan kita untuk memahami cara kerja alam semesta ini. Sometimes you just have to dance with the problem instead of trying to solve the problem.
Terkadang dengan kita tidak melakukan apapun sudah merupakan sebuah solusi, misalnya tidak mengukur software developer adalah sebuah solusi. Namun tidak peduli seberapa kali saya selalu mengatakan: “don’t measure your developers, measure the outcome”, tidak ada manajer yang pernah puas mendengarkan jawaban ini. Mengukur software developer bagi kebanyakan manajer dan pimpinan perusahaan adalah seperti masturbasi, mereka tidak akan berhenti mengukur software developer sampai mereka merasa puas — apapun itu alasannya.
Yang lebih penting lagi dari ukuran dan harus dilakukan oleh manajer
1. Trust your software developers
If you don’t trust your people, then why did you hire them in the first place?
Satuan ukuran yang digunakan oleh kebanyakan perusahaan digunakan untuk mengetahui produktifitas software developer agar perusahaan yakin apakah software developer yang bersangkutan benar-benar bekerja atau tidak. Mindset mereka adalah kalau software developer tidak diukur maka mereka akan malas-malasan. Dalam kata lain, ukuran yang diberlakukan seringkali karena tidak adanya trust terhadap software developer.
Ketika anda menumpangi pesawat terbang komersial, apakah anda percaya 100% terhadap pilot dibalik cockpit yang anda tidak kenal sama sekali ? Lalu kenapa terhadap software developer kita sendiri kita tidak bisa memiliki trust setinggi itu? Bagaimana anda bisa yakin pilot tidak akan menabrakkan pesawat yang anda tumpangi ke sebuah gunung yang dapat menewaskan anda? Apakah anda memiliki rasa percaya yang tinggi terhadap pilot karena anda tahu mereka akan bertindak profesional, tidak mengambil jalan pintas? Lalu apa yang telah kita lakukan agar software developer kita dapat bertindak profesional dalam mengembangkan software? Apakah satuan ukuran yang kita gunakan selama ini telah mendorong software developer ke perilaku yang tidak professional? Kenapa sebagai pimpinan perusahaan kita justru mendorong mereka untuk berperilaku tidak professional? Seperti mengijinkan mereka menulis kode jorok hanya untuk memenuhi deadline?
2. Coach your software developers
If you don’t trust your software developers, then you need to coach them so that you can trust them.
If you genuinely want your software developers to be better then you have to coach them proactively. Untuk kerangka kerja Scrum, ada peran bernama Scrum Master yang bertanggung-jawab untuk memberikan coaching kepada setiap anggota tim. Perlakukan setiap individu unik sebagaimana mestinya daripada menuntut mereka untuk compliant dengan ukuran yang diberlakukan kepada mereka.
Saya pribadi tidak setuju dengan pola pikir bahwa software developer harus diukur karena ini adalah paradigma dari era industrialisasi dimana manusia dipandang seperti mesin (resource) yang produktifitas dan efisiensinya harus diukur dan dioptimalkan. Bagi saya pribadi, pendekatan pribadi atau one-on-one coaching yang dilakukan manajer atau Scrum Master setiap bulannya tetap cara yang paling manusiawi untuk meningkatkan kapabilitas software developer dan mengidentifikasi kenaikan jabatan dan kenaikan gaji. Yak menjadi manajer software development dan Scrum Master memang tidak mudah.
Dengan saya menuliskan beberapa ukuran untuk software developer bukan berarti saya mendukung aktifitas ukur-mengukur software developer. Namun bila sebagai manajer anda tetap ingin mengukur software developer, gunakanlah satuan ukuran yang mendorong software developer ke perilaku yang profesional.
1. Quality over deadline
If you must choose between either writing quality code or meeting a deadline then there’s something wrong with the way you manage software development.
Ukuran yang mengutamakan kualitas di atas deadline (atau penyelesaian jumlah fitur) akan mengarahkan software developer untuk menjadi orang-orang yang professional yang selalu mengutamakan kualitas apapun situasi dan kondisinya. Sama seperti ahli bedah dan pilot yang selalu mengutamakan kualitas — bukan sekedar menyelesaikan pekerjaannya.
Kualitas software harus dilihat secara holistik bukan hanya dinilai dari luar saja dengan mengukur jumlah defects dalam software. Bisa saja kemasannya bagus tetapi dalamnya bosok, bisa saja defects rate-nya rendah tetapi kodenya bau. Kode yang bau akan menghasilkan technical debt yang dapat memperlambat laju pengembangan software dalam jangka panjang — dan bukan tidak mungkin dapat membuat perusahaan bangkrut.
Dalam dunia medis, proses pembedahan yang dilakukan dengan benar juga penting selain keselamatan keselamatan pasien itu sendiri. Dalam industri software development, mindset sebagian pimpinan perusahaan masih pada level “tidak apa-apa kode jorok asalkan pekerjaan selesai on-time”.
Kuantitatif
Secara kuantitatif metrik berikut dapat digunakan untuk mengukur tingkat kebersihan kode: Cyclomatic complexity, Maintainability index dan Test coverage. Tools berikut dapat digunakan untuk mengukur kebersihan kode yang dituliskan oleh software developer: Code Climate, Sonar.
Kualitatif
Tools tetap memiliki keterbatasan dalam mengukur tingkat maintainability dan kebersihan kode yang dituliskan oleh software developer. Cara yang terbaik untuk mendapatkan informasi kualitas kode adalah lewat pair programming atau mob programming. Satuan ukuran yang digunakan lewat aktifitas ini adalah:
- How does other feels about the code?
- Is it readable?
- Does it have too many comments (code with too many comments is a sign of a dirty code)?
- Is it Object-oriented?
- Does it follow design patterns and SOLID principles or other clean-code practices?
- Is the code testable?
Dalam aktifitas ini ukur seberapa sering software developer bersumpah-serapah membaca kode yang ditulis oleh software developer lain.
2. Learning rate over success rate
In a blameless culture, everybody know that the root cause of the problem is not a person.
Untuk tipe pekerjaan inovatif seperti software development, learning rate jauh lebih penting dibandingkan success rate. Selain karena inovasi berasal dari pembelajaran, dalam software development apa yang membuat perusahaan sukses hari ini tidak menjamin perusahaan tetap sustainable di pasar — contoh: Yahoo, Nokia dan Research in Motion (RIM). Dalam industri software development, yesterday’s solution becomes today’s problem.
Lingkungan kerja yang tidak mengijinkan orang-orang untuk membuat kesalahan hanya akan membuat orang-orang menjadi defensif atau saling menyalahkan satu sama lain. Ukuran yang mengutamakan learning rate di atas success rate akan mengarahkan software developer ke continuous improvement (kaizen), software craftmanship dan innovation. Ukur failure rate bukan hanya success rate dalam tim di setiap Sprint pada saat retrospective karena dalam software development: 0% failure = 0% learning = 0% innovation.
3. Collective effort over individual effort
[In software development] communication usually fails, except by accident.
— Osmo A. Wiio
Software development mirip seperti bermain sepakbola atau bermain musik dalam band musik. Sama seperti tim olahraga dan band musik, ukur secara tim daripada secara individu karena kesuksesan dalam software development adalah milik tim secara keseluruhan. Software developer yang tidak mau bekerja sama dalam tim lebih baik tidak usah bekerja dalam tim. Tidak ada alasan untuk yang satu ini.
In software development, interaction between team members matters. Dalam sepakbola bila kesuksesan tim sepakbola dilihat secara kolektif, demikian juga seharusnya dalam software development. Ukur secara tim bukan secara individu karena hal ini akan mengarahkan software developer kepada collaboration bukan saling lempar-lemparan pekerjaan seperti yang banyak terjadi di banyak perusahaan saat ini. Development team should get better and better each Sprint, they should become a rockstar development team.
Lalu bagaimana kalau ada satu individu yang slacking dan bersembunyi di antara kerja keras rekan kerja lainnya. Kalau demikian maka sebagai manajer andalah yang belum berhasil dalam melakukan coaching terhadap software developer yang bersangkutan. Keep on coaching each software developer until you can trust them.
Beberapa satuan ukuran yang dapat digunakan:
- Is the individual coachable?
- Bagaimana kemandirian software developer yang bersangkutan? Apakah dia self-organised, trustworthy, proaktif dan courageous dalam event-event Scrum?
- Apakah software developer yang bersangkutan kolaboratif? Apakah dia membantu anggota tim lain? Apakah dia memikirkan kemenangan secara kolektif atau kemenangan pribadinya saja?
- Flow efficiency, seberapa efisien pekerjaan yang melibatkan multi-departemen atau multi-fungsi dikerjakan? Apakah ada banyak hand-over atau bahkan loopback?
Data ini bisa didapatkan pada saat Sprint retrospective bisa melalui survey ataupun secara verbal.
4. Outcome over output
If you would like your software developers to go faster then you need to ask them to do less. Minimize output, maximize outcome.
Output adalah berapa banyak fitur yang dihasilkan oleh software developer dalam satuan waktu tertentu sedangkan outcome adalah bagaimana reaksi pengguna terhadap output setiap satuan waktu. Tidak ada gunanya mengembangkan banyak fitur tepat waktu kalau tidak ada pengguna yang merasakan dampak atau engagement dari fitur-fitur tersebut. Measure outcome not output — or feature completion.
Ukuran yang mengutamakan outcome di atas output akan mendorong software developer untuk berkolaborasi dengan kostumer untuk menghasilkan software yang bernilai bagi kostumer — bukan sekedar selesai saja. Beberapa ukuran yang dapat digunakan untuk mengukur outcome adalah:
- Usability / user experience — bagaimana perasaan pengguna ketika menggunakan fitur-fitur yang ada dalam software? Apakah mereka merasa fitur-fitur dalam software hanya semakin menyusahkan hidup mereka saja?
- Usage index — seberapa sering pengguna ingin menggunakan fitur-fitur dalam software?
- Strategic alignment index — apakah software yang dikembangkan oleh departemen teknologi informasi selaras dengan strategi perusahaan dalam jangka waktu 5 tahun ke depan?
- Innovation rate — berapa banyak prosentase waktu yang dihabiskan oleh software developer untuk maintenance vs defect fixing vs inovasi fitur baru?
- Bagaimana nilai dari software? Apakah software turut meningkatkan produktifitas perusahaan? Apakah software bisa menurunkan biaya operasional perusahaan? Atau pengelolaan software justru hanya menambah biaya operasional perusahaan karena softwarenya tidak user friendly, memiliki banyak defect dan membutuhkan banyak customer support personnel?
Jadi untuk menjawab pertanyaan para pembaca mengenai satuan ukuran terhadap Scrum development team, Scrum sendiri tidak menjabarkan satuan ukuran apa yang harus digunakan untuk mengukur development team karena Scrum cuma sebuah kerangka berpikir. Paradigma dalam Scrum adalah: semua pendekatan yang dilakukan oleh perusahaan dalam mengimplementasikan Scrum harus mengarahkan software developer ke perilaku yang profesional. Beberapa poin di atas hanyalah beberapa contoh satuan ukuran yang digunakan perusahaan yang menggunaan Scrum yang mengutamakan profesionalisme.
Satu hal yang saya selalu ingat dari mentor saya, the work relationship has to be based on mutual respect. Karena software developer bukan budak, lebih bagus lagi kalau anda sebagai manajer atau pimpinan perusahaan menanyakan kepada software developer bagaimana mereka mau diukur — memberlakukan satuan ukuran yang unik ke setiap individu itu lebih manusiawi karena anda melihat setiap individu sebagai human being bukan sekedar sebagai human resource.
Setelah membaca tulisan ini, apakah sebagai pimpinan perusahaan atau sebagai manajer anda benar-benar mau secara tulus menggunakan satuan ukuran yang mengarahkan software developer ke profesionalisme? Apakah anda memandang software developer sebagai human being atau anda cuma memandang mereka sebagai human resource? Sebagai manajer maukah anda secara genuine memberikan coaching ke masing-masing software developer agar mereka menjadi ninja software developer atau anda lebih memilih secara pasif mengukur mereka? Kalau anda sebagai manajer tidak mau melakukan coaching, apakah anda memiliki coach di perusahaan anda yang dapat mengekspansi kapabilitas software developer menjadi ninja developer?
Bila anda menemukan manfaat dari artikel ini jangan lupa untuk menekan tombol 👏🏻 di bawah sebanyak mungkin agar lebih banyak lagi orang yang dapat melihat artikel ini. Terima kasih atas dukungannya untuk memodernisasikan cara berpikir orang-orang dalam industri software development di Indonesia. Semoga industri software development di Indonesia bisa menjadi lebih baik ke depannya.
