Delapan Aturan untuk Produksi Perangkat Lunak yang Efektif

Selama karir saya, saya telah berpartisipasi dalam beberapa proyek perangkat lunak kehidupan nyata dan mengamati bagaimana hal-hal dilakukan di semua tingkatan: pengambilan keputusan, penerapan praktik, pembangunan tim, perekrutan, distribusi keterampilan, dll. Jelas, pendekatan yang berbeda menghasilkan hasil yang berbeda . Menjadi tipe orang yang berorientasi pada peningkatan, saya memperhatikan dan mengumpulkan praktik paling efektif dan trik praktis terbaik untuk membantu saya dalam pekerjaan saya.

Belajar dari observasi adalah cara yang sulit dan panjang untuk dilakukan. Saya akan sangat senang untuk mengambil pengetahuan ini lebih awal dari buku sebagai gantinya. Sayangnya, saya tidak menemukan topik tersebut. Jadi saya memutuskan untuk berbagi pengalaman saya dengan pencari lain dari jenis pengetahuan ini. Mudah-mudahan, itu akan menyelamatkan mereka beberapa tahun penelitian pribadi.

Dalam artikel ini, Anda akan mempelajari bagaimana Anda dapat mengalahkan rata-rata kinerja industri dengan memproduksi produk perangkat lunak yang kokoh dan andal yang memerlukan perawatan 5-10 kali lebih sedikit. Saya dapat mengatakan tanpa kerendahan hati yang salah bahwa dalam 10-15 tahun terakhir, saya (secara pribadi dan juga tim saya) telah melampaui semua harapan, meninggalkan jejak kesuksesan di belakang. Manajer tidak bisa lebih bahagia.

Suatu kali tim saya menyelesaikan proyek penting dalam kerangka waktu yang sangat singkat, di mana kami diberi penghargaan "Tim Kinerja Tinggi" oleh manajemen yang lebih tinggi. Semua ini tanpa menginap malam dan akhir pekan melelahkan diri kita sendiri. Kerja biasa saja.

Anda lihat, pengetahuan produksi perangkat lunak yang efektif itu sendiri adalah sebuah kekuatan. Faktanya, itu adalah semacam ilmu hitam yang tidak banyak orang dapat pahami bahkan ketika dijelaskan dengan kata-kata biasa. Anda akan mendapatkannya secara gratis. Baca terus jika Anda ingin dianggap sebagai ahli produksi perangkat lunak.

Untuk Siapa Ini?

Biarkan saya membuat penafian penting, penting, penting di sini.

Saya menyampaikan hal ini kepada mereka yang membutuhkan peningkatan produktivitas. Tidak semua hal dalam hidup ini tentang produktivitas. Tidak semua proyek perangkat lunak juga. Ada kasus ketika Anda tidak dinilai berdasarkan kinerja Anda. Jelas, praktik ini tidak akan membantu.

Teknik-teknik ini akan sangat berguna bagi pemimpin tim, arsitek, dan manajer proyek, meskipun pengembang perangkat lunak senior juga dapat memperoleh manfaat darinya.

Aturan No. 1: Pahami Mentalitas TI

Industri TI adalah perpaduan antara sains, teknologi, seni, dan bisnis. Cukup sulit untuk menavigasi ke sana tanpa memahami aspek-aspek ini pada tingkat yang cukup baik. Masalah terbesar adalah bahwa industri itu sendiri cukup kompleks; oleh karena itu, praktik terbaik juga kompleks. Anda perlu belajar banyak dan memverifikasi pengetahuan Anda dengan berlatih banyak untuk berhasil.

Tingkat pembaruan teknologi yang luar biasa membuatnya sangat sulit. Tidak ada yang Anda pelajari sepuluh tahun yang lalu diperlukan lagi. Jadi, Anda perlu belajar dengan kecepatan yang dipercepat.

Meringkas semua hal di atas, kita dapat mengatakan bahwa sukses di bidang TI tidak didasarkan pada keterampilan atau perasaan bawaan tetapi pada contoh-contoh praktis yang sulit. Jangan pernah "mengikuti naluri" atau percaya hanya berdasarkan perasaan, termasuk perasaan Anda.

Jika ya, ide tersebut layak dipertimbangkan. Jika tidak, mintalah penjelasan yang sangat baik dan sangat rinci tentang bagaimana memilih jalan ini membuat hidup tim Anda lebih baik. Jika lulus tes ini, jadwalkan proyek pembuktian konsep ringan yang secara eksperimental membuktikannya cocok dengan lingkungan Anda.

Hal yang penting untuk dipahami disini adalah tidak ada solusi yang benar dan salah karena ada banyak cara untuk menyelesaikan masalah software. Namun, ada pemahaman yang baik dan buruk dari solusi.

Jika seseorang dapat dengan jelas mengartikulasikan ide secara rinci atau menarik tautan dari mengadopsi solusi ini ke kesuksesan tim untuk membujuk anggota tim lainnya, maka kita dapat mengandalkan visi dan harapan orang ini untuk peluang sukses yang tinggi.

Aturan No. 2: Jangan Campurkan Metodologi Produksi Perangkat Lunak dan Pengembangan Perangkat Lunak

Produksi perangkat lunak didasarkan pada pengembangan perangkat lunak. Namun, keduanya memiliki tujuan, pola pikir, dan praktik yang sangat berbeda. Mencoba memecahkan masalah dari salah satu alam ini dengan metode dari yang lain menghasilkan hasil yang konyol. Penting untuk memahami perbedaan dan menggunakan metode yang tepat untuk masing-masing dunia ini.

