Mengejar yang terbaik

Saya tidak tahu tentang Anda, tetapi saya suka bereksperimen dengan orang-orang. Biasanya saya tidak meminta pendapat orang, tetapi kali ini percobaan dilakukan atas permintaan mereka sendiri. Orang-orang ingin saya memberi mereka sistem motivasi baru. Ya saya lakukan.

Artikel ini agak panjang, karena Saya mencoba menjelaskan tidak hanya input dan output, tetapi juga proses pengembangan sistem, pertanyaan yang muncul di sepanjang jalan, dan bagaimana kami menyelesaikannya. Mungkin pengalaman kami akan bermanfaat bagi Anda - jika tidak seluruhnya, maka beberapa bagiannya.

Jadi, di pintu masuk - tim kecil programmer 1C dari tiga orang yang bekerja pada perbaikan. Plus, saya, pemimpin mereka, dengan kompetensi inti, juga seorang programmer 1C.

Proses bisnis adalah yang paling umum:

1. Programmer ditugaskan tugas dari departemen mana pun;
2. Tugas dapat disetujui, jika diperlukan. Daftar koordinator berbeda untuk tugas yang berbeda;
3. Tugas memiliki tenggat waktu, ada kemungkinan transfernya (tidak lebih dari dua kali). Sebelum dimulainya tenggat waktu, kedua belah pihak harus menyetujui
4. Ada proyek otomatisasi yang dilaksanakan berdasarkan kaskade. Tugas-tugas dalam proyek ini memiliki kehidupan yang sama dengan yang lain - ada tenggat waktu, ada persetujuan, dll.
5. Ada dukungan teknis dalam bentuk tugas - programer bergiliran duduk di atasnya selama 1 minggu.

Sistem motivasi :
1. Pemrogram memiliki gaji, tergantung pada kualifikasi;
2. Ada demotivasi untuk tugas-tugas yang tidak selesai tepat waktu;
3. Ada bonus untuk implementasi proyek.

Otomatisasi semua hal ini adalah yang paling umum. Untuk menetapkan tujuan, sistem perusahaan umum digunakan, seperti 1C: Manajemen Dokumen. Ini memiliki instruksi dan memo di mana tugas hidup. Ada otomatisasi kecil manajemen proyek cascading. Ada penghitungan demotivasi otomatis jika terjadi pelanggaran tenggat waktu.

Tampaknya - hidup dan bersukacita, bekerja - jangan memukul telentang. Tidak sulit untuk memenuhi tenggat waktu jika Anda berpartisipasi dalam produksi mereka. Bekerja - tanpa banyak kesulitan, tidak ada yang supranatural. Saya, sebagai pemimpin, tidak menonjol di antara yang lain - dalam layanan lain, tugas, jadwal dan proyek dikelola sesuai dengan prinsip yang sama.

Tetapi satu pertanyaan menghantui kami - bagaimana cara mendapatkan lebih banyak uang?

Dalam sistem saat ini ada dua tuas - untuk mencapai peningkatan gaji atau penghargaan proyek . Perusahaan biasanya tidak suka menaikkan gaji programmer 1C, karena mereka hampir tidak mengerti mengapa orang ini perlu membayar lebih banyak uang .

Untuk pelatihan lanjutan, atau semacam kategorisasi, seperti nilai? Tidak terlalu jelas mengapa Anda harus membayar lebih untuk ini jika kualifikasi tidak memengaruhi hasil. Dan jika hasilnya berbeda untuk programmer, apakah ini terkait dengan kualifikasi formal? Berapa kenaikan gaji, kalau masih begini? Gaji saat ini kira-kira sama dengan rata-rata pasar.

Beberapa kali untuk meningkatkan gaji para programmer masih berhasil. Misalnya, seseorang diusir melalui sertifikasi oleh pasukan franchis yang terlibat. Mereka meningkatkan yang lain, karena dia baik di pasar, dia lebih berharga (penilaian subyektif). Tetapi jalan ini tidak dapat sering diulang, sehingga tidak mendengar, "Apakah Anda kacau di sana pada akhirnya, atau apa?"

