Memotivasi pengembang dalam proyek yang dianggap membosankan?

Sebagai seorang manajer, saya tidak selalu bisa menghasilkan pekerjaan yang canggih. Beberapa proyek berjalan pada mode pemeliharaan, dan menghasilkan arus kas bebas sehat untuk perusahaan.

Sebagai pengembang, apa yang diperlukan untuk bertahan di proyek ini? Saya telah berpikir untuk merek-ulang pekerjaan, tetapi saya bisa lakukan dengan banyak bantuan di sini.

EDIT: Terima kasih atas sarannya. Sejauh ini yang kami punya:

1. Rotasi pekerjaan sesuai minat pengembang
2. Lingkungan kerja yang fleksibel
3. Luangkan waktu untuk mengerjakan proyek hewan peliharaan
4. Acara sosial dan menyenangkan
5. Branding proyek
6. Gunakan ini sebagai batu loncatan untuk proyek lain

Untuk proyek dalam mode pemeliharaan, pikirkan apa yang terjadi selanjutnya. Apa yang akhirnya akan membuat mereka tidak menarik bagi pelanggan Anda? Untuk menghindari keusangan, apakah mereka memerlukan fitur baru, kinerja yang lebih baik, atau disederhanakan? Jika Anda memulai dari awal, dapatkah beberapa proyek digabungkan? Haruskah mereka dibangun dengan alat, bahasa, atau proses yang berbeda? Apakah ada perbaikan atau arahan yang tidak dipertimbangkan? Mintalah pengembang Anda menjawab beberapa pertanyaan ini. Buat prototipe. Coba bahasa atau kerangka kerja baru. Berikan proyek antarmuka seluler baru.

Lebih mudah untuk bereksperimen dengan alternatif ketika tidak ada tenggat waktu yang menjulang. Gunakan waktu yang membosankan untuk mengalahkan manuver pesaing Anda.

Anda perlu menawarkan mereka sesuatu untuk mengisi waktu mereka. Proyek dalam mode pemeliharaan seringkali tidak memerlukan 40 jam seminggu dari setiap pengembang. Jika ya maka mungkin ada sesuatu yang salah dengan perangkat lunak, tetapi berdasarkan cara Anda mengajukan pertanyaan, saya berasumsi bahwa Anda sedang mencari ide untuk menduduki pengembang Anda sementara tidak banyak yang harus dilakukan. Saya tidak tahu apa anggaran keuangan Anda, tetapi saya pikir beberapa insentif seperti mengirimkannya ke konferensi perangkat lunak mungkin membantu. Saran lain mungkin termasuk secara eksplisit memungkinkan mereka untuk mengeksplorasi minat mereka sendiri untuk mengatakan 15 jam seminggu. Seseorang mungkin tertarik untuk mengeksplorasi katakan algoritma sorting atau desain database. Mungkin tidak terkait langsung dengan bisnis Anda, tetapi saya tidak dapat membayangkan bahwa Anda tidak akan mendapat manfaat dari peningkatan pengetahuan mereka pada akhirnya. Hanya saja, jangan memaksa mereka untuk bekerja tanpa ada hubungannya. Biarkan mereka mengisi waktu mereka dengan sesuatu yang lain jika tidak ada banyak pekerjaan yang harus dilakukan. Saya pikir wajar untuk meminta ringkasan tentang apa yang mereka lakukan untuk memastikan mereka tidak hanya menjelajahi web secara acak, tetapi membiarkan mereka menjelajah sedikit.

Jadikan itu menyenangkan untuk mengerjakan proyek.

Sebenarnya proyek yang menarik cukup langka. Dan penelitian menunjukkan bahwa kebahagiaan karyawan sangat bergantung pada sosial dan kesenangan. Mereka secara besar-besaran menyebut kolega ketika ditanya mengapa mereka tidak meninggalkan pekerjaan mereka saat ini.

Itu sebabnya Anda harus selalu bahagia ketika Anda mendengar tawa di gedung Anda alih-alih berteriak.

Bagi saya, motivator terbaik dalam situasi itu adalah tujuan yang sangat jelas, terutama dalam bentuk spesifikasi yang baik. Atau, alih-alih yang terbaik, itu salah satu dari beberapa hal yang tersisa untuk Anda tawarkan. Alasannya adalah bahwa jika pekerjaan itu sendiri tidak menarik, mengetahui bahwa saya akan mengerjakan ulang banyak hal yang membosankan adalah demotivator lebih lanjut. Itu mungkin tergantung pada programmer yang secara jelas mengenali nilai suatu spesifikasi.

Hal lain adalah untuk memperjelas bahwa mungkin membosankan, proyek-proyek yang menghasilkan pendapatan adalah untuk kebaikan semua orang - tidak ada pendapatan, tidak ada pekerjaan dll. Pekerjaan perlu dilakukan, karena jika tidak, Anda tidak akan punya cukup uang untuk menyimpannya di atas kapal. Tunjukkan hal ini secara eksplisit, terkadang orang tidak menyadarinya.

