Mengelola tim pemrogram: bagaimana dan bagaimana memotivasi mereka dengan benar? Bagian kedua

Prasasti:
Sang suami, memandangi anak-anak yang kotor, berkata kepada istrinya: baiklah, haruskah kita mencucinya atau melahirkan yang baru?

Di bawah ini adalah bagian kedua dari artikel oleh ketua tim kami, serta Direktur Pengembangan Produk RAS Igor Marnat, tentang kekhasan memotivasi programmer. Bagian pertama artikel dapat ditemukan di sini - habr.com/ru/company/parallels/blog/452598

Mengelola tim pemrogram: bagaimana dan bagaimana memotivasi mereka dengan benar? Bagian kedua

Pada bagian pertama artikel, saya menyinggung dua tingkat terbawah dari piramida Maslow: kebutuhan fisiologis, kebutuhan akan rasa aman, kenyamanan dan keteguhan dan beralih ke tingkat berikutnya, ketiga, yaitu:

III - Kebutuhan akan rasa memiliki dan cinta

Mengelola tim pemrogram: bagaimana dan bagaimana memotivasi mereka dengan benar? Bagian kedua

Saya tahu bahwa mafia Italia disebut “Cosa Nostra”, tetapi saya sangat terkesan ketika mengetahui bagaimana “Cosa Nostra” diterjemahkan. “Cosa Nostra” yang diterjemahkan dari bahasa Italia berarti “Bisnis Kami”. Pemilihan nama sangat berhasil untuk motivasi (kesampingkan saja pekerjaan, dalam hal ini kita hanya tertarik pada motivasi). Seseorang biasanya ingin menjadi bagian dari sebuah tim, untuk melakukan suatu hal yang besar dan umum.

Pemuasan kebutuhan akan rasa memiliki dan cinta di angkatan darat, angkatan laut, dan formasi paramiliter besar mana pun sangat penting. Dan, seperti yang bisa kita lihat, di mafia. Hal ini dapat dimaklumi, karena perlu memaksa orang-orang yang memiliki sedikit kesamaan, yang pada awalnya tidak membentuk tim yang terdiri dari orang-orang yang berpikiran sama, yang disatukan melalui wajib militer (tidak secara sukarela), yang memiliki tingkat pendidikan yang berbeda, nilai-nilai pribadi yang berbeda. , untuk benar-benar mengabdikan hidup mereka, dengan risiko mematikan, untuk tujuan bersama, mempercayakan hidup Anda kepada rekan seperjuangan.

Ini adalah motivasi yang sangat kuat; bagi kebanyakan orang, sangatlah penting untuk merasa menjadi bagian dari sesuatu yang lebih besar, mengetahui bahwa Anda adalah bagian dari sebuah keluarga, negara, dan tim. Di ketentaraan, seragam, berbagai ritual, parade, pawai, spanduk, dan sebagainya memenuhi tujuan ini. Kira-kira faktor yang sama penting bagi tim mana pun. Simbol, merek perusahaan dan warna perusahaan, perlengkapan dan suvenir adalah hal yang penting.

Adalah penting bahwa peristiwa-peristiwa penting mempunyai perwujudan nyata yang dapat dikaitkan dengannya. Saat ini, sudah menjadi hal yang lumrah bagi sebuah perusahaan untuk memiliki barang dagangan sendiri, jaket, T-shirt, dan lain-lain. Namun penting juga untuk menonjolkan tim di dalam perusahaan. Seringkali kami merilis kaos berdasarkan hasil rilis yang diberikan kepada semua pihak yang terlibat dalam rilis tersebut. Beberapa acara, perayaan bersama atau kegiatan dengan seluruh tim merupakan faktor motivasi penting lainnya.

Selain atribut eksternal, ada beberapa faktor lain yang mempengaruhi rasa memiliki terhadap suatu tim.
Pertama, adanya tujuan bersama sehingga semua orang memahami dan berbagi penilaian tentang pentingnya tujuan tersebut. Pemrogram biasanya ingin memahami bahwa mereka melakukan hal keren, dan mereka melakukan hal keren ini bersama-sama, sebagai sebuah tim.
Kedua, tim harus memiliki ruang komunikasi di mana seluruh tim hadir dan hanya menjadi miliknya (misalnya, obrolan di messenger, sinkronisasi tim secara berkala). Selain masalah pekerjaan, komunikasi informal, terkadang diskusi tentang acara eksternal, offtop ringan - semua ini menciptakan rasa kebersamaan dan tim.
Ketiga, saya akan menyoroti pengenalan praktik rekayasa yang baik dalam tim, keinginan untuk meningkatkan standar dibandingkan dengan yang diterima di perusahaan. Menerapkan pendekatan terbaik yang diterima di industri, pertama di tim, dan kemudian di perusahaan secara keseluruhan, memberikan kesempatan kepada tim untuk merasa bahwa mereka lebih maju dari yang lain dalam beberapa hal, memimpin, hal ini menciptakan rasa memiliki. ke tim yang keren.

