Chào bạn. Nếu bạn đang làm đồ án phần mềm ở trường, chắc bạn quen cảnh này rồi: cả nhóm ngồi lại, hỏi nhau "làm app gì giờ?", chốt một ý tưởng nghe hay hay, rồi lao vào vẽ màn hình, chia việc, code. Tới lúc đem cho người dùng thật xài thử thì mới té ngửa. App giải sai vấn đề. Thiếu mấy chức năng mà ai làm nghề cũng biết phải có. Và gần như chắc chắn quên mất những người dùng phía sau, như nhân viên, quản lý, người duyệt.
Nói thật, chuyện này không phải do nhóm bạn code dở. Nó nằm ở phần việc trước khi code: hiểu ai đang khổ vì cái gì, công việc thật của họ chạy ra sao, rồi biến những thứ đó thành danh sách việc cần làm mà không sót cái gì quan trọng. Và sau khi làm xong thì phải biết nó có hiệu quả thật không.
Lộ trình này dạy đúng mấy phần đó, theo đúng thứ tự mà người làm sản phẩm chuyên nghiệp vẫn làm.
Ai nên học?
- Bạn đang học CNTT, hệ thống thông tin, kỹ thuật phần mềm, đang làm đồ án hoặc sắp đi thực tập.
- Bạn mới vào nghề BA, PO, PM hay dev, và hay bị hỏi "sao thiếu chức năng này?".
- Nhóm khởi nghiệp sinh viên muốn thử ý tưởng trước khi đổ ba tháng vào code.
Không cần biết gì trước về nghiên cứu người dùng hay dữ liệu. Chỉ cần chịu khó đi nói chuyện với người thật.
Một câu chuyện đi suốt cả lộ trình
Bảy khóa đầu dùng chung một tình huống: Căng tin số, app đặt cơm cho căng tin của một trường đại học khoảng 9.000 sinh viên. Giờ cao điểm xếp hàng 20 tới 25 phút. Quầy cơm có hôm 12 giờ rưỡi là hết món mặn. Có bạn dị ứng đậu phộng mà hỏi ai cũng không chắc món nào ăn được. Còn cô bếp thì giờ đông khách không có tay nào để cầm điện thoại.
Bạn sẽ gặp sáu người: ba bạn sinh viên, cô bếp trưởng 14 năm nghề, anh quản lý căng tin và chị chuyên viên bên phòng quản trị của trường. Khóa sau lấy kết quả của khóa trước làm đầu vào. Học hết, bạn sẽ thấy tận mắt một câu than trong buổi phỏng vấn đầu tiên biến thành một user story có tiêu chí nghiệm thu, rồi thành một con số trên bảng theo dõi sau bốn tuần chạy thử.
Khóa cuối đổi sang một bài toán khác hẳn để bạn tự làm từ đầu tới cuối.
Tám bước, cứ đi lần lượt
Bước 1. Phỏng vấn để hiểu vấn đề
Vào khóa: Phỏng vấn để hiểu vấn đề
Hỏi người dùng, hỏi người rành nghiệp vụ và hỏi người có quyền quyết định là ba chuyện khác nhau, nên cần ba bộ câu hỏi khác nhau. Mẹo quan trọng nhất của khóa này: hỏi chuyện đã xảy ra, đừng hỏi ý kiến. Hỏi "lần gần nhất bạn ăn trưa ở căng tin, chuyện gì xảy ra?" thì bạn có sự thật. Hỏi "bạn có muốn đặt món trước không?" thì bạn chỉ nhận được một câu trả lời cho có.
- Mang vào: một đề bài.
- Mang ra: ghi chép phỏng vấn, ghi chép quan sát, bảng thuật ngữ đầu tiên.
- Mẫu: Bộ câu hỏi phỏng vấn
Bước 2. Từ ghi chép tới insight
Vào khóa: Từ ghi chép tới insight
Sáu buổi phỏng vấn là cỡ 200 mẩu ghi chú. Khóa này chỉ bạn gom nhóm, tách cái nào là nỗi khổ thật, cái nào là mong muốn, cái nào là giải pháp người dùng tự nghĩ ra. Bạn cũng học cách cân xem điều gì có nhiều bằng chứng, và xử lý khi người dùng với sếp muốn hai thứ ngược nhau.
- Mang vào: ghi chép từ bước 1.
- Mang ra: danh sách vấn đề có bằng chứng, problem statement, nhật ký quyết định.
- Mẫu: Tổng hợp nghiên cứu
Bước 3. Persona và User Journey dựa trên bằng chứng
Vào khóa: Persona & User Journey
Persona ở đây không phải nhân vật bịa ra cho đẹp, có ảnh và sở thích. Dòng nào trong persona cũng phải chỉ ra được nó lấy từ ghi chú nào. Bạn vẽ hành trình của một bạn có lớp lúc 12 giờ 45, rồi vẽ luôn phần hậu trường: bếp nấu theo mẻ, nhân viên ngồi soát chuyển khoản, quản lý đối soát cuối ngày. Mấy chức năng hay bị quên nhất nằm hết ở đây.
- Mang vào: vấn đề và problem statement từ bước 2.
- Mang ra: hai tới ba persona, journey hiện tại, service blueprint, journey tương lai.
- Mẫu: Persona và journey
Bước 4. Hiểu nghiệp vụ trước khi xây
Vào khóa: Hiểu nghiệp vụ trước khi xây
Đây là bước sinh viên hay bỏ qua nhất, và cũng là lý do app hay thiếu chức năng huỷ đơn, hoàn tiền hay báo cáo. Bạn lập bảng thuật ngữ để cả nhóm nói chung một thứ tiếng, nghe ra mấy quy tắc người ta nói thoáng qua, chạy một buổi event storming rút gọn và vẽ vòng đời của từng đối tượng. Mỗi mũi tên trên vòng đời là một việc mà ai đó phải làm được trong app.
- Mang vào: ghi chép từ người rành nghiệp vụ, service blueprint.
- Mang ra: bảng thuật ngữ, quy tắc nghiệp vụ, sơ đồ trạng thái, quy trình.
- Mẫu: Nghiệp vụ
Bước 5. Từ journey tới user story
Vào khóa: Từ journey tới user story
Tới đây mới bàn tới tính năng. Từ một cơ hội, bạn nghĩ ra vài cách giải rồi mới chọn. Bạn dựng story map, chọn phiên bản mỏng nhất chạy thử được, viết user story theo INVEST, tách story cho vừa một sprint, viết tiêu chí nghiệm thu Given, When, Then. Và ghi ra cả mấy thứ người dùng không bao giờ nói: chịu tải giờ cao điểm, bảo mật, mất mạng ở quầy.
- Mang vào: journey tương lai, quy tắc, vòng đời.
- Mang ra: story map, user story có tiêu chí nghiệm thu, yêu cầu phi chức năng.
- Mẫu: Story map và user story
Bước 6. Không bỏ sót: kiểm tra độ đầy đủ
Câu hỏi ít ai dạy: làm sao biết mình chưa quên gì? Bạn chạy năm phép kiểm tra trên backlog: ai tạo, xem, sửa, xoá từng đối tượng; vai trò nào làm được gì; chuyện gì xảy ra khi mọi thứ trục trặc; story nào cũng phải chỉ ra được bằng chứng; và một buổi đi qua mọi thứ với người quyết định trước khi viết dòng code đầu tiên.
- Mang vào: story map và user story.
- Mang ra: backlog đã kiểm tra, truy được nguồn gốc, sẵn sàng giao cho dev.
- Mẫu: Kiểm tra độ đầy đủ
Bước 7. Đo lường thành công
Làm xong app chưa phải là xong. Câu hỏi thật là: app có giúp được ai không, và giờ làm gì tiếp? Bạn học đọc mấy số liệu có sẵn từ trước khi đi hỏi, chọn chỉ số thành công từ chính problem statement, đo đường cơ sở trước khi ra mắt, lên kế hoạch ghi nhận dữ liệu ngay trong user story. Rồi bạn ngồi đọc số liệu thật sau bốn tuần chạy thử ở căng tin: chỗ nào người dùng rơi rụng, tuần nào số liệu "đẹp giả" vì trùng tuần thi, và cuối cùng là quyết định tiếp tục, sửa, dừng hay mở rộng.
- Mang vào: backlog đã sẵn sàng và bản chạy thử.
- Mang ra: kế hoạch đo lường, đường cơ sở, kết luận sau bốn tuần, quyết định cho vòng tiếp theo.
- Mẫu: Kế hoạch đo lường
Bước 8. Dự án cuối: Phòng học nhóm thư viện
Bạn nhận sáu bản phỏng vấn y như ngoài đời: có người nói lan man, có người tự sửa lời, có người buột ra một quy tắc quan trọng giữa một câu chuyện khác. Kèm theo là một bảng số liệu thư viện xuất từ sổ đăng ký. Trong đó giấu 24 điều: nỗi khổ, mâu thuẫn, quy tắc, và mấy manh mối chỉ số liệu mới cho thấy. Bạn làm đủ sản phẩm của bảy bước, rồi mới mở đáp án ra đếm xem mình tìm được bao nhiêu.
Con số đó nói cho bạn biết mình cần quay lại luyện bước nào.
Học sao cho hiệu quả?
- Đi đúng thứ tự. Khóa sau dùng kết quả của khóa trước. Nhảy thẳng tới user story là lặp lại đúng cái lỗi lộ trình này muốn sửa.
- Làm bài kiểm tra sau mỗi bài học. Câu hỏi là tình huống thật chứ không phải học thuộc định nghĩa. Sai câu nào, đọc lại phần đó liền.
- Làm song song với đồ án của bạn. Học xong bước 1 thì tuần đó đi phỏng vấn năm người thật. Lộ trình này có giá trị nhất khi bạn áp vào sản phẩm của chính mình.
- Rủ bạn học chung. Phỏng vấn cần một người hỏi, một người ghi. Gom ghi chú thì ba người nhìn ra nhiều hơn một người.
- Dùng mẫu, nhưng đừng điền cho có. Mẫu nào cũng có sẵn ví dụ Căng tin số. Bắt đầu dự án của bạn thì xoá ví dụ đi.
Lịch học gợi ý
Mỗi khóa có sáu bài, mỗi bài cỡ 20 tới 30 phút đọc và 30 phút thực hành.
- Tuần 1: Bước 1, và phỏng vấn ít nhất năm người cho đồ án của bạn.
- Tuần 2: Bước 2 và bước 3.
- Tuần 3: Bước 4, và đọc lại mô hình nghiệp vụ với một người rành nghề.
- Tuần 4: Bước 5 và bước 6.
- Tuần 5: Bước 7, và viết kế hoạch đo lường cho đồ án của bạn.
- Tuần 6: Dự án cuối, chấm bài, rồi quay lại bước còn yếu.
Học nhanh hơn cũng được, nhưng đừng bỏ phần đi gặp người thật. Phần đó không khóa học nào làm thay bạn được.
Muốn đi sâu thêm về dữ liệu?
Năm khóa dưới đây giờ cũng dùng chung ví dụ Căng tin số, nên học tiếp rất liền mạch:
- Metrics & North Star cho PM: chọn chỉ số và dựng cây chỉ số.
- Ra quyết định dựa trên dữ liệu: kết hợp số liệu với phỏng vấn, tránh nhầm tương quan với nhân quả.
- Product Analytics thực chiến: tracking, phễu, phân nhóm người dùng.
- A/B Testing & Thử nghiệm sản phẩm: khi nào cần thử nghiệm thật, và làm sao cho đúng.
- Chiến lược dữ liệu: khi cả tổ chức, chứ không chỉ một nhóm, muốn ra quyết định bằng dữ liệu.
Học xong rồi thì sao?
Bạn sẽ biết hỏi đúng người, đúng câu; biến lời nói thành bằng chứng; vẽ ra phần hậu trường mà người khác quên; giao cho dev một backlog mà dòng nào cũng giải thích được vì sao nó có mặt; và sau khi ra mắt, biết đọc số để quyết định bước tiếp theo. Đó là cách làm phần mềm đúng ngay từ đầu.
Có gì thắc mắc trong lúc học thì cứ bình luận ngay dưới bài này nhé. Làm xong dự án cuối thì khoe luôn: bạn tìm được bao nhiêu trong 24 điều?