MVP và ưu tiên tính năng: làm ít mà đúng

Bản đồ công trìnhTờ này lắp: Giao diện app, Màn hình bếp, Thanh toán VietQR

Bài nàyĐã họcChưa tớiĐã thay thế

Bạn sẽ học được gì

Tiêu chí nghiệm thu

Định nghĩa MVP đúng nghĩa và nhận ra các kiểu “MVP giả”.
Phân loại tính năng bằng MoSCoW và xếp hạng bằng RICE, biết giới hạn của từng công cụ.
Vẽ bản đồ user story (user story map) và cắt thành lát phát hành.
Viết danh sách non-goals (những gì không làm) kèm lý do và thời điểm xem lại.
Nhận diện và tránh cạm bẫy “AI làm nhanh nên làm luôn”.

MVP đúng nghĩa là gì?

MVP (Minimum Viable Product — sản phẩm khả dụng tối thiểu) là khái niệm được phổ biến rộng rãi qua phong trào Lean Startup: phiên bản sản phẩm cho phép bạn học được nhiều nhất về người dùng với ít công sức nhất. Hai chữ quan trọng là Minimum (tối thiểu) và Viable (khả dụng, sống được) — người ta hay nhớ chữ đầu và quên chữ sau.

Một hình ảnh quen thuộc trong giới làm sản phẩm: nếu khách cần đi lại, đừng giao một bánh xe, rồi một khung xe, rồi mới tới ô tô — vì bánh xe không dùng được. Hãy giao một chiếc xe trượt, rồi xe đạp, rồi xe máy. Mỗi phiên bản đều giải được việc “đi lại”, chỉ ở mức khác nhau.

Với phần mềm nội bộ như Mộc OMS, “khả dụng” có một định nghĩa rất thực tế:

MVP của Mộc OMS là phiên bản nhỏ nhất mà Hà, anh Tuấn và nhân viên một chi nhánh sẵn sàng bỏ Google Sheet và nhóm Zalo để dùng thật cho mọi đơn đặt trước trong 2 tuần liên tục.

Định nghĩa này lập tức loại bỏ rất nhiều thứ “hay” (báo cáo doanh thu, nhắc sinh nhật) và lập tức đòi hỏi vài thứ “chán” mà bạn có thể quên (đăng nhập theo vai trò, tìm lại đơn theo số điện thoại, sửa và hủy đơn). Nếu thiếu chức năng sửa đơn, nhân viên sẽ quay lại Sheet ngay khi khách đổi giờ nhận lần đầu tiên.

Kiểu “MVP giả”	Biểu hiện	Vì sao sai
MVP = bản demo đẹp	Giao diện bóng bẩy, dữ liệu giả, không ai dùng thật	Không học được gì về hành vi thật
MVP = bản đầy đủ làm ẩu	Có mọi tính năng, mỗi cái làm dở	Không “khả dụng” ở chỗ nào cả; nợ kỹ thuật lớn
MVP = một mảnh kỹ thuật	Xong database, chưa có màn hình nào dùng được	Người dùng không chạm vào được
MVP vô thời hạn	“Thêm cái này nữa rồi mới ra mắt”	Không bao giờ có dữ liệu thật để học

MoSCoW: phân loại bắt buộc và không bắt buộc

MoSCoW chia tính năng thành bốn nhóm:

Must have (phải có): thiếu thì MVP không khả dụng — người dùng không thể bỏ cách làm cũ.
Should have (nên có): quan trọng, nhưng có cách xoay xở tạm thời nếu chưa có.
Could have (có thể có): hay, nhưng thiếu cũng không ai phàn nàn nhiều.
Won’t have this time (lần này không làm): đã cân nhắc và chủ động gác lại.

Phép thử cho nhóm Must: “Nếu thiếu tính năng này, Hà có dùng Mộc OMS cho 100% đơn đặt trước trong 2 tuần không?” Nếu câu trả lời vẫn là “có”, đó không phải Must.

