Mở đầu — vì sao bài này quan trọng
Có một sự thật mà ít người nói với bạn khi bạn chuyển từ Finance/Kế toán sang BA: bạn sẽ thường xuyên đứng giữa lằn ranh giữa "người làm requirement" và "người gánh tiến độ dự án". Trên lý thuyết, quản lý dự án (Project Management — PM) là việc của Project Manager. Nhưng trong thực tế tại Việt Nam, đặc biệt ở các công ty fintech, ngân hàng số hay các nhà thầu phần mềm vừa và nhỏ, ranh giới đó mờ đi rất nhiều. BA thường là người hiểu rõ nghiệp vụ nhất, là người mà stakeholder tin tưởng nhất, và do đó cũng là người bị hỏi đầu tiên khi câu chuyện "bao giờ xong?" được đặt ra trong cuộc họp.
Tin tốt là: nếu bạn xuất thân từ Finance/Kế toán, bạn đã có sẵn một bộ não rất phù hợp với quản lý dự án. Bạn quen với deadline cứng (hạn nộp báo cáo thuế, hạn chốt sổ), quen với việc kiểm soát ngân sách, quen với việc đánh giá rủi ro tài chính, và quen với tư duy "đánh đổi" — muốn cái này thì phải hy sinh cái kia. Đây chính xác là tư duy cốt lõi của một Project Manager giỏi.
Bài này không biến bạn thành PMP (chứng chỉ Project Management Professional), và cũng không dạy bạn cách lập kế hoạch Agile chi tiết (đã có Bài 23 lo phần đó). Mục tiêu của bài là trang bị cho bạn bộ khái niệm nền tảng về quản lý dự án — đủ để bạn nói cùng ngôn ngữ với PM, đủ để bạn nhận diện khi nào dự án đang chệch hướng, và đủ để bạn tự tin gánh vai trò "BA kiêm điều phối" khi dự án nhỏ không có PM riêng. Đây là kỹ năng giúp bạn thăng tiến nhanh, vì một BA hiểu PM là một BA mà sếp dám giao việc lớn.
Khái niệm cốt lõi
Tam giác ràng buộc (Triple Constraint) và sáu yếu tố nền tảng
Trái tim của quản lý dự án là một ý tưởng đơn giản đến mức đẹp: mọi dự án đều bị giới hạn bởi ba thứ — Scope (phạm vi), Schedule (lịch trình), và Cost (chi phí/ngân sách) — và ba thứ này luôn kéo nhau. Đây gọi là Triple Constraint hay tam giác ràng buộc. Ở giữa tam giác là Quality (chất lượng). Bao quanh tất cả là Risk (rủi ro).
Hãy hiểu từng yếu tố theo ngôn ngữ của người làm Finance:
| Khái niệm | Nghĩa | Tương đương trong tư duy Finance |
|---|---|---|
| Scope | Phạm vi: làm những gì, không làm những gì | Giống như "phạm vi kiểm toán" — định rõ ranh giới trước khi bắt tay |
| Schedule | Lịch trình: khi nào làm, khi nào xong | Giống lịch chốt sổ, hạn nộp báo cáo theo kỳ |
| Cost | Ngân sách: tốn bao nhiêu tiền, bao nhiêu man-day | Giống dự toán ngân sách (budgeting) |
| Quality | Chất lượng đầu ra: output có đạt chuẩn không | Giống độ chính xác của báo cáo tài chính — sai một con số là vỡ trận |
| Risk | Rủi ro: điều gì có thể trục trặc | Giống đánh giá rủi ro tín dụng, rủi ro thanh khoản |
Scope — kẻ thù lớn nhất tên là "Scope Creep"
Scope creep là hiện tượng phạm vi dự án phình to dần qua từng yêu cầu nhỏ "tiện thể làm luôn" mà không ai chính thức phê duyệt thêm thời gian hay ngân sách. Với BA, đây là chiến trường chính, vì bạn là người gác cổng requirement. Mỗi khi stakeholder nói "à thêm cái nút này nữa nhé, đơn giản mà", đó là một viên gạch của scope creep. Công cụ chống lại nó là Change Request (yêu cầu thay đổi) — mọi thay đổi scope phải được ghi nhận, ước lượng tác động lên Schedule và Cost, rồi được người có thẩm quyền duyệt. (Bài 29 về Change Management sẽ đi sâu phần này.)
Schedule — chuỗi công việc và đường găng
Một lịch trình dự án không phải là danh sách việc xếp cạnh nhau, mà là một mạng lưới các công việc có quan hệ phụ thuộc. Critical Path (đường găng) là chuỗi công việc dài nhất quyết định ngày kết thúc dự án — chậm bất kỳ việc nào trên đường găng là chậm cả dự án. Người Finance hiểu điều này rất nhanh: giống như bạn không thể lập báo cáo tài chính hợp nhất trước khi từng công ty con chốt sổ — có một trình tự bắt buộc.
Cost — ngân sách và man-day
Trong dự án phần mềm, "tiền" thường được quy đổi ra man-day (số ngày công của một người) hoặc man-month. Nếu một module ước tính 40 man-day và team có 4 dev, lý thuyết là 10 ngày làm việc. Nhưng cẩn thận với cái bẫy mà Fred Brooks đã cảnh báo: thêm người vào một dự án đang trễ thường làm nó trễ hơn, vì chi phí giao tiếp và đào tạo tăng theo cấp số nhân.
Quality và Risk
Quality là việc output đáp ứng đúng acceptance criteria đã định. Risk là quản lý những điều có thể đi sai. Một công cụ tối thiểu bạn nên dùng là Risk Register (sổ đăng ký rủi ro) với bốn cột: mô tả rủi ro, xác suất xảy ra, mức tác động, và phương án ứng phó. Tư duy này quá quen thuộc với dân Finance — nó chính là bản chất của quản trị rủi ro.
Tình huống thực tế
Tình huống 1 — Scope creep nuốt chửng deadline tại một fintech cho vay tiêu dùng
Một công ty fintech cho vay tiêu dùng tại TP.HCM (đặt tên là CredFast) triển khai dự án nâng cấp luồng phê duyệt khoản vay, deadline cam kết với ban giám đốc là 8 tuần, ngân sách 320 man-day cho team 5 người. Lan, một BA mới chuyển từ vị trí chuyên viên phân tích tín dụng, phụ trách requirement.
Tuần thứ ba, trưởng phòng vận hành đề nghị "thêm luôn màn hình dashboard theo dõi tỷ lệ nợ xấu, tiện mà". Tuần thứ tư, phòng pháp chế muốn "thêm bước kiểm tra CIC tự động". Tuần thứ năm, marketing muốn "gắn thêm chương trình giới thiệu bạn bè". Mỗi yêu cầu đều nghe có vẻ nhỏ, và vì Lan vốn quen làm hài lòng các phòng ban, cô gật đầu hết.
Kết quả: đến tuần thứ 7, team mới hoàn thành 60% khối lượng. Dự án trễ 3 tuần, và Quality sụp đổ — luồng phê duyệt chính có 12 bug nghiêm trọng vì dev bị phân tán sang ba tính năng phát sinh.
Bài học rút ra: Lan đã thiếu một thứ cốt lõi — cơ chế kiểm soát Scope. Đáng lẽ với mỗi yêu cầu mới, cô phải ước lượng tác động (ví dụ: "dashboard nợ xấu = thêm 25 man-day = lùi deadline 4 ngày") và đưa lên người có thẩm quyền quyết định đánh đổi. Cô không cần nói "không" với phòng ban; cô chỉ cần làm cho cái giá của chữ "có" hiện rõ lên bàn. Tư duy "mỗi thay đổi đều có chi phí" này chính là tư duy của một kế toán — Lan đã có nó, chỉ là chưa áp dụng vào quản lý dự án.
Tình huống 2 — Đường găng bị bỏ qua tại dự án core banking
Một ngân hàng số (đặt tên là Ngân hàng Sao Mai) triển khai tích hợp cổng thanh toán mới vào hệ thống core. Dự án có nhiều luồng song song: phát triển API, kiểm thử bảo mật, ký hợp đồng với đối tác cổng thanh toán, và xin phê duyệt từ Ngân hàng Nhà nước.
Team kỹ thuật tập trung 100% sức lực vào việc code API cho thật nhanh, hoàn thành sớm 2 tuần và rất tự hào. Nhưng dự án vẫn trễ 6 tuần. Lý do? Việc xin phê duyệt pháp lý từ NHNN — vốn nằm trên đường găng — không ai theo dõi sát, và nó mất tới 10 tuần thay vì 4 tuần như giả định. Code API xong sớm cũng vô nghĩa vì không thể go-live khi chưa có giấy phép.
Bài học rút ra: Tăng tốc một công việc không nằm trên đường găng không giúp dự án về đích sớm hơn — nó chỉ tạo ra cảm giác bận rộn. Người làm Finance hiểu điều này qua khái niệm "nút thắt cổ chai" (bottleneck): tối ưu một khâu không phải nút thắt thì tổng throughput không đổi. BA giỏi sẽ nhận diện đâu là việc thực sự quyết định ngày go-live và dồn sự chú ý điều phối vào đó — trong trường hợp này là hồ sơ pháp lý, không phải dòng code.
Tình huống 3 — BA gánh vai PM tại một startup SaaS
Tại một startup SaaS kế toán cho doanh nghiệp nhỏ (đặt tên là SoBoOk), không có Project Manager riêng. Minh, một BA xuất thân kế toán, được giao điều phối luôn dự án xây tính năng hóa đơn điện tử kết nối Tổng cục Thuế.
Minh áp dụng đúng tư duy chốt sổ kế toán: anh lập một bảng theo dõi đơn giản trên Notion gồm danh sách công việc, người phụ trách, ngày bắt đầu, ngày hạn, và trạng thái. Mỗi sáng anh dành 15 phút cập nhật và mỗi tuần gửi một email "tình hình dự án" cho founder gồm ba mục: đã xong gì, đang vướng gì, rủi ro tuần tới. Anh cũng lập một Risk Register nhỏ, trong đó ghi rõ rủi ro lớn nhất: "API của Tổng cục Thuế hay thay đổi spec đột ngột — phương án: giữ liên hệ trực tiếp với cán bộ kỹ thuật bên thuế, kiểm tra changelog hàng tuần."
Khi API của thuế thật sự đổi định dạng XML giữa chừng, Minh đã chuẩn bị tinh thần và phương án, nên dự án chỉ trễ 4 ngày thay vì sụp đổ. Founder sau đó cất nhắc anh lên vị trí Product Owner.
Bài học rút ra: Bạn không cần công cụ phức tạp để quản lý một dự án nhỏ — bạn cần kỷ luật theo dõi đều đặn và tư duy lường trước rủi ro. Đây chính là hai thói quen mà nghề Finance/Kế toán đã rèn cho bạn: kỷ luật chốt sổ định kỳ và bản năng phòng ngừa sai sót.
Hướng dẫn từng bước
Đây là quy trình tối thiểu để một BA điều phối hoặc theo dõi một dự án nhỏ tới vừa:
- Xác định và viết rõ Scope. Trước khi bắt đầu, viết một danh sách hai cột: "Trong phạm vi" và "Ngoài phạm vi". Cột thứ hai quan trọng không kém cột thứ nhất — nó là tấm khiên chống scope creep. Đưa cho stakeholder ký xác nhận (dù chỉ là một email đồng ý).
- Phân rã công việc (Work Breakdown). Chia dự án thành các hạng mục lớn, rồi chia tiếp thành các công việc đủ nhỏ để ước lượng được (lý tưởng là mỗi việc ≤ 5 ngày). Đây giống cách bạn phân rã một báo cáo tài chính thành từng khoản mục.
- Ước lượng thời gian và xác định phụ thuộc. Với mỗi việc, ước lượng man-day và ghi rõ nó phụ thuộc vào việc nào. Từ đây bạn vẽ ra được đường găng — chuỗi việc dài nhất.
- Lập lịch và phân bổ nguồn lực. Gắn người phụ trách và ngày hạn cho từng việc. Đừng phân bổ ai đó 100% công suất — luôn chừa khoảng đệm (buffer) 15–20% cho việc phát sinh, giống như bạn luôn để khoản dự phòng trong ngân sách.
- Lập Risk Register. Liệt kê ít nhất 5 rủi ro lớn nhất, mỗi cái có xác suất, tác động và phương án ứng phó. Cập nhật hàng tuần.
- Theo dõi và báo cáo định kỳ. Mỗi tuần trả lời ba câu: Tiến độ thực tế so với kế hoạch thế nào? Có việc nào trên đường găng đang trễ không? Rủi ro nào vừa hiện ra? Báo cáo ngắn gọn, trung thực, không tô hồng.
- Quản lý thay đổi có kỷ luật. Mọi yêu cầu mới đều đi qua một bước: ước lượng tác động lên Scope–Schedule–Cost rồi mới quyết định. Không có "tiện thể làm luôn".
Lỗi thường gặp & mẹo
Lỗi 1 — Nhận hết yêu cầu để làm hài lòng mọi người. Dân Finance/Kế toán thường giỏi phục vụ nội bộ và ngại từ chối. Nhưng trong dự án, "có" với mọi yêu cầu nghĩa là "không" với deadline. Mẹo: đừng từ chối, hãy báo giá. "Em làm được, nhưng nó cộng thêm 5 ngày — anh có muốn lùi go-live không?"
Lỗi 2 — Nhầm "bận rộn" với "tiến độ". Team chạy hết công suất chưa chắc dự án về đích, nếu họ không làm việc trên đường găng. Mẹo: mỗi tuần tự hỏi "việc nào nếu trễ sẽ làm cả dự án trễ?" và dồn sự chú ý vào đúng việc đó.
Lỗi 3 — Lập kế hoạch quá chi tiết rồi không cập nhật. Một bản Gantt 200 dòng đẹp đẽ nhưng để mốc meo còn tệ hơn một bảng Notion 20 dòng được cập nhật mỗi ngày. Mẹo: chọn công cụ nhẹ nhất mà bạn chịu cập nhật đều.
Lỗi 4 — Bỏ qua buffer. Lên lịch sát sạt 100% là tự sát, vì luôn có việc phát sinh, người nghỉ ốm, API đổi spec. Mẹo: áp dụng đúng tư duy "khoản dự phòng" của kế toán — luôn chừa 15–20%.
Lỗi 5 — Không phân biệt rõ vai BA và vai PM. Khi gánh cả hai, bạn dễ ưu tiên điều phối mà bỏ bê chất lượng requirement, hoặc ngược lại. Mẹo: nói rõ với sếp về ranh giới vai trò và thời gian bạn dành cho mỗi việc.
Mẹo tổng quát: Tận dụng "vốn liếng Finance" của bạn. Bạn đã quen với deadline cứng, ngân sách, rủi ro và sự đánh đổi. Hãy diễn đạt mọi vấn đề dự án bằng ngôn ngữ con số và chi phí — đó là điểm mạnh độc nhất khiến BA xuất thân Finance trở thành người điều phối đáng tin.
Bài tập thực hành
Bài 1 — Phân tích đánh đổi tam giác. Giả sử bạn là BA cho dự án CredFast ở Tình huống 1. Trưởng phòng vận hành yêu cầu thêm dashboard nợ xấu giữa dự án, ước tính tốn 25 man-day. Viết một đoạn 4–5 câu trình bày cho trưởng phòng ba lựa chọn đánh đổi: (a) giữ deadline nhưng cắt một tính năng khác, (b) lùi deadline, (c) thêm người. Nêu rõ tác động của mỗi lựa chọn.
Bài 2 — Lập Risk Register. Chọn một dự án bạn từng tham gia (hoặc giả định một dự án hóa đơn điện tử). Liệt kê 5 rủi ro lớn nhất theo bảng 4 cột: mô tả rủi ro, xác suất (cao/trung bình/thấp), tác động (cao/trung bình/thấp), phương án ứng phó.
Bài 3 — Tìm đường găng. Cho danh sách công việc sau với thời gian và phụ thuộc: A (3 ngày, không phụ thuộc) → B (4 ngày, cần A xong) → D (2 ngày, cần B xong); C (5 ngày, không phụ thuộc) → D. Hãy xác định đường găng và tổng thời gian tối thiểu để hoàn thành dự án. (Gợi ý: so sánh hai nhánh dẫn tới D.)
Bài 4 — Soạn báo cáo tuần. Viết một email báo cáo tình hình dự án dài tối đa 150 từ theo cấu trúc ba mục: đã hoàn thành, đang vướng, rủi ro tuần tới. Tập làm cho nó trung thực và súc tích như một bản tóm tắt số liệu kế toán.
Tóm tắt
Quản lý dự án không phải là một thế giới xa lạ với người xuất thân Finance/Kế toán — nó là phần mở rộng tự nhiên của những kỹ năng bạn đã có: kiểm soát ngân sách, tôn trọng deadline, quản trị rủi ro và tư duy đánh đổi. Cốt lõi của PM nằm ở tam giác ràng buộc Scope–Schedule–Cost, với Quality ở giữa và Risk bao quanh; bạn không thể tối ưu cả ba cạnh cùng lúc, nên việc của bạn là làm cho sự đánh đổi hiện rõ trên bàn họp.
Ba kẻ thù lớn nhất bạn cần canh chừng là scope creep (phạm vi phình to âm thầm), việc nhầm bận rộn với tiến độ (bỏ quên đường găng), và thiếu kỷ luật theo dõi. Ba thói quen cứu bạn là: viết rõ ranh giới scope, báo giá thay vì từ chối khi có yêu cầu mới, và theo dõi định kỳ với một Risk Register sống. Là một BA hiểu PM, bạn không cần trở thành Project Manager toàn thời gian — nhưng khi bạn nói cùng ngôn ngữ với PM và dám gánh điều phối lúc cần, bạn trở thành người mà sếp dám giao việc lớn. Và đó chính là bệ phóng nhanh nhất cho sự nghiệp BA của một người từng làm Finance.