Rasa memiliki juga dipengaruhi oleh partisipasi tim dalam perencanaan dan pengelolaan. Ketika anggota tim terlibat dalam mendiskusikan tujuan proyek, rencana kerja, standar tim dan praktik teknis, serta mewawancarai karyawan baru, mereka mengembangkan rasa partisipasi, kepemilikan bersama, dan pengaruh terhadap pekerjaan. Masyarakat jauh lebih bersedia untuk melaksanakan keputusan yang dibuat dan disuarakan oleh mereka sendiri dibandingkan dengan keputusan yang diusulkan oleh orang lain, meskipun keputusan tersebut secara praktis selaras.

Ulang tahun, hari jadi, peristiwa penting dalam kehidupan rekan kerja - pizza bersama, hadiah kecil dari tim memberikan perasaan hangat akan keterlibatan dan rasa syukur. Di beberapa perusahaan, merupakan kebiasaan untuk memberikan tanda peringatan kecil selama 5, 10, 15 tahun bekerja di perusahaan tersebut. Di satu sisi, menurut saya hal ini tidak begitu memotivasi saya untuk mencapai prestasi baru. Tapi, tentu saja, hampir semua orang akan senang karena mereka tidak melupakannya. Ini adalah salah satu kasus ketika ketiadaan suatu fakta justru menurunkan motivasi, bukan kehadiran fakta yang memotivasi. Setuju, sayang sekali jika LinkedIn mengingatkan Anda di pagi hari dan mengucapkan selamat ulang tahun ke 10 di tempat kerja Anda, namun tidak ada satu pun rekan kerja di perusahaan tersebut yang mengucapkan selamat atau mengingat Anda.

Tentu yang menjadi poin penting adalah perubahan komposisi tim. Jelas bahwa meskipun kedatangan atau kepergian seseorang dari tim diumumkan sebelumnya (misalnya, dalam buletin perusahaan atau tim, atau pada rapat tim), hal ini tidak terlalu memotivasi siapa pun untuk mencapai prestasi baru. Namun jika suatu hari Anda melihat orang baru di samping Anda, atau tidak melihat orang lama, itu bisa menjadi kejutan, dan jika Anda pergi, itu benar-benar tidak menyenangkan. Orang tidak seharusnya menghilang secara diam-diam. Terutama di tim yang terdistribusi. Apalagi jika pekerjaan Anda bergantung pada rekan kantor lain yang tiba-tiba muncul dan menghilang. Momen seperti itu patut untuk diberitahukan kepada tim secara terpisah terlebih dahulu.

Faktor penting, yang dalam bahasa Inggris disebut kepemilikan (terjemahan literal dari “kepemilikan” tidak sepenuhnya mencerminkan maknanya). Ini bukan perasaan memiliki, melainkan rasa tanggung jawab terhadap proyek Anda, perasaan ketika Anda mengasosiasikan diri Anda secara emosional dengan produk dan produk dengan diri Anda sendiri. Hal ini kira-kira sesuai dengan doa para Marinir dalam film “Full Metal Jacket”: “Ini senapanku. Ada banyak senapan seperti itu, tapi yang ini milik saya. Senapanku adalah sahabatku. Dia adalah hidupku. Saya harus belajar memilikinya dengan cara yang sama seperti saya memiliki hidup saya. Tanpa saya, senapan saya tidak ada gunanya. Aku tidak berguna tanpa senapanku. Aku harus menembakkan senapanku dengan lurus. Saya harus menembak lebih akurat dibandingkan musuh yang mencoba membunuh saya. Aku harus menembaknya sebelum dia menembakku. Biarkan seperti itu… ".

