Dự án quản vendor: khi phần lớn việc nằm ngoài

Một dự án vendor là hình hoàn toàn khác: team mà bạn quản không phải team đang làm việc. Việc của bạn nằm ở hợp đồng, scope, chấp nhận, và tích hợp. Case study này giới thiệu cấu trúc team nội bộ mỏng, nhịp tuần với vendor, và các artifact ngăn tranh chấp vendor biến thành thảm hoạ dự án.

Khi nào quản vendor là có lý?

Có ba tín hiệu chính.

Kỹ năng không có sẵn nội bộ. Một domain chuyên (tích hợp SAP, firmware embedded, tuân thủ một quy định cụ thể) - nơi xây kỹ năng đó còn đắt hơn mua.

Nhu cầu có hạn thời gian. Một dự án 6 tháng nhưng tuyển sẽ mất 4 tháng. Capacity của vendor có sẵn ngay hôm nay.

Dự đoán chi phí quan trọng. Hợp đồng vendor giá cố định cho sponsor một con số biết trước. Còn nội bộ thường kèm scope creep khó dự đoán.

Nếu việc thuộc lõi nghiệp vụ, sẽ kéo dài liên tục, và kỹ năng nội bộ vẫn khả thi, đừng outsource. Vendor chỉ phù hợp cho việc không cốt lõi và có hạn thời gian.

Cái giá khi quản vendor kém là gì?

Có ba kiểu lỗi thường gặp.

Vendor giao sai thứ. Spec mơ; vendor xây theo cách diễn giải của họ; gap lộ ra ở bước chấp nhận. Sửa cần đàm phán lại và mất thêm thời gian.

Ác mộng tích hợp. Vendor giao code, nội bộ phải tự tích hợp, và tích hợp tốn lâu hơn cả việc xây. Team nội bộ chưa chuẩn bị cho việc đó.

Khoá vendor. Vendor nắm phần lớn kiến thức; thay họ tốn đến mức bất khả thi. Dự án vô tình biến thành quan hệ vendor vĩnh viễn.

Team mỏng nội bộ trông thế nào?

flowchart TB
    InHouse[Team nội bộ] --> PM[PM<br/>scope, hợp đồng, status]
    InHouse --> SE[Engineer senior<br/>review tech, tích hợp]
    InHouse --> Buyer[Procurement<br/>hợp đồng, thanh toán]
    Vendor[Team vendor<br/>5-15 engineer] --> VL[Lead vendor<br/>sync tuần với PM]
    Vendor --> VEng[Engineer vendor]
    PM <-.sync tuần.-> VL
    SE <-.code review.-> VEng

Hai người nội bộ full-time, cộng support procurement bán thời gian. PM sở hữu quan hệ; engineer senior sở hữu bar kỹ thuật. Cùng nhau, hai vai này tốn khoảng 50% thời gian cho việc quản vendor; nửa còn lại dành cho phần tích hợp.

Cấu trúc hợp đồng trông thế nào?

Bản thân hợp đồng nằm ngoài scope của series, nhưng artifact bọc quanh hợp đồng thì không:

# Plan Dự án Vendor — {{ Tên dự án }}

## Vendor
{{ Tên vendor }}; liên hệ chính: {{ tên }}; SLA: {{ link }}

## Deliverable theo phase và thanh toán

| Phase | Deliverable | Tiêu chí chấp nhận | Thanh toán | Hạn |
|-------|-------------|--------------------|------------|-----|
| 1 | Doc kiến trúc | Engineer senior review; khớp hệ hiện có | $X | Tuần 4 |
| 2 | Tích hợp auth | Pass bộ test ta cung cấp; đạt SLA | $Y | Tuần 8 |
| 3 | Tính năng cốt alpha | Demo cho team nội bộ; test hiệu năng pass | $Z | Tuần 14 |
| 4 | Sẵn sàng production | Review bảo mật pass; runbook giao; support 30 ngày | $W | Tuần 20 |

## Quy trình chấp nhận mỗi phase
1. Vendor demo
2. Engineer nội bộ review theo tiêu chí (3 ngày)
3. Pass: thanh toán được cho phép; Fail: feedback viết, thử lại
4. Sau 2 lần fail cùng phase, kích escalation theo hợp đồng

## Out of scope (vendor không làm)
- Deploy production (nội bộ sở hữu)
- Oncall 24/7 (nội bộ sở hữu)
- Customer support (nội bộ sở hữu)
- Training cho team nội bộ (add-on riêng)

