Selamat siang Saya ingin menceritakan sebuah kisah pendek yang terjadi pada saya belum lama ini dan terhubung dengan harapan karir dan dengan persepsi yang salah tentang apa yang terjadi dalam kenyataan. Bagaimana majikan bisa menyesatkan atau tidak sadar merusak motivasi tim.
Tiba di kota provinsi dari Moskow, saya akan mendapatkan pekerjaan sebagai kepala departemen TI di beberapa perusahaan. Setelah menyelesaikan pengembangan profesional di Moskow dan semua tahap kerja dari baris pertama ke ketiga, menyadari bahwa saya suka manajemen dan mengelola orang / proses dan saya bisa melakukannya, saya mulai mencari lowongan.
Detail di bawah potongan.
Saya tidak secara khusus terganggu oleh lowongan transformer ketika perusahaan membutuhkan "spesial, reaper, dan gamer" (ini adalah ketika seseorang perlu menyolder papan dan menulis konfigurasi 1C), saya dengan sabar menunggu penawaran yang bagus. Setelah 2 bulan, wakil kepala departemen mendatangi saya dengan proposal yang sulit untuk tidak disetujui. Arahan baru saja muncul, sebuah perusahaan skala federal, menciptakan departemen dukungan dan pengembangan di wilayah ini, rencana-rencana itu muluk dan sepenuhnya konsisten dengan harapan saya. Dimungkinkan untuk membangun tim dan proses dari awal, mengoptimalkan dan mengintegrasikannya ke dalam proses yang ada. Semua orang memanggil posisi dengan fungsi "koordinator / kepala Dukungan Teknis". Ya, saya siap bertempur.
Tujuan Awal:
- Dukungan pada baris pertama dan kedua.
- Pembuatan Basis Pengetahuan
- Membuat dokumentasi pengguna
- Untuk mempelajari proses bisnis untuk implementasi "konsultasi bisnis"
- Untuk menyiapkan aturan untuk interaksi antar unit dalam kerangka metodologi ITIL Service Desk (saya berencana untuk mengambil dari sana hanya proses melewati aplikasi dan insiden + menulis SLA, karena saya tahu bahwa tidak ada yang akan memberikan implementasi yang membosankan dari proses yang diformalkan sepenuhnya, dan itu tidak akan berhasil)
- Pekerjakan staf pendukung.
Pembuatan Dokumentasi
Apa yang saya inginkan: Karena saya harus memelihara sistem informasi yang dibeli, dan saya terbiasa berurusan lebih banyak dengan infrastruktur perangkat keras, saya memutuskan untuk masuk ke dalam hal-hal secara bertahap dan dari sisi yang paling jelas bagi saya - saya meminta aturan proses yang diotomatisasi oleh sistem dan dokumentasi padanya. Dan saya mengalami kejutan pertama - tidak ada dokumentasi untuk sistem yang dibeli untuk "uang". Ada slide yang dibuat sketsa oleh pengembang di atas lutut, bagaimana peran tertentu terlibat dalam proses, dan itu saja. Perusahaan memiliki 4 bulan dukungan kontrak, ketika mereka dapat dihubungi dengan pertanyaan tentang pengoperasian sistem. Tidak ada proyek internal untuk implementasi sistem, tenggat waktu ditentukan oleh kesepakatan dan dokumen excel, yang menunjukkan tanggal untuk implementasi perbaikan tertentu. Ya, setelah perekrutan saya, sistem ditambah selama 5 bulan.
Apa yang terjadi: Dengan setengah dosa, beberapa proses dijelaskan dalam bentuk diagram Visio. Modul sistem yang dijelaskan sebagian. Karena batas waktu, komunikasi dengan pengembang sistem yang dibeli menjadi lebih buruk. Seperti yang saya pahami, dokumentasi itu tidak wajib saat dibeli.
Kesimpulan: Sistem yang belum selesai tidak terdokumentasi dijelaskan dengan buruk tanpa bantuan pengembang. Cobalah untuk membangun proses komunikasi.Pembuatan Basis Pengetahuan
Apa yang saya inginkan: Dukungan pada baris pertama seharusnya mengumpulkan kumpulan pertanyaan tertentu dari pengguna, diasumsikan bahwa manajer sudah memiliki kumpulan ini, setidaknya sebagian. Tetapi setelah negosiasi dengan kepala departemen penjualan, menjadi jelas bahwa tidak ada kumpulan dan prosesnya akan terlihat seperti ini: pengguna memanggil, jika terhubung dengan bagian teknis, kami membantu, jika dengan bagian bisnis, kami menelepon kembali. Karena bagian bisnis dari jawaban sama sekali tidak, pengguna pertama seharusnya tidak terlalu beruntung. Sekali lagi, selama percakapan, saya menyadari bahwa bisnis tidak benar-benar menghargai pengguna baru dan siap untuk mengambil risiko ini.
Untuk memperjelas, dengan sumber-sumber seperti itu gambarnya tampak agak kabur, tetapi saya menganggapnya sebagai tantangan.
Apa yang terjadi: Sebuah dokumen dibuat untuk membahas volume awal konsultasi bisnis. Prosedur untuk bekerja dengan bisnis tidak dapat diatur. Bisnis bisa lupa untuk menjawab pertanyaan baru "bukan dari daftar". Saya harus meminta kembali, tetap memegang kendali. Basis pengetahuan dibuat berdasarkan docuwiki dengan deskripsi masalah, arsitektur sistem, tindakan dasar dari garis dukungan kedua dan administrator. Itu tidak mungkin untuk menggambarkan pengaturan untuk membuat produk baru dalam sistem, karena itu dibuat dalam cara semi-diprogram dan itu perlu untuk menggambarkannya bersama-sama dengan programmer.
Kesimpulan: Menciptakan basis pengetahuan yang mengorbankan loyalitas pelanggan adalah langkah yang salah. Jika bisnis melakukan ini, maka beban tambahan jatuh pada dukungan dalam bentuk alasan untuk cacat dan penahanan klien negatif tambahan.Perekrutan staf
Apa yang saya inginkan: Untuk memilih karyawan, saya pergi ke tim saya secara metodis: Saya memilih daftar kompetensi dan menyusun pertanyaan untuk wawancara telepon tentang kompetensi ini. Pada awalnya, semua pertanyaan memiliki bobot yang sama, dan setelah beberapa wawancara, saya menyadari bahwa semua kandidat sama-sama cocok untuk lowongan tersebut dan dengan kecepatan seperti itu Anda dapat mempekerjakan orang untuk waktu yang lama. Semua kompetensi diberi bobot dan prosesnya menjadi lebih menyenangkan.
Tabel kompetensi baris pertama:
Templat ini dikirim untuk disetujui oleh manajemen, tetapi respons "berlaku-tidak berlaku" tidak kembali.
Saya mengambil orang pertama atas rekomendasi seorang kolega lama tanpa templat (saya bekerja selama seminggu). Bos berikutnya mengambil. Tiga (perempuan) yang tersisa direkrut sebagian dengan partisipasi saya, tetapi tanpa meminta rekomendasi saya dan tidak tertarik pada pendapat. Penerimaan untuk motivasi materi dan anggaran yang belum saya terima.
Apa yang terjadi: Menyenangkan, tetapi tidak sepenuhnya memenuhi persyaratan departemen direkrut, di mana karyawan melakukan pekerjaan yang sangat baik dengan baris pertama, tetapi untuk perendaman yang lebih dalam dalam sistem, proses pelatihan dan transfer pengetahuan yang terstruktur diperlukan. Dengan saya, orang-orang dengan RFP di atas rata-rata pasar kehilangan motivasi tidak berwujud di mata mereka karena proses kerja yang salah.
Kesimpulan: siapkan untuk karyawan termotivasi baru jumlah pekerjaan. Kalau tidak, itu sangat mempengaruhi loyalitas kepada majikan dan sistem. Memahami proses motivasi staf - baik material maupun non-material.Proses kerja
Apa yang saya inginkan: Setelah memulai sistem, kami mulai menghadapi kesulitan pertama: antarmuka lama tampak mengerikan dan bekerja melawan semua konsep yang ramah pengguna. Aliran utama panggilan pergi ke ketidakpuasan dengan antarmuka, dan bukan dengan proses bisnis. Pengguna tidak bisa membuat permintaan. Kesalahan utama segera dibawa ke tim pengembangan yang baru direkrut, tetapi di sini kami menghadapi masalah kedua: tidak ada komunikasi tidak hanya dengan mereka yang mendukung sistem dari luar, tetapi tidak ada prioritas untuk memperbaiki sistem - semua upaya ditujukan untuk menulis yang baru fungsi dan produk, itu tidak mungkin untuk mengalokasikan seseorang untuk menambal kesalahan dasar yang akan mengurangi separuh jumlah panggilan.
Apa yang terjadi: Setelah sekali lagi menunjukkan masalah kepada manajemen, masih memberikan izin untuk melakukan koreksi dan aliran panggilan menurun tiga kali lipat.
Kesimpulan: menetapkan proses penentuan prioritas tugas, membahas urutan interaksi dengan tim pengembangan.Menghadapi masing-masing tugas di atas, saya datang ke manajemen setiap kali dengan saran untuk merampingkan proses dan mencoba mengoordinasikan visi saya dengan visi perusahaan, tetapi saya selalu menemukan pekerjaan manajer (masalah sistem) atau menerima jawaban "sejauh ini" dan "kami tidak ingin memformalkan terlalu banyak ". Saya juga tahu bahwa itu direncanakan untuk memperluas departemen menjadi 5 orang dan melihat bahwa perlu untuk memahami bagaimana proses dukungan dan sumber daya akan dikelola. Saya sudah mulai curiga bahwa pihak berwenang telah mengubah rencana untuk saya karena upaya terus-menerus saya untuk mengimplementasikan perubahan. Saya tidak lagi dipanggil koordinator atau bos, saya tidak berpartisipasi dalam aksi unjuk rasa terkait dengan pengembangan sistem.
Setelah itu, saya memutuskan untuk menyiapkan strategi dan memahami apakah saya melakukannya sama sekali. Karena bos sama sekali tidak berkomunikasi dengan saya dalam hal strategi. Strategi itu langsung diarahkan kepada orang yang unggul di bidang TI di Moskow dan, bagi saya, gambaran pekerjaan saya telah berubah. Kemudian strategi diarahkan dari Moskow ke bos langsung saya dan saya jatuh ke dalam konfrontasi dengan bos lokal.
Kesimpulan: Analisis strategi unit. Tetapkan rencana jangka pendek dan panjang. Diskusikan visi dengan kepemimpinan.Bagian kedua dari "Balet Marleson"
Setelah episode yang dijelaskan di atas, bos langsung praktis berhenti berbicara kepada saya. Dan saya mulai berpikir untuk pergi. Awalnya, saya melihat proyek yang menarik, yang, setelah mengatasi kesulitan tertentu dengan interaksi yang benar dari semua peserta dalam proses, dapat diselesaikan dengan sukses, setelah menerima departemen dukungan yang termotivasi dengan KPI yang tepat dan dengan indikator output yang jelas yang dapat dipahami oleh bisnis. Sekarang, saya melihat bahwa departemen itu jatuh ke dalam rutinitas tanpa benar-benar mengembangkannya. Dua tugas menjadi prioritas - menjawab panggilan dan menjelaskan bug (bukan perbaikan) sistem menggunakan gitlab, yang diperbaiki oleh pengembang.
Cerita lain adalah proses "pengujian", seperti yang disebut manajer, yang juga kami usulkan untuk dilakukan. Tidak ada yang memiliki pemahaman tentang prosedur ini, atau penguji terpisah. Pengujian fungsional "kotak hitam" tanpa indikator kinerja oleh seluruh tim sebelum rilis. Tidak ada metode lain yang digunakan. Staf yang direkrut tidak dapat berpartisipasi secara efektif dalam pengujian karena kurangnya latar belakang di bidang pengembangan dan kurangnya pelatihan. Tanggal rilis selalu gagal atau rilis diluncurkan tanpa pengujian.
Kesimpulan: departemen tidak dapat secara efektif menangani dua proses besar secara paralel. Akan ada dua proses yang terjadi.
Konfrontasi berlanjut. Manajer berhasil membalik semua elemen manajemen yang saya anggap penting:
- visi strategis
- kontrol
- manajemen
- motivasi
Poin-poin ajaib seperti "kesetiaan kepada perusahaan dalam bentuk datang untuk bekerja lebih awal dan pergi kemudian" juga disuarakan.
Setelah akhirnya kehilangan motivasi, saya mengundang bos untuk berbicara tentang posisi saya selanjutnya di perusahaan dan keputusan untuk meninggalkannya, di mana saya diberitahu bahwa departemen dalam bentuk saat ini cocok untuk semua orang dan tidak ada rencana untuk mengembangkan elemen individu. Akibatnya, saya meninggalkan perusahaan, setelah mendapatkan pengalaman praktis dalam mencoba mewujudkan visi saya tentang pekerjaan departemen pendukung.
Apa yang terjadi: pengalaman, pengalaman, dan lagi pengalaman.
Kesimpulan: Kesalahan apa yang saya rekam untuk diri saya sendiri:
- Agar tidak membuang waktu - perbaiki dan koordinasikan rencana sebelumnya
- Tetapkan strategi Anda dengan jelas. Jika ada kelalaian - segera selesaikan masalah
- Tentukan alur kerja yang nyaman untuk Anda sendiri. Temukan kompromi antara motivasi material dan non-material Anda
- Mungkin saya menghabiskan terlalu banyak waktu untuk memahami hal-hal ini. Banyak yang terbaring di permukaan
Saya juga ingin mendengar dari rekan-rekan Anda cerita dan nuansa implementasi, yang, kurang pengalaman, tidak saya perhatikan.