9.6 Batas Solusi: In-Scope, Out-of-Scope, dan Asumsi
Setelah tahu arah perubahan, kita perlu menetapkan batas-batas solusi agar tidak melebar. Ini langkah yang sering dianggap remeh. Banyak tim merasa sudah cukup jelas apa yang harus dikerjakan, lalu berjalan tiga bulan dan baru sadar bahwa setengah jalan ternyata ada ekspektasi yang tidak terpenuhi. Atau sebaliknya, tim mengerjakan terlalu banyak hal karena tidak berani mengatakan "itu bukan bagian kita."
Saya pernah melihat satu tim membangun portal pengajuan cuti. Scope-nya terdengar sederhana: karyawan bisa mengajukan cuti, atasan menyetujui, dan HR mencatat. Tapi begitu berjalan, muncul permintaan integrasi dengan sistem absensi, lalu laporan kehadiran real-time, lalu dashboard beban kerja tim, lalu notifikasi ke WhatsApp. Masing-masing terdengar masuk akal. Tapi semuanya adalah perluasan scope yang tidak pernah disepakati di awal. Tim kelelahan, deadline molor, dan fitur inti pengajuan cuti malah tidak selesai dengan baik.
Di sinilah kita butuh alat untuk menjaga fokus. Alat itu sederhana: in-scope, out-of-scope, dan asumsi.
Berikut diagram yang merangkum tiga area utama batas solusi.
In-scope adalah daftar hal yang pasti dikerjakan dalam inisiatif ini. Ini harus dituliskan secara eksplisit, bukan hanya dipikirkan. Misalnya untuk portal cuti: "fitur pengajuan cuti, persetujuan atasan, pencatatan HR, dan notifikasi email." Tidak perlu panjang, tapi harus jelas sehingga semua orang tahu apa yang menjadi tanggung jawab tim.
Berikut contoh dokumentasi scope dalam format YAML untuk portal cuti.
project: portal-pengajuan-cuti
version: 1.0
in-scope:
- fitur pengajuan cuti
- persetujuan atasan
- pencatatan HR
- notifikasi email
out-of-scope:
- integrasi dengan sistem absensi
- dashboard beban kerja tim
- notifikasi WhatsApp
asumsi:
- data karyawan sudah tersedia di sistem HR
- semua atasan memiliki akses email
- kebijakan cuti perusahaan tidak berubah
dependency:
- API sistem HR harus siap sebelum fitur pencatatan cuti dikerjakan
constraint:
- solusi harus berjalan di infrastructure yang sudah ada tanpa tambahan server baru
mitigation:
- jika API sistem HR belum siap, tim akan membuat mekanisme input manual sementara
Out-of-scope adalah daftar hal yang sengaja tidak dikerjakan. Ini sama pentingnya dengan in-scope. Dengan menuliskan apa yang tidak termasuk, kita mencegah ekspektasi yang mengambang. Contoh: "integrasi dengan sistem absensi tidak termasuk dalam inisiatif ini. Dashboard beban kerja tim tidak termasuk. Notifikasi WhatsApp tidak termasuk." Dengan menuliskan ini, ketika nanti ada yang bertanya "kapan fitur absensi selesai?", tim bisa menjawab dengan tenang: "itu di luar scope inisiatif ini, kita perlu inisiatif terpisah."
Asumsi adalah hal-hal yang kita percayai benar agar solusi bisa berjalan. Misalnya: "data karyawan sudah tersedia di sistem HR existing", "setiap atasan memiliki akses email", atau "kebijakan cuti perusahaan tidak berubah selama enam bulan ke depan." Asumsi perlu dicatat karena jika ternyata salah, scope bisa berubah. Jika data karyawan ternyata tidak lengkap, tim harus menambahkan pekerjaan pembersihan data yang sebelumnya tidak direncanakan.
Selain tiga alat utama itu, ada dependency dan constraint. Dependency adalah hal yang harus tersedia lebih dulu agar solusi bisa dikerjakan. Misalnya: "API sistem HR harus siap sebelum fitur pencatatan cuti dikerjakan." Constraint adalah batasan yang tidak bisa diubah, misalnya: "solusi harus berjalan di infrastructure yang sudah ada tanpa tambahan server baru."
Terakhir, mitigation. Ini adalah rencana jika asumsi ternyata salah atau dependency tidak terpenuhi. Misalnya: "jika API sistem HR belum siap, tim akan membuat mekanisme input manual sementara." Mitigation bukan untuk menakut-nakuti, tapi untuk memastikan tim tidak berhenti total ketika hambatan muncul.
Dengan menuliskan in-scope, out-of-scope, asumsi, dependency, constraint, dan mitigation, tim memiliki pagar yang jelas. Setiap kali ada permintaan baru, tim bisa kembali ke dokumen ini dan bertanya: "Apakah ini masuk in-scope? Apakah asumsi kita masih berlaku?" Jika tidak, permintaan itu ditunda atau dijadikan inisiatif terpisah.
Setelah batas solusi jelas, kita perlu melihat lebih detail ke boundary antara aplikasi, data, dan tim. Siapa yang memiliki bagian mana, dan bagaimana mereka berinteraksi.
