Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 6 — Chống phân mảnh và quản trị nền tảng trong thực tế

Phân mảnh: kẻ thù số một của nền tảng

Phân mảnh (fragmentation) là khi nhiều đội cùng dựng những model, pipeline, hoặc công cụ trùng lặp và không tương thích. Hậu quả: chi phí gấp nhiều lần, rủi ro an toàn không kiểm soát, không thể nâng cấp đồng loạt, và mỗi sự cố lại là một cuộc điều tra riêng. Với AI nội bộ, phân mảnh còn nguy hiểm hơn vì mỗi model 'ngoài luồng' là một điểm rủi ro tuân thủ và dữ liệu.

Vì sao phân mảnh xảy ra (hiểu nguyên nhân để trị)

Phân mảnh hiếm khi do đội khác 'cứng đầu'. Thường vì: nền tảng chậm, khó tích hợp, không đáp ứng ca dùng đặc thù, hoặc thiếu tin tưởng vào độ ổn định. Phân mảnh là triệu chứng, không phải nguyên nhân. Nếu bạn chỉ ra lệnh cấm mà không sửa gốc, đội khác sẽ lách hoặc nghỉ dùng.

Khung tư duy: Golden Path + hàng rào mềm

  • Golden Path (đường vàng): con đường được nền tảng hỗ trợ tốt nhất, có tài liệu, có SLA, dễ đến mức đội khác muốn đi theo. Chống phân mảnh bằng sức hút, không chỉ bằng luật.
  • Hàng rào mềm (paved road, not walls): cho phép đi ngoài đường vàng khi thật sự cần, nhưng đội đó phải tự gánh vận hành và đăng ký vào registry. Tự do có trách nhiệm, không phải hỗn loạn.
  • Đăng ký bắt buộc: mọi model production phải vào registry — đây là ranh giới không nhân nhượng, vì nó cho bạn khả năng nhìn thấy và quản trị.

Cơ chế quản trị thực dụng

  • Hội đồng nền tảng (platform council): đại diện các đội cùng quyết ưu tiên và chuẩn chung — để quyết định không mang tính áp đặt.
  • Chuẩn tối thiểu chung: mọi model dùng chung phải đạt ngưỡng eval, có logging, có chủ sở hữu. Không đạt → không lên production.
  • Cổng an toàn ở gateway: chính sách an toàn, giới hạn tải, kiểm tra dữ liệu nhạy cảm thực thi tập trung, không phụ thuộc từng đội tự giác.
  • Chương trình migrate chủ động: định kỳ rà registry tìm model trùng lặp, đề xuất hợp nhất kèm lợi ích rõ ràng (chi phí, bảo trì).

Ví dụ cụ thể

Bạn phát hiện 3 đội có 3 model phân loại ý định (intent) gần giống nhau. Cách sai: gửi email cấm và bắt gộp. Cách đúng: xây một intent-classifier dùng chung tốt hơn cả ba, cho time-to-integrate 1 ngày, chứng minh tiết kiệm chi phí bảo trì, mời 3 đội vào council định hình nó. Khi đường vàng thực sự tốt hơn, hợp nhất diễn ra tự nguyện.

Sai lầm thường gặp

  • Chống phân mảnh bằng mệnh lệnh thay vì bằng nền tảng đủ tốt để hút người dùng.
  • Dựng tường cứng cấm mọi lối đi riêng → đội bị dồn sẽ đi 'chui', phân mảnh ngầm còn tệ hơn.
  • Quản trị mà không có dữ liệu (không registry, không observability) → không biết phân mảnh ở đâu để trị.
  • Bỏ qua nguyên nhân gốc (nền tảng chậm/khó) và trách đội khác 'không hợp tác'.

Checklist chống phân mảnh

  • [ ] Có một Golden Path rõ ràng, có tài liệu và SLA cho mỗi năng lực chính.
  • [ ] Mọi model production đều nằm trong registry (không ngoại lệ).
  • [ ] Cho phép lối đi riêng nhưng gắn trách nhiệm vận hành và đăng ký.
  • [ ] Có cơ chế council để các đội cùng định chuẩn, giảm cảm giác bị áp đặt.
  • [ ] Định kỳ rà tìm trùng lặp và đề xuất hợp nhất kèm lợi ích cụ thể.
Kết khóa: một Platform PM giỏi không phải người ra nhiều luật nhất, mà là người xây nền tảng tốt đến mức đội khác chọn dùng nó — và nhờ đó tổ chức có AI nội bộ nhất quán, an toàn, tiết kiệm và tiến nhanh cùng nhau.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi