12 Perkara Yang Memusnahkan Produktiviti Pembangun Perisian aka Programmer

kami melihat banyak pasukan yang mengalami kerugian produktiviti yang besar dalam beberapa cara yang negatif 

.

Banyak artikel menangani peranan petunjuk teknologi dan pengurus kejuruteraan. Satu tema biasa yang sering kita temui ialah bagaimana meningkatkan produktiviti pasukan . Tetapi sebelum anda menumpukan tenaga anda untuk meningkatkan produktiviti mereka, anda mungkin perlu mempertimbangkan apa yang memusnahkannya, untuk mempunyai asas bunyi yang boleh anda bina. Malangnya, walaupun Peopleware telah diterbitkan hampir 30 tahun yang lalu, kami melihat banyak pasukan yang mengalami kerugian produktiviti yang besar dalam beberapa cara yang negatif (negatif)!

Tiada siapa yang mengharapkan seorang pengaturcara untuk mendapatkan kerja yang dilakukan tanpa akses kepada komputer, tetapi terdapat banyak syarikat yang mengharapkan pengaturcara untuk mendapatkan kerja yang dilakukan tanpa akses kepada fikiran mereka. Ini sama sekali tidak realistik.

Jadi marilah kita menyelam dalam senarai 12 perkara yang menghalang pemaju anda daripada masuk "ke zon" dan menjadi produktif. Saya akan cuba untuk mengutamakan senarai ini dari yang paling kurang kepada yang kurang berkesan. Jangan ragu untuk komen!

Jika anda tertanya-tanya sama ada semua ini bernilai pelaburan, hanya pertimbangkan gaji pemaju. Malah produktiviti 10% lebih banyak!

1) Gangguan & Mesyuarat

Gangguan adalah pembunuh produktiviti utama untuk pemaju, dalam fikiran saya. Pemaju tidak boleh dengan mudah kembali ke tempat yang betul sebelum gangguan. Mereka perlu masuk ke dalam pemikiran untuk pembangunan dan kemudian perlahan-lahan mengesan kembali ke mana mereka berhenti. Ini boleh mengambil masa lebih daripada 30 minit.Dan lebih banyak gangguan, lebih banyak kekecewaan, kerja yang kurang berkualiti, semakin banyak pepijat - dan ia berterusan.

"Semakin banyak kali anda mengarahkan saya semasa saya cuba memulakan - semakin lama setiap kali saya cuba. Jika anda mengisi pagi saya dengan gangguan - jangan terkejut apabila hari itu tidak produktif. "-A pemaju di Reddit

Bagaimana dengan mesyuarat? Satu-satunya perbezaan antara mesyuarat dan gangguan adalah bahawa mesyuarat adalah gangguan yang dirancang, yang menjadikannya lebih buruk lagi. Pemaju tidak boleh maju ke atas tugas jika mereka tahu bahawa mereka akan mengalami gangguan ketika mengerjakannya. Jadi jika mereka mengadakan pertemuan dalam satu atau dua jam, mereka tidak akan dapat maju apa-apa, kerana kebanyakan tugas kejuruteraan memerlukan lebih banyak masa.

Seperti yang ditulis Paul Graham , "Satu pertemuan tunggal boleh meniup seluruh petang dengan memecahnya menjadi dua keping, masing-masing terlalu kecil untuk melakukan apa-apa yang sukar."

Bagaimanakah ini boleh dielakkan? Bahagian ini didokumenkan dengan baik; anda tidak mempunyai alasan.Mengadakan mesyuarat status pendek pada awal hari atau sebelum makan tengah hari, sebagai contoh, untuk mengelakkan gangguan yang tidak perlu.

2) Pengurusan mikro

Daripada jenis pengurus yang berbeza, pengurus mikro mungkin paling buruk dari segi produktiviti pemaju. Pasti, pengurus mikro cenderung mempunyai lebih banyak mesyuarat dan gangguan yang tidak dirancang. Tetapi itu bukan hanya itu. Mereka menunjukkan kekurangan kepercayaan, dan dengan berbuat demikian, anda merasakan mereka sentiasa melemahkan kemahiran anda dan keupayaan anda untuk menyelesaikan sesuatu. Mana-mana motivasi pemaju yang ada antara gangguan akan pergi pada ketika itu.Kesannya melampaui produktiviti. Pengurus mikro mungkin menjadi alasan pertama untuk pemaju meninggalkan, atau sekurang-kurangnya, untuk menukar pasukan.

3) Ketiadaan

Terdapat banyak cara untuk menggambarkan kekaburan.Laporan bug seperti "Ia rosak, memperbaikinya!" Tidak mempunyai maklumat yang mencukupi untuk pemaju berfungsi. Dengan cara ini, mempunyai template laporan pepijat boleh membantu dalam kes itu.

