Siapa pemimpinnya, dan mengapa mereka dibutuhkan? Apa gunanya mereka dalam hidup? Apa yang mereka lakukan? Apa yang harus mereka lakukan?
Di satu sisi, pemimpin secara tradisional dipahami sebagai orang yang mengelola - membuat rencana, memberikan instruksi, mengendalikan waktu, berteriak paling keras, membuat keputusan dan bertanggung jawab untuk itu.
Di sisi lain, ada pendapat bahwa kepala hanya harus berurusan dengan pengembangan unit yang dipercayakan, tanpa mengambil bagian dalam manajemen operasional.
Di pihak ketiga, ada pemerintahan sendiri dan organisasi pirus, yang dalam praktiknya telah membuktikan bahwa entitas seperti pemimpin tidak diperlukan sama sekali - itu hanya seperangkat tanggung jawab, peran, dan titik kontrol yang mudah menyebar di antara orang yang berbeda.
Jadi siapa dia, pemimpin ini, dan mengapa dia dibutuhkan? Apakah manajer membutuhkan perusahaan atau perusahaan membutuhkan pemimpin sebagai sumber pendapatan? Mungkin dia membenarkan keberadaannya, karena hasilnya sepadan - penghasilan manajer seringkali jauh lebih tinggi daripada pendapatan karyawan biasa.
Saya menggunakan model khusus untuk mengevaluasi manajer, yang saya sarankan Anda kenali.
Model
Modelnya sederhana untuk dipermalukan, tetapi biasanya hanya bisa dimengerti oleh programmer. Tetapi Anda adalah programmer, dan semuanya akan jelas bagi Anda.
Jadi, bayangkan sebuah perusahaan yang telah mengotomatisasi akuntingnya dalam sistem informasi tertentu. Dan di sebelah sistem ini adalah seorang programmer, hanya satu. Dia dan kepala departemen TI, dan coder, dan arsitek - semuanya dalam satu. Situasi ini cukup umum untuk perusahaan kecil dan kadang-kadang besar - saya sendiri, untuk beberapa waktu, adalah satu-satunya programmer di perusahaan itu.
Jadi, sekarang bayangkan seorang programmer adalah kepala departemen, dan sistem informasi, pada kenyataannya, departemennya, termasuk personel, peralatan, proses, dll. Dan departemen, dan layanan, dan departemen, dan seluruh perusahaan - ini adalah sebuah sistem. Dan informasi - itu juga sebuah sistem.
Programmer bebas untuk memperlakukan sistemnya dengan cara yang berbeda - untuk mengembangkan, memelihara, menghapus, menghancurkan, atau meningkatkan produktivitas, mengganti dengan yang lain, menulis atau menghapus dokumen, mengontrol saldo, dll.
Kepala bebas melakukan hal yang sama dengan sistemnya (departemen) - untuk mengembangkan, menemani, bekerja sebagai pelaksana, mengganggu, membantu, membubarkan, mengganti personil, dll.
Modelnya jelas: hubungan manajer / departemen sama dengan programmer / sistem informasi.
Sekarang mari kita lihat pemimpin melalui prisma model ini.
Jas hujan
Tipe programmer yang paling primitif adalah programmer yang tidak melakukan apa-apa, tetapi entah bagaimana berhasil tidak keluar dari pekerjaan. Saya pribadi melihat ini - dia dibawa untuk beralih dari soft starter 1C 7,7 ke 1C 8 yang terintegrasi, dan dia tidak menggunakan kakinya, tidak juga pada yang pertama, maupun yang kedua, tetapi dia berbaring setahun - hanya karena fakta bahwa dia berlari ke Internet untuk mengatur Internet pada waktunya, ICQ dan unduh musik dari torrent.
Contoh lain adalah seorang gadis yang tidak tahu bagaimana melakukan sesuatu sendiri, tetapi memiliki jaringan kontak yang luas di antara programmer dan, seperti yang mereka katakan, cantik dan menawan, sehingga para pria dengan senang hati membantu, sepenuhnya menyelesaikan tugasnya. Terlebih lagi, mereka bekerja di perusahaan lain.
Anda mengerti bahwa sistem dengan programmer seperti itu menjalani hidupnya sendiri, praktis tidak tergantung sama sekali, dan tidak ada perubahan yang terlihat di dalamnya sebelum pergi.
Di antara para pemimpin orang-orang ini juga penuh - bahwa mereka, bahwa mereka tidak. Kadang-kadang mereka disebut jenderal pernikahan, tetapi ini dalam kasus-kasus di mana kepala dapat melakukan setidaknya fungsi representatif, misalnya, untuk duduk manis dalam pertemuan dengan klien.
Pemimpin seperti itu menyukai semua jenis acara, pertemuan - terutama di mana ada banyak orang dan tidak perlu membuka mulut mereka. Kadang-kadang mereka begitu sengsara sehingga jika mereka masih mendapatkan tugas dari kepemimpinan, maka mereka bahkan tidak dapat mendelegasikannya secara normal, karena sistem mengabaikan mereka sama sekali, kecuali jika seseorang mengasihani dan membantu.
Tidak masuk akal untuk berbicara tentang peran programmer dan pemimpin dalam sistem dan pengembangannya tidak ada peran dan tidak ada pengembangan. Ini adalah kasus yang paling menyedihkan.
Kerabat
Ini adalah jenis penyelaman yang terpisah, dengan perbedaan bahwa kerabat tidak perlu berbuat banyak untuk tetap di tempat. Mereka dibawa ke sana dengan cakar yang kasar, dan mereka duduk. Siapa yang seharian, siapa yang sebelum makan malam, siapa yang setelah makan malam, yang ada di rumah.
Kerabat sudah berdampak pada sistem, seperti mereka takut - Anda tidak pernah tahu kendali macam apa yang akan jatuh di bawah ekor, Anda bisa kehilangan pekerjaan Anda.
Namun pada kenyataannya, mereka biasanya tidak menggunakan pengaruh ini. Jadilah elemen dari sistem, mis. mereka tidak ingin melakukan fungsi apa pun di dalamnya, karena tanggung jawab dan kewajiban akan muncul, setidaknya Anda harus datang bekerja. Mereka tidak dapat mengembangkan sistem, karena ini membutuhkan setidaknya beberapa kompetensi dan pemahaman tentang apa yang terjadi.
Tentu saja, ada pengecualian ketika seorang kerabat tidak berperilaku seperti kerabat, tetapi kemudian kami dengan sungguh-sungguh mengecualikannya dari kategori ini. Kadang ikatan keluarga bahkan membantu, membuat seseorang lebih bertanggung jawab dan efektif, misalnya, dalam bisnis keluarga. Efisiensi meningkat karena kerabat tidak takut pemecatan.
Tetapi secara umum, untuk sebagian besar, programmer seperti itu tidak memainkan peran dalam kehidupan sistem, dan kepala dalam kehidupan departemen.
Sekrup
Kebetulan seorang programmer berubah menjadi operator. Tidak sering, tetapi itu terjadi.
Hanya melakukan pertukaran, mengunggah dan mengunduh file, membuat cadangan, memasukkan dokumen, menghasilkan laporan, melakukan beberapa jenis analisis data, dll. Bahkan, itu hanya melakukan pekerjaan pengguna. Dalam hidup saya, saya melihat ini ketika, perlahan, sedikit demi sedikit, dan programmer berubah menjadi seorang akuntan.
Jika diputar, mis. pindah ke departemen lain dan ke posisi lain - dan persetan dengannya, transformasi yang normal. Tetapi kebetulan itu bekerja sebagai operator, dan disebut programmer. Lalu siapa dia, dalam model kita? Hanya elemen dari sistem yang seharusnya dia kelola. Siapa yang kemudian mengelola dan mengembangkan sistem? Tidak ada, sampai yang lain datang dan melihat ada yang salah di sini.
Ini terjadi setiap saat dengan para pemimpin, terutama dengan tingkat terendah, seperti pemimpin tim, manajer lokasi, administrator sistem kepala, dll. Posisi mereka adalah formalitas, mereka tidak mengelola apa pun dan tidak mengembangkan apa pun, mereka bekerja seperti orang lain, mereka hanya memiliki sedikit lebih banyak tanggung jawab, seperti pergi ke RAM dan menyediakan lembar waktu.
Baik pemimpin maupun pemimpin lainnya tidak memiliki pengaruh pada sistem mereka. Jangan mengelola, jangan mengembangkan, jangan merespons. Sistem tidak bergantung pada mereka.
Gurita
Tetapi ini adalah kasus yang sangat berbeda. Pemrogram seperti itu, meskipun tidak terlibat dalam pemrograman, adalah elemen sistem penting yang unik. Misalnya, dia sendiri yang tahu cara menghitung biaya dan menyesuaikannya sesuai dengan strategi perpajakan.
Sebenarnya, ini adalah operator yang sama, hanya lebih maju, menyadari nilainya dan berhasil menjualnya. Programmer seperti itu mengklaim bahwa hanya dia yang tahu bagaimana membuat penyesuaian untuk mendaftarkan entri sehingga "tidak ada yang terbang." Hanya dia yang bisa mengoreksi minus di belakang sehingga subconto tidak bubar. Anda dapat melanjutkan daftar sendiri.
Programmer seperti itu adalah bagian integral dari sistem, bottleneck-nya, pelengkap yang tidak bisa dilenyapkan. Tanpanya, akan ada krisis, dan semua orang, termasuk dirinya sendiri, memahami ini - semuanya bergantung padanya. Dia membuat keputusan tentang pelaksanaan operasi yang kompleks, pada penyelesaian masalah yang kompleks, seperti kesalahan saat mengunduh laporan, dll.
Ada lebih banyak manajer jenis ini daripada programmer. Mereka secara artifisial dan sengaja menciptakan kondisi di mana sistem tidak dapat ada tanpanya bahkan untuk satu hari (ini dapat dilihat dengan jelas ketika mereka pergi berlibur). Mereka mengoordinasikan segalanya, memeriksa semuanya, terutama apa yang disediakan "lantai atas", membuat keputusan pada setiap contoh proses (misalnya, pesanan pelanggan), pergi ke semua rapat.
Ketika mereka diberitahu bahwa mereka perlu didelegasikan, mereka merujuk pada pekerjaan - tidak ada waktu untuk duduk dan berpikir, menulis instruksi dan menyerahkan semuanya. Secara umum, ini adalah alasan favorit mereka - pekerjaan yang mereka buat secara artifisial. Dan lebih multitasking.
Situasi kadang-kadang terlihat konyol, terutama ketika manajer yang lebih tinggi berubah dan mulai menanyakan elemen kunci kami - apa yang Anda lakukan? Dan yang paling penting - mengapa? Jawabannya biasanya - "diterima begitu", atau, jika ia berhasil memperbaiki ketidaktergantungannya dalam standar perusahaan, "maka seharusnya begitu." Siapa yang menerima, ketika diterima, mengapa diterima - tidak ada jawaban, atau tidak dapat diucapkan, karena "Aku memikirkan omong kosong yang tidak berarti ini" terdengar begitu-begitu.
Baik programmer dan manajer secara bertahap mulai percaya pada eksklusivitas mereka. Kadang-kadang mereka bahkan mulai merasa kasihan pada diri mereka sendiri, dan meminta belas kasihan dari orang lain, atau bahkan mendorong orang ini dari orang-orang yang lebih tinggi untuk meningkatkan pendapatan mereka.
Kebetulan programmer atau manajer kunci seperti itu membuat perubahan pada sistem, mis. bertindak positif padanya. Tapi dia hampir selalu kurang fokus membersihkan dirinya dari sistem. Sebagai contoh, seorang programmer dapat menulis pemrosesan keren untuk pembentukan kumpulan dokumen, yang menyelamatkan orang dari pekerjaan rutin, tetapi hanya programmer yang akan menggunakan pemrosesan ini. Jika mereka memintanya untuk mengajar orang lain, maka dia akan menemukan banyak alasan, seperti "ya di sana untuk menjelaskan lebih lama, biarkan saya melakukannya dengan lebih baik."
Para pemimpin melakukan hal yang sama, mempertajam sistem untuk diri mereka sendiri. Sebagai contoh, ada seorang direktur penjualan yang membuat kondisi: berikan saya persentase dari penjualan seluruh departemen, dan saya akan membagikan premi sesuka saya. Anda mengerti bahwa bagi orang-orang penjualan itu menjadi motif utama dalam bekerja untuk pemimpin seperti itu - bukan "untuk menjual lebih banyak", tetapi "untuk lebih menyukai". Manajer tidak akan dapat menjelaskan algoritma distribusi, karena algoritma ini tidak ada.
Akibatnya, untuk programmer, untuk manajer, hasilnya adalah satu: sistem tidak dapat ada atau berkembang tanpanya.
Sarung tangan
Ada programmer yang mengubah sistem seperti sarung tangan. Mereka tidak benar-benar tahu cara memprogram, membawa implementasi ke pikiran, memecahkan masalah kecil dan besar pengguna, dan menguntungkan perusahaan.
Dalam situasi krisis apa pun, ketika ada lebih banyak kerugian daripada kebaikan dari sistem, mereka mengucapkan: sudah waktunya untuk beralih ke sistem lain.
Untungnya, sekarang tidak ada masalah dengan ini, terutama mengingat pencampuran relung di lini produk, 1C yang sama. Anda dapat beralih dari UT 10.3 ke soft starter, lalu ke KA 1, lalu ke KP 3.0, lalu ke KA 2, lalu ke ERP, lalu meludahi semuanya dan mengimplementasikan UNF, lalu beberapa jenis penyimpangan seperti USHP (jika industri memungkinkan), kemudian, secara mengejutkan, kembali ke SCP. Setiap transisi adalah minimal satu tahun. Hitung sendiri berapa banyak Anda bisa bertahan pada strategi seperti itu. Sudahkah Anda bertemu programmer seperti itu? Saya telah bertemu
Seperti apa rupa pemimpin yang serupa? Dia tanpa henti mengubah metodologi, pendekatan dasar untuk manajemen. Hari ini dia menetapkan rencana selama satu bulan, besok dia menetapkan rencana selama satu tahun, kemudian beralih ke Agile, lalu ke TOS, lalu ke Lean, lalu ke 4-4-5, lalu ke penganggaran, lalu ke model yang bebas anggaran. Ini tidak buruk jika kepala mengetahui semua teknik ini, setidaknya Anda bisa mempraktikkan aplikasi mereka.
Tapi biasanya semuanya lebih biasa - pemimpin seperti itu menyelesaikan semua masalah dengan restrukturisasi. Dia membuat dua dari satu departemen, kemudian sepuluh, lalu satu lagi, kemudian dia merekrut departemen baru dari orang-orang baru, kemudian membatalkan dan menempatkan mereka ke dalam departemen lama, menciptakan posting baru dan menulis instruksi, proses dan standar, atau dengan cara yang sangat kekanak-kanakan - mengubah divisi ke divisi, divisi untuk departemen, departemen untuk tim, tim untuk distrik, dll.
Inti dari pendekatan baik untuk programmer dan manajer adalah sama: sementara perubahan skala besar sedang berlangsung, tidak ada yang akan sampai ke bagian bawah hasil. Dan jika Anda sampai ke bawah, Anda selalu dapat otmazatsya: kami sedang dalam perubahan besar, sekarang tidak mungkin untuk menjawab pertanyaan Anda, kembali dalam sebulan, atau mencari jawabannya sendiri.
Dampak pada sistem ini menakutkan dalam skala, tetapi tidak berarti dalam hasil dan efektivitasnya. Ini hanya perubahan demi perubahan, hanya pada skala kolosal.
Yang sangat buruk adalah bahwa orang lain terbiasa dengan perilaku seperti itu, dan lambat laun hanya lupa bahwa perubahan ini memiliki permulaan dan harus ada akhirnya. Mereka lupa rantai perubahan, sistem atau metodologi mana yang telah berubah, dan mengapa. Akibatnya, setelah beberapa saat Anda dapat mengulangi seluruh rentang perubahan lagi, dan tidak ada yang akan memperhatikan. Dalam praktiknya, saya mengamati gambar seperti itu, dan menghitung frekuensi siklus - 4 tahun.
Tentu saja, tidak perlu berbicara tentang manfaat apa pun untuk perusahaan dari seorang programmer dan manajer.
Plyushkin
Plyushkin adalah karakter "Dead Souls" Gogol, seorang tentara bayaran kecil yang serakah yang menyeret dan menyimpan semua yang dia temukan, sampai ke bagian-bagiannya.
Pemrogram Plyushkin seperti itu menyukai semua jenis repositori solusi dan kode, seperti git, tetapi mereka digunakan untuk tujuan lain. Alih-alih mencari solusi untuk masalah mereka di sana, mereka dengan bodoh mengunduh segala sesuatu yang memiliki kapasitas disk atau uang yang cukup (untuk solusi berbayar). Mereka disimpan dalam folder yang rapi, disortir, kadang-kadang mereka mencoba membangunnya ke dalam sistem mereka untuk ditampilkan kepada pengguna atau direktur, menyamar sebagai milik mereka dan dengan demikian membenarkan keberadaan mereka.
Mereka sendiri tidak benar-benar tahu bagaimana melakukan sesuatu, jadi menggunakan hal-hal kecil orang lain untuk mereka adalah satu-satunya cara untuk bertahan dalam profesi. Untuk perubahan serius, mereka tidak memiliki kekuatan, kompetensi, dan keberanian.
Anda dapat mengenali Plyushkins dengan melihat antarmuka sistem mereka - itu akan penuh dengan ikon dari berbagai add-on, yang artinya tidak akan jelas bagi siapa pun. Semua jenis panel fungsi, menduplikasi pohon metadata, menyortir tabel universal, mengelola pertukaran dalam database yang tidak menggunakan pertukaran, banyak laporan, bahkan untuk sistem lain, dll.
Eksekutif Plyushkina berperilaku serupa. Mereka membaca blog, artikel, segala macam kelompok di jejaring sosial tentang cara membuat perubahan yang bermanfaat dengan sedikit usaha. Karena sifat tidak sistematis dalam pemilihan metode, pemahaman tentang masalah departemen mereka dan implementasinya sendiri, mereka biasanya mendapatkan omong kosong.
Misalnya, Plyushkin akan menonton di TV bahwa gubernur muda yang baru ini mengadakan pertemuan sambil berdiri, mengatakan bahwa ini meningkatkan efisiensi - dan hanya itu, nikmatilah, bawahan. Sebelumnya, duduk di stupa, mereka mendorong air, sekarang Anda akan berdiri. Atau dia akan membaca praktik terbaik lainnya bahwa semua karyawan harus menulis laporan harian dengan tangan, mereka mengatakan ini bukan copy-paste komputer, tetapi kata-kata nyata, sepenuh hati - dan di sini, esai harian, minus satu jam dari waktu kerja.
Pemrogram dan manajer seperti itu memiliki dampak kecil, dan sebagian besar berbahaya, pada sistem. isi dengan sampah dan kebisingan.
Escort kekasih
Ada programmer yang hampir selalu, untuk solusi tugas yang kurang lebih kompleks, disebut agen outsourcing. Proyek memperkenalkan sistem, meluncurkan subsistem baru, mengintegrasikan dengan situs, mengembangkan dokumen baru, menambahkan alat peraga - programmer eksternal (s) dipanggil untuk semuanya.
Ada pemimpin yang sama, saya pribadi melihat. Perlu sistem motivasi? Optimalisasi Proses Bisnis? Pengembangan strategi? Analisis sistem manajemen? Hanya ada satu jawaban - kami mencari spesialis eksternal.
Dampaknya pada sistem, tetapi hampir selalu bengkok dan berbahaya, karena konsultan bekerja dengan hanya satu bagian dari mosaik.
Misalnya, itu membuat sistem motivasi untuk proses bengkok. Atau menulis strategi, tidak mempertimbangkan motivasi pelaksanaannya. Atau, asli kami - apakah otomatisasi snapshot proses, yang kehilangan relevansi satu tahun sebelum akhir proyek, meskipun ini tidak penting, karena tujuan dan motivasi juga tidak diperhitungkan.
Akibatnya, selalu bengkok, dengan bias di beberapa arah. Baik kepala dan programmer. Tetapi yang utama adalah bahwa peran mereka sendiri dalam proses pengembangan ini adalah nol.
Ditoleransi
Ini adalah tipe programmer yang paling umum - mereka yang melakukan semua yang diperintahkan. Karenanya, mereka membuat perubahan yang tidak berarti pada sistem, memberikannya, sepotong demi sepotong, untuk mewujudkan ambisi tidak sehat orang lain. Inilah mayoritas dari kita, apa yang bisa saya katakan.
Dan para pemimpin seperti itu - dalam jumlah besar. Ini semua adalah mereka yang membiarkan spesialis otomatisasi eksternal, pelaksana ISO 9001, birokrat internal semua garis yang diharuskan untuk memberikan banyak laporan, selembar kertas, melalui jutaan persetujuan, mempelajari lagu dan menyiapkan adegan untuk acara perusahaan, dll. Secara umum, yang membuka bagian dari sistemnya untuk serangan eksternal, seperti teras untuk para tunawisma, dan sekarang tidak tahu bagaimana mengusir mereka keluar dari sana, agar tidak mencium baunya.
Akibatnya, baik sistem informasi dan departemen atau sistem manajemen perusahaan menjadi seperti Frankenstein yang terhambat, tidak dapat mengambil langkah.
Orang seperti itu adalah hama, karena dengan kedok "dan I Che, mereka mengatakan kepada saya untuk" menghancurkan sistem mereka.
Normal
Ada programmer normal di dunia yang memutuskan sendiri apa yang harus dilakukan dengan sistem, mengetahui tujuan yang dihadapinya. Jika tujuan ditetapkan kurva, maka mereka tidak malu, dan menyesuaikannya, dan semua orang berhasil menyetujuinya.
Ada manajer normal yang secara konstan terlibat dalam meningkatkan efisiensi sistem mereka, dan mereka melakukannya dengan penuh pertimbangan, konsisten, dan profesional.
Tidak satu pun dari keduanya masuk ke dalam sistem, kecuali dalam kasus yang sangat darurat.
Tak satu pun dari mereka mengikat sistem pada diri mereka sendiri, dan kapan saja mereka dapat pergi, dan sistem akan terus bekerja, meskipun itu akan berhenti berkembang.Satu-satunya masalah adalah bahwa tidak ada satu atau yang lain ada.Masalah utama
, , , , . , , , , . .
, , .
, , . , , , .
, , .
, , . , , .
– , .
Solusi
– . , .
, . , - .
, – .
, , , , .
, , . ..
– , , -.
ERP, 10 % , . , . , , .
: , , , , .
, – , . – , , .
– , – . , HR, . , , , – .
, , – . . , , . , , . , , « », « », «» , .
. , , , . , , . , – , , .
, , , , , .
?
, – « ». , , , ?
. – , , .
? , .
, , ? , .
? , .
, , ? , .
Bisakah Anda menganalisis, mengingat banyak parameter sistem dan memahami kerentanannya? Ok, jadilah analis.Semua peran ini bukan kepemimpinan. Itu hanya peran, pekerjaan seperti itu.Jika Anda memberi tahu orang apa yang harus dilakukan, itu tidak berarti Anda yang bertanggung jawab. Dispatcher juga memberi tahu pengemudi taksi ke mana harus pergi. Dia tidak berbicara, dia berbicara. Ia digantikan oleh sistem.Jika Anda tahu cara menginspirasi orang, ini tidak berarti Anda bertanggung jawab. Seseorang hanya perlu menonton film yang tepat untuk menjadi inspirasi, dan Anda bercinta dengannya tidak menyerah dengan motivasi Anda. Dan seseorang di rumah akan sangat terinspirasi di rumah sehingga dia tidak akan tampak cukup.«» , . ? , , .
- , .