Dalam artikel ini saya ingin berbagi sedikit pengalaman mengenai membangun tim dalam proyek TI. Saya ingin berbicara tentang hal yang tidak selalu jelas seperti "Piramida Kedewasaan Tim."
Indikator ini bukan istilah ilmiah yang ketat dan tidak memiliki formula perhitungan yang tepat, tetapi prinsipnya dirumuskan dengan baik dalam namanya sendiri.
Tim tipikal dalam proyek-proyek menengah dan besar terdiri dari berbagai peserta: manajer proyek, analis bisnis, pengembang, penguji, dan insinyur operasi. Di setiap arah biasanya ada calon pelanggan - karyawan terkemuka di arah itu, misalnya, insinyur pengembangan terkemuka, insinyur pengujian terkemuka, dan sebagainya.
Jika kita menggambarkan struktur tim semacam itu dalam bentuk piramida dengan refleksi pengalaman karyawan dan pengaruhnya terhadap pengambilan keputusan, maka kita mendapatkan piramida seperti itu:
Kami mendapat semacam "piramida Maslow untuk tim." Tetapi jangan lupa bahwa proyek-proyek TI tidak hanya memiliki insinyur. Misalnya, pengembang dapat dibagi menjadi SMP / Menengah / Senior dan Tuhan tahu caranya, tergantung pada pengalaman kerja dan pengetahuan (atau pada imajinasi majikan).
Kebetulan seseorang memiliki gelar yang rendah, tetapi berdasarkan pengalaman dan pengetahuan orang ini mampu memenuhi peran Arsitek Solusi (tetapi karena keadaannya itu tidak memenuhi peran ini). Jelas, orang-orang tersebut mempengaruhi pengambilan keputusan dalam tim, bahkan tanpa mengambil posisi formal dalam proyek. Dan orang-orang seperti itu perlu diangkat ke langkah kedua dalam piramida kita. Penting bahwa tidak ada lebih banyak orang di level kedua daripada di level ketiga.
Anda dapat menetapkan “manna” dalam jumlah tertentu untuk setiap anggota tim, tergantung pada pengalaman dan pengaruh pada pengambilan keputusan. Misalnya, anggota tim peringkat-dan-file akan menerima 1 poin, arahan, dan manajer 2 poin.
Bayangkan bahwa kita memiliki tim yang terdiri dari 15 orang, maka sebuah piramida khas akan dianggap entah bagaimana seperti ini:
1 :
Project Manager + Technical Lead = 4 pts
2 :
2x Stream Leads + 2x Senior Engineer = 8 pts
3 :
9x Middle and Junuor Engineers = 9 ptsDan kita mendapatkan piramida seperti itu:
Nah, Anda berkata, ini persis jalan atau tidak di proyek kami dan semuanya baik-baik saja dengan kami. Dan apa hasil praktis dari ini?
Mengevaluasi tim yang menggunakan metode ini memungkinkan Anda untuk memahami dua hal: seberapa mudah dikelola (stabil) tim yang ada dan betapa anehnya kenyamanan setiap orang untuk bekerja dalam tim semacam itu.
Faktanya, yang lebih penting, apa yang terjadi ketika piramida kematangan tim menjadi terbalik. Atau ketika menjadi datar, sejajar, atau yang lainnya. Dan ini adalah skenario yang sangat buruk.
Piramida yang benar sangat stabil, tetapi yang terbalik tidak. Anda dapat mengingat percobaan berbahaya dengan koloni "White Swan" di mana beberapa otoritas kriminal duduk dan bagaimana itu berakhir bagi mereka.
Dan jika Anda tidak menyimpang dari sektor TI, maka Anda dapat membayangkan dua situasi nyata:
- mereka mengusulkan untuk membuat manajer proyek yang efektif menjadi murah dan ceria - merekrut 30 "orang India" dan mengajukan proyek dalam sebulan, bukannya enam bulan;
- Pemotongan pelanggan yang sangat penting di wawancarai semua insinyur kecuali yang memiliki gelar Senior atau Lead.
Dalam kasus pertama, kita mendapatkan "batu bata" bukan piramida dan proyek yang jelas tidak terkendali dengan akhir yang menyedihkan.
Dalam kasus kedua, kita mendapatkan koloni yang sama "White Swan" pada proyek tersebut. Ini adalah ketika orang-orang yang dihormati dan berpengalaman berkumpul di satu ruangan dan dalam dua jam tidak dapat menemukan solusi sederhana. Hanya karena mereka semua berpengalaman dan keren, masing-masing ingin berbicara dan percaya bahwa idenya baik. Rasa percakapan seperti itu biasanya sangat kecil. Selain itu, tidak jelas siapa yang harus "mengangkat sabun", oh, siapa yang harus melihat fitur ini?
Dalam karir saya, ada proyek-proyek dengan sekelompok orang dalam tim dan saya jujur mengatakan bahwa bekerja di versi pertama dan kedua tidak begitu nyaman. Baik manajer maupun karyawan biasa. Ketika sebuah tim memiliki terlalu banyak orang pintar, itu menjadi bodoh. Piramida menjadi tidak stabil dan sering "jatuh" sehingga tidak hati-hati.
Faktanya, semuanya sederhana, sebuah proyek TI harus memiliki cukup banyak insinyur yang melakukan pekerjaan, manfaat dan tidak mengajukan pertanyaan. Tanpa jumlah orang yang cukup, proyek itu tidak memiliki “tenaga kuda” yang cukup dan tidak akan keluar untuk masa depan yang bahagia.
Situasi sebaliknya adalah ketika Anda memiliki terlalu banyak "tenaga kuda" dan sedikit kontrol, maka mobil balap Anda hanya akan menabrak pagar pertama.
Jumlah ideal orang dalam tim TI adalah 5-15 orang. Bezos dari Amazon mengkompilasi ini sebagai prinsip “Two Pizza team”. Peningkatan lebih lanjut dalam jumlah orang mempersulit komunikasi dalam tim dan tidak lagi memiliki efek pengganda.
Distribusi anggota tim yang ideal pada saat jatuh tempo adalah per lead dari 2 hingga 5 insinyur tingkat menengah. Jika kita berbicara tentang insinyur Junior atau tentang
Vasiliev - maka tidak boleh lebih dari 1-2 per pemimpin (atau orang yang bertanggung jawab atas mereka). Hanya karena dia secara fisik tidak dapat memperhatikan lebih banyak orang. Peninjauan Kode Dasar untuk 5 orang sudah dapat mengambil setengah dari waktu kerja. Selain itu, para pemimpin masih memiliki semua jenis pertemuan dengan tim lain dan pelanggan, sehingga ia tidak dapat melakukan pekerjaan 100% dari waktu sebagai insinyur reguler.
Yaitu kita dapat mengatakan bahwa di dalam piramida kematangan tim, kita harus membangun piramida kecil dari sub-tim yang terpisah untuk stabilitas tambahan.
Adapun tingkat atas piramida - tidak begitu penting berapa banyak orang yang Anda miliki di bagian paling atas, jika Anda memiliki 2 tingkat yang lebih rendah - mereka akan mengambil seluruh proyek. Piramida dalam banyak kasus tidak akan sempurna, tetapi tidak menakutkan. Yang utama adalah memiliki cukup banyak orang dari bawah.
Jangan memperhitungkan dalam piramida pengawas - mis. orang-orang yang memimpin seluruh arah dan hanya mengendalikan proses pada beberapa proyek tanpa mengganggu manajemen.
Pemilik Produk Agile adalah bagian dari tim, tetapi tidak boleh mengganggu proses manajemen. Jika dia mulai terlibat dalam manajemen mikro atau Anda langsung memiliki 5 Pemilik Produk, maka Anda memiliki masalah besar. Tapi ini sudah menjadi masalah manajemen proyek yang kompeten dan hubungan pelanggan. Jika Anda jatuh ke dalam perangkap ini, maka piramida terbalik sudah menjadi masalah terkecil Anda.
Poin lain adalah ketika terlalu banyak orang ingin memimpin proyek, dan Anda, sebagai satu-satunya orang yang bekerja, ingat karya Saltykov-Shchedrin, "Bagaimana satu orang memberi makan dua jenderal." Atau
cerita ini. Tapi situasi seperti itu mudah diprediksi menggunakan "tim maturity pyramid" dan tidak melanjutkan proyek seperti itu.
Dalam perusahaan yang kompeten, hal-hal seperti komposisi tim harus direncanakan sedini tahap penjualan proyek. Kemudian mereka memilih manajer proyek yang akan membentuk tulang punggung tim pemimpin dan dengan bantuan mereka membangun piramida, melihat proyek, dan menangkap galaksi.