Perencanaan sumber daya untuk alur kerja engineering mencocokkan pekerjaan yang diusulkan dengan ketersediaan nyata orang dan kemampuan yang dibutuhkan. Mulailah dari komitmen yang ada, tanggung jawab operasional, ketidakhadiran terencana, dan keahlian yang langka. Lalu bandingkan urutan yang layak. Menghitung jumlah karyawan atau menugaskan engineer yang sama ke beberapa rencana penuh waktu tidak menciptakan kapasitas.
Tujuannya adalah membuat kompromi terlihat sebelum tim menjanjikan tanggal pengiriman. Gambaran kapasitas yang berguna harus spesifik per peran, memiliki batas waktu, dan jujur tentang ketidakpastian. Gambaran itu mendukung diskusi dengan orang yang mengerjakan tugas; bukan skor pengawasan atau ramalan produktivitas per individu dari menit ke menit.
Kanban Guide menjelaskan pengendalian pekerjaan yang sedang berlangsung dan memulai pekerjaan saat kapasitas tersedia. Prinsip itu relevan di sini, tetapi tabel perencanaan di bawah adalah alat bantu praktis orisinal, bukan metode manajemen sumber daya Kanban yang diwajibkan.
Bedakan orang, keterampilan, upaya, dan waktu yang berlalu
Sebuah tim dapat memiliki enam engineer, tetapi hanya satu yang mampu meninjau perubahan infrastruktur tertentu. Jumlah karyawan secara keseluruhan menyembunyikan hambatan itu. Daftarkan kemampuan yang dibutuhkan tiap alur kerja: penerapan, keputusan domain, tinjauan keamanan, pekerjaan data, pengujian, dan penerimaan operasional.
Upaya adalah kontribusi yang diperlukan. Waktu yang berlalu mencakup penantian dan urutan. Dua minggu-orang pekerjaan belum tentu muat dalam satu minggu kalender dengan dua orang yang tersedia, terutama jika tugas saling bergantung atau memerlukan peninjau langka.
Ketersediaan juga berbeda dari waktu yang dapat ditugaskan ke proyek. Tugas siaga, tanggapan insiden, pemeliharaan, perekrutan, pendampingan, dan komitmen yang ada menghabiskan kapasitas. Buat tanggung jawab itu terlihat tanpa berpura-pura semuanya dapat diperkirakan dengan tepat. Gunakan pola historis bila sesuai, dan tandai cadangan apa pun sebagai asumsi perencanaan.
Jangan membandingkan story point lintas tim seolah-olah merupakan mata uang sumber daya bersama. Untuk perencanaan lintas alur kerja, ketersediaan peran yang konkret dan kondisi ketergantungan biasanya lebih mudah dijelaskan daripada jumlah poin gabungan.
Buat gambaran kapasitas untuk satu rentang perencanaan
Mulailah dengan rentang singkat yang membuat peserta memahami komitmen saat ini. Empat minggu mungkin sesuai bagi satu organisasi, sedangkan organisasi lain memerlukan jangka waktu berbeda. Rentang ini adalah pilihan perencanaan, bukan standar engineering universal.
| Peran atau kemampuan | Ketersediaan bruto | Komitmen yang ada | Cadangan operasional | Alokasi baru yang diusulkan |
|---|---|---|---|---|
| Implementasi backend | Kontribusi yang tersedia dalam rentang ini | Pekerjaan yang sudah diterima | Dukungan dan pemeliharaan yang diperkirakan | Kontribusi khusus alur kerja |
| Tinjauan platform | Kapasitas tinjauan yang ditetapkan | Tinjauan dan migrasi yang ada | Tanggung jawab insiden dan siaga | Slot keputusan atau tinjauan |
| Validasi data | Kontribusi analitis yang tersedia | Tugas pelaporan dan kualitas | Investigasi data tak terencana | Pekerjaan rekonsiliasi |
| Keputusan produk | Ketersediaan pengambil keputusan | Inisiatif yang ada | Keputusan operasional | Pilihan penerimaan yang diperlukan |
Gunakan satuan yang konsisten untuk perbandingan tertentu, misalnya hari kontribusi dalam rentang itu. Jangan mencampurkan hari kalender seseorang dengan hari implementasi terfokus orang lain tanpa penjelasan.
Papan bersama dapat mengumpulkan batasan dan permintaan yang saling bersaing dalam diskusi perencanaan. Simpan alokasi serta jadwal resmi di sistem sumber daya atau proyek organisasi. Jangan menggambarkan Nextretro sebagai alat yang otomatis memperkirakan kebutuhan staf atau menyelesaikan ketergantungan.
Contoh lengkap: tiga alur berbagi satu peninjau
Bayangkan kelompok engineering hipotetis merencanakan pekerjaan selama empat minggu. Mereka ingin menjalankan proyek pelaporan, perbaikan autentikasi, dan migrasi infrastruktur. Rencana setiap alur secara terpisah menganggap spesialis platform yang sama akan tersedia saat diperlukan.
Sebagai ilustrasi, spesialis tersebut memiliki 20 hari kerja dalam rentang itu. Lima hari sudah dialokasikan untuk tanggung jawab operasional, tiga untuk ketidakhadiran terencana, dan empat untuk pekerjaan migrasi yang diterima. Tersisa delapan hari sebelum permintaan baru masuk. Proyek pelaporan meminta empat hari dan autentikasi meminta enam hari. Keduanya membutuhkan sepuluh hari, bahkan sebelum ketidakpastian diperhitungkan.
Angka tersebut dibuat untuk perencanaan, bukan tolok ukur produktivitas. Nilainya adalah mengungkap kontradiksi: rencana tiap alur secara keseluruhan menganggap kontribusi spesialis lebih besar daripada yang tersedia.
Kelompok mempertimbangkan mengurutkan autentikasi sebelum pelaporan, mengurangi ruang lingkup awal pelaporan, memasangkan engineer lain untuk mengembangkan kemampuan, atau mengubah tanggal sasaran. Kelompok tidak menyelesaikan ketidakcocokan dengan memberi persentase yang jumlahnya melebihi waktu yang dapat disediakan orang tersebut.
Pilih kompromi yang eksplisit
Saat permintaan melebihi kapasitas, sebutkan apa yang akan berubah. Pilihannya termasuk mengurangi ruang lingkup, menunda awal pekerjaan, menyelesaikan pekerjaan yang ada lebih dulu, mengubah urutan, mengembangkan kemampuan orang lain, atau menambah dukungan yang memang tersedia. Setiap pilihan memiliki konsekuensi.
Menambah orang mungkin memerlukan orientasi dan supervisi dari spesialis terbatas yang sama. Catat biaya itu alih-alih menganggap tenaga baru langsung dapat saling menggantikan. Demikian pula, mengerjakan beberapa hal secara paralel dapat menambah koordinasi atau integrasi. Periksa ketergantungan sebenarnya sebelum menjanjikan durasi lebih singkat.
Buat catatan keputusan yang memuat kemampuan yang terbatas, alur terdampak, opsi yang dipertimbangkan, urutan terpilih, ketidakpastian tersisa, dan waktu tinjauan berikutnya. Identifikasi siapa yang dapat menyetujui perubahan ruang lingkup atau komitmen. Lokakarya dapat mengungkap konflik, tetapi tidak dengan sendirinya memberikan wewenang untuk menyelesaikannya.
Jika terlalu banyak pekerjaan sudah dimulai di banyak tempat, prioritaskan penyelesaian atau penghentian yang aman sebelum menambah pekerjaan lain. Tinjau pekerjaan yang belum selesai dan ketergantungan yang terhambat. Tingginya tingkat alokasi bukan bukti bahwa hasil yang berguna sedang mengalir.
Tinjau kembali asumsi saat pekerjaan berjalan
Tinjau gambaran kapasitas saat insiden besar, ketidakhadiran, perubahan ruang lingkup, atau ketergantungan mengubah rencana. Jaga pembaruan tetap proporsional. Tujuannya menyadari perubahan penting, bukan meminta engineer melaporkan setiap gangguan.
Bandingkan kontribusi yang direncanakan dengan alasan pekerjaan benar-benar menunggu. Apakah peninjau langka menjadi hambatan? Apakah keputusan penerimaan datang terlambat? Apakah tugas yang dianggap mandiri ternyata membutuhkan integrasi tak terduga? Pengamatan ini membantu percakapan perencanaan berikutnya.
Retrospektif agile dapat meninjau alur kerja yang selesai atau terlambat tanpa mengubah perencanaan kapasitas menjadi upaya menyalahkan individu. Gunakan format dari ide retrospektif untuk membedakan fakta, asumsi, dan perbaikan berikutnya.
Jangan menyebut pemanfaatan yang tercatat rendah sebagai pemborosan tanpa konteks. Kapasitas luang dapat mendukung pekerjaan mendesak, pembelajaran, dan pemulihan. Pertanyaan yang relevan adalah apakah pengaturan ini mendukung pengiriman andal dan pekerjaan berkelanjutan, bukan apakah setiap kolom kalender terisi.
Pertanyaan yang sering diajukan
Apakah kapasitas engineering harus direncanakan hingga 100%?
Jangan berasumsi seluruh waktu yang tersedia dapat dijanjikan untuk pekerjaan proyek baru. Tanggung jawab yang ada, gangguan, dan ketidakpastian perlu dipertimbangkan secara eksplisit. Cadangan yang tepat bergantung pada pekerjaan nyata tim dan perlu ditinjau, bukan disalin dari persentase universal.
Bisakah satu engineer bekerja di beberapa alur?
Bisa, tetapi perhitungkan total kontribusi, urutan, dan beban koordinasi. Semua alokasi harus muat dalam ketersediaan nyata. Jika seorang spesialis berulang kali menjadi ketergantungan, pertimbangkan mengubah urutan atau mengembangkan kemampuan tambahan.
Apa perbedaan perencanaan kapasitas dengan penjadwalan?
Perencanaan kapasitas memeriksa apakah kemampuan yang dibutuhkan tersedia dalam suatu rentang waktu. Penjadwalan mengoordinasikan aktivitas, ketergantungan, dan tanggal tertentu. Jadwal yang dibangun di atas kapasitas yang tidak tersedia tidak menjadi kredibel hanya karena ditambah rincian.