Ketika seseorang mengerjakan suatu produk untuk waktu yang lama, memiliki kesempatan untuk memikul tanggung jawab penuh atas penciptaan dan pengembangannya, untuk melihat bagaimana suatu karya muncul dari “ketiadaan”, bagaimana orang menggunakannya, perasaan yang kuat ini muncul. Tim produk yang bekerja sama dalam waktu lama dalam satu proyek biasanya lebih termotivasi dan kohesif dibandingkan tim yang berkumpul dalam waktu singkat dan bekerja dalam mode jalur perakitan, berpindah dari satu proyek ke proyek lainnya, tanpa tanggung jawab penuh atas keseluruhan produk. , dari awal sampai akhir.

IV. Kebutuhan akan pengakuan

Kata-kata yang baik juga menyenangkan kucing. Setiap orang termotivasi oleh pengakuan akan pentingnya pekerjaan yang telah mereka lakukan dan penilaian positifnya. Bicaralah dengan programmer, beri mereka umpan balik secara berkala, rayakan pekerjaan yang telah diselesaikan dengan baik. Jika Anda memiliki tim yang besar dan terdistribusi, pertemuan berkala (yang disebut pertemuan satu lawan satu) sangat cocok untuk ini; jika tim sangat kecil dan bekerja sama secara lokal, kesempatan ini biasanya diberikan tanpa pertemuan khusus di kalender (walaupun pertemuan berkala hanya satu saja. Itu masih diperlukan, Anda hanya dapat melakukannya lebih jarang). Topik ini dibahas dengan baik dalam podcast untuk manajer di manager-tools.com.

Namun, ada baiknya mempertimbangkan perbedaan budaya. Beberapa pendekatan yang familiar bagi rekan-rekan Amerika tidak selalu berhasil dengan pendekatan Rusia. Tingkat kesopanan yang diterima dalam komunikasi sehari-hari dalam tim di negara-negara Barat pada awalnya terkesan berlebihan bagi programmer asal Rusia. Beberapa sifat keterusterangan rekan-rekan Rusia mungkin dianggap sebagai kekasaran oleh rekan-rekan mereka dari negara lain. Ini sangat penting dalam komunikasi dalam tim antaretnis; banyak yang telah ditulis tentang topik ini; manajer tim tersebut harus mengingat hal ini.

Demonstrasi fitur, dimana programmer menunjukkan fitur yang dikembangkan selama sprint, adalah praktik yang baik untuk mewujudkan kebutuhan ini. Selain fakta bahwa ini adalah peluang bagus untuk membersihkan saluran komunikasi antar tim, memperkenalkan fitur baru kepada manajer produk dan penguji, ini juga merupakan peluang bagus bagi pengembang untuk menunjukkan hasil pekerjaan mereka dan menunjukkan kepenulisan mereka. Ya, dan asah keterampilan berbicara di depan umum Anda, tentu saja, tidak ada salahnya.

Merupakan ide bagus untuk merayakan kontribusi signifikan dari kolega-kolega terkemuka dengan sertifikat, tanda peringatan (setidaknya kata-kata baik) pada pertemuan tim gabungan. Orang-orang biasanya sangat menghargai sertifikat dan tanda peringatan tersebut, membawanya saat pindah, dan umumnya merawatnya dengan segala cara yang memungkinkan.

Untuk menandai kontribusi jangka panjang yang lebih signifikan terhadap kerja tim, akumulasi pengalaman dan keahlian, sistem penilaian sering digunakan (sekali lagi, analogi dapat ditarik dengan sistem pangkat militer di angkatan bersenjata, yang juga untuk memastikan subordinasi, juga memenuhi tujuan ini). Seringkali pengembang muda bekerja dua kali lebih keras untuk mendapatkan bintang baru (yaitu berpindah dari pengembang junior ke pengembang penuh waktu, dll.).

Mengetahui ekspektasi masyarakat Anda sangatlah penting. Beberapa lebih cenderung termotivasi oleh nilai yang tinggi, kesempatan untuk dipanggil, katakanlah, seorang arsitek, sementara yang lain, sebaliknya, acuh tak acuh terhadap nilai dan gelar dan akan menganggap kenaikan gaji sebagai tanda pengakuan dari perusahaan. . Berkomunikasi dengan orang-orang untuk memahami apa yang mereka inginkan dan apa harapan mereka.

