Tại sao chúng ta không có Requirement tốt?

Những câu trả lời bên dưới được tích góp từ nhiều năm làm việc BA :-) Các bạn bổ sung thêm (nếu có):

  • Thiếu thời gian
  • Không có khả năng giao tiếp tốt
  • Có định kiến
  • Yêu cầu quá chung chung
  • User thay đổi yêu cầu sau khi đã được duyệt
  • Quá tập trung cho câu hỏi "Làm như thế nào?" mà không tập trung cho câu hỏi "Làm cái gì?"
  • Khác biệt về văn hóa
  • Lấy yêu cầu chỉ từ 1 người
  • IT nghĩ là mình hiểu về Business
  • User quá bận rộn
  • Người dùng không biết mình thực sự muốn gì
  • Không đầy đủ câu hỏi
  • User không tin vào BA
  • User không đọc kỹ tài liệu mà chỉ biết ký duyệt
  • Thiếu sự cam kết/hỗ trợ của nhà tài trợ (ban giám đốc)
  • Yêu cầu chưa đầy đủ
  • Yêu cầu không liên kết với mục tiêu

Bình luận

Chào bạn,

Cảm ơn bạn đã chia sẻ, có thể thấy những gì bạn liệt kê ra ở trên là cả một quá trình "nếm mật nằm gai" để đúc kết các hình thái của việc chất lượng requirement không tốt. Nhưng đằng sau đó là những lỗ hỏng không phải là nhỏ từ tư thế, sự chuẩn bị chưa tốt, hướng tiếp cận có thể chưa phù hợp.

Mình xin đóng góp  thêm vài ý:

1/ Tâm thế chưa chủ động: Khác hàng luôn nghĩ họ biết hết những gì họ cần nhưng sự thật không phải vậy. BA luôn nghĩ mình biết hết các nghiệp vụ sau khi phỏng vấn vài đối tượng nhưng hoá ra phỏng vấn chưa đúng đối tượng cần phỏng vấn, hoặc chỉ nghe khách hàng kể bề nỗi của tảng băng. Việc tìm ra ai là đối tượng cần phỏng vấn là thực sự quan trọng và quan trọng hơn là cần xác định đâu là mặt chìm của tảng băng.

2/ Chưa lắng nghe và thấu hiểu: Thông thường các BA nhiều năm kinh nghiệp luôn đặt mục tiêu để khơi gởi bằng câu hỏi đúng để lắng nghe các kỳ vọng, vấn đề của khác hàng là gì (What?) thay vì cứ tập trung vào (How?). Liệu câu hỏi HOW có giúp ích được gì bạn khách hàng khi câu hỏi WHAT chưa được xác định câu trả lời?

3/ Quản lý cam kết với stakeholders luôn là một thách thức: Mỗi dự án có một bối cảnh khác nhau, đối tượng khác nhau (nếu các đối tượng giống dự án trước đó thì vai trò và trách nhiệm cũng khác nhau, phạm vi cũng sẽ khác với dự án trước). Do đó chúng ta cần có cách tiếp cận phù hợp để quản lý sự cam kết của họ.

4/ User không phải là chủ thể tạo ra phần lớn change: Nếu chúng ta để ý thì bao năm họ vẫn làm theo process đó, công việc họ vẫn chạy, giờ áp hệ thống vào thì họ yêu cầu change. Thật chất là user đang thất vọng vì những gì trên phần mềm không như họ kỳ vọng và họ đang cố chấp nhận đồng ý change (theo đề nghị của nhà cung cấp) để họ có thể được bình an. Sự thật phần lớn change đến từ sự thiếu trách nhiệm của người lấy yêu cầu.

5/ Sự chuẩn bị chưa tốt: Cả một câu chuyện dài, có rất nhiều bạn cứ than khách hàng cứ làm khó. Thật ra họ dang cần BA giúp nhưng BA không tạo cho họ 1 niềm tin vì sự chuẩn bị yếu kém đang trung bày trước mặt họ. Nếu đặt bạn là khách hàng thì bạn có tin các mà các BA non kinh nghiệm đang thể hiện?

Với BA chuyên nghiệp thì cũng giống như các vũ công "Nhạc nỗi lên là nhảy, điệu nào cũng nhảy được :)". Nhưng sự thành công đến từ khâu chuẩn bị. Các bạn có thể tham khảo cách chuẩn bị một buổn phỏng vân của BA chuyên nghiệp.

Hoặc bạn có thể thao khảo 1 quá trình gian nan của một IT Business Analyst

Mình hi vọng những comment này không làm phật lòng bất cứ bạn nào. Bản thân mình cũng đã có khoản thời gian sống với nghề này nên mình chia sẻ góc nhìn thực tại.

Trân trọng,

Nguyễn Đức Giang

Bài chia sẻ khá hay, thanks bạn !!!

Còn các bạn khác có ý kiến gì không???

 

 

một ý nữa là BA áp dung kỹ thuật lấy requirement không phù hợp