Bagaimana menyusun tim pengembangan

Saya adalah manajer dari tim yang terdiri dari 11 pengembang perangkat lunak yang menjaga situs web perusahaan saya / aplikasi web, menjalankan hingga 4 proyek bersamaan ditambah dukungan sehari-hari setiap saat. Dalam 11 pengembang ada campuran keterampilan teknis, jabatan dan pengalaman, meskipun struktur tim datar dengan semua 11 pengembang melaporkan langsung kepada saya.

Seluruh tim yang memiliki seorang manajer tunggal mulai membuktikan untuk tidak mengukur dengan sangat baik. Saya mulai menyebar terlalu tipis sehingga saya ingin mengurangi jumlah laporan langsung saya. Semua cara yang dapat saya pikirkan untuk melakukan ini memiliki kerugian besar:

• Mintalah para pengembang junior melapor kepada yang senior. Ini mengurangi waktu yang dihabiskan untuk pengembangan oleh teknisi terbaik.
• Membagi tim dengan produk perangkat lunak, mis. Pengembang 1-6 bekerja di intranet dan 7-11 bekerja di situs eksternal, dengan setiap bagian memiliki pemimpin tim baru (mungkin deskripsi pekerjaan baru dengan tanggung jawab manajemen / pendampingan / pembinaan yang lebih banyak daripada pengembang senior saat ini ). Ini menambahkan silo buatan dan mungkin membuat sulit untuk mendapatkan "pengembang intranet" untuk bekerja di situs web eksternal jika saya menginginkannya.
• Pertahankan struktur tetap datar dan tambahkan dukungan manajerial dalam bentuk Manajer Proyek / Administrator Tim hanya untuk melepas tekanan. Ini tidak menyelesaikan masalah karena tim tidak dapat terus tumbuh seperti ini selamanya.

Apakah ada cara standar untuk menyelesaikan masalah ini yang saya lewatkan?

Jika tidak, bagaimana orang lain dari Anda memecahkan masalah ini?

Beberapa pemikiran cepat:

• Sub-tim adalah ide yang baik: 11 laporan langsung tanpa struktur apa pun terlalu besar untuk tim yang dapat dikerjakan (Anda tidak akan punya cukup waktu untuk pelatihan langsung, dan pertemuan tim dengan banyak orang cenderung tidak produktif).
• Pertimbangkan untuk memisahkan operasi dari pengembangan - ini merupakan keahlian yang sedikit berbeda dan terganggu oleh masalah operasional sepanjang hari dapat sangat merusak produktivitas pembangunan pada proyek.
• Sebagai hasil dari dua poin pertama, saya pikir Anda mungkin harus memiliki 3 subteam - Intranet, Situs Eksternal, dan Operasi. Petugas operasi akan menangani semua masalah sehari-hari / perbaikan pemeliharaan dll. Sementara kedua tim pengembangan fokus pada memberikan proyek / nilai baru ke bisnis.
• Siklus orang di antara tim secara teratur. Ini bisa bersifat sesekali (mis. Meminta orang melakukan review kode di subteam lain), untuk proyek atau secara permanen. Tetapi pastikan dipahami bahwa peran tim akan berubah kapan pun ada kebutuhan bisnis - tidak ada yang "memiliki" peran tertentu selamanya.
• Jangan menambahkan lebih banyak manajer / administrator - ini adalah cara pasti untuk mengurangi efektivitas / produktivitas tim Anda secara keseluruhan. Mintalah orang yang paling berpengalaman dalam setiap subteam memainkan peran pemimpin / pelatih tim. Pastikan bahwa mereka melihat peran mereka di sini sebagai pembinaan dan membuat seluruh tim berhasil, dan pastikan bahwa mereka diperlengkapi untuk berperilaku dengan cara ini daripada bertindak sebagai "manajer tugas".
• Peran Anda harus difokuskan pada manajemen pemangku kepentingan eksternal, memprioritaskan sumber daya / tugas dalam kelompok, dan bertindak sebagai "pelatih kepala". Anda harus menangani masalah eskalasi yang sesekali muncul dari sub-tim, tetapi secara umum Anda harus mendorong mereka untuk menyelesaikan masalah sendiri tanpa mendatangi Anda.
• Jika Anda sangat teknis sendiri, Anda juga dapat memilih untuk memainkan peran arsitek / jaminan desain. Jika tidak, cari seseorang yang bisa, dalam tim atau di tempat lain .....

Juga, selalu layak untuk dikunjungi dan (kembali) membaca Agile Manifesto , dan terutama dua belas prinsip .

