Ada 15 orang di studio saya, setengahnya adalah programmer. Studio mengkhususkan diri dalam mengembangkan toko online, sehingga programmer adalah sumber daya utama kami.
Tiga hal selalu dituntut pemrogram
- Lebih cepat menyerahkan proyek.
- Tetap dalam penilaian Anda sendiri tentang biaya tenaga kerja.
- Tumbuh dan berkembang
Tetapi karena berbagai alasan, mereka tidak selalu siap untuk ini. Bagaimana kami memotivasi para programmer untuk meningkat di ketiga bidang, kesulitan apa yang mereka temui dan apa yang terjadi, saya akan ceritakan dalam artikel tersebut.
Bagaimana kita mulai mengirimkan proyek lebih cepat
Kami akan segera membicarakan mengapa ini penting: jika seorang programmer mengajukan proyek lebih cepat, perusahaan menghasilkan lebih banyak uang pada startup dan, pada akhirnya, programmer juga mendapatkan lebih cepat. Karena ia dengan cepat melanjutkan ke proyek berikutnya, dan yang sebelumnya pergi ke dukungan dan promosi. Tampaknya semuanya jelas, namun kami melihat bahwa programmer tidak menyelesaikan tugas dan menyelesaikan proyek secepat mungkin, dan memutuskan untuk membantu mereka mempercepat
Bagaimana termotivasi
Tahap pertama
Opsi pertama adalah membuat gaji programmer setengah dari gaji dan setengah dari bonus untuk proyek. Akibatnya, perusahaan dan pengembang akan "di kapal yang sama", dan keberhasilan yang satu akan langsung mempengaruhi keberhasilan yang kedua. Tampaknya semuanya logis, tetap hanya untuk mempercepat.
Apa yang dibutuhkan untuk menyelesaikan proyek lebih cepat?
Jelas, Anda perlu memprogram lebih cepat. Bagaimana cara melakukannya? Kurang gangguan dan semuanya baik untuk dilakukan segera, sehingga Anda tidak perlu mengulanginya.
Tetapi di sini kita menemukan masalah lain: programmer tidak selalu teralihkan oleh kesalahan atau keinginan mereka sendiri. Sebagai contoh, seorang manajer dapat mentransfer seorang programmer untuk memecahkan masalah dalam mendukung proyek sebelumnya.
Selain itu, antara pengembangan dan pengiriman proyek ada proses integrasi yang panjang dan bermasalah. Jadi programmer menerima bonus untuk pengembangan proyek yang belum disampaikan. Ini sepertinya tidak terlalu logis, jadi kami terus mencari opsi.
Tahap kedua
Keputusan kedua adalah membayar bonus pada saat penyerahan proyek, dan bukan setelah penyelesaian proyek.
Sekarang, programmer menjadi lebih buruk: tidak hanya tugas-tugas terkait yang mempengaruhi bonus penerimaan mereka, tetapi, misalnya, kecepatan menyediakan akses pelanggan untuk diintegrasikan dengan pembayaran dan pengiriman (dan kadang-kadang beberapa bulan), dan kecepatan spesialis 1C-nya (untuk integrasi dengan 1C )
Juga, pada tahap pemrograman, semua kesalahan dari langkah-langkah sebelumnya terungkap: perencanaan, perancangan, desain. Dan programmer harus benar-benar mengoreksi mereka untuk gaji kosong (dan dia sangat kecil dalam kerangka sistem ini).
Ternyata programmer tetap tanpa bonus (dan mereka signifikan) bukan karena kesalahan mereka sendiri.
Penjajaran ini tidak dapat diterima dan percobaan dengan bonus untuk proyek harus dikurangi.
Di sini, saatnya meminta maaf kepada tim pengembangan untuk eksperimen semacam itu. Saya masih kagum bagaimana mereka semua tidak melarikan diri saat itu.
Hasil percobaan adalah pemahaman bahwa programmer cukup termotivasi untuk melakukan tugas dengan cepat dan baik, jika mereka tidak ikut campur. Dan mereka tidak membutuhkan insentif tambahan.
Jadi, apakah motivasi material diperlukan dalam kasus ini?
Saya membutuhkannya Bonus kecil setelah selesainya proyek memotivasi programmer untuk tidak "bekerja lebih baik" (untuk ini, dalam pengalaman kami, ia tidak membutuhkan insentif), tetapi untuk mempelajari bidang terkait. Sebagai contoh, seorang programmer, bersama dengan manajer proyek, mempelajari tata letak desain sebelum menunjukkannya kepada klien, mencari ketidakkonsistenan dan area masalah di dalamnya. Akibatnya, proyek lebih mudah diprogram dan dikirim ke pelanggan.
Rasio gaji dan bonus pada saat yang sama di level 80/20%.
Kami memotivasi agar sesuai dengan penilaian biaya tenaga kerja Anda
Jika tidak mungkin untuk mengirimkan proyek lebih cepat karena motivasi material dari pengembang, maka mungkin layak memotivasi programmer untuk masuk ke dalam perkiraan tenggat waktu untuk tugas mereka sendiri?
Apa yang kita bicarakan: berdasarkan perkiraan kerumitan tugas, direncanakan bagi pemrogram untuk bekerja - tugas ditetapkan untuk perspektif jangka pendek (minggu) dan jangka panjang (1-2 bulan). Dengan demikian, jika programmer tidak memenuhi tenggat waktu, maka seluruh jadwal pekerjaan akan jatuh, tenggat waktu akan bergerak pada proyek yang bergantung padanya, dan seterusnya.
Bagaimana membantu programmer tetap dalam kerangka waktu yang direncanakan?
Dimungkinkan untuk memberi penghargaan jika Anda telah memenuhi sasaran. Anda bisa dicabut, jika tidak bertemu.
Namun, keputusan pertama dan kedua menunjukkan bahwa intinya di sini semata-mata dalam motivasi, dan bukan karena alasan eksternal. Kami sudah menemukan bahwa programmer, jika tidak terganggu, bekerja sebaik mungkin.
Kami mulai melakukan retrospektif untuk mencari tahu mengapa tugas tertentu memakan waktu lebih lama dari yang direncanakan untuk menemukan "kemacetan" baik dalam tugas itu sendiri, atau dalam konteks pelaksanaannya, atau dalam pengetahuan programmer.
Ini membantu, tugas-tugas mulai dilakukan lebih sering dalam waktu yang ditentukan. Menjadi jelas bahwa Anda perlu mencari tahu tentang tugas yang berlarut-larut sebelum mereka keluar dari tenggat waktu.
Untuk ini, kami datang dengan "retrospektif awal." Ketika lebih dari separuh waktu yang diberikan untuk tugas telah berlalu, dan tugas itu masih belum mendekati setengahnya, programmer memberi tahu manajer tentang hal ini, dan bersama-sama mereka mencari alasan.
Jadi, karena apa Anda tidak dapat memenuhi tenggat waktu untuk tugas tersebut
Tugas itu awalnya dievaluasi secara salah.
Entah kompleksitas dinilai secara salah, atau solusi yang dipilih selama evaluasi tidak cocok pada akhirnya. Ini berarti bahwa programmer memiliki kesenjangan pengetahuan di bidang tertentu. Penting! Informasi ini digunakan untuk pelatihan, bukan untuk menghukum programmer.
Tugas ini telah ditumbuhi dengan detail di sepanjang jalan.
Jika detail datang dari pelanggan dan pada awalnya tidak jelas, maka programmer memperbaiki penilaian, dan manajer menjual jam yang hilang dan menggeser tenggat waktu.
Jika detailnya jelas, tetapi manajer melewatkannya
Itu sudah berbicara tentang kesenjangan dalam pengetahuan manajer. Kami memahami bahwa manajer harus belajar sehingga masalah serupa tidak lagi muncul.
Tetapi apakah Anda membutuhkan motivasi finansial di sini
Saya membutuhkannya Kami mempertimbangkan hadiah untuk jumlah jam yang terjual kepada pelanggan dan dikerjakan oleh programmer. Tujuannya tetap sama: termotivasi untuk memberikan penilaian yang akurat, programmer menggali lebih dalam tugas, kadang-kadang mengarahkannya untuk menjelaskan, kadang-kadang menawarkan versinya sendiri.
Pelatihan programmer dan motivasi untuk pengembangan
Pada tahap retrospektif, kami menemukan celah dalam pengetahuan programmer, tetapi bagaimana membuat mereka belajar dan menutup kesenjangan ini?
Kami berlokasi di Krasnodar, dan di sini secara umum ada satu studio e-niaga (sebenarnya, kami). Ini berarti bahwa tidak ada tempat untuk mengambil personil yang siap pakai. Dan setiap orang perlu tumbuh dari awal, atau "tumbuh" dari level yang mereka miliki di studio lain.
Apa yang harus diketahui oleh seorang programmer
- Frontend
- Backend
- Mesin
- Integrasi (1C dan seterusnya)
- Linux, Nginx, Apache
Dengan demikian, kami memiliki 5 bidang kompetensi. Masing-masing dari mereka memiliki seperangkat keterampilan tertentu dari mana peta kompetensi programmer terbentuk. Ini menentukan pembagian pengembang ke dalam level (Trainee, Junior, Middle, Senior).
Saat level naik, gaji meningkat.
Bagaimana kami meningkatkan pengembang
Hipotesis 1
Gagasan pertama adalah untuk memberikan pengembang peta kompetensi dan materi metodologis dan menawarkan diri untuk dikembangkan di atasnya.
Di Bitrix24, kami memulai tugas otomatis di mana setiap orang harus melaporkan kemajuan dalam pelatihan.
Dan kemudian saya mengalami masalah pertama. Untuk beberapa alasan, programmer tidak mau belajar dan tidak ingin tumbuh di peta kompetensi.
Setelah beberapa bulan upaya yang sia-sia, saya kira bertanya kepada mereka: apa yang salah?
Ternyata ada terlalu banyak perbedaan kompetensi antara level yang berbeda. Dan dia tidak termotivasi untuk belajar.
Hipotesis 2
Kemudian saya memutuskan untuk memecah level menjadi beberapa level (sebagai persentase dari peta kompetensi yang dipelajari). Dan untuk setiap level memberi sedikit kenaikan gaji.
Itu menjadi sedikit lebih baik. Programmer menjangkau untuk belajar dan mengambil ujian. Tapi masih terlalu lambat.
Masalah berikut menjadi jelas: tidak ada waktu atau energi untuk mempelajari materi di rumah, dan di tempat kerja, programmer sibuk dengan tugas. Jadi mereka yang memiliki pendidikan mandiri setengah hari maju pada peta kompetensi, dan mereka yang tidak tetap pada tingkat yang sama, yang dengan dingin menurunkan motivasi mereka.
Hipotesis 3
Berikan waktu luang. Di sela-sela tugas, programmer mulai meninggalkan beberapa jam seminggu untuk pelatihan.
Dan itu berhasil. Programmer mulai terlibat dalam pengembangan diri, mengikuti tes dan tumbuh dalam gaji.
Mereka yang tidak siap untuk belajar, tunduk pada waktu yang ditentukan dan prospek pertumbuhan, harus dibiarkan begitu saja. Ada orang yang nyaman pada level mereka dan jika mereka dapat menutup beberapa tugas, lalu mengapa tidak?
Kesimpulan
Dalam pengalaman kami, programmer memiliki motivasi internal yang cukup, dan jika mereka tidak terganggu, mereka bekerja sebaik mungkin.
Penghargaan berfungsi sebagai motivator tambahan tidak terlalu untuk kualitas pekerjaan tetapi untuk perendaman dalam pekerjaan spesialis terkait (mencari bidang masalah dalam desain dan TK sebelum akhirnya disepakati).
Semua alat belajar tidak ada artinya kecuali ada dua hal penting. Perasaan kemajuan (termasuk imbalan yang bisa dicapai) dan waktu yang diberikan untuk ini. Percayalah, ketika seorang programmer, setelah hampir tidak berhasil menutup tugas dalam sehari, tiba di rumahnya dari jam kerja, setelah itu ia benar-benar tidak memenuhi "rencana pengembangan" Anda. Dan saya berpikir bahwa "Anda akan belajar sekarang dan Anda akan memiliki waktu luang" hanya akan menimbulkan satu reaksi diam: "Saya tidak percaya".