Mở đầu — vì sao bài này quan trọng
Khi bạn còn làm Finance hay Kế toán, môi trường làm việc của bạn xoay quanh một bộ công cụ rất quen thuộc: Excel, phần mềm kế toán (MISA, Fast, SAP, Oracle), email, và những folder chia sẻ trên ổ mạng. Mọi thứ đều tuyến tính: số liệu vào, đối chiếu, lên báo cáo, đóng sổ. Nhưng khi bước chân vào vai trò Business Analyst, bạn sẽ nhận ra một sự thật gây sốc nhỏ trong tuần đầu tiên: gần như mọi đội ngũ phần mềm ở Việt Nam hiện nay đều sống trong hai công cụ mà có thể bạn chưa từng nghe đến — Jira và Confluence.
Tôi đã chứng kiến nhiều bạn chuyển nghề rất giỏi về tư duy nghiệp vụ, nhưng tuần đầu lúng túng vì không biết "ticket" là gì, không hiểu vì sao dev hỏi "Acceptance Criteria nằm ở đâu", hay viết tài liệu xong gửi qua email rồi cả team không ai tìm thấy. Lý do không phải vì bạn yếu — mà vì bạn chưa được trao bản đồ của một hệ sinh thái làm việc hoàn toàn mới.
Tin vui là: nền tảng Finance của bạn cực kỳ phù hợp với hai công cụ này. Confluence là "sổ cái tài liệu" — nơi mọi requirement được ghi chép, đánh số phiên bản, kiểm soát thay đổi y hệt cách bạn kiểm soát chứng từ. Jira là "hệ thống theo dõi công việc" — vận hành theo logic luồng trạng thái, deadline và trách nhiệm, không khác gì cách bạn theo dõi tiến độ closing cuối tháng. Bài học này sẽ giúp bạn làm chủ workflow Jira + Confluence từ góc nhìn của một người Finance, để ngày đầu tiên ngồi vào ghế BA, bạn không bị động mà chủ động dẫn dắt.
Khái niệm cốt lõi
Confluence là gì — và vì sao nó giống "sổ cái tài liệu"
Confluence là một wiki nội bộ của công ty, do hãng Atlassian phát triển (cùng hãng với Jira). Hãy hình dung nó như một thư viện tài liệu sống, nơi mọi người trong team cùng viết, cùng đọc, cùng chỉnh sửa trên một trang web duy nhất thay vì gửi file Word qua lại.
Điểm mấu chốt khiến Confluence khác hẳn với việc lưu file trên ổ đĩa hay Google Drive:
- Mỗi tài liệu là một "page" (trang), có thể lồng nhau theo cấu trúc cây cha–con. Một dự án thường có một Index page (trang chỉ mục) làm gốc, rồi từ đó tỏa ra các trang con: BRD, SRS, các spec từng tính năng, biên bản họp, quyết định kỹ thuật.
- Versioning tự động — mỗi lần ai đó sửa trang, Confluence lưu lại một phiên bản mới. Bạn có thể xem ai sửa gì, lúc nào, và quay về phiên bản cũ bất cứ lúc nào. Với người Finance, đây chính là "audit trail" (dấu vết kiểm toán) mà bạn vốn quen thuộc — không cần đặt tên file kiểu "BRD_final_v3_final_thật.docx" nữa.
- Comment ngay trên nội dung — stakeholder có thể bôi đen một dòng và để lại bình luận, giống như review chứng từ có ghi chú bên lề.
Jira là gì — và vì sao nó giống "theo dõi tiến độ closing"
Nếu Confluence là nơi mô tả công việc, thì Jira là nơi theo dõi việc thực thi công việc đó. Jira chia công việc thành các đơn vị gọi là issue (thường dịch là "ticket" hoặc "đầu việc"). Mỗi issue có một mã định danh duy nhất, ví dụ PAY-142, và đi qua một chuỗi trạng thái cho đến khi hoàn thành.
Hệ thống phân cấp công việc trong Jira (gọi là issue hierarchy) thường gồm ba tầng:
- Epic — một mảng nghiệp vụ lớn, một mục tiêu kinh doanh. Ví dụ: "Tự động hóa đối soát thanh toán". Một Epic có thể kéo dài nhiều tháng.
- Story (User Story) — một nhu cầu cụ thể của người dùng, đủ nhỏ để hoàn thành trong một sprint (chu kỳ làm việc, thường 2 tuần). Ví dụ: "Là kế toán viên, tôi muốn upload file sao kê ngân hàng để hệ thống tự động khớp với hóa đơn."
- Sub-task / Task — các đầu việc nhỏ kỹ thuật để hoàn thành một Story, thường do dev tự chia.
Mỗi issue di chuyển qua một workflow (luồng trạng thái), ví dụ điển hình: To Do → In Progress → In Review → In Test → Done. Đây chính là điểm mà tư duy Finance của bạn phát huy: bạn vốn đã quen với việc một chứng từ phải đi qua các bước "lập → kiểm tra → phê duyệt → hạch toán → lưu trữ". Workflow Jira chỉ là phiên bản phần mềm của cùng một logic kiểm soát luồng.
Mối quan hệ giữa Jira và Confluence — cặp đôi không thể tách rời
Đây là điều quan trọng nhất cần khắc cốt: Jira và Confluence không thay thế nhau, chúng bổ trợ nhau.
- Confluence trả lời câu hỏi "Cái này phải làm gì, vì sao, chi tiết ra sao?" — tài liệu sâu, dài, có ngữ cảnh.
- Jira trả lời câu hỏi "Ai đang làm, đến đâu rồi, bao giờ xong?" — đầu việc ngắn gọn, theo dõi tiến độ.
Tình huống thực tế
Ví dụ 1: Lan — kế toán tổng hợp chuyển BA tại một công ty fintech ở TP.HCM
Lan từng là kế toán tổng hợp 4 năm, vừa chuyển sang làm BA cho một startup fintech về ví điện tử có khoảng 60 nhân sự. Tuần đầu, leader giao cho cô phụ trách tính năng "Hoàn tiền giao dịch lỗi" (refund). Phản xạ cũ của Lan là mở Word, viết một tài liệu 12 trang, rồi gửi email cho cả team.
Kết quả: dev không đọc email (họ chỉ nhìn Jira), tester không biết bản nào là mới nhất, và sau hai lần Lan sửa, có ba phiên bản file trôi nổi trong inbox mọi người. Sprint đầu trễ một tuần.
Sau khi được mentor hướng dẫn, Lan làm lại theo chuẩn: cô tạo một Index page trên Confluence tên "Dự án Ví — Module Hoàn tiền", bên dưới có một spec page riêng cho tính năng refund, mô tả luồng nghiệp vụ, business rule (ví dụ: "chỉ hoàn tiền trong 7 ngày kể từ giao dịch", "số tiền hoàn không vượt quá số tiền gốc"). Sau đó cô tạo một Epic trong Jira tên "Hoàn tiền giao dịch lỗi", chia thành 4 Story, và mỗi Story đều gắn link tới đúng đoạn trong spec page.
Bài học rút ra: tài liệu sống ở Confluence, công việc sống ở Jira, và hai bên liên kết với nhau. Khi business rule "7 ngày" sau này đổi thành "30 ngày", Lan chỉ sửa một chỗ duy nhất trên Confluence — phiên bản cũ tự lưu lại, mọi người vẫn nhìn vào cùng một nguồn sự thật. Đúng nguyên tắc "single source of truth" mà Finance gọi là "một sổ cái thống nhất".
Ví dụ 2: Đội ngũ tại một ngân hàng số — cấu trúc Epic theo nghiệp vụ
Tại một ngân hàng số ở Hà Nội, đội sản phẩm tổ chức Jira theo đúng tư duy nghiệp vụ ngân hàng. Họ không tạo Epic kiểu kỹ thuật ("Xây API", "Làm màn hình") mà tạo Epic theo mảng nghiệp vụ: "Mở tài khoản eKYC", "Chuyển khoản liên ngân hàng", "Quản lý hạn mức tín dụng".
Một BA cũ là chuyên viên tín dụng phụ trách Epic "Quản lý hạn mức tín dụng". Anh chia ra các Story dựa trên các tình huống nghiệp vụ mà anh đã quá hiểu từ thời làm tín dụng: "Khách hàng yêu cầu tăng hạn mức", "Hệ thống tự động giảm hạn mức khi quá hạn thanh toán", "Cảnh báo khi sử dụng vượt 80% hạn mức". Mỗi Story có Acceptance Criteria viết theo công thức Given-When-Then, và link tới business rule catalog trên Confluence.
Bài học rút ra: nền nghiệp vụ Finance/Banking giúp bạn cấu trúc Epic và Story theo logic kinh doanh, không phải theo logic kỹ thuật. Đây là lợi thế lớn — nhiều BA xuất thân thuần công nghệ lại yếu chính ở chỗ này. Khi bạn đặt tên Epic và chia Story theo nghiệp vụ, cả team hiểu vì sao họ làm, không chỉ làm cái gì.
Ví dụ 3: Sai lầm về "board" và sprint của một bạn mới
Minh, cựu kiểm toán nội bộ, chuyển sang BA tại một công ty phần mềm ERP. Anh quen với mô hình "đóng sổ định kỳ" nên nghĩ Jira board cũng vận hành cứng nhắc: cứ kéo hết ticket vào sprint, ai làm nấy chịu. Trong sprint đầu, anh nhồi 25 Story vào một sprint 2 tuần, kết quả là cuối sprint chỉ xong 9 cái, board ngập màu đỏ, daily standup biến thành buổi giải trình căng thẳng.
Vấn đề là Minh đã coi sprint như một kỳ closing bắt buộc phải hoàn thành 100% bằng mọi giá. Sau đó anh học được rằng sprint là một cam kết có giới hạn năng lực — team chỉ nhận đúng khối lượng làm được, đo bằng story point. Anh học cách dùng board để nhìn "luồng" công việc: cột nào bị nghẽn (ví dụ quá nhiều ticket kẹt ở "In Review") thì xử lý điểm nghẽn đó, thay vì chỉ chăm chăm đẩy số lượng.
Bài học rút ra: workflow Jira là công cụ quản lý luồng làm việc liên tục, không phải kỳ đóng sổ "được ăn cả ngã về không". Tư duy kiểm soát của Finance là tài sản, nhưng cần điều chỉnh từ "tuân thủ cứng" sang "tối ưu luồng".
Hướng dẫn từng bước
Dưới đây là quy trình chuẩn để bạn thiết lập và vận hành một tính năng từ đầu đến cuối bằng Jira + Confluence.
Bước 1 — Dựng Index page trên Confluence cho dự án. Mỗi dự án có một trang gốc. Trên đó liệt kê: mục tiêu dự án, danh sách stakeholder, link tới BRD, SRS, RTM, và một mục lục dẫn tới các spec page con. Đây là "trang bìa sổ cái" của bạn.
Bước 2 — Viết spec page cho từng feature. Mỗi tính năng một trang. Cấu trúc gợi ý: bối cảnh nghiệp vụ → user story tổng quát → business rules → process flow (có thể nhúng sơ đồ) → wireframe/mockup nếu có → Acceptance Criteria → các câu hỏi mở chưa chốt. Dùng template "Product Requirements" có sẵn của Confluence để khỏi viết từ con số không.
Bước 3 — Tạo Epic trong Jira. Đặt tên Epic theo mảng nghiệp vụ, không theo kỹ thuật. Trong phần mô tả Epic, dán link tới Index page hoặc spec page liên quan trên Confluence.
Bước 4 — Chia Epic thành các Story. Mỗi Story viết theo công thức "Là [vai trò], tôi muốn [hành động], để [giá trị]". Story phải đủ nhỏ để xong trong một sprint. Trong mỗi Story, điền Acceptance Criteria (tiêu chí nghiệm thu) — đây là phần dev và tester đọc kỹ nhất.
Bước 5 — Liên kết Story với Confluence. Trong mỗi Story, dùng tính năng "Link" để gắn tới đúng spec page. Đừng copy toàn bộ nội dung tài liệu vào Jira — Jira chỉ giữ phần ngắn gọn, chi tiết nằm ở Confluence. Tránh trùng lặp gây lệch phiên bản.
Bước 6 — Đưa Story vào Backlog và lên kế hoạch Sprint. Trong buổi Sprint Planning, team chọn các Story từ backlog đưa vào sprint dựa trên độ ưu tiên và năng lực. Vai trò BA là làm rõ Story, trả lời thắc mắc, đảm bảo Acceptance Criteria không mơ hồ.
Bước 7 — Theo dõi qua Board. Trong sprint, mỗi ngày nhìn board để biết ticket đang ở trạng thái nào. Khi dev hỏi, bạn là người làm rõ requirement; khi tester báo bug, bạn xác nhận đó có đúng là lỗi hay là yêu cầu thay đổi.
Bước 8 — Cập nhật tài liệu khi có thay đổi. Mỗi khi requirement đổi, sửa trên Confluence trước (để giữ versioning), rồi cập nhật lại Story/Acceptance Criteria trong Jira. Đừng bao giờ chỉ sửa miệng trong daily mà quên cập nhật tài liệu — đó là nguồn gốc của mọi hiểu lầm sau này.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhồi toàn bộ tài liệu vào mô tả Jira. Nhiều bạn mới copy cả trang BRD vào ô description của một Story. Hậu quả: Jira trở nên rối, và khi tài liệu đổi, bạn quên cập nhật ở Jira. Mẹo: Jira giữ phần tóm tắt + Acceptance Criteria + link; chi tiết để Confluence.
Lỗi 2 — Đặt tên Epic theo kỹ thuật thay vì nghiệp vụ. "Làm backend", "Sửa database" không phải là Epic tốt. Mẹo: dùng chính lợi thế nghiệp vụ Finance của bạn để đặt tên theo giá trị kinh doanh, ví dụ "Tự động đối soát công nợ".
Lỗi 3 — Acceptance Criteria mơ hồ. Viết "hệ thống phải chạy đúng" là vô nghĩa với dev và tester. Mẹo: viết theo Given-When-Then, có số liệu cụ thể: "Cho file sao kê có 100 dòng, khi upload, thì hệ thống khớp tự động tối thiểu 95% trong vòng 30 giây."
Lỗi 4 — Coi Confluence như ổ cứng để vứt file. Tạo trang lộn xộn, không có cây phân cấp, không Index page. Ba tháng sau không ai tìm thấy gì. Mẹo: luôn bắt đầu bằng Index page, đặt tên trang nhất quán, dùng label để gắn nhãn.
Lỗi 5 — Không tận dụng versioning và comment. Vẫn gửi file qua email để xin ý kiến. Mẹo: để stakeholder comment trực tiếp trên trang; mọi phản hồi và thay đổi được lưu vết, đúng tinh thần audit của dân Finance.
Mẹo nâng cao: Dùng macro Jira trong Confluence để nhúng bảng "tất cả issue thuộc Epic này" vào spec page. Bảng tự cập nhật trạng thái, cho stakeholder thấy tiến độ thực mà không cần bạn báo cáo thủ công — giống như một dashboard tự chạy thay cho việc cập nhật báo cáo Excel hằng ngày.
Bài tập thực hành
- Lập cấu trúc Confluence. Chọn một nghiệp vụ Finance bạn am hiểu (ví dụ: quy trình duyệt tạm ứng, đối soát công nợ, hoặc lập báo cáo thuế). Phác thảo trên giấy hoặc trong một tài liệu: một Index page và ít nhất 3 spec page con. Ghi rõ mỗi spec page sẽ chứa nội dung gì.
- Viết Epic và 4 Story. Cũng với nghiệp vụ trên, hãy đặt tên một Epic theo logic nghiệp vụ, rồi chia thành 4 Story theo công thức "Là... tôi muốn... để...". Đảm bảo mỗi Story đủ nhỏ để xong trong 2 tuần.
- Viết Acceptance Criteria. Chọn một trong 4 Story vừa viết, soạn ít nhất 3 tiêu chí nghiệm thu theo định dạng Given-When-Then, có con số cụ thể.
- Vẽ workflow. Phác sơ đồ luồng trạng thái cho loại issue "Bug" trong dự án của bạn, từ lúc tester phát hiện đến lúc đóng. So sánh nó với quy trình xử lý chênh lệch khi đối soát mà bạn từng làm — bạn sẽ thấy chúng giống nhau đến mức nào.
- Tự kiểm tra. Viết ra 3 thông tin nên nằm ở Jira và 3 thông tin nên nằm ở Confluence. Giải thích vì sao. Đây là bài kiểm tra xem bạn đã thực sự hiểu ranh giới giữa hai công cụ chưa.
Tóm tắt
Jira và Confluence là hệ thần kinh trung ương của mọi đội ngũ phần mềm hiện đại, và làm chủ chúng là kỹ năng sống còn của một BA. Hãy nhớ ba ý cốt lõi:
- Confluence là sổ cái tài liệu — nơi lưu BRD, SRS, RTM và spec từng tính năng, có Index page làm gốc, mỗi feature một trang riêng, được đánh phiên bản tự động như một audit trail. Đây là "single source of truth" cho mọi yêu cầu.
- Jira là hệ thống theo dõi công việc — phân cấp Epic → Story → Sub-task, mỗi issue đi qua một workflow trạng thái tương tự cách chứng từ đi qua các bước kiểm soát. Đặt tên Epic theo nghiệp vụ, viết Story theo công thức người dùng, và luôn có Acceptance Criteria rõ ràng.
- Hai công cụ bổ trợ, không thay thế — Confluence trả lời "làm gì, vì sao", Jira trả lời "ai làm, đến đâu rồi". Liên kết chúng bằng link, đừng sao chép trùng lặp.