Từ bản yêu cầu đến một lộ trình khả thi
Cách thực tế để chuyển một ý tưởng còn rộng thành phạm vi sản phẩm rõ ràng, với người dùng cụ thể, tiêu chí hoàn thành, danh sách rủi ro và thứ tự ưu tiên.
Một bản yêu cầu tốt không cần dài. Nó chỉ cần làm được ba việc: giúp cả đội nhìn thấy cùng một vấn đề, chỉ rõ ai đang chịu tác động của vấn đề đó, và xác định bằng chứng nào cho thấy sản phẩm đã thật sự thay đổi được tình hình.
Khó khăn nằm ở chỗ bản yêu cầu ban đầu thường trộn lẫn ba thứ: mong muốn kinh doanh, ý tưởng giải pháp và một danh sách tính năng. Nếu đưa nguyên danh sách đó vào phát triển, đội ngũ rất dễ rơi vào tình huống làm đúng từng đầu việc nhưng vẫn xây sai sản phẩm.
1. Bắt đầu từ công việc đang diễn ra
Thay vì hỏi “anh/chị muốn phần mềm có những gì?”, hãy chọn một ca thật gần nhất và đi theo nó. Ai khởi tạo công việc? Thông tin đến từ đâu? Bước nào phải chờ? Khi có lỗi thì mọi người liên hệ với ai? Một quy trình đang vận hành, dù rời rạc đến mấy, vẫn chứa nhiều sự thật hơn một danh sách mong muốn.
Chẳng hạn, “cần dashboard theo dõi đơn hàng” chưa cho biết dashboard đó giúp ai quyết định điều gì. Nhưng khi đi theo một đơn bị trễ, bức tranh hiện ra ngay: người điều phối cần thấy đơn nào quá hạn, nguyên nhân trễ và ai đang giữ việc, chứ không phải thêm một biểu đồ doanh thu nữa.
- Ghi lại từng bước: ai làm, đầu vào là gì, quyết định gì và kết quả ra sao.
- Khoanh vùng những chỗ dữ liệu phải nhập lại, phải chờ xác nhận hoặc chỉ truyền qua tin nhắn.
- Chọn 3–5 ca thật: một ca bình thường, một ca lỗi và một ca phải xử lý ngoại lệ.
2. Sáu câu hỏi cần có lời giải
Trước khi ước lượng thời gian, Easy Alo dùng sáu câu hỏi này để đo mức độ rõ ràng của đề bài. Câu trả lời không cần hoàn hảo, nhưng câu nào còn bỏ trống thì lộ trình phải dành chỗ để tìm hiểu hoặc kiểm chứng.
Cũng đừng cố gói mọi câu trả lời vào một con số duy nhất. “Giảm thời gian xử lý” có thể bắt đầu bằng việc xác định rõ đo từ đâu đến đâu: từ lúc đơn được tạo đến lúc có người nhận xử lý, không tính khoảng chờ khách hàng bổ sung giấy tờ.
- Ai trực tiếp sử dụng và ai chịu ảnh hưởng từ kết quả?
- Công việc nào đang khó, chậm, dễ sai hoặc không ai quan sát được?
- Vì sao phải thay đổi ngay lúc này: chi phí, quy mô, quy định hay trải nghiệm?
- Kết quả nào là quan trọng và sẽ được đo ở đúng điểm nào trong quy trình?
- Giới hạn thật sự là gì: dữ liệu, tích hợp, thời hạn, bảo mật hay nguồn lực?
- Phần nhỏ nhất có thể đưa cho người dùng thử để giảm được rủi ro lớn nhất là gì?
Nếu người ra quyết định, người vận hành và người dùng cuối trả lời khác nhau, đó không phải lỗi của buổi khảo sát mà là dấu hiệu cho thấy dự án cần thống nhất mục tiêu trước khi chốt phạm vi.
3. Chia phạm vi theo lát giá trị thay vì theo tầng kỹ thuật
Lộ trình kiểu “tháng đầu làm giao diện, tháng sau làm backend” chỉ mô tả cách đội kỹ thuật chia việc, chưa mang lại cho người dùng thứ gì để kiểm chứng. Cách tốt hơn là chọn một lát đi trọn từ đầu đến cuối: tạo yêu cầu, duyệt, thông báo, xem lại lịch sử, và hoàn thiện cho một loại yêu cầu trước.
Mỗi lát nên khép lại bằng một hành vi nhìn thấy được. Khi lát đầu tiên chạy với dữ liệu thật ở phạm vi nhỏ, cả đội học được về phân quyền, ngoại lệ và tích hợp sớm hơn nhiều so với việc ngồi hoàn thiện toàn bộ giao diện.
- Lát 1: một vai trò chính, một luồng quan trọng, dữ liệu thật có kiểm soát.
- Lát 2: những ngoại lệ thường gặp và quyền của các vai trò liên quan.
- Lát 3: báo cáo, tự động hoá hay tích hợp, chỉ triển khai khi dữ liệu nguồn đã đáng tin cậy.
4. Viết tiêu chí hoàn thành bằng ngôn ngữ của người làm nghiệp vụ
“Có chức năng duyệt” mới chỉ là tên một tính năng. Còn “quản lý chỉ duyệt được yêu cầu thuộc đơn vị mình; người gửi nhận được kết quả; mọi thay đổi đều lưu thời gian và tên người thực hiện” mới là tiêu chí kiểm tra được.
Một tiêu chí đủ tốt sẽ nói rõ đường đi chính, quyền truy cập, dữ liệu bắt buộc, phản hồi khi có lỗi và dấu vết cần lưu. Đây cũng là nơi thiết kế, phát triển và người phụ trách nghiệp vụ cùng nói chung một ngôn ngữ.
Một tiêu chí không kiểm tra được thường cho thấy trong phạm vi vẫn còn những từ mơ hồ như “nhanh”, “thân thiện”, “linh hoạt”, “tự động”, mà chưa ai làm rõ là nhanh trong tình huống nào.
5. Sắp xếp lộ trình theo rủi ro cần giảm trước
Không phải hạng mục lớn nhất thì nên làm trước. Nếu dự án phụ thuộc vào dữ liệu của hệ thống cũ, hãy soi chất lượng dữ liệu và cách tích hợp ngay trong lát đầu tiên. Nếu người dùng gần như không có thời gian học, hãy mang prototype đi thử với họ trước khi hoàn thiện giao diện.
Một lộ trình đáng tin cậy sẽ nói rõ: kết thúc mỗi chặng cả đội học được điều gì, ai là người xác nhận và quyết định nào được mở ra. Khi có thay đổi, hai bên trao đổi về ảnh hưởng tới mục tiêu và rủi ro, thay vì tranh luận xem tính năng nào “đã hứa rồi”.
- Discovery khép lại bằng bản đồ quy trình, các giả định và câu hỏi còn bỏ ngỏ.
- Prototype khép lại bằng kết quả thử nghiệm với đúng nhóm người dùng đó.
- Pilot khép lại bằng dữ liệu vận hành và danh sách ngoại lệ trong thực tế.
- Rollout khép lại bằng người sở hữu, hướng dẫn và cách theo dõi sau bàn giao.
Checklist trước khi chốt lộ trình
- Một câu mô tả vấn đề, không nhắc đến bất kỳ tên tính năng nào.
- Nhóm người dùng chính và những quyết định họ phải đưa ra.
- Luồng hiện tại, bao gồm cả ca bình thường lẫn ca ngoại lệ.
- Kết quả có điểm bắt đầu, điểm kết thúc và nguồn dữ liệu để đo.
- Giới hạn và các tích hợp đã được xác nhận.
- Lát đầu tiên đủ nhỏ để thử nghiệm nhưng đủ trọn vẹn để tạo ra giá trị.
- Mỗi chặng có người duyệt và tiêu chí hoàn thành nhìn thấy được.
