Nhiều năm qua, một trong những câu hỏi mà Py thường nhận được — và cũng khó trả lời nhất — là: Học gì để làm PO? Bởi lẽ, Py biết rằng hành trình của mình không phải là con đường phổ biến, và trải nghiệm của một người cũng không thể đại diện cho cả một ngành nghề. Vì vậy, Py viết lại chuỗi bài Vỡ lòng với mong muốn tái hiện một cách chân thật nhất con đường học nghề, những chặng đường mình đã đi qua, cũng như cách làm product đã thay đổi ra sao trong thập kỷ thứ ba của thiên niên kỷ thứ hai — khi mà AI có lẽ không chỉ còn dừng lại ở vai trò công cụ.
Ngữ cảnh
Vào một ngày cuối thu, đầu đông năm 2019, sau nhiều buổi trò chuyện về định hướng nghề nghiệp, Py quyết định rẽ sang một ngành mới chỉ vừa được nghe và tiếp xúc đâu đó khoảng 1,5 năm: Business Analyst (BA). Thời điểm đó, hiểu biết của Py chỉ gói gọn trong việc: BA là người viết lại tài liệu cho Dev thực hiện; muốn điều chỉnh sản phẩm (app, web) đều phải thông qua BA phân tích rồi mới đến lượt Dev làm. Thật sự, Py thấy BA rất “ngầu”, nhất là khi các bạn BA ở công ty trước của Py — dù xuất thân từ khối kinh tế — vẫn có thể làm được trong lĩnh vực “high-tech” như vậy.
Và thế là hành trình học làm “ngầu” bắt đầu.
Vỡ lòng của vỡ lòng
Bài tập đầu tiên mà Py nhận là viết tài liệu (docs). Do các team đã bắt đầu xây app từ trước, nhưng phần tài liệu chưa kịp hoàn thiện, nên việc “nhớ” logic của sản phẩm chủ yếu dựa vào ký ức của các thành viên (tụi Py vẫn hay gọi vui là “Docs sống”). Nhiệm vụ của Py là viết lại đặc tả các tính năng đang vận hành. Dĩ nhiên, Py không biết bắt đầu từ đâu, và chắc chắn các anh PM, Dev hay chị QC đều không đủ thời gian để chỉ dạy từng bước như hồi đi học.
Vậy nên, Py chọn cách học theo “văn mẫu”:
- Đọc lại cách docs mà anh PM đã viết, tự tìm hiểu cái khái niệm, định nghĩa mới, và giả định bản thân mình ở vị trí của anh PM thì mình sẽ tư duy như thế nào để viết ra docs này.
- Google search mọi từ khóa có thể nghĩ ra: “viết tài liệu mô tả tính năng”, “viết docs mô tả phần mềm”… bằng cả tiếng Việt lẫn tiếng Anh.
Thật ra, đây là cách học mặc định của Py khi tiếp cận vấn đề mới: đọc. Việc đọc giúp Py có được nền tảng kiến thức cơ bản về task được giao; nếu may mắn, còn tìm thấy cả những “bài văn mẫu” để tham khảo cách trình bày, hướng giải. Tuy nhiên, quá trình bước ra khỏi vùng an toàn chưa bao giờ dễ dàng — đầy cảm giác hoang mang, không biết mỗi bước mình vừa đặt xuống đã vững vàng để bước tiếp hay chưa. Dù vậy, quá trình bước từ comfort zone sang fear zone1 là chuyện rất bình thường, và chúng ta sẽ phải trải qua hàng ngàn lần trong đời.
Hiển nhiên, sau khi tự tìm hiểu, Py luôn hỏi lại để anh PM xác nhận hướng đi đã đúng chưa trước khi bắt tay vào viết chính thức. Một nguyên tắc “ngầm” mà Py học được trước đó là phải làm rõ “kỳ vọng” giữa người giao task (reporter) và người nhận task (assignee). Một mẹo mà anh PM chia sẻ — và đến giờ Py vẫn áp dụng — là tìm ví dụ hữu hình để hai bên cùng xác nhận cách hiểu. (Trong ngữ cảnh task vỡ lòng này, benchmark đơn giản nhất chính là những tài liệu anh PM từng viết.)
Vỡ lòng
Tài liệu (docs) ở công ty Py thời điểm đó thường có 3 thành phần chính, bắt đầu với User Flow:
- Tên đầy đủ: User Flow Diagram
- Tên gọi khác: Flow Chart, Task Flow, UX Flow, Lưu đồ…*
- Công năng chính: Diễn tả user cần thực hiện những thao tác gì trên sản phẩm (app/web) để giải quyết nhu cầu của mình.
- (Bias) Tool: Draw.io, Figjam
Ví dụ: User Flow case Login cho Xsy-peasy by ChatGPT 4o
*Nếu tìm hiểu sâu hơn, bạn sẽ thấy mỗi khái niệm có chút khác biệt, nhưng ở các công ty Py từng làm việc, mọi người thường dùng chúng thay thế cho nhau.
Lần đầu tiên nhìn thấy User Flow, ký ức của Py lập tức gọi về hình ảnh một “flow” quen thuộc từng học hồi cấp 2: sơ đồ khối thuật toán2 trong môn Tin học lớp 8. Dựa vào đó, Py bắt đầu tìm hiểu lại ý nghĩa của từng loại hình khối (tròn, thoi, chữ nhật…), các loại mũi tên… Cũng từ đây, Py biết đến BPMN3 — một bộ quy tắc chung khi vẽ diagram, tương tự như “ngữ pháp” trong hệ quy chiếu ngôn ngữ. Tất cả PO, BA, Dev, QC (và nhiều stakeholders khác) mà Py từng làm việc cùng đều hiểu các quy tắc cơ bản này, nên vẽ flow theo BPMN thực sự giúp tiết kiệm rất nhiều thời gian khi trình bày logic.
Vậy user flow có bắt buộc không? Có, theo một cách tự nguyện. Sẽ có nhiều cách khác nhau để mô tả logic cần xử lý; thậm chí với những use case quá phổ biến, việc vẽ lại user flow đôi khi không còn cần thiết. Cũng như nhiều bài học vỡ lòng khác, User Flow sẽ dần trở thành kỹ năng tiềm thức khi bạn đã quen việc. Tuy nhiên, User Flow vẫn luôn có giá trị riêng — nhất là khi xảy ra tranh cãi: chỉ cần nhìn vào flow là biết ngay vấn đề nằm ở đâu.
Vẽ flow dĩ nhiên cần kèm bảng mô tả để làm rõ thêm các bước trong flow. Tuy không bắt buộc, nhưng nguyên tắc chung là: bản flow cần đủ rõ ràng để người đọc có thể tự hiểu mà không cần người viết ngồi cạnh để giải thích.
Ví dụ: Bảng mô tả cho User Flow ở trên do ChatGPT 4o thực hiện.
| Step ID | Step Name | Type | Description |
| 1 | Start | Event (Start) | Người dùng mở ứng dụng hoặc website Xsy-peasy. |
| 2 | Welcome Screen | Screen/Task | Màn hình chào hiển thị với tùy chọn: “Đăng nhập” hoặc “Đăng ký tài khoản mới”. |
| 3 | Choose: Login or Sign Up? | Decision (Gateway) | Hỏi người dùng: đã có tài khoản chưa? (Có → đăng nhập, Không → đăng ký). |
| 4 | Login Form | Screen/Task | Nếu chọn “Login”, hệ thống hiển thị form đăng nhập (chọn phương thức Email/Password hoặc Social login: Google/Apple). |
| 5 | Input Credentials | User Action | Người dùng nhập thông tin đăng nhập (email/số điện thoại + mật khẩu hoặc xác thực bằng tài khoản Google/Apple). |
| 6 | Submit | User Action | Người dùng nhấn nút “Submit” để gửi thông tin đăng nhập. |
| 7 | Validate Credentials | System Process (Decision) | Hệ thống xác thực thông tin đăng nhập: kiểm tra tài khoản, mật khẩu hoặc token của social login. |
| 8 | Success | System Response | Nếu xác thực thành công, hệ thống chuyển người dùng tới trang chủ (homepage) của Xsy-peasy. |
| 9 | Failure | System Response | Nếu xác thực thất bại (ví dụ: sai mật khẩu, tài khoản không tồn tại), hiển thị thông báo lỗi và quay lại form đăng nhập để nhập lại thông tin. |
| 10 | End | Event (End) | Kết thúc flow đăng nhập: người dùng đã đăng nhập thành công vào hệ thống hoặc tiếp tục retry nếu thất bại. |
Túi mù 1: mermaidchart.com
Mermaid là tool phổ biến dùng để render diagram. Ngoài ra Mermaid cũng giới thiệu thêm tính năng vẽ flow bằng AI, theo Py trải nghiệm cũng có vẻ có tiềm năng để khai thác thêm (nhìn về khoản visual thì đang ok hơn ChatGPT). Mà tool nào cũng vậy, cần thời gian làm quen trước khi thật sự ứng dụng vào công việc hàng ngày.
Ví dụ: User Flow case Login cho Xsy-peasy by Mermaid
Túi mù 2: Py’s example
Trong bài này đa phần Py dùng AI tools để phần nào kiểm nghiệm (và làm quen) khả năng ứng dụng của AI, chỉ là có lẽ về các task thiên về logic, Py vẫn chưa tìm được cách tối ưu prompt, nên có thể thấy các flow được vẽ chỉ có thể dùng để làm nháp cho những version hoàn thiện hơn bởi chính PO. Nên Py gửi thêm ở đây một trong nhiều user flows Py đã vẽ như nỗ lực diễn giải rõ hơn user flow là gì và nó đang được dùng như thế nào.
Ví dụ by Anpy
- Ackerman, C. E. (2023, September 11). What Is the Comfort Zone & Why Is It So Hard to Leave It?. Positive Psychology. https://positivepsychology.com/comfort-zone/
- Stanford. (n.d.). Hướng dẫn viết sơ đồ khối thuật toán trong lập trình. Stanford Academy Vietnam. Retrieved April 28, 2025, from https://stanford.com.vn/kien-thuc-lap-trinh/tin-chi-tiet/cagId/27/id/22569/huong-dan-viet-so-do-khoi-thuat-toan-trong-lap-trinh
- Lucid Software Inc. (n.d.). BPMN Tutorial: Quick Introduction to Business Process Model and Notation. Lucidchart. Retrieved April 28, 2025, from https://www.lucidchart.com/pages/tutorial/bpmn
Cám ơn bạn đã nán lại cho đến những dòng cuối cùng.
Thật ra còn một từ khóa chưa được đề cập đến là UML, mong sẽ nhận được bình luận từ ai đó về từ khóa này để Py tự tin viết thêm nhé. Và chắc chắn sẽ có Vỡ lòng 2 (hoặc 3) để Py kể nốt về bài tập đầu đời không thể quên này.
Chúc bạn nhiều may mắn và bình an.
Anpy
Leave a Reply