Kemudian, bagi beban. Cobalah untuk mencari cara untuk menjaga batas-batas pekerjaan yang membosankan dan menjengkelkan (tergantung pada jenis pekerjaan, membagi hari kerja, membagi tugas, dll) sehingga tidak ada yang punya perasaan mereka terjebak dengan semua kekacauan sementara yang lain bisa melakukan hal yang menyenangkan.

Kemudian, cobalah untuk menyamakannya dengan hal-hal yang menyenangkan. Dan berbicara dengan pengembang, mereka mungkin punya ide bagus.

Anda harus mengubah persepsi proyek "membosankan". Jika ini menghasilkan pendapatan yang sehat, itu tidak sulit untuk dilakukan.

Seringkali, proyek-proyek ini bagus untuk programmer Anda yang biasa-biasa saja dan senang menjadi biasa-biasa saja. Anda tahu, orang-orang yang tidak bersemangat tentang pemrograman dan yang hanya melihatnya sebagai cara untuk membayar tagihan. Sekarang, pahamilah sesuatu: Saya tidak mengatakan ini karena mereka adalah programmer yang lebih lemah dan Anda ingin membuat hidup mereka sengsara. Saya mengatakan ini karena ini biasanya orang-orang yang tidak berharap pekerjaan mereka menjadi sumber pemenuhan dalam hidup mereka. Dari suaranya, ini seperti tekanan rendah, aliran pendapatan yang stabil. Kemungkinan besar, para pekerja ini lebih dari senang untuk mengambil pekerjaan mudah, tekanan rendah.

Tentu saja, itu tidak berarti Anda bisa memberi mereka tugas-tugas yang membosankan dan melupakannya. Mungkin Anda bisa memberi "pemain A" 80% tugas menyenangkan / 20% tugas Anda membosankan, "pemain B" Anda bisa 50/50, dan "pemain C" Anda bisa 20/80.

Biarkan pengembang Anda mendapatkan waktu yang dibayar untuk mengerjakan proyek peliharaan / sumber terbuka / menarik mereka sendiri dengan melakukan pekerjaan kasar. Tawarkan kepada mereka beberapa dukungan dengan jenis proyek ini, terutama jika pekerjaannya adalah proyek atau program in-house. Itu strategi yang digunakan Google, saya kira?

Saya harus mengakui bahwa saya belum pernah mengerjakan proyek yang membosankan dan tidak menarik, jadi saya tidak yakin bahwa saya memahami pertanyaan Anda. Dan saya mengembangkan sistem perusahaan untuk mencari nafkah. :) Serius, dalam praktiknya saya telah menemukan bahwa programmer terganggu oleh pekerjaan "membosankan" jauh lebih sedikit daripada yang saya harapkan. Pekerjaan tidak berguna, seperti mengisi lembar waktu yang tidak pernah diperiksa siapa pun adalah masalah yang jauh lebih besar. Yang telah dibilang:

Ketahui preferensi programmer Anda; beberapa programmer tidak suka GUI, beberapa menjauh dari SQL. Cobalah untuk menghargai preferensi itu, karena tugas yang membosankan untuk satu programmer mungkin menyenangkan untuk yang lain. Jika tidak mungkin membagi pekerjaan sedemikian rupa karena alasan apa pun, buat itu menarik dengan meningkatkan persaingan - biarkan mereka bersaing siapa yang akan menjadi yang pertama untuk menyelesaikan bagiannya, atau membuat papan skor yang bagian kodenya memiliki jumlah paling sedikit bug di QA. Microsoft dikenal karena budaya perusahaan mereka yang membuat programmer bersaing pada pendekatan yang berbeda, dan memilih yang terbaik pada akhirnya atau menggabungkan bagian terbaik dari setiap pendekatan dalam produk akhir.

Memiliki bagian dari produk dan mengendalikannya juga secara drastis meningkatkan keterlibatan seseorang. Sebaliknya, tidak ada yang lebih membosankan daripada meminta seseorang mengatur pekerjaan Anda secara mikro. Juga, jika ada tugas berulang yang dibenci semua orang, menjelaskan gambaran yang lebih besar - bahwa itu adalah sesuatu yang harus dilakukan dan mengapa dan memutar orang yang melakukannya setiap minggu biasanya lebih dari cukup.

Saya telah / melihat sukses dengan menggunakan proyek semacam ini sebagai jalan menuju yang lebih menarik.

Jika pengembang baru dan menengah Anda semua mulai dalam proyek "membosankan", mengajukan pertanyaan dari pengembang senior (yang sebagian besar berada di proyek lain) dan Anda menjelaskan bahwa semakin baik Anda melakukannya di area pemeliharaan semakin banyak kemungkinan Anda akan mendapatkan keterlibatan di masa depan dalam pekerjaan baru, kemudian dengan asumsi Anda memiliki tim yang layak dan benar-benar menindaklanjuti dengan perubahan tim sesekali dan menarik para pengembang utama sesekali pada pekerjaan baru yang akan disejajarkan oleh tim sendiri.

Jika Anda memiliki tim yang buruk, atau tim yang sangat bagus, pendekatan ini mungkin tidak cocok untuk Anda.