Hiểu về Requirement như thế nào cho đúng?

Hế lô anh em! Ai cũng biết là requirement là 1 thứ rất quan trọng. Và hầu như được quan tâm nhiều nhất trong các dự án.

Đối với BA thì requirement là một trong những yếu tố thể hiện được performance của mình. Requirement có rõ ràng hay không, có sát thực tế hay không, có đảm bảo được đúng scope hay không, bla bla…

Đối với requirement, đầu tiên thì chúng ta phải lấy nó về, hay nói thực tế là phải “moi móc, gợi mở” nó về.

Requirement sau khi được lấy về, chúng ra sẽ phải xử lý nó. Lấy như thế nào và xử lý như thế nào? Bài này mình sẽ chia sẻ về những gì mình hiểu và đã áp dụng thực tế.

Ngoài ra bài này mình cũng sẽ chém gió về cái gọi là Requirement thực sự của khách hàng. Nó tồn tại như thế nào? Và làm thế nào để nhận biết được đó có phải thật sự là requirement của khách hàng hay không?

Trạng thái và các bước xử lý requirement trong Business Analyst được thể hiện ở hình dưới đây. Toàn bộ bài viết mình sẽ dựa vào hình này.

Như hình trên, requirement trong Business Analyst tồn tại ở 2 giai đoạn: giai đoạn moi móc thông tin (elicitation) và giai đoạn phân tích (analysis). Ở mỗi giai đoạn, requirement sẽ có những đặc tính riêng và có cách xử lý riêng.

1.1. Ở giai đoạn Elicitation

Giả dụ có một công ty đang gặp vấn đề. Team triển khai sẽ xuất hiện để giải quyết vấn đề của họ. Khi đó BA cần phải hiểu được họ đang gặp vấn đề gì để biết đường mà giải quyết đúng không nào.

Đương nhiên là công ty khách hàng sẽ không tuôn ra tất tần tật những vấn đề của họ. Không phải vì họ không muốn, mà là vì họ không thể.

Cụ thể hơn là vì họ chưa hệ thống hóa được hiện trạng và vấn đề của họ. Do đó, BA cần phải elicit – tức là moi móc thông tin để lấy được requirement từ họ.

Qua nhiều lần trao đổi, workshop hoặc làm việc với khách hàng, BA sẽ nắm được yêu cầu cụ thể từ phía khách hàng (lẫn các stakeholders). Để rồi từ đó, chúng ta sẽ hệ thống hóa lại và cung cấp cho khách hàng một góc nhìn tổng quan hơn về thông tin cũng như các requirements của họ.

Điều này có nghĩa là requirement ban đầu chưa được khách hàng nói ra, chưa được phát biểu ra (unstated). Sau khi BA moi móc, requirement đó mới được nói ra và phát biểu ra bởi khách hàng (stated).

Đó là mục đích của việc moi móc thông tin (elicitation). Và requirement sẽ từ trạng thái unstated chuyển sang trạng thái stated 🙂

Mình nghĩ đây là một cách nghĩ rộng và tổng quan cho mọi vấn đề. Nó kích thích câu hỏi: “Tại sao khách hàng lại muốn như vậy?”. Đây là một câu hỏi cực kỳ quan trọng. Không phải requirement nào cũng nên ôm vào. Và không phải requirement nào cũng đáp ứng được mức độ hài lòng của khách hàng.

Khi tiếp nhận một requirement, cái đầu tiên mình nên nghĩ là khách hàng họ có thực sự họ cần cái này hay không? Hay chỉ đơn thuần chỉ là… cơn mưa ngang qua thôi.

Câu chuyện requirement từ unstated sang stated là cả một quá trình. Sẽ có lý do để khách hàng nói ra yêu cầu của họ cho mình nghe. Do đó, cần phải nhận diện đúng để biết đâu mới là requirement thật sự. Và trong những requirement thực sự đó thì cái gì nên ưu tiên hàng đầu :3

Nguồn: Modern Analyst

1.2. Ở giai đoạn Analysis

Requirement sau khi được anh em khai thác về sẽ được làm gì tiếp? Requirement sau khi thu thập về rất lộn xộn và hỗn tạp nhiều loại.

Có thể là biên bản họp. Có thể là 1 tấm hình sketch lại quy trình kinh doanh. Có thể là một vài tấm hình chụp những gì đã thống nhất trên bảng. Hoặc thậm chí có thể là file ghi âm quá trình moi móc thông tin từ phía khách hàng. Nói chung là nhiều. Rất đa dạng và thường rất hỗn độn để anh em hệ thống lại.

