Tiếng Việt: Tradeoff Analysis Decisions

Một buổi chiều thứ Năm, sếp hỏi: "Tính năng export báo cáo, mình build (tự xây) hay buy (mua giải pháp có sẵn)?" Bạn có 48 giờ để trả lời trước cuộc họp roadmap quý sau. Đây là kiểu quyết định mà mọi BA/PM/PO đều gặp hàng tuần, không phải hàng năm: build vs buy, làm ngay hay để sau (now-vs-later), cắt scope nào khi deadline dí sát nút. Vấn đề không nằm ở việc thiếu framework — RICE, ICE, WSJF đã có sẵn ở các bài trước — mà nằm ở chỗ những quyết định "khó cân" này thường có nhiều tiêu chí mâu thuẫn nhau, thiếu dữ liệu đầy đủ, và dễ bị chi phối bởi ý kiến to tiếng nhất trong phòng thay vì bằng chứng. Một quyết định trade-off tệ không lộ ra ngay lập tức — nó âm thầm gây hậu quả sau 3-6 tháng, khi bạn nhận ra mình đã chọn sai vendor, hoặc đã trì hoãn một tính năng lẽ ra phải làm ngay.

AI không ra quyết định thay bạn — quyết định vẫn là trách nhiệm của PM/PO, và cuối cùng vẫn cần con người chịu trách nhiệm giải trình. Nhưng AI có thể giúp bạn cấu trúc hóa vấn đề nhanh hơn, liệt kê đầy đủ tiêu chí hơn, tính điểm nhất quán hơn, đóng vai phản biện (devil's advocate) để lật lại giả định của chính bạn, và viết lại toàn bộ quá trình ra quyết định thành tài liệu có thể tra cứu sau này. Bài này đi qua bốn mảng: cấu trúc hóa các loại trade-off phổ biến nhất, xây decision matrix (ma trận quyết định) có trọng số, dùng AI để stress-test (kiểm tra chịu áp lực) quyết định trước khi công bố, và ghi lại quyết định bằng ADR (Architecture/Decision Record — hồ sơ quyết định) để không ai phải hỏi lại "tại sao hồi đó mình chọn thế này" sau sáu tháng.

Làm Sao Dùng AI Để Cấu Trúc Hóa Các Quyết Định Build-vs-Buy, Now-vs-Later, Và Cắt Scope?

Ba loại trade-off này chiếm phần lớn thời gian ra quyết định thực tế của một PM/PO, nhưng mỗi loại có bộ câu hỏi cấu trúc khác nhau. Sai lầm phổ biến nhất là nhảy thẳng vào tranh luận cảm tính ("tôi nghĩ nên mua vì rẻ hơn") mà không liệt kê hết các biến số cần cân nhắc trước. AI rất mạnh ở bước này: nó có thể lấy một câu hỏi mơ hồ và biến thành một bộ khung câu hỏi đầy đủ, dựa trên hàng ngàn case study mẫu nó đã học được, nhanh hơn nhiều so với việc bạn tự brainstorm từ đầu.

Build-vs-Buy: Không Chỉ Là So Sánh Giá

Câu hỏi build-vs-buy tưởng đơn giản nhưng thực chất có ít nhất 6-7 trục cần cân: chi phí ban đầu, chi phí vận hành dài hạn (TCO — Total Cost of Ownership), thời gian ra thị trường (time-to-market), mức độ kiểm soát và tùy biến, rủi ro phụ thuộc vendor (vendor lock-in), khả năng mở rộng (scalability), và mức độ phù hợp với core competency (năng lực cốt lõi) của công ty. Một PM thiếu kinh nghiệm thường chỉ so sánh giá license với chi phí dev-month, bỏ qua chi phí bảo trì, chi phí tích hợp, và rủi ro nếu vendor ngừng hỗ trợ sau 2 năm.

Now-vs-Later: Chi Phí Cơ Hội Là Biến Số Ẩn

Quyết định làm ngay hay để sau không chỉ là bài toán ưu tiên (đã có RICE/WSJF xử lý phần đó), mà còn liên quan đến cost of delay (chi phí trì hoãn) — nếu để sau, công ty mất gì mỗi tuần/tháng chờ đợi? Có tính năng để sau 1 quý không sao, có tính năng để sau 1 tuần đã mất khách vào tay đối thủ. Trục thứ hai là dependency: tính năng này có đang chặn (block) tính năng khác chưa làm được không?

Cắt Scope Dưới Áp Lực Deadline

Đây là tình huống căng thẳng nhất: deadline không đổi, nhưng scope ban đầu không kịp làm hết. PM phải quyết định cắt gì, giữ gì, trong khi mỗi stakeholder đều nghĩ phần của mình quan trọng nhất. Cấu trúc hóa ở đây nghĩa là tách bạch giữa "must-have cho MVP hoạt động được" và "nice-to-have có thể release sau ở v1.1", dựa trên tiêu chí khách quan chứ không phải ai la to hơn.

Các Bước Thực Hành

1. Xác định loại quyết định — trước khi hỏi AI bất cứ điều gì, tự trả lời: đây là build-vs-buy, now-vs-later, hay scope-cut? Mỗi loại cần prompt khác nhau vì bộ tiêu chí khác nhau.
2. Thu thập input thô — gom lại: mô tả bài toán, 2-3 phương án đang cân nhắc, ràng buộc đã biết (ngân sách, deadline, đội ngũ hiện có), và dữ liệu định lượng nếu có (chi phí, effort estimate theo story point).
3. Yêu cầu AI liệt kê đầy đủ tiêu chí trước khi cho ý kiến — bước quan trọng nhất, tránh để AI nhảy thẳng vào kết luận khi chưa đủ khung.
4. Yêu cầu AI chỉ ra thông tin còn thiếu — AI nên tự nói "tôi cần thêm dữ liệu X, Y để đánh giá chính xác hơn" thay vì giả định liều.
5. Đối chiếu kết quả với thực tế nội bộ — bản thân PM/PO luôn phải review lại output AI, bổ sung ngữ cảnh chính trị nội bộ (ví dụ: sếp đã hứa deadline này với khách VIP) mà AI không thể biết.
6. Lưu output vào Notion/Confluence ngay, dùng làm input cho bước xây decision matrix ở phần sau.

Ví Dụ Prompt

Bạn là một Product Advisor có 15 năm kinh nghiệm tư vấn quyết định
build-vs-buy cho các công ty SaaS B2B.

Bài toán: Chúng tôi cần tính năng "xuất báo cáo tài chính dạng PDF
tùy biến" cho khách hàng doanh nghiệp. Team có 2 backend dev, 1
frontend dev rảnh trong 6 tuần tới. Có 3 vendor SaaS cung cấp API
report-generation với giá từ $300-$900/tháng.

Hãy:
1. Liệt kê đầy đủ các tiêu chí cần cân nhắc cho quyết định build-vs-buy
   này (tối thiểu 7 tiêu chí: chi phí ban đầu, TCO 12 tháng, time-to-
   market, mức độ tùy biến, vendor lock-in, khả năng mở rộng, mức độ
   phù hợp với core competency của công ty tôi).
2. Với mỗi tiêu chí, đặt câu hỏi cụ thể tôi cần trả lời để đánh giá
   (không tự trả lời thay tôi).
3. Chỉ ra thông tin nào tôi đang thiếu để ra quyết định chính xác.
4. Đề xuất 2-3 câu hỏi tôi nên hỏi vendor trước khi quyết định "buy".

Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ tiếng Anh (TCO,
time-to-market, vendor lock-in, v.v.).

Bạn là Senior PM tư vấn về quyết định cắt scope dưới áp lực deadline.

Bối cảnh: Sprint cuối cùng trước khi demo cho nhà đầu tư, còn 5 ngày
làm việc. Scope ban đầu gồm 8 hạng mục (liệt kê bên dưới), team ước
tính chỉ làm được 5/8 trong thời gian còn lại.

[DÁN DANH SÁCH 8 HẠNG MỤC + ƯỚC TÍNH EFFORT (STORY POINT/NGÀY) CHO
MỖI HẠNG MỤC]

Hãy:
1. Phân loại từng hạng mục vào 1 trong 3 nhóm: Must-have (demo không
   chạy được nếu thiếu), Should-have (làm giảm chất lượng demo rõ rệt
   nếu thiếu), Nice-to-have (không ảnh hưởng demo).
2. Với các hạng mục Must-have, tính tổng effort — nếu vượt quá năng
   lực 5 ngày còn lại, cảnh báo rõ ràng và đề xuất phương án (giảm
   phạm vi kỹ thuật của must-have, thêm người, hay đổi ngày demo).
3. Đề xuất scope cuối cùng cho 5 ngày còn lại, kèm rủi ro nếu áp dụng
   phương án này.

Mẹo: Đừng để AI liệt kê tiêu chí xong là dừng lại. Luôn hỏi thêm "tiêu chí nào trong danh sách này quan trọng nhất trong bối cảnh công ty giai đoạn Series A, ưu tiên tốc độ hơn là ổn định dài hạn?" — bối cảnh giai đoạn công ty (startup mới gọi vốn vs công ty enterprise đã ổn định) thay đổi hoàn toàn trọng số của từng tiêu chí, và đây là thứ chỉ PM mới biết rõ, AI cần được nhắc mới áp dụng đúng.

Dùng AI Để Tạo Decision Matrix Với Trọng Số (Weighted Criteria)

Sau khi đã có đầy đủ tiêu chí, bước tiếp theo là lượng hóa chúng thành một decision matrix — công cụ kinh điển giúp biến một cuộc tranh luận cảm tính thành một bảng điểm có thể tranh luận dựa trên con số, không phải dựa trên ai nói to hơn trong họp.

Cấu Trúc Một Decision Matrix Chuẩn

Một decision matrix có trọng số gồm: danh sách phương án (option) theo hàng, danh sách tiêu chí theo cột, mỗi tiêu chí có một trọng số (weight, thường tính theo % hoặc thang 1-5), mỗi phương án được chấm điểm theo từng tiêu chí (thường thang 1-5 hoặc 1-10), và điểm tổng = Σ(điểm × trọng số).

Ví dụ minh họa cho bài toán build-vs-buy ở trên — giả sử 3 tiêu chí được rút gọn để dễ hình dung: Chi phí 12 tháng (trọng số 30%), Time-to-market (trọng số 40%), Mức độ tùy biến (trọng số 30%):

Với ví dụ này, Vendor B thắng dù không phải phương án tùy biến cao nhất — vì trọng số time-to-market cao nhất và chi phí thấp nhất trong 3 lựa chọn. Đây chính là giá trị của decision matrix: nó buộc bạn tường minh hóa cái gì quan trọng hơn cái gì, thay vì để trực giác quyết định ngầm.

Các Bước Thực Hành

1. Thống nhất danh sách tiêu chí trước (đã làm ở phần trước) — không thêm/bớt tiêu chí giữa chừng khi đang chấm điểm, tránh thiên vị ngược để ra kết quả mong muốn từ trước.
2. Gán trọng số cùng với stakeholder liên quan, không tự làm một mình — mời ít nhất Engineering Lead và 1 stakeholder kinh doanh cùng thống nhất trọng số trước khi chấm điểm từng phương án, tránh tình huống "tôi chỉnh trọng số cho ra kết quả tôi thích".
3. Dùng AI để chấm điểm nháp ban đầu dựa trên dữ liệu bạn cung cấp, sau đó con người review và điều chỉnh — AI không nên là người quyết điểm cuối cùng cho các tiêu chí mang tính chủ quan (như "mức độ phù hợp văn hóa công ty").
4. Yêu cầu AI giải thích lý do đằng sau mỗi điểm số, không chỉ đưa con số — nếu AI không giải thích được vì sao Vendor A được 5/5 time-to-market, đó là dấu hiệu điểm số thiếu căn cứ.
5. Chạy sensitivity analysis (phân tích độ nhạy) — thử thay đổi trọng số ±10-15% xem kết quả cuối có đổi phương án thắng không; nếu thay đổi nhỏ trọng số đã đảo ngược kết quả, đó là tín hiệu quyết định đang "sát nút" và cần thêm dữ liệu trước khi chốt.
6. Trình bày matrix cho stakeholder cùng phần giải thích, không chỉ gửi bảng số — con số một mình không thuyết phục ai, câu chuyện đằng sau con số mới thuyết phục.

Ví Dụ Prompt

Bạn là chuyên gia phân tích quyết định (decision analyst) cho sản
phẩm B2B SaaS.

Tôi cần xây decision matrix có trọng số để so sánh 3 phương án sau
cho bài toán "xuất báo cáo PDF": Build nội bộ, Vendor A ($900/tháng,
API mạnh, hỗ trợ tốt), Vendor B ($300/tháng, API cơ bản, ít tùy biến).

Tiêu chí và trọng số đã thống nhất với team:
- Chi phí 12 tháng: 30%
- Time-to-market: 40%
- Mức độ tùy biến: 30%

Dữ liệu tham khảo:
[DÁN SỐ LIỆU CHI PHÍ, ƯỚC TÍNH THỜI GIAN TRIỂN KHAI CHO TỪNG PHƯƠNG ÁN]

Hãy:
1. Chấm điểm mỗi phương án theo từng tiêu chí (thang 1-5), kèm lý do
   ngắn gọn cho từng điểm số dựa trên dữ liệu tôi cung cấp.
2. Tính điểm tổng có trọng số, xuất bảng Markdown đầy đủ.
3. Chạy sensitivity analysis: nếu trọng số Time-to-market giảm xuống
   25% và Chi phí tăng lên 45%, kết quả có đổi phương án thắng không?
4. Đưa ra khuyến nghị cuối cùng, nêu rõ điều kiện nào sẽ khiến khuyến
   nghị này thay đổi.

Trả lời bằng tiếng Việt, giữ thuật ngữ tiếng Anh (decision matrix,
weighted criteria, sensitivity analysis, TCO).

Tôi vừa dùng Notion AI/Claude để tạo decision matrix cho quyết định
"Now vs Later" của tính năng Single Sign-On (SSO).

[DÁN DECISION MATRIX ĐÃ TẠO]

Hãy đóng vai một Head of Product review lại matrix này và chỉ ra:
1. Tiêu chí nào có vẻ bị đánh giá quá cao hoặc quá thấp so với thực
   tế ngành SaaS B2B (ví dụ: có công ty đánh giá thấp risk mất deal
   enterprise nếu thiếu SSO).
2. Có tiêu chí quan trọng nào bị bỏ sót không (ví dụ: yêu cầu compliance
   như SOC 2 có thể bắt buộc phải có SSO sớm hơn dự kiến).
3. Đề xuất điều chỉnh trọng số nếu cần, kèm lý do.

Mẹo: Luôn giới hạn số lượng tiêu chí trong matrix ở mức 5-7. Nhiều PM có xu hướng nhồi 12-15 tiêu chí vì sợ bỏ sót, nhưng càng nhiều tiêu chí, trọng số của từng tiêu chí càng loãng và kết quả cuối càng khó diễn giải cho stakeholder không chuyên. Nếu có nhiều hơn 7 tiêu chí ứng viên, hãy dùng AI để gom nhóm chúng thành các nhóm lớn hơn (ví dụ gom "chi phí license" + "chi phí bảo trì" thành một tiêu chí "TCO 12 tháng").

Dùng AI Làm Devil's Advocate — Kiểm Tra Chịu Áp Lực Quyết Định Và Phát Hiện Điểm Mù

Decision matrix cho bạn một con số, nhưng con số đó chỉ tốt bằng chất lượng của input và giả định đưa vào. Một trong những cách dùng AI hiệu quả nhất mà nhiều PM chưa khai thác đủ là biến nó thành devil's advocate (người phản biện có chủ đích) — một vai trò chuyên tìm lỗ hổng, thách thức giả định, và hỏi những câu hỏi khó chịu mà không ai trong phòng họp muốn hỏi vì sợ mất lòng đồng nghiệp.

Vì Sao Con Người Thường Ngại Đóng Vai Phản Biện

Trong nội bộ team, việc phản biện quyết định của sếp hoặc đồng nghiệp thân thiết luôn có rủi ro chính trị — không ai muốn là người duy nhất nói "tôi nghĩ quyết định này sai" giữa cuộc họp mà cả phòng đã đồng thuận. Hiện tượng này gọi là groupthink (tư duy tập thể), và nó là nguyên nhân hàng đầu khiến các quyết định trade-off tệ vẫn được thông qua dù có đủ dữ liệu để nhận ra vấn đề từ trước. AI không có rủi ro chính trị này — nó có thể được giao nhiệm vụ "hãy tìm mọi lý do quyết định này có thể sai" mà không sợ bị ai giận.

Ba Loại Điểm Mù AI Có Thể Giúp Phát Hiện

1. Giả định chưa kiểm chứng — ví dụ giả định "khách hàng sẽ chấp nhận UI mới" chưa từng được test với user thật.
2. Thiên vị xác nhận (confirmation bias) — PM đã thích một phương án từ đầu và vô tình chọn dữ liệu ủng hộ phương án đó, bỏ qua dữ liệu trái chiều.
3. Rủi ro dài hạn bị đánh giá thấp vì áp lực ngắn hạn — ví dụ chọn vendor rẻ ngay bây giờ nhưng bỏ qua rủi ro vendor lock-in sẽ đắt gấp 3 lần khi muốn chuyển đổi sau 2 năm.

Các Bước Thực Hành

1. Hoàn thiện quyết định nháp trước (từ decision matrix ở phần trước) — đừng dùng devil's advocate ngay từ đầu khi còn chưa có phương án cụ thể để phản biện.
2. Giao vai trò rõ ràng cho AI — chỉ định cụ thể "hãy đóng vai CFO hoài nghi" hoặc "hãy đóng vai Head of Engineering từng bị vendor bỏ rơi giữa chừng", vai trò càng cụ thể, phản biện càng sắc.
3. Yêu cầu AI liệt kê giả định ẩn trong lập luận của bạn — đây là bước giá trị nhất, vì con người thường không nhận ra chính mình đang giả định điều gì.
4. Yêu cầu kịch bản thất bại (failure scenario) — hỏi AI "nếu quyết định này sai sau 6 tháng, nguyên nhân nhiều khả năng nhất là gì?"
5. Đối chiếu phản biện với dữ liệu thật — không phải mọi điểm AI nêu ra đều đáng lo, PM cần lọc lại xem điểm nào thực sự có rủi ro cao trong bối cảnh cụ thể của công ty mình.
6. Ghi lại các phản biện đã cân nhắc (kể cả những cái bị bác bỏ) vào ADR ở bước tiếp theo — đây là bằng chứng cho thấy quyết định đã được stress-test kỹ, không phải ra quyết định hời hợt.

Ví Dụ Prompt

Tôi vừa quyết định chọn Vendor B ($300/tháng) thay vì build nội bộ
cho tính năng xuất báo cáo PDF, dựa trên decision matrix có điểm tổng
Vendor B = 3.7, Build = 2.5.

Hãy đóng vai một CFO hoài nghi, từng bị 2 vendor bỏ rơi giữa chừng
trong quá khứ và luôn nghi ngờ các quyết định "chọn rẻ ngay bây giờ".

Nhiệm vụ của bạn:
1. Liệt kê tất cả giả định chưa được kiểm chứng trong quyết định này
   (ví dụ: giả định Vendor B sẽ ổn định về giá trong 12 tháng tới,
   giả định API của Vendor B đủ ổn định cho nhu cầu tăng trưởng).
2. Đưa ra kịch bản thất bại khả dĩ nhất nếu quyết định này sai — mô tả
   cụ thể điều gì xảy ra sau 6 tháng, không nói chung chung.
3. Hỏi tôi 5 câu hỏi khó mà tôi chưa trả lời được trong lập luận hiện
   tại, buộc tôi phải đi tìm thêm dữ liệu trước khi chốt.
4. Nếu có, chỉ ra dấu hiệu tôi đang bị confirmation bias (thiên vị vì
   đã thích phương án này từ đầu).

Đừng khách sáo, hãy phản biện thẳng thắn như một CFO thực sự làm.

Đây là toàn bộ lập luận và dữ liệu tôi dùng để quyết định trì hoãn
tính năng SSO sang quý sau (KHÔNG làm now, để later):

[DÁN LẬP LUẬN + DECISION MATRIX]

Hãy đóng vai Head of Sales, người sẽ mất 2 deal enterprise nếu SSO
không có trong quý này. Phản biện quyết định trên bằng cách:
1. Chỉ ra chi phí cơ hội (cost of delay) mà lập luận hiện tại có thể
   đang đánh giá thấp.
2. Đặt câu hỏi về nguồn dữ liệu — dữ liệu nào trong lập luận là ước
   tính chủ quan, chưa có bằng chứng cụ thể?
3. Đề xuất phương án thỏa hiệp (nếu có) mà lập luận ban đầu chưa xét
   đến, ví dụ triển khai SSO giới hạn cho 2 khách hàng đang chờ trước.

Mẹo: Chạy devil's advocate hai lượt với hai vai trò khác nhau (ví dụ CFO và Head of Engineering) thường lộ ra nhiều điểm mù hơn chạy một lượt với vai trò chung chung "hãy phản biện quyết định này". Mỗi vai trò có một bộ ưu tiên khác nhau (CFO lo chi phí dài hạn, Engineering lo nợ kỹ thuật), và sự khác biệt góc nhìn đó chính là thứ giúp bạn nhìn thấy toàn cảnh thay vì chỉ một lát cắt.

Ghi Lại Quyết Định — Tạo ADR Và Decision Log Với AI

Một quyết định trade-off tốt mà không được ghi lại rõ ràng sẽ bị lãng quên, và 6 tháng sau, khi có người mới join team hỏi "tại sao mình chọn Vendor B thay vì build nội bộ?", không ai còn nhớ lý do — hoặc tệ hơn, mỗi người nhớ một phiên bản khác nhau. ADR (Architecture/Decision Record — hồ sơ quyết định) là công cụ vay mượn từ giới kỹ thuật (ban đầu dùng để ghi lại quyết định kiến trúc phần mềm), nhưng áp dụng cực kỳ tốt cho các quyết định product/business trade-off, vì nó buộc người viết trình bày đủ 5 phần: bối cảnh, quyết định, lý do, phương án đã cân nhắc, và hệ quả.

Vì Sao ADR Quan Trọng Hơn Một Email Thông Báo Quyết Định

Một email "Team ơi, mình quyết định chọn Vendor B nhé" trả lời được câu hỏi "quyết định gì" nhưng không trả lời được "tại sao", và hoàn toàn không lưu lại "đã cân nhắc phương án nào khác". ADR khắc phục cả ba vấn đề này bằng một cấu trúc chuẩn hóa, dễ tìm kiếm lại (searchable), và có thể tham chiếu chéo khi quyết định tương lai cần liên quan đến quyết định cũ.

Các Bước Thực Hành

1. Viết ADR ngay sau khi quyết định được chốt, không để quá 1-2 ngày — trí nhớ về lý do quyết định phai rất nhanh, đặc biệt là các phương án đã bị loại bỏ.
2. Dùng AI để nháp ADR từ toàn bộ nguyên liệu đã có — decision matrix, kết quả devil's advocate, và ghi chú họp — thay vì viết từ đầu bằng tay.
3. Yêu cầu AI viết phần "Alternatives Considered" đầy đủ, kể cả phương án bị loại, kèm lý do loại — đây là phần hay bị bỏ sót nhất khi con người tự viết vì có xu hướng chỉ ghi phương án được chọn.
4. Thêm "Review trigger" (điều kiện xem xét lại) rõ ràng — ví dụ "xem lại quyết định này nếu chi phí Vendor B tăng quá 50% hoặc SLA uptime giảm dưới 99%" — để ADR không bị coi là quyết định vĩnh viễn không thể đổi.
5. Lưu ADR vào một nơi tập trung, có đánh số (Confluence, Notion, hoặc thư mục /docs/adr/ trong repo) — đặt tên file theo chuẩn ADR-[ngày]-[chủ-đề] để dễ tìm và sắp theo thời gian.
6. Liên kết ADR với roadmap/backlog item liên quan — thêm link ADR vào ticket Jira tương ứng, để bất kỳ ai mở ticket cũng thấy được lý do quyết định.

Ví Dụ Prompt

Bạn là Product Lead, chuyên viết ADR (Architecture/Decision Record)
rõ ràng, súc tích cho các quyết định product trade-off.

Dưới đây là toàn bộ ngữ cảnh của một quyết định vừa được chốt:

- Bài toán: cần tính năng xuất báo cáo PDF cho khách hàng doanh nghiệp
- Các phương án đã xét: Build nội bộ, Vendor A ($900/tháng), Vendor B
  ($300/tháng)
- Decision matrix: [DÁN BẢNG ĐIỂM]
- Kết quả devil's advocate: [DÁN CÁC ĐIỂM RỦI RO ĐÃ ĐƯỢC NÊU RA VÀ
  CÁCH XỬ LÝ/CHẤP NHẬN TỪNG ĐIỂM]
