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.

Đối với BA, công việc quan trọng nhất chính là lấy được nhiều requirement nhất của user, càng nhiều, càng thầm kín càng tốt. Và một trong những thuật ngữ đẹp đẽ được dùng cho công việc này đó là Requirement Elicitation. Hay Việt hóa là: khơi gợi, đào bới, moi móc nhu cầu từ user.

Nói tóm lại, đó là quá trình để ông BA đi cạ nhau với user, với người nắm giữ và phát sinh mọi nhu cầu cho dự án, từ đó moi được từ miệng user những thông tin giá trị, cái họ cần, cái họ kỳ vọng, làm cơ sở hình thành nên Scope của dự án (phạm vi) và tạo ra requirement chi tiết cho team phát triển làm.

Thường thì quá trình này hay được gán với những buổi workshop dài đằng đẵng, mời đủ kiểu stake holder, từ giám đốc đến nhân viên vệ sinh, làm thành 1 đại hội, 1 festival lấy requirement kéo dài từ sáng sớm đến chiều tối. Nhưng thực ra trong đa số trường hợp quá trình này bao gồm nhiều những session nhỏ kết hợp với nhau, mỗi lần chỉ có sự tham gia của 1 vài stakeholder nhất định. Đòi hỏi BA phải vận dụng linh hoạt tùy tình huống.

Dưới đây tôi sẽ chia sẻ 5 kỹ thuật moi móc requirement từ stakeholder để bạn có thể áp dụng tùy hoàn cảnh.

Top 5 kỹ thuật moi móc requirement

1. Quan sát

Kỹ thuật đầu tiên đó là soi mói bằng mắt thường. Hãy ngồi bên cạnh user nếu bạn được tiếp cận với họ, hoặc cũng có thể qua 1 phần mềm share màn hình online nào đó.

Ngồi ngay ngắn và xem user làm việc thực tế. Bạn có thể yêu cầu họ vừa làm, vừa giải thích các bước mà họ đang thực hiện. Ví dụ như: Tôi phải làm gì để tạo 1 sản phẩm mới, hoặc các bước nào tôi cần làm để hủy 1 đơn hàng.

Nhìn 1 cách trực tiếp vào quy trình làm việc hiện tại của user và đặt những câu hỏi tại sao. Đừng sợ rằng bạn sẽ hỏi “Ngu”. Hãy luôn hỏi lý do tại sao họ bấm vào nút đó, họ nghĩ gì trong đầu khi làm thế. Cố gắng thấu hiểu được logic công việc và làm rõ các logic đó bằng câu hỏi.

Câu hỏi ngu duy nhất là câu hỏi mà bạn không hỏi.

Hãy đặt ra 1 vài tình huống giả định khác ngoài “happy case” mà user đang trình diễn. Nếu tôi không bấm vào nút này mà bấm vào bên ngoài thì sao, nếu tài liệu nặng hơn mức cho phép thì sẽ thế nào.

2. Sử dụng sơ đồ, nguyên mẫu

Phương pháp thứ hai tôi muốn chia sẻ với bạn là Sử dụng nguyên mẫu để xác định với user những thứ họ cần.

Đây là một cách tuyệt vời để nói chuyện với user và làm rõ requirement nhanh chóng. Hãy mô tả lại cách bạn hiểu business logic của họ thông qua

• Sơ đồ workflow: khi cần mô tả lại 1 quy trình phức tạp gồm 1 hoặc nhiều đối tượng tham gia
• 1 bản wireframe: khi cần mô tả luồng thao tác và các component hiển thị trên 1 màn hình thiết bị.
• 1 sơ đồ mối quan hệ thực thể (ERD): khi cần mô tả mối quan hệ giữa các đối tượng tồn tại trong hệ thống và 1 vài thuộc tính cơ bản của chúng

Từ những mô hình này, bạn có thể trực quan hóa toàn bộ business hoặc 1 số khía cạnh cần làm rõ. Tiếp theo là cho phép user feedback lại dựa trên cái bạn đã vẽ. Cách này có thể giúp bạn khám phá ra những thông tin bất ngờ, những kỳ vọng lạ lẫm mà trước nay bạn không nghĩ tới.

Bạn có thể làm một bản nháp đơn giản của những mô hình trên, tùy theo nhu cầu mô tả và mức độ thành thạo của user.

3. Phỏng vấn theo bộ câu hỏi chuẩn bị trước

Kỹ thuật thứ 3 là phỏng vấn theo check list. Liệt kê danh sách những câu hỏi mà bạn cần làm rõ. Gửi trước danh sách này cho stakeholder để họ có thời gian xem xét và chuẩn bị.

