Satu orang atau tim? Cara menentukan susunan minimum proyek berdasarkan keterampilan, ketergantungan, dan risiko

Penelitian tidak mendukung aturan sederhana seperti "tim kecil selalu lebih baik" atau "tim besar selalu menghasilkan lebih banyak".

Meta-analisis tahun 2023 yang mencakup 208 efek independen dan 21.435 tim menemukan hubungan keseluruhan yang nyaris nol antara ukuran tim dan kinerja tugas, sekaligus variasi besar menurut konteks. Penulis menunjukkan bahwa pengaruh ukuran tim berubah antara lain bersama kompleksitas tugas dan kebutuhan koordinasi. [4]

Eksperimen pada tugas pemetaan krisis yang kompleks juga menunjukkan manfaat dan biaya tim yang lebih besar: kolaborasi meningkat seiring ukuran tim, sementara pola upaya individu berubah. Dalam eksperimen khusus itu, tim terbesar mengungguli jumlah orang yang setara yang bekerja secara mandiri. Ini bukan resep universal untuk semua jenis pekerjaan. [5]

Kesimpulan praktisnya sederhana: jumlah orang harus mengikuti sifat pekerjaan, bukan angka ajaib.

Scrum Guide 2020 menggambarkan Scrum Team sebagai tim kecil, lintas keahlian, dan mengelola pekerjaannya sendiri. Panduan itu juga menyebut bahwa tim seperti ini biasanya berjumlah 10 orang atau kurang. [3]

Itu merupakan panduan yang berguna dalam konteks Scrum, tetapi bukan hukum universal untuk semua proyek, layanan, industri, atau model kerja.

Proyek konstruksi, kampanye pemasaran, penilaian keamanan, sistem keuangan, dan situs informasi kecil memiliki kebutuhan yang sangat berbeda. Satu angka tidak seharusnya dipindahkan begitu saja di antara konteks tersebut.

Service Standard Inggris mengharuskan tim layanan digital bersifat multidisipliner dan memiliki akses ke rentang keterampilan yang sesuai. Standar tersebut juga menyatakan bahwa susunan tim harus mengikuti apa yang perlu dicapai pada fase tertentu. [1]

Panduan GOV.UK lainnya menyebut bahwa ukuran tim dan peran yang dibutuhkan berubah sepanjang fase pembangunan layanan. [2]

Dari sini muncul aturan praktis:

petakan pekerjaan dan tanggung jawab terlebih dahulu, lalu tentukan keterampilan, dan baru setelah itu tetapkan orang tertentu.

Tim tidak dapat ditentukan dengan baik jika ruang lingkupnya kabur.

Setidaknya tuliskan:

• hasil yang harus dibuat,
• apa yang termasuk ruang lingkup,
• apa yang tidak termasuk,
• persyaratan kualitas utama,
• batas waktu dan anggaran,
• siapa yang menerima hasil,
• apakah tim hanya menyerahkan solusi atau juga harus mengoperasikannya.

Proyek "membuat aplikasi" dan proyek "merancang, membuat, mengamankan, menerapkan, dan mengoperasikan aplikasi selama satu tahun" membutuhkan cakupan pekerjaan yang sangat berbeda.

Jangan langsung menetapkan jabatan. Daftarkan terlebih dahulu jenis pekerjaan yang benar-benar harus dilakukan.

Untuk layanan digital, contohnya:

• memahami kebutuhan pengguna,
• merancang solusi,
• membangun bagian yang terlihat pengguna,
• membangun logika dan integrasi sisi server,
• pengujian,
• keamanan,
• aksesibilitas,
• penerapan dan operasi,
• koordinasi ruang lingkup dan keputusan.

Jenis proyek lain akan memiliki daftar berbeda.

GOV.UK menyatakan bahwa tim yang membangun dan menjalankan layanan digital membutuhkan keterampilan luas yang mencakup kebutuhan pengguna, desain, pembangunan, pengujian, keamanan, penerapan, dan operasi. [2]

Tidak setiap keterampilan yang dibutuhkan memerlukan satu orang penuh waktu di dalam tim.

Untuk setiap area, tentukan:

Tetap - dibutuhkan secara rutin dan langsung memengaruhi keputusan sehari-hari.
Berkala - dibutuhkan pada fase atau titik pemeriksaan tertentu.
Tersedia secara eksternal - dapat diberikan orang atau tim lain jika waktu respons dan tanggung jawab cukup jelas.

GOV.UK secara eksplisit memungkinkan keahlian khusus tersedia bagi tim tanpa mengharuskan spesialis menjadi anggota tetap. [1]