Pengembangan perangkat lunak adalah kombinasi dari seni dan kerajinan. Komponen seni akan selalu ada terlepas dari alat otomatisasi dan metodologi pengembangan perangkat lunak di luar sana. Oleh karena itu, menyelesaikan tugas pengembangan membutuhkan konsentrasi dan perlindungan maksimum dari semua sinyal pengganggu lainnya.

Cara terbaik untuk memotivasi pengembang berpengalaman adalah dengan memberi mereka tugas dalam bentuk teknis murni dengan semua faktor manusia dikecualikan. Semua persyaratan juga harus dinyatakan dalam bahasa teknis. Mereka harus mudah diverifikasi untuk memungkinkan mereka menavigasi ke arah tujuan selama fase penelitian solo mereka.

Produksi perangkat lunak, sebaliknya, lebih dalam domain administrasi bisnis. Anda tahu apa yang dibutuhkan pelanggan Anda dari satu sisi dan Anda tahu sumber daya tim apa yang Anda miliki dari sisi lain. Jadi sekarang Anda mencoba mengarahkan upaya tim Anda untuk mencapai tujuan. Sementara itu, Anda juga dapat memperkirakan kecepatan kemajuan Anda dan menyajikan rencana yang matang kepada bos. Keterampilan penting di sana adalah memahami keinginan pelanggan Anda, memahami kekuatan tim Anda, dan mengomunikasikan rencana dan jadwal formal.

Karena itu, saya ingin menyoroti bahwa banyak peran dalam pengembangan perangkat lunak bekerja di kedua dunia ini—dalam membangun jembatan antara bisnis dan teknologi—seperti pemimpin tim, arsitek, analis, dan manajer proyek. Orang-orang dalam peran ini harus dapat berjalan dengan mudah di antara dua bidang realitas dan memahami kapan waktunya untuk membicarakan bisnis dan kapan waktunya untuk seni.

Aturan No. 3: Gunakan Penyimpanan Persisten sebagai Ekstensi ke Memori Manusia

Ingatan manusia, meskipun luar biasa dalam kapasitasnya, memiliki batasnya. Anda mengingat hal-hal dengan akurasi dan durasi yang tidak dapat diprediksi, dan ketika Anda lupa, tidak ada cara untuk mengingatnya sesuka hati.

Itu sebabnya kami menggunakan penyimpanan memori persisten untuk bergerak dengan kecepatan yang dapat diprediksi. Ini bukan tentang dokumentasi formal seperti manual pengguna yang Anda buat lama setelah fakta dan untuk digunakan orang lain. Ini tentang menggunakan dokumen secara harfiah sebagai ekstensi eksternal memori Anda selama pekerjaan yang membantu Anda melalui proses pengembangan perangkat lunak.

Saya sarankan Anda mendokumentasikan pemikiran dan rencana Anda di sepanjang jalan setiap kali Anda menghadapi tugas-tugas non-sepele atau tugas-tugas yang melibatkan lebih dari satu orang. Cobalah untuk membuatnya semurah mungkin. Jangan membuat dokumen formal dengan logo perusahaan di atasnya. Alat yang bagus adalah wiki perusahaan dengan ruang proyek Anda di dalamnya. Buat halaman khusus untuk tugas atau masalah (30 detik). Kemudian perbarui setiap kali Anda mendapatkan ide atau Anda akan mendiskusikannya dengan orang lain.

Dalam rapat, katakan “tunggu, biarkan saya meletakkannya” dan luangkan 10-30 detik untuk mengungkapkannya secara tertulis. Tulisannya tidak boleh panjang lebar, tetapi harus lengkap dan koheren, seperti Anda mentransfer ide secara keseluruhan ke atas kertas. Nanti, Anda atau siapa pun yang membaca bagian Anda harus memahaminya sejelas yang Anda pahami sekarang. Trik itu menghemat banyak waktu, namun memungkinkan Anda untuk mendokumentasikan dengan cepat.

Teknik ini memiliki dua tujuan.

Pertama, itu mengunci kemajuan Anda menuju kesuksesan dengan menekannya dengan keras ke batu. Tidak ada lagi risiko seseorang melupakan sesuatu, mengulangi hal yang sama berulang kali, atau menegosiasikan kembali hal yang sama yang sudah dinegosiasikan.

Kedua, Anda menjernihkan pikiran, membuang masalah yang mengganggu Anda. Sekarang pikiran Anda lapar akan tantangan berikutnya. Apa peningkatan produktivitas!

Ini berlaku untuk semua ukuran proyek atau tugas. Untuk yang lebih besar, Anda hanya akan memiliki ruang yang lebih besar dengan hierarki halaman yang tumbuh secara bertahap seiring perkembangan proyek Anda. Konsep penting di sini adalah menyiapkan ruang dan struktur dokumentasi sebelum Anda memulai tugas Anda untuk membuat protokol pembuangan memori cepat!

Bagi orang-orang yang menyukai analogi teknologi, saya akan membandingkan pikiran kita dengan prosesor dengan kekuatan pemrosesan yang sangat besar tetapi memori operasional yang terbatas. Anda pada dasarnya dapat memikirkan satu hal pada satu waktu. Dalam analogi ini, dokumentasi Anda berfungsi sebagai penyimpanan persisten, sedangkan pikiran Anda memecahkan masalah kompleks dalam pendekatan berulang. Pada titik tertentu, Anda memutuskan untuk memulai iterasi berikutnya, membaca dokumentasi sebelumnya, dan memuat status saat ini dalam memori operasi Anda, memikirkannya sebentar dan memperbarui kode dan dokumentasi dengan temuan baru Anda. Langkah demi langkah hingga selesai.

