Mở đầu — vì sao bài này quan trọng
Bạn đã đi qua 29 bài đầu tiên của khóa học. Nếu nhìn lại, bạn sẽ thấy mình đã đi một quãng đường khá dài: từ chỗ chỉ biết vẽ giao diện trên Figma, bạn đã học cách đọc BPMN, viết use case theo Cockburn, nắm được user story với Gherkin, biết dùng SQL cơ bản, đọc được ERD và API spec, làm quen với RTM, UAT, Jira và Confluence. Đó là rất nhiều mảnh ghép rời rạc.
Vấn đề của phần lớn học viên tại thời điểm này không phải là "thiếu kiến thức" — mà là chưa lắp được các mảnh ghép thành một bức tranh liền mạch. Bạn biết BPMN là gì, nhưng khi có một feature thật đặt trước mặt, bạn có biết bắt đầu vẽ As-Is từ đâu không? Bạn hiểu stakeholder analysis, nhưng bạn có thực sự dựng được ma trận stakeholder cho chính cái tính năng bạn từng thiết kế không?
Bài 30 là điểm bản lề của cả Module 1. Ở đây chúng ta làm hai việc: (1) review lại toàn bộ tư duy và công cụ của Module 1 dưới dạng một khung tích hợp, và (2) bắt tay vào Capstone 1 — bài tập lớn đầu tiên, nơi bạn lấy một feature bạn từng design và làm lại nó hoàn toàn theo góc nhìn của một Business Analyst.
Tại sao capstone lại quan trọng đến vậy? Vì trong phỏng vấn BA tại Việt Nam (chúng ta sẽ đào sâu ở Bài 47 và 48), nhà tuyển dụng gần như luôn hỏi: "Bạn đã từng phân tích một nghiệp vụ nào chưa? Cho tôi xem output." Một Designer chuyển ngành mà có sẵn một capstone tự làm — với As-Is/To-Be BPMN, stakeholder matrix, và bộ requirement rõ ràng — sẽ vượt xa những ứng viên chỉ nói suông "em có tư duy phân tích". Capstone chính là bằng chứng.
Khái niệm cốt lõi
Module 1 đã dạy bạn điều gì — nhìn lại theo tầng
Cách tốt nhất để review không phải là liệt kê 29 bài, mà là xếp chúng thành bốn tầng năng lực của một BA:
Tầng 1 — Tư duy (mindset). Sự dịch chuyển cốt lõi từ "designer nghĩ về trải nghiệm và giải pháp" sang "BA nghĩ về vấn đề nghiệp vụ và giá trị". Designer hỏi "làm sao cho đẹp và dễ dùng?"; BA hỏi "vấn đề thật là gì, ai chịu ảnh hưởng, và giải pháp này tạo ra giá trị gì cho doanh nghiệp?".
Tầng 2 — Mô hình hóa (modeling). Đây là nhóm công cụ trực quan mà Designer vốn có lợi thế: BPMN 2.0 để mô tả quy trình, journey map nâng cấp thành As-Is process flow, state machine để mô tả trạng thái, ERD để hiểu dữ liệu, wireframe annotation để bắc cầu giữa design và spec.
Tầng 3 — Đặc tả (specification). Nhóm biến hiểu biết thành văn bản có cấu trúc: use case theo Cockburn, user story và acceptance criteria theo Gherkin, business rule catalog, đọc/viết API spec.
Tầng 4 — Quản trị & thực thi (governance & delivery). Stakeholder analysis, workshop facilitation, RTM (Requirement Traceability Matrix), UAT planning, và workflow trên Jira + Confluence.
Khi làm capstone, bạn sẽ đi lần lượt qua bốn tầng này với một feature cụ thể. Đó chính là "tổng duyệt" trước khi bước vào Module 2.
As-Is và To-Be: linh hồn của capstone
Nếu chỉ được chọn một khái niệm quan trọng nhất của Module 1 để nhắc lại, tôi chọn cặp As-Is / To-Be.
As-Is là quy trình hiện tại — cách mọi thứ đang thực sự diễn ra, kể cả những phần lộn xộn, thủ công, thừa thãi. Với tư cách Designer, bạn thường bỏ qua As-Is vì bạn nhảy thẳng vào "thiết kế cái mới". Nhưng BA bắt buộc phải hiểu As-Is trước, vì nếu không hiểu vì sao quy trình hiện tại tệ, bạn sẽ không chứng minh được To-Be tốt hơn ở chỗ nào.
To-Be là quy trình mục tiêu — sau khi có giải pháp bạn đề xuất. Điểm mấu chốt: To-Be không phải là "màn hình đẹp hơn", mà là "quy trình ít bước hơn, ít lỗi hơn, nhanh hơn, hoặc tạo ra dữ liệu mà trước đây không có".
Sự khác biệt giữa As-Is và To-Be — được vẽ bằng BPMN — chính là phần "value proposition" của bạn dưới ngôn ngữ nghiệp vụ. Đây là thứ mà một Designer thuần túy hiếm khi tạo ra được, và cũng là thứ khiến hồ sơ BA của bạn có sức nặng.
Stakeholder analysis: ai là người thực sự quyết định
Ở Bài 20, chúng ta đã học chuyển empathy map thành stakeholder analysis matrix. Trong capstone, bạn sẽ dùng lại nó. Điểm cần nhớ: stakeholder không chỉ là "người dùng cuối" như trong tư duy Design. Stakeholder gồm cả người trả tiền cho dự án (sponsor), người vận hành nghiệp vụ (operations), đội kỹ thuật (dev, QA), bộ phận tuân thủ (compliance, đặc biệt quan trọng trong fintech/banking), và cả những người bị ảnh hưởng gián tiếp.
Công cụ chuẩn là ma trận Power/Interest (Quyền lực/Mức quan tâm), chia stakeholder vào 4 ô: Manage Closely (quyền lực cao, quan tâm cao), Keep Satisfied (quyền lực cao, quan tâm thấp), Keep Informed (quyền lực thấp, quan tâm cao), Monitor (thấp/thấp). Với mỗi stakeholder, bạn ghi rõ: họ cần gì, họ sợ gì, và bạn giao tiếp với họ thế nào.
Tình huống thực tế
Ví dụ 1 — Feature "đặt lịch spa" tại một chuỗi làm đẹp ở TP.HCM
Chị Ngọc, một UX Designer có 4 năm kinh nghiệm, từng thiết kế màn hình đặt lịch cho app của một chuỗi spa 8 chi nhánh tại TP.HCM. Bản Figma cũ của chị rất đẹp: chọn dịch vụ, chọn chi nhánh, chọn khung giờ, xác nhận. Khi làm capstone, chị lấy chính feature này ra làm lại theo góc BA.
Điều đầu tiên chị phát hiện khi vẽ As-Is process flow: đằng sau cái màn hình đẹp đó là một quy trình thủ công đầy lỗ hổng. Khách đặt lịch trên app, nhưng lễ tân từng chi nhánh vẫn phải mở một file Excel riêng để kiểm tra kỹ thuật viên nào rảnh — vì app không hề biết lịch làm việc thực của nhân viên. Kết quả: khoảng 15% lịch đặt bị trùng hoặc phải gọi lại khách để đổi giờ.
Khi vẽ To-Be, chị Ngọc không thêm màn hình nào cả. Chị đề xuất một thay đổi nghiệp vụ: đồng bộ lịch làm việc của kỹ thuật viên vào hệ thống, để bước "chọn khung giờ" chỉ hiện các slot thực sự khả dụng. Ở tầng stakeholder, chị nhận ra người quan trọng nhất không phải khách hàng mà là quản lý vận hành chuỗi — người chịu trách nhiệm về tỷ lệ lấp đầy ghế, và lễ tân — người đang phải làm thủ công.
Bài học: cùng một feature, Designer nhìn thấy màn hình, BA nhìn thấy quy trình và những người vận hành phía sau. Capstone của chị Ngọc trở thành câu chuyện phỏng vấn đắt giá vì nó có con số (15% trùng lịch) và có giải pháp nghiệp vụ chứ không chỉ giao diện.
Ví dụ 2 — Feature "hoàn tiền" của một sàn TMĐT giả định (ShopViet)
Anh Tuấn từng là Product Designer tại một startup e-commerce nhỏ tên ShopViet. Feature anh chọn cho capstone là luồng "yêu cầu hoàn tiền". Bản design cũ chỉ có 2 màn hình: nút "Yêu cầu hoàn tiền" và màn hình xác nhận.
Khi làm lại theo BA, anh phát hiện độ phức tạp thật nằm ở các trạng thái nghiệp vụ (state machine — Bài 22). Một yêu cầu hoàn tiền không đơn giản là "gửi rồi xong". Nó đi qua: Submitted → Under Review → Approved/Rejected → Refund Processing → Refunded/Failed. Mỗi trạng thái có business rule riêng: đơn dưới 200.000đ được duyệt tự động, đơn trên 2.000.000đ cần quản lý duyệt tay, đơn quá 7 ngày kể từ ngày nhận hàng bị từ chối tự động.
Anh Tuấn dựng một business rule catalog (Bài 23) gồm 12 rule, viết vài use case cho các luồng chính, và mô tả acceptance criteria theo Gherkin cho luồng duyệt tự động. Trong stakeholder analysis, anh xác định bộ phận tài chính (kiểm soát dòng tiền hoàn) và chăm sóc khách hàng (xử lý khiếu nại) là hai nhóm "Manage Closely" mà bản design cũ hoàn toàn bỏ quên.
Bài học: khi bạn buộc mình mô tả trạng thái và luật nghiệp vụ, một feature "2 màn hình" lộ ra là một hệ thống quy tắc phức tạp. Đây chính là năng lực BA mà thị trường trả tiền.
Ví dụ 3 — Sai lầm điển hình: capstone "đẹp mà rỗng"
Một học viên khác, bạn Linh, nộp capstone về feature onboarding của một app học tiếng Anh. Bản của Linh cực kỳ chỉn chu về mặt hình ảnh: sơ đồ BPMN được tô màu đẹp, wireframe annotation gọn gàng. Nhưng khi tôi review, tôi hỏi: "As-Is của em đâu?" Linh chỉ có To-Be. Em vẽ luôn quy trình lý tưởng mà không mô tả quy trình hiện tại, nên không ai biết em đang cải thiện điều gì.
Tệ hơn, phần stakeholder của Linh chỉ liệt kê "người dùng mới" — đúng thói quen Designer. Không có sponsor, không có growth team (người quan tâm tỷ lệ kích hoạt), không có đội nội dung. Và không có một con số nào: không tỷ lệ hoàn tất onboarding, không thời gian trung bình, không drop-off rate.
Bài học: capstone không phải bài thi vẽ đẹp. Nó là bài thi tư duy nghiệp vụ. Một As-Is xấu xí nhưng trung thực có giá trị hơn một To-Be lộng lẫy mà không neo vào thực tế nào.
Hướng dẫn từng bước
Dưới đây là quy trình 7 bước để hoàn thành Capstone 1. Hãy dành khoảng 6–10 giờ, chia làm vài buổi.
Bước 1 — Chọn feature. Lấy một feature bạn từng design thật (mở file Figma cũ). Tiêu chí: đủ nhỏ để làm trong một tuần, nhưng đủ có "nghiệp vụ" phía sau (đặt lịch, thanh toán, hoàn tiền, đăng ký, duyệt hồ sơ...). Tránh những feature thuần trình bày như "trang giới thiệu".
Bước 2 — Khai quật bối cảnh nghiệp vụ. Trước khi vẽ gì, trả lời bằng văn bản: Feature này giải quyết vấn đề gì cho doanh nghiệp? Ai là người thực sự hưởng lợi? Có con số nào không (dù là ước lượng)? Đây là bước Designer hay bỏ qua nhất.
Bước 3 — Vẽ As-Is process flow bằng BPMN. Mô tả quy trình hiện tại một cách trung thực, kể cả các bước thủ công, các điểm chờ, các nơi có thể sai. Dùng đúng ký hiệu BPMN đã học ở Bài 15: lane cho từng vai trò, gateway cho điểm rẽ nhánh, task cho hành động. Đánh dấu các "pain point" bằng ghi chú.
Bước 4 — Vẽ To-Be process flow. Đề xuất quy trình mục tiêu. Với mỗi thay đổi, ghi rõ nó xử lý pain point nào ở As-Is. Nhớ: To-Be là thay đổi quy trình, không chỉ là màn hình mới.
Bước 5 — Dựng stakeholder analysis matrix. Liệt kê tất cả stakeholder (tối thiểu 5–6, không chỉ end user). Xếp vào ma trận Power/Interest. Với mỗi người: nhu cầu, mối lo, cách giao tiếp.
Bước 6 — Viết bộ requirement tối thiểu. Chọn 2–3 luồng chính và viết: một use case ngắn theo Cockburn, 3–5 user story kèm acceptance criteria (Gherkin), và một business rule catalog nhỏ (5–10 rule). Không cần viết hết — cần đủ để thể hiện bạn biết cách.
Bước 7 — Đóng gói trên Confluence (hoặc một tài liệu). Ghép tất cả thành một trang gọn gàng theo cấu trúc: Bối cảnh → As-Is → Pain points → To-Be → Stakeholder → Requirements. Đây chính là artifact bạn mang đi phỏng vấn.
Lỗi thường gặp & mẹo
Lỗi 1 — Bỏ qua As-Is. Như trường hợp bạn Linh. Không có As-Is thì To-Be vô nghĩa vì không có gì để so sánh. Mẹo: luôn vẽ As-Is trước, dù nó xấu.
Lỗi 2 — To-Be chỉ là "redesign giao diện". Đây là cái bẫy nghề nghiệp lớn nhất của Designer chuyển BA. Nếu To-Be của bạn chỉ khác As-Is ở chỗ "màn hình đẹp hơn" mà quy trình y hệt, bạn vẫn đang tư duy như Designer. Mẹo: với mỗi thay đổi trong To-Be, tự hỏi "thay đổi này làm quy trình nhanh hơn / ít lỗi hơn / rẻ hơn / tạo dữ liệu mới ở chỗ nào?".
Lỗi 3 — Stakeholder chỉ có end user. Mẹo: luôn hỏi ba câu — Ai trả tiền cho feature này? Ai vận hành nó hằng ngày? Ai bị phạt nếu nó sai? Ba câu này thường lôi ra sponsor, operations và compliance.
Lỗi 4 — Không có con số. Một BA nói "cải thiện trải nghiệm" sẽ thua một BA nói "giảm tỷ lệ trùng lịch từ 15% xuống dưới 3%". Mẹo: nếu không có số thật, hãy ước lượng hợp lý và ghi rõ "ước lượng" — vẫn tốt hơn là không có gì.
Lỗi 5 — Tham lam viết requirement cho mọi luồng. Capstone không cần đầy đủ như SRS thật (cái đó để Module 2). Mẹo: chọn 2–3 luồng tiêu biểu và làm sâu, thay vì làm nông trên toàn bộ.
Mẹo tận dụng lợi thế Designer: Bạn giỏi trực quan hóa hơn phần lớn BA truyền thống. Hãy dùng lợi thế đó — BPMN của bạn sẽ rõ ràng và dễ đọc hơn, stakeholder matrix của bạn sẽ trình bày đẹp hơn. Nhưng nhớ: cái đẹp phải phục vụ nội dung nghiệp vụ, không thay thế nó.
Bài tập thực hành
Bài tập chính (Capstone 1): Hoàn thành đủ 7 bước ở trên cho một feature bạn từng design. Output bắt buộc gồm:
- As-Is BPMN — có ít nhất 2 lane và 1 gateway, đánh dấu tối thiểu 2 pain point.
- To-Be BPMN — mỗi thay đổi có ghi chú giải thích nó xử lý pain point nào.
- Stakeholder analysis matrix — tối thiểu 6 stakeholder, xếp vào ma trận Power/Interest, mỗi người có nhu cầu + mối lo.
- Bộ requirement tối thiểu — 1 use case Cockburn, 3 user story + acceptance criteria Gherkin, 5 business rule.
- Một chỉ số định lượng — dù là ước lượng — thể hiện giá trị của To-Be so với As-Is.
Gợi ý mở rộng (không bắt buộc): Đóng gói capstone lên Confluence hoặc Notion và xin một BA/mentor thật review. Chúng ta sẽ dùng lại chính capstone này khi xây BA portfolio ở Bài 47.
Tóm tắt
Bài 30 là điểm bản lề: bạn dừng lại, xâu chuỗi 29 bài của Module 1 thành bốn tầng năng lực BA (tư duy, mô hình hóa, đặc tả, quản trị & thực thi), rồi bắt tay vào Capstone 1 — lấy một feature bạn từng design và làm lại theo góc BA.
Ba điều cốt lõi cần nhớ: Một, As-Is trước To-Be luôn luôn — không có quy trình hiện tại thì không chứng minh được giá trị của giải pháp. Hai, To-Be là thay đổi quy trình và giá trị nghiệp vụ, không phải redesign giao diện — đây là ranh giới phân biệt BA thật với Designer đội lốt BA. Ba, stakeholder luôn rộng hơn end user, và mọi lập luận đều mạnh hơn khi có con số.
Qua các ví dụ của chị Ngọc (spa TP.HCM), anh Tuấn (ShopViet) và bạn Linh (bài học từ sai lầm), bạn đã thấy cùng một feature trông rất khác nhau qua lăng kính Designer và lăng kính BA. Capstone này không chỉ là bài tập — nó là artifact đầu tiên trong portfolio BA của bạn, thứ sẽ đi cùng bạn vào phòng phỏng vấn. Hãy làm nó tử tế. Khi bạn hoàn thành, bạn đã sẵn sàng bước vào Module 2, nơi chúng ta đào sâu BABOK và các kỹ thuật elicitation chuyên nghiệp.