Có ba chi tiết quan trọng. Một, chấp nhận theo tiêu chí, không theo ý kiến. Hai, thanh toán gắn vào phase được chấp nhận. Ba, phần out-of-scope phải rõ để vendor không thể quay sang nói "chúng tôi tưởng anh sẽ làm cái đó".

Nhịp tuần với vendor trông thế nào?

sequenceDiagram
    participant PM as PM nội bộ
    participant VL as Lead vendor
    participant SE as SE nội bộ
    participant Sponsor as Sponsor
    PM->>VL: Thứ Hai: template status hạn thứ Tư
    VL->>PM: Thứ Tư: status viết (RAG, rủi ro, blocker)
    PM->>SE: Thứ Tư: điểm tech cần review
    SE->>VL: Thứ Năm: feedback code review
    PM->>VL: Thứ Năm: sync 30 phút (chỉ hỏi câu hỏi)
    PM->>Sponsor: Thứ Sáu: status rollup cho sponsor nội bộ

Status viết tuần từ phía vendor là thứ không thương lượng. Không có nó, PM bay mù. Buổi sync thứ Năm cần ngắn và có cấu trúc: chỉ hỏi câu hỏi trên status đã viết, đừng để nó thành cuộc đọc lại status.

Rủi ro tích hợp và cách xử ra sao?

Tích hợp là chỗ phần lớn dự án vendor fail ở bước chấp nhận. Một số phương án giảm thiểu chạy được:

• SE nội bộ pair với vendor từ sớm. Đừng đợi tới Phase 3 mới nhìn code; code review hàng tuần bắt đầu ngay từ Phase 1.
• Contract API do nội bộ viết. Interface giữa việc vendor và hệ của bạn là trách nhiệm của bạn; đừng để vendor tự định nghĩa.
• Test tích hợp chạy trong CI của bạn. Vendor giao fixture test; CI nội bộ chạy tích hợp hằng ngày.
• Spike vào tuần 4. Kéo một phần nhỏ vendor đã giao vào env của bạn; xác nhận quá trình tích hợp là khả thi thật.

Scale lên đa vendor hoặc chương trình lớn ra sao?

flowchart TB
    Sponsor[Sponsor] --> PMO[PM chương trình<br/>giám sát vendor]
    PMO --> V1[Vendor A<br/>xây front-end]
    PMO --> V2[Vendor B<br/>xây back-end]
    PMO --> V3[Vendor C<br/>QA / pen test]
    PMO --> Internal[Team nội bộ<br/>tích hợp + chấp nhận]

Một PM chương trình điều phối nhiều vendor. Mỗi vendor có hợp đồng riêng và nhịp tuần riêng; PM chương trình rollup status lại thành một bản chung. Team nội bộ lo phần tích hợp giữa các vendor, vì không vendor nào nhìn thấy cả bức tranh.

Quản vendor có thể tự tạo ra những lỗi nào?

• Kịch hoá chấp nhận. Ký off vì áp lực deadline, không phải vì tiêu chí đã đạt. Cách phòng: tiêu chí viết phải được engineer senior review; release thanh toán cần chữ ký của họ.
• Scope creep từ phía vendor. Vendor thêm các tính năng "hữu ích" rồi tính tiền; nội bộ không hỏi rõ. Cách phòng: hợp đồng cap việc theo scope viết; việc out-of-scope phải là change request riêng.
• Kiến thức ở lại vendor. Migration khỏi vendor bất khả thi vì tài liệu không tồn tại. Cách phòng: yêu cầu ADR (chương 19) và runbook được giao như một phần của tiêu chí chấp nhận.
• Quan hệ vendor xấu đi. PM và lead vendor va chạm. Cách phòng: định trước đường escalation trong hợp đồng; nếu sync tuần không chạy, escalate lên lãnh đạo cả hai bên; đừng để xấu đi mãi.

Khi nào quản vendor là hình sai?

Có hai trường hợp.

Capability cốt lõi và liên tục. Nếu việc đó là lợi thế cạnh tranh của bạn và sẽ kéo dài mãi, hãy tuyển nội bộ thay. Quan hệ vendor có overhead mà về dài hạn việc tuyển sẽ bù đắp được.

Việc rất sáng tạo hoặc mang tính khám phá. Khó viết tiêu chí chấp nhận cho câu "tìm hướng sản phẩm đúng". Vendor chỉ giao được theo spec; nếu không có spec rõ, vấn đề nằm ở phía nội bộ.

Đi tiếp từ đây như thế nào?

Bạn đã hoàn tất phần case study. Chương tiếp theo: checklist chạy dự án - hub link mọi artifact bạn đã học. Sau đó, kết luận sẽ khép series với những bài học sống sót qua mọi hình dạng dự án.