Để thực hiện phỏng vấn, bạn sẽ cần meeting với stakeholder, và cuộc họp sẽ sử dụng danh sách câu hỏi này như agenda. Các stakeholder chịu trách nhiệm sẽ trả lời câu hỏi của bạn theo thứ tự.

Việc tạo ra 1 danh sách câu hỏi và cho stakeholder có thời gian để chuẩn bị sẽ giúp bạn có được những câu trả lời rõ ràng hơn nhiều so với hỏi một cách ngẫu nhiên.

Tất nhiên, hãy giới hạn thời gian buổi họp, đặt câu hỏi có trọng tâm để tránh người trả lời lan man sang các khía cạnh khác.

4. Đọc tài liệu

Khi bạn tham gia vào một dự án thuộc 1 domain lạ lẫm, bạn cần dành thời gian để hỏi xin và đọc các tài liệu liên quan để có 1 nền tảng cơ bản. Các tổ chức, công ty, dự án thường có những tài liệu đã tồn tại trước

Cách này không đòi hỏi phải tương tác với stakeholder, chỉ cần đọc và đọc. Rồi từ những thứ đọc được, bạn tạo ra các sơ đồ, nguyên mẫu, tạo check list câu hỏi, giúp cho việc quan sát trở nên cụ thể và rõ ràng hơn.

Cách này có thể tiết kiệm rất nhiều thời gian của bạn và của stakeholder khỏi những cuộc họp lê thê. Nếu stakeholder của bạn là cực kỳ bận rộn, khó để tiếp cận thì hãy ưu tiên phương pháp này để có sự chuẩn bị tốt nhất trước khi book 1 buổi họp quý giá.

Nhưng lưu ý nhé, việc đọc tài liệu luôn là phương pháp tham khảo để tiếp tục thực hiện các phương pháp khác. Bạn sẽ không muốn dính vô cảnh đọc trúng 1 tài liệu đã out date từ đời nào, quy trình quy chuẩn đã khác xa với thực tế vận hành thì lúc đó xem như xu cà na.

Luôn nhớ verify lại với user về những gì bạn đọc được và cách mà bạn hiểu về tài liệu đó. Đừng vội đưa ra kết luận hay đúc kết một giả định sai lầm.

5 Khảo sát và dùng bảng câu hỏi

Bây giờ là kỹ thuật cuối cùng trong những kỹ thuật Elicite Requirement. Đây là cách thức tuyệt vời đề tương tác, lấy thông tin từ những stakeholder bạn không có cơ hội tiếp xúc trực tiếp nhiều.

Tạo ra 1 bảng khảo sát là cách để thu thập được thông tin một cách khách quan hơn. Trong đa số trường hợp, người ta sẵn sàng chia sẻ nhiều câu hỏi mang tính cá nhân hơn khi viết vào 1 bảng khảo sát thay vì trả lời trực tiếp. Nhưng ngược lại, phương pháp này cũng có nhược điểm là thông tin ghi nhận được thỉnh thoảng sẽ không rõ ràng, có để diễn giải khi không có ngữ cảnh cụ thể.

Hãy kết hợp các kỹ thuật

Hãy chọn cho mình kỹ thuật phù hợp nhất tùy theo tình huống và dự án cụ thể một cách thông minh. Mỗi kỹ thuật đều có điểm mạnh và điểm yếu, 1 BA giỏi sẽ biết lựa cơm gắp mắm, chọn đúng tool cho đúng mục đích. Đó là sơ lược những kỹ thuật lấy yêu cầu mà tôi biết. Chia sẻ thêm nếu bạn có thêm kỹ thuật nào khác nhé.

Viết

Là một BA, khi viết 1 requirement, hãy đảm bảo viết 1 cách rõ ràng sáng sủa nhất.

Requirement rõ ràng giúp người đọc dễ hiểu đúng requirement, tránh làm sai và lãng phí nguồn lực. Bạn bất lực khi nhận ra 1 từ ngữ nào đó khiến dev team hiểu lầm, và rồi đi tong cả 1 tính năng. Việc này là 1 trong những cơn ác mộng của BA. Khi nghe brief thì dev gật gật hiểu rồi, nhưng là nói 1 đằng hiểu 1 nẻo. Dev vẫn cần document để có “giấy trắng mực đen”. Nhưng mà mặt chữ thì có khi mỗi người đọc rồi hiểu 1 kiểu. Ngữ pháp Việt Nam nó lạ lắm, sơ sẩy 1 cái là có thể lật ngược ý nghĩa lại liền. Việc viết rõ như từ điển, câu cú gãy gọn để tránh bị “lật kèo” là bí quyết sống còn.

Đỡ mất công review tới lui và xác nhận nhiều lầm. Một requirement khó hiểu sẽ dẫn đến việc hỏi đi hỏi lại, mãi không chốt được.

