# Contoh Change Request — beranotasi

> **Untuk BA/PO.** Ini contoh, bukan formulir wajib. Silakan salin kerangkanya, atau tetap
> pakai format Anda sendiri — isi yang penting, bukan bentuknya.
>
> Anotasi (blok `>` berwarna) menjelaskan **kenapa** sebuah bagian ada dan **apa harganya
> kalau tidak ada**. Tiga bagian diberi anotasi. Sisanya bebas.
>
> Kerangkanya diambil dari CR nyata yang lolos triage tanpa bolak-balik.

---

## Bacaan cepat — apa yang benar-benar bikin CR ditolak

Cuma dua hal yang bikin CR balik ke Anda. Sisanya kami jalan pakai asumsi dan Anda verifikasi
belakangan.

| Bagian | Kalau tidak ada | Harganya |
|---|---|---|
| **Referensi** (Figma, guideline, aset) | **CR balik ke Anda** | Kami tidak bisa menebak desain. Menebak = salah, lalu diulang |
| **Satu tanggal rilis per CR** | **CR balik ke Anda** | Dua timeline tidak muat di satu tanda tangan |
| **Out of Scope** | CR **tidak** balik — tapi kami yang menebak batasnya | Anda baru bisa mengoreksi setelah kami keburu menulis spec |

Perhatikan bedanya. Dua yang pertama menghentikan pekerjaan. Yang ketiga tidak — dia cuma
membuat tebakan kami jadi kerja Anda untuk dibetulkan. Kami tidak menulis semuanya "wajib",
karena kalau semua wajib maka tidak ada yang wajib.

---

# CHANGE REQUEST

## [Judul singkat — apa + di mana]

* **Document No:** CR-2026-XXXX
* **Version:** v1
* **Date:** [tanggal]
* **Project:** [sistem]

| Project Name | Product Owner |
| :--- | :--- |
| [nama] | [nama] |

| Requested by | Date Submitted |
| :--- | :--- |
| [nama] | [tanggal] |

**Expected Release Date:** [boleh kosong]

> **Judul.** Sebut apa yang berubah dan di mana. Judul yang menjanjikan lebih sedikit dari
> isinya adalah cara paling umum sebuah CR jadi berantakan — "Tambah Section X" yang isinya
> ternyata section + menu admin + otomasi penjadwalan membuat seluruh dokumen terasa kecil,
> dan tanda tangan diberikan atas kesan itu, bukan atas isinya.

---

### Change Description

Revamp halaman Promo pada website (contoh fiktif), mencakup pembaruan konten sekaligus
penyesuaian layout, diimplementasikan sesuai desain Figma final dan dokumen guideline konten
(tautan pada bagian Referensi). Perubahan yang diminta:

1. **Section Hero baru** — mengganti banner statis dengan hero yang menampilkan promo aktif.
2. **Section Testimoni** — menambahkan testimoni pelanggan di bawah daftar promo.
3. **FAQ** — menambahkan section FAQ sesuai Figma terbaru, ditempatkan setelah daftar promo.
4. **Update Syarat & Ketentuan** — memperbarui isi sesuai kebijakan terbaru.

#### Referensi:
* Desain Figma (final): [tautan]
* Konten, aset foto & guideline: [tautan]

#### Guideline desain:
* **Font:** [nama font + tautan]
* **Palet warna:**

| Warna | Hex |
| :--- | :--- |
| [nama] | #XXXXXX |

> **Referensi — ini yang paling sering bikin CR balik.**
>
> "Mengikuti referensi kompetitor X" bukan spesifikasi. Kami tidak bisa menebak banner, tema
> warna, layout, atau anatomi kartu dari sebuah nama situs. Tanpa desain, tidak ada yang bisa
> dikerjakan — dan ini satu-satunya hal yang benar-benar menghentikan pekerjaan sejak hari
> pertama.
>
> Pertanyaan lain kami jalan pakai asumsi. Yang ini tidak bisa: tidak ada default untuk
> "warnanya apa".
>
> Belum ada Figma final? Tetap kirim CR-nya — tapi sebut kapan desainnya turun. Itu mengubah
> percakapan dari "kami menunggu" jadi "kami menjadwalkan".

---

### Reason for Change

Permintaan dari [tim], sebagai bagian dari [inisiatif]. Halaman promo saat ini [masalahnya
apa], dan [dampak bisnisnya apa].

Perubahan ini diperlukan agar [hasil yang diharapkan], sekaligus mendukung [aktivitas bisnis
yang bergantung padanya].

