Quản lý một dự án SI quy mô lớn tại Nhật — 7 bài học mình rút ra

Sau một thời gian dài cắm đầu vào một dự án SI siêu lớn cho khách hàng Nhật — kiểu dự án kéo dài nhiều phase, nhiều bên tham gia, scope phình ra liên tục — mình muốn ngồi lại note lại vài bài học. Không phải lý thuyết trong PMP, mà là những thứ mình thực sự "ăn đòn" rồi mới thấm.

Bài viết này mình cố tình viết ở mức tổng quát, bỏ qua mọi chi tiết cụ thể về khách hàng và con số. Cái mình muốn chia sẻ là pattern — vì mình tin những pattern này lặp lại ở hầu hết các dự án SI lớn theo mô hình offshore Việt–Nhật.

1. Replanning không phải là thất bại

Bài học đầu tiên, và cũng là cái mình mất nhiều thời gian nhất để chấp nhận: phải re-plan giữa chừng không có nghĩa là kế hoạch ban đầu sai.

Với một dự án lớn, việc giữ nguyên một baseline từ đầu đến cuối gần như là ảo tưởng. Requirement thay đổi, upstream chậm, scope được "phát hiện" thêm sau khi đào sâu thiết kế... Đó là bản chất của complex domain, không phải lỗi của ai. Vấn đề không nằm ở chỗ có phải re-plan hay không, mà ở chỗ re-plan sớm và minh bạch, hay giấu đến khi vỡ.

Mình học được rằng phải coi re-baseline là một hoạt động bình thường, có quy trình, có communication kèm theo — chứ không phải một sự kiện xấu hổ cần che giấu.

2. Estimate đẹp không bằng estimate trung thực

Cái bẫy lớn nhất khi estimate một dự án lớn là false precision — con số nhìn rất chi tiết, bottom-up từng task, cộng lại ra một số trông cực kỳ thuyết phục. Nhưng độ chi tiết không đồng nghĩa với độ chính xác.

Mình từng chứng kiến những estimate "đẹp" sụp đổ chỉ vì một vài giả định ngầm không được nói ra: giả định upstream giao đúng hạn, giả định môi trường sẵn sàng, giả định không có rework. Khi một trong các giả định đó vỡ, cả con số đẹp đẽ đi theo.

Bài học: estimate phải đi kèm assumption rõ ràng và risk buffer được giải thích tử tế. Và đừng ngạc nhiên nếu buffer bị khách hàng phản ứng — chuyện đó bình thường. Cái quan trọng là mình có dữ liệu để bảo vệ con số đó, thay vì cắt buffer cho dễ ký rồi sau này khổ.

3. Bạn không kiểm soát được bên thứ ba — hãy thiết kế cho điều đó

Trong dự án SI lớn, hiếm khi mình là bên duy nhất. Luôn có vendor khác, SIer khác, hoặc team phía khách hàng phụ trách một phần upstream. Và đây là sự thật phũ phàng: tiến độ của họ là rủi ro của mình, nhưng mình không kiểm soát được nó.

Một upstream chậm vài tuần có thể nén toàn bộ phần việc của mình vào một cửa sổ thời gian hẹp hơn nhiều, kéo theo overtime, chất lượng giảm, và tinh thần team đi xuống.

Cách mình xử lý sau này: làm rõ interface agreement (ai giao gì, khi nào, định dạng ra sao) thành văn bản; build slack vào lịch ở những điểm phụ thuộc; và quan trọng nhất — escalate dependency risk sớm, bằng dữ liệu, để khách hàng thấy đó là rủi ro chung chứ không phải vấn đề riêng của vendor.

4. Với khách Nhật, tin xấu phải đến sớm

報・連・相 không phải khẩu hiệu. Trong môi trường Nhật, cách mình báo cáo một vấn đề nhiều khi quan trọng ngang với việc giải quyết nó.