MoSCoW cho Mộc OMS

Nhóm	Tính năng	Lý do (truy về nghiên cứu ở bài 03-02)
Must	Tạo, sửa, hủy đơn; mã đơn `BM-YYMMDD-XXX`	Khách đổi giờ, đổi chữ thường xuyên; thiếu sửa/hủy là quay lại Sheet
Must	Trường bánh kem tùy chỉnh bắt buộc: chữ trên bánh, size, vị, giờ nhận	Nguyên nhân gốc của bánh làm lại
Must	Trạng thái đơn `moi` → `da_xac_nhan` → `dang_lam` → `dang_giao` → `hoan_tat` / `da_huy`	Bếp và quầy cần biết đơn đang ở đâu
Must	Tìm khách theo số điện thoại, tạo khách mới	Không tìm được thì nhập trùng khách, sai số điện thoại
Must	Ghi nhận tiền cọc/thanh toán thủ công trên đơn	Cọc nằm ngoài đơn là điểm nghẽn đối soát
Must	Màn hình bếp: bánh cần làm theo ngày, nhóm theo chuyến xe/chi nhánh	Thay ảnh chụp Zalo và sổ chép tay
Must	Đăng nhập theo vai trò `owner` / `manager` / `staff`	Dữ liệu khách và tiền không thể mở cho ai cũng xem
Should	Lịch sử mua của khách (“đặt như lần trước”)	5/8 khách quen nhắc tới; có thể tạm tra theo số điện thoại
Should	Dashboard đơn hôm nay theo trạng thái, chi nhánh	Chị Lan cần, nhưng tạm xem danh sách đơn có lọc
Should	Bản in phiếu bánh cho bếp	Dự phòng khi máy tính bảng ở bếp hỏng
Could	Báo cáo doanh thu theo kênh, sản phẩm	Hữu ích nhưng không giải vấn đề gốc
Could	Xuất CSV cho kế toán	Có thể xuất từ database tạm thời
Won’t (lần này)	Website cho khách tự đặt; chatbot AI; thông báo Zalo tự động; VietQR tự xác nhận; tích điểm	Xem danh sách non-goals bên dưới

Bàn thử

Kéo thẻ tính năng vào Must / Should / Could / Won’t với phép thử ‘thiếu thì có bỏ cách làm cũ không?’ (cảnh báo khi Must quá nửa) + máy tính RICE (Reach × Impact × Confidence ÷ Effort) tái hiện bảng 10 ứng viên

Bàn thử cần bật JavaScript.

Kết quả chỉ để tham khảo, không thay cho việc bạn tự duyệt.

RICE: xếp hạng bằng con số

MoSCoW cho biết nhóm, nhưng không cho biết thứ tự trong nhóm, và dễ bị chi phối bởi người nói to nhất. RICE là công thức chấm điểm giúp so sánh các ứng viên:

Reach (độ phủ): bao nhiêu người/đơn/lượt bị ảnh hưởng trong một khoảng thời gian (ví dụ mỗi tháng).
Impact (tác động): mức tác động lên mỗi lượt, thường dùng thang 3 = rất lớn, 2 = lớn, 1 = vừa, 0,5 = nhỏ, 0,25 = rất nhỏ.
Confidence (độ tin cậy): bạn tin vào ước tính của mình bao nhiêu phần trăm — 100% khi có dữ liệu, 50% khi chủ yếu là cảm giác.
Effort (công sức): tổng công sức, ví dụ “tuần công” (với Bánh Mộc: tuần làm việc của chị Lan cùng coding agent).

Điểm RICE = Reach × Impact × Confidence ÷ Effort.

RICE cho các ứng viên của Bánh Mộc

