Vì sao chủ đề quan trọng
Hãy hình dung buổi demo cuối sprint đầu tiên của Căng tin số. Nhóm bạn trình chiếu đẹp: sinh viên mở app, xem thực đơn, chọn cơm phần, quét QR trả tiền, nhận mã lấy món. Chị Lan gật đầu. Rồi Anh Tuấn hỏi bốn câu liên tiếp:
- "Sinh viên đặt xong rồi đổi ý thì huỷ ở đâu?"
- "Huỷ rồi thì tiền trả lại thế nào? Hoàn tiền thì chỉ tôi được duyệt, nhân viên quầy không được."
- "Cuối ngày tôi đối soát kiểu gì? Tôi đang mất cả tiếng mỗi ngày rồi."
- "Giảng viên với nhân viên trường cũng ăn ở đây, không có mã số sinh viên đâu. Họ đăng nhập bằng gì?"
Khóa học này nhận đầu vào là toàn bộ những gì bạn đã làm ở các khóa trước: ghi chép có bằng chứng (khóa Từ ghi chép tới insight), persona và service blueprint (khóa Persona & User Journey dựa trên bằng chứng), vòng đời đối tượng và quy tắc nghiệp vụ (khóa Hiểu nghiệp vụ trước khi xây), story map và user story (khóa Từ journey tới user story). Đầu ra là một backlog đã được kiểm tra và truy vết được, đủ an toàn để giao cho đội kỹ thuật.
Bức tranh lớn
Lỗ hổng trong backlog hiếm khi ngẫu nhiên. Chúng đến từ bốn nguồn quen thuộc:
- Chỉ phỏng vấn sinh viên. Sinh viên là người dùng dễ tiếp cận nhất, nên nhóm hỏi họ nhiều nhất. Nhưng Căng tin số còn có bếp, quầy, quản lý và Phòng Quản trị – Đời sống. Mỗi vai trò bị bỏ qua là một nhóm tính năng biến mất.
- Chỉ vẽ đường vui (happy path). Đường vui là kịch bản mọi thứ diễn ra suôn sẻ: đặt, trả, nhận. Đời thật có hết món, chuyển khoản treo, mất mạng, người không tới lấy.
- Quên phần hậu trường (back-office). Hậu trường là những việc người dùng cuối không nhìn thấy: chốt thực đơn, đối soát, báo cáo, cấp phiếu. Sinh viên không bao giờ kể về đối soát, vì họ không làm việc đó.
- Quy tắc được nói thoáng qua. "Thêm món mặn thứ ba là cộng mười nghìn" của Cô Hạnh được nói giữa câu chuyện về mẻ nấu. Nếu người ghi chép không tách nó thành quy tắc R1, nó không bao giờ thành tiêu chí chấp nhận.
flowchart TD
A[Backlog từ khóa trước] --> B[Ma trận CRUD - bài 2]
B --> C[Ma trận vai trò và hành động - bài 3]
C --> D[Đường không vui - bài 4]
D --> E[Truy vết về bằng chứng - bài 5]
E --> F[Walkthrough trước khi code - bài 6]
F --> G[Backlog sẵn sàng cho kỹ thuật]Ma trận CRUD bắt lỗ hổng theo dữ liệu: đối tượng nào được tạo mà không ai sửa hay xoá. Ma trận vai trò bắt lỗ hổng theo con người: ai có việc phải làm mà không có story. Đường không vui bắt lỗ hổng theo tình huống. Truy vết bắt lỗ hổng theo bằng chứng: pain point nào bị bỏ rơi, story nào không có lý do tồn tại. Walkthrough là phép kiểm tra cuối, bằng mắt và miệng của những người thật sẽ dùng hệ thống.
Ví dụ chi tiết
Lấy bốn lỗ hổng Anh Tuấn chỉ ra trong buổi demo. Với mỗi cái, hãy hỏi: nó đến từ nguồn nào, và nếu phát hiện ở từng giai đoạn thì tốn gì?
| Lỗ hổng | Nguồn gốc | Phát hiện lúc khám phá | Phát hiện lúc kiểm thử | Phát hiện sau ra mắt |
|---|---|---|---|---|
| Huỷ đơn | Chỉ vẽ đường vui | Thêm một story và vài tiêu chí | Thêm trạng thái vào vòng đời đơn, sửa màn hình và dữ liệu | Sinh viên gọi điện, nhắn tin xin huỷ, quầy xử lý tay |
| Hoàn tiền theo R6 | Quy tắc nói thoáng qua | Ghi R6 vào tiêu chí của story huỷ | Phải thêm phân quyền quản lý, viết lại luồng thanh toán | Nhân viên quầy tự hoàn tiền, Anh Tuấn mất kiểm soát dòng tiền |
| Đối soát cuối ngày P7 | Quên hậu trường | Một story báo cáo cho quản lý | Phải bổ sung dữ liệu chưa từng lưu như kênh thanh toán | Anh Tuấn vẫn mất một giờ mỗi ngày, app không giải quyết P7 |
| Giảng viên không có mã số sinh viên | Chỉ phỏng vấn sinh viên | Quyết định cách đăng nhập thứ hai, giải mâu thuẫn C2 | Đổi cơ chế đăng nhập khi hệ thống đã gắn chặt với mã số sinh viên | Khoảng 15% doanh thu không đặt được qua app |
flowchart TD
A[Khám phá - sửa một dòng bảng tính] --> B[Thiết kế - sửa vài màn hình phác thảo]
B --> C[Lập trình - sửa mã và dữ liệu]
C --> D[Kiểm thử - sửa, kiểm lại, trễ hạn]
D --> E[Sau ra mắt - mất tiền, mất niềm tin]Điều đáng chú ý nhất: cả bốn lỗ hổng đều có bằng chứng sẵn trong ghi chép. Câu của Anh Tuấn về hoàn tiền và về giảng viên nằm nguyên văn trong biên bản phỏng vấn. Lỗ hổng không phải do thiếu thông tin, mà do thiếu một bước kiểm tra có hệ thống giữa "đã nghe" và "đã đưa vào backlog".
Mẫu để dùng ngay
Toàn bộ khóa học dùng một tệp Excel với năm trang tính, mỗi trang ứng với một phép kiểm tra.
Tải mẫu: Kiểm tra độ đầy đủ (Excel)
Nếu chưa tải, bạn có thể dựng nhanh các cột cốt lõi:
Trang CRUD: Đối tượng / Tạo / Đọc / Sửa / Xoá hoặc lưu trữ / Câu hỏi mở
Trang Vai trò: Hành động / Sinh viên / Giảng viên-NV / Quầy / Bếp / Quản lý / QT-ĐS
Trang Đường không vui: Bước / Điều gì sai / Hệ thống làm gì / Ai quyết / Story
Trang Phi chức năng: Hạng mục / Yêu cầu / Bằng chứng / Đã có story chưa
Trang Truy vết: Story / Pain point / Quy tắc / Ghi chép gốc / Trạng thái
Lộ trình từng bước
- Gom đầu vào vào một chỗ: danh sách story, story map, bảng quy tắc R1 tới R6, danh sách pain point P1 tới P12, danh sách đối tượng và vai trò.
- Liệt kê bảy đối tượng cốt lõi: Thực đơn ngày, Món, Đơn đặt trước, Khung giờ nhận, Thanh toán, Phiếu suất hỗ trợ, Phản hồi. Đây là đầu vào cho bài 2.
- Liệt kê sáu vai trò: Sinh viên, Giảng viên và nhân viên trường, Nhân viên quầy, Bếp, Quản lý căng tin, Phòng Quản trị – Đời sống. Đây là đầu vào cho bài 3.
- Với mỗi lỗ hổng bạn đã biết, ghi lại nó đến từ nguồn nào trong bốn nguồn. Nếu phần lớn rơi vào một nguồn, đó là điểm mù của nhóm.
- Lên lịch năm phép kiểm tra theo thứ tự của khóa. Mỗi phép tạo ra một danh sách câu hỏi mở, không phải một danh sách tính năng.
- Đặt lịch walkthrough ở bài 6 ngay từ bây giờ, vì Chị Lan, Anh Tuấn và Cô Hạnh đều bận.
Thói quen & kỷ luật
| Thói quen | Tần suất | Kết quả mong đợi |
|---|---|---|
| Hỏi "nguồn nào đã sinh ra lỗ hổng này" mỗi khi phát hiện thiếu | Mỗi lỗ hổng | Nhóm thấy điểm mù lặp lại của mình |
| Đọc lại ghi chép của người không phải sinh viên trước khi chốt backlog | Mỗi lần chốt | Hậu trường không bị bỏ quên |
| Ghi câu hỏi mở thay vì tự đoán câu trả lời | Liên tục | Không có giả định ngầm lọt vào code |
| Cập nhật tệp kiểm tra khi backlog thay đổi | Mỗi tuần | Ma trận luôn khớp với backlog thật |
Cần luyện tập
Drill một: Mở ghi chép phỏng vấn Anh Tuấn. Gạch chân mọi câu chứa một quy tắc hoặc một việc hậu trường. Đếm xem bao nhiêu câu trong số đó đã có story tương ứng. Với Căng tin số, bạn sẽ thấy ít nhất câu về đặt suất nhóm qua điện thoại (P8) và câu về đối soát (P7) dễ bị bỏ sót.
Drill hai: Lấy bốn lỗ hổng trong bảng ở trên. Với mỗi cái, viết một câu mô tả chi phí nếu phát hiện sau ra mắt, dùng con số thật của case: 15% doanh thu, một giờ đối soát, khoảng 300 sinh viên dùng phiếu hỗ trợ.
Drill ba: Chọn một dự án môn học bạn từng làm. Liệt kê ba tính năng bị thiếu mà giảng viên hoặc người dùng chỉ ra lúc nghiệm thu. Xếp mỗi cái vào một trong bốn nguồn.
Checklist hành động tuần này
- [ ] Tải tệp kiểm tra độ đầy đủ và tạo năm trang tính
- [ ] Gom story, story map, quy tắc, pain point vào một thư mục chung
- [ ] Liệt kê bảy đối tượng và sáu vai trò vào tệp
- [ ] Phân loại mọi lỗ hổng đã biết theo bốn nguồn
- [ ] Gửi lời mời walkthrough 60 phút cho Chị Lan, Anh Tuấn và Cô Hạnh
Chỉ số cho cách làm
Các con số dưới đây đo cách nhóm làm bước này, không đo app có thành công hay không. Câu hỏi app có hiệu quả không, và làm gì tiếp, là việc của khóa Đo lường thành công.
| Loại chỉ số | Ví dụ | Vai trò |
|---|---|---|
| North Star | Số lỗ hổng phát hiện sau khi bắt đầu code, mục tiêu tiến về 0 | Đo xem kiểm tra có thực sự chặn lỗ hổng |
| Chỉ số dẫn dắt | Số câu hỏi mở được ghi nhận trong giai đoạn khám phá | Nhiều câu hỏi sớm là dấu hiệu tốt |
| Chỉ số dẫn dắt | Tỉ lệ vai trò có ít nhất một story, mục tiêu 6 trên 6 | Bắt vai trò bị quên |
| Chỉ số kết quả | Số yêu cầu đổi phạm vi trong học kỳ 2 do thiếu sót | Xác nhận chất lượng khám phá |
Dấu hiệu bạn đã thành thạo
- Khi xem một backlog, bạn tự động hỏi "hậu trường đâu" và "nếu hỏng thì sao".
- Bạn gọi tên được nguồn gốc của một lỗ hổng mà không cần nghĩ lâu.
- Bạn giải thích được cho đồng đội vì sao sửa trong bảng tính rẻ hơn sửa trong mã nguồn, bằng ví dụ cụ thể.
- Danh sách câu hỏi mở của bạn dài hơn danh sách giả định.
Cạm bẫy thường gặp
| Cạm bẫy | Biểu hiện | Cách tránh |
|---|---|---|
| Coi kiểm tra là thủ tục | Điền ma trận cho đủ ô rồi cất đi | Mỗi ô trống phải sinh ra một câu hỏi có người chịu trách nhiệm |
| Tự trả lời thay stakeholder | Ghi "chắc quản lý duyệt" mà không hỏi | Ghi câu hỏi, gắn tên người cần hỏi |
| Đợi đội kỹ thuật phát hiện | "Lập trình viên sẽ hỏi nếu thiếu" | Lập trình viên chỉ hỏi về thứ họ thấy, không hỏi thứ không có |
| Kiểm tra một lần rồi thôi | Backlog đổi mà ma trận không đổi | Cập nhật hằng tuần |
Chốt lại
Phần mềm thiếu tính năng thường không phải vì thiếu thông tin mà vì thiếu bước kiểm tra. Bốn nguồn sinh lỗ hổng là chỉ hỏi sinh viên, chỉ vẽ đường vui, quên hậu trường và bỏ qua quy tắc nói thoáng qua. Năm phép kiểm tra của khóa này bịt lần lượt từng nguồn. Bài 2 bắt đầu với phép kiểm tra cơ học nhất và hiệu quả nhất: ma trận CRUD cho bảy đối tượng của Căng tin số.