Karier Manajer TI: Dari Baris Perintah ke Kerja Tim

Dunia IT saat ini tidak seperti industri lainnya - antusias, orang yang kompeten bekerja pada kode aplikasi, game, solusi perusahaan, layanan. Pemrogram dan insinyur, perancang dan penguji, administrator sistem dan DevOps bermodel baru mengubah ide menjadi perangkat lunak yang digunakan jutaan orang. Mereka dengan antusias menulis kode, mengembangkan algoritme, menyiapkan tata letak, dan menggabungkannya menjadi mekanisme berguna yang bisa diterapkan. Kami, pengguna Habr, sering berbicara tentang pengembangan, administrasi, teknologi baru, dan bahasa pemrograman, terputus dalam perdebatan sengit tentang keunggulan satu tumpukan di atas yang lain, tetapi lupakan tentang tautan penting dalam perusahaan TI mana pun - manajer proyek dan produk. Namun sementara itu, bukan fakta bahwa besok Anda tidak akan ditawari untuk pindah dari urusan para programmer dan menjadi seorang manajer. Motivasi? Apakah itu sepadan? Plafon? Kebuntuan karier? Cakrawala baru? Mari kita perbaiki.

Manajer TI, menumpuknya ...

Kami menerapkan sistem CRM kami dan oleh karena itu kami tidak hanya memiliki pengalaman mengembangkan manajer kami sendiri (ini terutama hibrida dengan programmer - lebih dekat dengan pemimpin tim) di RegionSoft Developer Studio , tetapi kami juga bertemu dengan manajer proyek TI lainnya (dan bukan IT juga, tapi ini cerita yang berbeda). Selama bertahun-tahun, kami telah mampu mengidentifikasi sejumlah tanda khas manajer dengan "karakter buruk."

Sayangnya, sering terjadi bahwa manajer TI mendapatkan orang dengan pendidikan ekonomi, hukum, dan manajerial yang baik, tetapi tanpa pengetahuan tentang latar belakang teknis. Mereka dapat mencoba, menerapkan teknik psikologis, menghadiri pelatihan dan mengadakan pertemuan yang sangat panjang, tetapi tidak hanya mendapatkan hasil nol, tetapi juga mendapatkan kebencian di perusahaan. Programmer menganggap manajer itu sepatutnya, manajer takut teknologi yang tertanam. Dan ada alasan bagus untuk itu.

• Bekerja tanpa tujuan, rencana, dan tahapan proyek. Situasi seperti itu dapat muncul jika manajer memiliki gagasan yang buruk tentang tahap pengembangan dan proses pembuatan perangkat lunak secara umum, yaitu, pada kenyataannya, sulit baginya untuk merencanakan secara memadai. Kerja yang kacau, melempar dari satu tugas ke tugas yang lain, mengubah persyaratan yang terus-menerus menghabiskan semua anggota tim, menyebabkan PHK dan kelelahan profesional.
  
• Mengubah proyek dengan cepat adalah sifat lain dari manajer yang dibenci. Anda dapat dengan mudah mengenali tipe karyawan ini: setelah mendengar di sebuah konferensi atau mitap lain tentang teknologi baru atau model manajemen yang modis, ia kembali ke perusahaan dengan mata bersinar dan mulai secara aktif mendorong kebaruan pada proyek lama. Selain itu, ini bukan percobaan dengan praktik terbaik, tetapi pencelupan total dan sembrono dalam sesuatu yang baru. Terasa seperti lebih banyak mencelupkan. Ini mengarah pada gangguan jangka waktu proyek dan penurunan tajam dalam kualitas dan kecepatan pembangunan. Jika seorang inovator yang menyedihkan berhasil mendapatkan dukungan dari manajemen puncak - penulisan tidak ada.
  