Ứng viên	Reach (đơn/tháng)	Impact	Confidence	Effort (tuần)	Điểm RICE
Tạo đơn chuẩn hóa, trường bánh kem bắt buộc	3.300	3	90%	3	2.970
Ghi nhận cọc/thanh toán trên đơn	3.300	2	70%	2	2.310
Tìm khách theo SĐT + lịch sử mua	3.300	1	80%	1,5	1.760
Dashboard đơn hôm nay	3.300	0,5	80%	1	1.320
Màn hình bếp theo chuyến xe	900	3	80%	2	1.080
Báo cáo doanh thu theo kênh	3.300	0,5	50%	2	413
VietQR tự xác nhận chuyển khoản	1.500	1	50%	4	188
Chatbot AI nhận đơn qua Zalo	1.200	2	30%	8	90
Nhắc sinh nhật khách qua Zalo	300	1	50%	3	50
Website cho khách tự đặt	600	1	30%	6	30

Bảng này cho thấy vài điều đáng suy nghĩ:

Chatbot AI — ý tưởng ban đầu của chị Lan ở bài 03-01 — đứng gần cuối. Không phải vì nó dở, mà vì độ tin cậy thấp (chưa biết khách có chịu nói chuyện với bot không) và công sức lớn.
Màn hình bếp chỉ đứng thứ năm, sau cả dashboard. Lý do: Reach tính theo số đơn bánh kem (900) nhỏ hơn tổng số đơn. Nhưng nghiên cứu cho thấy đây là nơi phát sinh phần lớn lỗi đắt nhất. Đây là lúc bạn nhớ rằng RICE là công cụ hỗ trợ suy nghĩ, không phải cỗ máy ra quyết định. Màn hình bếp vẫn là Must vì nó trực tiếp xử lý nguyên nhân gốc.
Confidence thấp là tín hiệu cần thử nghiệm, không phải tín hiệu loại bỏ. Với chatbot, một thử nghiệm rẻ là để Hà dùng mẫu tin nhắn có cấu trúc trong 2 tuần và đếm bao nhiêu khách trả lời đúng mẫu.

Khi nào dùng công cụ nào

Tình huống	Công cụ phù hợp
Quyết định cái gì vào MVP, cái gì không	MoSCoW với phép thử “thiếu thì có bỏ cách làm cũ không?”
Sắp thứ tự các tính năng Should/Could cho phiên bản sau	RICE
Có tranh cãi giữa các bên	RICE (buộc mọi người nói rõ giả định)
Chia công việc thành các lần phát hành dùng được	User story map
Ngăn phạm vi phình ra	Danh sách non-goals

Bản đồ user story và lát phát hành

Danh sách tính năng phẳng có một nhược điểm: nó không cho thấy hành trình của người dùng. Bạn có thể làm rất tốt 5 tính năng ở khâu nhận đơn mà quên mất khâu đối soát — và sản phẩm không dùng được trọn vẹn.

User story map (bản đồ user story) sắp xếp công việc theo hai chiều:

Chiều ngang — xương sống (backbone): các hoạt động lớn theo thứ tự hành trình: Nhận đơn → Xác nhận & cọc → Làm bánh → Giao/nhận → Đối soát → Chăm sóc lại khách.
Chiều dọc — độ sâu: dưới mỗi hoạt động là các user story cụ thể, xếp từ cần thiết nhất (trên) đến “có thì tốt” (dưới).

Sau đó bạn kẻ các đường ngang để cắt lát phát hành (release slice): mỗi lát phải đi xuyên qua toàn bộ xương sống, dù ở mức đơn giản. Đó chính là tinh thần “xe trượt → xe đạp → xe máy”.