Semua yang disebutkan di atas, saya tidak mendorong orang untuk memproses banyak tugas sekaligus. Sebaliknya, semakin sedikit tugas yang Anda miliki, semakin baik. Namun, tidak banyak situasi kerja yang benar-benar dioptimalkan untuk manusia, dan multitasking mungkin diperlukan dan Anda harus menanganinya dengan cara tertentu. Trik di atas membantu menanganinya dengan lebih baik.

Aturan No. 4: Berhenti Membuang Waktu untuk Estimasi Waktu Formal

Tidak ada dua proyek yang sama. Lain kali Anda melakukan proyek serupa, Anda akan memiliki pelanggan yang berbeda, tujuan yang berbeda, tim yang berbeda; bahkan mungkin teknologi yang berbeda. Bahkan menggunakan alat dan komponen standar, Anda masih perlu menyesuaikan konfigurasi dan arsitekturnya. Saat Anda menangani proyek perangkat lunak, ingatlah bahwa mereka melibatkan suatu tempat antara 50% dan 100% pekerjaan kustom. Mereka membutuhkan penelitian, diskusi, pemikiran, percobaan, dan kegiatan lain yang sangat tidak terduga. Dalam praktiknya, Anda mungkin mengalami perbedaan besar dalam apa yang tampak di permukaan sebagai jenis proyek yang sama persis dan apa yang telah Anda lakukan sebelumnya. Jenis proyek baru, dengan perluasan, hampir tidak mungkin untuk memperkirakan dengan tepat.

Jika sangat tidak terduga, lalu bagaimana seharusnya manajer proyek menyajikan jadwal proyek dan menaatinya?

Ada satu metode formal untuk melakukan ini yang dijelaskan dalam literatur; yaitu, untuk membagi keseluruhan proyek menjadi langkah-langkah yang lebih kecil, memperkirakan berapa lama waktu yang dibutuhkan setiap langkah, dan kemudian menghitung total panjang proyek dengan menggabungkan panjang pekerjaan masing-masing bagian. Ada banyak teori di balik metode ini yang diajarkan dalam kursus MBA.

Sayangnya, tidak ada jumlah matematika yang bisa menyelamatkannya. Metode ini terkenal tidak akurat, sampai-sampai benar-benar tidak dapat digunakan dan tidak praktis, belum lagi betapa memakan waktu. Saya tidak pernah melihat seorang manajer proyek yang menggunakan metode perhitungan formal tanpa penyesuaian, bahkan di kalangan fanatik metodologis. Bahkan ketika perusahaan secara ketat memberlakukan penggunaan metode seperti itu! Faktanya, manajer dengan kinerja terbaik menggunakan metode alternatif yang sama sekali berbeda, seperti yang dijelaskan di bawah ini:

Manajer proyek yang baik memperhatikan jenis proyek, lingkungan, sumber daya yang terlibat, jenis organisasi, dan semua aspek pekerjaan lain yang mempengaruhi panjang proyek yang sebenarnya. Tentu saja, tidak ada yang perlu belajar hanya dari kesalahan mereka sendiri. Pengamatan tersebut dapat dilakukan baik secara langsung maupun tidak langsung; misalnya melalui buku-buku atau dengan mempelajari proyek-proyek yang dilakukan oleh orang lain atau bahkan hanya dengan mewariskan pengetahuan dari orang ke orang. Pengetahuan statistik tingkat atas seperti itu meningkatkan navigasi jadwal proyek pribadi.

Saya ingin menyoroti dua konsekuensi penting dari metode yang dijelaskan di atas.

Pertama, akurasi estimasi meningkat seiring dengan pengalaman. Tidak mungkin orang yang tidak berpengalaman yang dipersenjatai dengan metodologi kuat apa pun yang mereka miliki dapat menjadi ahli dalam hal itu. Kedua, bahkan estimasi terbaik pun masih bagus hanya dalam hal statistik. Artinya, seseorang dapat mengatakan bahwa proyek tertentu mungkin memakan waktu antara empat dan dua belas bulan. Seandainya ini benar, orang harus memahami bahwa ada kemungkinan 50% proyek akan berjalan selama waktu rata-rata delapan bulan.

Memahami prediksi statistik memiliki efek yang luar biasa. Seorang manajer yang bijaksana hanya akan memberikan perkiraan dua belas bulan pada proyek seperti itu dan kemudian membuat semua orang kagum dengan menyelesaikannya lebih awal. Dengan kata lain, tidak ada yang mengharapkan tim untuk mengikuti jadwal proyek hingga satu hari.

Saran umum untuk manajer proyek dan atasan mereka adalah berhenti membuang-buang waktu pada metodologi perkiraan waktu formal. Sebaliknya, dorong pengumpulan informasi statistik tentang durasi proyek dan bagikan informasi ini ke seluruh perusahaan. Saya tahu perusahaan di mana pendekatan semacam itu diterapkan di seluruh perusahaan, menghasilkan presisi prediksi yang menakjubkan.

Aturan No. 5: Pahami Biaya Beralih Tugas dan Prioritas Juggling

Pikiran manusia direkayasa secara luar biasa oleh alam. Meskipun luar biasa, ia memiliki keterbatasan. Dengan kata lain, itu dirancang untuk unggul di bidang tertentu dan dalam jenis tugas tertentu.

