Vì sao chúng ta cần Business Analyst?
Có khi nào chỉ cần khách hàng và lập trình viên nói chuyện trực tiếp với nhau mà không cần Business Analyst?
Disclaimer: Trong bài viết mình sẽ không dịch một số từ tiếng anh hay dùng trong ngành để giữ đúng nghĩa. Đồng thời, bài viết dựa trên kiến thức thực tế và thông tin mình tự tìm hiểu và trải nghiệm có thể sẽ khác với trải nghiệm ở các vị trí Business Analyst (BA) khác mà bạn đang làm.
Dù khách hàng đã trình bày hết yêu cầu và Developer xây dựng dựa trên yêu cầu đó nhưng kết quả là phần mềm hay tính năng làm xong không phải là cái khách hàng cần. Vậy vấn đề nằm ở đâu?
1. Vì sao chúng ta cần Business Analyst (BA)?
Những thành viên trong một dự án sẽ có ngôn ngữ sử dụng khác nhau dựa theo công việc gắn liền với họ.
Customer: đưa ra những yêu cầu cho hệ thống, ngôn ngữ họ sử dụng là ngôn ngữ trong doanh nghiệp/kinh doanh gắn liền với công việc của họ.
Developer: tiến hành xây dựng những yêu cầu thành tính năng/hệ thống để khách hàng sử dụng, ngôn ngữ họ sử dụng là ngôn ngữ lập trình, kĩ thuật.
Vì mỗi người đều sử dụng ngôn ngữ khác nhau, vì vậy giao tiếp trực tiếp sẽ dẫn đến không hiểu hết ý, hiểu lầm hoặc Developer sẽ tự tạo assumption (giả định). Hơn nữa công việc chính của Developer là lập trình hệ thống để có được chức năng như mong muốn của khách hàng sẽ không thể có đủ thời gian và công sức để có thể phân tích cặn kẽ yêu cầu của khách hàng.
Giống như việc hai người ở hai địa phương khác nhau cố gắng giao tiếp. Có những từ chỉ có địa phương đó sử dụng mà địa phương khác không hiểu, vì vậy khi giao tiếp sẽ sinh ra đoán mò. Hơn nữa hai người này làm các công việc khác nhau, cách dùng từ ngữ cũng khác nhau vì vậy để có thể hiểu hết ý là một điều vô cùng khó.
Lúc này BA xuất hiện chính là cầu nối gắn kết các bên liên quan, là người phiên dịch, kết nối và xác thực. BA lắng nghe nhu cầu của khách hàng, phân tích vấn đề và chuyển hóa chúng thành ngôn ngữ kỹ thuật mà Developer có thể hiểu và thực hiện.
2. Quy trình ‘Phiên dịch’ của BA
Quy trình ‘phiên dịch’ chính là các nhiệm vụ của BA đã trình bày ở bài viết Business Analyst (nhân viên phân tích nghiệp vụ doanh nghiệp) cụ thể là làm gì?
Những nhiệm vụ bao gồm trong phần phiên dịch này cụ thể và không giới hạn với các bước dưới đây:
Elicitation & Stakeholder Workshops (Thu thập yêu cầu và làm việc với các bên liên quan)
BA tổ chức các buổi workshop với đại diện của khách hàng, người dùng cuối, và đội ngũ nội bộ để hiểu quy trình nghiệp vụ hiện tại, cũng như xác định mong muốn hay vấn đề của doanh nghiệp đang gặp phải.
Các câu hỏi BA thường đặt ra:“Tại sao quy trình này quan trọng?”
“Điều gì xảy ra nếu khách hàng không thay đổi?”
“Ai sẽ sử dụng tính năng này và sử dụng như thế nào?”
Current State Analysis & Process Modelling (Phân tích trạng thái hiện tại và mô hình hóa quy trình)
Sau workshop, BA sẽ tiến hành phân tích yêu cầu bằng cách đọc các tài liệu sẵn có về quy trình hiện tại, mô phỏng dưới dạng các sơ đồ. Việc hiểu rõ quy trình hiện tại sẽ giúp BA nắm được những ‘pain points’ mà khách hàng đang gặp phải, những lỗ hổng nào mà quy trình mới có thể giải quyết.Solution Option Analysis & Technical Feasibility Review (Phân tích phương án giải pháp và tính khả thi kỹ thuật)
BA thảo luận với Tech Lead, System Architect (nếu có) để lên ý tưởng giải pháp và kiểm tra tính khả thi kỹ thuật. Quá trình này có thể thực hiện nhiều lần và cần nhiều cuộc thảo luận để đảm bảo giải pháp không chỉ giải quyết yêu cầu cho doanh nghiệp mà đồng thời giải pháp phải phù hợp với các phần khác của hệ thống.
Chưa kể có những yêu cầu liên quan đến nhiều hệ thống khác nhau (hệ thống tích hợp với phần mềm khác, hoặc bộ phận khác có liên quan) đòi hỏi BA sẽ là người cầu nối chính hiệu để trao đổi và đảm bảo giải pháp đưa ra tích hợp với các hệ thống khác hoặc các bên liên quan.Requirements Documentation & Business Rules Definition (Tài liệu hóa yêu cầu và quy tắc nghiệp vụ)
Xuyên suốt quá trình, BA phải đảm bảo ghi chép lại toàn bộ các buổi thảo luận, yêu cầu, giải pháp, những business rules (quy tắc nghiệp vụ/ quy tắc tính toán/ quy tắc phân quyền,…) để đảm bảo chức năng được xây dựng đúng như yêu cầu. Thông thường phân tích chi tiết và Business Rules sẽ được ghi chép ở user story (user story là mô tả ngắn gọn về một tính năng của sản phẩm dưới góc nhìn của người dùng cuối, thường được viết theo định dạng tiêu đề: “Với tư cách là [vai trò], tôi muốn [mục tiêu] để [lý do]”)User story phải đảm bảo bao gồm mọi yêu cầu cụ thể, chi tiết, rõ ràng và logic để Developer có thể nắm được đúng và đủ yêu cầu. Hơn nữa Tester cũng sẽ dựa vào user story để chạy kiểm thử chức năng đảm bảo chức năng đã được xây dựng đúng với yêu cầu đề ra.
Collaboration with UX/UI designer for User Experience Alignment (Phối hợp với UX/UI để đảm bảo trải nghiệm người dùng)
BA phối hợp với UX/UI Designer để đảm bảo prototype thân thiện và đúng logic nghiệp vụ.
Thông thường trong quá trình thiết kế giải pháp, BA sẽ trao đổi các logic và business rules để đảm bảo UX/UI designer có thể cân nhắc toàn bộ các trường hợp xảy ra và thiết kế sao cho thân thiện với người dùng. Thường sau khi trao đổi và đồng nhất giải pháp cuối cùng, BA sẽ xem lại user story để đảm bảo cập nhật đúng với những gì UX/UI designer đã thiết kế và có sự đồng nhất giữa prototype và user story.Requirements Validation & Client Sign-Off (Xác nhận yêu cầu và phê duyệt giải pháp)
BA trình bày giải pháp tổng thể cho khách hàng (bao gồm flow, prototype và tài liệu yêu cầu).
Nếu khách hàng đồng ý, BA sẽ chuyển yêu cầu sang backlog để Developer bắt đầu xây dựng.
Nếu khách hàng thay đổi yêu cầu, BA cần ghi nhận, đánh giá mức độ ảnh hưởng, và có thể phải quay lại bước phân tích ban đầu.
Support during Development & Testing (Hỗ trợ quá trình phát triển phần mềm và kiểm thử)
BA hỗ trợ Developer và Tester trong việc làm rõ yêu cầu, xác nhận kết quả kiểm thử đúng với yêu cầu của khách hàng.
Nếu như ở bước 6 khách hàng đồng ý với giải pháp thì user story sẵn sàng cho Developer xây dựng chức năng/ yêu cầu. Trong quá trình đi vào xây dựng để đảm bảo tính logic, Developer sẽ có nhiều câu hỏi cho BA ở các trường hợp khác nhau hoặc những phần chưa được đề cập trong user story. Developer sẽ phải đảm bảo tất cả các trường hợp xảy ra đều được hệ thống cân nhắc và có các phản hồi khác nhau. Vì vậy BA sẽ đóng vai trò giải đáp tất cả các thắc mắc của Developer. Sẽ có trường hợp BA cần kiểm tra lại với Customer, các bên liên quan để đảm bảo câu trả lời cho Developer được chính xác.
Sau khi xây dựng xong, Developer sẽ có buổi demo (chạy thử) cho nội bộ team tham khảo để đảm bảo những yêu cầu đã đề cập trong user story thoả mãn. Nếu có bất cứ phần nào chưa đúng sẽ được yêu cầu sửa lại.
Bên cạnh đó BA cũng sẽ trả lời các câu hỏi của Tester để đảm bảo Tester có thể hiểu đúng và kiểm thử tính năng đúng với yêu cầu viết trong user story.Demo & Acceptance with Customer (Chạy thử và nghiệm thu với khách hàng)
Thông thường bước này BA sẽ chạy thử cho khách hàng xem để đảm bảo yêu cầu đúng với mong muốn của khách hàng. Thường BA sẽ kết hợp nhiều chức năng/yêu cầu với nhau để có thể demo một flow từ đầu đến cuối cho khách hàng (ví dụ quy trình đăng kí, đăng nhập vào hệ thống hay quy trình thanh toán) từ đó phát hiện bất cứ lỗ hổng nào mà BA hay khách hàng đã bỏ qua và tìm hướng giải quyết cho phù hợp.
Note: Ở giữa các bước phía trên BA sẽ trao đổi với khách hàng khi cần thiết hoặc nếu có bất kì câu hỏi nào trong quá trình phân tích nhằm làm rõ yêu cầu và đảm bảo việc phân tích đi đúng hướng. 8 bước nêu trên thường là các bước chung nhất, nhưng sẽ có thể có thêm các bước ở giữa quy trình hoặc thay đổi người chịu trách nhiệm. Ví dụ BA sẽ có thể sẽ có thể là người thiết kế wireframe và xác nhận với khách hàng thông qua wireframe thay vì prototype từ UX/UI designer, BA có thể sẽ cũng là người test tính năng trước khi demo và xác nhận với khách hàng. Tuỳ thuộc vào tính chất và nhân sự của dự án bạn làm sẽ có thể thay đổi quy trình phía trên.
3. Những lỗi thường gặp trong quá trình ‘Phiên dịch’
Trong quá trình phân tích và truyền tải thông tin, BA sẽ khó lòng tránh khỏi một số lỗi dẫn đến chức năng xây dựng không đúng với yêu cầu của khách hàng. Dưới đây là một số lỗi BA thường gặp. Mình cũng vướng không ít các lỗi phía dưới và thực sự phải trải qua rồi mới có những bài học lớn để không mắc phải.
Không ghi chép đầy đủ dẫn đến hiểu chưa đúng và đủ yêu cầu khách hàng
Không tìm hiểu kĩ càng quy trình hiện tại và các tài liệu liên quan dẫn đến thiếu kiến thức về doanh nghiệp và khó trao đổi với khách hàng
Không xác nhận yêu cầu với khách hàng qua email/ giấy tờ cụ thể, không ghi chép đầy đủ các thông tin khách hàng đề cập
Quy trình không phản ánh hết thực tế của doanh nghiệp hoặc quá kĩ thuật khiến khách hàng không hiểu
Giải pháp quá phức tạp so với yêu cầu của khách hàng
Vội vàng đưa ra giải pháp cho khách hàng khi chưa có sự thống nhất nội bộ dẫn đến việc phải sửa đổi giải pháp sau này và mất uy tín với khách hàng
User story không rõ ràng, quá chung chung, không đề cập Acceptance Criteria (Tiêu chí chấp nhận)
Prototype thiếu, sai logic do chưa cân nhắc tất cả các trường hợp có thể xảy ra
Không kiểm tra/ thảo luận với các bên liên quan dẫn đến giải pháp không đáp ứng tích hợp với nhiều bộ phận/ hệ thống khác.
Dần dần mình học cách ghi chép lại các lỗi này và cố gắng bất cứ khi nào va phải trường hợp tương tự cũng sẽ bình tĩnh giải quyết và cố gắng tìm hiểu hết tất cả thông tin mình có được từ workshops, notes, trao đổi với các bên, tài liệu khách hàng cung cấp, website của khách hàng để khi trình bày giải pháp với khách hàng mình đã có hết tất cả các thông tin, các trường hợp có thể xảy ra nhằm đưa cho khách hàng một bức tranh tổng quan về giải pháp giúp khách hàng đánh giá và chọn lựa đúng đắn và phù hợp nhất.
4. Kết luận
Cẩn thận, tỉ mỉ, suy nghĩ thấu đáo trước khi trao đổi với khách hàng và các bên liên quan luôn là kim chỉ nam để BA có thể tự tin vào giải pháp của mình. Để có thể ‘phiên dịch’ từng yêu cầu thành công cũng phụ thuộc vào khả năng tuỳ cơ ứng biến, giải quyết vấn đề của BA để đảm bảo khách hàng vẫn đạt được yêu cầu họ mong muốn mà không gây khó khăn hay làm phức tạp hoá cho Developer.
BA chính là người kết nối kết hợp nhịp nhàng giữa các bên để cuối cùng ai cũng sẽ hoàn thành nhiệm vụ. Khách hàng vui vẻ vì yêu cầu được đáp ứng hơn nữa giải pháp thân thiện với người dùng và giúp khách hàng hoàn thành công việc nhanh và hiệu quả hơn, Developer cũng hoàn thành công việc được giao với hiệu quả cao, Tester có đủ thông tin để kiểm thử tính năng đảm bảo đúng với yêu cầu. Đây chính là quả ngọt sau quá trình ‘phiên dịch’ thành công mà bất cứ BA nào cũng mong muốn.
Cám ơn bạn nhiều đã đọc đến phần cuối của bài, hi vọng bài viết mang lại cho bạn góc nhìn cụ thể hơn về nhiệm vụ của BA trong dự án và hẹn bạn ở bài viết tiếp theo nha.
Mến thương,
Thơ Nguyễn