Lát	Nhận đơn	Xác nhận & cọc	Làm bánh	Giao/nhận	Đối soát	Chăm sóc lại
Lát 1 — MVP lõi (chạy thử Phú Nhuận + bếp)	Tạo/sửa/hủy đơn; tìm khách theo SĐT	Ghi cọc tay; chuyển `da_xac_nhan`	Màn hình bếp theo ngày, chuyến xe	Tra đơn theo mã/SĐT; ghi thanh toán khi nhận	Tổng thanh toán theo phương thức trong ngày	(chưa có — tra đơn cũ theo SĐT)
Lát 2 — MVP đầy đủ (mở cho 3 tiệm)	“Đặt lại như lần trước”	Hiển thị rõ số tiền còn phải thu	In phiếu bánh dự phòng	Ghi chú giao hàng riêng cho người giao	Dashboard đơn hôm nay theo chi nhánh	Xem lịch sử mua của khách
Lát 3 — giai đoạn 2–3	Website cho khách; trợ lý AI trích xuất đơn từ tin nhắn	Mã VietQR, tự xác nhận chuyển khoản	Ước tính tải bếp ngày lễ	Thông báo Zalo khi bánh sẵn sàng	Báo cáo doanh thu, xuất kế toán	Nhắc sinh nhật tự động

Hình chữ ký Băng chuyền công đoạn

Nhận đơn
Xác nhận & cọc
Làm bánh
Giao/nhận
Đối soát
Chăm sóc lại
Lát 1 — MVP lõi: thay Sheet + nhóm Zalo

Xem sơ đồ gốc (Hình 1)

Vuốt ngang để xem hết sơ đồ

Lát 3 — tự động hóa (giai đoạn 2–3)

Website, trợ lý AI

VietQR, tự xác nhận

Dự báo tải bếp

Thông báo Zalo

Báo cáo, kế toán

Lát 2 — MVP đầy đủ cho 3 tiệm

Đặt lại như lần trước

Số tiền còn phải thu

In phiếu bánh

Ghi chú giao hàng

Dashboard chi nhánh

Lát 1 — MVP lõi: thay Sheet + nhóm Zalo

Tạo/sửa/hủy đơn

Ghi cọc tay

Màn hình bếp

Tra đơn khi nhận

Tổng thanh toán ngày

Vuốt ngang để xem hết sơ đồ

Lát 3 — tự động hóa (giai đoạn 2–3)

Website, trợ lý AI

VietQR, tự xác nhận

Dự báo tải bếp

Thông báo Zalo

Báo cáo, kế toán

Lát 2 — MVP đầy đủ cho 3 tiệm

Đặt lại như lần trước

Số tiền còn phải thu

In phiếu bánh

Ghi chú giao hàng

Dashboard chi nhánh

Lát 1 — MVP lõi: thay Sheet + nhóm Zalo

Tạo/sửa/hủy đơn

Ghi cọc tay

Màn hình bếp

Tra đơn khi nhận

Tổng thanh toán ngày

Hình 1 Sơ đồ luồng

Đọc sơ đồ dạng chữ

Lát 1 — MVP lõi: thay Sheet + nhóm Zalo
Tạo/sửa/hủy đơn → Ghi cọc tay
Ghi cọc tay → Màn hình bếp
Màn hình bếp → Tra đơn khi nhận
Tra đơn khi nhận → Tổng thanh toán ngày
Lát 2 — MVP đầy đủ cho 3 tiệm
Đặt lại như lần trước → Số tiền còn phải thu
Số tiền còn phải thu → In phiếu bánh
In phiếu bánh → Ghi chú giao hàng
Ghi chú giao hàng → Dashboard chi nhánh
Lát 3 — tự động hóa (giai đoạn 2–3)
Website, trợ lý AI → VietQR, tự xác nhận
VietQR, tự xác nhận → Dự báo tải bếp
Dự báo tải bếp → Thông báo Zalo
Thông báo Zalo → Báo cáo, kế toán
L1 → L2
L2 → L3

Để ý lát 1 có một ô “chưa có”: chăm sóc lại khách. Điều đó chấp nhận được, vì MVP được định nghĩa là “nhân viên bỏ Sheet để dùng thật”; việc chăm sóc lại khách hiện vẫn đang làm thủ công và không chặn việc dùng hệ thống mới. Lát 1 và lát 2 cộng lại chính là “MVP Mộc OMS” của giai đoạn 1 trong lộ trình: lát 1 để chạy thử và học, lát 2 bổ sung những mục Should đã được nghiên cứu chứng minh trước khi mở cho cả ba tiệm.

