Halo semuanya! Nama saya Lyudmila Makarova, saya seorang manajer pengembangan di UBRD dan sepertiga dari tim saya bersifat universal.
Kenali: Setiap Pemimpin Teknologi memimpikan fungsi silang dalam timnya. Lagipula, itu sangat keren ketika satu orang dapat mengganti tiga, dan bahkan melakukannya secara kualitatif, tanpa menggeser kerangka waktu. Dan, yang terpenting, menghemat sumber daya!
Kedengarannya sangat menggoda, tetapi benarkah demikian? Mari kita coba mencari tahu.
Siapa dia, antisipasi harapan kita?
Istilah "generalis" biasanya dipahami sebagai anggota tim yang menggabungkan lebih dari satu peran, misalnya, seorang analis pengembangan.
Interaksi tim dan hasil pekerjaannya tergantung pada kualitas profesional dan pribadi peserta.
Dengan skill keras, semuanya jelas, tetapi soft skill pantas mendapat perhatian khusus. Mereka membantu menemukan pendekatan kepada karyawan dan mengarahkannya tepat ke tugas di mana ia akan sangat berguna.
Ada banyak artikel tentang semua jenis tipe kepribadian dari perwakilan industri TI. Berdasarkan pengalaman saya, saya akan membagi IT universal menjadi empat kategori:
1. "Universal - Mahakuasa"
Ada di mana-mana. Mereka selalu menunjukkan aktivitas yang hebat, ingin menjadi sorotan, terus-menerus bertanya kepada rekan mereka apakah bantuan mereka diperlukan, kadang-kadang bahkan menjengkelkan. Mereka hanya tertarik pada tugas-tugas penting, partisipasi di mana akan memberikan ruang untuk kreativitas dan dapat menghibur kebanggaan.
Apa yang kuat:
- mampu memecahkan masalah yang kompleks;
- tenggelam dalam masalah, "menggali" dan mencapai hasilnya;
- memiliki pikiran yang ingin tahu.
Tapi:
- labil secara emosional;
- dikelola dengan buruk;
- memiliki sudut pandang mereka sendiri yang tak tergoyahkan, yang sangat sulit untuk diubah;
- sulit untuk menyelesaikan sesuatu. Tugas-tugas mudah merusak kemahakuasaan kebanggaan.
2. "Station wagon - Saya akan mencari tahu dan melakukannya"
Orang-orang seperti itu memiliki cukup manual dan sedikit waktu - dan mereka akan menyelesaikan masalah. Biasanya mereka memiliki latar belakang yang besar di belakang mereka sebagai DevOps. Generalis seperti itu tidak peduli dengan desain dan lebih suka menggunakan metode pengembangan hanya berdasarkan pengalaman mereka sendiri. Mereka dapat dengan mudah memiliki camilan dengan techlide tentang opsi yang dipilih untuk melaksanakan tugas.
Apa yang kuat:
- independen;
- tahan stres;
- kompeten dalam banyak hal;
- terpelajar - selalu ada sesuatu untuk dibicarakan dengan mereka.
Tapi:
- sering melanggar kewajiban;
- cenderung mempersulit hal-hal: mereka menyelesaikan tabel perkalian dengan mengintegrasikan bagian-bagian;
- kualitas pekerjaan rendah, semuanya berubah 2-3 kali;
- mereka terus-menerus mengubah tenggat waktu, karena pada kenyataannya segala sesuatu ternyata tidak sesederhana itu.
3. "Universal - oke, biarkan saya, karena tidak ada orang lain"
Karyawan tersebut berpengalaman dalam beberapa bidang dan memiliki pengalaman yang relevan. Tetapi ia tidak berhasil menjadi seorang profesional di antara mereka, karena ia sering digunakan sebagai penyelamat, menyumbat lubang untuk tugas-tugas saat ini. Lunak, efisien, menganggap dirinya laris, tetapi tidak.
Karyawan ideal yang praktis. Kemungkinan besar, ia memiliki arah yang lebih ia sukai, tetapi karena kaburnya kompetensi, pengembangan tidak terjadi. Akibatnya, seseorang berisiko menjadi tidak diklaim dan terbakar secara emosional.
Apa yang kuat:
- bertanggung jawab;
- fokus pada hasilnya;
- tenang;
- sepenuhnya dikontrol.
Tapi:
- menunjukkan hasil rata-rata karena tingkat kompetensi yang rendah;
- tidak dapat memecahkan masalah yang kompleks dan abstrak.
4. "Universal adalah penguasa keahliannya"
Seseorang dengan latar belakang pengembang yang serius memiliki pemikiran sistemik. Pedantic, menuntut dirinya sendiri dan tim. Tugas apa pun dengan partisipasinya dapat tumbuh hingga tak terbatas, jika Anda tidak mendefinisikan batasan.
Dia sangat mengenal arsitektur, memilih metode implementasi teknis, dengan hati-hati menganalisis pengaruh solusi yang dipilih pada arsitektur saat ini. Sederhana, tidak ambisius.
Apa yang kuat:
- menunjukkan kerja berkualitas tinggi;
- mampu memecahkan masalah apa pun;
- sangat efisien.
Tapi:
- tidak toleran terhadap pendapat orang lain;
- maximalists. Mereka mencoba melakukan segalanya dengan benar, dan ini meningkatkan waktu pengembangan.
Apa yang kita miliki dalam praktik?
Mari kita lihat bagaimana peran dan kompetensi paling sering digabungkan. Sebagai titik awal, mari kita ambil tim pengembangan standar: PO, manajer pengembangan (pakar teknis), analis, pemrogram, penguji. Kami tidak akan mempertimbangkan pemilik produk dan pimpinan teknis. Yang pertama - karena kurangnya kompetensi teknis. Kedua, jika ada masalah dalam tim, ia harus bisa melakukan segalanya.
Pilihan paling umum untuk menggabungkan / menggabungkan / menggabungkan kompetensi adalah pengembang analitik. Juga, analis penguji dan tiga-dalam-satu sangat umum.
Dengan contoh tim saya, saya akan menunjukkan kepada Anda pro dan kontra dari sesama universalis. Ada sepertiga dari mereka di tim saya, dan saya sangat mencintai mereka.
PO menerima tugas mendesak untuk memperkenalkan tarif baru ke dalam produk yang sudah ada. Tim saya memiliki 4 analis. Pada saat itu, satu sedang berlibur, yang lain jatuh sakit, dan sisanya terlibat dalam pelaksanaan tugas strategis. Jika saya menarik mereka keluar, itu pasti akan mengganggu tenggat waktu implementasi. Hanya ada satu jalan keluar: menggunakan "senjata rahasia" - universal dari pengembang-analis, yang memiliki area subjek yang diperlukan. Sebut saja dia Anatoly.
Tipe kepribadiannya adalah
"gerobak - saya akan mencari tahu
dan melakukannya .
" Tentu saja, dia mencoba untuk waktu yang lama untuk menjelaskan bahwa dia memiliki "tumpukan lengkap tugasnya," tetapi dengan keputusan saya yang disengaja dia dikirim untuk menyelesaikan tugas yang mendesak. Dan Anatoly melakukannya! Dia menggelar dan menyelesaikan implementasi tepat waktu, dan pelanggan puas.
Pada pandangan pertama, semuanya berhasil. Tetapi setelah beberapa minggu, persyaratan untuk revisi muncul lagi pada produk ini. Sekarang pengaturan untuk tugas ini ditangani oleh seorang analis "murni". Pada tahap pengujian pengembangan baru, untuk waktu yang lama kami tidak bisa mengerti mengapa kami memiliki kesalahan dalam mengikat tarif baru dan hanya kemudian, setelah melepaskan seluruh kekacauan, kami sampai ke dasar kebenaran. Kami menghabiskan banyak waktu dan melewati tenggat waktu.
Masalahnya adalah bahwa banyak momen tersembunyi dan jebakan yang tersisa hanya di kepala station wagon kami dan tidak dipindahkan ke kertas. Seperti yang dijelaskan Anatoly kemudian, dia sedang terburu-buru. Tetapi pilihan yang paling mungkin adalah bahwa ia menemukan masalah yang sudah ada selama pengembangan dan hanya memotongnya, tanpa mencerminkannya di mana pun.
Ada situasi lain. Sekarang kami hanya memiliki satu penguji, sehingga beberapa tugas harus diuji oleh para analis, termasuk generalis. Karena itu, saya memberikan satu tugas kepada Fedor bersyarat -
"universal - oke, biarkan saya, karena tidak ada orang lain" .
Fedor - "three in one", tetapi pengembang telah dipilih untuk tugas ini. Jadi, Feda hanya perlu menggabungkan analis dan tester.
Persyaratan dikumpulkan, spesifikasi diserahkan kepada pengembangan, saatnya untuk menguji. Fedor tahu sistem yang sedang dikembangkan "seperti punggung tangannya" dan benar-benar mengerjakan persyaratan saat ini. Oleh karena itu, ia tidak repot-repot menulis skrip pengujian, tetapi menguji "bagaimana sistem seharusnya bekerja," dan kemudian meneruskannya kepada pengguna.
Tes selesai, revisi pergi ke prom. Kemudian ternyata bahwa sistem tidak hanya menunda pembayaran ke akun saldo tertentu, tetapi juga memblokir pembayaran dari akun internal yang sangat jarang yang seharusnya tidak terlibat dalam hal ini.
Ini terjadi karena fakta bahwa Fedor tidak melakukan pemeriksaan pada bagaimana "sistem tidak seharusnya bekerja", tidak menyusun rencana pengujian, daftar periksa. Dia memutuskan untuk menghemat waktu dan mengandalkan instingnya sendiri.
Bagaimana kita mengatasi masalah?
Situasi seperti itu mempengaruhi efektivitas tim, kualitas rilis dan kepuasan pelanggan. Oleh karena itu, mereka tidak dapat diabaikan dan dianalisis alasannya.
1. Untuk setiap masalah yang menyebabkan kesulitan, saya meminta Anda untuk mengisi formulir terpadu: peta kesalahan yang memungkinkan Anda untuk mengidentifikasi tahap di mana "drawdown" terjadi:
2. Setelah mengidentifikasi hambatan, dengan setiap karyawan yang memengaruhi masalah tersebut, sesi brainstorming "Apa yang harus diubah?" (kami tidak mempertimbangkan kasus khusus dalam retro), sebagai akibatnya tindakan tertentu (untuk setiap jenis kepribadian) dilahirkan dengan garis waktu.
3. Kami memperkenalkan aturan interaksi dalam tim. Sebagai contoh, kami sepakat untuk mencatat semua informasi tentang kemajuan tugas dalam sistem manajemen proyek. Saat mengubah / mengidentifikasi artefak selama proses pengembangan, Anda perlu menampilkan ini di basis pengetahuan dan versi final TOR.
4. Kontrol mulai dilakukan pada setiap tahap (perhatian khusus diberikan ke tahap bermasalah di masa lalu) dan secara otomatis berdasarkan pada hasil tugas berikutnya.
5. Jika hasil dari tugas selanjutnya tidak berubah, maka saya tidak menaruh pertanyaan pada peran tersebut yang dengannya ia mengatasi dengan buruk. Saya mencoba mengevaluasi kemampuan dan keinginannya untuk mengembangkan kompetensi dalam peran ini. Jika saya tidak menemukan jawaban, saya meninggalkan dia dalam peran yang lebih dekat dengannya.
Apa hasilnya?
Proses pengembangan menjadi lebih transparan. Faktor BUS menurun. Anggota tim, mengerjakan kesalahan, menjadi lebih termotivasi, meningkatkan karma mereka. Kami secara bertahap meningkatkan kualitas rilis kami.
Kesimpulan
Karyawan Universal memiliki pro dan kontra mereka.
Keuntungan:- Anda dapat menutup tugas kendur setiap saat atau menyelesaikan bug mendesak dalam waktu singkat;
- pendekatan terpadu untuk memecahkan masalah: pelaku melihat dari sisi semua peran;
- generalis dapat melakukan hampir semuanya dengan sama baiknya.
Kekurangan:- Faktor BUS tumbuh;
- kompetensi inti yang melekat dalam peran tersebut terkikis. Karena itu, kualitas pekerjaan berkurang;
- kemungkinan pergeseran dalam hal meningkat, karena tidak ada kontrol di setiap tahap. Ada juga risiko menumbuhkan "bintang": karyawan yakin bahwa ia lebih tahu bahwa ia adalah seorang profesional;
- risiko profesional kelelahan meningkat;
- Banyak informasi penting tentang proyek hanya dapat tetap "di kepala" karyawan.
Seperti yang Anda lihat, ada lebih banyak kekurangan. Oleh karena itu, saya menggunakan universal hanya jika tidak ada sumber daya yang cukup, dan tugas itu cukup mendesak. Atau seseorang memiliki kompetensi yang tidak dimiliki orang lain, dan kualitas dipertaruhkan.
Jika dalam pekerjaan bersama pada aturan aturan distribusi peran diamati, maka kualitas kerja tumbuh. Kita melihat masalah dari sudut yang berbeda, mata kita tidak kabur, pikiran segar selalu muncul. Selain itu, setiap anggota tim memiliki semua peluang untuk pertumbuhan profesional dan perluasan kompetensi mereka.
Saya percaya bahwa hal yang paling penting adalah merasa terlibat dalam proses, untuk terlibat dalam pekerjaan Anda, secara bertahap meningkatkan luasnya kompetensi Anda. Namun demikian, gerbong dalam sebuah tim bermanfaat: yang utama adalah memastikan bahwa mereka secara efektif menggabungkan peran yang berbeda.
Saya berharap setiap orang tim yang mengatur diri sendiri dari "tuan universal kerajinan mereka"!