• Strategi di semua biaya adalah moto manajer proyek TI yang bekerja untuk bonus mereka sendiri, tetapi tidak untuk kebaikan tim. Orang-orang ini siap untuk apa pun demi KPI dan ROI dan mengecualikan risiko, hanya untuk menghindari kehilangan nilai koefisien yang didambakan. Pilihan yang paling berbahaya adalah ketika manajer melobi pengenalan koefisien yang terkait dengan pencapaian "yang tidak diterima" ke dalam matriks indikator - seperti koefisien loyalitas, indikator motivasi internal, dan tingkat interaksi yang diperkirakan dengan kolega. Sebagai aturan, profesional introvert tidak melewati saringan ini dan tetap tanpa bonus. Dan di sana, tanpa motivasi, dan ... tanpa kerja.
  
• Kesalahpahaman prinsip-prinsip pembangunan adalah momok manajer non-teknologi. Tanpa mengetahui kekhasan membuat kode, kecepatan programmer, prinsip pengujian, waktu membawa produk ke produksi, sangat sulit untuk datang ke penyebut bersama dengan R&D dan menjadi penghubung nyata dalam proyek. Manajer seperti itu yang suka menghafal beberapa kata dari topik IT dan mengatakan: "Apakah Anda punya waktu untuk fitur sebelum Jumat?", "Refactor kode untuk bekerja lebih cepat", "Ya, hanya ada dua baris untuk berubah. Mengapa menguji seluruh bangunan? "
  
  
  
  
  Beberapa manajer berpikir bahwa input adalah semacam ide, output adalah yang terbesar di dunia perangkat lunak, dan di tengah adalah keajaiban. Tidak, biasanya ide yang bagus, pengembangan yang panjang, membosankan, rumit dan produk yang didahului oleh pesaing. Dan hanya manajer keren dan pengembang cerdas dari produk ini yang mengarah ke HEBAT :-)
• Pertemuan tanpa akhir adalah cara yang bagus untuk meniru kegiatan tanpa mencapai hasil. Hal utama adalah bahwa harus ada kalender untuk memesan ruang negosiasi (lebih disukai publik), dan manajer itu sendiri dengan pandangan penting mendengarkan keadaan hubungan proyek dan memberikan komentar. Jika Anda mencoba, Anda dapat menyebut ini sebagai tiruan dari Scrum atau Agile. Tetapi kemudian harus ada papan dengan potongan kertas berwarna. Ini adalah manajer-konsultan yang dipelajari.
  
• Klien selalu benar, bahkan ketika dia benar-benar salah. Untuk beberapa alasan, formula ajaib "pelanggan selalu benar" dari ritel dan layanan dimigrasikan, termasuk ke pengembangan. Manajer, dipanggil untuk bekerja di sisi klien, tidak berubah menjadi pengacara kepentingan klien, tetapi menjadi dewa mengangguk yang melakukan tugas-tugas paling delusi dari klien yang ditandai dengan mendesak. Dan, tentu saja, tanpa TK dikompilasi dan ditandatangani.
  
• Mengabaikan aspek pribadi adalah kesalahan yang bisa dilakukan manajer mana pun, termasuk teknisi. Dalam kasus apa pun Anda tidak boleh mengabaikan fakta bahwa Anda bekerja di lingkungan orang - dan karenanya, dalam lingkungan kepribadian, karakter, suasana hati, motivasi. Dan jika Anda mengabaikan fitur-fitur ini di dalam tim, Anda bisa mendapatkan efek bom mini nuklir di dalam tim. Itu menyakitkan semua orang.
  
• Kegagalan untuk menetapkan prioritas mengarah pada gangguan yang tidak merata dalam tenggat waktu proyek, kebingungan dalam pengembangan, kasus-kasus yang terbengkalai, tumpukan simpanan yang belum dirangkai, dan bugtracker yang kewalahan. Pengembangan seperti teknik apa pun tidak tahan kekacauan.
  
• Kontrol total dan manajemen mikro adalah penyakit manajemen yang dapat menyerang semua orang. Tidak ada yang lebih buruk dari seorang manajer. berusaha untuk menggantikan semua orang di tempat kerja dan siap masuk ke setiap tahap perkembangan.
  