Danh sách “không làm” (non-goals)

Non-goals là danh sách những thứ bạn chủ động quyết định không làm trong phiên bản này, kèm lý do. Nó khác với “chưa nghĩ tới”: mỗi dòng trong non-goals là một cuộc tranh luận đã kết thúc.

Vì sao non-goals quan trọng — đặc biệt khi làm việc với AI:

Với con người: khi Hà đề xuất “thêm tích điểm đi chị”, chị Lan chỉ cần chỉ vào danh sách và ngày xem lại, thay vì tranh luận lại từ đầu.
Với coding agent: agent rất hay “tiện tay” làm thêm — thêm gửi email xác nhận, thêm trang quản trị, thêm đa ngôn ngữ. Một mục “Ngoài phạm vi” rõ ràng trong PRD và spec là hàng rào hiệu quả nhất. Bạn sẽ thấy mục này xuất hiện trong mẫu spec ở bài 03-0603-06.

Non-goals của Mộc OMS (MVP)

Không làm	Lý do	Xem lại khi
Website cho khách tự đặt hàng	Vấn đề gốc nằm ở phía tiệm, không phải phía khách đặt	Sau khi lát 1 chạy ổn 1 tháng ở cả 3 tiệm
Chatbot/trợ lý AI nhận đơn	Độ tin cậy thấp, cần dữ liệu đơn chuẩn trước	Giai đoạn 3, khi đã có vài nghìn đơn chuẩn hóa
Thay máy tính tiền tại quầy, xuất hóa đơn điện tử	Đã quyết định mua, không xây (bài 03-03)	Khi tích hợp kế toán ở giai đoạn 4
Tự động xác nhận chuyển khoản qua webhook	Cần tích hợp ngân hàng/cổng trung gian, rủi ro cao	Giai đoạn 2
Gửi thông báo Zalo/SMS/email tự động cho khách	Cần mẫu được duyệt và quy trình đồng ý nhận tin	Giai đoạn 2
Quản lý kho nguyên liệu, công thức, giá vốn	Vấn đề khác, chưa có bằng chứng ưu tiên	Khi có problem statement riêng
Tích điểm, mã giảm giá, khuyến mãi	Không giải vấn đề gốc	Sau khi có dữ liệu khách quen 3 tháng
Ứng dụng di động cài từ kho ứng dụng	Web responsive đủ dùng trên máy tính bảng và điện thoại	Khi có nhu cầu dùng ngoại tuyến rõ ràng
Tự tính phí giao hàng theo khoảng cách	Nhập tay đủ cho quy mô hiện tại	Khi đơn giao hàng chiếm đa số
Nhiều doanh nghiệp dùng chung (multi-tenant)	Chưa có khách hàng bên ngoài	Giai đoạn 4

Cạm bẫy “AI làm nhanh nên làm luôn”

Đây là cạm bẫy đặc trưng của thời AI. Khi agent có thể thêm tính năng báo cáo doanh thu trong 20 phút, câu hỏi “có nên làm không?” dường như trở nên thừa. Nó không thừa, vì chi phí của một tính năng chủ yếu không nằm ở lúc viết code:

Kiểm chứng: mỗi tính năng cần test, cần bạn đọc và hiểu, cần thử với dữ liệu thật. Báo cáo doanh thu sai còn nguy hiểm hơn không có báo cáo.
Ngữ cảnh: mỗi tính năng làm codebase lớn hơn, agent phải đọc nhiều hơn mỗi phiên, dễ nhầm lẫn hơn (xem bài context engineering02-05).
Bề mặt rủi ro: mỗi màn hình mới là một chỗ có thể lộ dữ liệu khách nếu phân quyền sai.
Con người: nhân viên phải học thêm, tài liệu hướng dẫn phải cập nhật; giao diện nhiều nút hơn thì nút quan trọng khó tìm hơn.
Bảo trì vô thời hạn: mỗi tính năng là một “thú cưng” phải cho ăn mãi — khi đổi database, nâng cấp thư viện, nó phải được sửa theo.

