Framework DACI: Cara Membuat Keputusan Tim Tanpa Kebanyakan Drama

Di project nyata, keputusan kecil bisa berubah jadi masalah besar kalau tidak jelas siapa yang punya keputusan.

Contohnya sederhana: tim mau menentukan stack, fitur, desain, payment gateway, CMS, atau cara deploy. Semua orang punya pendapat. Meeting jalan. Diskusi panjang. Tapi setelah itu masih muncul pertanyaan yang sama: “Jadi kita pakai yang mana?”

Masalahnya sering bukan karena tim kurang pintar atau kurang diskusi. Masalahnya karena keputusan tidak punya pemilik.

Di situ framework DACI bisa membantu.

Diagram explaining the four DACI roles: Driver, Approver, Contributor, and Informed — Empat role utama dalam DACI: Driver menggerakkan proses, Approver mengambil keputusan, Contributor memberi masukan, dan Informed menerima update.

Apa Itu DACI?

DACI adalah framework untuk membuat proses pengambilan keputusan lebih jelas. Namanya berasal dari empat role:

Driver
Approver
Contributors
Informed

Framework ini sering dipakai saat keputusan melibatkan banyak orang, banyak konteks, dan punya dampak ke pekerjaan tim. Tujuannya bukan membuat proses jadi kaku, tapi membuat diskusi punya arah.

Kalau tanpa struktur, semua orang bisa merasa punya hak menentukan. Akhirnya keputusan jadi lambat, bolak-balik, atau berubah karena ada satu suara baru yang muncul belakangan.

DACI membantu menjawab empat pertanyaan penting:

Siapa yang menggerakkan proses keputusan?
Siapa yang punya keputusan final?
Siapa yang perlu memberi masukan?
Siapa yang cukup diberi tahu hasilnya?

Kenapa Keputusan Tim Sering Macet?

Dalam project web development, keputusan jarang berdiri sendiri. Satu keputusan bisa menyentuh desain, development, SEO, performance, budget, timeline, bahkan operasional setelah website live.

Misalnya tim sedang menentukan apakah website harus pakai WordPress, Laravel, Astro, atau headless CMS.

Developer mungkin melihat dari sisi maintainability dan performance. Designer melihat dari fleksibilitas layout. Client melihat dari kemudahan edit konten. Project manager melihat dari timeline. Owner bisnis melihat dari biaya dan risiko.

Semua masukan itu valid. Tapi kalau tidak ada role yang jelas, diskusi bisa berputar di tempat yang sama.

Note

DACI bukan framework untuk menghilangkan diskusi. Justru sebaliknya, DACI membuat diskusi lebih sehat karena semua orang tahu kapan harus memberi input dan siapa yang bertanggung jawab mengambil keputusan final.

Role di Dalam DACI

Driver

Driver adalah orang yang menggerakkan proses keputusan dari awal sampai selesai.

Tugas driver bukan selalu memutuskan. Tugas driver adalah memastikan prosesnya jalan:

mengumpulkan konteks
menjelaskan masalah
mengundang orang yang tepat
menyusun opsi
meminta input
menjaga deadline
mendokumentasikan keputusan

Kalau diibaratkan project, driver adalah orang yang memastikan keputusan tidak menggantung.

Contoh: seorang web developer bisa menjadi driver saat tim perlu memilih pendekatan teknis untuk revamp website. Ia mengumpulkan requirement, membandingkan opsi, melihat risiko, lalu membawa rekomendasi ke approver.

Approver

Approver adalah orang yang punya keputusan final.

Dalam DACI, idealnya approver tidak terlalu banyak. Kalau semua orang menjadi approver, artinya tidak ada approver yang jelas.

Approver harus punya otoritas dan konteks yang cukup untuk mengambil keputusan. Ia boleh mendengar banyak masukan, tapi pada akhirnya ia yang mengatakan:

Kita ambil opsi ini.

Di project client, approver bisa owner, lead, project manager, atau stakeholder yang memang bertanggung jawab terhadap hasil akhirnya.

Contributors

Contributors adalah orang-orang yang memberi masukan.

Mereka biasanya punya pengetahuan, pengalaman, atau data yang dibutuhkan agar keputusan tidak asal. Contributor bisa berasal dari developer, designer, SEO specialist, marketing, finance, operations, atau user yang akan memakai sistemnya.

Yang penting: contributor memberi input, bukan memegang keputusan final.

