Tidak seorang pun akan mengharuskan pengembang untuk menulis kode tanpa akses ke komputer, tetapi banyak perusahaan percaya bahwa entah bagaimana ia harus bekerja tanpa kemampuan untuk sepenuhnya memanfaatkan kemampuan mentalnya. Dan ini tidak realistis.
Jadi mari kita lihat daftar dua belas hal yang mencegah pengembang memasuki kondisi aliran dan memberikan produktivitas maksimum. Saya akan mencoba untuk beralih dari yang paling penting ke yang kurang penting. Sarankan opsi dan komentar Anda!
Jika seseorang meragukan apakah perlu mengeluarkan uang dan usaha untuk hal ini, cukup untuk mengingat berapa banyak programmer dibayar. Bahkan peningkatan 10% dalam produktivitas adalah banyak uang!
1) Rapat dan gangguan lainnya
Menurut pendapat saya, mengganggu pengembang adalah cara paling pasti untuk membunuh produktivitasnya sejak awal. Dia tidak bisa begitu saja mengambil dan melanjutkan dari tempat dia terganggu. Pertama dia perlu terlibat dalam proses itu lagi, dan kemudian pergi melalui seluruh rantai pemikiran sampai saat yang tepat - ini saja bisa memakan waktu setengah jam atau lebih. Dan semakin banyak istirahat seperti itu, semakin banyak iritasi menumpuk, semakin rendah kualitas pekerjaan menjadi, semakin sering bug muncul, dan daftar ini dapat dilanjutkan.
“Semakin sering saya terganggu ketika saya mencoba memulai suatu tugas, semakin banyak waktu mulai berlalu di antara upaya. Jika saya ditarik sepanjang pagi, tidak ada yang terkejut bahwa hari itu ternyata tidak produktif "- Pengembang anonim dengan Reddit
Nah, bagaimana dengan pertemuan itu? Satu-satunya perbedaan mereka dari gangguan lain adalah bahwa mereka sudah direncanakan sebelumnya. Dan itu hanya membuat situasinya semakin buruk. Sulit bagi seorang programmer untuk maju dalam memecahkan masalah jika ia mengantisipasi kerusakan di muka. Oleh karena itu, jika dalam satu atau dua jam dia harus pergi ke pertemuan perencanaan, kemungkinan besar dia tidak akan dapat melakukan sesuatu yang signifikan untuk proyek-proyeknya - lagipula, sebagian besar tugas rekayasa membutuhkan lebih banyak waktu.
Seperti yang dikatakan Paul Graham: "Satu pertemuan dapat membunuh setengah hari: waktu dibagi menjadi dua periode, di mana Anda tidak dapat melakukan sesuatu yang serius."
Bagaimana cara menghindari keadaan ini? Semuanya telah dilukis di ini untuk waktu yang lama, jadi tidak ada alasan. Anda hanya perlu menempatkan planer di awal hari atau, katakanlah, tepat sebelum makan malam, sehingga Anda tidak perlu mengalihkan perhatian orang dari pekerjaan tanpa perlu.
2) nitpicking
Dari semua jenis manajer, mereka yang melakukan intervensi dengan alasan apa pun, mungkin dampak terburuk pada produktivitas karyawan. Tentu saja, ini juga dipengaruhi oleh fakta bahwa tipe khusus ini cenderung mengatur banyak pertemuan dan menuntut perhatian pengembang karena alasan yang tidak terduga. Tapi ini bukan satu-satunya poin. Tindakan semacam itu menunjukkan kurangnya kepercayaan, dan sebagai akibatnya, orang merasa bahwa mereka dianggap tidak mampu melakukan apa pun dan mempertanyakan keterampilan profesional mereka. Sekalipun programmer masih memiliki motivasi untuk bekerja meskipun ada gangguan yang tak ada habisnya, sikap seperti itu akan benar-benar mengecewakannya. Konsekuensinya tidak terbatas pada satu tetes kinerja. Manajer yang intusif terutama sering memaksa karyawan untuk meninggalkan perusahaan, atau setidaknya tim.
3) Tidak jelas
Kurangnya kejelasan dapat diilustrasikan dengan banyak contoh berbeda. Misalnya, laporan bug dengan semangat "Tidak berfungsi di sini, perbaiki!" jelas tidak memberikan pengembang semua informasi yang diperlukan untuk bekerja. Ngomong-ngomong, dalam kasus khusus ini, pengenalan template untuk laporan bug dapat membantu.
Atau kasus lain: persyaratan yang tidak jelas untuk beberapa bagian dari produk. Dengan pengantar seperti itu, pengembang mulai melakukan seperti yang mereka bayangkan, dan kemudian seorang manajer datang dengan deskripsi yang lebih rinci tentang perilaku pengguna yang diharapkan, dan mereka semua harus memulai dari awal lagi.
Prioritas yang ditetapkan secara tidak jelas termasuk dalam kategori yang sama. Pemrogram menghabiskan banyak waktu memeras otak mereka pada apa yang harus mereka mulai dengan, meskipun menghindari ini akan sangat sederhana. Nah, jika mereka harus melapor kepada manajer mengapa mereka terlibat dalam ini dan bukan ini (terlepas dari kenyataan bahwa tidak ada yang menentukan pesanan), Anda dapat yakin bahwa ini akan membuat mereka hebat.
4) Manajer Seagull
Pernah dengar ini? Ada manajer yang sama sekali tidak berpartisipasi dalam alur kerja ... kecuali saat-saat ketika mereka tiba-tiba memutuskan untuk menyelam pada seseorang dan melakukan kesalahan. "Ini tidak baik, dan ini juga, tetapi tidak terlihat sama sekali," dan terbang. Harus saya akui, saya suka perbandingannya, tetapi fenomena di baliknya jauh lebih umum daripada yang kita inginkan. Perilaku ini sangat memengaruhi para pengembang: banyak dari mereka harus bekerja dengan baik selama berjam-jam, dan seseorang keluar dari aliran selama berhari-hari.
5) Pencurian Laurels
Pernahkah terjadi pada Anda bahwa salah satu manajer atau pemrogram lain mengaitkan dirinya dengan apa yang Anda perjuangkan selama beberapa minggu? Pengembang menempatkan profesionalisme mereka di atas segalanya. Mencuri jasa orang lain sama halnya dengan menyangkal kompetensi seseorang untuk meningkatkan kemampuannya. Saya menempatkan poin ini cukup tinggi karena saya percaya bahwa hal-hal seperti itu mengarah pada situasi yang sangat tegang, yang untuk waktu yang lama "menjatuhkan" kinerja seluruh tim.
6) Perabot: kebisingan, gerakan, desain ruang kerja ...
Ini mungkin tampak aneh bagi orang-orang dari profesi lain, tetapi bagi para programmer, lingkungan banyak menentukan dalam perjalanan pekerjaan. Ucapkan white noise - dengung AC, dengung mobil dan truk dari jalanan - bantu mereka fokus lebih baik. Itu sebabnya banyak dari kita bekerja dengan headphone! Ngomong-ngomong, saya baru-baru ini menemukan RainyMood - hal yang hebat!
Namun, jika kantor dirancang sedemikian rupa sehingga selalu ada gerakan di sekitar orang tersebut, maka ini akan memiliki efek sebaliknya. Dan jika, di samping itu, monitor dipasang sedemikian rupa sehingga manajer terus-menerus melihat apa yang ada di layar, ini menciptakan tekanan yang tidak perlu dan alasan yang tidak perlu untuk mengalihkan perhatian pengembang dari bisnis.
7) Batas proyek offset
Dalam manajemen proyek, istilah ini digunakan untuk situasi di mana volume proyek tumbuh tak terkendali. Ini biasanya terjadi ketika awalnya mereka tidak didefinisikan secara ketat dan didokumentasikan atau tidak dipantau dalam proses.
Karena perpindahan perbatasan, pertanyaan yang relatif sederhana tumbuh menjadi monster bingung yang menghabiskan banyak waktu! Dan dalam banyak kasus ini dimulai ketika produk sudah dalam pengembangan.
Ambil contoh fungsi sederhana:
- Versi pertama (sebelum implementasi): fungsi didefinisikan sebagai "Tampilkan peta lokasi"
- Versi kedua (ketika iterasi pertama hampir selesai): deskripsi berubah menjadi "Tampilkan peta lokasi 3D"
- Versi ketiga (ketika iterasi kedua hampir selesai): uraiannya berubah menjadi "Tampilkan peta lokasi 3D tempat pengguna dapat bergerak"
8) Proses Penentuan Fitur Produk
Sekilas mungkin tampak tidak bisa dipahami, tetapi kenyataannya, semuanya sederhana. Jika orang yang bertanggung jawab atas produk memprioritaskan tanpa menguji hipotesis mereka (melalui umpan balik atau dengan cara lain) tentang minat audiens terhadap peluang tertentu, dan pengembang melihat bahwa peluang ini sama sekali tidak digunakan, maka mereka akan merasa bahwa pekerjaan mereka tidak masuk akal, dan motivasi akan runtuh. Kita semua ingin merasa bahwa kita meninggalkan tanda di dunia, dan ini sangat penting bagi pengembang!
9) Mengabaikan hutang teknis
Tugas teknis adalah keputusan sadar untuk memungkinkan peregangan tertentu dalam memilih solusi dan menulis kode untuk meluncurkan produk lebih cepat. Sejumlah hutang teknis muncul dalam proyek apa pun yang tak terhindarkan dan dapat membantu tenggat waktu untuk jarak pendek. Namun, dalam jangka panjang, itu meningkatkan kompleksitas sistem dan dengan demikian memperlambat pengembang. Orang-orang yang jauh dari pemrograman seringkali meremehkan dampak dari proses-proses ini pada produktivitas dan membutuhkan bergerak maju tanpa henti - dalam situasi ini masalah mulai muncul. Jika refactoring selalu tetap di luar daftar prioritas, tidak hanya produktivitas karyawan, tetapi juga kualitas produk akan menderita.
10) Berbagai alat dan peralatan
Pengembang setiap hari menggunakan banyak alat untuk menulis, mendorong dan menggabungkan kode. Semakin mereka mengatur proses otomatis, semakin baik. Tak perlu dikatakan bahwa alat kuno akan berdampak langsung pada kinerja. Ini juga memutuskan banyak pekerjaan yang sedang dilakukan - pada satu laptop atau juga pada layar tambahan. Jika kita membandingkan harga besi dengan gaji programmer, maka bahkan peningkatan 5% dalam produktivitas pasti akan membayar semua biaya! Anda hanya perlu memberi tim peralatan dan alat yang mereka sukai untuk digunakan (untuk peralatan, solusinya harus individual, untuk alat - kolektif).
11) Dokumentasi cara
Dalam proses pengajaran pemrograman, kita semua belajar bahwa Anda perlu mulai menambahkan komentar ke kode sesegera mungkin dan sesering mungkin. Idenya adalah bahwa akan lebih baik jika ada terlalu banyak komentar daripada tidak cukup. Sayangnya, banyak orang salah paham akan hal ini dan memutuskan bahwa setiap baris membutuhkan penjelasan. Itu sebabnya kami memiliki sampel seperti ini, dari
artikel Jeff Atwood "Kode tanpa komentar":
r = n / 2; // Set r to n divided by 2
// Loop while r — (n/r) is greater than t while ( abs( r — (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}Apakah Anda mengerti apa yang kode ini lakukan secara umum? Jadi saya tidak mengerti apa-apa. Masalahnya adalah banyak yang dikatakan di sini tentang bagaimana semuanya bekerja, tetapi tidak sepatah kata pun tentang mengapa ini diperlukan. Jika kami berasumsi bahwa bug terjadi dalam program dan Anda menemukan fragmen kode di bawah kap, itu tidak akan membantu Anda mengetahui situasinya.
12) Tenggat waktu yang sangat ketat
Poin terakhir terkait dengan kecenderungan manajer untuk meminta pengembang memperkirakan secara kasar berapa banyak waktu yang mereka perlukan, lalu menekan mereka untuk meremehkan perkiraan ini, dan kemudian secara ajaib menyamakan tanggal terakhir dengan tenggat waktu! Pada saat yang sama, manajer bahkan percaya bahwa karena pengembang "menetapkan tenggat waktu sendiri", itu berarti mereka mendaftar untuk tenggat waktu yang sesuai dan itu harus dianggap sebagai opsi yang akhirnya disetujui yang dapat ditransfer ke manajemen senior.
Pengembang percaya bahwa tenggat waktu seperti itu benar-benar gila dan tidak mungkin untuk tetap di dalamnya; Ada perselisihan dalam tim dan tidak ada yang bisa berkonsentrasi.
Tetapi apakah ini hanya tentang pengembang?
Jika Anda melihat semua 12 poin ini, Anda akan melihat bahwa mereka, untuk sebagian besar, relevan untuk semua orang yang terlibat dalam proyek. Hanya saja dalam kasus programmer, mereka sangat kritis, karena pekerjaan mereka membutuhkan perendaman yang mendalam dalam proses.
Jika Anda memperhatikan bahwa beberapa poin yang disebutkan adalah tipikal untuk perusahaan Anda, alangkah baiknya mengikuti daftar ini bersama tim pengembang, membangun dialog dengan mereka, mencari tahu di mana masalah muncul dan cara terbaik untuk menyelesaikannya. Apa pun yang mereka katakan, sangat penting untuk menanggapi umpan balik dan komentar ini dengan serius. Selama tiga puluh tahun terakhir, banyak yang telah berubah dalam hal teknologi, tetapi prinsip dasar kerja tim tetap sama: ketika membahas kinerja, perlu untuk mempertimbangkan faktor manusia. Perbaiki proses kerja, lingkungan, kebiasaan tim Anda, dan beri mereka kesempatan untuk memberi tahu Anda cara mencapai produktivitas maksimum.