Cách phòng thủ cụ thể:

Ghi vào file hướng dẫn cho agent (AGENTS.md — xem bài AGENTS.md, rules và skills02-06) một dòng: “Chỉ làm đúng phạm vi trong spec. Nếu thấy cần thêm tính năng, ghi đề xuất vào mục ‘Câu hỏi mở’ của spec, không tự làm.”
Mọi ý tưởng mới đi vào backlog (xem bài quản lý dự án cho team nhỏ07-06) và được chấm RICE như mọi ứng viên khác.
Hỏi câu hỏi kiểm tra: “Tính năng này giúp đạt tiêu chí thành công nào của MVP?” Không trả lời được thì chờ.

Áp dụng vào dự án Bánh Mộc

Nhật ký công trình · Bánh Mộc

BM-261012-026

12.10.2026

Chị LanChủ chuỗi
Anh TuấnBếp trung tâm
HàBán hàng online

Hà cười bên bảng giấy nhớ, chị Lan kéo một tính năng xuống nhóm thấp hơn khi xếp MoSCoW

Chị Lan bắt đầu với một danh sách 34 ý tưởng gom từ chính chị, từ nghiên cứu ở bài 03-02 và từ những gì chị thấy trong các phần mềm đã dùng thử ở bài 03-03.

Bước 1 — MoSCoW với nhân viên

Chị ngồi cùng Hà, anh Tuấn và quản lý chi nhánh Phú Nhuận một buổi chiều, đọc từng ý và hỏi đúng một câu: “Thiếu cái này, mọi người có bỏ Sheet và nhóm Zalo để dùng hệ thống mới không?” Ban đầu nhóm Must có 15 mục. Sau vòng hỏi thứ hai còn 7. Một tranh luận đáng nhớ: Hà muốn “nhắc sinh nhật khách” là Must; khi được hỏi “thiếu nó em có quay lại Sheet không?”, Hà cười: “Không chị, cái đó em đang không làm luôn.”
Bước 2 — RICE cho phần còn lại

Chị chấm RICE cho các mục Should/Could để sắp lát 2 và lát 3. Bảng RICE cũng giúp chị nhìn ra ý tưởng chatbot nên chờ.
Bước 3 — story map

Chị vẽ bản đồ trên một bảng trắng bằng giấy note, chụp lại, rồi nhờ AI chuyển thành bảng Markdown. Khi kẻ đường cho lát 1, chị phát hiện quên khâu “khách đến nhận bánh, chi nhánh tra đơn và thu phần còn lại” — không có khâu này, thu ngân lại phải nhắn hỏi Hà. Chị bổ sung vào lát 1.
Bước 4 — non-goals và kế hoạch thử

Chị viết danh sách non-goals, dán vào docs/PRD.md. Lát 1 sẽ chạy thử ở bếp trung tâm + chi nhánh Phú Nhuận trước 2 tuần, sau đó mới mở cho Thảo Điền và Gò Vấp (kỹ thuật bật tính năng cho một nhóm người dùng được bàn ở bài preview, staging và feature flag10-06).

Một tuần sau khi bắt đầu xây, agent đề xuất: “Tôi có thể thêm nhanh chức năng gửi email xác nhận đơn cho khách.” Chị Lan mở danh sách non-goals, thấy dòng “Gửi thông báo tự động cho khách — xem lại ở giai đoạn 2”, và trả lời: “Không, ghi vào mục câu hỏi mở.” Đó là lúc chị hiểu giá trị của một tờ giấy liệt kê những điều sẽ không làm.

Prompt mẫu

Prompt 1 — Phản biện nhóm Must

Giao việc cho agent