- Quyết định cuối: chọn Vendor B

Hãy viết một ADR đầy đủ theo cấu trúc chuẩn: Context (Bối cảnh),
Decision (Quyết định), Rationale (Lý do), Alternatives Considered
(Phương án đã cân nhắc, kèm lý do loại từng phương án), Consequences
(Hệ quả, cả tích cực và tiêu cực), Review trigger (Điều kiện xem xét
lại quyết định này).

Viết bằng tiếng Việt, giữ nguyên các tiêu đề section bằng tiếng Anh
(Context, Decision, Rationale, Alternatives Considered, Consequences,
Review trigger) vì đây là chuẩn ADR được team kỹ thuật dùng chung.

Ví dụ một ADR hoàn chỉnh được tạo ra theo prompt trên (mẫu để tham khảo cấu trúc, có thể copy làm template):

## Context
Khách hàng doanh nghiệp (đặc biệt nhóm Enterprise tier) yêu cầu tính
năng xuất báo cáo tài chính dạng PDF tùy biến (logo công ty, chọn cột
dữ liệu, lịch xuất tự động hàng tháng). Đây là yêu cầu xuất hiện trong
6/10 deal enterprise gần nhất bị đối thủ nhắc tới như một tiêu chí so
sánh. Team có 2 backend dev + 1 frontend dev, năng lực khả dụng trong
6 tuần tới.