> **Alasan.** Satu paragraf cukup. Gunanya bukan formalitas — ini yang kami pakai untuk
> memutuskan saat dua hal bertabrakan di tengah pengerjaan. Tanpa ini, tiap pilihan kecil
> jadi tebakan tentang apa yang sebenarnya Anda kejar.

---

### Scope of Changes

#### Scope
1. Halaman Promo hasil revamp yang live di [URL], sesuai Figma final dan guideline.
2. Seluruh 4 perubahan yang tercantum pada Change Description.
3. Carousel foto diimplementasikan sebagai konten statis dengan set foto tetap (6 foto sesuai Figma).
4. Section FAQ ditempatkan setelah daftar promo.

#### Out of Scope
1. Pembuatan konten testimoni — disiapkan tim requester secara paralel.
2. Perubahan header/navigasi — tetap mengikuti website yang ada saat ini.
3. Halaman detail promo — tidak disentuh pada CR ini.

> **Out of Scope — bagian yang paling sering dihapus, dan paling mahal saat hilang.**
>
> Ini **tidak** membuat CR Anda ditolak. Tapi tanpa ini, kami yang menebak di mana batasnya,
> dan Anda baru tahu tebakan kami saat spesifikasi sudah ditulis. Kalau tebakannya salah,
> yang terbuang bukan cuma waktu kami — waktu Anda juga, untuk membaca dan membetulkannya.
>
> Bagian ini nanti langsung jadi **Anti-Scope** di BRD Lite yang kami kirim balik untuk Anda
> verifikasi. Menulisnya di sini artinya Anda menulisnya sekali, bukan mengoreksinya dua kali.
>
> Isinya cukup hal-hal yang wajar dikira termasuk padahal tidak. Kalau ragu, tulis saja —
> lebih murah dicoret daripada ditebak.

---

### Time and Cost
* **Release Date:** [target bisnis Anda]
* **Mandays / Cost:** [biaya vendor eksternal — 0 kalau dikerjakan internal]

> **Satu CR = satu tanggal rilis = satu tanda tangan.**
>
> Ini aritmatika, bukan birokrasi. Kalau permintaan Anda punya dua fase yang rilis di bulan
> berbeda, satu tanda tangan tidak bisa menutup keduanya — salah satu tanggalnya pasti bohong
> sejak hari dokumen ditandatangani. Pecah jadi CR terpisah, masing-masing dengan tanggalnya
> sendiri.
>
> **Tesnya:** butuh tanggal rilis sendiri? Ya → CR terpisah. Tidak → tetap satu CR.
>
> Banyak perubahan dalam satu CR itu **tidak masalah** selama tanggalnya satu. Contoh di atas
> punya 4 perubahan dalam 1 CR dan itu benar — semuanya satu halaman, satu tanggal, satu tema.
> Memecahnya jadi 4 CR justru ceremony palsu.
>
> **Release Date itu ekspektasi Anda, bukan janji kami.** Estimasi nyata lahir dari rincian
> tugas teknis — yang kami susun **setelah** Anda memverifikasi ruang lingkup. Angka itu
> nanti kami kirim ke Anda untuk dinegosiasikan. Jadi tanggal yang ambisius bukan masalah;
> dia titik awal negosiasi, bukan kegagalan.

### SIGN OFF SIGNATURE
| Approved By, |
| :--- |
| [tanda tangan] |

---

## Yang TIDAK perlu Anda urus

Supaya jelas apa yang bukan tugas Anda:

* **Estimasi hari / mandays internal** — lahir dari rincian tugas teknis, disusun setelah Anda
  memverifikasi ruang lingkup. Kolom `Mandays`/`Cost` itu untuk biaya vendor eksternal; 0 untuk
  kerja internal memang benar.
* **Weight (S/M/L)** — kami yang menilai saat triage. Ini yang Anda pakai untuk menyusun
  prioritas selagi angka hari belum terbit.
* **Asumsi teknis** — kami yang mengusulkan defaultnya di BRD Lite, Anda tinggal
  mengonfirmasi atau mengoreksi. Anda tidak perlu menebak-nebak jawaban teknis di CR.
* **Format dokumen** — kerangka di atas contoh, bukan aturan. Isi yang dinilai.

## Ke mana CR ini pergi

```
CR Anda → triage (Lead)
            ├─ ada blocker? → balik ke Anda + daftar pertanyaan
            └─ lolos → BRD Lite putaran 1 (bisnis) → Anda verifikasi
                     → putaran 2 (teknis) → estimasi terbit → nego
```

Detail lengkapnya ada di playbook. Yang perlu Anda tahu dari CR ini cuma: **Referensi dan satu
tanggal rilis** menentukan CR Anda lolos atau balik. **Out of Scope** menentukan seberapa
akurat tebakan kami.