Juga tidak mungkin untuk bekerja keras untuk meningkatkan penghargaan proyek, karena topiknya agak licin. Suka atau tidak suka, penghargaan proyek adalah pembayaran tambahan untuk pekerjaan yang sudah dibayar . Tentu saja, Anda entah bagaimana dapat mengulanginya, misalnya, biaya tambahan untuk tampil lebih cepat dari jadwal, atau untuk berpartisipasi aktif dalam implementasi, atau untuk dengan cepat membawa otomatisasi ke persyaratan pelanggan.

Tetapi cepat atau lambat, pemimpin mulai mengajukan pertanyaan - jika seseorang selalu melakukan proyek lebih cepat dari jadwal, mengapa saya harus membayar ekstra untuk ini? Mungkin batas waktu dihitung secara salah?

Setelah berpikir, kami dan para programmer memutuskan sendiri untuk menciptakan sistem motivasi dan mengubah pekerjaan kami sehingga jelas membawa lebih banyak manfaat bagi perusahaan. Dengan asumsi bahwa untuk keuntungan yang lebih besar kita akan menerima lebih banyak uang.

Adalah hak untuk berbicara dengan perusahaan tentang manfaat bagi perusahaan, yang saya lakukan. Saya berbicara dengan para pemimpin, direktur, pemilik. Pendapat berbeda, tetapi jika Anda mengelompokkan dan mengurutkannya, ide utamanya adalah ini: kami menginginkan apa yang sudah Anda lakukan, hanya lebih cepat . Atau dengan cara lain: kami ingin mendapatkan lebih banyak dalam waktu yang bersamaan.

Jelas, kita berbicara tentang kecepatan pemrograman dan implementasi . Perlu dicatat bahwa pada saat itu kami tidak tahu apa-apa tentang scrum, sebagai metode yang mempercepat pekerjaan programmer.

Bagi saya, sebagai seorang pemimpin, momen ini sangat penting: saya ingin para programmer menjaga hasil mereka . Saya tidak ingin menendang mereka, berdiri di atas jiwa saya, mengontrol proses dan waktu. Saya membutuhkan sistem otonom yang bisa dilakukan tanpa saya, dan tanpa pemimpin sama sekali.

Sistem pembayaran terdekat yang cocok untuk keperluan kami tampaknya merupakan pembayaran per satuan untuk pekerjaan yang dilakukan . Kedengarannya menjanjikan dan mudah dibuktikan: di sini adalah pria, di sini adalah pekerjaan yang dilakukan, di sini adalah penghasilan. Tidak perlu memotivasi - jika seseorang tidak ingin bekerja, dia tidak akan mendapatkan uang, dan ini akan menjadi jelas. Dengan orang seperti itu akan mungkin untuk pergi tanpa penyesalan.

Sebuah pertanyaan kunci muncul - bagaimana cara mengevaluasi pekerjaan dan berapa banyak yang harus dibayar untuk mereka ? Dalam franc, masalah ini diselesaikan lebih sederhana - ada perkiraan kompleksitas dalam jam yang dibayar klien. Programmer, pada kenyataannya, menerima persentase dari tarif per jam. Kami tidak memiliki klien dan hubungan uang, tetapi kami perlu mengevaluasi pekerjaan itu.

Idenya datang dengan cepat, begitu pula implementasinya dan basis bukti. Saya memutuskan untuk mengevaluasi tugas pada jam-jam programmer terbaik .

Jika programmer terbaik menyelesaikan masalah dalam 1 jam, maka biayanya 1 jam. Programmer lain yang menyelesaikan masalah ini dalam 4 jam akan menerima 1 jam bayaran untuk itu.

Untuk mengevaluasi tugas "oleh programmer terbaik", Anda perlu memahami siapa itu. Kami memutuskan dengan cara ini: programmer terbaik memiliki semua pengetahuan yang diperlukan tentang cara mengatasi masalah . Dia tahu bidang metodologis, tahu mekanisme yang diperlukan dari platform, tahu metadata dan "di mana apa yang ada". Secara umum, duduk dan melakukannya, tanpa membuang waktu dengan sia-sia.

Tujuan utama dari penilaian semacam itu adalah untuk meminimalkan hilangnya waktu dengan menjadikannya tidak menguntungkan. Kerugian dalam pekerjaan seorang programmer sangat besar, dan dalam hal kehilangan volume sering melebihi setengah dari waktu kerja.