Ini penting karena banyak project macet saat contributor berubah menjadi veto. Semua orang bisa memberi pendapat, tapi tidak semua pendapat harus menghentikan keputusan.

Informed

Informed adalah orang-orang yang perlu tahu hasil keputusan, tapi tidak perlu ikut semua proses diskusi.

Role ini sering diremehkan, padahal penting. Banyak miskomunikasi terjadi karena keputusan sudah dibuat, tapi orang yang terdampak tidak tahu.

Contoh informed:

developer lain yang akan melanjutkan implementasi
tim content yang perlu menyesuaikan flow
tim support yang perlu tahu perubahan fitur
client internal yang tidak ikut meeting teknis

Mereka tidak harus ikut semua meeting, tapi harus menerima ringkasan keputusan yang jelas.

Ringkasan Role DACI

Role	Tanggung Jawab	Kesalahan Umum
Driver	Menggerakkan proses, mengumpulkan konteks, menjaga deadline, dan mendokumentasikan keputusan.	Dianggap sebagai orang yang otomatis membuat keputusan final.
Approver	Mengambil keputusan final setelah melihat konteks dan masukan.	Terlalu banyak approver sampai keputusan tetap tidak jelas.
Contributors	Memberi masukan, data, risiko, dan sudut pandang yang relevan.	Masukan berubah menjadi veto untuk semua keputusan.
Informed	Menerima hasil keputusan dan konteks yang perlu diketahui.	Tidak diberi update, lalu bingung saat implementasi berjalan.

Contoh DACI di Project Website

Bayangkan ada project revamp website company profile.

Masalahnya: website lama lambat, konten sulit diedit, dan client ingin tampilan baru yang lebih rapi. Tim harus memutuskan platform yang dipakai.

Pilihan:

tetap pakai custom code
pindah ke WordPress
pakai headless CMS
pakai static site generator

Kalau memakai DACI, pembagian role bisa seperti ini:

Decision:
Menentukan platform untuk revamp website company profile.

Driver:
Web Developer

Approver:
Project Manager atau client decision maker

Contributors:
Designer, SEO specialist, content team, backend developer

Informed:
Tim support, tim content, stakeholder yang terdampak

Driver mengumpulkan requirement dan trade-off:

siapa yang akan update konten
apakah butuh katalog produk
apakah butuh multi language
apakah butuh payment
apakah SEO menjadi prioritas besar
apakah client punya tim teknis
bagaimana kebutuhan maintenance setelah live

Setelah itu driver membawa rekomendasi. Contributor memberi masukan. Approver mengambil keputusan final. Informed menerima ringkasan keputusan dan alasan kenapa pilihan itu diambil.

Hasilnya bukan cuma “kita pakai WordPress”, tapi:

Kita pakai WordPress karena client butuh update konten sendiri, ada kebutuhan katalog produk, timeline terbatas, dan maintenance setelah live harus mudah dilakukan oleh tim non-teknis.

Keputusan seperti ini lebih kuat karena punya alasan, bukan sekadar preferensi.

Kapan DACI Perlu Dipakai?

Tidak semua hal perlu DACI.

Kalau keputusannya kecil, reversible, dan dampaknya rendah, cukup putuskan langsung. Misalnya memilih nama class, posisi spacing kecil, atau wording minor yang bisa diganti kapan saja.

DACI lebih cocok untuk keputusan yang:

melibatkan banyak stakeholder
berdampak ke timeline atau budget
sulit diubah setelah berjalan
punya risiko teknis atau bisnis
sering memicu diskusi berulang
butuh dokumentasi agar tidak diperdebatkan lagi

Dalam web development, DACI cocok dipakai untuk:

memilih stack atau platform
menentukan scope fitur
memutuskan CMS
memilih payment gateway
menentukan strategi multi language
mengubah flow checkout
menentukan prioritas sprint
memutuskan migrasi besar
memilih pendekatan SEO teknis
menentukan apakah fitur custom layak dibuat

Template DACI Sederhana

Kamu tidak perlu tool khusus untuk mulai memakai DACI. Bisa pakai Notion, Google Docs, Markdown, issue tracker, atau dokumen project biasa.

Template sederhana:

Decision:
Apa keputusan yang perlu dibuat?

Deadline:
Kapan keputusan harus final?

Status:
Draft / Waiting input / Decided

Driver:
Siapa yang menggerakkan proses?

Approver:
Siapa yang mengambil keputusan final?

Contributors:
Siapa yang perlu memberi masukan?

Informed:
Siapa yang perlu tahu hasilnya?