Ini sering mencegah pembesaran tim secara artifisial tanpa kehilangan keahlian penting.

Dua orang dapat bersama-sama memiliki semua keterampilan yang dibutuhkan tetapi tetap menjadi susunan yang buruk jika seluruh pekerjaan berada dalam satu rantai ketergantungan yang sempit.

Periksa:

• tugas mana yang dapat berjalan paralel,
• tugas mana yang harus menunggu yang lain,
• siapa yang membuat keputusan yang dapat memblokir pekerjaan berikutnya,
• tim atau pemasok luar mana yang menjadi ketergantungan proyek,
• di mana ketidakhadiran satu orang menghentikan beberapa area sekaligus.

GOV.UK memasukkan pengelolaan ketergantungan pada tim lain sebagai salah satu kemampuan yang diperlukan dalam pembangunan layanan digital. [2]

Ketika lebih dari satu tim mengerjakan layanan yang sama, kebutuhan tambahan muncul untuk mengoordinasikan rencana dan kemajuan antar tim. [8]

Sebagian keahlian yang diperlukan tidak terlihat dalam daftar fitur produk, tetapi ketiadaannya dapat mahal.

Tergantung proyek, ini dapat mencakup:

• keamanan,
• perlindungan data,
• aksesibilitas,
• persyaratan hukum atau industri,
• keandalan,
• migrasi data,
• integrasi dengan sistem kritis,
• teknologi yang belum pernah digunakan tim.

GOV.UK menyarankan akses ke keahlian khusus ketika proyek membutuhkannya dan menyatakan bahwa susunan tim juga harus mencerminkan asumsi paling berisiko pada fase saat ini. [1]

Ini tidak otomatis berarti satu jabatan penuh waktu untuk setiap risiko. Artinya seseorang yang kompeten harus memiliki tanggung jawab yang jelas dan kemampuan nyata untuk memengaruhi keputusan.

Seseorang mungkin menguasai desain, pengembangan, pengujian, dan penerapan. Itu tidak berarti orang tersebut dapat melakukan semuanya secara bersamaan dalam tenggat apa pun.

Materi PMI tentang perencanaan sumber daya menekankan pentingnya mencocokkan keterampilan, ketersediaan, biaya, dan pengalaman dengan kebutuhan proyek. [7]

Untuk setiap orang, periksa:

• berapa banyak waktu yang benar-benar dapat diberikan,
• tugas apa yang berebut perhatian,
• apakah pekerjaan perlu berjalan paralel,
• apakah tenggat mengandaikan perpindahan yang tidak realistis di antara banyak jenis pekerjaan,
• apakah seseorang masih harus mengoperasikan solusi setelah peluncuran.

Cakupan keterampilan tanpa cakupan waktu bukanlah cakupan proyek yang lengkap.

Susunan minimum juga harus mempertimbangkan kesinambungan.

Tanyakan:

• apa yang terjadi jika orang kunci tidak tersedia,
• apakah hanya satu orang memahami bagian kritis solusi,
• apakah keputusan dan pengetahuan didokumentasikan,
• apakah orang lain dapat mengambil alih tugas terpenting,
• apakah proyek dapat berhenti sementara dengan aman selama ketidakhadiran.

Tidak semua proyek kecil memerlukan pengganti penuh. Dalam proyek singkat dan berisiko rendah, menerima risiko ini secara sadar dapat masuk akal.

Dalam proyek kritis, ketergantungan yang sama pada satu orang dapat tidak dapat diterima.

Proyek tidak memerlukan orang terpisah untuk setiap nama peran.

Jika satu orang benar-benar memiliki keterampilan yang diperlukan, kapasitas yang cukup, dan tidak menciptakan risiko yang tidak dapat diterima, orang tersebut dapat bertanggung jawab atas beberapa area.

Dalam proyek kecil, misalnya, satu orang dapat menggabungkan desain antarmuka dan implementasi. Dalam proyek lain, satu orang dapat menggabungkan analisis bisnis dan koordinasi ruang lingkup.

Jangan menggabungkan tanggung jawab hanya karena "seseorang harus melakukannya". Penggabungan masuk akal hanya jika orang tersebut mampu menjalankan keduanya pada tingkat yang diperlukan dan memiliki cukup waktu.

Satu orang dapat menjadi susunan yang rasional jika semua kondisi ini terpenuhi:

• ruang lingkup kecil dan jelas,
• keterampilan yang diperlukan benar-benar ada pada orang tersebut,
• tugas tidak membutuhkan banyak pekerjaan paralel,
• ketergantungan eksternal terbatas,
• risiko dapat diterima,
• tenggat sesuai kapasitas nyata,
• ketiadaan pengganti diterima secara sadar.