Saya melakukan penilaian "terbaik" secara pribadi, dan ini mungkin merupakan hambatan dari keseluruhan sistem. Segera jelas bahwa perlu untuk membuat sistem penilaian, jika tidak transparan, kemudian diperiksa secara retrospektif. Oleh karena itu, saya memutuskan untuk membuat klasifikasi pekerjaan penilaian - buku referensi sederhana yang berisi komponen standar untuk memecahkan masalah dan penilaian mereka. Secara berangsur-angsur terisi, kami menyebut evaluasi pekerjaan itu sebagai "hukum kasus" - item yang diuji dalam praktik, dengan waktu tenggang yang diukur, jatuh ke penggolong.

Pengklasifikasi berisi, misalnya, item berikut:

• Pengembangan laporan sederhana, seperti "Penjualan", satu register, pada ACS dalam mode pengguna. Skor - 15 menit;
• Pembuatan daftar akumulasi, dengan rekaman gerakan sederhana sepenuhnya ditentukan oleh konteks dokumen. Skor - 15 menit;
• Pengembangan peran, tanpa RLS, dengan daftar kecil (hingga 10) objek yang diizinkan. Peringkat - 10 menit.

Waktu tunggu termasuk pengembangan dan pengujian oleh pengembang. Jika kesalahan terjadi di database yang berfungsi pada perubahan yang dibuat dalam tugas ini, maka kesalahan diperbaiki oleh pelaksana dengan biaya sendiri.

Setiap tugas yang dilakukan programmer menerima penilaian seperti itu sebelum dieksekusi. Jelas bahwa beberapa tugas mengandung beberapa poin dari pengklasifikasi - misalnya, register, ditambah beberapa detail, ditambah laporan, ditambah tugas otomatis. Waktu dalam kasus ini diringkas.

Sekarang perlu untuk menentukan berapa banyak yang harus dibayar untuk satu jam kerja programmer terbaik . Kami memutuskan pertanyaan ini di dahi. Seorang programmer yang baik rata-rata kemudian menerima 60 ribu rubel di pasar. Kami memutuskan bahwa programmer terbaik harus mendapatkan 100 tr. Jelas bahwa selanjutnya angka ini dapat diubah ke segala arah.

Perhitungan dan pembulatan sederhana memberi kami tingkat per jam dari programmer terbaik: 600 rubel per jam .

Angka itu akan terlihat bagus, karena itu adalah setengah dari tarif waralaba lokal per jam, dan lebih rendah daripada biaya freelancer, yang kemudian meminta 700-900 rubel per jam.

Tetapi hal utama - hanya pekerjaan langsung adalah bagian dari tarif per jam kami. Tidak ada refleksi, pemodelan, analisis keputusan, dll.

Namun, menyadari bahwa percakapan tentang taruhan ini dengan kepemimpinan masih akan berlangsung, kami memutuskan untuk memastikan bahwa kami benar. Untuk melakukan ini, berbicaralah dengan teman dan orang asing, waralaba dan pekerja lepas. Kami memberi orang-orang ini beberapa tugas untuk dievaluasi, dan mengajukan pertanyaan sederhana - berapa banyak yang akan Anda ambil uang untuk pekerjaan seperti itu? Hasilnya dapat diprediksi - para lelaki meminta pekerjaan 2-3 kali lebih banyak daripada kita (dengan memperhitungkan pajak atas gaji). Ini tenang - keledai tertutup.

Sekarang perlu menyeimbangkan sistem dengan jumlah akrual bulanan untuk menghindari kesalahan di kedua arah. Sisi pertama adalah programmer. Anda tidak pernah tahu, tiba-tiba ternyata programmer mendapat 10 tr - dia tidak akan punya apa-apa untuk memberi makan keluarganya. Solusinya sederhana, saya melihatnya ketika saya bekerja di waralaba - untuk menetapkan pembayaran bulanan minimum , kurang dari yang tidak akan diterima oleh programmer. Tanpa berpikir dua kali, mereka memutuskan bahwa ini akan menjadi gaji saat ini.

