Bản đồ công trìnhTờ này lắp: Sheet & sổ tay, Màn hình bếp, Kênh bán
Bài nàyĐã họcChưa tớiĐã thay thế
Bạn sẽ học được gì
Tiêu chí nghiệm thu
Vì sao phải bắt đầu từ vấn đề — nhất là khi có AI
Hãy tưởng tượng bạn thuê một đội thợ xây cực nhanh: sáng nói, chiều đã có ngôi nhà. Nghe tuyệt, cho tới khi bạn nhận ra mình cần một cái kho chứ không phải một ngôi nhà. Đội thợ càng nhanh, bạn càng xây sai nhanh hơn, và càng có nhiều thứ phải đập bỏ.
Coding agent chính là đội thợ đó. Trong bài về vai trò mới của bạn00-04, chúng ta đã nói: khi AI làm phần “gõ code”, giá trị của bạn nằm ở chỗ quyết định làm cái gì và nghiệm thu nó có đúng không. Bài này là bước đầu tiên của năng lực “quyết định làm cái gì”.
Có ba lý do khiến việc bắt đầu từ vấn đề càng quan trọng hơn trong thời AI:
- Chi phí tạo ra giải pháp giảm mạnh, chi phí sống với giải pháp thì không. Agent viết một tính năng trong một buổi chiều, nhưng nhân viên phải học dùng nó, dữ liệu phải được duy trì, lỗi phải được sửa, và mỗi tính năng là một chỗ có thể hỏng.
- AI rất giỏi làm theo, rất kém đặt câu hỏi “có nên không”. Bạn nói “làm chatbot nhận đơn”, nó sẽ làm chatbot nhận đơn. Nó hiếm khi tự hỏi: “Chị chắc vấn đề nằm ở khâu nhận đơn chứ?”
- Một problem statement tốt là “mỏ neo” cho mọi spec và prompt sau này. Khi agent đề xuất thêm thứ gì, bạn so với vấn đề gốc: nó có giúp giải bài toán đó không?
Triệu chứng, vấn đề và giải pháp
Ba khái niệm này thường bị nói lẫn trong cùng một câu. Ví dụ chị Lan từng nói: “Tiệm chị loạn đơn quá, chị cần một chatbot AI trên Zalo.” Câu đó chứa cả ba thứ:
- Triệu chứng (symptom): điều bạn nhìn thấy, cảm thấy — “loạn đơn”, “khách phàn nàn”, “cuối ngày mệt”.
- Vấn đề (problem): nguyên nhân có cấu trúc, lặp lại, nằm bên dưới triệu chứng — “thông tin đơn không có một nơi lưu chuẩn, nên bị chép tay nhiều lần qua nhiều người”.
- Giải pháp (solution): một cách cụ thể để xử lý vấn đề — “chatbot”, “phần mềm quản lý đơn”, “một tờ phiếu đặt bánh in sẵn”.
Giống như đi khám bệnh: “đau đầu” là triệu chứng, “thiếu ngủ do mất ngủ kéo dài” là vấn đề, “uống thuốc giảm đau” là một giải pháp — và có thể là giải pháp sai, vì nó chỉ dập triệu chứng.
| Câu nói thường gặp | Thực chất là | Câu hỏi nên hỏi tiếp |
|---|---|---|
| “Khách phàn nàn bánh ghi sai chữ” | Triệu chứng | Sai ở khâu nào: lúc nhận, lúc chuyển tới bếp, hay lúc viết? |
| “Cuối ngày đối soát mất 2 tiếng” | Triệu chứng | Thời gian đó tiêu vào việc gì: tìm đơn, khớp chuyển khoản, hay tính cọc? |
| “Cần chatbot AI nhận đơn” | Giải pháp | Nếu có chatbot, điều gì sẽ khác? Vấn đề nào nó giải? |
| “Cần website đặt hàng” | Giải pháp | Khách hiện có gặp khó khăn khi đặt không, hay khó khăn nằm ở phía tiệm? |
| “Đơn ghi ở nhiều nơi, không ai nắm toàn bộ” | Vấn đề | Hậu quả cụ thể là gì, tốn bao nhiêu? |
Câu chuyện chatbot của chị Lan
Khi mới bắt đầu, chị Lan muốn làm ngay “trợ lý AI trên Zalo tự nhận đơn”. Ý tưởng hấp dẫn, lại đúng xu hướng. Nhưng khi ngồi xuống liệt kê các lần đơn bị sai trong tháng, chị nhận ra: phần lớn lỗi không xảy ra lúc khách nhắn tin. Hà nhận tin rất nhanh và chính xác. Lỗi xảy ra sau đó — khi Hà chụp màn hình tin nhắn gửi vào nhóm Zalo của bếp, khi anh Tuấn chép lại vào sổ, khi thu ngân chi nhánh không biết đơn đã cọc bao nhiêu.
Nếu làm chatbot trước, chị Lan sẽ tự động hóa đúng khâu đang chạy tốt, còn khâu đang hỏng vẫn y nguyên — thậm chí tệ hơn vì đơn đổ về nhanh hơn. Chatbot vẫn nằm trong lộ trình, nhưng ở giai đoạn 312-04, khi đã có nơi chuẩn để chatbot “đổ” đơn vào.
5 Whys: đào tới nguyên nhân gốc
5 Whys (5 lần hỏi “tại sao”) là kỹ thuật bắt nguồn từ hệ thống sản xuất của ngành ô tô Nhật Bản: từ một sự cố cụ thể, hỏi “tại sao” liên tiếp cho đến khi chạm tới nguyên nhân mà nếu sửa thì sự cố không lặp lại. Con số 5 chỉ là quy ước — có khi 3 lần là đủ, có khi cần 7.
Quy tắc quan trọng: bắt đầu từ một sự cố cụ thể, có thật, không bắt đầu từ cảm giác chung chung. “Đơn hay sai” là quá mơ hồ. “Thứ Bảy tuần trước, bánh sinh nhật của khách ghi ‘Ngọc Anh’ thay vì ‘Ngọc Ánh'” là đủ cụ thể.
Ví dụ chị Lan làm cùng Hà và anh Tuấn:
- Tại sao bánh ghi sai tên? Vì thợ bánh viết theo tờ giấy ghi “Ngoc Anh” không dấu.
- Tại sao tờ giấy không có dấu? Vì anh Tuấn chép lại từ ảnh chụp màn hình Zalo, ảnh bị mờ, phần dấu khó đọc, anh gõ vội trên điện thoại.
- Tại sao bếp nhận đơn qua ảnh chụp màn hình? Vì đó là cách nhanh nhất Hà có để chuyển đơn: không có nơi nào chung để ghi đơn mà bếp cũng xem được.
- Tại sao không có nơi chung? Vì mỗi kênh mỗi người ghi một kiểu: Google Sheet cho đơn online, sổ tay ở tiệm, tin nhắn Zalo cá nhân; Sheet không có cột bắt buộc nào cho “chữ trên bánh”.
- Tại sao mỗi người ghi một kiểu? Vì chưa ai định nghĩa “một đơn bánh kem đầy đủ gồm những thông tin gì” và chưa có quy trình chuyển đơn chuẩn từ người nhận tới bếp.
Nguyên nhân gốc: thiếu một nguồn sự thật duy nhất cho đơn hàng, với định nghĩa thống nhất về thông tin bắt buộc. Đáng chú ý, nguyên nhân gốc này giải thích được cả những triệu chứng khác: trùng đơn, sót đơn, đối soát lâu.
- Sự cố: bánh ghi ‘Ngọc Anh’ thay vì ‘Ngọc Ánh’
- Thợ viết theo giấy không dấu
- Anh Tuấn chép lại từ ảnh chụp Zalo bị mờ
- Bếp chỉ nhận đơn qua ảnh chụp màn hình
- Không có nơi ghi đơn chung, Sheet không có cột bắt buộc
- Gốc: chưa có nguồn sự thật duy nhất và định nghĩa đơn chuẩn
Xem sơ đồ gốc (Hình 1)
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- Sự cố: bánh ghi ‘Ngọc Anh’ thay vì ‘Ngọc Ánh’ → Thợ viết theo giấy không dấu
- Thợ viết theo giấy không dấu → Anh Tuấn chép lại từ ảnh chụp Zalo bị mờ
- Anh Tuấn chép lại từ ảnh chụp Zalo bị mờ → Bếp chỉ nhận đơn qua ảnh chụp màn hình
- Bếp chỉ nhận đơn qua ảnh chụp màn hình → Không có nơi ghi đơn chung, Sheet không có cột bắt buộc
- Không có nơi ghi đơn chung, Sheet không có cột bắt buộc → Gốc: chưa có nguồn sự thật duy nhất và định nghĩa đơn chuẩn
- Gốc: chưa có nguồn sự thật duy nhất và định nghĩa đơn chuẩn → Cũng giải thích: trùng đơn
- Gốc: chưa có nguồn sự thật duy nhất và định nghĩa đơn chuẩn → Cũng giải thích: sót đơn
- Gốc: chưa có nguồn sự thật duy nhất và định nghĩa đơn chuẩn → Cũng giải thích: đối soát cọc lâu
Cạm bẫy khi làm 5 Whys
- Dừng ở con người: “Tại sao sai? Vì anh Tuấn cẩu thả.” Đây không phải nguyên nhân gốc; một người cẩn thận khác trong cùng hệ thống cũng sẽ sai. Hãy hỏi tiếp: “Hệ thống nào khiến một người bình thường dễ mắc lỗi này?”
- Nhảy sang giải pháp giữa chừng: “Tại sao? Vì không có app.” Thiếu app không phải nguyên nhân, nó là một giải pháp bạn đang muốn.
- Chỉ đi một nhánh: một sự cố có thể có hai, ba nhánh nguyên nhân. Cứ vẽ nhánh ra, đừng ép về một đường thẳng.
- Làm một mình: người trực tiếp làm việc biết những chi tiết bạn không biết. Làm 5 Whys cùng họ, và nói rõ trước: mục tiêu là sửa hệ thống, không tìm người để trách.
Jobs-to-be-Done: người dùng đang “thuê” giải pháp để làm gì?
Jobs-to-be-Done (JTBD — “việc cần hoàn thành”) là cách nhìn cho rằng người ta không mua sản phẩm, người ta “thuê” sản phẩm để hoàn thành một việc trong một hoàn cảnh cụ thể. Khách không mua bánh kem; họ “thuê” chiếc bánh để buổi sinh nhật của mẹ trọn vẹn và để mình trông chu đáo.
Mẫu câu JTBD phổ biến:
Khi [hoàn cảnh], tôi muốn [động cơ / việc cần làm], để [kết quả mong đợi].
Với Bánh Mộc, có ít nhất ba “người thuê” khác nhau:
| Ai | Câu JTBD |
|---|---|
| Khách đặt bánh | Khi sinh nhật người thân sắp tới, tôi muốn đặt một chiếc bánh đúng ý mà không phải nhắn đi nhắn lại, để buổi tiệc diễn ra suôn sẻ và tôi yên tâm. |
| Hà (bán hàng online) | Khi khách nhắn đặt bánh cho ngày mai, tôi muốn ghi đơn một lần và chắc chắn bếp nhận đúng, để tôi không phải gọi lại kiểm tra hay chịu trách nhiệm khi bánh sai. |
| Anh Tuấn (bếp trung tâm) | Khi bắt đầu ca sáng, tôi muốn biết chính xác hôm nay phải làm những bánh nào, xong trước mấy giờ, để sắp xếp thợ và không bánh nào trễ. |
| Chị Lan (chủ) | Khi cuối ngày, tôi muốn biết tiền thu, tiền cọc, tiền chuyển khoản đã khớp chưa, để tôi về nhà mà không phải mở ba cuốn sổ. |
Điều JTBD làm được mà danh sách tính năng không làm được: nó giữ bạn tập trung vào kết quả. “Màn hình bếp” là một tính năng; “anh Tuấn biết chính xác phải làm gì, xong trước mấy giờ” là một kết quả. Có thể đạt kết quả đó bằng màn hình trên máy tính bảng, bằng phiếu in, hay bằng cả hai. Khi viết spec cho agent, việc mô tả kết quả giúp agent đề xuất phương án tốt hơn thay vì sao chép đúng ý tưởng đầu tiên của bạn.
Viết problem statement
Problem statement (câu tuyên bố vấn đề) là một đoạn văn ngắn, thường 3–6 câu, trả lời: ai đang gặp vấn đề, vấn đề là gì, trong hoàn cảnh nào, hậu quả ra sao (có số), vì sao bây giờ cần giải, và làm sao biết đã giải xong. Nó không nhắc tới giải pháp.
Khung mẫu:
Điền ô trống rồi sao chép
[Nhóm người dùng] đang gặp khó khăn khi [việc cần hoàn thành]
trong bối cảnh [hoàn cảnh, tần suất].
Nguyên nhân chính là [nguyên nhân gốc, không phải giải pháp còn thiếu].
Hậu quả là [tác động đo được: thời gian, tiền, khách hàng, rủi ro].
Việc giải quyết quan trọng lúc này vì [lý do thời điểm].
Chúng ta sẽ biết vấn đề được giải quyết khi [tiêu chí đo được, có mốc thời gian].Problem statement hoàn chỉnh của Bánh Mộc
Sau hai tuần ghi chép và trao đổi với nhân viên, chị Lan viết:
Vấn đề: Nhân viên bán hàng, bếp trung tâm và thu ngân ở 3 chi nhánh Bánh Mộc đang khó phối hợp để giao đúng các đơn đặt trước — đặc biệt là bánh kem tùy chỉnh (chữ trên bánh, size, vị, giờ nhận, tiền cọc). Mỗi ngày có khoảng 80–150 đơn đến từ Facebook, Zalo, điện thoại và tại quầy, ngày lễ tăng 3–4 lần.
Nguyên nhân chính: Không có một nơi lưu đơn duy nhất với thông tin bắt buộc thống nhất; đơn được chép lại thủ công 2–3 lần (tin nhắn → Sheet/sổ → ảnh chụp gửi bếp → giấy ở bếp), và tiền cọc ghi ở chỗ khác với đơn.
Hậu quả (ước tính, xem bảng giả định): khoảng 27 bánh kem phải làm lại mỗi tháng vì sai thông tin, khoảng 135 giờ công mỗi tháng cho đối soát cuối ngày, vài đơn bị sót mỗi tuần; tổng thiệt hại trực tiếp khoảng 18 triệu đồng/tháng, chưa tính khách không quay lại.
Vì sao bây giờ: mùa 20/10 vừa qua cho thấy khi số đơn tăng gấp 3–4 lần thì sai sót cũng tăng theo, mà Noel, Tết đang tới; chị Lan muốn có hệ thống chạy ổn trước Trung thu năm sau, và dự định mở thêm chi nhánh, quy trình hiện tại không nhân rộng được.
Thành công nghĩa là: sau 3 tháng, tỷ lệ bánh kem làm lại do sai thông tin giảm ít nhất một nửa so với mức đo được trước khi thay đổi; thời gian đối soát cuối ngày mỗi tiệm còn tối đa 30 phút; không còn đơn đặt trước nào bị sót.
Để ý những gì không có trong đoạn này: không có chữ “app”, “phần mềm”, “AI”, “Next.js”. Có thể vấn đề này được giải một phần bằng một tờ phiếu đặt bánh in sẵn và một quy trình chuyển đơn mới. Phần mềm chỉ là một ứng viên giải pháp — và bài 03-0303-03 sẽ so sánh các ứng viên đó.
Định lượng chi phí của vấn đề
Một vấn đề chưa có con số là một vấn đề dễ bị đánh giá sai: hoặc bạn đầu tư quá ít (vì “cũng chỉ là chút lộn xộn”), hoặc quá nhiều (vì đang bực). Con số giúp trả lời câu hỏi rất thực tế: đáng bỏ ra bao nhiêu tiền và thời gian để giải bài toán này?
Bạn không cần số chính xác tuyệt đối. Bạn cần số ước tính có giả định minh bạch — để người khác nhìn vào và nói “giả định này quá cao” thay vì tranh luận cảm tính.
Bảng chi phí ước tính của Bánh Mộc
| Hạng mục | Giả định | Cách tính | Ước tính/tháng |
|---|---|---|---|
| Bánh kem làm lại do sai thông tin | ~30 đơn bánh kem đặt trước/ngày thường; 3% bị sai chữ/size/vị/giờ; chi phí làm lại (nguyên liệu + công) 350.000đ/bánh | 30 × 3% × 30 ngày ≈ 27 bánh × 350.000đ | ≈ 9,5 triệu đồng |
| Giờ công đối soát cuối ngày | 1,5 giờ/tiệm/ngày × 3 tiệm; chi phí giờ công 35.000đ | 1,5 × 3 × 30 = 135 giờ × 35.000đ | ≈ 4,7 triệu đồng |
| Đơn bị sót (không làm, phải hoàn cọc) | ~2 đơn/tuần; giá trị trung bình 450.000đ | 8 đơn × 450.000đ | ≈ 3,6 triệu đồng doanh thu mất |
| Tổng thiệt hại trực tiếp | ≈ 17,8 triệu đồng/tháng (≈ 213 triệu đồng/năm) |
Bảng chưa tính những chi phí khó định giá nhưng có thật: khách không quay lại (một gia đình đặt 4–6 bánh sinh nhật mỗi năm, mất họ vì bánh ghi sai tên mẹ là mất cả chuỗi doanh thu), căng thẳng của nhân viên (ảnh hưởng tới việc giữ người), chi phí cơ hội của chị Lan (mỗi giờ dò sổ là một giờ không làm marketing), và ngày lễ, khi số đơn gấp 3–4 lần nên số bánh làm lại cũng tăng theo — đúng lúc bếp không còn công suất để làm lại.
Kiểm tra độ nhạy: nếu giả định sai thì sao?
Một thói quen tốt là thử “kéo” giả định quan trọng nhất lên xuống. Nếu tỷ lệ sai thật ra chỉ 1,5% (một nửa), chi phí làm lại còn khoảng 4,7 triệu, tổng còn khoảng 13 triệu/tháng. Nếu là 5%, tổng lên khoảng 24 triệu/tháng. Dù ở kịch bản thấp, vấn đề vẫn tốn trên 150 triệu đồng/năm — đủ lớn để đầu tư nghiêm túc, nhưng cũng cho thấy không nên chi một khoản gấp nhiều lần con số đó cho năm đầu.
Con số này sau đó trở thành trần ngân sách hợp lý khi bạn so sánh các phương án ở bài 03-03 và tính ROI ở bài kinh tế học phần mềm13-06.
Cách lấy số nhanh mà không cần phần mềm: dán một tờ giấy kẻ bảng ở bếp và ở quầy trong 2 tuần, gạch một vạch kèm lý do mỗi lần có bánh làm lại hay đơn sót; bấm đồng hồ lúc bắt đầu và kết thúc đối soát. Hai tuần dữ liệu thô vẫn tốt hơn hai năm cảm giác.
Bảng chi phí vấn đề với giả định sửa được (đơn bánh kem/ngày, tỷ lệ sai, chi phí làm lại, giờ đối soát, giá giờ công, đơn sót) → tổng tháng/năm; thanh kéo độ nhạy cho tỷ lệ sai (1,5% ≈ 13 triệu, 5% ≈ 24 triệu/tháng)
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.
Dùng AI làm “người phản biện”
Mô hình ngôn ngữ có xu hướng đồng tình với người hỏi. Nếu bạn hỏi “ý tưởng chatbot nhận đơn của tôi có hay không?”, rất có thể bạn nhận về một bài khen kèm danh sách tính năng. Muốn AI hữu ích ở giai đoạn này, bạn phải giao cho nó vai trò phản biện một cách tường minh và cấm nó đề xuất giải pháp.
Ở vai trò này, AI làm tốt các việc: chỉ ra chỗ bạn trộn triệu chứng với giải pháp, liệt kê giả định ẩn (“bạn đang giả định lỗi xảy ra ở bếp, đã kiểm chứng chưa?”), đề xuất giả thuyết cạnh tranh cho cùng triệu chứng, kiểm tra phép tính và hỏi nguồn của từng con số.
Những việc AI không làm thay bạn được: biết chuyện gì thật sự xảy ra ở bếp lúc 6 giờ sáng. Phản biện của AI chỉ dựa trên những gì bạn kể; nó là chiếc gương giúp bạn thấy lỗ hổng trong lập luận, không phải nguồn sự thật. Đó là lý do bài tiếp theo03-02 đưa bạn ra hiện trường.
Áp dụng vào dự án Bánh Mộc
Nhật ký công trình · Bánh Mộc
BM-261013-023
13.10.2026
- Chị LanChủ chuỗi
- Anh TuấnBếp trung tâm
- HàBán hàng online
Đây là cách chị Lan đi từ “chị cần chatbot” tới problem statement ở trên, trong khoảng hai tuần, không viết một dòng code nào.
Tuần 1 — gom triệu chứng. Chị lập một trang ghi chú tên “Nhật ký sự cố đơn hàng”. Mỗi khi có chuyện — bánh sai, khách gọi hỏi đơn, tiền cọc không khớp — Hà, anh Tuấn và thu ngân ba tiệm nhắn vào nhóm Zalo riêng với mẫu ba dòng: chuyện gì xảy ra, ở khâu nào, hậu quả. Cuối tuần có 31 dòng.
Cuối tuần 1 — phân loại. Chị nhờ AI gom 31 dòng thành nhóm (sau khi xóa tên và số điện thoại khách). Kết quả: phần lớn sự cố rơi vào khâu “chuyển đơn từ người nhận tới bếp/quầy” và “ghi nhận tiền cọc”, rất ít sự cố ở khâu “nhận tin nhắn của khách”. Đây là lúc chị gác lại ý tưởng chatbot.
Tuần 2 — đào sâu và đếm. Chị chọn ba sự cố tiêu biểu, ngồi cùng người trong cuộc làm 5 Whys. Song song, bảng kiểm đếm giấy được dán ở bếp và quầy. Chị bấm giờ đối soát ở cả ba tiệm trong 5 ngày.
Cuối tuần 2 — viết và phản biện. Chị viết bản nháp problem statement, đưa cho AI phản biện bằng prompt ở mục dưới. AI chỉ ra hai điểm: bản nháp đầu viết “cần một hệ thống quản lý đơn tập trung” (đó là giải pháp), và con số “3% bánh sai” chưa rõ lấy từ đâu. Chị sửa câu thứ nhất thành nguyên nhân gốc, và ghi chú rằng 3% là ước tính ban đầu sẽ được thay bằng số đo thật.
Cuối cùng, chị lưu problem statement vào file docs/PRD.md — dòng đầu tiên của tài liệu sản phẩm, trước cả khi repo banhmoc-oms có code. Từ đây, mọi spec và prompt cho agent đều có một mỏ neo để quay về.
Prompt mẫu
Prompt 1 — Tách triệu chứng, vấn đề, giải pháp
Điền ô trống rồi sao chép
Bạn là chuyên gia phân tích nghiệp vụ, nhiệm vụ là phản biện chứ không đề xuất giải pháp.
Dưới đây là mô tả của tôi về những khó khăn ở chuỗi tiệm bánh (đã ẩn thông tin khách):
"""
[dán mô tả hoặc nhật ký sự cố]
"""
Hãy:
1. Phân loại từng ý thành: triệu chứng / vấn đề / giải pháp (đặt trong bảng).
2. Chỉ ra những chỗ tôi đang nói về giải pháp nhưng tưởng là vấn đề.
3. Đề xuất 2–3 giả thuyết nguyên nhân gốc cạnh tranh nhau, mỗi giả thuyết kèm cách kiểm chứng
bằng quan sát hoặc đếm số (không cần phần mềm).
Không đề xuất app, phần mềm hay công nghệ nào trong câu trả lời.Prompt 2 — Phản biện problem statement
Điền ô trống rồi sao chép
Đóng vai một nhà đầu tư khó tính đang đọc bản tuyên bố vấn đề dưới đây.
"""
[dán problem statement]
"""
Kiểm tra theo các tiêu chí: (a) có nêu rõ ai gặp vấn đề không; (b) có lẫn giải pháp không;
(c) mỗi con số có nguồn hoặc giả định rõ ràng không; (d) tiêu chí thành công có đo được và có mốc thời gian không;
(e) lý do "vì sao bây giờ" có thuyết phục không.
Với mỗi tiêu chí, cho điểm Đạt/Chưa đạt và một câu sửa cụ thể. Sau đó liệt kê 5 giả định ẩn
mà tôi nên kiểm chứng trước khi đầu tư.Prompt 3 — Kiểm tra bảng chi phí
Điền ô trống rồi sao chép
Đây là bảng ước tính chi phí của vấn đề, mọi con số là giả định:
"""
[dán bảng]
"""
Hãy: kiểm tra lại từng phép tính; chỉ ra giả định nào ảnh hưởng tổng lớn nhất;
tính lại tổng ở kịch bản thấp (giả định chính giảm một nửa) và kịch bản cao (tăng 60%);
gợi ý cách đo thực tế từng giả định trong 2 tuần mà không cần phần mềm.Sai lầm thường gặp
-
Sự cố 01
Mô tả vấn đề bằng tên giải pháp.
Triệu chứng“Vấn đề của chúng tôi là chưa có app.” *
Cách tránh* viết lại problem statement không dùng bất kỳ từ công nghệ nào; nếu không viết được, bạn chưa hiểu vấn đề.
-
Sự cố 02
Dừng 5 Whys ở một con người.
Triệu chứng“Vì Hà ẩu.” *
Cách tránh* đặt luật trước buổi phân tích: câu trả lời phải là về quy trình, công cụ hoặc thông tin, không phải về tính cách ai đó.
-
Sự cố 03
Định lượng bằng cảm giác.
Triệu chứng“Chắc mất cả chục triệu mỗi tháng.” *
Cách tránh* ghi rõ từng giả định thành một dòng trong bảng, và đếm thật ít nhất 1–2 tuần trước khi quyết định đầu tư lớn.
-
Sự cố 04
Giải quá nhiều vấn đề cùng lúc.
Triệu chứngGộp chuyện đơn hàng, chấm công, kho nguyên liệu, marketing vào một “hệ thống tổng thể”. *
Cách tránh* chọn một vấn đề có chi phí lớn nhất và rõ nhất làm trọng tâm; các vấn đề khác ghi vào danh sách chờ.
-
Sự cố 05
Để AI khen ý tưởng của mình.
Triệu chứngHỏi “ý tưởng này hay không?” và nhận về lời khen. *
Cách tránh* giao vai phản biện tường minh, yêu cầu liệt kê giả định ẩn và giả thuyết cạnh tranh.
-
Sự cố 06
Không hỏi người làm thật.
Triệu chứngChủ doanh nghiệp tự viết vấn đề từ văn phòng. *
Cách tránh* mọi problem statement phải được ít nhất một người làm trực tiếp đọc và xác nhận “đúng là vậy”.
Checklist
Bài tập thực hành
-
Bài 1
Cơ bản
Phân loại câu nói
Lấy 10 câu phàn nàn bạn nghe nhiều nhất trong doanh nghiệp của mình (hoặc dùng bối cảnh Bánh Mộc). Phân loại mỗi câu thành triệu chứng, vấn đề hay giải pháp.
Kết quả mong đợi
một bảng 10 dòng; với mỗi câu “giải pháp”, bạn viết được một câu hỏi để tìm ra vấn đề phía sau nó.
-
Bài 2
Cơ bản
5 Whys có thật
Chọn một sự cố xảy ra trong tháng này. Làm 5 Whys cùng ít nhất một người trực tiếp liên quan, vẽ lại bằng sơ đồ Mermaid như trong bài.
Kết quả mong đợi
một nguyên nhân gốc nói về quy trình/thông tin, kèm 1–2 triệu chứng khác mà nguyên nhân đó cũng giải thích được.
-
Bài 3
Nâng cao
Problem statement và bảng chi phí
Viết problem statement theo khung 6 dòng cho một vấn đề của bạn, kèm bảng chi phí ít nhất 3 hạng mục với giả định rõ ràng. Dùng Prompt 2 và Prompt 3 để phản biện, sửa ít nhất hai lần.
Kết quả mong đợi
bản cuối không chứa từ công nghệ, có tổng chi phí ở ba kịch bản (thấp/giữa/cao), và có tiêu chí thành công đo được kèm mốc thời gian.
Thuật ngữ trong bài
- Triệu chứng (symptom)
- Điều quan sát thấy bên ngoài, ví dụ “khách phàn nàn”, “cuối ngày mệt”.
- Vấn đề (problem)
- Nguyên nhân có cấu trúc, lặp lại, nằm dưới triệu chứng.
- Giải pháp (solution)
- Một cách cụ thể để xử lý vấn đề; có thể là phần mềm hoặc không.
- Nguyên nhân gốc (root cause)
- Nguyên nhân mà nếu sửa thì sự cố không lặp lại.
- 5 Whys
- Kỹ thuật hỏi “tại sao” liên tiếp từ một sự cố cụ thể để tìm nguyên nhân gốc.
- Jobs-to-be-Done (JTBD)
- Cách nhìn người dùng “thuê” sản phẩm để hoàn thành một việc trong hoàn cảnh cụ thể.
- Problem statement
- Đoạn tuyên bố vấn đề: ai, vấn đề gì, hậu quả, vì sao bây giờ, thành công là gì.
- Baseline
- Số liệu đo được trước khi thay đổi, dùng để so sánh sau này.
- Phân tích độ nhạy
- Thử thay đổi giả định quan trọng để xem kết luận có còn đứng vững không.
Đọc thêm
- Vai trò mới của bạn: kiến trúc sư, quản lý sản phẩm và kiểm định viên00-04
- Gặp gỡ Bánh Mộc: dự án xuyên suốt chuỗi bài00-05
- Đo lường thành công: chỉ số, mục tiêu và kế hoạch analytics03-08
- Kinh tế học phần mềm: chi phí sở hữu, ROI và định giá13-06
- Tình trạng phát triển phần mềm có AI hỗ trợ (DORA): https://dora.dev
Nghiệm thu tờ 03-01
Đọc xong và tự kiểm theo phiếu nghiệm thu, rồi đánh dấu tờ này.
