Vì sao chủ đề quan trọng
Sau năm bài, nhóm bạn có bốn mô hình: bảng thuật ngữ, danh sách quy tắc R1 tới R6, vòng đời Đơn đặt trước và Phiếu suất hỗ trợ, swimlane năm làn. Tất cả đều do nhóm viết, từ ghi chép của nhóm. Nghĩa là tất cả đều có lỗi mà nhóm không thấy, vì lỗi nằm đúng ở chỗ nhóm hiểu sai.
Buổi đọc lại (read-back) là lúc bạn mang mô hình về cho người am hiểu nghiệp vụ và nhờ họ bắt lỗi. Mục tiêu duy nhất là bị sửa càng nhiều càng tốt, khi việc sửa còn rẻ. Một dòng sai trong bảng chuyển trạng thái hôm nay tốn một phút gạch đi. Cùng dòng đó sau khi đã thành code, đã chạy thử ở một quầy trong học kỳ 2, tốn một tuần và một lần mất lòng tin của Anh Tuấn.
Đầu vào: bốn mô hình từ bài 1 tới bài 5, bản v0.1. Đầu ra: bản v0.2 đã được Cô Hạnh sửa, nhật ký sửa đổi, và danh sách mâu thuẫn còn mở có tên người quyết định. Gói này đi vào khóa "Từ journey tới user story" và khóa "Không bỏ sót: kiểm tra độ đầy đủ".
Bức tranh lớn
Sai lầm phổ biến nhất là đọc lại bằng cách chiếu sơ đồ và hỏi "Cô thấy đúng không ạ?". Người nghiệp vụ sẽ gật đầu, vì sơ đồ trạng thái là ngôn ngữ của bạn, không phải của họ. Cô Hạnh không đọc mũi tên, cô đọc câu chuyện.
Vì thế, buổi đọc lại chạy bằng kịch bản: một câu chuyện cụ thể có người, giờ, món. Bạn kể, rồi dùng ngón tay đi theo mô hình từng bước, và dừng ở mỗi bước để hỏi "rồi sao nữa ạ?". Khi câu chuyện của bạn và câu chuyện của cô tách nhau, bạn vừa tìm ra một lỗi.
flowchart TD
A[Chọn kịch bản có người, giờ, món] --> B[Kể kịch bản bằng lời thường]
B --> C[Đi từng bước trên mô hình]
C --> D{Cô Hạnh nói khác mô hình?}
D -->|Không| E[Sang bước tiếp theo]
D -->|Có| F[Ghi nguyên văn câu cô nói]
F --> G{Thuộc quy tắc của ai?}
G -->|Của Cô Hạnh| H[Sửa ngay trong bản mới]
G -->|Của người khác| I[Ghi mâu thuẫn, hỏi chủ quy tắc]
E --> C
H --> CVí dụ chi tiết
Nhóm hẹn Cô Hạnh 30 phút lúc 14:00, sau giờ trưa. Mang theo bản in v0.1 của bốn mô hình và năm kịch bản.
Kịch bản 1: một sinh viên đặt phần nhận lúc 11:40 rồi không tới. Nhóm đi trên vòng đời: Đã thanh toán, Đang nấu, Sẵn sàng, rồi Quá hạn không tới. Bản v0.1 có một mũi tên tự động từ Quá hạn không tới sang Đã hoàn tiền, do một bạn trong nhóm thấy "trả lại tiền cho công bằng". Cô Hạnh kể lại cách cô làm: "Phần đặt mà quá 30 phút không tới lấy thì cô bán cho người đang xếp hàng." Cô không nói gì về tiền, vì tiền không phải việc của cô. Nhóm đối chiếu với câu của Anh Tuấn, "Hoàn tiền thì chỉ tôi được duyệt", và nhận ra mũi tên tự động vi phạm R6. Sửa: bỏ mũi tên tự động; hoàn tiền chỉ đi qua quản lý. Câu "30 phút tính từ đầu hay cuối khung giờ nhận" được hỏi trực tiếp và ghi vào nhật ký.
Kịch bản 2: đơn đặt lúc 10:20 cho khung 11:45. Bản v0.1 cho đặt tới 11:15, theo mong muốn của sinh viên. Cô Hạnh dừng ngay: "Đặt trước mà sau 10 giờ mới báo thì cô không kịp." Đây không phải lỗi của mô hình mà là mâu thuẫn C3 giữa người nghiệp vụ và người dùng. Nhóm không sửa tại chỗ; ghi vào danh sách mâu thuẫn và dẫn về cách giải quyết ở khóa "Từ ghi chép tới insight".
Kịch bản 3: Quốc Bảo chọn ba món mặn. Bản v0.1 chặn món thứ ba, vì đọc "tối đa hai món mặn" như một giới hạn cứng. Cô Hạnh: "Thêm món mặn thứ ba là cộng mười nghìn." Sửa R1 ngay: món thứ ba được phép, cộng 10.000đ. Câu hỏi trứng chiên có tính là món mặn được hỏi luôn trong kịch bản này.
Kịch bản 4: món hết lúc 12:00. Trên swimlane, bản v0.1 có mũi tên "App gửi thông báo cho bếp" và "Bếp báo hết món qua điện thoại". Cô Hạnh: "Giờ cao điểm cô không cầm điện thoại được, tay đâu mà xem." Nhóm đã dự đoán điều này ở bài 5, nên bản v0.1 đã có phương án phiếu in lúc 10:00. Nhưng chiều ngược lại, bếp báo hết món, vẫn dựa vào điện thoại. Sửa: chuyển thành một nút trên màn hình lớn ở bếp, chờ Anh Tuấn đồng ý vì R2 là quy tắc của anh.
Kịch bản 5: phần nấu lúc 10:30 còn thừa lúc 13:00. Một bạn đề xuất cho bán buổi chiều để giảm 40 suất bỏ đi mỗi ngày. Cô Hạnh: "Món nấu quá bốn tiếng là phải bỏ, quy định vệ sinh an toàn thực phẩm." Mẻ 10:30 chạm 4 giờ lúc 14:30. Đề xuất bị loại; R5 được ghi thêm hệ quả "không bán sau 14:30 cho mẻ 10:30".
Mọi sửa đổi được ghi vào nhật ký theo bốn cột.
| Kịch bản | Mô hình bị sửa | Câu nguyên văn | Quyết định |
|---|---|---|---|
| Sinh viên đặt nhận 11:40 rồi không tới | Vòng đời Đơn đặt trước | Phần đặt mà quá 30 phút không tới lấy thì cô bán cho người đang xếp hàng | Bỏ mũi tên hoàn tiền tự động, theo R6 |
| Đơn đặt lúc 10:20 | Quy tắc hạn chót | Đặt trước mà sau 10 giờ mới báo thì cô không kịp | Ghi mâu thuẫn C3, chưa sửa |
| Ba món mặn | R1 | Thêm món mặn thứ ba là cộng mười nghìn | Cho phép, cộng 10.000đ |
| Món hết lúc 12:00 | Swimlane | Giờ cao điểm cô không cầm điện thoại được | Nút trên màn hình bếp, chờ Anh Tuấn |
Mô hình : Vòng đời Đơn đặt trước
Phiên bản : v0.2
Ngày : sau buổi đọc lại với Cô Hạnh
Đổi gì : bỏ mũi tên Quá hạn không tới sang Đã hoàn tiền
Vì sao : R6, chỉ quản lý duyệt hoàn tiền
Còn mở : mốc tính 30 phút, tiền của phần bán lại
Có phiên bản, bạn trả lời được câu "Ai bảo sửa chỗ này, và khi nào?"
Còn một tình huống khó hơn: người nghiệp vụ nói ngược với bên liên quan. Trong kịch bản 1, Cô Hạnh bán lại phần không ai lấy, còn Anh Tuấn yêu cầu trả trước vì "Đặt rồi không tới, tôi lỗ." Đặt hai câu cạnh nhau, căng tin thu tiền hai lần cho một phần. Cả hai đều nói thật: Cô Hạnh mô tả việc đang làm, Anh Tuấn mô tả điều anh muốn được phép. Đây không phải chỗ để nhóm chọn ai đúng.
flowchart TD
A[Chuyên gia và bên liên quan nói khác nhau] --> B[Ghi cả hai câu nguyên văn]
B --> C[Xác định đây là quy tắc về việc gì]
C --> D{Ai là chủ quy tắc?}
D -->|Việc bếp| E[Cô Hạnh quyết]
D -->|Tiền và hoàn tiền| F[Anh Tuấn quyết]
D -->|Quyền lợi sinh viên| G[Chị Lan quyết]
E --> H[Ghi quyết định và tăng phiên bản]
F --> H
G --> HTiền của phần bán lại thuộc về R6 và chính sách thanh toán, nên đi tới Anh Tuấn. Nhưng vì nó chạm vào quyền lợi của sinh viên đã trả trước, nhóm gửi bản tóm tắt cho Chị Lan, người tài trợ dự án, cùng lúc.
Lộ trình từng bước
- Chuẩn bị năm kịch bản. Mỗi kịch bản có người, giờ, món và chạm ít nhất một quy tắc hoặc nhánh không thuận.
- In mô hình ra giấy. Người nghiệp vụ cần chỉ tay vào được.
- Kể trước, chỉ sơ đồ sau. Câu chuyện bằng lời thường, sơ đồ chỉ để đi theo.
- Hỏi "rồi sao nữa ạ?" ở mỗi bước. Không hỏi "đúng không ạ?".
- Ghi nguyên văn mọi câu sửa. Không diễn giải trong lúc nghe.
- Phân loại mỗi câu sửa. Lỗi của nhóm thì sửa; mâu thuẫn với người khác thì ghi và chuyển chủ quy tắc.
- Đổi phiên bản trong 24 giờ. Gửi lại bản mới kèm nhật ký cho người đã tham dự.
- Lên lịch lần đọc lại tiếp theo. Sau mỗi thay đổi lớn, không phải một lần duy nhất.
Thói quen & kỷ luật
| Thói quen | Tần suất | Kết quả mong đợi |
|---|---|---|
| Đọc lại bằng kịch bản, không bằng sơ đồ | Mỗi buổi đọc lại | Người nghiệp vụ sửa được trên câu chuyện của họ |
| Tăng phiên bản sau mỗi buổi | Mỗi buổi | Biết ai sửa gì, khi nào |
| Chuyển mâu thuẫn tới chủ quy tắc trong 48 giờ | Mỗi mâu thuẫn mới | Không mâu thuẫn nào bị nhóm tự quyết |
| Đếm câu sửa mỗi buổi | Mỗi buổi | Số câu sửa giảm dần qua các lần |
Cần luyện tập
Drill một: Viết thêm ba kịch bản cho Căng tin số, mỗi kịch bản chạm một quy tắc chưa dùng trong bài: R2 khi thực đơn đã chốt lúc 16:00, R4 khi Thảo Vy đặt vào thứ Bảy, và đơn nhóm 30 suất của câu lạc bộ. Với mỗi kịch bản, ghi bước nào trên mô hình bạn nghi là sai.
Drill hai: Lấy mâu thuẫn C2: Chị Lan muốn đăng nhập bằng mã số sinh viên, Anh Tuấn nó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." Đi theo sơ đồ xử lý mâu thuẫn ở trên: ghi cả hai câu, xác định đây là quy tắc về việc gì, và chỉ ra ai nên quyết định.
Drill ba: Lấy một mô hình bất kỳ bạn từng vẽ cho đồ án. Viết hai kịch bản, rồi đọc lại với một người hiểu việc đó hơn bạn. Đếm số câu sửa và ghi nhật ký sửa đổi bốn cột.
Checklist hành động tuần này
- [ ] Chuẩn bị năm kịch bản, mỗi kịch bản chạm một quy tắc
- [ ] In bốn mô hình bản v0.1 ra giấy
- [ ] Chạy buổi đọc lại 30 phút với người nghiệp vụ
- [ ] Ghi nhật ký sửa đổi và tăng lên v0.2 trong 24 giờ
- [ ] Gửi từng mâu thuẫn còn mở tới đúng chủ quy tắc
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ố kịch bản đi trọn mô hình mà người nghiệp vụ không sửa | Đo mô hình đã khớp nghiệp vụ thật chưa |
| Chỉ số dẫn | Số câu sửa mỗi buổi đọc lại | Nhiều ở buổi đầu là tốt, phải giảm dần |
| Chỉ số rủi ro | Số mâu thuẫn còn mở chưa có người quyết | Cảnh báo trước khi viết story |
| Chỉ số kỷ luật | Thời gian từ buổi đọc lại tới bản mới | Dưới 24 giờ |
Dấu hiệu bạn đã thành thạo
Bạn không còn hỏi "đúng không ạ?" mà hỏi "rồi sao nữa ạ?". Buổi đọc lại đầu tiên của bạn có nhiều câu sửa, và bạn thấy vui vì điều đó. Khi Cô Hạnh nói một điều ngược với Anh Tuấn, bạn ghi cả hai câu và biết gửi cho ai, thay vì chọn bên. Và mỗi mô hình bạn bàn giao cho khóa sau đều có số phiên bản, ngày và tên người đã đọc lại.
Cạm bẫy thường gặp
| Cạm bẫy | Biểu hiện | Cách tránh |
|---|---|---|
| Đọc lại bằng sơ đồ | Người nghiệp vụ gật đầu cho xong | Kể kịch bản, sơ đồ chỉ để đi theo |
| Bảo vệ mô hình | Giải thích vì sao nhóm vẽ vậy | Ghi câu sửa, không tranh luận |
| Tự giải mâu thuẫn | Nhóm chọn giờ chốt 11:15 | Chuyển chủ quy tắc |
| Không đánh phiên bản | Không ai biết bản nào mới nhất | Dòng nhật ký ở đầu mỗi mô hình |
| Đọc lại một lần rồi thôi | Mô hình cũ hơn quyết định mới | Lịch đọc lại sau mỗi thay đổi lớn |
Chốt lại
Buổi đọc lại là cách rẻ nhất để sửa mô hình: kể kịch bản có người, giờ, món, đi theo mô hình từng bước, ghi nguyên văn mọi câu sửa. Lỗi của nhóm thì sửa ngay và tăng phiên bản; mâu thuẫn giữa người nghiệp vụ và bên liên quan thì ghi cả hai câu và chuyển cho chủ quy tắc. Năm kịch bản với Cô Hạnh đã sửa R1, bỏ một mũi tên vi phạm R6, và làm lộ ra khoản tiền có thể bị thu hai lần. Gói v0.2 gồm bảng thuật ngữ, quy tắc, vòng đời và quy trình giờ sẵn sàng cho khóa "Từ journey tới user story".