Context:
Kenapa keputusan ini perlu dibuat?

Options:
Apa saja pilihan yang tersedia?

Recommendation:
Opsi mana yang direkomendasikan dan kenapa?

Final Decision:
Apa keputusan finalnya?

Follow-up:
Apa tindakan setelah keputusan dibuat?

Bagian paling penting menurut saya adalah context, options, recommendation, dan final decision. Karena dari sana kita bisa melihat apakah keputusan dibuat berdasarkan data atau cuma karena “kayaknya lebih enak”.

DACI vs RACI

DACI sering terdengar mirip dengan RACI, tapi fokusnya beda.

RACI biasanya dipakai untuk pembagian tanggung jawab pekerjaan:

Responsible
Accountable
Consulted
Informed

Sementara DACI lebih fokus ke pengambilan keputusan:

Driver
Approver
Contributors
Informed

Sederhananya:

Framework	Fokus	Cocok Untuk
RACI	Menjelaskan siapa yang mengerjakan dan bertanggung jawab atas pekerjaan.	Eksekusi task, proses operasional, pembagian kerja.
DACI	Menjelaskan siapa yang menggerakkan, memutuskan, memberi input, dan menerima update keputusan.	Keputusan project, pilihan teknis, scope, strategi, dan prioritas.

Kalau masalahnya adalah “siapa yang mengerjakan ini?”, RACI lebih cocok.

Kalau masalahnya adalah “siapa yang memutuskan ini?”, DACI lebih cocok.

Kesalahan Umum Saat Memakai DACI

1. Terlalu Banyak Approver

Ini kesalahan paling umum.

Kalau ada lima approver, keputusan bisa tetap lambat karena semua orang merasa harus setuju. DACI bekerja lebih baik saat final decision owner jelas.

2. Driver Tidak Punya Deadline

Driver tanpa deadline bisa membuat proses tetap menggantung.

Keputusan harus punya batas waktu, terutama kalau keputusan itu memblokir development.

3. Contributor Dianggap Harus Setuju Semua

Contributor memberi masukan. Mereka tidak selalu harus puas dengan keputusan final.

Yang penting input mereka didengar dan dipertimbangkan.

4. Informed Tidak Diberi Konteks

Mengirim pesan “kita pakai opsi A” kadang tidak cukup.

Lebih baik sertakan alasan singkat:

Kita pakai opsi A karena lebih cepat untuk timeline sekarang, lebih mudah dikelola client, dan risikonya lebih rendah untuk maintenance.

5. Keputusan Tidak Ditulis

Keputusan yang tidak ditulis gampang berubah menjadi debat ulang.

Dokumentasi keputusan tidak perlu panjang. Yang penting jelas:

apa yang diputuskan
siapa approver-nya
kapan diputuskan
kenapa keputusan itu diambil
apa follow-up setelahnya

Cara Mulai Memakai DACI di Tim Kecil

Kalau tim masih kecil, jangan dibuat terlalu berat.

Mulai dari format singkat:

Decision:
Driver:
Approver:
Contributors:
Informed:
Recommendation:
Final:

Pakai hanya untuk keputusan yang benar-benar penting. Kalau setiap hal kecil dibuat DACI, framework ini malah jadi beban.

Untuk saya, nilai utama DACI ada di clarity. Ia memaksa kita untuk jujur:

siapa yang sebenarnya punya keputusan?
siapa yang hanya perlu memberi input?
siapa yang perlu tahu hasilnya?
apa alasan keputusan ini?

Pertanyaan-pertanyaan itu sederhana, tapi bisa mengurangi banyak drama project.

Penutup

Framework DACI membantu tim membuat keputusan dengan lebih rapi.

Bukan karena framework ini membuat keputusan otomatis benar, tapi karena ia membuat prosesnya jelas. Ada orang yang menggerakkan, ada orang yang memutuskan, ada orang yang memberi masukan, dan ada orang yang menerima informasi.

Di project web development, kejelasan seperti ini sangat berguna. Banyak masalah teknis sebenarnya bukan murni masalah teknis. Kadang masalahnya adalah keputusan yang menggantung, scope yang berubah tanpa pemilik, atau stakeholder yang tidak tahu kenapa sesuatu dipilih.

DACI tidak perlu dipakai untuk semua hal. Tapi untuk keputusan yang berdampak besar, framework ini bisa menjadi cara sederhana untuk membuat tim bergerak lebih cepat dan lebih jelas.