Bài học đắt giá nhất ở mảng này: tin xấu mất giá rất nhanh theo thời gian. Một rủi ro được báo sớm, kèm phương án, là dấu hiệu của một PM đáng tin. Cũng rủi ro đó nhưng để khách hàng tự phát hiện ra sau, thì dù mình có giải pháp tốt đến đâu, niềm tin cũng đã sứt mẻ.

Steering committee, weekly report, escalation — tất cả những "thủ tục" tưởng phiền phức đó thực ra là hạ tầng để chuyển tin xấu một cách có kiểm soát. Mình học cách dùng chúng chủ động thay vì coi là gánh nặng.

5. Chất lượng là vấn đề hệ thống, không phải vấn đề cá nhân

Khi số lượng bug bắt đầu phình lên ở một dự án lớn, phản xạ đầu tiên thường là "ai làm ẩu". Nhưng càng làm mình càng tin: bug nhiều ở quy mô lớn gần như luôn là triệu chứng của hệ thống, không phải lỗi của một vài cá nhân.

Requirement mơ hồ, thiết kế thay đổi không đồng bộ, môi trường test không ổn định, fix version quản lý lỏng lẻo — đó mới là gốc rễ. Đếm bug và ép từng người không giải quyết được gì; phân tích root cause theo nhóm và sửa vào quy trình mới có hiệu quả.

Bài học: dành thời gian cho kỷ luật fix-version và phân tích nguyên nhân theo cụm, thay vì biến quản lý chất lượng thành trò đổ lỗi.

6. PM phải đọc hợp đồng như một điều khoản kỹ thuật

Đây là thứ mình ước có người nói với mình sớm hơn. Là PM, rất dễ nghĩ "hợp đồng là việc của legal/sales". Sai lầm.

Trong một dự án fixed-price, những điều khoản tưởng chừng khô khan — phạm vi bảo hành, thời điểm nghiệm thu, cơ chế thanh toán tạm ứng, điều kiện thay đổi scope — lại chính là thứ quyết định dự án của mình có lãi hay lỗ. Một câu chữ mơ hồ về warranty window hay về việc additional工 được tính thế nào có thể nuốt trọn margin.

Bài học: đọc hợp đồng với con mắt của người sẽ phải delivery, và chủ động đặt câu hỏi về những điểm mơ hồ trước khi ký, chứ không phải sau khi tranh chấp.

7. AI và automation: đòn bẩy, không phải phép màu

Gần đây mình dành nhiều thời gian đưa AI vào toàn bộ vòng đời dự án — không chỉ ở coding mà cả ở planning, governance, quản lý tri thức, soạn báo cáo. Hiệu quả thật, và mình tin đây là hướng đi đúng.

Nhưng bài học đi kèm là: AI khuếch đại năng lực của một quy trình tốt, và cũng khuếch đại sự hỗn loạn của một quy trình tồi. Nếu requirement đã mơ hồ, governance đã lỏng, thì tự động hoá chỉ giúp mình tạo ra rác nhanh hơn.

Vì vậy mình coi AI là đòn bẩy đặt lên một nền tảng kỷ luật, chứ không phải thứ thay thế cho kỷ luật.

Tổng kết

Nếu phải gói lại trong một câu, thì 7 bài học trên đều xoay quanh cùng một thứ: trong dự án lớn, sự minh bạch và kỷ luật quan trọng hơn sự hoàn hảo của kế hoạch ban đầu.

Kế hoạch sẽ thay đổi, estimate sẽ lệch, bên thứ ba sẽ chậm, bug sẽ xuất hiện. Cái phân biệt một dự án về đích với một dự án thảm hoạ không phải là tránh được những điều đó, mà là xử lý chúng sớm, trung thực, và có hệ thống.

Hi vọng vài note này hữu ích cho những anh em đang hoặc sắp gánh một dự án SI lớn tại Nhật. Nếu bạn có bài học nào khác, mình rất muốn nghe.

Ghi chú: Bài viết được tạo với sự hỗ trợ của AI; nội dung và quan điểm vẫn là của cá nhân Cường Nguyễn.