Sisi kedua adalah perusahaan. Hanya pembayaran minimum tidak menguntungkan, karena itu dapat digunakan untuk menipu sistem. Misalnya, untuk melakukan 20 tugas sebulan sebelum negara “hampir siap”, dapatkan gaji, dan bulan depan buat terobosan, tutup 20 tugas yang belum selesai dan 30 tugas baru, dan dapatkan kesepakatan. Ngomong-ngomong, dalam waralaba itu memang seperti itu, dan semua orang menggunakannya.

Jalan keluar dari situasi ini juga sederhana - "ingat minus . " Dia bekerja pada 40 tr, menerima gaji 60 tr - ok, ingat minus 20 tr Bulan depan kamu harus. Lakukan pekerjaan bulan depan di 80 tr - Anda mendapatkan 60 tr, dan Anda seharusnya tidak.

Pada saat yang sama, untuk berjaga-jaga, kami menetapkan batas pembayaran - 100 tr. Kami sepakat bahwa pekerjaan yang dilakukan melebihi jumlah ini akan dianggap sebagai nilai tambah di bulan berikutnya.

Sekarang saya harus mencari tahu apa yang harus dilakukan dengan proyek. Sebuah proyek, jika disederhanakan, adalah sekumpulan tugas yang terkait satu sama lain dengan beberapa makna atau tujuan. Tetapi perusahaan tertarik tidak hanya pada percepatan implementasi dari masing-masing tugas ini, tetapi juga dalam pelaksanaan secepat mungkin dari seluruh daftar tugas proyek dan memperoleh hasilnya.

Solusinya juga sederhana, dan sekali lagi diintip oleh orang lain - untuk mengakumulasikan dan memberikan bagian dari gaji anak-anak pada akhir proyek . Kami memutuskan bahwa dengan kami itu akan menjadi 20%. Sementara proyek sedang berlangsung, programmer menerima 480 rubel per jam, dan 120 rubel sisanya dari setiap jam di akhir proyek.

Nah, semuanya sepertinya dihitung dan dipikirkan, perlu untuk memulai operasi uji.

Langkah pertama adalah mengubah proses bisnis programmer:
1. Tugas sekarang harus ditetapkan tidak secara pribadi untuk pemain, tetapi untuk saya, pemimpin;
2. Saya sekarang harus mengevaluasi setiap tugas dalam hitungan jam;
3. Setelah penerimaan dan evaluasi, tugas menjadi tersedia untuk implementasi.

Ok, proses bisnis telah berubah, perlu untuk mengotomatisasi . Untuk memiliki lebih banyak kebebasan kreativitas, kami berhenti menggunakan tugas dan memo (semua orang menggunakannya), dan kami membuat dan membuat dua objek baru untuk diri kita sendiri dalam 1-2 hari:
1. Aplikasi ke departemen TI, dengan semua bidang yang diperlukan untuk evaluasi kami;

2. Sistem akuntansi yang disederhanakan untuk proyek dan tugas di dalamnya, dengan sistem evaluasi yang sama.

Dan segera mereka membuat laporan yang menunjukkan output dalam hitungan jam dan uang yang didapat sehingga programmer bisa melihat hasilnya setiap hari.

Mulai bekerja, dan segera menghadapi kesulitan - programmer mulai mengeluh bahwa peringkat tugasnya terlalu rendah . "Aku perlu memikirkannya," "tapi aku belum pernah menemukan pemrosesan, aku perlu menyelesaikannya", "Aku pernah melakukan tugas otomatis, apakah ada instruksi untuk membaca?" dll.

Saya mendengarkan mereka, dan mulai merenungkan kedalaman filosofis dari pertanyaan: haruskah perusahaan membayar untuk memperoleh pengetahuan oleh karyawannya?

Tampaknya jawabannya jelas - seharusnya. Tetapi apakah itu semua sangat jelas? Apa yang terjadi?

Ini adalah tugas untuk satu programmer - untuk mengisi sub-gudang Warehouse di posting ke akun 003 (untuk beberapa alasan, dalam soft starter tipikal itu tidak terisi). Tetapi dia tidak tahu bagaimana memprosesnya, baik di sisi kontraktor, maupun di sisi prosesor.

Tampaknya - duduk dan mencari tahu apa ini dan itu, selalu melakukannya. Dalam sistem gaji tradisional, majikan akan membayar Anda saat Anda mencari-cari di sana.