Pikiran pengembang jelas merupakan aset besar dalam pengembangan perangkat lunak. Apakah Anda, sebagai manajer proyek, tertarik untuk memahaminya dengan lebih baik dan menempatkannya pada posisi di mana ia melakukan yang terbaik?

Mari kita jelaskan secara sederhana, hindari terlalu banyak teori. Ingat, teori hanya membawa Anda sejauh ini sebelum Anda perlu belajar dari pengalaman, baik Anda sendiri atau dari orang lain.

Pikiran manusia memiliki pemecahan masalah yang kuat dan potensi generasi ide. Sayangnya, tidak selalu mungkin untuk memanfaatkan potensi ini, terutama karena untuk mendukung pembuatan ide, Anda perlu menyimpan semua bagian dari masalah bersama-sama dalam memori aktif Anda pada waktu yang sama. Itulah sebabnya pemecahan masalah kompleks melalui tahap penyederhanaan ketika tugas digeneralisasi atau dirumuskan ulang untuk memotong bagian yang tidak penting dan mengurangi jumlah elemen yang disimpan dalam memori secara bersamaan. Dengan kata lain, kita dapat memecahkan satu masalah kompleks yang sangat sempit atau beberapa masalah sederhana.

Namun rasionya tidak linier. Meningkatkan jumlah hal yang Anda lakukan secara bersamaan secara drastis merusak kemampuan pemecahan masalah Anda. Karena itulah manusia selalu bekerja dan akan menggunakan pemisahan peran sebagai optimalisasi kehidupan. Dua orang yang bekerja secara terpisah pada dua tugas akan membuat terobosan lebih cepat daripada jika mereka berdua mengerjakan kedua tugas pada waktu yang sama.

Sifat pikiran manusia yang penting lainnya adalah ketidakmampuannya untuk beralih di antara tugas-tugas dengan segera seperti yang dilakukan komputer. Memang, Anda tidak bisa berhenti memikirkan sesuatu sesuka hati. Anda juga tidak dapat langsung mulai memikirkan konsep baru dengan kecepatan penuh. Kelambanan mental semacam itu diilustrasikan dengan sempurna oleh operator kontrol lalu lintas udara. Meskipun mereka melihat radar dan melihat keseluruhan gambar, mereka masih perlu memasukkannya ke dalam memori mereka untuk beroperasi dengan cepat. Dibutuhkan sepuluh menit bagi operator baru untuk melihat layar sebelum mereka dapat mengganti yang lama pada pergantian shift.

Apa yang membuatnya lebih buruk adalah bahwa kita tidak bisa melupakan hal-hal sesuka hati. Segala sesuatu yang telah kita pelajari tetap bersama kita dan secara bertahap memudar seiring waktu, menempati ruang yang dapat kita gunakan untuk pengetahuan baru. Dan bahkan lebih buruk, efek ini diperparah oleh perasaan "urusan yang belum selesai". Jauh lebih mudah untuk melupakan sesuatu yang sudah selesai dan yang tidak akan pernah Anda butuhkan di masa depan. Sedangkan ketika Anda mengesampingkan hal-hal untuk diselesaikan nanti, otak Anda secara alami mencengkeram informasi yang ditandai sebagai "untuk referensi di masa mendatang", tidak mau membiarkan pengetahuan baru menggantikannya.

Baik. Sekarang setelah kita menguraikan gagasan untuk beralih tugas, mari kita lihat cara kerjanya dalam eksperimen pemikiran kehidupan nyata (bisa dikatakan).

Bayangkan Anda memiliki sepuluh pengembang reguler yang mengerjakan sepuluh tugas reguler—satu tugas per orang. Dengan asumsi kita dapat memasukkan mereka ke dalam lingkungan bebas gangguan yang sempurna, setiap tugas dapat diselesaikan dalam waktu tertentu oleh satu pikiran. Semuanya akan memakan waktu selama yang dibutuhkan untuk menyelesaikan satu tugas terpanjang.

Sekarang, mari kita ulangi eksperimen mental yang sama. Kali ini, kami akan terus mengalihkan tugas tugas antara pengembang tanpa alasan (penting). Setiap hari, setiap pengembang mendapat tugas baru untuk dikerjakan. Lebih baik lagi, mari kita aktifkan setiap jam. Seberapa cepat mereka akan selesai, menurut Anda? Mungkin tidak pernah.

Manajer proyek dalam skenario pertama mampu menjalankan proyek secara efektif. Yang kedua berhasil "mengeksekusi", itu pasti...dalam arti mereka memfasilitasi kematiannya. Selamat. Teknik membunuh proyek ini lebih efektif karena selain membuang-buang waktu, juga menurunkan moral karyawan hingga nol.

Kebanyakan orang akan setuju dengan contoh di atas ketika disajikan kepada mereka dengan cara yang murni akademis seperti itu. Namun, dalam kehidupan nyata mereka tiba-tiba melupakan segalanya di bawah tekanan sekecil apa pun. Bos besar menuntut laporan kemajuan, atau pelanggan menanyakan tentang tanggal implementasi fitur tertentu—hampir semua peristiwa eksternal dapat membuat manajer proyek bergegas ke tim dan mengungkapkan keprihatinan mereka, diikuti dengan kesibukan penugasan kembali dan juggling prioritas dalam mencoba untuk memenangkan sedikit waktu di sana-sini, pada akhirnya menghasilkan apa-apa selain membuang proyek lebih jauh lagi.

Itu adalah skenario kehidupan nyata yang cukup sering terjadi, sayangnya.

