Workflow Estimasi Pengembangan dengan Claude Code untuk Proyek Nyata

Estimasi pengembangan bukan permainan menebak jumlah hari yang paling tepat. Dalam proyek nyata, estimasi yang berguna menjelaskan scope, asumsi, unknowns, risiko, waktu review, dan pekerjaan verifikasi agar produk, engineering, dan klien mengambil keputusan dari bukti yang sama.

Kesalahan pemula adalah menghitung waktu coding saja. “Tambah field telepon di profil” terlihat kecil, tetapi bisa menyentuh database migration, tipe API, validasi form, export CSV, audit log, test, release note, dan ketersediaan reviewer. Migration berarti perubahan schema atau data database. Ini harus dihitung terpisah karena data tidak selalu mudah dikembalikan seperti kode.

Claude Code tidak membuat estimasi otomatis akurat. Nilainya ada pada membaca repository, membuka blast radius, menaruh asumsi dan unknowns ke tabel, lalu membuat risiko terlihat. Jangan gunakan untuk mengarang tanggal pasti. Gunakan untuk mengurangi pekerjaan yang terlewat.

Workflow ini cocok dengan empiricism di Scrum Guide: transparency, inspection, dan adaptation. Untuk melacak kumpulan issue dan PR, lihat dokumentasi GitHub milestones. Untuk relative estimation, panduan Atlassian estimation juga berguna. Untuk Claude Code, jadikan overview dan CLI reference sebagai rujukan.

Di ClaudeCodeLab, baca juga panduan navigasi codebase, template bug report, dan checklist code review.

Pisahkan Input Estimasi

Sebelum membahas tanggal, pisahkan lima input.

Input	Arti sederhana	Bantuan Claude Code
scope	Apa yang masuk dan tidak masuk	File, fitur terkait, test
assumptions	Hal yang harus benar	Aturan produk, izin, jalur release
unknowns	Hal yang belum diketahui	File, pertanyaan, owner
risk buffer	Ruang untuk gagal dan menunggu	Migration, auth, billing, review queue
evidence	Mengapa angka bisa dibela	PR lama, git history, jumlah test

Hindari hanya berkata “2 hari”. Lebih baik: “low 1,5 hari, likely 3 hari, high 5 hari jika CRM masuk scope.” Range bukan tanda lemah. Itu cara jujur menunjukkan apa yang sudah diketahui dan apa yang masih bisa berubah.

flowchart LR
  A["Permintaan"] --> B["repo scan"]
  B --> C["dekomposisi tugas"]
  C --> D["tabel asumsi"]
  D --> E["risk register"]
  E --> F["range estimasi"]
  F --> G["prompt review"]
  G --> H["ringkasan klien"]

Empat Use Case Realistis

Kasus pertama adalah perubahan field profil di SaaS. Menambah phone_number bisa memengaruhi DB schema, validasi API, UI, search, CSV export, audit log, privacy, dan test. Jika datanya personal, masking log dan aturan delete/export juga masuk estimasi.

Kasus kedua adalah bug di layar legacy. “Filter tidak jalan” bisa terkait query helper lama, cache, parameter URL, fixture, dan E2E. Sebelum meminta Claude Code memperbaiki, minta ia memetakan impact dan jalur verifikasi.

Kasus ketiga adalah proposal konsultasi atau permintaan DX internal. Klien berkata “butuh admin screen”, tetapi scope sebenarnya bisa mencakup login, role, audit trail, CSV, notifikasi, handover permission, dan manual operasional. Claude Code dapat membaca issue dan kode yang ada untuk menemukan pekerjaan yang tidak tertulis di permintaan awal.

Kasus keempat adalah situs konten yang dimonetisasi. Perubahan MDX kecil dapat mencakup speed, internal link, OGP, structured data, localization, screenshot, dan review layout yang ramah AdSense. Kualitas publish lebih luas daripada edit teks.

Pola Gagal Yang Sering Terjadi