Tapi itu tidak sesederhana itu. Dari empat orang (tiga programmer + saya, kepala), dua berpengalaman dalam memproses, dan tugas pergi ke seseorang yang tidak mengerti. Kapan kami mengerti daur ulang? Programmer berada di pekerjaan terakhir, saya di tempat saat ini, karena sebelumnya tidak ada praktik tol / daur ulang. Ternyata perusahaan saat ini telah membayar kompetensi ini . Dan sepertinya membayar untuk kedua kalinya, setidaknya dalam jumlah yang sama, salah. Apa yang sekarang perlu dilakukan? Itu benar, mentransfer kompetensi kepada orang yang menerima tugas.

Pertanyaan lain muncul - dan untuk apa pembawa kompetensi memerlukan ini? Ia juga memiliki gaji per satuan, dan alih-alih mentransfer pengetahuan, ia akan melakukan lebih banyak pekerjaan dengan lebih baik.

Saya mulai merenungkan pertanyaan yang bahkan lebih filosofis: haruskah perusahaan membayar untuk alih kompetensi antar karyawan? Secara tradisional, transfer pengetahuan diterima begitu saja. Tetapi kita semua tahu bahwa kualitas transfer seperti itu menyisakan banyak yang diinginkan. Pengecualiannya adalah program adaptasi dan pendampingan, tetapi mereka tidak terlalu umum.

Jadi, solusinya menjadi jelas bagi kami:
1. Untuk transfer pengetahuan dan saling membantu harus dibayar;
2. Untuk perolehan kompetensi baru harus dibayar.

Poin kedua adalah tentang pengetahuan yang tidak dimiliki oleh tim. Sebagai contoh, kami memiliki tugas untuk secara konstan menarik data dari sistem eksternal ke dalam 1C menggunakan permintaan langsung ke MS SQL. Tugasnya tidak sulit, tetapi belum ada yang melakukan ini sebelumnya. Saya melakukan ini - saya membuat aplikasi atas nama saya, intinya adalah merokok bekerja dengan sumber data eksternal pada tingkat yang cukup untuk menyelesaikan masalah tertentu. Penilaian tugas - 1 jam (dan Anda bisa duduk setidaknya sepanjang hari).

Sebagai hasil dari penyelesaian masalah, kami mendapatkan spesialis yang dapat menyelesaikan masalah dengan sumber data eksternal, dan kami tidak akan membayar lebih untuk kompetensi ini . Hanya untuk transfernya ke programmer lain.

Kami memutuskan untuk membayar transfer kompetensi dan bantuan timbal balik, dan untuk ini kami datang dengan istilah yang tepat - biaya analisis dan desain. Agar tidak membuang waktu pada birokrasi besar, kami menggambar sebuah tabel di Word yang berisi data:
1. Masalah yang dibahas / dirancang / dirujuk;
2. Waktu mulai dan berakhirnya diskusi, akurat hingga menit;
3. Para peserta.

Dokumen terpisah ditambahkan ke sistem akuntansi, di mana hasil diskusi tersebut didorong dalam seminggu sekali. Biasanya diskusi masuk dalam 5 menit , kadang-kadang mencapai 15 menit. Selama seminggu ternyata 3-5 jam sekali .

Yang penting: waktu diskusi dibayarkan kepada semua pesertanya , yaitu itu bermanfaat untuk memperoleh dan mengirimkan pengetahuan. Itu bermanfaat untuk membantu rekan kerja hukum manusia belum hilang - jika Anda membantu, maka mereka akan membantu Anda, dan jika Anda menyimpan pengetahuan untuk diri Anda sendiri, maka bersiaplah, dihadapkan dengan tugas yang tidak dikenal dengan perkiraan 1 jam, duduklah selama 2 hari. Tentu saja, ada pengecualian ketika saya sendiri menghapus dari daftar peserta yang duduk dan menghitung gagak.

Ya, semua rapat seperti itu seharusnya diadakan di hadapan saya, seperti Sebelum dunia luar, saya bertanggung jawab atas kualitas sistem. Semua masalah yang dibahas tercermin dalam sistem, dan jika perlu dimungkinkan untuk kembali dan melihat apakah uang itu dihabiskan secara legal.