Do đó, quá trình phân tích – Analysis sẽ giúp BA làm chuyện này. Nói nôm na Analysis không phải là phân tích, suy luận gì ghê gớm hết. Mà đơn thuần, Analysis chỉ là đi hệ thống lại thông tin một cách phù hợp mà thôi. Cụ thể nó là chuỗi các hoạt động như cái hình lúc nãy, mà là đoạn 3, 4, 5 và 6:

(3) Organized: Sắp xếp và tổ chức lại dữ liệu một cách có cấu trúc.

Hình ra hình, file word ra file word, excel ra excel. Đoạn ghi âm cũng cần phải tài liệu hóa lại. Những phần nào là nháp thì note riêng ra. Những phần nào để chốt, quan trọng thì phải ghi nhận kỹ.

Thông tin sắp xếp theo chiều nào? Đi theo quy trình kinh doanh hay đi theo hành vi của người dùng? Bước Organized cần phải xác định rõ những điều này.

(4) Specified: Trả lời câu hỏi các dữ liệu này được xác định và phân loại dùng để làm gì, dùng như thế nào và dùng cho đối tượng nào?

Đối với end-user thì họ quan tâm cái gì? Họ liên quan đến thông tin nào, chức năng nào? Các stakeholders còn lại thì sao? Khách hàng họ quan tâm gì, cần theo dõi thông tin gì? Trả lời càng rõ ràng thì việc specify tài liệu sẽ dễ thở hơn. Sau này khi cần anh em cũng dễ lục lại.

(5) Verified: Bước này nhằm mục đích: đảm bảo các tài liệu mình hệ thống được đã ĐÚNG hay chưa.

Nhưng bước này là để verify với team nội bộ, chứ không phải khách hàng. Dữ liệu sẽ được internal team kiểm tra xem thử đã chính xác và đảm bảo đúng logic hay chưa. Ví dụ các tài liệu đặc tả đã viết đúng trình tự hay chưa? Đã thể hiện đầy đủ nội dung cần truyền tải hay chưa? Đảm bảo tất cả mọi thứ ok trước khi deliver cho khách hàng.

(6) Validated: Bước này thì lại nhằm mục đích: confirm các thông tin trao đổi với khách hàng đã chính xác, có sự ĐỒNG THUẬN giữa cả team phần mềm và phía khách hàng.

Dữ liệu sẽ được xác nhận với các stakeholder là đã đúng như yêu cầu của người ta hay chưa. Mỗi cái meeting đều cần 1 người chốt lại biên bản họp. Thường thì vô họp chém ghê lắm, mà họp xong cũng thường là quên hết bà.

Nói thêm về bước Specify, anh em BA cần phải làm tài liệu rất nhiều để gửi cho stakeholders. Mình note lại mấy điều sau nên chú ý:

• Biết Stakeholder là ai để bàn giao tài liệu cho phù hợp. Mình chỉ nói cái người khác muốn nghe. Không ai đi gửi tài liệu kỹ thuật cho end-users xem cả. Giống như không ai đưa bản vẽ thiết kế đường ống nước cho thợ điện xem hết.
• Anh em nên nắm vững ngôn ngữ của mình, đó là Modelling. Modelling vẫn là một phương thức truyền đạt thông tin vô cùng bá đạo. Nói bằng lời khó diễn tả quá thì mình vẽ ra, mô hình hóa nó lại rồi lưu lại thành tài liệu. Mai mốt bà con có ai hỏi thì có hàng mà show liền. Đỡ mắc công giải thích dài dòng, rườm rà.

Lý thuyết suông quá, ví dụ nhé anh em.

Có một cô gái mới ra trường cần mua một cái túi xách tay để đi làm.

Cô này có 300.000đ tiền để dành để mua một cái túi LV. Cô đến 1 cửa hàng chuyên bán túi thời trang nữ.

Người bán hàng hỏi cô gái: “Chị có cần em tư vấn gì không ạ?”

Cô gái trả lời: “Dạ em đang muốn mua 1 cái túi xách tay để đi làm, em có xem mấy mẫu LV trên website của mình…”.

Giả sử cô gái là khách hàng còn người bán hàng là BA (vì người bán hàng đang đóng vai trò là người giải quyết vấn đề cho cô gái).

Vậy thì vấn đề của cô gái là gì? Hay nói cách khác, requirement của cô gái là gì?