• Kurangnya retrospektif adalah cara yang bagus untuk mengurangi motivasi tim dan kualitas pengembangan. Jika karena alasan tertentu manajer menghindari kesalahan menganalisis, pekerjaan yang dilakukan, takut untuk memuji atau menyerukan perubahan kualitatif, ia pasti akan menerima tim yang tidak tahu apa yang bergerak.
  
• Mengabaikan praktik terbaik. Keberhasilan, penemuan, dan keuntungan orang lain kadang-kadang sulit dikenali. Namun, perilaku ini berakibat fatal dalam pekerjaan - jika Anda tidak mempertimbangkan praktik terbaik, Anda dapat tertinggal dari pesaing dan pada dasarnya kehilangan semua keuntungan. Jika manajer takut untuk mengenali yang terbaik dan secara aktif mengimplementasikannya, proyek akan hancur.
  
• Ada aspek lain dari pekerjaan manajer yang mengarah pada konsekuensi negatif - keinginan untuk menciptakan tim yang ramah, bahkan dengan mengorbankan efisiensi dan produktivitas. Dalam mengejar iklim psikologis yang nyaman dalam tim dan sepenuhnya tanpa konflik, manajer mengarahkan proyek ke peringkat "kumpul-kumpul persahabatan", yang baik untuk semua orang, tetapi pekerjaan itu tidak dilakukan. Cepat atau lambat, ini selalu mengarah pada konflik dan krisis manajerial yang mendalam.
  

Tentu saja, semua kualitas ini jarang digabungkan dalam satu manajer, tetapi masing-masing sudah mampu mengguncang proyek dalam perjalanan ke tujuan. Namun demikian, ini bukan utopia - manajer seperti itu ditemukan dalam karya hampir kita semua. Apa jalan keluarnya? Untuk menumbuhkan Babu Yaga di tim Anda dan mentransfer ke manajer programmer terbaik yang mengetahui proyek sebelum setiap karakter kode? Opsi! Tetapi apakah begitu sederhana untuk mentransfer dari seorang programmer atau kursi insinyur ke kursi manajer?

Dari programmer ke manajer - jalan samurai

Jika kita berbicara tentang perubahan karir dari seorang programmer yang baik, sangat baik dan berbakat, maka kita tidak dapat mengatakan tentang keuntungan yang jelas dari tumbuh menjadi manajer. Ada beberapa jalur pengembangan untuk seorang programmer yang telah tumbuh dalam suatu proyek hingga maksimum profesional.

1. Mengubah perusahaan dan mendapatkan tugas-tugas baru dalam kerangka proyek baru adalah yang paling sederhana, tetapi seringkali merupakan hasil yang paling tidak diinginkan untuk semua. Mari kita lupakan sebelum posting lainnya.
   
2. Mengubah proyek di dalam perusahaan Anda dan mengembangkan arah baru adalah pilihan yang bagus, menguntungkan bagi perusahaan dan memotivasi pengembang. Tetapi tidak setiap perusahaan melakukan pengembangan paralel dari beberapa proyek, kesempatan seperti itu mungkin tidak ada.
   
3. Terus tumbuh di tempatnya, menggali optimasi pengembangan, meningkatkan fungsionalitas produk, meningkatkannya melalui refactoring dan penggunaan algoritma dan teknologi baru. Pilihan yang bagus, yang paling sering dipilih oleh programmer terbaik.
   
4. Menjadi seorang manajer - jika programmer menunjukkan fitur manajerial dan jelas siap untuk memikul beban pekerjaan proyek, dan percayakan pengembangannya ke timnya sendiri.
   
5. Menjadi penginjil teknologi - untuk perusahaan yang sangat besar atau untuk produk yang sangat langka dan sangat populer.
   

Pendapat khusus - RegionSoft Developer Studio, pengembang utama, berbicara tentang pengalamannya bekerja dengan manajer dan programmer.