## Decision
Chọn tích hợp Vendor B (API report-generation, $300/tháng) thay vì
build nội bộ hoặc dùng Vendor A ($900/tháng).

## Rationale
Decision matrix có trọng số (Chi phí 30%, Time-to-market 40%, Tùy
biến 30%) cho điểm: Build nội bộ 2.5, Vendor A 3.2, Vendor B 3.7.
Vendor B thắng nhờ cân bằng tốt giữa chi phí thấp và thời gian triển
khai nhanh (ước tính 2 tuần thay vì 6-8 tuần nếu build nội bộ). Mức độ
tùy biến của Vendor B (3/5) được đánh giá là đủ dùng cho 90% use case
hiện tại của khách hàng, dựa trên khảo sát nhanh với 8 khách Enterprise.

## Alternatives Considered
- **Build nội bộ:** bị loại vì time-to-market quá chậm (6-8 tuần) so
  với áp lực deal đang chờ; mức độ tùy biến cao (5/5) không đủ bù đắp
  cho chi phí cơ hội mất deal trong lúc chờ.
- **Vendor A ($900/tháng):** bị loại vì chi phí cao hơn 3 lần Vendor B
  trong khi mức độ tùy biến thực tế không khác biệt đáng kể cho use
  case hiện tại; cân nhắc lại nếu nhu cầu tùy biến tăng cao trong
  tương lai (xem Review trigger).