Manajer yang baik berdiri dan melindungi tim dari gangguan kecil seperti itu dengan menyerap gelombang kejut emosional dan mengubahnya menjadi topik diskusi masa depan yang produktif. Itu pasti sulit secara emosional, tetapi itu satu-satunya cara untuk menjaga tim dalam ritme kerja yang baik dan membiarkan mereka melakukannya.

Aturan No. 6: Gunakan Tinjauan Arsitektur sebagai Cara untuk Meningkatkan Desain Sistem

Industri TI beroperasi dengan gagasan over -dan under- engineering. Ketika muncul dalam sebuah wawancara, semua orang mengatakan bahwa over-engineered itu buruk. Yang itu mudah dijawab karena pertanyaannya sendiri mengandung konotasi negatif “over” yang berarti “terlalu banyak.” Pengetahuan praktis yang sebenarnya bagaimana mengenali ketika arsitektur Anda menjadi terlalu direkayasa dan menghindarinya pada tahap awal.

Biarkan saya memberi Anda beberapa petunjuk saya yang sudah terbukti benar tentang itu.

Pertama-tama, solusi tersebut dapat dianggap over-engineered jika ada solusi lain yang lebih sederhana yang memberikan semua fungsi yang diperlukan. Itu berarti jika Anda tidak mengetahui solusi yang lebih sederhana, maka solusi paling sederhana apa pun yang dapat Anda tawarkan adalah yang terbaik di mata Anda kecuali seseorang membuktikan bahwa Anda salah.

Jika arsitek imajiner kami benar-benar berusaha untuk kesempurnaan solusi, tinjauan arsitektur biasa menjamin itu cukup optimal. Sayangnya, tinjauan arsitektur membutuhkan setidaknya beberapa arsitek berkualitas lainnya. Ini berbahaya karena tidak tersedia atau tidak praktis dalam banyak kasus. Dengan tidak adanya peer review, arsitek rentan terhadap kesalahan umum. Mari kita tinjau satu per satu dan diskusikan kemungkinan solusi untuk masing-masing.

Salah satu kesalahan paling populer adalah mendesain tanpa tujuan bisnis. Tampaknya jelas bahwa setiap aktivitas kerja harus dikaitkan dengan kepuasan konsumen akhir atau keberhasilan perusahaan atau kebutuhan bisnis serupa. Namun seringkali, Anda dapat melihat arsitektur dirancang secara keseluruhan atau sebagian tanpa tujuan tersebut dalam pikiran. Alasannya tidak ada atau bermuara pada penggunaan lonceng dan peluit modern sebanyak mungkin.

Arsitek dalam hal ini tidak melakukan apa yang telah dibayar konsumen. Sebaliknya, mereka bermain dengan mainan keren untuk kesenangan dan kesenangan mereka sendiri. Ini sama sekali tidak dapat diterima dalam industri formal. Namun, tampaknya hal itu cukup sering terjadi.

Terkadang, masalahnya terletak pada kepribadian arsitek dan obsesi mereka terhadap teknologi atau alat tertentu. Mereka hanya suka menggunakannya dan tidak dapat menjelaskan secara koheren kebutuhan bisnis apa yang mereka coba selesaikan. Dekat dengan itu adalah kasus lain ketika orang tidak tahu apa-apa selain membangun sesuatu dari potongan-potongan kecil. Tentunya, setiap peristiwa eksternal memicu dorongan mereka untuk terjun ke dunia desain dan tidak pernah kembali ke klien nyata. Meskipun pemicu awal mungkin merupakan masukan bisnis yang valid, keterpisahan mereka yang berkepanjangan dari kenyataan mengurangi kegunaan karya seni mereka.

Obat untuk ini sangat sederhana, tetapi membutuhkan disiplin diri. Seorang arsitek yang baik tidak boleh menyentuh pena dan kertas sampai mereka dapat dengan jelas dan jujur ​​menjawab sendiri mengapa itu diperlukan. Kebutuhan seperti itu bisa datang dalam berbagai bentuk. Ini bisa menjadi persyaratan formal, kebutuhan implisit untuk peningkatan produk, atau munculnya teknologi baru yang membuat desain sebelumnya kurang efektif. Bagaimanapun, itu tidak boleh menjadi pemicu formal selama arsitek sendiri memahami kekuatan pendorongnya. Kemudian mereka dapat menggunakan kekuatan ini sebagai verifikasi akhir dari kualitas desain mereka.

Masalah lain yang lebih sulit dideteksi terkait dengan pemikiran arsitektur blok. Orang-orang dengan mentalitas seperti itu percaya bahwa ada solusi untuk segala sesuatu dan solusi tersebut selalu diimplementasikan sebagai blok bangunan. Dengan kata lain, mereka menerjemahkan fungsionalitas ke komponen secara langsung tanpa mengevaluasi arsitektur secara keseluruhan. Mereka mungkin hanya melampirkan komponen yang memberikan fungsionalitas yang diinginkan ke sistem ketika kebutuhan akan fungsionalitas tersebut muncul. Sebagian besar waktu, ini memenuhi persyaratan formal tetapi meninggalkan sistem dalam keadaan tidak koheren. Blok baru tidak dipilih berdasarkan kompatibilitas sistem yang ada untuk pengembangan, dukungan, atau bahkan model lisensi perusahaan. Jadi, tim mencoba memodifikasi konfigurasi yang ada atau mengimplementasikan fungsi ini melalui kapasitas sistem yang ada. Akibatnya, dukungan dan pemeliharaan sistem secara bertahap berubah menjadi mimpi buruk yang berbelit-belit diikuti oleh penurunan kinerja.