Menurut pendapat saya, programmer dan manajer adalah entitas yang benar-benar berbeda yang secara praktis berlawanan satu sama lain. Saya tidak tahu seorang programmer tunggal yang akan menjadi manajer yang baik. Kepala departemen pengembangan, pemimpin tim - ya, tetapi untuk bekerja termasuk promosi dan bekerja dengan klien - saya tidak tahu itu. Programmer benar-benar sangat pasif dalam hal komunikasi - mereka sering diam, keras kepala, introvert yang keras, singkat, mereka tidak suka ditarik dan mereka sendiri tidak suka bergerak-gerak. Manajer haruslah seorang ekstrovert, suka berkomunikasi, menyelesaikan masalah, merencanakan dan mengambil inisiatif - tentu saja, di samping psikotipe kebanyakan programmer, ini adalah tipe yang berbeda.

Tetapi ada satu fitur penting. Jika seseorang menggabungkan fitur-fitur baik seorang programmer dan manajer, maka dari seorang karyawan seperti itu seorang manajer proyek yang ideal atau bahkan seorang manajer tingkat ahli diperoleh. Tetapi ini sangat jarang.

Seorang manajer tingkat ahli selalu menjadi bintang di tim mana pun, karena ia tahu cara bekerja sebagai "kemajuan" dan tahu materi pelajaran dari dalam. Ini seperti Korolev ketika ia memimpin biro desain untuk mengembangkan roket. Jika dia sendiri tidak meluncurkan dan membangun raket dan pesawat anak-anak ini, dia tidak akan pernah bisa mengendalikan biro desain secara keseluruhan dan tidak akan membuat roket yang mampu menaklukkan ruang.

Seorang manajer membutuhkan kualitas kepemimpinan untuk mengumpulkan tim di sekitarnya dan dapat mengelolanya, menetapkan tujuan, merencanakan untuk mencapai hasil antara, dll. Dan, tentu saja, dalam pengembangan perangkat lunak, dalam bidang teknis ini sangat penting.

Jadi, jika pemrograman adalah segalanya bagi Anda dan jiwa tidak terletak pada pekerjaan manajerial, jangan lanjutkan. Pengembang yang baik dan berbakat akan selalu menemukan poin pertumbuhan dalam bisnis dan proyek favoritnya.

Transisi dari pengembang ke manajer pengembangan adalah pertumbuhan karier dari sudut pandang masyarakat, pemimpin, dan tim. Ini adalah kenaikan gaji, tugas baru dan tanggung jawab baru. Tetapi pengembang tidak selalu siap untuk meninggalkan kode dan memulai tugas baru - jika hanya karena dia lebih suka pemrograman. Posisi ini patut dihormati (dan kenaikan gaji - ya, tuan-tuan, manajer, ini adalah bukti kesetiaan yang hampir patologis terhadap produk dan harganya sangat mahal!), Tapi kami akan berhenti pada situasi yang lebih umum: gaji memberi isyarat, tugas baru menggairahkan dan Anda hampir setuju untuk menjadi manajer, tetapi dari mana harus memulai? Bagaimana memulai jalan ini dan menjadi efektif di atasnya, dan tidak jatuh ke dalam perangkap prinsip Peter ?


Manajer TI hampir selalu orkestra manusia. Tapi apakah dia selalu bermain harmonis?

Apa yang perlu diwujudkan?

Setiap perubahan aktivitas baik di dalam perusahaan maupun di luarnya adalah tekanan tertentu, terkait dengan banyak pertanyaan dan keraguan. Bahkan jika Anda mengetahui proyek tersebut selama bertahun-tahun, Anda masih harus melihatnya dan tim dari sisi lain, beralih ke sisi interaksi baru, menjadi pemimpin rekan kerja Anda, menjadi pemimpin. Penting untuk segera menyadari beberapa poin yang akan membantu untuk berkumpul dan mulai bekerja "dari kaki itu".

