Mở đầu — vì sao bài này quan trọng
Suốt 54 bài trước, chúng ta đã đi qua rất nhiều công cụ và framework: WBS, Critical Path, EVM, Risk Register, Scrum, Kanban... Nhưng có một sự thật mà bất kỳ Project Manager nào cũng sớm nhận ra: kiến thức lý thuyết chỉ trở nên sống động khi bạn nhìn thấy nó vận hành trong một dự án thật, với con người thật, deadline thật và cả những sai lầm thật.
Bài này là một case study — nghiên cứu tình huống về một dự án outsourcing phần mềm mà một công ty như FPT Software thực hiện cho một ngân hàng Nhật Bản. Tôi chọn bối cảnh này vì nó cực kỳ điển hình cho ngành công nghệ Việt Nam: chúng ta là quốc gia xuất khẩu dịch vụ phần mềm hàng đầu Đông Nam Á, và phần lớn các bạn PM ở Việt Nam sẽ hoặc đang làm việc trong mô hình "vendor Việt — khách hàng nước ngoài". Đây chính là sân chơi thật của các bạn.
Điều làm dự án outsourcing khó không phải là code. Code thì kỹ sư Việt Nam làm rất giỏi. Cái khó nằm ở khoảng cách: khoảng cách địa lý (múi giờ), khoảng cách văn hóa (cách người Nhật hiểu "xong việc" khác hẳn cách người Việt hiểu), khoảng cách ngôn ngữ, và khoảng cách kỳ vọng. Một PM giỏi trong bối cảnh này là người quản lý được những khoảng cách đó, chứ không chỉ quản lý task. Hãy cùng mổ xẻ một dự án cụ thể để thấy điều đó.
Khái niệm cốt lõi
Bối cảnh dự án — "MB Bank Facade"
Tôi sẽ dùng một dự án giả định nhưng dựng lại rất sát thực tế, đặt tên là Project MBF (Mobile Banking Facade). Đây là tổng hợp mô hình từ nhiều dự án ngân hàng Nhật mà các công ty Việt Nam thường nhận.
- Khách hàng: một ngân hàng khu vực tại Nhật (regional bank), gọi là Sakura Bank (tên giả).
- Vendor: FPT Software, đội dự án đặt tại Hà Nội, cộng thêm một BrSE (Bridge System Engineer) và một Comtor (Communicator — phiên dịch kỹ thuật) làm việc onsite tại Tokyo.
- Scope: xây dựng một lớp Core Banking Facade API — nghĩa là một tầng API trung gian bọc lấy hệ thống core banking cũ (viết bằng COBOL, chạy trên mainframe), để hệ thống mới và mobile app có thể gọi vào mà không đụng trực tiếp vào lõi cũ. Kèm theo đó là một mobile app (iOS + Android) cho khách hàng cá nhân: xem số dư, chuyển khoản, lịch sử giao dịch.
- Duration: 14 tháng, chia làm 3 phase.
- Team size: cao điểm 32 người (18 dev, 4 QA, 3 BrSE, 2 BA, 1 PM, 1 PL — Project Leader, 1 comtor, 2 DevOps).
- Mô hình hợp đồng: Phase 1 là Time & Material (T&M) cho giai đoạn khảo sát; Phase 2 và 3 chuyển sang Fixed Price cho phần phát triển.
Vì sao cấu trúc này quan trọng
Nếu bạn đọc kỹ, đã có ba quyết định quản lý dự án nằm ngay trong bối cảnh:
Một, vai trò BrSE và Comtor. Đây là đặc trưng gần như bắt buộc của dự án Nhật. BrSE là kỹ sư biết tiếng Nhật, đóng vai trò cầu nối kỹ thuật giữa khách hàng và đội dev Việt Nam. Comtor thuần về ngôn ngữ. Nếu thiếu hai vai trò này, mọi yêu cầu bị dịch sai và dự án chết vì hiểu lầm.
Hai, chia mô hình hợp đồng theo phase. Không ai dám ký Fixed Price cho một hệ thống core banking cũ mà mình chưa hiểu rõ. Nên Phase 1 khảo sát chạy T&M (khách trả theo giờ, rủi ro thuộc về khách), sau khi hiểu hệ thống mới báo giá Fixed Price. Đây là cách quản lý rủi ro hợp đồng kinh điển — nối thẳng với Bài 29 về Procurement.
Ba, facade pattern như một chiến lược giảm rủi ro kỹ thuật. Không đụng vào core cũ nghĩa là giảm rủi ro làm sập hệ thống ngân hàng — điều mà không ngân hàng nào tha thứ.
Tình huống thực tế
Tình huống 1 — Khủng hoảng "chất lượng theo định nghĩa Nhật Bản"
Ở cuối Phase 2, đội FPT giao module chuyển khoản. Về mặt kỹ thuật, code chạy đúng: chuyển tiền thành công, số dư cập nhật chính xác. Đội Việt Nam tự tin báo "done". Nhưng phía Sakura Bank trả về một bug list dài 147 điểm, phần lớn không phải lỗi logic mà là: khoảng cách padding trên màn hình lệch 2px, thông báo lỗi dùng sai kính ngữ tiếng Nhật (keigo), thời gian phản hồi 1.2 giây trong khi spec ngầm hiểu là dưới 1 giây, và log không ghi đủ chi tiết theo chuẩn audit của ngân hàng.
Đội Việt Nam sốc: "Những cái này đâu có trong requirement?" Phía Nhật cũng sốc ngược lại: "Sao phải viết ra? Đây là điều đương nhiên."
Diễn giải: đây là va chạm giữa văn hóa "requirement tường minh" (explicit — kiểu Việt/Âu Mỹ) và văn hóa "requirement ngầm định" (implicit — kiểu Nhật). Người Nhật có khái niệm hinshitsu (chất lượng) bao trùm cả những thứ không viết ra. Khoảng cách kỳ vọng này làm phát sinh rework khổng lồ, đội phải OT hai tuần, và tệ hơn là niềm tin bị xói mòn.
Bài học rút ra: Với khách Nhật, PM phải chủ động "khai quật" các yêu cầu ngầm ngay từ đầu — bằng cách hỏi về Definition of Done chi tiết, xin xem hệ thống cũ làm mẫu, và thiết lập một checklist chất lượng phi chức năng (non-functional). Đừng chờ requirement được viết ra hết mới làm; hãy giả định rằng phần chưa viết luôn tồn tại.
Tình huống 2 — Múi giờ và cái bẫy "làm việc bất đồng bộ"
Tokyo nhanh hơn Hà Nội 2 tiếng. Nghe thì nhỏ, nhưng vấn đề thật nằm ở nhịp làm việc. Mỗi khi đội Việt Nam gặp câu hỏi cần khách xác nhận, họ gửi email cuối ngày. Khách Nhật đọc sáng hôm sau, trả lời — nhưng thường trả lời bằng câu hỏi ngược lại để làm rõ. Một vòng hỏi–đáp mất trọn một ngày. Có những quyết định nhỏ mất cả tuần vì đi qua 5 vòng email.
PM của FPT nhận ra: độ trễ giao tiếp đang giết tiến độ nhiều hơn cả độ khó kỹ thuật. Anh áp dụng ba biện pháp. Thứ nhất, thiết lập một khung giờ vàng overlap 14h–17h (giờ VN) làm "core collaboration hours", trong đó BrSE và khách phải online cùng lúc. Thứ hai, thay email dài bằng một daily written stand-up trên Backlog (công cụ quản lý dự án phổ biến ở Nhật) với format cố định: hôm qua làm gì, hôm nay làm gì, đang chờ khách quyết gì. Thứ ba, gom mọi câu hỏi cần khách quyết vào một Q&A sheet duy nhất, cập nhật realtime, có deadline trả lời rõ ràng cho từng dòng.
Diễn giải: Vấn đề không phải 2 tiếng chênh lệch, mà là số vòng lặp (round-trip) trong giao tiếp. Mỗi vòng lặp bất đồng bộ nhân với độ trễ múi giờ tạo ra độ trễ cấp số nhân.
Bài học rút ra: Trong dự án phân tán, hãy tối ưu để giảm số round-trip, không chỉ giảm thời gian mỗi round-trip. Một câu hỏi được đặt đầy đủ ngữ cảnh, kèm luôn phương án đề xuất để khách chỉ cần gật hay lắc, đáng giá gấp mười lần một câu hỏi mở.
Tình huống 3 — Rủi ro nhân sự và "tài sản tri thức bốc hơi"
Tháng thứ 9, BrSE trưởng — người nắm rõ nhất logic COBOL của core cũ và quan hệ với khách — nhận offer lương cao hơn 40% và xin nghỉ. Đây là kịch bản kinh hoàng với mọi dự án outsourcing Việt Nam, nơi tỷ lệ nghỉ việc (attrition) trong ngành IT có thể lên 15–20%/năm. Tri thức về hệ thống cũ nằm gần như hết trong đầu một người.
May mắn là PM đã lường trước. Từ Phase 1, anh yêu cầu mọi buổi họp khảo sát core cũ phải có hai người tham dự (nguyên tắc no single point of knowledge), mọi phát hiện phải ghi vào một wiki tri thức nội bộ, và có một BrSE số 2 được luân phiên shadow. Khi BrSE trưởng nghỉ, người số 2 tiếp quản trong 3 tuần thay vì để dự án đứng hình 3 tháng.
Bài học rút ra: Trong outsourcing, rủi ro lớn nhất thường không phải công nghệ mà là con người rời đi mang theo tri thức. Hãy đối xử với tri thức như tài sản: bắt buộc tài liệu hóa, luôn có người dự phòng, và đừng bao giờ để một người duy nhất là "linh hồn" của một mảng quan trọng.
Hướng dẫn từng bước
Nếu bạn được giao một dự án outsourcing tương tự, đây là khung 7 bước để khởi động và vận hành nó cho chắc:
- Làm rõ mô hình hợp đồng trước khi làm rõ scope. Xác định phần nào T&M, phần nào Fixed Price. Nguyên tắc: cái gì chưa hiểu rõ thì đừng ký Fixed Price. Giai đoạn khảo sát/thăm dò luôn nên là T&M.
- Đầu tư vào cầu nối giao tiếp ngay từ ngày một. Với khách Nhật là BrSE + Comtor; với khách Âu Mỹ là một Client-facing PM/BA nói tiếng Anh trôi chảy. Đây không phải chi phí phụ, đây là hạ tầng sống còn.
- Khai quật requirement ngầm định. Tổ chức workshop, xin demo hệ thống cũ, hỏi thẳng về Definition of Done, non-functional requirements (hiệu năng, bảo mật, log, chuẩn audit). Ghi mọi thứ ngầm thành tường minh.
- Thiết kế nhịp giao tiếp bất đồng bộ. Định nghĩa core overlap hours, daily written stand-up, và một Q&A sheet trung tâm có deadline. Tối ưu để giảm số round-trip.
- Lập Risk Register có mục nhân sự. Ít nhất phải có: rủi ro attrition (giải pháp: no single point of knowledge, wiki, backup người), rủi ro hiểu lầm requirement, rủi ro hệ thống legacy phức tạp hơn dự kiến.
- Thiết lập cơ chế nghiệm thu theo phase. Mỗi phase có một milestone nghiệm thu (UAT) rõ ràng, có tiêu chí pass/fail được ký trước. Đừng để "done" mang hai nghĩa khác nhau giữa hai bên.
- Chuẩn bị bàn giao và bảo trì. Ngay từ đầu đã nghĩ đến tài liệu vận hành, quy trình hỗ trợ warranty, và transition sang đội maintenance — thứ mà chúng ta sẽ nói kỹ hơn ở các bài về closing.
Lỗi thường gặp & mẹo
Lỗi 1 — Hiểu "done" theo nghĩa của mình. Đội Việt hiểu done là "code chạy đúng logic". Khách Nhật hiểu done là "hoàn hảo cả những thứ không nói ra". Mẹo: viết một Definition of Done chung, ký cả hai bên, càng chi tiết càng tốt.
Lỗi 2 — Báo cáo tô hồng vì ngại mất mặt. Văn hóa Á Đông ngại báo tin xấu. PM báo "vẫn ổn" cho tới khi không giấu được, rồi vỡ trận. Mẹo: xây văn hóa "báo sớm được khen, giấu muộn bị phạt". Với khách Nhật, họ thích nghe vấn đề sớm hơn là bị bất ngờ — đây gọi là văn hóa horenso (báo cáo–liên lạc–bàn bạc).
Lỗi 3 — Coi nhẹ non-functional requirement. Hiệu năng, bảo mật, log, khả năng chịu tải — những thứ này với ngân hàng quan trọng ngang tính năng. Mẹo: tách hẳn một checklist NFR và test riêng.
Lỗi 4 — Dồn giao tiếp qua một người duy nhất (thường là BrSE trưởng). Người đó thành nút thắt cổ chai, và là điểm rủi ro nhân sự chí mạng. Mẹo: phân tán kênh giao tiếp, luôn có backup.
Mẹo vàng: Với khách Nhật, một buổi họp được chuẩn bị kỹ với tài liệu gửi trước, agenda rõ ràng, và biên bản (minutes) gửi ngay sau họp có giá trị xây niềm tin hơn mười lời hứa suông. Sự chỉn chu trong quy trình chính là thứ tạo ra chữ tín trong văn hóa làm việc Nhật.
Bài tập thực hành
Bài tập 1 — Phân tích quyết định hợp đồng. Giả sử bạn là PM nhận một dự án migrate hệ thống ERP cũ cho khách Singapore, chưa ai trong đội từng thấy hệ thống đó. Khách muốn ký Fixed Price toàn bộ ngay. Hãy viết một đoạn 150–200 từ lập luận vì sao bạn đề xuất chia phase T&M + Fixed Price, và bạn sẽ thuyết phục khách thế nào.
Bài tập 2 — Thiết kế nhịp giao tiếp. Đội bạn ở TP.HCM, khách ở London (chênh 6–7 tiếng). Hãy vẽ ra một lịch giao tiếp một tuần: core overlap hours, khi nào stand-up, kênh nào cho câu hỏi khẩn, kênh nào cho câu hỏi thường. Mục tiêu: giảm số round-trip.
Bài tập 3 — Lập Risk Register mini. Dựa trên ba tình huống trong bài (chất lượng ngầm định, độ trễ múi giờ, attrition nhân sự), hãy lập một Risk Register 5 dòng, mỗi dòng gồm: rủi ro, xác suất, mức tác động, và một biện pháp ứng phó (nối lại kiến thức Bài 24 về Risk Response Planning).
Bài tập 4 — Đóng vai. Bạn nhận bug list 147 điểm từ khách. Hãy soạn một email (bằng tiếng Việt cũng được) gửi khách vừa nhận trách nhiệm, vừa phân loại bug theo mức độ, vừa đề xuất kế hoạch xử lý — sao cho khôi phục niềm tin thay vì đổ lỗi "cái này không có trong spec".
Tóm tắt
Dự án outsourcing MBF cho Sakura Bank cho chúng ta thấy một điều cốt lõi: trong mô hình vendor Việt — khách nước ngoài, kỹ thuật hiếm khi là điểm chết. Điểm chết nằm ở khoảng cách — khoảng cách kỳ vọng chất lượng (tình huống 1), khoảng cách giao tiếp do múi giờ và bất đồng bộ (tình huống 2), và khoảng cách tri thức khi nhân sự rời đi (tình huống 3).
Người PM giỏi trong bối cảnh này quản lý ba thứ song song: quản lý scope và tiến độ (như mọi PM), quản lý mối quan hệ và kỳ vọng khách hàng, và quản lý rủi ro con người trong chính đội mình. Các đòn bẩy quan trọng nhất là: chia mô hình hợp đồng theo mức độ hiểu biết, đầu tư vào vai trò cầu nối (BrSE/Comtor), khai quật requirement ngầm định, thiết kế nhịp giao tiếp giảm round-trip, và tài liệu hóa tri thức để không phụ thuộc một người.
Đây chính là năng lực đưa các công ty phần mềm Việt Nam như FPT Software vươn ra thị trường quốc tế. Và nó cũng chính là năng lực sẽ đưa sự nghiệp PM của bạn tiến xa. Ở bài tiếp theo, chúng ta sẽ xem một case study khác — dự án migrate core banking cho ngân hàng Việt Nam — để so sánh bối cảnh trong nước với outsourcing quốc tế.