Kepemimpinan Perekayasa Perangkat Lunak
(... atau Software Engineering Leadership)
Banyak literatur yang tersedia ketika membahas terkait kepemimpinan. Bahkan terlalu banyak literatur dan referensi yang tersedia membuat kita tidak tahu harus memulai dari mana ketika ingin mendalami mengenai ilmu kepemimpinan.
Hal ini juga berlaku apabila kita membahas kepemimpinan pada ruang lingkup yang lebih spesifik, yaitu kepemimpinan pada kegiatan rekayasa perangkat lunak. Kegiatan perekayasaan, terutama rekayasa perangkat lunak memiliki konteks dan tantangan yang cukup berbeda dan spesifik sehingga memerlukan pembahasan khusus ketika berbicara mengenai kepemimpinan pada kegiatan tersebut.
Namun di Indonesia, literatur dan referensi yang mendalam mengenai kepemimpinan pada kegiatan rekayasa perangkat lunak masih jarang ditemui. Hal ini dikarenakan industri rekayasa perangkat lunak di Indonesia belum tumbuh dan berkembang sebagaimana halnya industri lainnya. Sebagai anekdot, saya cukup kesulitan menemukan padanan kata untuk software engineering leadership.
Karena kondisi di atas, maka untuk sementara kita akan memulai dengan membahas literatur dan referensi tokoh dari luar negeri dengan industri rekayasa perangkat lunak yang lebih matang agar hal-hal yang sudah terbukti baik dapat dipraktekkan juga di Indonesia.
Tulisan ini saya buat tidak bertujuan untuk membahas kepemimpinan secara komprehensif. Tetapi saya akan mengambil topik-topik spesifik yang menarik untuk dibahas. Topik-topik lain yang belum dibahas pada tulisan ini mungkin dapat kita bahas pada tulisan berikutnya.
Topik yang akan saya bahas kali ini adalah mengenai satuan terkecil dari suatu organisasi teknis, yaitu tim dan peran seorang pemimpin teknis atau manajer pada tim. Alasan saya memilih kedua topik ini adalah karena dalam pembahasan tentang kepemimpinan, bentuk organisasi merupakan salah satu keputusan pertama yang harus diambil dan keputusan tersebut akan sangat mempengaruhi banyak hal pada organisasi.
Apa Itu Tim?
Sebagai seorang introvert, posisi alami saya ketika melakukan kegiatan adalah dengan melakukan sesuatu seorang diri. Namun saya menyadari benar bahwa untuk memberikan dampak yang besar maka saya memerlukan kolaborasi dengan banyak pihak. Apalagi kalau berbicara mengenai pembangunan perangkat lunak yang semakin kompleks disebabkan oleh ekspektasi pengguna yang semakin tinggi. Kecuali tentunya jika kita adalah perekayasa 10x atau perekayasa berkemampuan penuh (full-stack engineer) yang menguasai seluruh perkakas mulai dari desain hingga deployment. Atau jika kita menggunakan layanan perangkat lunak yang dapat membantu kita untuk mengisi kekosongan pada kemampuan kita.
Oleh karena itu menurut saya definisi paling tepat dari sebuah tim adalah kumpulan individu yang dapat menyampaikan nilai kepada para pengguna. Kuncinya disini adalah sebuah tim harus memiliki individu dengan kemampuan yang beragam dan saling melengkapi, sehingga tim tersebut dapat menyampaikan nilai kepada pengguna tanpa memiliki ketergantungan berlebihan kepada pihak lain.
Berkaitan dengan hal tersebut di atas, mari kita bahas sedikit mengenai tanggung jawab tim dalam menyampaikan nilai kepada para pengguna supaya kita memiliki pemahaman yang sama mengenai ruang lingkup kerja suatu tim.
Apa saja sebenarnya tanggung jawab tim?
Menganalisa dan merencanakan kegiatan pengembangan
Membuat fitur yang bermanfaat untuk pengguna berdasarkan rencana yang telah dibuat
Mendokumentasikan kegiatan yang dilakukan agar pengembangan dapat dilakukan secara berkesinambungan
Memperbaiki kesalahan yang ditemui pada perangkat lunak
Berpartisipasi dalam panggilan dukungan (on-call support)
Hal di atas belum termasuk kegiatan lainnya yang penting untuk kesinambungan organisasi seperti peran tim dalam kegiatan orientasi maupun sesi berbagi.
Setelah mendapat gambaran mengenai tim dan ruang lingkup kerja tim, sekarang kita bisa membahas topik berikutnya yang masih terkait dan tidak kalah penting yaitu ukuran tim.
Ukuran Tim
Ukuran tim merupakan hal yang paradoks. Kenapa? Karena untuk memberikan dampak yang besar umumnya kita membutuhkan jumlah orang yang banyak pula. Namun jumlah orang yang banyak dalam suatu tim akan menimbulkan masalah, salah satunya yaitu masalah komunikasi. Masalah komunikasi akan meningkat secara eksponensial seiring dengan jumlah orang yang bertambah pada suatu tim.
Meskipun demikian, seiring dengan berkembangnya teknologi, keuntungan dari memiliki jumlah orang yang banyak dalam sebuah organisasi untuk menghasilkan dampak semakin berkurang, sebagaimana dibahas oleh Deloitte. Kita tidak akan bahas lebih lanjut mengenai fenomena tersebut pada tulisan ini, tapi hal ini cukup menarik untuk diketahui.
Dengan mempertimbangkan hal-hal di atas, sekarang saatnya kita menentukan jumlah optimal anggota dari sebuah tim. Salah satu buku terakhir yang saya baca mengenai kepemimpinan perekayasa perangkat lunak adalah An Elegant Puzzle yang ditulis oleh William Larson. Pada buku tersebut, William berpendapat bahwa jumlah perekayasa yang ideal pada suatu tim berada diantara 6 hingga 8 perekayasa. Jumlah itu ideal karena dinamika tim berubah secara signifikan ketika jumlah orangnya terlalu banyak atau terlalu sedikit. Sebagai contoh:
- Tim yang jumlah orangnya terlalu sedikit (≤4 orang) akan mengalami kesulitan beroperasi apabila salah satu anggota tim sedang sakit atau izin.
- Tim yang jumlah orangnya terlalu sedikit akan mengalami kesulitan mengatur rotasi jadwal panggilan dukungan (on-call support).
- Tim yang jumlah orangnya terlalu sedikit juga akan mengalami kesulitan membagi waktu antara kegiatan pemeliharaan dengan inovasi. Seringkali mereka hanya akan fokus pada kegiatan pemeliharaan saja.
- Tim yang jumlah orangnya terlalu banyak akan mengalami kesulitan berkomunikasi dan pimpinannya akan mengalami kesulitan dalam mengelola tim tersebut.
Kemudian apabila kita berbicara mengenai komposisi dari tim, tentunya hal tersebut sangat dipengaruhi oleh jenis pekerjaan dan tingkat kesulitan yang dihadapi oleh tim. Terkadang perlu dilakukan beberapa iterasi hingga kita menemukan rumusan dan komposisi yang tepat untuk tiap tim. Sebenarnya sah saja apabila kita ingin melakukan beberapa kali perubahan pada tim, selama kita menetapkan ekspektasi yang tepat di depan dan membangun budaya umpan balik yang baik.
Selanjutnya mari kita membahas topik yang tidak kalah penting, yaitu mengenai pemimpin tim.
Pemimpin Teknis / Manajer Perekayasa
Kegiatan rekayasa memiliki kekhasan karena dikerjakan oleh para pakar dan membutuhkan keahlian spesifik dari tiap anggota tim. Pada organisasi yang menganut prinsip meritokrasi, seringkali orang yang paling “pandai” atau “jago” dalam kepakarannya di dalam tim juga diasosiasikan atau bahkan dituntut menjadi pemimpin untuk tim tersebut. Padahal keahlian yang diperlukan cukup berbeda.
Ada sebuah pemikiran yang menarik tentang hal ini, yaitu Peter principle.
People in a hierarchy tend to rise to their “level of incompetence”
Kutipan di atas dapat diartikan: ada tendensi seorang pegawai dipromosikan menjadi pemimpin atau manajer karena sukses mereka di masa lampau. Proses ini terjadi berulang kali hingga mencapai titik di mana mereka tidak kompeten lagi. Hal ini disebabkan karena kemampuan seseorang di suatu bidang belum tentu dapat ditranslasikan ke bidang lainnya (dalam konteks pembahasan kita berarti dari kemampuan teknis ke kemampuan manajemen).
Untuk menjawab paradoks di atas, salah satu tulisan yang menurut saya cukup ringkas namun tepat dalam membahas peran seorang pemimpin teknis adalah Tech Lead Manifesto yang ditulis oleh Sam Newman.
A Tech Lead Should
Ensure the creation of a clear and consistent technical vision for the project which can best result in a successful project
Ensure all members of the team have a proper understanding of the technical vision
Ensure that the technical vision updates to reflect new requirements
Track and resolve issues where the code deviates from the technical vision
Create an environment in which all members of the team can contribute towards the technical vision
Understand and address skills gaps in the team which would result in difficulties implementing the technical vision
A Tech Lead Should Not
Tell everyone what to do
Necessarily be the best at everything
Write no code
Write all the hard code
Ada hal yang dapat kita garis bawahi dari manifesto di atas. Salah satunya pada bagian “A Tech Lead Should not” tercantum “Necessarily be the best at everything” dan “Write all the hard code”. Kita telah bahas pada bagian sebelumnya bahwa bidang keilmuan yang diperlukan untuk menyampaikan nilai kepada pengguna di bidang perekayasaan perangkat lunak sangatlah luas. Hampir mustahil satu orang dapat menguasai sekaligus menjadi yang terbaik dari setiap bidang pada suatu tim. Selain itu hal ini juga berisiko menimbulkan satu titik kegagalan (single point of failure), dimana ketidaktersediaan pemimpin teknis pada tim dapat menimbulkan tim tersebut tidak dapat beroperasi. Tentunya kita ingin terhindar dari kejadian ini.
Hal lain yang dapat digaris bawahi adalah pada bagian “A Tech Lead Should” mayoritas prinsip yang tercantum adalah terkait dengan penyelarasan. Seperti misalnya penyelarasan antara visi teknis dengan kebutuhan, penyelarasan antara tim dengan visi teknis dan penyelarasan di dalam tubuh tim itu sendiri. Penyelarasan merupakan tanggung jawab utama yang pemimpin teknis harus lakukan dalam mengelola tim.
Sekarang kalau kita coba simpulkan, pesan utama yang terkandung pada manifesto ini adalah mengenai apa saja sebenarnya ekspektasi yang sesuai untuk disematkan kepada seorang pemimpin teknis. Dengan menyesuaikan ekspektasi kita, harapannya kita dapat mengurangi efek negatif dari Peter Principle dan meningkatkan kejelasan dari peran seorang pemimpin teknis.
Demikian tulisan mengenai “Kepemimpinan Perekayasa Perangkat Lunak” yang pertama. Mudah-mudahan saya dapat menuangkan subtopik lain mengenai kepemimpinan pada kegiatan rekayasa perangkat lunak di tulisan berikutnya. Apabila ada pertanyaan atau saran dapat langsung disampaikan melalui widget komentar medium.