Ada satu lagi pertanyaan "busuk" - dukungan teknis . Pelanggaran - karena saya tidak suka ketersediaan dukungan teknis, itu menumpulkan pikiran pengguna, menghilangkan waktu berharga dari spesialis, tanpa membawa manfaat khusus bagi perusahaan.

Secara formal, dukungan teknis pada waktu itu adalah petugas yang berdedikasi yang harus membantu orang dalam waktu seminggu. Berapa yang harus dibayarkan kepada seorang programmer yang duduk di dukungan teknis?

Pada awalnya, idenya bukan untuk membayar sama sekali, tetapi untuk mengurangi dasar untuk menghitung gaji saat menghitung pembayaran. Misalnya, jika seorang programmer memiliki gaji 60 tr, menghabiskan 2 minggu dalam sebulan untuk dukungan teknis, maka ketika menghitung, pertimbangkan setengah sebagai gaji - 30 tr, dan untuk sisa waktu, pertimbangkan kesepakatan.

Tetapi segera jelas bahwa semacam omong kosong sedang diperoleh - perusahaan tidak terlalu besar, dan dukungan teknis yang obyektif tidak memakan waktu seharian. Dengan demikian, programmer berhasil memecahkan masalah dan dapat menggunakan skema dengan "brengsek".

Ada cara yang jauh lebih mudah - untuk menghitung berapa banyak waktu per hari pergi ke dukungan teknis dari karyawan terbaik , dan membayar programmer jumlah yang sama hari ini. Karena Saya dianggap yang terbaik di geng ini, lalu saya mengukurnya sendiri. Saya hanya duduk selama beberapa hari di dukungan dengan stopwatch dan tujuannya bukan untuk mengoleskan ingus, tetapi untuk dengan cepat membantu orang. Arahkan pertanyaan mereka ke tugas dengan benar. Berikan tautan ke instruksi jika seseorang belum membacanya dan membutuhkan pelatihan online tentang apa yang diketahui semua orang di sekitarnya. Baik, dll

Menurut hasil pengukuran, ternyata dukungan teknis membutuhkan rata-rata 2 jam sehari . Nah, itu angkanya. Kami sepakat bahwa dalam jumlah ini ia akan dibayarkan kepada petugas jaga - 2 jam sehari, atau 10 jam seminggu.

Jelas bahwa tidak menguntungkan untuk hanya terlibat dalam dukungan teknis - ini sekitar 25 ribu rubel sebulan.

Agar petugas jaga tidak bosan, kami memberinya selembar kertas dan membuatnya menuliskan semua orang yang memanggilnya - hanya nama belakangnya. Dalam sistem akuntansi, dokumen dibuat di mana petugas pada hari itu membawa semua "mualaf". Mengapa - lihat di akhir artikel, di bawah judul "Bonus yang bagus."

Sebenarnya, gambar terbentuk pada ini, dan kami melanjutkan uji operasi sistem .

Di antara programmer ada antusiasme yang belum pernah terjadi sebelumnya . Digenggam pada tugas itu, asap berdiri sebagai pilar saat eksekusi.

Diam-diam seorang programmer mulai bekerja, yang dulu suka membahas "tugas yang sulit, ada begitu banyak jebakan", ia bisa menghabiskan waktu berjam-jam mengisap jebakan ini, mengisi harganya sendiri (namun tidak jelas, mengapa, mengapa - gajinya).

Programmer segera mulai memberikan keputusan optimal, yang dulu suka duduk berjam-jam dan "memikirkan solusi optimal", karena sekarang solusi optimal dikeluarkan oleh tim brainstorming dalam 5 menit.

Seorang programmer introvert mulai berkomunikasi lebih sering dengan pelanggan, yang bisa duduk selama dua hari karena sudah merasa malu untuk berbicara dengan pelanggan.

Banyak tugas yang lebih masuk akal, berkualitas tinggi dari pengguna mulai muncul, karena programmer mulai membantu dalam desain mereka.

Programmer pemula, yang malu mengajukan pertanyaan kepada rekan-rekannya karena "tidak nyaman untuk mengalihkan perhatian, akan terganggu" (harus saya katakan, mereka benar-benar kesal sebelumnya) selama berjam-jam duduk dan mati.