Kegagalan pertama adalah menjadikan tebakan pertama sebagai komitmen. “Mungkin satu hari” sebelum repo scan hanyalah harapan. Setelah harapan itu sampai ke stakeholder, estimasi yang lebih realistis terlihat seperti keterlambatan.

Kegagalan kedua adalah menganggap review dan verifikasi gratis. Implementasi enam jam masih bisa membutuhkan test, perbaikan hasil review, staging check, release note, dan koordinasi deploy.

Kegagalan ketiga adalah menyembunyikan unknowns di buffer yang kabur. “Tambah 30%” tidak membantu jika alasannya tidak disebut: API eksternal belum jelas, rollback belum dirancang, antrian reviewer, fixture kurang, atau aturan produk ambigu.

Kegagalan keempat adalah percaya angka AI tanpa bukti. Jika Claude Code berkata “3 hari” tetapi tidak menyebut file, PR lama, test, dan risiko, estimasi itu hanya prosa rapi.

Step 1: Repo Scan Read-Only

Mulai dari bentuk repository. Jangan edit dulu.

git status --short
git branch --show-current
git rev-parse --show-toplevel

rg --files \
  -g '!*node_modules*' \
  -g '!dist' \
  -g '!build' \
  -g '!coverage' \
  -g '!*.lock' \
  | sort \
  | head -200

find . -maxdepth 3 \( \
  -name package.json -o \
  -name pyproject.toml -o \
  -name go.mod -o \
  -name Cargo.toml -o \
  -name AGENTS.md -o \
  -name CLAUDE.md -o \
  -name README.md \
\) -print

Lalu minta Claude Code membuat peta read-only.

claude -p "
Run a read-only repo scan.
Do not edit, create files, or add dependencies.

Return:
1. apps, packages, and services
2. runtime, test, and build entrypoints
3. generated folders to ignore
4. 10 files that must be read for this estimate
5. reasons this task cannot yet be estimated
"

Step 2: Dekomposisi Tugas

Bagi pekerjaan menjadi unit yang bisa direview dan diverifikasi.

claude -p "
Task: Let users add, view, and edit a phone number on their profile.

Break this into reviewable work items.
For each item include:
- name
- likely files
- implementation work
- test work
- definition of done
- size: small, medium, or large

Also list out-of-scope items.
Separate guessed product rules as assumptions.
"

Biasanya muncul DB, API, UI, test, dan release work. Jika satu item tidak bisa masuk satu PR, pecah sebelum diestimasi.

Step 3: Tabel Assumptions

Assumptions adalah tempat plan sering pecah. Tulis secara eksplisit.

| ID | Assumption | Why it matters | Owner | Confirm by |
| --- | --- | --- | --- | --- |
| A1 | Phone number is optional | Required fields change validation and migration | PM | 2026-06-05 |
| A2 | Web only, no mobile app change | Mobile release adds review and store delay | PM | 2026-06-05 |
| A3 | Existing user rows stay null | Backfill work is not included | Tech lead | 2026-06-06 |

claude -p "
Review this assumptions table.
Find assumptions that could break the estimate.
Add missing owners, deadlines, and questions.
Move anything risky into a risk register.
"

Step 4: Risk Register

Risk register adalah tabel yang menyebut apa saja yang bisa merusak rencana.

| Risk | Trigger | Impact | Mitigation | Buffer |
| --- | --- | --- | --- | --- |
| DB rollback is unclear | migration changes existing rows | High | dry-run and rollback plan | 0.5-1 day |
| External CRM stores phone | CRM field mapping appears | Medium | check integration owner | 0.5 day |
| Review queue is full | no reviewer within 24h | Medium | book review slot early | 1 day |
| Test data is missing | no edge-case users | Medium | create fixtures first | 0.5 day |

Buffer bukan ruang untuk bekerja lambat. Itu ruang untuk unknowns, failure, dan waktu menunggu. Auth, billing, data pribadi, alur delete, dan migration perlu risiko yang lebih eksplisit daripada perubahan UI saja.

Step 5: Hitung Range Estimasi

Script ini bisa langsung disalin dan dijalankan.

