Hotline

0963 801 047
APEX Global
ACADEMY FOR PROFESSIONAL EXCELLENCE

Làm sao để tôi có requirement đạt chất lượng?

2017-05-15  (1881)

Đề xuất của bạn được sếp duyệt thì chỉ mới là khởi đầu. Bởi lẽ bức tranh bạn đang vẽ ra cho chủ doanh nghiệp, các phòng ban nghiệp vụ vẫn là một bức tranh tương lai mang tính tạm thời, nó chỉ mang giá trị thật cho đến khi giải pháp chọn lựa đó hoàn thành triển khai thành công và đáp ứng các mục tiêu đề ra.

Chat_luong_requirement_03

(Hình ảnh của tác giả chia sẻ chủ đề “Agile Business Analyst” ở sự kiện Agile Vietnam Conference 2016)

Nhưng thực tế diễn ra hiếm khi được như kế hoạch. Dự án có thể gặp rất nhiều thách thức và gây ra thất bại bất cứ lúc nào. Ở vai trò một IT Manager kiêm trưởng dự án (Project Manager) ở các doanh nghiệp Non-IT bạn có thể nghe những lời phàn nàn từ các bên liên quan ở các meeting dự án:

  • Business Analyst bên nhà cung cấp nói rằng: Người làm nghiệp vụ không xác nhận yêu cầu kịp thời nên thời gian phát triển sản phẩm có thể bị trì hoãn.
  • Người làm nghiệp vụ nói rằng: Yêu cầu được mô tả sơ sài và không chắc đáp ứng với yêu cầu thực tế.
  • Người dùng cuối đưa ra tuyên bố khi nhìn thấy sản phẩm: Sản phẩm thực tế không đáp ứng được yêu cầu như họ đã nghĩ.
  • Quản lý dự án bên nhà cung cấp nói rằng: Người làm nghiệp vụ thay đổi yêu cầu thường xuyên và tiến độ dự án không chắc chắn giữ được và cần tính thêm chi phí.
  • Quản lý cấp cao của bạn nói rằng: Tình hình tiến độ chậm như hiện tại thì làm sao dự án đi vào hoạt động đúng kế hoạch và cần thảo luận với quản lý cấp cao của nhà cung cấp.

Có thể nguy cơ đề xuất của bạn không đạt được kết quả như lúc bạn thuyết phục ban giám đốc đầu tư và con đường tiến thân của bạn đang đặt dấu chấm hỏi trong mắt của ban giám đốc và người làm nghiệp vụ.