Programmer telah menjadi bergairah dan serakah, dalam arti kata yang baik. Saya, sebagai seorang pemimpin, mencapai tujuan saya - sistem mulai bekerja, meskipun tidak tanpa saya, kemudian dengan partisipasi minimum saya.

Partisipasi saya menjadi transparan dan dapat dimengerti, ini hanya poin dalam proses bisnis:
1. Penerimaan dan penilaian tugas, saya lakukan ini sekali sehari, selama sekitar 15 menit;
2. Partisipasi dalam rapat analisis dan desain (ini ~ 3 kali sehari selama 5 menit).

Total, untuk mengelola tiga programmer - 30-60 menit sehari . Tidak ada yang perlu menendang, mengikuti eksekusi dan waktu, memotivasi, memeriksa kualitas - semuanya dilakukan dengan sendirinya . Saya bisa menonton hasilnya kapan saja melalui sistem. Ini bukan untuk mengatakan bahwa itu ternyata pemerintahan mandiri yang lengkap, tetapi kami sedekat mungkin dengannya.

Kami melakukan operasi uji selama 3 bulan. Selama waktu ini, output di jam tangan telah dua kali lipat , dan gaji yang dihitung untuk motivasi baru telah tumbuh sebesar 30%. Perbedaannya jelas - sekarang gaji harus dikerjakan . Menurut programmer sendiri, mereka tidak pernah harus bekerja secara intensif di mana pun sebelumnya. Itu intens, tidak lama atau lama - saya selalu menentang lebih dari 8 jam hari kerja.

Tetapi yang penting di sini bukanlah apa yang mereka katakan tentang intensitas pekerjaan, tetapi bagaimana mereka mengatakannya. Mereka berbicara dengan bangga untuk diri mereka sendiri.. Bukan hanya karena sistem baru membuat pekerjaan mereka lebih efisien, tetapi juga karena mereka sendiri adalah penulis sistem ini. Mereka sendiri membuat diri mereka lebih efektif, mereka sendiri membuat pekerjaan mereka transparan dan terukur, mereka sendiri mulai melihat secara berbeda pada perusahaan, para manajer dan karyawannya.

Saya menjelaskan kesuksesan sebagai berikut:
1. Jika Anda melihat melalui prisma tesis tentang pengembangan sistem motivasi, menjadi jelas bahwa kami telah mendefinisikan produk dengan baik. Suatu produk adalah tugas yang diselesaikan. Uang jernih dibayarkan untuk produk ini. Segala sesuatu yang lain - dengan biaya Anda sendiri (refleksi, Internet, komunikasi dalam pesan instan, istirahat asap, mengomel, depresi, dll.).
2. Jika Anda melihat proses pengembangan melalui manajemen diri, Anda dapat melihat bahwa sistem itu dibuat dengan partisipasi langsung dari orang-orang yang bekerja di dalamnya.
3. Kami membuat sistem terukur yang kami bisa - sesuai dengan persyaratan pengendalian. Hanya pengukuran pekerjaan yang dilakukan membuat orang bergerak lebih cepat dan tidak terlibat dalam omong kosong.

Setelah operasi pengujian, saya melewati beberapa iterasi untuk melindungi sistem baru: direktur personalia, direktur keuangan, direktur, pemilik, konsultan SDM eksternal (Moskow, tampaknya sangat terkenal). Semua orang menyukai sistem.

Sebagai kepala pengembangannya, saya secara khusus tertarik pada pendapat konsultan SDM, sebagai Dia tahu praktik dunia dengan baik dan telah menyelesaikan ratusan proyek untuk mengembangkan sistem motivasi. Penilaiannya terhadap sistem saya ternyata sangat tinggi, ia terutama menyukai kontur pertahanan ("ingat minus" dan membatasi pembayaran maksimum).

Selanjutnya, prinsip-prinsip sistem ini menjadi dasar untuk sistem motivasi perusahaan lainnya.

Bonus yang bagus.
Jadi, kami memiliki estimasi dalam rubel untuk semua pekerjaan, termasuk analisis, desain, dan dukungan teknis. Adalah dosa untuk tidak mengambil kesempatan ini, dan tidak membuat perhitungan biaya otomatisasi dalam konteks pelanggan dan proyek . Bagaimanapun, kami sekarang tahu pasti berapa banyak uang yang dihabiskan perusahaan melalui otomatisasi, dan jika Anda melihat data ini dalam hal utilitas , kami hanya mendapatkan gambaran yang bagus.

