1 BA mới thường sẽ gặp vấn đề với việc lấy yêu cầu khi tham gia những dự án đầu tiên mà không được hướng dẫn bởi 1 leader. 1 ví dụ như sau:

Ở công ty em không có 1 quy trình lấy requirement chính thức nào cả. Em toàn phải đi lượm lặt requirement từ các buổi họp của 1 ai đó: 1 buổi brainstorm, 1 buổi design review hay buổi break down funtion…
Mà thường các buổi họp đó cũng ngắn ngủn, thường gói gọn trong 1 tiếng đồng hồ, em muốn đặt thêm mấy câu hỏi để làm rõ requirement cũng không được. Cũng chẳng có ai confirm requirement một cách chính thức. Đến cuối cùng thì không thấy được bức tranh tổng thể và các requirement cũng không được ghi lại đầy đủ, đúng đắn.

1. Làm rõ vai trò của bạn trong dự án

Gốc rễ của vấn đề này là bạn thiếu hình dung được vai trò của mình trong dự án, có thể bạn chưa vạch ra được 1 BA Plan cụ thể khi tiếp nhận dự án ở những ngày đầu tiên. Hãy đảm bảo thực hiện việc đó.

Chẳng phải vai trò của BA là lấy requirement, viết doc, rồi chuyển giao thành Fuctional spec sao. Thực ra không có 1 vai trò cố định cho BA với tất cả các dự án. Mỗi dự án có thể sẽ yêu cầu mức tham gia của bạn ở mức độ khác nhau. Việc của bạn là xác định rõ phạm vi đó. BA không nắm được vai trò của mình trong dự án sẽ có xu hướng deliver những thứ mà stakeholder không thật sự cần và đầy thiếu sót.

Hãy làm việc với những người sau để có được thông tin cần thiết về vai trò của mình:

• Business stakeholder
• PM hoặc manager
• BA lead (nếu có)
• Dev team

Để có thể biết được mình đóng vai trò gì, output mình cần tạo ra là gì, bạn cần phải chịu trách nhiệm cho những nhiệm vụ nào. Từ đó, bạn có thể có được BA Plan, làm theo kế hoạch để tránh sự lạc lối xuyên suốt dự án.

2. Chủ động trong quy trình lấy requirement

Requirement là thứ input bạn cực kỳ thèm thuồng, vậy thì bạn phải cực kỳ chủ động tìm kiếm nó. Đừng gò ép vô những quy trình của team hay của công ty. Đừng chen chúc vào các buổi họp eo hẹp thời gian của 1 ai đó để lần mò requirement. Hãy chủ động setup, book meeting, gửi mail cho stakeholder để mời meeting khi bạn thực sự cần. Chuẩn bị cho các buổi họp đó thật kỹ lưỡng để có thể có 1 buổi họp thật hiệu quả và tập trung.

Nắm quyền chủ động kiểm soát các thông tin và chủ đề thảo luận trong buổi họp. Chuẩn bị sẵn những câu hỏi, để chắc chắn lấy được thông tin mà bạn cần.

Hãy chắc chắn rằng bạn tập trung vào 1 vài vấn đề cụ thể. Nếu stakeholder bắt đầu lệch hướng, hãy nói rằng “Em sẽ setup 1 buổi meeting nữa để thảo luận về vấn đề này”. Hãy đảm bảo buổi họp đầu tiên sẽ thực sự năng suất.

3. Validate và review requirement

Đừng quên làm động tác quan trọng này. 1 vài câu hỏi và vài buổi lấy requirement chắc chắn không thể đủ. Nếu bạn dựa hoàn toàn vào đó thì đảm bảo là sẽ thiếu đầu thiếu đuôi. Hãy tổng hợp thông tin đã có, thông tin chưa có thì có thể meeting để lấy tiếp hoặc giả định 1 cách cẩn thận. Và đem mớ thông tin ấy tổng hợp thành document và đưa cho stakeholder validate 1 lần nữa.

Đó không cần là 1 buổi mài đít 5 tiếng trong phòng họp, review 50 trang document. Việc đó sẽ làm stakeholder kiệt sức và né tránh việc ngồi với bạn trong tương lai. Đôi khi cách này sẽ giúp ích, nhưng nó không phải là cách làm hiệu quả nhất.

Bạn có thể dùng các công cụ như: review Wireframe, workflow, sơ đồ use case… Bất cứ cách nào dùng để capture requirement và mô hình hóa một cách ngắn gọn cách hiểu của bạn đối với những vấn đề đang nói tới. Chỉ cần stakeholder sơ lược qua tài liệu mà bạn tạo ra và validate thông tin trong đó thì xem như việc phân tích đã hoàn thành

Đó là lúc bạn nhận được câu trả lời “ Đúng rồi, nhưng mà…” từ stakeholder, người sẽ cho bạn thêm những requirement mới mà bạn đã bỏ lỡ

Bạn có thể sẽ gặp chút ráng cự từ stakeholder, họ chỉ cho bạn 1 thời gian rất ngắn ngủi trên lịch trình của họ, sau đó hy vọng BA tạo ra 1 document requirement rõ ràng từ không khí. Hãy giải thích giá trị của bạn một cách rõ ràng. Việc làm rõ vai trò của mình ở bước 2 cũng là 1 cách để stakeholder hiểu được đây là những việc bạn phải làm để hoàn thành vai trò mà họ kỳ vọng bạn mang lại cho dự án.