Dừng đúng lúc trong một dự án container marketplace

Problem

Khoảng giữa quý 2 và quý 3 cách đây vài năm, tôi tham gia một dự án SaaS làm sàn kết nối giữa chủ xe và đơn vị sở hữu xe container. Bài toán kinh doanh ban đầu khá sáng: nhà đầu tư đã có sẵn khoảng 200 xe, tức là không phải mở quán rồi mới đi tìm bàn ghế.

Điểm gãy nằm ở một quyết định tưởng như “thêm vào cho đủ hệ”: phía outsource muốn hệ thống nhận tín hiệu từ tất cả hộp đen của xe. Nói thì oách, nhưng thị trường thiết bị này rất lộn xộn, nhất là các dòng giá rẻ và nhiều biến thể từ Trung Quốc. Mỗi bên nói một giao thức, mỗi hộp nói một giọng. Lúc đó bài toán không còn là “làm một SaaS marketplace” nữa, mà đang trượt thành “xây một integration platform cho cả thị trường thiết bị”.

Hình 1. Khi một tính năng “thêm vào cho đủ hệ” biến thành cuộc chiến giải mã hàng trăm giao thức phần cứng không ổn định.

Constraints

• Dự án đã cháy từ trước đó khoảng chín tháng
• Nhân sự còn non, chưa đủ lực để đỡ một scope tích hợp nhiều biến thể
• Kỳ vọng lãnh đạo vẫn nghiêng về việc “cố kéo lại tiến độ”
• Unknown unknowns nằm ở lớp giao tiếp thiết bị, không phải ở màn hình hay CRUD

Approach

Vai trò của tôi khi nhìn vào dự án không phải để tô hồng rằng “cố thêm sprint nữa là cứu được”. Việc cần làm là bóc tách lại bản chất scope:

1. Tách bài toán kinh doanh khỏi bài toán tích hợp thiết bị. Marketplace và telematics ingestion là hai sản phẩm khác nhau về độ khó.
2. Đánh giá lại blast radius kỹ thuật. Chỉ cần thêm vài loại hộp đen “lệch chuẩn” là toàn bộ timeline có thể trượt dài, vì không có hợp đồng giao tiếp ổn định.
3. Nhìn năng lực đội ngũ một cách tỉnh táo. Team non không phải tội; tội là giao cho team non một bài toán integration ngổn ngang rồi giả vờ như đó chỉ là feature tiếp theo trên backlog.
4. Đưa cuộc nói chuyện về lại decision quality. Khi burn kéo dài quá lâu, mục tiêu không còn là cứu sĩ diện của plan cũ, mà là dừng chỗ nào để thiệt hại ít nhất và học được nhiều nhất.

Hình 2. Đánh giá chất lượng quyết định: Dừng dự án kịp thời để bảo toàn ngân sách và giải phóng năng lực đội ngũ.

Outcome

Dự án cuối cùng phải dừng. Nghe buồn, nhưng nhìn theo góc quản lý dự án thì đó không hẳn là kết cục tệ nhất. Kết cục tệ hơn là tiếp tục bơm người, bơm sprint, bơm hy vọng vào một scope chưa được đóng đúng cách.

Điều tích cực còn lại là bài học rất rõ: không phải cứ có sẵn xe, có nhu cầu thị trường, và có đội outsource là bài toán sẽ tự khớp. Nếu lớp tích hợp lõi chưa được giới hạn, chưa có danh sách thiết bị ưu tiên, chưa có giao thức kiểm chứng sớm, thì kế hoạch sẽ trượt ngày càng dài như dây thun cũ.

Hình 3. Đường scope drift thực tế lệch dần so với kế hoạch bàn giao.

Takeaway

Không phải dự án nào dừng lại cũng là thất bại quản lý. Nhiều khi, dừng đúng lúc là hành vi quản lý chuyên nghiệp hơn là cố sống cố chết bảo vệ một timeline đã gãy.

Với các dự án có phần cứng hoặc thiết bị bên thứ ba, bài học tôi giữ tới giờ rất đơn giản: chốt phạm vi tích hợp thật hẹp trước, validate trên một nhóm thiết bị đại diện trước, rồi mới nói chuyện scale. Đừng biến một bài toán marketplace thành một cuộc chiến bất tận với “mọi loại hộp đen trên thị trường”.