Demonstrasi pengakuan, tingkat kepercayaan yang lebih tinggi di pihak tim, dapat diberikan dengan memberikan lebih banyak kebebasan bertindak atau keterlibatan dalam bidang kerja baru. Misalnya, setelah memperoleh pengalaman tertentu dan mencapai hasil tertentu, seorang programmer, selain mengimplementasikan fitur-fiturnya sesuai dengan spesifikasi, juga dapat mengerjakan arsitektur hal-hal baru. Atau terlibat dalam bidang baru yang mungkin tidak terkait langsung dengan pengembangan - otomatisasi pengujian, penerapan praktik teknik terbaik, membantu manajemen rilis, menjadi pembicara di konferensi, dll.

V. Kebutuhan akan kognisi dan aktualisasi diri.

Banyak programmer berfokus pada berbagai jenis aktivitas pemrograman pada berbagai tahap kehidupan mereka. Beberapa orang suka melakukan pembelajaran mesin, mengembangkan model data baru, membaca banyak literatur ilmiah untuk bekerja, dan membuat sesuatu yang baru dari awal. Cara lainnya lebih dekat dengan men-debug dan mendukung aplikasi yang sudah ada, di mana Anda perlu menggali lebih dalam kode yang ada, mempelajari log, jejak tumpukan, dan captcha jaringan selama berhari-hari dan berminggu-minggu, dan hampir tidak menulis kode baru.

Kedua proses tersebut memerlukan upaya intelektual yang besar, namun hasil praktisnya berbeda. Hal ini diyakini bahwa programmer enggan untuk mendukung solusi yang ada; mereka lebih termotivasi untuk mengembangkan solusi baru. Ada sebutir hikmah dalam hal ini. Di sisi lain, tim yang paling termotivasi dan bersatu yang pernah bekerja dengan saya berdedikasi untuk mendukung produk yang sudah ada, menemukan dan memperbaiki bug setelah tim dukungan menghubungi mereka. Orang-orang itu benar-benar hidup untuk pekerjaan ini dan siap untuk pergi keluar pada hari Sabtu dan Minggu. Kami pernah dengan penuh semangat menangani masalah mendesak dan kompleks lainnya, baik pada malam tanggal 31 Desember atau pada sore hari tanggal 1 Januari.

Ada beberapa faktor yang mempengaruhi tingginya motivasi tersebut. Pertama, ini adalah perusahaan dengan nama besar di industrinya, tim mengasosiasikan diri mereka dengannya (lihat “Kebutuhan Afiliasi”). Kedua, mereka adalah garis depan terakhir, tidak ada orang di belakang mereka, dan tidak ada tim produk saat itu. Antara mereka dan pelanggan ada dua tingkat dukungan, tetapi jika masalah mencapai mereka, tidak ada tempat untuk mundur, tidak ada seorang pun di belakang mereka, seluruh perusahaan ada pada mereka (empat programmer muda). Ketiga, perusahaan besar ini mempunyai pelanggan yang sangat besar (pemerintah negara, perusahaan otomotif dan penerbangan, dll.) dan instalasi berskala sangat besar di beberapa negara. Akibatnya, masalah selalu kompleks dan menarik, masalah sederhana diselesaikan dengan dukungan level sebelumnya. Keempat, motivasi tim sangat dipengaruhi oleh tingkat profesional tim pendukung yang berinteraksi dengan mereka (ada insinyur yang sangat berpengalaman dan mampu secara teknis), dan kami selalu yakin dengan kualitas data yang mereka siapkan, analisis yang mereka lakukan. , dll. Kelima, dan menurut saya ini adalah poin yang paling penting - tim ini masih sangat muda, semua pemain masih berada di awal karir mereka. Mereka tertarik untuk mempelajari produk yang besar dan kompleks, memecahkan masalah serius yang baru bagi mereka di lingkungan baru, mereka berusaha untuk secara profesional mencocokkan tingkat tim, masalah, dan pelanggan di sekitarnya. Proyek ini ternyata merupakan sekolah yang luar biasa, semua orang kemudian memiliki karier yang baik di perusahaan dan menjadi pemimpin teknis dan manajer senior, salah satu dari mereka sekarang menjadi manajer teknis di Amazon Web Services, yang lainnya akhirnya pindah ke Google, dan semuanya diantaranya masih mengingat proyek ini dengan hangat.

Jika tim ini terdiri dari programmer dengan pengalaman 15-20 tahun, motivasinya akan berbeda. Usia dan pengalaman tentu saja tidak 100% menjadi faktor penentu, semuanya tergantung pada struktur motivasi. Dalam kasus khusus ini, keinginan akan pengetahuan dan pertumbuhan programmer muda membuahkan hasil yang sangat baik.