// estimate-range.mjs
const tasks = [
  { name: "Repo scan and design check", hours: 2, risk: 1.1 },
  { name: "DB migration and schema", hours: 4, risk: 1.4 },
  { name: "API contract and validation", hours: 5, risk: 1.2 },
  { name: "Profile UI update", hours: 6, risk: 1.2 },
  { name: "Tests and fixtures", hours: 5, risk: 1.3 },
  { name: "Review fixes and release note", hours: 3, risk: 1.2 },
];

const base = tasks.reduce((sum, task) => sum + task.hours, 0);
const likely = tasks.reduce((sum, task) => sum + task.hours * task.risk, 0);
const low = Math.max(base * 0.8, base - 4);
const high = likely * 1.35;

const day = 6;
const format = (hours) => `${hours.toFixed(1)}h / ${(hours / day).toFixed(1)}d`;

console.log(`Low:    ${format(low)}`);
console.log(`Likely: ${format(likely)}`);
console.log(`High:   ${format(high)}`);

node estimate-range.mjs

Jangan anggap multiplier sebagai kebenaran. risk: 1.4 berarti “area ini tidak pasti”. Jika diubah, catat alasannya di issue atau PR.

Step 6: Review Secara Kritis

Sebelum dikirim ke klien, minta Claude Code menyerang estimasi.

You are a critical project estimation reviewer.

Review this estimate before I share it with a client.
Find:
1. hidden scope
2. weak assumptions
3. missing tests
4. missing rollout or rollback work
5. fake precision
6. tasks that should be split

Return findings first.
Then provide a revised low / likely / high range.
Do not make the estimate look more certain than the evidence supports.

Instruksinya penting. “Buat lebih bagus” menghasilkan teks lebih bagus. “Review secara kritis” menghasilkan gesekan yang berguna.

Step 7: Ringkasan Untuk Klien

Ubah catatan internal menjadi dokumen keputusan singkat.

# Development Estimate Summary

## Scope
- Add optional phone number to user profile.
- Update DB schema, API validation, profile UI, and tests.
- Include release note and manual verification.

## Not included
- SMS notification.
- Mobile app release.
- Historical data backfill.
- CRM integration changes unless confirmed.

## Estimate
- Low: 3 business days
- Likely: 4-5 business days
- High: 7 business days if CRM or migration rollback work expands

## Assumptions
- Phone number is optional.
- Web only.
- Existing users can keep the value empty.

## Risks
- DB rollback plan must be reviewed before implementation.
- Reviewer availability may add one calendar day.

## Next decision
- Confirm whether CRM and mobile app are in scope by 2026-06-05.

Masukkan estimasi kembali ke GitHub Issues atau milestone agar bisa dibandingkan dengan hasil aktual.

## Estimate
- Low:
- Likely:
- High:
- Confidence: Low / Medium / High

## Scope
- [ ]

## Out of scope
- [ ]

## Assumptions
- [ ]

## Risks
- [ ]

## Verification
- [ ] Unit tests:
- [ ] Integration tests:
- [ ] Manual check:

## Actual result
- Started:
- Merged:
- Extra work found:
- What to adjust next time:

Bagian Actual result membuat estimasi berikutnya berbasis pembelajaran, bukan opini.

CTA Konsultasi

Estimasi cocok untuk konsultasi karena setiap pembaca perlu menyesuaikan workflow dengan repository, bahasa klien, dan aturan timnya. ClaudeCodeLab dapat membantu membuat template estimasi, prompt review Claude Code, checklist PR, dan aturan rollout tim. Jika ingin menghubungkannya ke issue atau proposal milikmu, kirim konteks lewat training dan konsultasi Claude Code.

Hasil Praktik

Masa menguji workflow ini pada perubahan kecil field profil. Perkiraan awal adalah “setengah hari UI”. Setelah repo scan, muncul DB schema, API validation, CSV export, audit log, test, dan review queue. Range siap klien menjadi likely 4-5 hari kerja, dengan high case 7 hari jika CRM muncul. Claude Code berguna bukan karena menebak tanggal, melainkan karena membuka file tersembunyi dan unknowns sejak awal.