• Posisi manajer adalah pertumbuhan bagi programmer, babak baru pengembangan di bidang manajemen. Ketika pengembang telah mencapai hampir semua yang ada dalam kode, ia harus melangkah lebih jauh dan mengelola persis seperti yang diminta oleh proyek. Ketika Anda mengetahui proses pengembangan dan fitur produk dari dalam, Anda dapat banyak berubah dalam manajemen, untuk membuat tim benar-benar kuat. Bonus untuk semua risiko - tantangan baru dan sisi material.
  
• Transisi ke manajer adalah cara untuk mengatasi batas karier yang dicapai. Ini sangat penting bagi para profesional yang ingin berkembang dalam perusahaan mereka, dan tidak berganti pekerjaan. Ini adalah cara untuk menerapkan akumulasi pengetahuan dalam kualitas baru.
  
• Lebih mudah bagi manajer untuk beralih ke pekerjaan bergaji baik di perusahaan lain, karena programmer harus mempelajari kode, gaya pengembangan, berurusan dengan "warisan" yang tidak selalu terbaik dari pendahulunya, dan manajer datang dengan kemampuan untuk mengelola proyek dengan benar, memahami pengembangan, tetapi menghabiskan waktu mengumpulkan banyak kode . Ini awalnya efektif (meskipun bukan fakta bahwa pembongkaran dengan sekelompok dibatalkan!).
  
• Menjadi seorang manajer, Anda harus menghindari manajemen mikro dan berhenti mempelajari fitur pengembangan terkecil, di setiap baris kode - Anda harus memberi tim kesempatan untuk menyelesaikan masalah pembangunan. Namun, sering kali seorang manajer yang telah berkembang dari seorang programmer terus melihat build dan komitmen individu, dan seringkali bahkan terus menulis kode sendiri. namun, cepat atau lambat, volume tugas-tugas manajerial yang serius akan menggantikan peluang seperti itu, oleh karena itu, penting untuk membangun delegasi yang tepat dalam sebuah tim.
  
• Manajer bukanlah birokrat TI dan bukan pejuang di sisi gelap. Ini adalah orang yang mampu menerapkan pengalamannya untuk membuat ide produk hidup, untuk membuat perangkat lunak yang dapat digunakan dan yang dapat bermanfaat.
  

Bagi saya, tidak ada alasan untuk khawatir

• Seorang manajer adalah orang yang bekerja dengan orang-orang, dan ini tidak boleh diabaikan. Pekerjaan baru Anda adalah proses interaksi yang berkelanjutan dengan manajemen, pelanggan dan, tentu saja, tim. Penting untuk memastikan lingkungan kerja yang menguntungkan, untuk belajar bagaimana mengelola orang yang benar-benar berbeda dan pada saat yang sama tidak meluncur ke perusahaan yang bergembira atau, sebaliknya, menjadi rawa-rawa yang dibendung hanya oleh orang-orang yang "perlu dan tenang". Ingat Vysotsky, "ada beberapa kekerasan nyata, dan tidak ada pemimpin"? Adalah perlu untuk tetap dengan cara kekerasan yang baik.
  
• Manajer harus bergerak, tetapi dalam hal apapun berpindah dari tumpukan ke tumpukan, dari teknologi ke teknologi. Kondisi teknis harus diciptakan untuk pekerjaan yang berhasil - khususnya, otomatisasi harus diperkenalkan jika diperlukan.
  

Dengan otomatisasi, Anda dapat melakukannya secara berlebihan. Secara teori. Dalam praktiknya, ada underautomatization abadi.

Dan ya, Anda harus menghadapi gambar ini dalam hidup :-)

Yang utama adalah benar-benar mencintai produk Anda. Terkadang, tentu saja, bertentangan dengan :-)

Jadi, Anda adalah manajernya. Untuk waktu yang lama Anda adalah seorang pengembang, insinyur, belajar banyak dalam proyek ini. Sekarang Anda mendapatkan pengalaman baru, tanggung jawab dan uang dengan imbalan sejumlah besar pekerjaan, banyak tekanan dan kebutuhan untuk membuat keputusan yang sulit. Anda melihat peluang dan dapat memengaruhi pengembangan bisnis.

Apa yang harus diterima?

