RULES OF ENGAGEMENT · IT DEV × BUSINESS ANALYST
No DoD, no code.
Seluruh permintaan wajib melalui gerbang validasi tunggal. Permintaan yang lolos akan dijadwalkan, sementara yang tidak lolos otomatis dikembalikan dengan alasan penolakan yang spesifik. Dokumen ini mendefinisikan kriteria penerimaan, pemecahan, dan pengembalian permintaan kerja secara transparan.
01
Request Flow, End to End
Alur kerja dari pengajuan hingga tahap perilisan. Proses melibatkan dua gerbang kontrol utama: validasi kelayakan (DoD) pada saat triage dan verifikasi BA atas ruang lingkup, batas pengerjaan, serta asumsi. Untuk permintaan berbobot M/L, spesifikasi disusun dalam dua putaran: putaran bisnis diverifikasi BA terlebih dahulu, baru putaran teknis yang menerbitkan estimasi.
LEAD TRIAGE
feat · change · bug · project
NO ↓
hanya pertanyaan yang jawabannya tidak dapat ditetapkan sebagai default · revisi → pengajuan ulang
YES ↓
S — SMALL
scope + anti-scope, 2–3 baris
1 kontainer · triage per-item
Alur langsung ke tahap pengembangan ↓
M / L — MEDIUM / LARGE
core, anti-scope, asumsi & default · belum memuat estimasi
sinyal prioritas: Weight (S / M / L), bukan angka hari
Ditolak: revisi putaran 1 | Disetujui: asumsi dikunci ↓
struktur data, keterhubungan antar sistem, dan rincian tugas
Estimasi di luar ekspektasi bisnis: kembali ke putaran 1 untuk pemangkasan ruang lingkup ↩
Estimasi diterima: masuk antrian pengembangan ↓
DELIVERY
02
DoD Gate — Why a Request Gets Bounced
Kepatuhan kelayakan dinilai melalui 15 kriteria dalam 4 kelompok utama. Kegagalan pada satu kriteria berakibat pada pengembalian permintaan kerja secara otomatis — bukan karena idenya buruk, melainkan indikasi belum siap dikerjakan. Adapun pertanyaan terbuka yang muncul saat triage disaring lebih dahulu melalui satu pengujian: apakah jawabannya dapat ditetapkan sebagai default? Apabila dapat, pertanyaan tersebut bukan blocker dan akan diturunkan menjadi asumsi & default pada spesifikasi. Hanya pertanyaan yang jawabannya tidak dapat ditetapkan sebagai default yang dikembalikan sebagai blocker; pada praktiknya jumlah blocker jauh lebih sedikit daripada jumlah pertanyaan terbuka. Silakan lakukan penilaian mandiri melalui daftar periksa berikut; panel di sebelah kanan akan menampilkan hasil penilaian (verdict) secara otomatis.
03
Weight & Priority — Two Axes, Two Owners
Klasifikasi pekerjaan dipisahkan secara tegas berdasarkan dua sumbu kontrol: Weight (bobot teknis yang ditentukan oleh tim developer) dan Priority (tingkat urgensi bisnis yang Anda usulkan dan wajib dikonfirmasi oleh Lead). Kedua metrik ini dilarang keras dicampuradukkan. Pada tahap verifikasi, Weight adalah acuan besaran yang Anda pakai untuk menyusun prioritas. Weight memberi rentang, estimasi memberi angka: rentang S dan M rapat karena pekerjaannya kecil dan sudah dipahami, sedangkan rentang L sengaja terbuka justru karena aspek yang belum diketahui masih banyak. Angka pastinya lahir dari rincian tugas teknis pada putaran kedua.
WEIGHT · rated by dev from effort + blast radius + unknowns
S ≤ 2 hari · 1 komponen · alur sudah jelas
Terbatas pada 1 komponen dengan alur yang sudah jelas. Langsung dieksekusi; dokumentasi spesifikasi cukup dicatat pada kolom komentar tiket.
M 3–5 hari · 1 modul · ada aspek yang perlu klarifikasi
Meliputi 1 modul dengan 1-2 aspek yang membutuhkan klarifikasi. Wajib melampirkan BRD Lite ringkas yang disusun dua putaran: putaran bisnis diverifikasi terlebih dahulu oleh BA, baru dilanjutkan ke putaran teknis.
L > 5 hari · lintas modul · atau wajib dipecah
Melibatkan lintas modul, perubahan struktur data, atau integrasi eksternal. Wajib menyusun BRD Lite lengkap dalam dua putaran: putaran bisnis diverifikasi BA terlebih dahulu, baru putaran teknis yang memuat rincian tugas dan menerbitkan estimasi.
PRIORITY · you propose, Lead confirms
P0 drop semua, kerja sekarang
Kriterian mutlak: Sistem production mati total, transaksi terhenti, atau terjadi kerusakan/kebocoran data. Dilarang menyalahgunakan status ini untuk urgensi non-kritis. Pengajuan lebih dari 2 tugas P0 secara bersamaan otomatis dibatalkan untuk ditinjau ulang.
P1 sprint terdekat
Memiliki dampak bisnis signifikan dengan batas waktu (deadline) yang nyata dan tidak dapat ditunda (contoh: perilisan kampanye pemasaran pada tanggal tertentu).
P2 antri normal
Dibutuhkan untuk peningkatan sistem, namun tidak memiliki batas waktu yang ketat. Masuk ke dalam antrian penjadwalan normal.
P3 backlog
Peningkatan minor (nice-to-have). Hanya dikerjakan apabila seluruh antrian utama telah selesai dan terdapat kapasitas luang.
04
Real Case Study: "Dashboard Revamp"
Analisis kasus nyata: permintaan kerja yang dikembalikan saat triage karena tidak layak, kemudian berhasil lolos setelah dipecah menjadi 7 bagian terpisah. Bandingkan struktur sebelum dan sesudah perubahan.
"Dashboard Revamp"
Satu tiket besar mencakup: reorder homepage section, banner homepage slider, Best Seller section, logika kategori Shop All, pembaruan tipografi, tombol navigasi, dan WhatsApp CS. Cakupan ini tidak terdefinisi secara spesifik dan menyalahgunakan fungsi tiket tunggal.
- · Judul tidak spesifik — gagal menjelaskan komponen dan area sistem yang diubah.
- · Menggabungkan tujuh concern berbeda — menghambat proses estimasi waktu dan verifikasi kualitas per bagian.
- · Spesifikasi bertolak belakang — penulisan instruksi layout Best Seller tidak konsisten (menyebutkan dua kolom sekaligus dua baris pada dokumen yang sama).
- · Ketergantungan tidak siap — menyertakan kebutuhan yang ditandai untuk tahap berikutnya, sehingga menyandera pekerjaan saat ini.
05
BRD Lite — The Doc You Verify
Untuk permintaan berskala M/L, tim developer wajib merespons dengan menerbitkan BRD Lite putaran pertama (aspek bisnis) pada tiket terkait — untuk permintaan berskala besar, dokumen disimpan pada repositori dan tautannya dilampirkan di tiket. Dokumen putaran pertama memuat ruang lingkup, batas pengerjaan, dan asumsi yang digunakan — belum memuat estimasi waktu. Sebagai indikator skala untuk kebutuhan prioritas, dokumen ini mencantumkan bobot pekerjaan (Weight S/M/L); angka hari baru diterbitkan pada putaran kedua setelah Anda memberikan persetujuan. Spesifikasi dinilai belum berkekuatan hukum sebelum Anda memberikan konfirmasi final. Kriteria peninjauan wajib mencakup:
BRD LITE — ROUND 1 (BUSINESS)
- Ruang Lingkup Utama (Core)Rincian fitur dan batasan pengguna yang akan diimplementasikan pada perilisan.
- Batas Pengerjaan (Anti-Scope)Poin kritis yang mendefinisikan hal-hal yang sengaja dikecualikan guna mencegah pembengkakan ruang lingkup (*scope creep*).
- Rencana Lanjutan (Post-MVP)Fitur yang ditangguhkan pengerjaannya untuk dialihkan sebagai pengajuan tiket berikutnya.
- Asumsi & DefaultDaftar pertanyaan terbuka beserta nilai default yang digunakan tim developer dan dampaknya apabila default tersebut keliru. Pengerjaan berjalan menggunakan default; tidak adanya tanggapan dianggap sebagai persetujuan atas default.
YOUR VERIFICATION CHECKLIST
- ☐ Apakah Ruang Lingkup Utama (Core) telah sepenuhnya merepresentasikan tujuan awal permintaan bisnis Anda?
- ☐ Apakah Batas Pengerjaan (Anti-Scope) tidak memotong kebutuhan esensial yang Anda perlukan untuk rilis ini?
- ☐ Apakah fitur pada Rencana Lanjutan (Post-MVP) secara bisnis dapat ditangguhkan?
- ☐ Apakah seluruh Asumsi & Default yang digunakan tim developer sudah tepat, dan dapatkah Anda menerima dampaknya apabila asumsi tersebut keliru?
Pemberian persetujuan (Approve) mengunci ruang lingkup beserta seluruh asumsi, dan menjadi syarat dimulainya penyusunan spesifikasi teknis serta rincian tugas — tahap yang menerbitkan estimasi waktu. Apabila estimasi tersebut tidak sejalan dengan batas waktu bisnis, ruang lingkup dapat ditinjau ulang dan dipangkas sebelum pengerjaan dimulai. Adapun perubahan atau penambahan fitur setelah tahap ini wajib diajukan sebagai tiket baru, bukan revisi pengerjaan.
06
Triage Response — How to Read It
Setiap permintaan kerja wajib direspons dengan salah satu dari dua keputusan mutlak berikut. Dilarang membiarkan status tiket menggantung tanpa keputusan.
✅ ACCEPTED — [judul] · Weight: M · Priority: P2 (usulan)
Scope: [1 kalimat]
Next: dev assigned → spec putaran 1 (bisnis) → verifikasi BA
Konsekuensi: Permintaan kerja masuk ke antrian pengerjaan. BA selanjutnya akan menerima spesifikasi putaran pertama — ruang lingkup, batas pengerjaan, serta asumsi & default — untuk diverifikasi. Estimasi belum disertakan pada tahap ini dan baru diterbitkan setelah verifikasi Anda; untuk keperluan prioritas, yang tersedia adalah Weight (S/M/L).
❌ NEEDS REVISION — [judul]
Alasan: [REASON_CODE]
Pecah jadi: 1… 2… 3…
Blocker (wajib dijawab): 1… 2…
Revisi dan
kirim ulang sebelum masuk antrian.
Konsekuensi: Permintaan kerja dinilai tidak layak jalan. Pengembalian disertai kode kegagalan (reason code) dan daftar pertanyaan blocker, yaitu pertanyaan yang jawabannya tidak dapat ditetapkan sebagai default. BA wajib menjawab seluruh pertanyaan blocker dan memperbaiki kelengkapan tiket sebelum dapat diajukan kembali. Pertanyaan lain yang jawabannya masih dapat ditetapkan sebagai default tidak menahan pengajuan; pertanyaan tersebut akan diturunkan menjadi asumsi & default pada spesifikasi untuk Anda verifikasi kemudian.
Referensi: contoh Change Request beranotasi — kerangka permintaan yang lolos triage tanpa pengembalian, disertai penjelasan bagian mana yang menahan pengajuan dan bagian mana yang hanya memengaruhi akurasi asumsi kami. Ini contoh, bukan formulir wajib; format Anda sendiri tetap diterima.
| REASON CODE | MEANING | WHAT YOU DO |
|---|---|---|
| TOO_GENERIC | Judul atau ruang lingkup terlalu abstrak | Tulis ulang menggunakan formula: kata kerja + objek + lokasi pengerjaan |
| MULTI_CONCERN | Penumpukan banyak fungsi dalam satu tiket | Lakukan pemecahan tiket sesuai draf rekomendasi yang dilampirkan |
| MISSING_CRITERIA | Kriteria penerimaan tidak terukur atau tidak dapat diuji | Tambahkan skenario pengujian menggunakan format: Given → When → Then |
| BLOCKED_DEPENDENCY | Terkendala ketergantungan aset, sistem, atau persetujuan eksternal | Selesaikan kendala ketergantungan terlebih dahulu sebelum melakukan pengajuan ulang |
| NEEDS_SPECIALIST | Membutuhkan keahlian khusus di luar kapasitas tim aktif | Lakukan koordinasi ulang bersama Lead untuk merancang pendekatan alternatif |
07
Many Small Requests? — Batch Lane
Akumulasi permintaan minor dilarang diajukan menggunakan tiket terpisah. Kenali klasifikasi "permintaan minor" berdasarkan tiga pola berikut untuk menentukan prosedur penanganan yang tepat. Klik pada tab pola untuk detail.
→ Pertahankan dalam 1 tiket (dilarang memecah tiket)
Seluruh komponen berada pada satu area fungsional dengan benang merah yang sama. Pemecahan menjadi beberapa tiket dinilai sebagai inefisiensi administrasi. Pekerjaan akan diproses secara utuh sebagai satu unit kerja (umumnya berskala M).
⚠ KONTROL BATCH GUARD — Ketentuan Larangan Backdoor
Prosedur Batch hanya diizinkan untuk unit pekerjaan dengan bobot teknis sangat rendah. Dua kriteria berikut otomatis membatalkan kelayakan jalur Batch secara mutlak berdasarkan sifat pekerjaan asli:
↩ UNCLEAR
Spesifikasi Tidak Lengkap: Permintaan tanpa kejelasan alur bisnis atau ketiadaan draf desain (mockup) wajib dikeluarkan dari kontainer hingga kriteria lengkap.
↩ ACTUALLY BIG
Kompleksitas Terselubung: Pekerjaan yang memodifikasi sistem transaksi keuangan, integrasi eksternal, atau basis data krusial wajib dialihkan ke jalur permintaan kerja M/L.