Banyak yang telah dikatakan tentang mengelola orang secara keseluruhan (menurut banyak orang, lebih dari cukup). Tentang mengelola programmer, dengan mempertimbangkan spesifik tugas mereka, organisasi kerja dan hubungan internal dalam tim, jauh lebih sedikit. Setiap upaya untuk meringkas dan menganalisis pengalaman Anda dari orang yang telah memasak di lingkungan TI dan sebagai pengembang dan sebagai manajer memiliki nilai khusus bagi mereka yang bersiap untuk pergi dengan cara yang sama dan mencari cara bagaimana menerapkan teori manajemen umum ke realitas programmer.
J. Hank Rainwater, seorang programmer tua-sekolah, adalah salah satu dari orang-orang yang tahu semua tempat menginjak peran pemimpin teknis sia-sia, karena mereka sendiri melayang di dalamnya. Bukunya "
How to Graze Cats " memikat dengan objektivitasnya: ia menggambarkan situasi spesifik yang terkenal bagi semua orang, komponen yang berbeda dan kondisi kerja tim, memahami bahkan solusi teknologi penulis (sayangnya, sudah ketinggalan zaman). Dalam serangkaian artikel pendek, kami berencana untuk menyoroti segala sesuatu yang menurut kami paling berguna dan relevan dalam buku ini - mulai dari tipologi karyawan hingga rekomendasi untuk berkomunikasi dengan tim lain.
Mulailah dengan pertanyaan yang masuk akal: mengapa, sebenarnya, kucing? Penulis sendiri, sebagai penjelasan, merujuk pada kutipan dari Helen Alman, yang menggambar analogi ini dalam bukunya Close to the Machine:
“Salah satu kenalan saya dengan manajer proyek pernah membandingkan proses mengelola pemrogram dengan penggembalaan kucing. Dia ingin mengatakan bahwa anjing-anjing, dengan setia menatap mata, kita sama sekali tidak perlu. Seorang programmer yang baik perlu dihargai bersama dengan semua keanehannya. Di sisi lain, semua programmer yang baik ini perlu dibuat untuk bergerak ke satu arah. ”
Pertama-tama, programmer terkait dengan kucing oleh fakta bahwa tidak satu atau yang lain memiliki kecenderungan bawaan untuk tersesat. Mereka lebih suka berjalan sendiri, dan budaya yang telah berkembang di bidang TI telah lama mendorong jenis perilaku ini (atau, setidaknya, tidak mencegahnya). Oleh karena itu, manajer teknis menghadapi tugas yang sangat sulit: untuk mengatur orang lajang menjadi kelompok yang lebih atau kurang kompak, tanpa melanggar individualitas mereka, kemungkinan besar, Anda harus mengasah keterampilan Anda sendiri dalam bekerja dengan orang-orang.
Rainwater mendefinisikan audiens targetnya sebagai berikut: pendatang baru untuk manajemen (pengembang kemarin yang menerima posisi kepemimpinan), pemimpin tim kecil (hingga sepuluh orang) yang bekerja pada beberapa proyek, dari usaha kecil atau menengah. Untuk skala yang lebih besar, beberapa teknik tidak lagi berfungsi, dan pemimpin teknis yang lebih berpengalaman mungkin sudah belajar banyak untuk diri mereka sendiri. Buku ini dirancang untuk membantu pemimpin dalam periode transisi paling akut dan mempersiapkan perubahan di masa depan.
Jika Anda melihat secara luas, manajer pemula menghadapi dua masalah utama: posisi baru secara fundamental mengubah mekanisme interaksinya, pertama, dengan orang-orang, dan kedua, dengan proses. Kita akan membicarakan yang kedua secara rinci nanti, tetapi satu kesalahan umum harus segera disebutkan.
Sangat banyak yang tidak dapat menerima bahwa mereka harus menyerahkan sebagian tugas mereka terkait penulisan kode, dan semakin kuat programmer, semakin kuat perasaan protes ini. Situasi ini diperburuk oleh rasa tanggung jawab baru untuk semua kode yang dihasilkan tim. Akibatnya, alih-alih mendistribusikan kembali waktu dan menghabiskan waktu berjam-jam untuk pekerjaan administrasi, kepala langsung pergi ke kekhawatiran tentang sisi teknis proyek - dia melakukan semua ulasan sendiri, dengan cermat memeriksa desain, atau bahkan menulis ulang fragmen yang tidak berhasil. Yang paling gigih mengabaikan semua tanggung jawab lain yang tidak terkait langsung dengan kode, dan ini berakhir dengan bencana. Yang lebih waras berubah menjadi manusia serigala: pada siang hari sang pemimpin, pada malam hari sang programmer, dan ini berakhir dengan kelelahan.
Untuk alasan ini, hal pertama yang harus dilakukan oleh seorang pemimpin teknis adalah mengenali dan menerima perubahan struktur pekerjaan yang tak terhindarkan dan menyesuaikan periode “putus” yang agak lama. Penulis memperkirakan periode adaptasi sekitar enam bulan - hanya pada saat ini mayoritas terbiasa dengan peran baru dan mulai merasa nyaman di dalamnya. Orang dapat terhibur oleh fakta bahwa definisi "teknis" bukanlah ungkapan kosong: orang yang memimpin pengembang tidak mampu sepenuhnya beralih dari bekerja dengan teknologi, sehingga tidak perlu takut bahwa kegiatan manajemen akan menggantikannya.
Sekarang mari kita beralih ke sumber perubahan kedua - bekerja dengan orang-orang. Dalam posisi kepemimpinan, seorang programmer tidak hanya harus bergaul dengan anggota tim, tetapi, secara kasar, menggunakannya sebagai sumber daya - mengidentifikasi siapa yang mampu melakukan apa dan mengarahkan keterampilan ini ke tempat yang paling mereka butuhkan. Dengan demikian, tugas tersebut terbagi menjadi dua bagian: Anda harus dapat memahami orang dan dapat berkomunikasi dengan mereka.
Untuk membantu pembaca dengan paragraf pertama, Rainwater menawarkan klasifikasi "trah" kucing IT, yang ia bangun berdasarkan pengalaman dan pengamatannya sendiri. Daftar trahnya merangkum jenis-jenis pengembang yang terjadi secara teratur dengan fitur, kekuatan, dan kelemahan yang jelas. Seperti yang lain, klasifikasi ini tidak boleh dianggap sebagai standar absolut - di alam liar, jenis sering dicampur dan bersilangan, lebih dan kurang diucapkan. Namun, ini adalah titik awal yang berguna untuk menganalisis karakteristik intelektual dan pribadi programmer mereka.
Penulis membagi breed menjadi tiga kelompok: umum (paling sering ditangkap), jarang (ditangkap sesekali) dan mongrels (dalam bentuk aslinya membawa nilai lebih rendah dari massa total).
Keturunan umum
ArsitekFavorit sebagian besar manajer. Ini berfokus pada struktur umum kode, mulai dari analisis dan konstruksi abstrak hingga implementasi solusi khusus untuk mereka dalam kode. Kekuatan - itu menghasilkan ide-ide bagus, kadang-kadang bisa memimpin proyek sendiri, dari konsep ke bentuk akhir (meskipun beberapa individu kehilangan minat setelah struktur umum diuraikan dan memberikan pekerjaan "kerajinan" kepada pengembang tingkat bawah). Kelemahan - seringkali menghasilkan kode yang membingungkan dan tidak jelas dengan desain aneh yang hanya mematuhi pemiliknya dan sangat sulit untuk memberikan dukungan eksternal.
KonstruktivisDia mengambil kesenangan tulus dari proses pemrograman itu sendiri, berusaha untuk hasil yang bagus. Perencanaan strategis biasanya acuh tak acuh, kode ditulis pada firasat, tidak terlalu memikirkan logika umum. Pada jarak pendek, ini tidak banyak merugikan, dan Anda dapat mengandalkan kualitas pekerjaan konstruktivis. Ketika proyek tumbuh, kurangnya logika internal biasanya mulai mempengaruhi dan keputusan "tambalan" digunakan - kita ingat bahwa konstruktivis sangat fokus pada hasilnya. Bekerja sangat baik bersama dengan seorang arsitek. Dokumen enggan ("semuanya jelas"), tetapi dengan kegigihan karena kepala - cukup nyenyak.
ArtisSaya juga tahu kegembiraan menulis kode, tetapi elemennya adalah mencari solusi elegan yang tak terduga untuk menerapkan persyaratan yang diberikan. Dengan logika dan organisasi, sebagai suatu peraturan, tidak ada masalah. Kerugian utama adalah kecintaan yang berlebihan pada seni dan eksperimen, yang mendorong untuk melakukan tugas-tugas sederhana dan mengganggu tenggat waktu. Ini memiliki beberapa kesamaan dengan kedua arsitek dan konstruktivis, tetapi biasanya menonjol dengan gaya pemrograman individu yang cerah.
InsinyurMempertimbangkan pengembangan perangkat lunak sebagai analog virtual dari perakitan perangkat keras dengan semua konsekuensi berikutnya. Dia sangat suka menyesuaikan satu dengan yang lain, untuk merakit modul yang berbeda menjadi struktur yang kompleks sehingga semuanya berfungsi, untuk menemukan tempat untuk solusi dari pihak ketiga dalam sistem yang dibangun. Keterampilan memang bermanfaat, tetapi ada cara untuk membiarkan insinyur terbawa suasana, kompleksitas dapat berubah menjadi tujuan bagi dirinya. Kompleksitas yang berlebihan dan kurangnya fleksibilitas produk adalah dua kerentanan dari trah ini.
IlmuwanBerbeda dengan seniman, ia menganggap pemrograman sebagai ilmu pasti - ia mencoba mengikuti prinsip-prinsip dasar dalam segala hal dan menghindari "lelucon". Sangat bertele-tele, berusaha keras untuk menyempurnakan kode dan mencapai operasi yang benar dalam kondisi apa pun, sering kali merugikan pertimbangan praktis. Seperti seorang insinyur, ia cenderung mempersulit segala sesuatu yang tidak perlu. Tetapi ketika datang ke tugas-tugas yang benar-benar kompleks yang membutuhkan ketelitian dan pengetahuan, ia tidak memiliki harga.
LihachIni menempatkan kecepatan di atas segalanya, termasuk kualitas kode. Mengabaikan hal-hal sepele seperti berkomentar, desain yang benar, mengikuti peraturan yang diterima. Pada pandangan pertama, ini memberikan hasil yang bagus, cukup bekerja, tetapi pengujian mendalam mengungkapkan banyak masalah. Sayangnya, jenis ini dibudidayakan oleh para pemimpin sendiri: pencetak gol paling sering diperoleh dari programmer muda yang ditanamkan dengan prioritas palsu dan yang takut untuk tidak memenuhi harapan.
Trah langka
PenyihirDalam terminologi modern, penyihir biasanya disebut bintang rock. Mengambil tugas dan mengelola yang paling sulit, menemukan cara revolusioner untuk menyelesaikan masalah, melakukan segalanya tepat waktu dan efisien. Bahkan dengan pemeliharaan kodenya, kesulitan khusus biasanya tidak muncul. Secara umum, semuanya tampak luar biasa, tetapi pemimpin teknis perlu membuka matanya dalam dua hal. Pertama, seseorang seharusnya tidak membiarkan ketergantungan berlebihan pada penyihir - seluruh tim, termasuk pemimpin, berisiko berubah menjadi tarian untuk satu karyawan. Kedua, Anda harus siap menghadapi kenyataan bahwa suatu hari penyihir itu akan mengecewakan Anda sama saja - tidak ada yang dapat secara konsisten menghasilkan mukjizat. Kesempatan seperti itu harus diambil dengan tenang dan memiliki rencana cadangan.
MinimalisDia menulis kode fungsional yang mengejutkan dari jumlah yang sangat sederhana. Semuanya terlihat harmonis, dibangun dengan jelas dan tidak diragukan lagi mengumumkan pengangkatannya. Trah ini sangat moody dalam pemilihan tugas dan proyek; minimalis akan bertarung lebih dari yang lain untuk hak untuk menetapkan area penerapan kemampuannya. Titik lemah - pengawalan. Dia berjuang dengan semua kekuatannya untuk membuat perubahan pada kodenya (belum lagi milik orang lain) - dia hanya tidak tertarik mengacaukan detail ketika hal utama dilakukan.
AnalogiIni berbeda dalam pemikiran tertentu, mengimbangi kesulitannya dengan abstraksi dengan cinta analogi. Di pertemuan, sulit untuk menangkap pemikirannya, tetapi ia dengan cepat memahami maksudnya. Sebagai aturan, mereka menulis kode yang bagus dan mudah didukung, tetapi dalam beberapa kasus kesalahpahaman tentang abstraksi dapat memperlambatnya. Juga terjadi bahwa analogi gagal, terutama jika analogis memilih salah satu yang dicintainya dari semua yang ia coba untuk menarik semuanya. Anda dapat menyeimbangkan kekurangan analogis dengan menempatkannya bersama arsitek - keduanya saling membunuh, atau membuat sesuatu yang luar biasa.
StuntmanDia menyukai trik-trik spektakuler dan terus mengejar inovasi teknologi yang menghasilkannya. Faktanya, tidak ada pengembalian nyata dari hobi ini: stuntman tidak dapat berpikir secara pragmatis, nilai aktual dari teknologi ini atau itu untuk produk akhir dan pengguna tetap bersembunyi untuknya. Karyawan ini perlu terus memantau dan mengarahkan antusiasmenya ke tugas-tugas prioritas.
Mutts
Rainwater memilih mongrels ke dalam kategori yang terpisah sebagai kucing dengan beberapa kelemahan, keunggulan dibandingkan kelemahan relatif terhadap kekuatan. Tapi dia tidak menelepon untuk menyingkirkan mereka tanpa melihat. Banyak basteran cukup setuju untuk pelatihan dan secara bertahap dapat dilatih kembali pada ras lain. Di bawah ini kami memberikan perkiraan dan rekomendasi untuk berbagai jenis.
SlobberPenyedia utama ceroboh, kode ceroboh. Seringkali melompat dari gaya ke gaya. Seperti scorcher, ia mengorbankan desain dan kepatuhan terhadap perjanjian yang diadopsi oleh tim, tetapi, tidak seperti scorcher, ia tidak dapat dibenarkan bahkan oleh kecepatan tinggi pekerjaan. Ini adalah kode-nya yang terkadang harus ditulis ulang dari awal - begitu melelahkan dan membutuhkan banyak sumber daya untuk memahaminya.
Kelesuan adalah akut dan kronis. Jika tiba-tiba menyerang karyawan, ini mungkin karena masalah pribadi. Jika ini adalah kondisi yang biasa baginya, perlu dipertimbangkan apakah masuk akal untuk menghabiskan waktu melatih kembali. Kriteria utama di sini adalah keinginan dan kesiapan para jempol untuk melakukan upaya. Si jorok, yang umumnya menikmati pekerjaannya, dengan perhatian dari kepala atau mentor, mungkin direhabilitasi dan belajar metode kerja yang lebih efektif.
RemUntuk waktu yang lama dia tidak dapat mengambil tugas, tidak tahu harus mulai dari mana, mengejar spesifikasi dengan harapan putus asa bahwa mereka akan membawa semacam kejelasan. Karena tidak sulit ditebak, keragu-raguan dari rem berasal dari keraguan diri. Penting untuk bertindak di sini berdasarkan dari mana ketidakpastian ini berasal. Jika seorang pengembang telah gagal secara menyedihkan di masa lalu dan sekarang panik karena takut akan kegagalan, biarkan dia memiliki kesempatan untuk membuktikan dirinya bahkan dalam tugas-tugas kecil dan tidak rumit sehingga rasa takut ini secara bertahap menghilang. Jika masalahnya adalah kurangnya pengalaman, maka dengan waktu dan dukungan tim yang terkenal, semuanya kemungkinan akan kembali normal dengan sendirinya. Jika keragu-raguan seperti itu hanyalah sifat karakter, akan lebih mudah untuk memberi orang miskin model yang akan membantunya memilih gaya dan mulai bekerja.
KekasihKekasih tidak memiliki pengetahuan, tetapi biasanya ada lebih dari cukup motivasi. Spesies basteran ini kemungkinan besar akan membobol pengembang yang baik. Namun, kemajuan mereka harus dipantau secara ketat - untuk menilai kemampuan, untuk mencatat prestasi yang memberi alasan untuk mengirim mereka ke tugas yang lebih bertanggung jawab. Seseorang seharusnya tidak terlalu melebih-lebihkan harapan: banyak yang kelelahan ketika dihadapkan dengan kesulitan atau rutinitas yang tak terhindarkan dalam pekerjaan seorang programmer. Secara umum, amatir memiliki kelebihan mereka - pertama-tama, tampilan segar yang terkenal, tanpa rasa malu, meskipun mungkin melelahkan untuk menunggu sampai mereka menginjak garu dan memahami kebenaran umum.
ProfanTampaknya membosankan. Biasanya, pemimpin baru mewarisi ini dari yang lama, kisah penempatan mereka di tim tetap menjadi misteri. Melakukan sesuatu untuk orang-orang seperti itu sulit - pembangunan membutuhkan perbaikan diri terus-menerus, yang tidak akan mereka tarik. Jika seorang awam sendiri sadar akan levelnya dan tidak dibedakan oleh ambisi yang tidak memadai, Anda dapat mencoba melampirkannya ke departemen pengujian - terkadang kemampuan rendah tidak mencegah orang menemukan bug dengan benar. Mereka yang bahkan tidak menyadari kedekatan mereka lebih baik tidak harus berurusan dengan.
EklektikCampuran nuklir seorang insinyur, seniman yang jorok dan tidak terlalu berbakat. Kode yang dia tulis adalah vinaigrette yang tidak bisa dicerna dari berbagai gaya dan modul. Tidak seperti produk kecerobohan, ini adalah kode dengan klaim bakat - dalam penampilan sepertinya ada sesuatu di dalamnya sampai Anda mencoba menjalankannya. Pertanyaan utama dari orang yang membaca kode eklektik: "Apa maksudnya?" Untuk memperbaiki situasi, Anda harus terlebih dahulu memahami apakah kebingungan ini benar-benar hasil dari beberapa jenis pencarian, atau apakah Anda mencoba dengan sembrono di atas trek. Eklektisme jinak sangat diuntungkan oleh ulasan kode sistematis.
Akhirnya, ada jenis lain yang berbeda dari yang lain - ini adalah
koboi atau serigala. Kebiasaan kucing mencapai dia ke tingkat tertinggi. Dalam keahliannya, seorang koboi, sebagai suatu peraturan, sangat baik (kalau tidak, dia tidak bisa tetap di tempatnya), dalam kerja tim - sama sekali tidak ada harapan. Dia dibedakan oleh tekadnya untuk bermain hanya sesuai dengan aturannya sendiri: untuk mengambil proyek yang menarik baginya, dan tidak lain, untuk menggunakan cara yang dia inginkan, untuk memperhitungkan secara eksklusif dengan rencananya, dan sebagainya. Hanya ada satu cara dengan koboi: sekali dan untuk semua memahami bahwa mereka tidak akan menjadi bagian dari tim, dan memutuskan apakah Anda cukup menghargai mereka untuk bertahan dengan kebiasaan aneh mereka. Secara umum, koboi sangat diperlukan dalam dua kasus: situasi kritis, yang tampaknya tidak ada harapan dan proyek terisolasi yang akan disertai oleh para ahli dari luar.
Jadi, kami telah mendaftarkan keturunan yang paling sering ditemui penulis. Namun, beberapa catatan harus dibuat untuk klasifikasi ini:
- Pemimpin tidak boleh menganggap dirinya sebagai pengecualian terhadap aturan: ia memiliki pengalaman pemrograman, yang berarti bahwa ia sendiri termasuk salah satu ras. Ini adalah keadaan yang penting - pendekatan individualnya dalam menulis kode akan memengaruhi budaya tim secara keseluruhan. Misalnya, dalam kelompok pemimpin minimalis, dokumentasi mungkin tergelincir, karena ia tidak pernah memberinya perhatian yang layak bahkan dalam karyanya sendiri.
- Kami ulangi sekali lagi: tipe tidak selalu murni dan tidak berubah, orang sering berubah menjadi lebih beragam daripada konstruksi teoretis. Sangat mudah untuk menilai siapa yang menjadi ras pada saat-saat ketika fitur individu paling menonjol ditampilkan - dengan awal yang baru dan ketika mendekati batas waktu.
- Jika Anda harus membentuk tim dari awal, ingatlah bahwa ansambel yang paling menang adalah arsitek (pemikiran strategis), konstruktivis (elaborasi detail) dan seniman (coretan kreatif). Tetapi kemungkinan besar, Anda sudah memiliki tim yang memiliki staf, dan ini benar-benar normal - Anda dapat bekerja bersama dalam tim mana pun.
- Tiga kualitas utama yang dibutuhkan untuk bekerja dengan sebagian besar breed adalah kebijaksanaan, kesabaran, dan kemampuan untuk menjadi mentor.
Dengan semua kesenangan dari daftar ini, mungkin tidak segera jelas bagaimana mendapat manfaat darinya dalam pekerjaan sehari-hari. Penulis menawarkan beberapa contoh dengan analisis situasi tertentu yang sering muncul dengan ras tertentu.
Contoh No. 1
Situasi: Anda memiliki kode yang sangat banyak yang perlu ditingkatkan ke kebutuhan perusahaan saat ini, dan pengembang minimalis yang melihatnya untuk pertama kali dalam hidupnya. Pengembang mengklaim bahwa kode harus ditulis ulang dari awal - semuanya terlalu rumit, tetapi Anda tidak dapat melakukannya: banyak sumber daya telah dihabiskan untuk produk. Apa yang harus dilakukan
Solusi: sedikit mengubah tugas. Kejelasan cinta minimalis, memiliki kelemahan untuk bekerja dengan arsitektur - menyuapnya dengan beberapa benda atau fungsi yang tidak terlalu mahal dan jelas cacat, memberikan kebebasan untuk merekonstruksi mereka atas kebijaksanaan Anda di masa depan. Mintalah untuk mempelajari dan mendokumentasikan kode, termasuk untuk tujuan ini. Akibatnya, minimalis akan dipaksa untuk melakukan apa yang dia tolak - untuk mencari tahu kode ajaib untuk beralih ke pelajaran yang lebih menarik.
Contoh No. 2
Situasi: Anda tidak setuju dengan arsitek tentang solusi yang diterapkannya. Tampaknya bagi Anda bahwa beberapa hal tidak dilakukan dengan cara yang optimal, ia tidak melihat masalah.
Solusi: arsitek biasanya memiliki beberapa visi struktur - holistik dan konsisten, tetapi tidak jelas bagi pengamat luar. Jika Anda tidak dapat melihat masalah ini melalui matanya, jangan pimpin perselisihan spekulatif, melainkan atur diskusi yang lebih substantif. Misalkan, minta arsitek untuk menjelaskan secara rinci mekanisme tindakan, idealnya prototipe kerja atau versi demo sederhana. Ini akan dengan cepat mengungkapkan semua kelemahan implementasi, jika ada, atau menunjukkan kesalahan Anda. Demikian pula, jika kode itu tampak terlalu rumit dan monolitik bagi Anda, sarankan untuk memecahnya menjadi komponen - jika ini tidak mempengaruhi sistem, tidak apa-apa.. , , , , .