Contohnya dapat berupa materi informasi kecil, analisis sederhana, konsultasi sekali jalan, atau implementasi terbatas dalam lingkungan yang sudah dikenal.

Tetap bergantung pada ruang lingkup konkret. Label "proyek kecil" tidak menentukan jawabannya sendiri.

Tim menjadi lebih beralasan ketika beberapa kondisi ini muncul:

• keterampilan yang dibutuhkan terlalu luas untuk satu orang,
• banyak pekerjaan harus berjalan paralel,
• tenggat lebih pendek daripada pelaksanaan berurutan yang realistis,
• proyek memiliki banyak ketergantungan dan antarmuka,
• risiko membutuhkan keahlian khusus yang independen,
• solusi harus dibangun dan dioperasikan pada saat yang sama,
• satu orang akan menjadi titik kritis bagi seluruh proyek,
• tanggung jawab melintasi beberapa disiplin yang berbeda.

Dalam kondisi ini, menambah kemampuan yang kurang lebih penting daripada sekadar menambah jumlah orang.

Menambah orang meningkatkan kumpulan pengetahuan dan kapasitas potensial, tetapi juga dapat menambah ketergantungan, serah terima pekerjaan, dan kebutuhan menyelaraskan keputusan.

Studi proyek perangkat lunak dalam Journal of Systems and Software menunjukkan bahwa hubungan antara ukuran tim, produktivitas, upaya, dan waktu bersifat kompleks dan tidak selalu cocok dengan intuisi. [6]

Meta-analisis tentang ukuran tim juga menunjukkan bahwa hasil bergantung pada konteks tugas dan biaya proses tim. [4]

Jadi pertanyaannya bukan "berapa banyak orang yang dapat kita tambahkan?", melainkan "apakah orang berikutnya menghilangkan kendala nyata proyek lebih besar daripada menambah biaya koordinasi?"

Tidak semua kemampuan penting harus hadir setiap hari.

Kehadiran tetap lebih masuk akal ketika orang tersebut rutin membuat keputusan, pekerjaannya memiliki banyak ketergantungan dengan area lain, atau respons cepat penting.

Dukungan berkala dapat cukup ketika keahlian dibutuhkan pada titik tertentu, misalnya untuk peninjauan, konsultasi, penilaian risiko, atau penerimaan khusus.

Syaratnya satu: ketersediaan harus nyata. Harus jelas:

• siapa yang bertanggung jawab,
• kapan orang itu tersedia,
• waktu respons yang diharapkan,
• keputusan apa yang dapat dibuat,
• apa yang terjadi jika ditemukan masalah.

Akses ke spesialis tanpa tanggung jawab yang jelas dapat terlihat baik di bagan organisasi tetapi gagal dalam proyek nyata.

Misalkan tujuannya meluncurkan sistem pemesanan daring.

Varian A: prototipe sederhana untuk menguji gagasan
Ruang lingkup terbatas, tidak ada pembayaran atau data yang sangat sensitif, dan tujuannya menguji proses dengan kelompok pengguna kecil. Satu orang serba bisa berpotensi mencakup desain dan implementasi, dengan konsultasi berkala bila perlu.

Varian B: layanan publik dengan akun, pembayaran, dan integrasi
Muncul lebih banyak spesialisasi, pengujian, risiko, ketergantungan, dan pekerjaan paralel. Tim beberapa orang menjadi jauh lebih masuk akal.

Varian C: layanan yang berjalan terus dan membutuhkan respons cepat terhadap masalah
Selain pembangunan, ada operasi, pemantauan, respons insiden, dan kesinambungan pengetahuan. Susunan yang cukup untuk peluncuran mungkin tidak cukup untuk operasi berkelanjutan.

Jenis produknya secara umum sama, tetapi ruang lingkup, risiko, dan model operasi yang berbeda menciptakan kebutuhan tim yang berbeda.

1. Anda mulai dari daftar jabatan siap pakai, bukan pekerjaan yang perlu dilakukan.

2. Anda menganggap setiap peran memerlukan orang terpisah.

3. Anda hanya melihat keterampilan dan mengabaikan waktu yang tersedia.

4. Anda menambah orang tanpa menghilangkan ketergantungan dan hambatan.

5. Anda mengabaikan keterampilan yang didorong risiko karena tidak menghasilkan fitur yang terlihat.

6. Anda membuat beberapa area kritis bergantung pada satu orang tanpa secara sadar menerima risikonya.

7. Anda menganggap susunan awal tetap sampai proyek selesai.

GOV.UK secara eksplisit menyatakan bahwa ukuran dan peran tim berubah di sepanjang fase pengembangan layanan. [2]