## Consequences
Tích cực: ra mắt tính năng trong 2 tuần, kịp phục vụ 2 deal enterprise
đang chờ ký. Tiêu cực: phụ thuộc vào uptime và roadmap của Vendor B
(vendor lock-in); nếu Vendor B ngừng dịch vụ hoặc tăng giá đột ngột,
chi phí chuyển đổi sang phương án khác có thể tốn 3-4 tuần effort.

## Review trigger
Xem xét lại quyết định này nếu: (1) Vendor B tăng giá quá 50% trong
12 tháng tới, (2) SLA uptime của Vendor B giảm dưới 99% trong 2 quý
liên tiếp, (3) hơn 30% khách hàng yêu cầu tính năng tùy biến vượt quá
khả năng của Vendor B.

Duy Trì Một Decision Log Cho Cả Team

Bên cạnh ADR cho từng quyết định riêng lẻ, nên có một decision log (nhật ký quyết định) tổng hợp — một bảng đơn giản trong Confluence/Notion liệt kê tất cả quyết định trade-off quan trọng theo thời gian, mỗi dòng gồm: ngày, tên quyết định, link ADR chi tiết, người quyết định, trạng thái (đang hiệu lực/đã review lại/đã thay đổi). AI có thể giúp bạn duy trì log này bằng cách tự động tóm tắt ADR mới thành một dòng log, và định kỳ quét lại xem ADR nào đã đến hạn "Review trigger" mà chưa được xem xét.