Đó là cần mua một túi xách tay đi làm đúng không nào. Ngay lúc đầu, requirement này của cô gái có được nói ra, hay được phát biểu ra không?

Không, vì chỉ có mỗi cô gái mới hiểu được nhu cầu của cô mà thôi. Khi cô bước vào tiệm bán túi, người bán hàng hỏi thì cô mới trả lời là tôi cần mua một cái túi LV. Đó là khi requirement được phát biểu ra.

Và người BA (ở đây là người bán hàng) đã hỏi cô gái để có được thông tin: à, cô này đang cần 1 cái túi đi làm và cô muốn mua túi LV. Đây đúng là requirement của cô gái, do cô phát biểu ra. Nhưng thường thì nó đâu có dễ ăn như vậy :)) Với trường hợp này thì mọi thứ không dừng lại ở đó.

Anh em nghĩ 300.000đ có thể mua được một cái túi LV không. Mình không rành túi nhưng cũng biết chắc chắn là không rồi. Hàng đểu chắc cũng trên 300.

Với 300.000đ trong tay và đang cần 1 cái túi đi làm, nhu cầu thật sự của cô gái (requirement thật sự của cô gái) là: mua một cái túi xách tay hàng Việt Nam, bền chắc và chất lượng, với mức giá tối đa là 300.000đ.

Đó mới thật sự là requirement phù hợp nhất với cô gái!

Và requirement này không chỉ đơn giản là từ unstated, hỏi một cái, chuyển thành stated là thôi. Mà người BA (hay người bán hàng) cần phải tiếp tục elicit thêm thông tin. Như hỏi thêm: túi LV ở chỗ em có 3 mức giá, 850.000đ, trên 1.550.000đ và trên 4.200.000đ. Chị muốn xem mức giá nào. Lúc này, cô gái cảm thấy không đủ ngân sách thì sẽ chuyển hướng sang một mẫu túi xách khác. Rẻ và phù hợp với mình hơn.

Elicitation không chỉ đơn thuần là lấy thông tin từ khách hàng mà còn phải khơi gợi và hướng khách hàng đi đúng hướng họ cần, gãi đúng chỗ họ ngứa. Và đó phải là hướng đi phù hợp với họ nhất trong thời điểm hiện tại. Đâu đó sẽ có thêm hàm lượng business consultant vào quá trình này nữa.

Thực tế là nhiều khách hàng cũng không biết mình đang muốn gì. Hay trớ trêu hơn, cái thực sự họ muốn là quả táo, nhưng khi elicitation thì họ lại nói họ muốn quả chanh. Vì đơn giản, họ đang không thực sự nhận thức được là họ đang cần quả táo chứ không phải quá chanh.

Họ chưa nhận thức ngay được điều đó và BA sẽ giúp họ hệ thống lại toàn bộ mọi thứ. Khi đó, chính khách hàng sẽ tự trả lời được họ muốn gì một cách rõ ràng nhất.

Do đó, việc elicit thông tin để ra được requirement từ trạng thái unstated sang trạng thái stated là không hề đơn giản chút nào. Đòi hỏi kinh nghiệm lão luyện mấy năm trời thì làm mới êm được.

Tóm gọn, requirement trong Business Analyst sẽ có 2 trạng thái: chưa được phát biểu và đã được phát biểu.

Nhiệm vụ của người BA là phải thật cẩn thận trong việc MOI MÓC (ELICIT) thông tin. Để biến những requirement từ trạng thái chưa đươc phát biểu thành trạng thái đã được phát biểu. Requirement chính xác thì làm ra cái phần mềm mới chính xác, mới khớp với nhu cầu sử dụng của người ta. Không thì cũng banh chành.

Tiếp đến, BA cần PHÂN TÍCH (ANALYSIS) những requirement này. Ý là hệ thống, sắp xếp lại thôi.

Quy trình analysis cứ lặp đi lặp lại cho đến khi nào đã đầy đủ các loại requirement cần có trong dự án thì thôi. Bao gồm: Business Objective Requirement (cái này quan trọng), Stakeholder Requirement (cái này cũng rất quan trọng), Solution Requirement (cái này thì lại càng quan trọng) và Transition Requirement (cái này cũng quan trọng nốt).

Anh em tham khảo bài Business Analyst là gì mình có nói về 4 giai đoạn này.

Hú hú. Bài này vầy là xong. Để lại bình luận bên dưới cùng trao đổi nhé anh em!