Đã bao giờ bạn tự hỏi, liệu BA có còn cần thiết trong đội phát triển sản phẩm? Thậm chí trong scrum guide cũng không đề cập đến role BA trong agile-scrum team. Hoặc bạn gặp tính huống nhiều lúc Dev/Tester nhận yêu cầu trực tiếp từ Stake Holders đã thực hiện rất tốt chức năng mà không cần bạn phân tích? Hoặc thậm chí, sếp của bạn cũng hoài nghi về giá trị mà bạn mang lại cho dự án?
Theo mình, BA là một trong những role/công việc quan trọng nhất trong vòng đời dự án/sản phẩm. BA đóng vai trò không thể thiếu trong quá trình xây dựng sản phẩm thành công. Vì vậy, đừng lo lắng và thêm yêu công việc của mình bạn nhé 🍻
Bảy chia bài đăng làm 3 phần:
- Phần 1: BA là người có hiểu biết tổng thể
- Phần 2: BA có những kỹ năng đặc thù không ai thay thế được (Coming soon)
- Phần 3: Liệu vị trí BA có còn hợp trend? (Coming soon)
Ngoài ra, để dễ hình dung, Bảy lấy bối cảnh chúng ta đang là “BA chính” cho sản phẩm có đặc điểm:
- Có nhiều Stake holders cùng tham gia
- Làm việc chung với Scrum team có cả Developer và Tester
1. BA là người có hiểu biết tổng thể
Vai trò của BA trong đội phát triển sẽ luôn là “wikipedia sống”, tìm ra câu trả lời mọi câu hỏi của đội phát triển và các bên liên quan. Vì vậy bạn luôn cần là người nắm rõ nhất các thông tin về nghiệp vụ và sản phẩm nhé. Tìm hiểu thêm tại bài viết good BA / bad BA (Coming soon).
1.1. Hiểu biết về Sản phẩm một cách tổng thể
Sẽ có rất nhiều người cảm
thấy việc phải mô tả, làm rõ, đưa yêu cầu cho BA thật tốn thời gian. Stakeholder A chọn đi thẳng đến chỗ Developer và “đi đêm” ("nhờ" làm task nhưng không chính thống) để hoàn thành tính năng
mong muốn 1 cách nhanh nhất.
Chúng ta cần hạn chế việc này, nó sẽ luôn rất rủi ro cho dự án vì:
- Sản phẩm của bạn ảnh hưởng đến rất nhiều bên, Stake holder A là 1 trong số đó. A dù rất giỏi mảng nghiệp vụ của họ, thậm chí solution rất hay. Nhưng, solution mới có giá trị không, có ảnh hưởng đến bên liên quan khác không? Có ảnh hưởng đến các tính năng đang có không?... BA mới là người thấy được toàn bộ bài toán một cách tổng thể để phân tích được.
- Developer thường khó đưa ra lý do để từ chối làm ngay những yêu cầu này, dẫn đến chậm tiến độ các ưu tiên khác. Trong trường hợp này, BA chính là người bảo vệ đội phát triển khỏi cái bẫy “muốn mọi thứ, ngay lập tức” của Stake holder.
Hơn nữa, hiểu biết sản
phẩm một cách tổng thể, giúp BA có ưu thế rõ ràng trong việc phân tích SWOT của
các thay đổi diễn ra liên tục. Từ đó đưa ra được nhiều phương án đề xuất giải
pháp “hợp lý”.
1.2. Hiểu biết về Nghiệp vụ
Bạn còn thực hiện những
công cụ static analysis, dynamic analysis không? Khi thực hiện một dự án mới,
hoặc có thay đổi về nghiệp vụ kinh doanh, BA chính là người đại diện của đội
phát triển tìm hiểu những kiến thức này. Bạn cần có những kiến thức “càng sâu,
càng tốt” về nghiệp vụ đang làm.
Khi có kiến thức tốt về nghiệp vụ:
- BA tự tin tư vấn, cùng phân tích bài toán kinh doanh
- BA tự tin trình bày câu hỏi Why, để cả nhóm phát triển hiểu cùng một hướng
Một dự án không có BA,
sẽ luôn phải đối mặt với việc đội phát triển không hiểu mình đang làm gì? mục
đích phát triển là gì? Dẫn đến bộ tính năng rất dễ đi lệch hướng. Sản phẩm làm ra có thể không được chấp
nhận (UAT).
1.3. Hiểu biết về Quy trình phát triển phần mềm
Dù bạn đang trong dự
án chạy theo mô hình Agile-scrum hay Waterfall, đội dự án đều phải tuân theo một
số nguyên tắc chung nhất định.
Ví dụ: UAT sẽ chỉ được
thực hiện sau khi biên bản SIT được ký, code đã được deploy lên môi trường, người
dùng được phân quyền...
Những quy tắc này luôn “quá
sức” với đơn vị chuyên làm nghiệp vụ. Thực hiện theo nguyên tắc đã thống
nhất là cách dễ dàng nhất để đội dự án thực hiện được mục tiêu đề ra. BA đảm bảo mọi thay đổi (changes) trong quá trình phát triển được thực hiện đúng nguyên tắc, đảm bảo chất lượng, tiến độ cam kết với các bên. Hiểu quy trình từ góc nhìn của BA tại đây
0 Comments
Đừng quên để lại comment của bạn, trao đổi về chủ đề đang nhắc đến nhé. Cảm ơn bạn!