Secara umum, seperti yang telah kami sebutkan beberapa kali, Anda harus mengetahui ekspektasi programmer Anda, memahami siapa di antara mereka yang ingin memperluas atau mengubah bidang kegiatannya, dan mempertimbangkan ekspektasi tersebut.

Melampaui piramida Maslow: visibilitas hasil, gamifikasi, dan persaingan, bukan omong kosong

Ada tiga poin penting lagi mengenai motivasi programmer yang perlu disebutkan, tetapi memasukkan mereka ke dalam model kebutuhan Maslow akan terlalu dibuat-buat.

Yang pertama adalah visibilitas dan kedekatan hasilnya.

Pengembangan perangkat lunak biasanya bersifat maraton. Hasil dari upaya penelitian dan pengembangan akan terlihat setelah berbulan-bulan, terkadang bertahun-tahun. Sulit untuk mencapai tujuan yang jauh di luar cakrawala, banyaknya pekerjaan yang menakutkan, tujuan yang jauh, tidak jelas dan tidak terlihat, “malam gelap dan penuh kengerian.” Sebaiknya jalan menuju ke sana dipecah menjadi beberapa bagian, buatlah jalan menuju pohon terdekat yang terlihat, dapat dijangkau, garis luarnya jelas, dan tidak jauh dari kita - dan menuju ke tujuan yang dekat ini. Kami ingin berusaha beberapa hari atau minggu, mendapatkan dan mengevaluasi hasilnya, lalu melanjutkan. Oleh karena itu, ada baiknya memecah pekerjaan menjadi bagian-bagian kecil (sprint dengan tangkas dapat memenuhi tujuan ini dengan baik). Kami telah menyelesaikan sebagian pekerjaan - mencatatnya, menghembuskannya, mendiskusikannya, menghukum yang bersalah, memberi penghargaan kepada yang tidak bersalah - kita dapat memulai siklus berikutnya.

Motivasi ini sampai batas tertentu mirip dengan apa yang dialami pemain ketika menyelesaikan permainan komputer: mereka secara berkala menerima medali, poin, bonus saat mereka menyelesaikan setiap level; ini bisa disebut “motivasi dopamin.”

Pada saat yang sama, visibilitas hasil sangatlah penting. Fitur tertutup dalam daftar akan berubah menjadi hijau. Jika kode ditulis, diuji, dirilis, tetapi tidak ada perubahan status visual yang terlihat oleh programmer, ia akan merasa tidak lengkap, tidak ada rasa selesai. Di salah satu tim di sistem kontrol versi kami, setiap patch melewati tiga tahap berturut-turut - build dirakit dan pengujian berhasil, patch lolos tinjauan kode, patch digabungkan. Setiap tahap secara visual ditandai dengan tanda centang hijau atau tanda silang merah. Begitu salah satu pengembang mengeluh bahwa peninjauan kode memakan waktu terlalu lama, rekan kerja perlu mempercepatnya, tambalan terhenti selama beberapa hari. Saya bertanya, apa sebenarnya perubahan ini baginya? Lagi pula, ketika kode ditulis, build sudah dirakit dan tes telah lulus, dia tidak perlu memperhatikan patch yang dikirim jika tidak ada komentar. Rekan-rekan sendiri yang akan meninjau dan menyetujuinya (kalau lagi tidak ada komentar). Dia menjawab, “Igor, saya ingin mendapatkan tiga tanda centang hijau saya sesegera mungkin.”

Poin kedua adalah gamifikasi dan kompetisi.

Saat mengembangkan salah satu produk, tim teknik kami memiliki tujuan untuk mengambil posisi menonjol di komunitas salah satu produk open source, untuk masuk ke dalam 3 besar. Pada saat itu, belum ada cara obyektif untuk menilai visibilitas seseorang di masyarakat; masing-masing perusahaan besar yang berpartisipasi dapat mengklaim (dan secara berkala mengklaim) bahwa perusahaan tersebut adalah kontributor nomor satu, namun tidak ada cara nyata untuk membandingkan kontribusi para peserta. di antara mereka sendiri, untuk mengevaluasi dinamikanya seiring berjalannya waktu. Oleh karena itu, tidak ada cara untuk menetapkan tujuan bagi tim yang dapat diukur pada beberapa burung beo, menilai tingkat pencapaiannya, dll. Untuk mengatasi masalah ini, tim kami telah mengembangkan alat untuk mengukur dan memvisualisasikan kontribusi perusahaan dan kontributor individu www.stackalytics.com. Dari segi motivasi, ternyata hanya bom belaka. Bukan hanya para insinyur dan tim yang terus-menerus memantau kemajuan mereka dan kemajuan rekan kerja serta pesaing mereka. Manajemen puncak perusahaan kami dan semua pesaing utama juga memulai hari mereka dengan stackalytics. Semuanya menjadi sangat transparan dan visual, setiap orang dapat memantau kemajuan mereka dengan cermat, membandingkannya dengan rekan kerja, dll. Kini menjadi nyaman dan mudah bagi para insinyur, manajer, dan tim untuk menetapkan tujuan.

