Trong bài báo, Điều khó nhất về Kỹ thuật là Yêu cầu, tác giả Jay giải thích tại sao việc nắm bắt các yêu cầu lại khó. Trước hết là thách thức giao tiếp giữa đội kỹ thuật và kinh doanh. Các nhà thiết kế và kỹ sư muốn có các yêu cầu rõ ràng để họ có thể xắn tay áo thực hiện các quy trình mong muốn và xây dựng một giải pháp được tối ưu hóa để hoạt động tốt nhất cho các trường hợp sử dụng đã nêu. Tuy nhiên, người dùng doanh nghiệp không thể hoặc không có thời gian để viết ra các trường hợp sử dụng. Họ không thể làm như vậy vì các trường hợp sử dụng mới hoặc các lỗ hổng trong yêu cầu chỉ được phát hiện khi họ thấy một giải pháp hiệu quả. 

Michael Lewis đã nắm bắt điều này một cách tuyệt vời trong Tập Six Levels Down (Podcast chống lại Quy tắc). Anh ấy chia sẻ cách tiếp cận với chuyên gia am hiểu các quy tắc kinh doanh là chìa khóa giúp Athena Health trở thành công ty phần mềm Tỷ đô la. Các chuyên gia thường là người dùng thực tế (giảm 6 cấp trong hệ thống phân cấp) chứ không phải những người trong phòng họp. Nếu bạn chỉ có 5 phút, tôi khuyên bạn nên nghe từ 30 đến 35 phút của tập.

Dưới đây là những điều chính yếu:

1) Có các yêu cầu dưới dạng văn bản

• Nói chuyện với người dùng thực tế. Ghi lại các yêu cầu của họ. Họ muốn gì từ phần mềm? Họ muốn thực hiện những hành động nào? Họ cần thông tin gì?
• Theo kinh nghiệm của bản thân, chúng tôi nhận thấy rằng các buổi động não tốt có thể đưa ra nhiều tình huống có thể đạt được trong các yêu cầu.
• Yêu cầu các bên liên quan chính ký tên vào các yêu cầu. Mặc dù điều này có thể gây ra sự chậm trễ, nhưng điều này cũng sẽ buộc người dùng phải suy nghĩ kỹ.

2) Phân tích yêu cầu, xác định khoảng trống và cập nhật

• Các chuyên gia triển khai và nhà phát triển nên biết rằng các yêu cầu sẽ có những khoảng trống, và phải giỏi trong việc xác định những lỗ hổng đó và làm rõ những khoảng trống đó trước khi giải pháp được thực hiện.

3) Thiết kế trong một số tính linh hoạt

• Nhà thiết kế và Nhà phát triển phải cho phép các mẫu, quy tắc, cảnh báo, báo cáo và luồng có thể định cấu hình.

4) Nhận phản hồi sớm bằng cách hiển thị các nguyên mẫu

• Phản hồi sớm sẽ tiết kiệm thời gian vì việc truy đòi sẽ đòi hỏi ít nỗ lực hơn so với việc nhận phản hồi sau khi nó được thực hiện đầy đủ.

Hội thảo trên web & Video

Học viện Vtiger & Cơ sở Kiến thức

Báo cáo CRM

(Tin tức CRM và Xu hướng công nghệ)

Tính năng yêu thích của tôi

Nhận nội dung CRM độc quyền!