Tidak ada solusi sederhana untuk masalah ini, karena rekayasa sistem adalah seni dan tidak pernah mungkin untuk memprediksi apakah komponen baru harus ditambahkan atau dapat dihindari. Praktik terbaik mungkin adalah menyimpan simpanan pemeliharaan dan masalah arsitektur yang terakumulasi dari waktu ke waktu, diikuti dengan tinjauan berkala terhadap arsitektur sistem secara keseluruhan. Tinjauan berkala ini juga dapat mempertimbangkan teknologi yang muncul. Jadi tujuan umum dari tinjauan arsitektur seharusnya bukan untuk memperbaiki masalah tetapi untuk menilai kelayakan potensial dari perbaikan yang diinginkan dan dari sistem secara keseluruhan terhadap keniscayaan yang menjulang dari keusangan.

Peraturan No. 7: Nilai Pemain Tim

Sebagian besar profesional industri TI ditanya dalam sebuah wawancara apakah mereka adalah pemain tim yang baik atau apakah mereka bekerja dengan baik dalam sebuah tim. Namun, mungkin tidak ada yang pernah melihat definisi yang jelas untuk itu dalam literatur. Jelas, orang seperti itu akan berkontribusi pada kesuksesan tim secara umum, tetapi hanya sedikit orang yang benar-benar dapat mendefinisikan kualitas pribadi yang khas untuk memastikan kesuksesan tersebut.

Saya mengamati banyak orang yang bekerja pada tingkat yang berbeda dan melihat bagaimana kualitas pribadi mereka mempengaruhi kemajuan proyek. Saya ingin menyampaikan petunjuk berikut mengenai kualitas pribadi yang paling membantu dalam kerja tim.

Berkomunikasi

Kualitas pertama dan terpenting, tentu saja, adalah kemampuan untuk berkomunikasi.

Bayangkan seseorang dengan kemampuan komunikasi nol. Tentunya tidak menerima umpan balik dari anggota tim membuat mereka sama sekali tidak berguna. Ini sangat jelas bahwa tidak ada yang benar-benar mengukur keterampilan ini selama wawancara, yang menyiratkan bahwa keterampilan tersebut berada pada tingkat yang cukup baik selama orang tersebut dapat berbicara dengan baik.

Komunikasi bukanlah keterampilan biner ya/tidak; ini lebih merupakan jendela transfer informasi. Semakin luas, semakin cepat dan jelas pertukaran informasi.

Karena kisaran bukaan jendela itu sangat bervariasi di seluruh populasi, ukuran lebar jendela seperti itu merupakan karakteristik penting dari pemain tim. Ingatlah bahwa kita berbicara tentang menyampaikan informasi dalam konteks ini tetapi bukan tentang berbicara dengan lancar atau mendorong orang atau memotivasi mereka atau mengatur mereka melalui pembicaraan dan komunikasi.

Gaya komunikasi juga tidak relevan. Informasi dapat disampaikan secara lisan, tekstual, gambar, atau campuran. Orang tersebut dapat berbicara cepat atau lambat. Mereka bisa ramah, seperti menatap mata Anda dan tersenyum sepanjang waktu, atau mereka bisa memalingkan muka dan berbicara dengan suara yang monoton. Gaya dapat mempengaruhi persepsi pribadi Anda tentang rekan kerja Anda, tetapi selama Anda memahami dengan jelas apa yang mereka maksud, gaya apa pun sudah cukup.

Mari beralih ke kasus praktis dalam mendeteksi dan mengukur kemampuan komunikasi.

Ada dua aspek utama keterampilan komunikasi secara umum. Pertama, kemauan untuk berbagi informasi. Beberapa orang ingin sekali berbagi tetapi yang lain mencoba menyembunyikan informasi. Kecenderungan itu kurang lebih alami, tetapi dapat diubah secara perlahan dengan motivasi dan pelatihan diri. Aman untuk mengasumsikan bahwa orang yang menunjukkan satu jenis kesediaan berbagi informasi akan menunjukkannya di masa depan juga. Itulah mengapa sifat itu bagus untuk memprediksi kesuksesan kandidat di masa depan dalam sebuah tim.

Dalam kehidupan nyata, orang yang mencoba menyembunyikan informasi mudah terlihat. Mereka biasanya mencoba untuk memberikan informasi yang sengaja tidak berguna daripada apa pun yang benar-benar dibutuhkan. Atau, mereka mengajukan pertanyaan pendahuluan untuk mengubah arus informasi ke dalam dan meminimalkan jawaban mereka terhadap kejadian yang “perlu diketahui”. Apa pun taktik mereka, pada akhirnya Anda akan merasa bahwa Anda tidak mendapatkan informasi yang diinginkan dari mereka, atau bahwa mendapatkan informasi itu membutuhkan terlalu banyak usaha ekstra.

Penting untuk memahami maksudnya, karena beberapa tipe orang yang terbuka mungkin akan menanyakan pertanyaan awal kepada Anda untuk lebih memahami pertanyaan Anda dan kemudian memberikan jawaban untuk Anda dengan cara yang paling nyaman. Orang yang bermaksud menyembunyikan informasi akan mengajukan pertanyaan tambahan hanya untuk mengalihkan pembicaraan dan tidak pernah menjawab pertanyaan awal Anda.

Bagian lain dari keterampilan komunikasi adalah kemampuan untuk mendengarkan pendengar.

