Vì sao chủ đề quan trọng
Bạn bước vào khóa này với ba thứ trong tay. Từ khóa Persona & User Journey dựa trên bằng chứng, bạn có hành trình tương lai (future journey) của sinh viên ăn trưa ở Căng tin khu A, trên đó đã đánh dấu các cơ hội (opportunity), tức những chỗ trong hành trình mà nếu làm tốt hơn thì người dùng đỡ khổ. Từ khóa Hiểu nghiệp vụ trước khi xây, bạn có bảng thuật ngữ, quy tắc R1 tới R6 và vòng đời các đối tượng như Đơn đặt trước.
Việc tiếp theo là biến cơ hội thành tính năng, và đây là chỗ nhiều nhóm trượt chân. Ngay khi đọc "P1 Xếp hàng 20–25 phút", cả nhóm đồng thanh: "Làm chức năng đặt món trước!". Ý tưởng đó không sai, nhưng nó là ý tưởng đầu tiên, và ý tưởng đầu tiên hiếm khi là ý tưởng tốt nhất.
Nhảy thẳng tới giải pháp có ba cái giá. Một, bạn bỏ qua các lựa chọn rẻ hơn mà có thể giải được phần lớn vấn đề. Hai, bạn không có cơ sở để nói "không" khi ai đó đề xuất thêm thứ khác. Ba, khi giải pháp thất bại, bạn không biết quay lại đâu.
Bài này dạy một thói quen nhỏ: với mỗi cơ hội, nghĩ ra ít nhất ba giải pháp ứng viên, rồi chọn bằng bằng chứng và chi phí. Đầu ra của bài là danh sách tính năng được đặt tên theo kết quả người dùng nhận được, sẵn sàng để xếp lên story map ở bài 2.
Bức tranh lớn
Công cụ chính là cây cơ hội – giải pháp (opportunity solution tree), một sơ đồ bốn tầng do Teresa Torres phổ biến:
- Kết quả mong muốn (outcome): một con số mà nhà tài trợ quan tâm. Ở đây là giảm số sinh viên bỏ bữa trưa và giảm 25 email phàn nàn mỗi tháng mà Chị Lan nhận.
- Cơ hội: các pain point đã có bằng chứng, lấy từ journey. Ta chỉ làm hai nhánh trong bài này: P1 xếp hàng và P2 hết món.
- Giải pháp ứng viên: nhiều cách khác nhau để xử lý cùng một cơ hội.
- Thử nghiệm: cách rẻ nhất để kiểm tra giải pháp có hiệu quả trước khi xây thật.
flowchart TD
O[Giảm sinh viên bỏ bữa trưa] --> P1[P1 Xếp hàng 20-25 phút]
O --> P2[P2 Hết món với người tới muộn]
P1 --> S1[Đặt món trước]
P1 --> S3[Khung giờ nhận món]
P2 --> S2[Bảng còn món trực tiếp]
P2 --> S1
S1 --> T1[Thử bằng Google Form một tuần]
S2 --> T2[Thử bằng bảng cập nhật mỗi 15 phút]
S3 --> T3[Thử chia ba khung giờ trên giấy]Chú ý một giải pháp có thể phục vụ hai cơ hội: đặt món trước vừa bớt xếp hàng vừa giữ phần cho người tới muộn. Điều đó làm nó hấp dẫn, nhưng cũng làm nó đắt nhất, như bạn sẽ thấy.
Còn P10 hết chỗ ngồi thì sao? Nó là một pain point thật, Minh Anh kể "Có hôm em đứng ăn luôn vì hết chỗ ngồi". Nhưng không giải pháp phần mềm nào tạo thêm ghế. Ghi nó vào cây với nhánh "chuyển cho Phòng Quản trị – Đời sống, ngoài phạm vi ứng dụng".
Ví dụ chi tiết
Hãy làm cây cho Căng tin số, từng bước, với bằng chứng thật từ sáu cuộc phỏng vấn.
Bước 1. Gom bằng chứng cho từng cơ hội. P1 có Minh Anh: "Thứ Hai em hay nhịn trưa, vì xếp hàng xong là trễ giờ vào lớp." Lớp kết thúc 11:30, lớp sau bắt đầu 12:45, quầy cơm xếp hàng 20–25 phút vào cao điểm 11:35–12:15. P2 có Quốc Bảo, tới khoảng 12:40: "Tới nơi thì quầy cơm hết món mặn, chỉ còn trứng chiên." Và câu quan trọng nhất: "Giá mà biết trước là hết thì em ghé quầy bánh mì luôn."
Bước 2. Liệt kê ba giải pháp ứng viên.
- Đặt món trước: sinh viên chọn món trong app, nhận phần đã nấu sẵn.
- Bảng "còn món" trực tiếp: app hiển thị món nào ở quầy nào còn hay hết, cập nhật trong ngày.
- Khung giờ nhận món: sinh viên chọn khung 15 phút để nhận, quầy chuẩn bị theo khung, giãn đỉnh 11:35.
Đặt món trước va ngay vào ba thứ. Anh Tuấn nói "Đặt trước thì phải trả trước. Đặt rồi không tới, tôi lỗ." Minh Anh nói "Em không muốn trả tiền trước, lỡ ra tới nơi hết món thì sao." Đó là mâu thuẫn C1. Cô Hạnh nói "Đặt trước mà sau 10 giờ mới báo thì cô không kịp", trong khi sinh viên muốn đặt tới 11:15, mâu thuẫn C3. Rồi R3: phần đặt giữ 30 phút sau khung giờ nhận, quá thì bán cho hàng. Đặt món trước kéo theo thanh toán trong app, hoàn tiền (R6 chỉ quản lý duyệt), giờ chốt đơn, trạng thái đơn. Chi phí cao.
Ở khóa Persona & User Journey, cơ hội này bị dời vì chưa ai ở hậu trường giữ việc báo hết món. Khóa Hiểu nghiệp vụ trước khi xây đề xuất một nút lớn trên màn hình bếp, chờ Anh Tuấn đồng ý. Ở đây ta dời nút đó ra quầy, vì người thấy món hết đầu tiên là nhân viên đang múc cơm, còn bếp thì không rảnh tay. Đó là một quyết định thiết kế mới, nên phải hỏi lại Cô Hạnh và Anh Tuấn trước khi chốt. Bảng còn món chỉ cần nhân viên quầy bấm "hết" khi một món hết, không đụng tới tiền. Nhưng P11 nhắc ta: "Giờ cao điểm cô không cầm điện thoại được, tay đâu mà xem." Vậy người bấm không thể là Cô Hạnh; phải là nhân viên quầy, với một nút rất to. Chi phí thấp, rủi ro nằm ở việc có ai chịu bấm hay không.
Khung giờ nhận món đứng một mình chỉ là lời mời "hãy tới lúc 12:00". Nó chỉ có nghĩa khi đi kèm đặt trước, nên nó là một phần của đặt món trước.
Bước 4. So sánh bằng bằng chứng và chi phí.
| Giải pháp | Bằng chứng ủng hộ | Chi phí và rủi ro | Quyết định |
|---|---|---|---|
| Đặt món trước | Minh Anh nhịn trưa Thứ Hai; 600 suất ở quầy cơm | Cao, chạm C1, C3, R3, R6 | Làm, giới hạn ở quầy cơm |
| Bảng còn món | Quốc Bảo nói thẳng sẽ đổi sang bánh mì | Thấp, phụ thuộc nhân viên quầy bấm | Làm trước tiên |
| Khung giờ nhận | Đỉnh 11:35–12:15 dồn 40 phút | Trung bình, vô nghĩa nếu không có đặt trước | Gộp vào đặt món trước |
| Thêm bàn ghế | Minh Anh đứng ăn | Không phải phần mềm | Chuyển Chị Lan |
Bước 6. Đặt tên tính năng theo kết quả người dùng. Tên tính năng theo bạn suốt dự án, từ story map tới báo cáo cho Chị Lan. Tên theo kỹ thuật làm mọi người quên lý do nó tồn tại.
Tên theo kỹ thuật -> Tên theo kết quả người dùng
Module tồn kho realtime -> Biết món còn hay hết trước khi đi
Pre-order API -> Có phần cơm chờ sẵn khi tan lớp
Slot booking -> Nhận món đúng khung giờ mình chọn
Allergen field -> Biết món có chất gây dị ứng không
Tên bên phải trả lời câu hỏi "người dùng được gì". Khi ai đó đề xuất "thông báo đẩy khi có món mới", hỏi: nó giúp "biết món còn hay hết trước khi đi" ở chỗ nào?
flowchart TD
A[Một cơ hội có bằng chứng] --> B[Nghĩ ít nhất ba giải pháp]
B --> C[Đối chiếu quy tắc và mâu thuẫn]
C --> D{Bằng chứng mạnh và chi phí chấp nhận được}
D -->|Có| E[Thiết kế thử nghiệm rẻ]
D -->|Không| F[Ghi lý do bỏ vào cây]
E --> G{Thử nghiệm đạt}
G -->|Đạt| H[Đặt tên theo kết quả và đưa lên story map]
G -->|Không đạt| BLộ trình từng bước
- Chép kết quả mong muốn của nhà tài trợ lên đầu trang, dạng một con số có thể đo.
- Lấy từ future journey các cơ hội có ít nhất hai bằng chứng độc lập.
- Với mỗi cơ hội, viết ít nhất ba giải pháp trước khi bàn ưu nhược điểm.
- Đọc từng giải pháp qua bảng quy tắc R1–R6 và mâu thuẫn C1–C3. Ghi rõ nó chạm quy tắc nào.
- Ước chi phí ở mức thô: thấp, trung bình, cao.
- Chọn bằng hai trục bằng chứng và chi phí. Ghi lý do cho cả nhánh bị bỏ.
- Thiết kế một thử nghiệm làm được trong một tuần, không cần viết code.
- Đặt tên tính năng theo kết quả người dùng, rồi chuyển sang bài 2.
Thói quen & kỷ luật
| Thói quen | Tần suất | Kết quả mong đợi |
|---|---|---|
| Viết ba giải pháp trước khi chọn một | Mỗi cơ hội mới | Không còn tình trạng chọn ý tưởng đầu tiên theo quán tính |
| Gắn mỗi giải pháp với câu trích dẫn gốc | Mỗi lần cập nhật cây | Ai cũng truy được vì sao có tính năng này |
| Xem lại nhánh đã bỏ | Hai tuần một lần | Phát hiện nhánh đáng mở lại khi có bằng chứng mới |
| Đổi tên kỹ thuật sang tên kết quả | Mỗi lần thêm mục vào backlog | Backlog đọc được với Chị Lan và Anh Tuấn |
Cần luyện tập
Drill một: Lấy cơ hội P3 không biết thành phần và chất gây dị ứng. Dựa vào lời Thảo Vy "Lần nào em cũng phải hỏi món này có đậu phộng không, mà cô bán cũng không chắc", viết ba giải pháp ứng viên khác hẳn nhau. Gợi ý: một cái trong app, một cái ở quầy, một cái ở bếp. Với mỗi cái, ghi ai phải làm thêm việc gì mỗi sáng.
Drill hai: Chọn một ứng dụng bạn dùng hằng ngày, tìm ba tính năng và viết lại tên theo kết quả người dùng.
Drill ba: Với P8, Anh Tuấn nói "Câu lạc bộ, lớp gọi điện đặt 20, 30 suất cho sự kiện, ghi tay vào sổ." Vẽ một nhánh cây cho P8 và thiết kế một thử nghiệm không cần code, nói rõ đo gì để biết đạt.
Checklist hành động tuần này
- [ ] Vẽ cây cơ hội – giải pháp cho P1 và P2 trên một trang
- [ ] Ghi ít nhất ba giải pháp ứng viên cho mỗi cơ hội
- [ ] Đánh dấu quy tắc R1–R6 và mâu thuẫn C1–C3 mà mỗi giải pháp chạm tới
- [ ] Thiết kế một thử nghiệm rẻ cho giải pháp được chọn
- [ ] Đổi tên mọi tính năng trong danh sách sang tên kết quả người dùng
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ố sinh viên ăn trưa được trước giờ vào lớp 12:45 mỗi tuần | Hướng mọi lựa chọn giải pháp về đúng mục tiêu |
| Chỉ số dẫn dắt | Tỉ lệ người tới sau 12:30 có xem bảng còn món | Báo sớm giải pháp có được dùng hay không |
| Chỉ số kết quả | Số email phàn nàn mỗi tháng so với mức 25 | Cho Chị Lan thấy tác động thật |
| Chỉ số bảo vệ | Số suất quầy cơm bỏ đi mỗi ngày so với mức 40 | Đảm bảo giải pháp không làm bếp lãng phí hơn |
Dấu hiệu bạn đã thành thạo
Bạn tự hỏi "còn cách nào khác không" mỗi khi ai đó nêu một tính năng. Bạn giải thích được vì sao làm bảng còn món trước đặt món trước mà không nói "vì thấy hay". Mỗi tính năng có một câu trích dẫn đi kèm. Và bạn bỏ được ý tưởng mình thích khi thử nghiệm không đạt.
Cạm bẫy thường gặp
| Cạm bẫy | Biểu hiện | Cách tránh |
|---|---|---|
| Chọn ý tưởng đầu tiên | Cây chỉ có một nhánh giải pháp cho mỗi cơ hội | Bắt buộc ba giải pháp trước khi thảo luận |
| Giải pháp không có bằng chứng | Không chỉ ra được ai đã nói gì | Gắn mỗi giải pháp với một câu trích dẫn |
| Biến mọi pain point thành tính năng | P10 hết chỗ ngồi xuất hiện trong backlog | Ghi rõ nhánh ngoài phạm vi phần mềm |
| Quên chi phí nghiệp vụ | Đặt món trước được ước lượng như một màn hình | Đối chiếu quy tắc R1–R6 trước khi ước chi phí |
| Đặt tên theo công nghệ | Backlog đầy chữ API, module, realtime | Viết lại theo câu "người dùng được gì" |
Chốt lại
Một cơ hội luôn có nhiều lời giải. Với Căng tin số, nhóm chọn bảng còn món làm trước vì bằng chứng mạnh và chi phí thấp, chọn đặt món trước có khung giờ nhận cho riêng quầy cơm vì nó giải cả P1 lẫn P2 dù đắt, và ghi rõ hết chỗ ngồi không phải việc của phần mềm. Đầu ra của bài là danh sách tính năng đặt tên theo kết quả người dùng. Ở bài 2, bạn sẽ xếp chúng lên story map để thấy toàn bộ hành trình một lượt và chọn lát cắt đầu tiên cho đợt chạy thử học kỳ 2.