Atau spesifikasi yang tidak jelas mengenai ciri, di mana pemaju akan mula melaksanakan apa yang dirasakan tepat kepada mereka sebelum mereka perlu bermula semula dari awal sekali apabila pengurus lebih terperinci mengenai perilaku yang diharapkan.

Keutamaan yang tidak jelas juga tergolong dalam kategori ini.Masa yang dibelanjakan seorang pembangun yang tertanya-tanya jika mereka bekerja pada tugas yang betul boleh dengan mudah dielakkan. Dan sekiranya mereka mendapat komen dari pengurus yang bertanya mengapa mereka bekerja pada tugas tertentu (sementara keutamaan tidak ditakrifkan) ... baik, anda mendapatkannya - banyak kekecewaan ...

4) Pengurusan Seagull

Pernahkah anda mendengarnya? Ia berlaku apabila pengurus benar-benar tidak terlibat dalam kerja, tetapi ... mereka hanya menyerang sekali seketika untuk mengelak segala-galanya."Ini salah, dan ini, dan ini kelihatan buruk," dan sebagainya, sebelum terbang lagi. Saya perlu mengakui saya suka imej, tetapi malangnya, ini berlaku lebih kerap daripada yang kami mahukan. Tingkah laku ini sangat mengecewakan kepada pemaju; mereka tidak dapat kembali ke zon dalam beberapa jam ke depan, dan kadang-kadang tidak selama beberapa hari.

5) Kredit Kerakitan

Pernahkah anda mempunyai pengurus atau pemaju lain yang mengambil semua kredit untuk kerja yang telah anda lakukan dalam beberapa minggu yang lalu? Pemaju nilai kecekapan di atas semua. Mengambil kredit untuk orang lain mengambil kecekapan yang lain untuk diri sendiri dan membuangnya dari dia. Ini cukup tinggi dalam senarai saya, kerana saya rasa ia mencetuskan ketegangan sehingga ia hanya memusnahkan produktiviti keseluruhan pemaju untuk seketika.

6) Persekitaran - Bunyi, Gerak, Rangka Kerja Ruang Kerja ...

Ini mungkin kelihatan aneh untuk bukan pengaturcara, tetapi persekitaran di mana pemaju bekerja mempunyai kesan penting terhadap aktiviti mereka. Sebagai contoh, mempunyai bunyi bising putih - AC kuat, kereta dan trak pendengaran digulung - membantu mereka memberi tumpuan lebih baik.Itulah sebabnya banyak daripada kita meletakkan alat dengar!Saya sebenarnya telah menemui RainyMood - sangat hebat!

Begitu juga, jika ruang kerja direka untuk mempunyai gerakan sebanyak mungkin, itu tidak akan menolong mereka fokus!Atau mempunyai skrin komputer desktop berorientasikan sedemikian rupa sehingga mereka dapat dilihat oleh para pengurus ... dengan baik, yang menimbulkan beberapa tekanan tambahan dan lebih banyak kesempatan untuk terganggu.

7) Skop Penyerapan

Skop rayapan (juga dikenali sebagai rayap fokus, merayap keperluan, merayap ciri, dan kadang-kadang sindrom sink dapur) dalam pengurusan projek merujuk kepada perubahan yang tidak terkawal dalam skop projek. Ini boleh berlaku apabila skop projek tidak ditakrifkan, didokumenkan, atau dikawal dengan betul.

Skop rayapan bertukar permintaan yang agak sederhana ke dalam raksasa yang sangat kompleks dan memakan masa!Dan kebanyakan masa ia berlaku semasa pembangunan!Sebagai contoh, untuk ciri mudah: 

• Versi 1 (sebelum pelaksanaan): ciri ini ialah "Papar peta lokasi" 
• Versi 2 (apabila versi 1 hampir selesai): ciri ditukar kepada "Tunjukkan peta 3D lokasi" 
• Versi 3 (apabila versi 2 hampir selesai): ciri ini sekali lagi ditukar kepada "Tunjukkan peta 3D lokasi yang pengguna boleh terbang melalui"

8) Proses Definisi Produk

Jadi ini mungkin kelihatan aneh pada pandangan pertama tetapi sebenarnya agak mudah dimengerti. Jika pasukan produk menentukan keutamaan pasukannya tanpa mengesahkan (melalui maklum balas pelanggan atau apa-apa cara lain) kepentingan ciri-ciri yang sepadan, dan pemaju melihat bahawa kebanyakan ciri akhirnya tidak digunakan, mereka akan merasakan bahawa apa yang mereka lakukan adalah sia-sia dan akan kehilangan motivasi mereka. Kita semua mahu merasa berdampak, dan itu mungkin lebih penting kepada pemaju!