Prinsip ini juga masuk akal di luar layanan publik:

• pada awal proyek, lebih banyak riset dan definisi masalah mungkin dibutuhkan,
• selama pembangunan, kemampuan pelaksanaan dan pengujian menjadi lebih penting,
• sebelum peluncuran, kebutuhan keamanan, kualitas, dan kesiapan operasi dapat meningkat,
• setelah peluncuran, keseimbangan bergeser antara pengembangan dan operasi.

Susunan minimum adalah sifat dari fase dan ruang lingkup, bukan angka tetap untuk seluruh umur proyek.

Untuk setiap area penting, tuliskan lima hal:

Area kerja - apa yang harus dilakukan?
Keterampilan - pengetahuan dan kemampuan apa yang dibutuhkan?
Tanggung jawab - siapa yang memutuskan dan bertanggung jawab atas hasil?
Ketersediaan - apakah keterampilan bersifat tetap, berkala, atau eksternal?
Risiko ketiadaan - apa yang terjadi jika keterampilan tidak ada atau orangnya tidak tersedia?

Baru setelah itu tetapkan orang tertentu.

Jika satu orang mencakup beberapa baris, periksa waktu dan ketergantungannya. Jika satu baris membutuhkan beberapa orang, periksa apakah alasannya kapasitas, pengawasan independen, atau pekerjaan paralel.

1. Apakah setiap area kerja wajib memiliki penanggung jawab?
2. Apakah setiap tanggung jawab kritis ditangani orang dengan keterampilan yang tepat?
3. Apakah ada orang yang memegang beberapa peran, dan apakah waktunya benar-benar cukup?
4. Apakah proyek membutuhkan pekerjaan paralel yang tidak dapat didukung susunan saat ini?
5. Apakah kita mengetahui ketergantungan utama pada orang, tim, dan pemasok lain?
6. Apakah risiko penting memiliki akses ke keahlian khusus yang tepat?
7. Bisakah ketidakhadiran satu orang menghentikan seluruh proyek?
8. Apakah susunan cukup bukan hanya untuk membangun, tetapi juga meluncurkan dan mengoperasikan solusi jika itu termasuk ruang lingkup?
9. Apakah kita tahu keterampilan mana yang dapat bersifat berkala, bukan tetap?
10. Sudahkah kita menentukan titik untuk menilai ulang susunan setelah perubahan ruang lingkup atau fase?

Perancangan tim tidak seharusnya dimulai dengan:

"biasanya berapa orang yang dibutuhkan proyek seperti ini?"

Urutan yang lebih baik:

hasil -> pekerjaan -> keterampilan -> ketergantungan -> risiko -> kapasitas -> orang.

Jika setelah melalui urutan ini satu orang benar-benar mencakup semuanya, satu orang dapat menjadi pilihan yang tepat.

Jika ada kekurangan keterampilan, waktu, peninjauan independen, kesinambungan, atau kemampuan kerja paralel, Anda memerlukan orang tambahan atau akses yang dapat diandalkan ke spesialis.

Tujuannya bukan tim terkecil. Tujuannya adalah susunan terkecil yang secara realistis dapat menghasilkan hasil yang diperlukan pada tingkat risiko dan kualitas yang dibutuhkan.

[1] GOV.UK Service Standard - Have a multidisciplinary team
Buka sumber

[2] GOV.UK Service Manual - Set up a service team at each phase
Buka sumber

[3] The Scrum Guide, 2020 - Scrum Team
Buka sumber

[4] Bernerth, Beus, Helmuth, Boyd - The more the merrier or too many cooks spoil the pot? A meta-analytic examination of team size and team effectiveness, Journal of Organizational Behavior, 2023
Buka sumber

[5] Mao, Mason, Suri, Watts - An Experimental Study of Team Size and Performance on a Complex Task, PLOS ONE, 2016
Buka sumber

[6] Rodríguez, Sicilia, García, Harrison - Empirical findings on team size and productivity in software development, Journal of Systems and Software, 2012
Buka sumber

[7] Project Management Institute - Solving The Resource Puzzle
Buka sumber

[8] GOV.UK Service Manual - Running more than one service team
Buka sumber

Catatan metodologis: sebagian sumber membahas layanan publik digital, sebagian tim Scrum, manajemen proyek, atau penelitian tim dan pengembangan perangkat lunak. Panduan ini memakai setiap sumber hanya untuk hal yang benar-benar didukungnya. Metode tujuh langkah untuk menentukan susunan minimum adalah sintesis editorial dari prinsip tersebut, bukan standar formal dari organisasi yang disebutkan.