Struktur itu terutama depend on project specifications

Idealnya, harus ada 3 junior per pengembang senior dalam satu tim. Akibatnya, ada 2-3 pengembang senior per petunjuk mengajar.

Dengan demikian, hanya lead teknologi yang akan melaporkan kepada PM tentang status kemajuan proyek. Struktur yang dijelaskan masih mengasumsikan bahwa untuk masalah non-teknis (liburan, waktu istirahat, konflik, dll.) Setiap orang dapat memiliki akses ke PM.

Salah satu tim pengembangan perangkat lunak yang relatif sukses, saya adalah bagian dari kegiatan seperti ini, berdasarkan per proyek:

Manajer Pengembangan Perangkat Lunak / Pengembang Senior / Mentor, kepada siapa orang lain melaporkan secara langsung.

• Seorang manajer proyek, yang menjaga jadwal, memfasilitasi persyaratan dan negosiasi penerimaan, dan melakukan komunikasi. Semua orang putus-putus melaporkan ke orang ini juga. Orang dokumentasi (yang terkadang juga PM, tetapi hanya jika keahlian diizinkan).
• Gabungan 1-3 pengembang atau pengembang senior, tergantung pada kebutuhan proyek.
• Pengembang junior saat tersedia.
• Seseorang ditugaskan dari kolam QA.
• Seorang infrastruktur (peran yang sering dipenuhi oleh manajer, karena ia juga memiliki kompetensi SA yang solid).

Ini bekerja dengan sangat baik, dan saya menyukai organisasi itu. Di sisi lain, saya adalah Manajer Pengembangan Perangkat Lunak, dan struktur organisasi tim berkembang.

Pertimbangkan mengikuti pola Organisasi Staf Fungsional . Ini akan berbicara mengenai opsi kedua Anda untuk membagi tim dengan produk perangkat lunak.

Mengutip artikel dalam konteks Anda:

Kekuatan terbesar dari organisasi fungsional adalah bahwa ia mengikat struktur sosial dengan penyampaian nilai bisnis. Dalam pandangan saya proyek perangkat lunak berhasil sebanyak mereka meningkatkan efektivitas kegiatan yang mereka dukung - menghasilkan nilai bisnis. Dengan mengatur tim Anda dengan cara yang sama, Anda memiliki tim yang berorientasi untuk memuaskan pengguna bisnis mereka.

Struktur manajemen / SDM yang sebenarnya tidak relevan di luar itu.

Apakah ada cara standar untuk menyelesaikan masalah ini yang saya lewatkan?

Tidak juga. Itu akan tergantung pada tim Anda, Anda, apa yang perlu Anda lakukan, dan sumber daya apa yang disediakan perusahaan untuk Anda.

Secara pribadi, jenis saklar terbaik adalah dengan memisahkan manajemen teknis dari manajemen administrasi. Jarang orang pandai keduanya, dan mereka jarang berinteraksi.

Satu orang menangani aspek teknis. Apa yang perlu dilakukan, siapa yang akan melakukannya, bagaimana segala sesuatunya perlu berbaris. Yang lain menangani aspek administrasi. Ulasan, rapat anggaran, perencanaan produk, dll. Mereka kemudian bekerja sama untuk mengkomunikasikan wawasan dari satu sisi ke sisi lain dan untuk memberikan front persatuan.

Bagaimana ini dipecah dapat pergi beberapa cara berbeda. Yang paling umum adalah memiliki manajer teknik menjadi sisi administrasi dan seorang arsitek menjadi sisi teknis. Mereka adalah rekan sejawat dan melapor kepada direktur / VP.

Pekerjaan lain yang pernah saya lihat adalah menjadikan manajer teknik sebagai orang administratif, dan kemudian ketua tim bertindak sebagai orang teknis. Ini rumit, dan mengharuskan orang yang tepat untuk bertindak sebagai (kebanyakan) teman sebaya walaupun pelaporannya bersifat hierarki.

Untuk skenario spesifik Anda, saya akan merekomendasikan memiliki 2-3 tim dan memiliki arahan teknis melakukan aspek teknis dan Anda fokus pada administrasi. Ya, itu benar-benar menghemat waktu dari lead yang benar-benar menulis kode, tetapi mereka harus (jika mereka melakukan pekerjaan dengan baik) mengganti waktu itu dengan membuat lebih banyak pengembang junior lebih efisien / produktif. Ini memberi mereka lebih banyak motivasi dan rasa prestasi dengan promosi yang sebenarnya juga. Dan yang paling praktis, ini lebih mudah dijual kepada manajemen daripada membuka posisi baru.