Có 1001 nguyên nhân tạo ra sự phàn nàn ở trên. Theo tôi thì “Chất lượng requirement quá kém” là nguồn cơn của mọi vấn đề, điều mà ít quản lý dự án nào tự tin thừa nhận ở thời điểm đóng dự án. Có thể bạn đang đặt ra câu hỏi “Vậy làm sao để có requirement chất lượng?”. Bên dưới là một vài tips cho bạn:

  • Bạn đừng đặt kỳ vọng quá cao vào đầu ra của Business Analyst – BA của nhà cung cấp. Bởi vì yêu cầu họ thu thập được gắn liền với cái “sản phẩm đóng khung” của họ mà không quan tâm nhiều đến cái thực trạng của vấn đề mà doanh nghiệp bạn đang đối diện. Nhiều khi họ chỉ nghe người làm nghiệp vụ kể về yêu cầu và ghi lại, nhưng đôi khi ngôn ngữ của người kể và ngôn ngữ của Business Analyst không đồng điệu với nhau.
  • Người làm nghiệp vụ luôn rất bận rộn. Bạn cần vận động hành lang bằng những bữa ăn bên ngoài công ty và nói cho họ biết sự quan trọng của họ trong việc hỗ trợ dự án, cung cấp yêu cầu, đặt ra những câu hỏi khơi gợi để được lắng nghe niềm trăn trở của họ từ chính sách, quy trình, biểu mẫu, cơ chế kiểm soát thông qua phê duyệt trong quản lý… bạn sẽ hiểu thật sự phần chìm của tảng băng trong doanh nghiệp. Người làm nghiệp vụ sẽ rất thích khi bạn nói được ngôn ngữ chuyên môn của họ.
  • Hãy dành thời gian để tìm hiểu cách mà nhiều doanh nghiệp dẫn đầu ngành trong nước hoặc khu vực đang áp dụng và học từ họ. Thành công của họ có thể đã bị đánh đổi rất nhiều thất bại trong việc xây dựng hệ thống. Hãy học các chính sách mới, quy trình làm việc và cả cách họ tiếp cận xây dựng hệ thống. Sau đó chọn lọc những cách thực phù hợp mà có thể triển khai được để nâng cấp quy trình nghiệp vụ trong doanh nghiệp mình. Đây là cách tiếp cận thông minh ở các IT Manager ở các doanh nghiệp FDI.
  • Bạn cần đưa ra cơ chế quản lý yêu cầu giữa bạn, người làm nghiệp vụ, và Business Analyst của đối tác. Bạn cần xác định những output của người làm nghiệp vụ, output của Business Analyst bên đối tác, và nói rõ cho họ biết chất lượng của yêu cầu ngay từ đầu. Bạn là owner của dự án, requirement là nguồn gốc lớn gây ra các vấn đề trong dự án. Hãy dành thời gian cho công việc này ngay từ đầu thay vì đi quản lý lỗi do yêu cầu kém gây ra trong quá trình triển khai dự án.
  • Bài toán tích hợp hệ thống vẫn còn là một thách thức ở các doanh nghiệp. Khi bạn nâng cấp, hoặc triển khai mới một hệ thống thì bạn cần tính toán xem hệ thống mới tương tác với các hệ thống khác trong hệ thống thông tin doanh nghiệp – MIS như thế nào? Chính trị trong doanh nghiệp nhiều khi tạo ra vách ngăn vô hình giữa các bộ phận chức năng, và hệ thống phần mềm chức năng cũng ngăn cách tương ứng. Bạn là người quản lý hệ thống MIS thì bạn cần tìm cách xoá bỏ những vách ngăn vô hình trong hệ thống ấy khi đưa bất kỳ hệ thống thành phần mới vào hệ thống MIS. Thời gian gần đây, các IT Manager ở doanh nghiệp FDI họ đang triển khai tuyên bố “Automation First” để giải quyết bài toán tích hợp hệ thống.

Có thể bạn nói để thực hiện các tips trên là quá khó. Những người đảm nhận vai trò IT Manager ở các doanh nghiệp FDI lớn đang làm tốt điều này. Sếp của bạn cũng đang kỳ vọng bạn thể hiện vai trò IT Manager của bạn và tạo ra nhiều giá trị lớn hơn cho doanh nghiệp.

Chat_luong_requirement_04

(Một phần của nội dung được tác giả chia sẻ với chủ đề “BABOK v3 – Những cải tiến nâng tầm vai trò Business Analyst do cộng đồng Business Analyst Việt Nam tổ chức ở tháng 4/2017)

Đúng là khó thật, khi bạn chưa sẵn sàng để trang bị cho mình bộ đồ nghề đủ mạnh để chiến đấu. Viện phân tích nghiệp vụ quốc tế – IIBA đã đúc kết kinh nghiệm thực tiễn từ các BA chuyên nghiệp ở các tập đoàn lớn trên thế giới và đưa vào cuốn hướng dẫn BABOK v3. Hãy dành thời gian đọc thật nhanh và thực hành trong dự án, bạn sẽ có cơ hội cải thiện chất lượng công việc và giảm các nguồn cơn gây ra thách thức cho dự án của bạn. Quan trọng hơn là bạn chứng minh giải pháp đề xuất viết trong Business Case mang lại giá trị như thời điểm bạn thuyết phục sếp. Niềm tin của sếp sẽ tăng lên bằng kết quả của dự án và bạn sẽ được giao nhiều dự án lớn hơn thay vì chỉ là người support kỹ thuật cho dự án đúng nghĩa.

**

Đây là series bài viết ứng dụng kỹ thuật Business Analysis trong doanh nghiệp Non-IT. Bạn có thể đọc thêm các bài đã published:

1/ Tại sao Business Analysis là top technical skill cho CIO, CTO, Head of IT, IT Manager?

2/ Business Analyst làm gì trong doanh nghiệp?

3/ Làm sao để đề xuất (Business Case) được sếp phê duyệt?

**

by Cao Trần,

bài viết được tác giả chia sẻ trên tường facebook cá nhân của tác giả và nhận được nhiều đóng góp của các chuyên gia CNTT.