Orang yang berbeda memiliki tingkat pemahaman topik yang berbeda, gaya komunikasi yang berbeda, dan bahkan mungkin minat yang berbeda pada detail spesifik. Beberapa orang pintar komunikatif akan memvariasikan alur percakapan mereka tergantung pada kemampuan pendengar untuk memahaminya dan mempersiapkan jawaban mereka untuk menyampaikan informasi tertentu. Dalam persiapan seperti itu, beberapa pertanyaan pendahuluan mungkin diajukan untuk mempersempit minat pendengar. Kemampuan untuk "mengatasi" perbedaan komunikasi adalah keterampilan yang benar-benar hebat, karena memungkinkan kita untuk mencapai pemahaman di hampir semua kasus. Pembicara yang fleksibel, di sisi lain, kadang-kadang mungkin hanya terjebak di jalan buntu kesalahpahaman yang tak terpecahkan.

Memahami Kekuatan dan Kelemahan

Mari kita fokus pada kualitas pribadi lain yang penting bagi seorang pemain tim.

Kebanyakan orang akan setuju bahwa lingkungan tim harus lebih ramah daripada rata-rata dunia sekitarnya untuk mendorong kolaborasi dan meningkatkan produktivitas. Oleh karena itu, penting bagi sebuah tim untuk memahami area kuat dan lemah masing-masing anggota untuk mendistribusikan tugas dengan benar dan menutupi kelemahan dengan kekuatan. Langkah pertama di jalur ini adalah bagi semua anggota untuk secara jujur ​​mengukur keterampilan mereka satu sama lain. Secara psikologis, ini mungkin sulit karena kita secara alami cenderung menyembunyikan titik lemah kita dari orang lain, melindungi diri kita sendiri.

Di sinilah suasana tim yang ramah datang untuk membantu.

Jadi anggota baru diharapkan bermain sesuai aturan tim. Sayangnya, beberapa orang tidak dapat menurunkan kewaspadaan mereka bahkan di lingkungan yang bersahabat. Mereka berperilaku seperti serigala tunggal sepanjang hidup mereka. Ini lebih kuat dari mereka. Sayangnya, sikap seperti itu tidak berkontribusi pada upaya tim.

Ada teknik mudah untuk mengenali serigala penyendiri seperti itu dalam wawancara. Mereka tidak pernah mengakui bahwa mereka tidak tahu sesuatu. Tentu saja, orang suka menunjukkan yang terbaik, menunjukkan semua kemampuan mereka dan mencoba menyelesaikan setiap masalah yang sulit. Namun, ada batas pengetahuan untuk semua orang. Batasan kita membentuk keterampilan kita. Tidak mengakui batasan berarti bahwa para kandidat menampilkan diri mereka sebagai Jack-of-all-trade, sama-sama pandai dalam segala hal dan tidak sama sekali.

Ketika Anda menyewa seorang spesialis, Anda mungkin ingin menghindari orang-orang seperti itu. Selain itu, sikap arogan itu sering kali disertai dengan tanda bahaya lainnya: keengganan untuk meminta bantuan. Kemampuan untuk meminta bantuan sangat penting untuk kerja tim. Tanpa itu, kita tidak bisa maju dan berkembang secepat itu. Orang yang keras kepala seperti itu akan menghabiskan sumber daya dan waktu perusahaan, tanpa henti melawan tugas-tugas sulit tetapi tidak pernah meminta bantuan rekan satu tim. Ada trik mudah untuk mendeteksi kandidat seperti itu saat wawancara. Ajukan pertanyaan yang tidak masuk akal atau sebutkan istilah yang tidak masuk akal. Orang yang normal dan idealnya ingin tahu hanya akan mengatakan bahwa mereka tidak tahu dan bertanya apa itu. Orang yang defensif tidak akan pernah melakukan itu, bahkan jika Anda menyoroti bahwa tidak ada jawaban yang benar atau salah dan bahwa "Saya tidak tahu" tidak mendiskualifikasi mereka.

Aturan No. 8: Fokus pada Organisasi Kerja Tim

Ada sedikit informasi tentang organisasi kerja tim seperti pada topik sebelumnya di atas. Semua orang tahu bahwa kerja tim lebih baik, tetapi bagaimana membangun dan memelihara tim tetap menjadi misteri. Namun, meskipun tidak mungkin mencakup semua aspek pembangunan tim, setidaknya kita dapat menjelajahi beberapa teknik pembangunan tim utama di sini.

Keahlian Membangun

Setiap proyek TI adalah unik. Untuk menjadi sukses di dalamnya, seseorang perlu belajar dan menguasai spesifikasi proyek. Mereka mungkin termasuk pengetahuan teknis dan non-teknis. Contoh pengetahuan non-teknis dapat berupa jaringan pribadi untuk manajemen, pelanggan, tim dukungan teknis, dll. Pengetahuan teknis khusus adalah detail tambahan di atas keterampilan TI umum.

Misalnya, Anda mungkin perlu mengetahui Maven untuk membangun sebuah proyek. Namun, struktur bangunan yang tepat, lokasi properti, dan pemfilteran akan tetap bervariasi per proyek. Seperti halnya semua jenis pengetahuan, menguasai detail seperti itu membutuhkan waktu; semakin banyak waktu yang diinvestasikan di dalamnya, semakin baik kinerjanya. Waktu adalah sumber daya paling berharga yang Anda miliki. Anda ingin menjaga agar anggota tim Anda tetap fokus pada area fungsional yang sama selama mungkin untuk memanfaatkan keahlian mereka dan mengembangkannya lebih jauh lagi, sehingga terus meningkatkan kinerja tim.

