Vì sao chủ đề quan trọng
Bài 2 cho bạn 12 cụm, P1 tới P12. Nhưng mở một cụm ra, bạn sẽ thấy những thứ rất khác nhau nằm cạnh nhau: một nỗi khổ ("xếp hàng xong là trễ giờ vào lớp"), một điều người ta cần, một ước muốn, và đôi khi một giải pháp người nói đã tự nghĩ ra ("đặt trước thì phải trả trước"). Nếu bạn coi tất cả là yêu cầu, bạn sẽ xây đúng những gì người ta đề xuất, và bỏ lỡ điều họ thật sự cần.
Người dùng là chuyên gia về cuộc sống của họ, không phải chuyên gia thiết kế giải pháp. Khi Minh Anh nói về hàng dài, cô ấy hoàn toàn đúng. Khi một sinh viên nói "em muốn có nút đặt trước", bạn ấy đang đưa ra một cách giải, có thể tốt, có thể không. Việc của bạn là lần ngược từ cách giải đó về nhu cầu bên dưới.
Bài này nhận vào: 12 cụm có tên từ bài 2. Bài này giao ra: mỗi ghi chú trong cụm được gắn một trong bốn loại, mọi giải pháp đề xuất đã được dịch ngược thành nhu cầu, và một danh sách riêng những pain point thật nhưng không phải việc của phần mềm.
Bức tranh lớn
Bốn loại, phân biệt bằng câu hỏi "điều này nói về cái gì?":
- Pain point: một khó khăn đang xảy ra, có hậu quả. "Thứ Hai em hay nhịn trưa."
- Nhu cầu (need): điều người đó phải đạt được, không gắn với cách làm. "Có bữa trưa trước 12:45."
- Mong muốn (want): điều họ thích có, thường gắn với cảm xúc hoặc tiện lợi, mất đi thì không hỏng việc. "Muốn ngồi chỗ thoáng."
- Giải pháp đề xuất: một cách làm cụ thể người nói tự nghĩ ra. "Có nút đặt trước", "phải trả trước", "đăng nhập bằng mã số sinh viên".
Kỹ thuật dịch ngược đơn giản: với mỗi giải pháp đề xuất, hỏi "nếu có cái đó rồi, bạn được gì?" Lặp lại cho tới khi câu trả lời không còn nhắc tới một thứ để xây.
flowchart TD
A[Câu em muốn có nút đặt trước] --> B{Có cái đó rồi thì được gì?}
B --> C[Không phải đứng hàng 20 phút]
C --> D{Không đứng hàng thì được gì?}
D --> E[Có bữa trưa và vào lớp 12h45 đúng giờ]
E --> F[Nhu cầu đã đủ sâu]
F --> G[Nhiều cách đáp ứng, đặt trước là một]Chú ý: dịch ngược không có nghĩa là gạt bỏ giải pháp. "Đặt trước" có thể vẫn là cách tốt nhất. Nhưng khi bạn giữ nhu cầu, bạn còn so được nó với các cách khác, ví dụ mở thêm một hàng chỉ bán cơm hộp sẵn trong 11:35 tới 12:15, và bạn biết khi nào đặt trước đã đáp ứng đủ.
Ví dụ chi tiết
Đây là cách nhóm phân loại một số ghi chú Căng tin số:
| Ghi chú | Loại | Nhu cầu bên dưới |
|---|---|---|
| Minh Anh "Thứ Hai em hay nhịn trưa, vì xếp hàng xong là trễ giờ vào lớp." | Pain point | Có bữa trưa trong khoảng 11:30 tới 12:45 |
| Quốc Bảo "Giá mà biết trước là hết thì em ghé quầy bánh mì luôn." | Mong muốn chứa nhu cầu | Biết món nào còn trước khi đi tới căng tin |
| Một sinh viên nói "em muốn có nút đặt trước" | Giải pháp đề xuất | Không phải đứng hàng mà vẫn kịp giờ học |
| Anh Tuấn "Đặt trước thì phải trả trước. Đặt rồi không tới, tôi lỗ." | Giải pháp đề xuất | Không mất tiền vì suất đặt bị bỏ |
| Chị Lan "Đăng nhập phải bằng mã số sinh viên qua hệ thống của trường." | Giải pháp đề xuất | Biết chắc ai đang dùng, nhất là suất hỗ trợ |
| 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." | Pain point | Biết chắc món có chất gây dị ứng hay không |
| Minh Anh "Có hôm em đứng ăn luôn vì hết chỗ ngồi." | Pain point | Có chỗ ngồi ăn giờ cao điểm |
Thứ nhất, stakeholder cũng đề xuất giải pháp. Câu của Anh Tuấn nghe như một quy tắc nghiệp vụ, nhưng phần "phải trả trước" là cách ông ấy nghĩ ra để giải nỗi lo bị lỗ. Nhu cầu thật là "không mất tiền vì suất đặt bị bỏ". Trả trước là một cách. Cũng có những cách khác, và bài 6 sẽ dùng chính chỗ này để gỡ mâu thuẫn C1 với Minh Anh. Tương tự, câu của Chị Lan là giải pháp cho nhu cầu "biết chắc ai đang dùng", đặc biệt với suất hỗ trợ tối đa một suất một ngày.
Thứ hai, câu "em muốn có nút đặt trước" không thuộc về ai trong sáu người. Bạn sẽ nghe câu kiểu này rất nhiều khi phỏng vấn sinh viên, và rất dễ ghi thẳng thành yêu cầu. Khi dịch ngược, nó dẫn về đúng nhu cầu của P1. Nghĩa là nó không thêm vấn đề mới; nó là một ý tưởng giải P1, nên chuyển sang bãi đỗ ý tưởng.
Thứ ba, P10 là pain point thật nhưng không phải tính năng. Minh Anh đứng ăn vì hết chỗ ngồi. Đó là khó khăn có thật, có hậu quả. Nhưng không màn hình nào tạo thêm ghế. Cách giải nằm ở chỗ khác: kê thêm bàn, mở khu ngồi phụ, sắp xếp lại không gian, những việc của Phòng Quản trị – Đời sống và công ty Hòa Bình. Nhóm bạn ghi P10 vào danh sách "ngoài phạm vi phần mềm" và chuyển cho Chị Lan, kèm bằng chứng. Có thể đặt trước làm giờ lấy cơm trải đều hơn và giảm cao điểm ở bàn ăn, nhưng đó là giả thuyết, không phải tính năng, và không được dùng để hứa giải P10.
Đừng xóa P10. Một pain point bị xóa sẽ quay lại trong buổi demo dưới dạng "app hay nhưng vẫn không có chỗ ngồi", và lúc đó bạn không có câu trả lời.
Lộ trình từng bước
- Mở từng cụm, đọc từng ghi chú, gắn một trong bốn loại vào cột nhãn của bảng tính.
- Với mỗi giải pháp đề xuất, hỏi "được gì?" cho tới khi câu trả lời không còn nhắc tới thứ để xây.
- Viết nhu cầu bằng động từ và kết quả, không có danh từ của giải pháp: "biết món nào còn", không phải "có thông báo hết món".
- Kiểm tra nhu cầu bằng cách nghĩ ra hai cách đáp ứng khác nhau. Nghĩ không ra thì nhu cầu vẫn còn dính giải pháp.
- Chuyển mọi giải pháp đề xuất sang bãi đỗ ý tưởng, ghi kèm người đề xuất. Chúng sẽ có ích ở khóa Từ journey tới user story.
- Với mỗi pain point, hỏi: phần mềm có thể làm thay đổi điều này không? Nếu không, đưa vào danh sách ngoài phạm vi, ghi người nên nhận.
- Đọc lại 12 cụm và viết cho mỗi cụm một câu nhu cầu chính.
flowchart TD
A[Một ghi chú] --> B{Có thứ để xây trong câu?}
B -->|Có| C[Giải pháp đề xuất]
C --> D[Dịch ngược thành nhu cầu]
B -->|Không| E{Là khó khăn đang xảy ra?}
E -->|Có| F{Phần mềm thay đổi được?}
F -->|Có| G[Pain point trong phạm vi]
F -->|Không| H[Danh sách ngoài phạm vi]
E -->|Không| I[Nhu cầu hoặc mong muốn]Thói quen & kỷ luật
| Thói quen | Tần suất | Kết quả mong đợi |
|---|---|---|
| Hỏi được gì với mọi giải pháp đề xuất | Mỗi ghi chú có thứ để xây | Nhu cầu không dính giải pháp |
| Thử nghĩ hai cách đáp ứng mỗi nhu cầu | Mỗi nhu cầu | Biết nhu cầu đã đủ sâu |
| Giữ bãi đỗ ý tưởng có tên người đề xuất | Suốt quá trình | Ý tưởng không mất, không lẫn vào dữ liệu |
| Rà danh sách ngoài phạm vi với sponsor | Mỗi lần báo cáo | Pain point thật được chuyển đúng người |
Cần luyện tập
Drill một: Phân loại bốn câu của Cô Hạnh trong CASE theo bốn loại. Gợi ý: "Giờ cao điểm cô không cầm điện thoại được, tay đâu mà xem" là pain point, và nó âm thầm loại bỏ một giải pháp rất phổ biến là gửi đơn vào điện thoại cho bếp.
Drill hai: Dịch ngược ba giải pháp đề xuất bạn từng nghe trong lớp, ví dụ "thầy nên đưa slide lên trước". Viết nhu cầu, rồi nghĩ thêm hai cách đáp ứng khác.
Drill ba: Lấy P12 của Thảo Vy, "Đưa phiếu hỗ trợ ra giữa hàng người em hơi ngại." Viết nhu cầu bên dưới, sao cho không nhắc tới phiếu giấy hay app. Sau đó tự hỏi: nhu cầu này có phải chỉ của 300 sinh viên nhận hỗ trợ không?
Checklist hành động tuần này
- [ ] Gắn loại cho mọi ghi chú trong 12 cụm
- [ ] Dịch ngược ít nhất năm giải pháp đề xuất thành nhu cầu
- [ ] Viết một câu nhu cầu chính cho mỗi cụm
- [ ] Lập danh sách ngoài phạm vi có P10 và người nhận
- [ ] Gửi danh sách ngoài phạm vi cho sponsor
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ố nhu cầu có ít nhất hai cách đáp ứng khác nhau | Nhu cầu còn mở cho thiết kế |
| Chỉ số dẫn dắt | Tỉ lệ giải pháp đề xuất đã được dịch ngược | Cho biết còn bao nhiêu việc |
| Chỉ số chất lượng | Số câu nhu cầu còn chứa tên tính năng | Phát hiện giải pháp lọt vào |
| Chỉ số phạm vi | Số pain point ngoài phạm vi đã có người nhận | Không có vấn đề bị bỏ rơi |
Dấu hiệu bạn đã thành thạo
- Nghe "em muốn có nút..." là bạn tự hỏi "có nút đó rồi thì được gì?"
- Bạn nhận ra quy tắc của stakeholder đôi khi là một giải pháp họ đã chọn sẵn.
- Bạn nói được với sponsor rằng P10 có thật nhưng app không giải được, mà không thấy ngại.
- Câu nhu cầu của bạn không còn chứa chữ nút, màn hình, thông báo.
Cạm bẫy thường gặp
| Cạm bẫy | Biểu hiện | Cách tránh |
|---|---|---|
| Chép đề xuất thành yêu cầu | Danh sách yêu cầu có dòng "nút đặt trước" | Dịch ngược trước khi ghi |
| Dịch ngược quá xa | Nhu cầu thành "sinh viên muốn hạnh phúc" | Dừng khi còn đo được và còn gắn ngữ cảnh |
| Coi lời stakeholder là luật | "Phải trả trước" vào thẳng đặc tả | Tách quy tắc thật khỏi cách làm đã chọn |
| Xóa pain point ngoài phạm vi | P10 biến mất khỏi báo cáo | Giữ trong danh sách riêng có người nhận |
| Hứa giải gián tiếp | Viết "app sẽ giảm thiếu chỗ ngồi" | Ghi là giả thuyết, chưa kiểm chứng |
Chốt lại
Bốn loại, một câu hỏi: điều này là khó khăn, là điều phải đạt, là điều thích có, hay là một cách làm ai đó đã chọn sẵn? Giải pháp đề xuất, kể cả từ Anh Tuấn hay Chị Lan, được dịch ngược thành nhu cầu. P10 được giữ lại như một pain point thật nằm ngoài phạm vi phần mềm. Bây giờ bạn có nhu cầu cho từng cụm, nhưng chưa biết cụm nào nặng hơn. Bài 4 dạy cân bằng chứng.