Dưới đây là 8 ADR đã viết trong quý vừa qua:

[DÁN DANH SÁCH TÓM TẮT 8 ADR, MỖI ADR GỒM TIÊU ĐỀ, NGÀY, REVIEW TRIGGER]

Hôm nay là [NGÀY HIỆN TẠI]. Hãy:
1. Liệt kê ADR nào đã đến hoặc gần đến điều kiện Review trigger, cần
   được xem xét lại trong tháng này.
2. Tóm tắt mỗi ADR còn lại thành 1 dòng cho decision log (định dạng:
   Ngày | Quyết định | Trạng thái | Link).
3. Đề xuất 2-3 pattern lặp lại giữa các quyết định (ví dụ: nếu 3/8
   ADR đều chọn "buy" thay vì "build", đó có thể là tín hiệu công ty
   nên có chiến lược vendor tổng thể thay vì quyết định lẻ tẻ từng
   trường hợp).

Mẹo: Đừng viết ADR chỉ cho các quyết định "thành công". Quyết định nào sau này chứng minh là sai cũng nên có ADR ghi lại đầy đủ, kèm một mục bổ sung "Outcome" (kết quả thực tế) được cập nhật sau 3-6 tháng. Đây chính là nguồn dữ liệu quý giá nhất để bạn (và AI) học được pattern nào hay dẫn đến quyết định sai trong tổ chức của chính mình, thay vì lặp lại cùng một lỗi mỗi quý.