9) Kurangnya Pertimbangan Hutang Teknikal

Hutang teknikal adalah keputusan yang disengajakan untuk melaksanakan penyelesaian bukan terbaik atau menulis kod yang paling tidak tepat untuk melepaskan perisian dengan lebih cepat. Mengambil beberapa hutang teknikal tidak dapat dielakkan dan boleh meningkatkan kelajuan dalam pembangunan perisian dalam jangka pendek. Walau bagaimanapun, dalam jangka panjang, ia menyumbang kepada kerumitan sistem, yang melambatkan pemaju ke bawah. Bukan programmer sering meremehkan kehilangan produktiviti dan tergoda untuk sentiasa bergerak ke hadapan, dan itu menjadi isu. 
Tetapi jika refactoring tidak pernah menjadi sebahagian daripada keutamaan, ia bukan sahaja akan memberi kesan kepada produktiviti tetapi juga kualiti produk.

10) Alat Multiplicity & Hardware

Pemaju menggunakan banyak alat untuk program, menolak dan menggabungkan kod mereka setiap hari. Semakin banyak automasi, semakin baik. Ia tidak mengatakan bahawa jika anda menggunakan alat "kuno", ini akan memberi kesan kepada produktiviti anda. Begitu juga, mempunyai skrin besar vs hanya komputer riba yang boleh memberi impak.Memandangkan kos perkakasan dan gaji pemaju, hanya memperoleh keuntungan produktiviti sebanyak 5% pasti bernilai apa-apa pelaburan pada ketika itu! Hanya beri alat dan perkakasan yang dikehendaki oleh pasukan pembangun anda (secara individu untuk perkakasan, tetapi sebagai kumpulan untuk alat).

11) "Bagaimana" Dokumentasi

Apabila belajar bagaimana untuk kod, kami diberitahu untuk memberi komen awal dan sering. Idea ini adalah lebih baik untuk mempunyai terlalu banyak komen daripada terlalu sedikit. Malangnya, banyak pengaturcara tidak betul mentafsirkan ini bermakna mereka mesti memberi komen setiap baris kod, sebab itulah kami sering melihat kod seperti ini (dari jawatan Jeff Atwood pada "Coding Without Comments" ):

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)} 

Adakah anda mempunyai idea apa kod ini? Saya tidak.Masalahnya adalah bahawa walaupun terdapat banyak komen menggambarkan apa yang dilakukan oleh kod, tidak ada yang menggambarkan mengapa ia melakukannya. Sekiranya terdapat bug dalam program ini dan anda tersandung kod ini, anda tidak akan tahu di mana hendak bermula.

12) Deadlines yang Ketat

Yang terakhir ini dikaitkan dengan kecenderungan para pengurus untuk meminta pemaju untuk membuat anggaran, kemudian tolak mereka untuk menurunkan anggaran tersebut sebanyak mungkin, dan kemudian secara ajaib menganggapnya sebagai tarikh akhir! Pengurus akan menganggapnya, kerana pemaju sendiri "membuat keputusan" atas anggaran, mereka komited kepada tarikh akhir, dan oleh itu, tarikh akhir harus dianggap cukup sah untuk dikongsi dengan pengurusan atasan.

Tidak menghairankan, pemaju merasakan bahawa tarikh akhir tersebut tidak munasabah dan sewenang-wenangnya ketat; ini mewujudkan ketegangan dan ketidakupayaan untuk memberi tumpuan.

Bagaimana semua perkara yang unik kepada pemaju? Jika anda melihat semua 12 perkara, mereka sebenarnya cukup biasa untuk kebanyakan pekerjaan berasaskan projek lain.Hanya impak setiap ini adalah lebih penting bagi pemaju, kerana mereka memerlukan fokus yang mendalam untuk maju ke atas tugas mereka.

Jika anda mengenali beberapa perkara yang disebutkan di atas dalam syarikat anda, mungkin menarik untuk mengatasinya dengan pemaju anda. Bercakap dengan mereka;mengetahui sama ada ini adalah isu dan bagaimana ia dapat diselesaikan. Apa sahaja yang mereka katakan, perkara yang paling penting ialah mempercayai maklum balas dan pandangan mereka. Dan sementara teknologi hari ini sangat berbeza dari 30 tahun yang lalu, pelajaran masih sama. Anda tidak boleh mengabaikan faktor manusia apabila anda mempertimbangkan produktiviti pasukan. Terangkan proses, persekitaran dan tabiat kerja anda dengan pasukan anda, dan biarkan mereka membimbing anda tentang bagaimana produktiviti dan impak yang tinggi.

.
Diterjemah dari sumber asal: https://dzone.com/articles/top-12-things-that-destroy-developer-productivity?edition=407250
.