Sayangnya, tidak mungkin melakukannya tanpa batas waktu. Dari satu sisi, orang mungkin bosan. Dari sisi lain, Anda berisiko kehilangan keahlian mereka, secara tak terduga menempatkan proyek Anda dalam risiko.

Mari kita lihat apakah ada cara untuk mengatasi kerugian tanpa banyak menghambat kinerja tim.

Bagikan area fokus di antara anggota tim dan biarkan mereka membangun keahlian mereka di dalamnya. Pada titik tertentu, mereka mencapai tingkat yang cukup tinggi yang masuk akal dalam lingkup proyek ini. Upaya belajar ekstra tidak akan meningkatkannya secara signifikan pada saat ini. Tanpa motivasi dan tantangan, orang pintar menjadi bosan dan mulai membenci pekerjaan mereka.

Cegah hal ini dengan membuka kemungkinan belajar di tempat lain bagi mereka. Beri tahu mereka tentang proyek dan tumpukan teknologi perusahaan, dan buka tantangan baru. Jika minat mereka berada dalam ruang lingkup proyek, Anda mendapatkan imbalan ganda untuk menjaga tim Anda tertantang dan memperluas keahlian tim yang berguna pada saat yang sama. However, any self development is good to avoid boredom, even if it doesn't intersect with immediate project needs. As long as the team expert brains are engaged, they keep supporting already-learned project areas in the back of their minds.

When leaving the company, team experts take a big portion of expertise with them. One of the countermeasures you can use is to widely disseminate documentation that can be updated on the fly. Think of the “persistent memory storage” mentioned earlier.

Still, a project manager would love to duplicate knowledge in team member heads if possible. Having two of every expert would be a simple solution for that, albeit twice as expensive. But there is a leaner way to do it. The trick is to let most of your developers develop expertise in multiple areas, so that each project aspect is covered by at least one deep expert. At the same time, chose a few senior members to grow the breadth along with the depth of their expertise. Usually, this role is best played by a team development lead or an architect. The team lead interacts with all team members and participates in all task implementations. They can tap into each and every aspect of the project, understanding all of its internals. This way, even if you lose one of the experts, the leader can take over and keep on the project progressing until you can hire and train the replacement.

Another flavor of same idea is to cross-train developers in adjacent areas, letting them to observe, learn, and occasionally try their peers' work. Keep in mind that this cross-training needn't be extensive, so it doesn't disrupt focus on developers' primary tasks and doesn't impede productivity. Developing expertise across leadership and cross-training developers builds you a cushion of protection against unforeseen life culprits and allow you some time to maneuver with project resources.

Minimizing Distraction

Software development is a chain of complex and creative problem solving. Even though, with industry development, these complex problems get more and more automated, the work doesn't become easier. It still involves a large amount of art and individual insight, which is very hard to predict and sometimes even harder to wrangle.

Developers are the edge of the weapon. Their concentration is equivalent to the hardness of the weapon's tip. Increase their focus and you'll cut through problems like a hot knife through butter. Distract them and you'll end up clumsily poking at the butter with a blunted stick.

This cannot be over emphasized: Non-problem-solving work can be intensified with motivation or extra effort. For problem solving work, you need maximum detachment from the mundane world. It is difficult to leave all everyday problems behind, and a good project manager should build a quiet development environment in both the physical and mental senses. A developer's workplace should be analogous to a sensory deprivation tank.

Physically, this is implemented as a closed work space. Every team member should have a cube at least where they can dive into solitude. It is preferable to avoid loud noises and aisle conversations. Quick interpersonal communications should be maintained by emails and chats. Large groups should use closed rooms for their meetings to not distract others. This is a pretty standard picture for office life as it used to be.

Unfortunately, the open space paradigm is being adopted more and more widely even in large offices. I would warn against his fad. Even worse, together with open spaces, top management encourages in-place team conversations. That is, in essence, shouting to a person in another row over an uninvolved team member's head. A developer that is interrupted by loud conversation twenty times a day won't have a shred of concentration left. Certainly a major performance killer.

Allowing for a Learning Curve

Knowledge itself is power. This is especially true for such a complex industry as IT. Every task here has its regular cycle: learn, research, implement. The learning phase in particular is invaluable. Not only does better understanding allow better and faster implementation, there are certain knowledge thresholds that must be passed in order to achieve something at all. Of course, there is no point in over-learning either. Each skill should match the production need and not much above it.

However, often, developers are pressured in the opposite direction; to stop learning and to do nothing but produce. Learning is perceived as wasted effort, as it doesn't move the task progress bar. This seems like a really easy problem to solve, sitting at home and reading this article. Yet in the real life, the slightest work pressure turns every manager into that demanding idiot who insists that everybody “stop learning and start doing something already.” I swear, I have heard those exact words so many times throughout my career… A good manager and team leader should understand that learning is an important part of the process even if it doesn't directly increment the progress bar.

Building a Competitive Development Workshop

The tips and tricks presented above are a subset of effective software production expertise. By understanding and applying them in real life, you'll improve your production effectiveness little by little. If you think they are largely unconnected and lacking a theoretical base, you are absolutely right.

I would like to highlight that building a competitive development workshop is not a single-discipline task. It requires knowledge and expertise in multiple adjacent areas. Building such expertise is a hard work. There is no single theoretical base or idea that would solve all your problems at once. Believing in such a silver bullet just serves to distract you from the real goal.

Try out these tips at work to see if they are worth adopting permanently. If you find them useful (or not), leave a comment below and share your experience!