Poin penting yang muncul ketika menerapkan sistem metrik kuantitatif apa pun adalah bahwa segera setelah Anda menerapkannya, sistem secara otomatis berupaya memprioritaskan pencapaian metrik kuantitatif ini, sehingga merugikan metrik kualitatif. Misalnya, jumlah peninjauan kode yang diselesaikan digunakan sebagai salah satu metrik. Jelasnya, peninjauan kode dapat dilakukan dengan berbagai cara, Anda dapat menghabiskan beberapa jam untuk meninjau secara menyeluruh dan memeriksa patch yang rumit dengan memeriksa tes, menjalankannya di bangku Anda, memeriksa dengan dokumentasi, dan mendapatkan plus satu ulasan di karma Anda, atau klik secara membabi buta beberapa lusin tambalan dalam beberapa menit, berikan masing-masing tambalan +1 dan dapatkan karma plus dua puluh. Ada kasus lucu ketika para insinyur mengeklik tambalan dengan sangat cepat sehingga mereka memberi +1 pada tambalan otomatis dari sistem CI. Seperti yang kemudian kami bercanda, “ayo, ayo, jenkins.” Dalam kasus komitmen, ada juga banyak orang yang membaca kode dengan alat pemformatan kode, mengedit komentar, mengubah titik menjadi koma, dan dengan demikian meningkatkan karma mereka. Mengatasi hal ini cukup sederhana: kami menggunakan akal sehat dan, selain metrik kuantitatif, kami juga menggunakan metrik kualitatif yang esensial. Tingkat pemanfaatan hasil kerja tim, jumlah kontributor eksternal, tingkat cakupan pengujian, stabilitas modul dan keseluruhan produk, hasil pengujian skala dan kinerja, jumlah insinyur yang menerima bahu reviewer inti tali pengikatnya, fakta bahwa proyek diterima ke dalam komunitas proyek inti, kepatuhan terhadap kriteria berbagai tahapan proses rekayasa - semua ini dan banyak faktor lainnya harus dinilai bersama dengan metrik kuantitatif sederhana.

Dan terakhir, poin ketiga - Jangan omong kosong.

Pengembang adalah orang yang sangat cerdas dan sangat logis dalam pekerjaannya. Mereka menghabiskan 8-10 jam sehari untuk membangun rantai logis yang panjang dan rumit, sehingga mereka langsung melihat kerentanan di dalamnya. Ketika melakukan sesuatu, mereka, seperti orang lain, ingin memahami mengapa mereka melakukannya, apa yang akan berubah menjadi lebih baik. Sangatlah penting bahwa tujuan yang Anda tetapkan untuk tim Anda jujur ​​dan realistis. Mencoba menjual ide buruk kepada tim pemrograman adalah ide buruk. Sebuah ide dikatakan buruk jika Anda sendiri tidak mempercayainya, atau, dalam kasus ekstrem, Anda tidak memiliki kondisi internal untuk tidak setuju dan berkomitmen (saya tidak setuju, tapi saya akan melakukannya). Kami pernah menerapkan sistem motivasi di sebuah perusahaan, salah satu elemennya adalah sistem elektronik untuk memberikan feedback. Mereka menginvestasikan banyak uang, membawa orang ke Amerika untuk pelatihan, secara umum, mereka berinvestasi secara maksimal. Suatu ketika, dalam perbincangan usai pelatihan, salah satu manajer berkata kepada bawahannya: “Idenya lumayan, sepertinya akan berhasil. Saya sendiri tidak akan memberi Anda umpan balik elektronik, tetapi Anda memberikannya kepada orang-orang Anda dan memintanya dari mereka.” Itu saja, tidak ada yang bisa diimplementasikan lebih lanjut. Idenya, tentu saja, tidak berakhir apa-apa.

Sumber: www.habr.com

Tambah komentar