Tình huống
Team mình làm hệ thống quản lý cho doanh nghiệp. Một ngày đẹp trời, có ý tưởng “xịn sò”: Import user từ file CSV.
Và không chỉ là import bình thường:
- Cho phép upload hàng triệu dòng.
- Import đang chạy mà lỗi thì phải biết rollback từng phần.
- UI phải hiện tiến trình mượt như streaming Netflix.
Cả team mất 2 tháng trời để thiết kế & xây dựng. Khi release, kết quả: tỉ lệ sử dụng thực tế chưa tới 0.01%.
Bối cảnh
Ý tưởng nghe thì hay, nhưng thực tế:
- Doanh nghiệp dùng hệ thống này không bao giờ có tới hàng triệu user.
- Import vài trăm user đã là kịch bản hiếm gặp.
- Và với nhiều công ty, họ còn thích nhập tay hoặc sync từ hệ thống HR sẵn có.
Nói cách khác: team đã giải quyết một vấn đề… chưa từng tồn tại.
Vấn đề
Sai lầm ở đây: Không khảo sát nhu cầu thực tế trước khi làm. Team làm feature “hoàn hảo” theo trí tưởng tượng của dev, chứ không dựa trên nhu cầu thật sự của user.
Giải pháp
Từ vụ việc này, cả team rút ra kinh nghiệm:
- Làm MVP trước: bản đơn giản, đáp ứng nhu cầu cơ bản nhất.
- Phân tích yêu cầu thật sự của user trước khi design phức tạp.
- Ưu tiên tính năng: cái nào thực sự cần thì làm trước, còn chuyện “làm đẹp”, “xử lý case siêu to khổng lồ” → để sau.
Bài học
Không phải cái gì “hay” với dev thì cũng “cần” với user. Feature càng phức tạp, càng tốn thời gian → càng phải chắc rằng user thực sự sẽ dùng.
Bài học rút ra: Đừng để sự hào hứng kỹ thuật dẫn dắt kiến trúc, hãy để nhu cầu thực tế của người dùng định hình sản phẩm.