Autonomous Systems Product Manager (AS-PM) là người chịu trách nhiệm về sản phẩm cho các hệ thống ra quyết định và hành động trong thế giới vật lý mà không cần con người điều khiển từng bước: xe tự lái, drone giao hàng, robot kho (AMR/AGV), cánh tay robot, hệ thống phanh khẩn cấp tự động. Điểm khác biệt cốt lõi so với PM phần mềm thông thường là: lỗi của bạn có thể gây thương tích, thiệt hại tài sản hoặc chết người. Vì vậy, quyết định sản phẩm của bạn luôn bị ràng buộc bởi ba trục: hiệu năng, chi phí và an toàn — trong đó an toàn thường không được phép đánh đổi.
Vì sao vai trò này khó
PM phần mềm SaaS quen với vòng lặp "ship nhanh, đo lường, sửa". Với hệ thống tự hành, vòng lặp đó bị bẻ gãy vì:
- Không gian trạng thái vô hạn: một xe tự lái gặp vô số tổ hợp thời tiết, ánh sáng, người đi bộ, vật cản. Bạn không thể test hết.
- Đuôi phân phối (long tail) mới là nơi nguy hiểm: 99% tình huống dễ, nhưng 1% edge case hiếm (một người đẩy xe lăn băng qua đường trong sương mù) mới là thứ giết chết dự án.
- Chi phí thất bại bất đối xứng: một bug hiển thị sai màu nút bấm khác hoàn toàn một bug khiến robot 500kg không dừng đúng lúc.
- Niềm tin công chúng mong manh: một tai nạn được lên báo có thể xóa sổ cả năm tiến bộ về mặt truyền thông và pháp lý.
Khung tư duy: Tam giác Autonomy
Mỗi quyết định của AS-PM nên soi qua ba đỉnh:
- Capability (Năng lực) — hệ thống làm được gì trong điều kiện nào? (Operational Design Domain — ODD)
- Safety (An toàn) — xác suất và mức độ nghiêm trọng của thất bại là bao nhiêu, và ta chấp nhận ngưỡng nào?
- Trust (Niềm tin) — người dùng, cơ quan quản lý và công chúng có tin và cho phép ta vận hành không?
ODD — khái niệm nền tảng bạn phải thuộc
Operational Design Domain là tập điều kiện mà hệ thống được thiết kế để hoạt động an toàn: loại đường, tốc độ tối đa, thời tiết, thời gian trong ngày, khu vực địa lý. AS-PM giỏi là người định nghĩa ODD hẹp và rõ ràng, rồi mở rộng dần có kiểm soát. Sai lầm chết người là hứa ODD rộng ("xe chạy được mọi nơi") trong khi hệ thống chỉ an toàn trên đường cao tốc có vạch kẻ rõ.
Ví dụ ODD cho robot giao hàng vỉa hè: tốc độ ≤ 6 km/h, chỉ vỉa hè có độ dốc < 8%, ban ngày, không mưa lớn (< 5 mm/h), nhiệt độ 0–40°C, khu vực đã lập bản đồ HD. Ra khỏi ODD → hệ thống phải degrade an toàn (dừng lại, gọi người giám sát).
Checklist khởi động cho AS-PM mới vào dự án
- [ ] ODD đã được viết ra thành văn bản định lượng chưa?
- [ ] Có định nghĩa rõ "hành vi an toàn tối thiểu" (Minimal Risk Condition) khi hệ thống bó tay chưa?
- [ ] Ai là người chịu trách nhiệm cuối khi có sự cố (safety owner)?
- [ ] Có đường dây báo cáo sự cố và quy trình điều tra chưa?
- [ ] Các chỉ số an toàn (disengagement rate, số km/lỗi) có được đo và review định kỳ không?
Sai lầm thường gặp
- Áp tư duy SaaS "fail fast" nguyên xi: trong autonomy, "fail" có thể là tai nạn thật. Fail fast phải diễn ra trong mô phỏng và test khép kín, không phải trên đường thật với người thật.
- Coi an toàn là việc của team kỹ thuật: AS-PM phải sở hữu ngưỡng an toàn như một yêu cầu sản phẩm, không đẩy hết cho kỹ sư.
- Định nghĩa ODD mơ hồ: "hoạt động tốt trong điều kiện bình thường" là câu vô nghĩa. Phải có con số.
- Bỏ qua degrade an toàn: nhiều dự án chỉ thiết kế cho trường hợp mọi thứ chạy đúng, quên mất kịch bản mất cảm biến, mất mạng, hết pin.