Halo semua! Nama saya Lyudmila Makarova, saya manajer pengembangan di UBRD dan sepertiga dari tim saya adalah “generalis”.
Akui saja: setiap Pemimpin Teknologi memimpikan lintas fungsi dalam tim mereka. Keren sekali ketika satu orang mampu menggantikan tiga orang, dan bahkan melakukannya secara efisien, tanpa menunda tenggat waktu. Dan yang terpenting, ini menghemat sumber daya!
Kedengarannya sangat menggoda, tapi benarkah demikian? Mari kita coba mencari tahu.
Siapa dia, cikal bakal ekspektasi kita?
Istilah “generalis” biasanya mengacu pada anggota tim yang menggabungkan lebih dari satu peran, misalnya pengembang-analis.
Interaksi tim dan hasil kerjanya bergantung pada kualitas profesional dan pribadi para peserta.
Tentang hard skill semuanya sudah jelas, namun soft skill patut mendapat perhatian khusus. Mereka membantu menemukan pendekatan kepada seorang karyawan dan mengarahkannya ke tugas yang paling berguna baginya.
Ada banyak artikel tentang semua jenis kepribadian di industri TI. Berdasarkan pengalaman saya, saya akan membagi generalis TI menjadi empat kategori:
1. “Universal – Mahakuasa”
Ini ada dimana-mana. Mereka selalu sangat aktif, ingin menjadi pusat perhatian, terus-menerus bertanya kepada rekan-rekannya apakah mereka membutuhkan bantuan, dan terkadang mereka bahkan bisa menyebalkan. Mereka hanya tertarik pada tugas-tugas yang bermakna, partisipasi yang akan memberikan ruang bagi kreativitas dan dapat menghibur harga diri mereka.
Apa kekuatan mereka:
- mampu memecahkan permasalahan yang kompleks;
- menyelami masalah secara mendalam, “menggali” dan mencapai hasil;
- memiliki pikiran yang ingin tahu.
Tetapi:
- labil secara emosional;
- dikelola dengan buruk;
- memiliki sudut pandang yang tidak tergoyahkan, yang sangat sulit diubah;
- Sulit untuk membuat seseorang melakukan hal sederhana. Tugas-tugas mudah melukai ego Yang Mahakuasa.
2. “Universal – Saya akan mencari tahu dan melakukannya”
Orang-orang seperti itu hanya memerlukan panduan dan sedikit waktu - dan mereka akan menyelesaikan masalahnya. Mereka biasanya memiliki latar belakang yang kuat di DevOps. Generalis seperti itu tidak peduli dengan desain dan lebih memilih menggunakan metode pengembangan hanya berdasarkan pengalaman mereka. Mereka dapat dengan mudah berdiskusi dengan pimpinan teknis tentang opsi yang dipilih untuk melaksanakan tugas.
Apa kekuatan mereka:
- mandiri;
- tahan stres;
- kompeten dalam banyak hal;
- terpelajar - selalu ada sesuatu untuk dibicarakan dengan mereka.
Tetapi:
- sering melanggar kewajiban;
- cenderung memperumit segalanya: menyelesaikan tabel perkalian dengan mengintegrasikan per bagian;
- kualitas pekerjaannya rendah, semuanya berfungsi 2-3 kali;
- Mereka terus-menerus mengubah tenggat waktu, karena kenyataannya semuanya tidak sesederhana itu.
3. “Universal – oke, biarkan saya yang melakukannya, karena tidak ada orang lain”
Karyawan tersebut berpengalaman dalam beberapa bidang dan memiliki pengalaman yang relevan. Namun dia gagal menjadi seorang profesional di bidang tersebut, karena dia sering digunakan sebagai penyelamat, menyumbat lubang dalam tugas-tugas saat ini. Lentur, efisien, menganggap dirinya diminati, tetapi sebenarnya tidak.
Seorang karyawan ideal yang praktis. Kemungkinan besar, dia memiliki jurusan yang paling disukainya, namun karena kaburnya kompetensi, pengembangan tidak terjadi. Akibatnya, seseorang berisiko menjadi tidak diklaim dan mengalami kelelahan emosional.
Apa kekuatan mereka:
- bertanggung jawab;
- berdasarkan hasil;
- tenang;
- sepenuhnya terkendali.
Tetapi:
- menunjukkan hasil yang rata-rata karena rendahnya tingkat kompetensi;
- tidak dapat memecahkan permasalahan yang kompleks dan abstrak.
4. “Seseorang yang serba bisa adalah ahli dalam keahliannya”
Seseorang dengan latar belakang serius sebagai pengembang memiliki pemikiran sistem. Bertele-tele, menuntut dirinya sendiri dan timnya. Tugas apa pun yang melibatkannya dapat berkembang tanpa batas jika batasannya tidak ditentukan.
Dia sangat mengenal arsitektur, memilih metode implementasi teknis, menganalisis dengan cermat dampak solusi yang dipilih pada arsitektur saat ini. Sederhana, tidak ambisius.
Apa kekuatan mereka:
- menunjukkan kualitas kerja yang tinggi;
- mampu memecahkan masalah apa pun;
- sangat efisien.
Tetapi:
- tidak toleran terhadap pendapat orang lain;
- maksimalis. Mereka mencoba melakukan segalanya dengan benar, dan ini menambah waktu pengembangan.
Apa yang kita miliki dalam praktiknya?
Mari kita lihat bagaimana peran dan kompetensi paling sering digabungkan. Mari kita ambil tim pengembangan standar sebagai titik awal: PO, manajer pengembangan (pemimpin teknologi), analis, pemrogram, penguji. Kami tidak akan mempertimbangkan pemilik produk dan pimpinan teknis. Yang pertama adalah karena kurangnya kompetensi teknis. Yang kedua, kalau ada masalah di tim, harusnya bisa melakukan semuanya.
Pilihan paling umum untuk menggabungkan/menggabungkan/menggabungkan kompetensi adalah pengembang-analis. Analis pengujian dan “three in one” juga sangat umum.
Dengan menggunakan tim saya sebagai contoh, saya akan menunjukkan pro dan kontra dari rekan-rekan generalis saya. Ada sepertiga dari mereka di tim saya, dan saya sangat mencintai mereka.
PO mendapat tugas mendesak untuk memperkenalkan tarif baru pada produk yang sudah ada. Tim saya memiliki 4 analis. Saat itu ada yang sedang berlibur, ada yang sakit, dan ada yang sedang melaksanakan tugas-tugas strategis. Jika saya mencabutnya, hal itu pasti akan mengganggu tenggat waktu implementasi. Hanya ada satu jalan keluar: menggunakan "senjata rahasia" - seorang pengembang-analis serba bisa yang menguasai bidang subjek yang diperlukan. Sebut saja dia Anatoly.
Tipe kepribadiannya adalah “universal – saya akan mencari tahu dan melakukannya”. Tentu saja, dia mencoba untuk waktu yang lama untuk menjelaskan bahwa dia "memiliki tumpukan tugas yang penuh", tetapi dengan keputusan saya yang berkemauan keras, dia dikirim untuk memecahkan masalah yang mendesak. Dan Anatoly berhasil! Dia melaksanakan pementasan dan menyelesaikan implementasi tepat waktu, dan pelanggan puas.
Pada pandangan pertama, semuanya berhasil. Namun setelah beberapa minggu, persyaratan perbaikan muncul lagi untuk produk ini. Kini perumusan masalah ini dilakukan oleh seorang analis yang “murni”. Pada tahap pengujian perkembangan baru, untuk waktu yang lama kami tidak dapat memahami mengapa kami mengalami kesalahan dalam menghubungkan tarif baru, dan baru setelah itu, setelah mengungkap seluruh kekusutan, barulah kami dapat mengetahui kebenarannya. Kami membuang banyak waktu dan melewatkan tenggat waktu.
Masalahnya adalah banyak momen dan jebakan tersembunyi yang hanya tersisa di kepala station wagon kami dan tidak ditransfer ke kertas. Seperti yang kemudian dijelaskan Anatoly, dia terlalu terburu-buru. Namun pilihan yang paling mungkin adalah dia sudah menemukan masalah selama pengembangan dan mengabaikannya begitu saja tanpa merefleksikannya di mana pun.
Ada situasi lain. Sekarang kami hanya memiliki satu penguji, jadi beberapa tugas harus diuji oleh analis, termasuk generalis. Oleh karena itu, saya memberikan satu tugas kepada Fedor bersyarat - “universal – oke, biarkan aku yang melakukannya, karena tidak ada orang lain”.
Fedor adalah “tiga dalam satu”, tetapi pengembang telah dialokasikan untuk tugas ini. Artinya Fedya hanya perlu menggabungkan seorang analis dan penguji.
Persyaratan sudah dikumpulkan, spesifikasi sudah diserahkan ke pengembangan, saatnya pengujian. Fedor mengetahui bahwa sistem sedang dimodifikasi “dengan sangat cepat” dan telah sepenuhnya memenuhi persyaratan saat ini. Oleh karena itu, ia tidak repot-repot menulis skrip pengujian, melainkan melakukan pengujian tentang “bagaimana seharusnya sistem bekerja”, lalu menyebarkannya kepada pengguna.
Tes selesai, revisi masuk ke produksi. Belakangan ternyata sistem tersebut tidak hanya menangguhkan pembayaran ke rekening saldo tertentu, tetapi juga memblokir pembayaran dari rekening internal yang sangat jarang yang tidak seharusnya berpartisipasi dalam hal ini.
Hal ini terjadi karena Fedor tidak memeriksa bagaimana “sistem seharusnya tidak bekerja”, tidak menyusun rencana pengujian atau daftar periksa. Dia memutuskan untuk menghemat waktu dan mengandalkan instingnya sendiri.
Bagaimana kita menghadapi masalah?
Situasi seperti ini berdampak pada kinerja tim, kualitas rilis, dan kepuasan pelanggan. Oleh karena itu, mereka tidak dapat dibiarkan tanpa perhatian dan analisis penyebabnya.
1. Untuk setiap tugas yang menimbulkan kesulitan, saya meminta Anda mengisi formulir terpadu: peta kesalahan, yang memungkinkan Anda mengidentifikasi tahap di mana “penarikan” terjadi:
2. Setelah mengidentifikasi hambatan, sesi brainstorming diadakan dengan setiap karyawan yang mempengaruhi masalah tersebut: “Apa yang harus diubah?” (kami tidak mempertimbangkan kasus-kasus khusus dalam retrospeksi), sebagai akibatnya lahirlah tindakan-tindakan tertentu (khusus untuk setiap tipe kepribadian) dengan tenggat waktu.
3. Kami telah memperkenalkan aturan untuk interaksi dalam tim. Misalnya, kami sepakat untuk mencatat semua informasi tentang kemajuan suatu tugas dalam sistem manajemen proyek. Ketika artefak diubah/diidentifikasi selama proses pengembangan, hal ini harus tercermin dalam basis pengetahuan dan versi final spesifikasi teknis.
4. Pengendalian mulai dilakukan pada setiap tahapan (perhatian khusus diberikan pada tahapan permasalahan di masa lalu) dan secara otomatis berdasarkan hasil tugas berikutnya.
5. Jika hasil pada tugas berikutnya tidak berubah, maka saya tidak mempertanyakan peran generalis yang dia lakukan dengan buruk. Saya mencoba menilai kemampuan dan keinginannya untuk mengembangkan kompetensi dalam peran ini. Jika saya tidak menemukan respons, saya tinggalkan dia dalam peran yang lebih dekat dengannya.
Apa yang terjadi pada akhirnya?
Proses pembangunan menjadi lebih transparan. Faktor BUS mengalami penurunan. Anggota tim, mengatasi kesalahan, menjadi lebih termotivasi dan meningkatkan karma mereka. Kami secara bertahap meningkatkan kualitas rilis kami.
Temuan
Karyawan generalis memiliki kelebihan dan kekurangannya masing-masing.
Plus:
- Anda dapat menutup tugas yang tertunda kapan saja atau menyelesaikan bug yang mendesak dalam waktu singkat;
- pendekatan terpadu untuk memecahkan suatu masalah: pelaku melihatnya dari sudut pandang semua peran;
- generalis dapat melakukan hampir semua hal dengan sama baiknya.
Kekurangan:
- Faktor BUS meningkat;
- kompetensi inti yang melekat pada peran tersebut terkikis. Oleh karena itu, kualitas pekerjaan menurun;
- kemungkinan pergeseran tenggat waktu meningkat, karena tidak ada kontrol di setiap tahap. Ada juga risiko untuk menumbuhkan “bintang”: karyawan yakin bahwa dia lebih tahu bahwa dia adalah seorang profesional;
- risiko kelelahan profesional meningkat;
- banyak informasi penting tentang proyek yang hanya tersisa “di kepala” karyawan.
Seperti yang Anda lihat, ada lebih banyak kekurangan. Oleh karena itu, saya menggunakan generalis hanya jika sumber daya tidak mencukupi dan tugasnya cukup mendesak. Atau seseorang mempunyai kompetensi yang tidak dimiliki orang lain, namun kualitasnya yang dipertaruhkan.
Jika aturan pembagian peran dipatuhi dalam kerja sama pada suatu tugas, maka kualitas pekerjaan meningkat. Kita melihat permasalahan dari berbagai sudut pandang, pandangan kita tidak kabur, pikiran-pikiran segar selalu muncul. Pada saat yang sama, setiap anggota tim memiliki setiap kesempatan untuk pertumbuhan profesional dan perluasan kompetensi mereka.
Saya percaya bahwa hal yang paling penting adalah merasa terlibat dalam proses, melakukan pekerjaan Anda, dan secara bertahap meningkatkan kompetensi Anda. Namun, generalis dalam sebuah tim membawa manfaat: hal utama adalah memastikan bahwa mereka menggabungkan peran yang berbeda secara efektif.
Saya berharap setiap orang memiliki tim yang mengatur dirinya sendiri yang terdiri dari “ahli universal dalam keahliannya”!
Sumber: www.habr.com