Đây là danh sách tính năng tôi xếp vào nhóm Must cho MVP, kèm định nghĩa MVP:
Định nghĩa: """[dán định nghĩa MVP, ví dụ: phiên bản nhỏ nhất mà nhân viên 1 chi nhánh bỏ Sheet để dùng thật 2 tuần]"""
Must: """[dán danh sách]"""
Với từng mục, áp phép thử: "Nếu thiếu mục này, người dùng có còn bỏ cách làm cũ không?"
Trả lời dạng bảng: mục | giữ Must hay hạ xuống Should | lý do một câu | cách xoay xở tạm thời nếu hạ.
Sau đó chỉ ra những khâu trong hành trình người dùng mà danh sách đang bỏ sót.

Prompt 2 — Chấm RICE có giả định rõ ràng

Giao việc cho agent

Giúp tôi chấm RICE cho các ứng viên sau. Bối cảnh: ~3.300 đơn/tháng, ~900 đơn bánh kem đặt trước/tháng,
Effort tính bằng tuần công của một người không chuyên làm cùng coding agent.
Ứng viên: """[dán danh sách]"""
Với mỗi ứng viên: ghi Reach, Impact (3/2/1/0,5/0,25), Confidence (%), Effort, điểm RICE,
và MỘT dòng giả định quan trọng nhất cần kiểm chứng. Đánh dấu ứng viên nào có Confidence ≤ 50%
và gợi ý một thử nghiệm rẻ để tăng độ tin cậy. Không tự thêm ứng viên mới.

Prompt 3 — Viết non-goals

Giao việc cho agent

Dựa trên MoSCoW dưới đây, viết mục "Ngoài phạm vi (non-goals)" cho PRD.
"""[dán bảng MoSCoW]"""
Mỗi dòng gồm: điều không làm | lý do | khi nào xem lại.
Thêm 3–5 non-goals mà một coding agent hay "tiện tay" làm thêm với loại ứng dụng quản lý đơn hàng
(ví dụ gửi email, đa ngôn ngữ, trang quản trị phức tạp), để tôi chủ động loại trừ.

Sai lầm thường gặp

Sự cố 01

MVP thành bản demo.

Triệu chứng

Đẹp nhưng không ai dùng thật. *

Cách tránh

* định nghĩa MVP bằng hành vi thật (“nhân viên bỏ Sheet 2 tuần”), không bằng danh sách tính năng.
Sự cố 02

Nhóm Must phình ra.

Triệu chứng

*

Cách tránh

* phép thử “thiếu thì có bỏ cách làm cũ không?”, làm cùng người dùng thật; nếu Must chiếm quá nửa công sức, cắt tiếp.
Sự cố 03

Tin RICE tuyệt đối.

Triệu chứng

Để con số quyết định thay cho hiểu biết về nguyên nhân gốc. *

Cách tránh

* dùng RICE để sắp thứ tự trong cùng nhóm và để lộ giả định, không để ghi đè kết luận từ nghiên cứu.
Sự cố 04

Lát phát hành theo tầng kỹ thuật.

Triệu chứng

“Lát 1 làm database, lát 2 làm giao diện.” *

Cách tránh

* mỗi lát phải đi xuyên toàn bộ hành trình người dùng; kỹ thuật chia nhỏ theo lát dọc được bàn ở bài chia nhỏ công việc06-05.
Sự cố 05

Không viết non-goals.

Triệu chứng

Phạm vi phình dần qua từng câu “tiện thể”. *

Cách tránh

* non-goals là mục bắt buộc của PRD và mọi spec.
Sự cố 06

“AI làm nhanh nên làm luôn”.

Triệu chứng

*

Cách tránh

* mọi tính năng mới đi qua backlog và RICE; dặn agent trong AGENTS.md không tự mở rộng phạm vi.

Checklist