Những Điểm Chính Cần Nhớ

• Trade-off decision (build-vs-buy, now-vs-later, cắt scope) cần được cấu trúc hóa bằng bộ tiêu chí rõ ràng trước khi tranh luận phương án — AI giúp liệt kê đầy đủ tiêu chí nhanh hơn brainstorm thủ công, nhưng con người vẫn phải bổ sung ngữ cảnh nội bộ mà AI không biết.
• Decision matrix có trọng số biến tranh luận cảm tính thành con số có thể phản biện — giới hạn 5-7 tiêu chí, thống nhất trọng số cùng stakeholder trước khi chấm điểm, và luôn chạy sensitivity analysis để biết quyết định có "sát nút" hay không.
• Dùng AI làm devil's advocate với vai trò cụ thể (CFO, Head of Engineering, Head of Sales) để lật lại giả định ẩn và phát hiện confirmation bias — đây là cách rẻ nhất để stress-test quyết định trước khi nó trở thành hậu quả thật sau vài tháng.
• ADR ghi lại đủ 5 phần (Context, Decision, Rationale, Alternatives Considered, Consequences) cộng Review trigger giúp quyết định không bị lãng quên và có thể tra cứu lại khi cần — luôn viết ADR ngay sau khi chốt quyết định, kể cả cho các quyết định sau này chứng minh là sai.
• Duy trì decision log tổng hợp theo thời gian để nhìn ra pattern lặp lại trong tổ chức, biến từng quyết định đơn lẻ thành tài sản học hỏi dài hạn cho cả team.