Những requirement mạch lạc giúp ông BA sáng dạ hơn. Khi đặt vấn đề 1 cách tường minh, những câu hỏi mấu chốt sẽ xuất hiện. Dễ dàng hiểu được bức tranh toàn cảnh và khai thác những thông tin “xịn” từ PO. Từ đó nâng cao giá trị của ông BA trong team phát triển.

Dưới đây là 3 mẹo để viết 1 requirement “rõ như ban ngày”:

Không dùng câu bị động

Khi viết requirement, hãy dùng câu khẳng định, đủ chủ ngữ vị ngữ.

Thế nào là câu bị động:

• Bài viết được lưu ở portal
• Bài viết được hiển thị lên trang chủ

Từ “được”, “bị” thể hiện câu đang dùng là câu bị động. Chúng ta có xu hướng dùng câu bị động khi thiếu thông tin, điều này rất rủi ro. Trong 2 ví dụ trên, requirement mô tả hành động nhưng thiếu đi thông tin về chủ thể thực hiện hành động. Điều này dẫn đến 2 khả năng: 1 là người đọc sẽ hỏi lại để có thêm thông tin, 2 là họ sẽ giả định theo cách hiểu của chính họ (khả năng 2 này rất chí mạng nếu người đọc giả định sai).

Thế nên 1 cấu trúc câu khẳng định sẽ đảm bảo đầy đủ ý nghĩa.

• Admin nhập liệu lưu bài viết ở portal
• Hệ thống hiển thị bài viết trên trang chủ

Bằng cách thêm vào ai hoặc cái gì thực hiện hành động, requirement đã trở nên dễ hiểu gấp 100 lần.

Không dùng tá lả thuật ngữ

1 cách nữa để khiến mớ tài liệu requirement trở thành nồi cám heo đó là: Thuật ngữ

Cùng 1 định nghĩa nhưng ông BA mỗi lúc lại gọi 1 kiểu khác nhau. Lúc thì gọi là “Admin” lúc thì gọi là “Quản trị viên”. Rồi người đọc confuse đến nỗi muốn khóc vì không chắc 2 từ đó có phải là một không.

Nếu xét 1 cách dễ tính hơn thì có thể 1 nhóm người đọc đã quen với domain bạn đang làm, có thể đọc 1 hiểu 10 thì cũng không thành vấn đề. Nhưng nếu team bạn tuyển thêm dev, mở rộng quy mô, làm tài liệu cho end-user hoặc transfer kiến thức cho 1 ông BA mới vào thay cho bạn. Mà họ lại là tấm chiếu mới trong domain đó thì sẽ bắt đầu sấp mặt. 1 vạn câu hỏi vì sao sẽ xuất hiện, đè bẹp bạn và đồng bọn.

Mỗi khi thấy xuất hiện những thuật ngữ lạ khi giao tiếp trong dự án, hãy nói lên vấn đề đó để cả team ghi nhớ và bổ sung vào Glossary.

Không dùng từ nối, câu phức

Sử dụng những câu đơn, chỉ chứa 1 mệnh đề. Không nên xào chẻ 1 câu bằng cách ghép nhiều câu nhỏ lại. Nó rất đẹp trong văn học nhưng lại rất nhức đầu khi đọc requirement.

Dấu hiệu của 1 câu phức đó là bạn sử dụng những từ như: “và”, “hoặc”, “trước khi”, “sau khi”

Ví dụ: Admin nhập liệu nhập nội dung bài viết và xem bản review trước khi lưu.

Một requirement như vầy có thể được xem là rõ ràng mạch lạc không? Trong cùng 1 câu này, sử dụng rất nhiều động từ. Tuy rằng câu được viết ở thể chủ động nhưng nó hàm chứa 3 requirement cùng 1 lúc.

• Admin nhập liệu nhập nội dung bài viết
• Admin nhập liệu xem bản review bài viết
• Admin nhập liệu lưu bài viết

Đừng viết một cách bản năng khi sử dụng quá nhiều từ nối. Hãy rạch ròi ra để nhìn thấy được cụ thể phải làm những gì. Đôi khi chỉ ba từ “trước khi lưu” mà bạn để lẫn lộn nó trong 1 câu phức tạp cũng sẽ đẻ ra một đống việc phải làm.

Thực hành

Hãy lấy ra bất cứ tài liệu requirement nào bạn đang có, do chính bạn viết hay một ai đó viết. Áp dụng 3 checklist vừa nêu bên trên để kiểm tra xem mình đang dính lỗi này nhiều như thế nào.

Sau này, mỗi khi thấy bản thân hay đồng nghiệp mắc phải thói quen tương tự thì hãy thảo luận để cùng nhau viết requirement một cách rõ ràng hơn nhé.