MVP có định nghĩa bằng hành vi người dùng thật và một câu hỏi cần trả lời.
Mọi tính năng ứng viên đã được xếp MoSCoW cùng người dùng trực tiếp.
Nhóm Must đã qua phép thử “thiếu thì có bỏ cách làm cũ không?” ít nhất hai lần.
Các ứng viên Should/Could có điểm RICE và giả định được ghi rõ.
Có user story map với xương sống hành trình đầy đủ.
Lát 1 đi xuyên toàn bộ xương sống và có câu “sau lát này, ai làm được gì”.
Danh sách non-goals có lý do và thời điểm xem lại.
AGENTS.md có dòng dặn agent không tự mở rộng phạm vi.
Có kế hoạch thử MVP với một nhóm nhỏ (một chi nhánh) trước khi mở rộng.

Bài tập thực hành

Bài 1

Cơ bản

Định nghĩa MVP

Viết định nghĩa MVP cho sản phẩm của bạn theo mẫu “phiên bản nhỏ nhất mà [ai] sẵn sàng [bỏ cách làm cũ gì] để [dùng thật trong bao lâu]”, kèm một câu hỏi MVP cần trả lời.

Kết quả mong đợi

định nghĩa không nhắc tên tính năng, câu hỏi có thể trả lời bằng số đo.
Bài 2

Cơ bản

MoSCoW với người dùng

Lấy 15–30 ý tưởng tính năng, ngồi cùng ít nhất một người dùng trực tiếp xếp MoSCoW.

Kết quả mong đợi

nhóm Must không quá 7–8 mục; mỗi mục hạ hạng có ghi cách xoay xở tạm.
Bài 3

Nâng cao

RICE, story map và non-goals

Chấm RICE cho các mục Should/Could, vẽ story map có 3 lát, viết non-goals tối thiểu 6 dòng. Dùng Prompt 1 để phản biện.

Kết quả mong đợi

lát 1 đi xuyên toàn bộ xương sống; ít nhất một ứng viên có Confidence thấp được gắn với một thử nghiệm rẻ; non-goals có cả những thứ agent hay “tiện tay” làm.

Thuật ngữ trong bài

MVP (Minimum Viable Product): Phiên bản nhỏ nhất vẫn dùng được thật và giúp kiểm chứng giá trị.
MoSCoW: Phân loại Must / Should / Could / Won’t (this time).
RICE: Điểm ưu tiên = Reach × Impact × Confidence ÷ Effort.
User story map: Bản đồ sắp story theo hành trình (ngang) và độ ưu tiên (dọc).
Xương sống (backbone): Chuỗi hoạt động lớn của người dùng từ đầu đến cuối hành trình.
Lát phát hành (release slice): Một lần phát hành đi xuyên toàn bộ hành trình ở mức đơn giản.
Non-goals: Danh sách những gì chủ động không làm trong phiên bản này, có lý do.
Backlog: Danh sách công việc/ý tưởng chờ được ưu tiên.
Scope creep: Phạm vi phình dần ngoài kế hoạch qua những bổ sung nhỏ.

Đọc thêm

Nghiệm thu tờ 03-04

Đọc xong và tự kiểm theo phiếu nghiệm thu, rồi đánh dấu tờ này.

Tác giả

Phú Digital

Đội ngũ PDL Digital — triển khai website, giải pháp AI và digital marketing cho doanh nghiệp.

MoSCoW cho Mộc OMS

RICE cho các ứng viên của Bánh Mộc

Khi nào dùng công cụ nào

Non-goals của Mộc OMS (MVP)

MVP thành bản demo.

Nhóm Must phình ra.

Tin RICE tuyệt đối.

Lát phát hành theo tầng kỹ thuật.

Không viết non-goals.

“AI làm nhanh nên làm luôn”.

Định nghĩa MVP

MoSCoW với người dùng

RICE, story map và non-goals

Muốn dựng phần mềm riêng cho doanh nghiệp của bạn?

Nhận tư vấn miễn phí

Nhận tư vấn
miễn phí