Ada beberapa hal yang perlu Anda ambil dalam peran manajer: risiko, kemampuan untuk mendengarkan kritik dan menanggapinya, ukuran tanggung jawab baru, kemampuan untuk membuat keputusan yang sulit dan terkadang tidak populer. Harus menjadi pemimpin tim Anda sendiri. Namun, jika Anda telah berkembang menjadi manajer pengembangan, kemungkinan besar Anda sudah menjadi pemimpin informal.

Ketakutan terbesar

Ketakutan utama manajer, yang merupakan pengembang di masa lalu, adalah kehilangan kualifikasi, keterampilan teknis, dan ketinggalan inovasi di tumpukan. Ketakutan ini dibenarkan, tetapi sepenuhnya tergantung pada Anda. Manajer harus berada di ujung tombak teknologi dan memahami semua alat sebanyak mungkin. Untungnya, ada banyak informasi sekarang dan mudah diakses.

Cara belajar cepat

Tapi betapapun kerennya programmer Anda, ketika Anda mulai bekerja sebagai manajer, Anda perlu belajar banyak tentang nuansa dan seluk-beluk pekerjaan. Ada beberapa cara untuk mendapatkan intisari pengalaman orang lain dan mulai dengan cepat.

Anda dapat memilih seorang mentor, Anda dapat mempelajari buku pelajaran dan buku, dan ini adalah keputusan yang tepat. Tapi ini buang-buang waktu. Karena itu, lebih baik belajar - tetapi pertanyaannya adalah di mana. MBA itu panjang, mahal dan, sayangnya, jauh dari yang selalu Anda butuhkan. Karena itu, ada baiknya beralih ke peluang lain untuk mendapatkan intisari pengalaman orang lain.

1. Peluang termurah dan paling memadai adalah untuk menemukan mentor di perusahaan yang akan memungkinkan Anda untuk memasuki kebiasaan baru. Ini mungkin kepala departemen, manajer berpengalaman, atau bahkan CEO, terutama di perusahaan kecil. Karyawan itu, yang mengetahui sisi pekerjaannya, akan segera terbiasa dengannya dan pada awalnya akan mengetahui poin-poin masalah proyek.
   
2. Masuk jauh ke dalam buku, blog, materi, lakukan pendidikan mandiri. Sebuah solusi hebat, tetapi akan memakan banyak waktu dan akan memiliki dasar teoretis. Sebaliknya, ini merupakan tambahan wajib untuk semua metode ini.
   
3. Pergi ke yang lebih tinggi kedua, ke magistrasi, ke kursus yang sulit. Nah, jika Anda punya waktu dan uang ... Bahkan, itu cukup mahal dan tidak selalu efektif - fitur universitas, Anda mengerti: ada kurikulum dan guru gelisah, jadi selain hal-hal yang diperlukan Anda akan mempelajari logika yang berbeda. Namun, jika Anda seorang mahasiswa pascasarjana atau ingin memasuki TI tidak hanya sebagai junior, tetapi sebagai seorang pemuda yang masih pemula, Anda dapat mencoba tangan Anda.
   
4. Dapatkan gelar MBA. Mahal, sulit, menghabiskan banyak waktu, pengusaha daerah tidak mengesankan. Selain itu, ada beberapa program bagus di Rusia. Biasanya, atasan atau atasan hampir siap dari perusahaan besar, di mana ini menambah berat, diputuskan pada MBA. Namun, dalam pengalaman kami, beberapa keterampilan lain dihargai di bidang TI: otak, pengalaman, keterampilan kerja.
   

Tetapi secara umum, semua metode itu baik, terutama jika Anda mencampurnya dengan buku-buku yang masuk akal dan blog para praktisi manajemen TI nyata. Hal utama yang harus diingat adalah bahwa Anda harus menjadi seorang pemimpin, bukan
Seorang birokrat TI.

---

Saluran Telegram langsung kami, BizBreeze . Apa pun tentang CRM dan bisnis, dengan bijak, tanpa copy-paste dan 90% tanpa iklan. Berlangganan.