Sebagai contoh, kami mengetahui bahwa dukungan teknis untuk wakil kepala akuntan, yang, menurut uraian tugas, harus mengetahui AMR terbaik dalam bidang akuntansi, menyisakan lebih banyak uang daripada yang diterima orang ini dalam bentuk gaji.

Kami juga belajar bahwa orang yang selalu merengek “tidak terlibat dalam kami” mengkonsumsi 40% dari semua uang untuk otomatisasi.

Sangat menarik untuk melihat peningkatan anggaran dari bulan ke bulan untuk proyek-proyek yang tidak memiliki host (ini ketika direktur, misalnya, mengatakan - mengotomatisasi layanan ini, dan otomatisasi tidak berjalan di mana pun, tetapi mereka harus menulis tugas sendiri, sehingga mereka berputar-putar) .

Pendewaan adalah laporan pada sesi strategis dengan hasil yang mengecewakan - lebih dari setengah dari uang yang dihabiskan perusahaan untuk otomatisasi yang tidak masuk akal. Ketidakberesan adalah karakteristik yang sepenuhnya bermakna. Misalnya, fungsi dikembangkan, tidak ada komentar, tetapi tidak digunakan ("ya, entah bagaimana semua tangan tidak mencapai"). Atau fungsi yang dirancang untuk membantu meningkatkan proses manajemen dengan mengubah nilai indikator - dan nilai indikator diam atau memburuk (dan pada awal proyek dikatakan bahwa ini tidak akan membantu kalian, Anda memiliki masalah yang berbeda).

Apa hasilnya? Mereka mulai mendengarkan kami lebih sering dan hati-hati, terutama sebelum pekerjaan dimulai. Karena kami sekarang dapat memprediksi hasil proyek, tidak hanya mengandalkan pemikiran sistemik, tetapi juga pada statistik dalam jumlah. Volume pekerjaan yang tidak berarti di bulan-bulan pertama menurun hingga 30% - terlepas dari kenyataan bahwa struktur “tidak berarti” membaik. Tapi itu cerita lain.

PS

Ada orang yang telah mengulangi pengalaman saya - yah, yaitu, mereka juga membangun sistem manajemen dan motivasi berdasarkan jam standar tertentu. Mereka mengatakan mereka baik-baik saja. Meskipun, siapa yang mengakui ...

Saya tidak tahu tentang Anda, tapi saya bodoh. Pengalaman yang dijelaskan dalam artikel itu terjadi sekitar 4 tahun yang lalu, jika saya ingat dengan benar. Kemudian saya mengetahui tentang scrum - lebih tepatnya, saya membeli buku di obral - dan terbawa suasana, tetapi saya meninggalkan semua yang sudah tua. Karena itu bodoh.

Anda selalu ingin tidak berpikir, tetapi untuk menyelesaikannya. Scrum, PMBOOK, CORE PM, Kanban, CBT atau yang lainnya, "implement" atau, yang lebih modis, "implement". Dan beberapa bajingan, seperti pengembang panduan scrum, juga memicu situasi dengan mengatakan sesuatu seperti "jika Anda melakukannya dengan cara yang salah, maka Anda tidak perlu takut." Meskipun dalam buku itu mereka sendiri menulis bahwa Anda perlu berpikir dengan kepala sendiri.

Pengalaman yang dijelaskan dalam artikel ini sangat berharga. Bagi saya, tentu saja. Kalau saja karena dia menunjukkan pentingnya menilai tugas di beberapa unit yang lebih atau kurang stabil. Kemudian, sudah di scrum, itu berubah menjadi poin. Lebih banyak pengalaman menunjukkan apa yang sistem motivasi lakukan dengan orang. Dia juga menunjukkan bahwa dengan sistem manajemen dan motivasi yang tepat, orang tidak perlu seorang pemimpin. Dan banyak lagi yang telah ditampilkan.

Bagaimana kamu menyukainya? Apakah ini membantu? Atau beee, bukan tenaga kerja, ini tentang 1Snikov.