Chào các bạn,
Mình là Huyền - hiện đang là Business Analyst tại FPT Software, với 5 năm kinh nghiệm BA, ERP consultant trong nhiều lĩnh vực khác nhau như E-Commerce, Supply Chain, Production, HR, Accounting.
Kết nối với mình tại đây để chia sẻ kinh nghiệm thực chiến ở vị trí BA tại nhiều lĩnh vực khác nhau nhé!
----------------------------------
Lưu ý: Những chia sẻ này là quan điểm cá nhân của Huyền với kinh nghiệm 4 năm làm IT BA tại công ty outsource. Một số ví dụ có thể không chính xác với các vị trí BA tại công ty product, BA non-IT hoặc product owner.

Trong mô tả công việc về vị trí BA, chắc không ít lần các bạn gặp những yêu cầu như “Thành thạo ít nhất 1 công cụ vẽ mockup/wireframe”, “Có kinh nghiệm viết SRS, BRD, SRD”, “Có kinh nghiệm sử dụng Axure”…?

Và chắc là với những bạn đang tìm hiểu nghề BA sẽ cầm những từ khóa này lên mạng tìm hiểu để có thể học và bước chân vào nghề. Tạm bỏ qua định nghĩa về các loại tài liệu vì Huyền nghĩ đa số các bạn đều đã hiểu (hoặc có thể Google), vấn đề Huyền muốn thảo luận là hiểu cấu trúc, ý nghĩa và biết viết những tài liệu này liệu đã đủ chưa?

Thông thường tài liệu BA mang lại cho dự án hai lợi ích cơ bản:
Là biên bản để xác nhận yêu cầu chi tiết với khách hàng
Là nguồn thông tin đầy đủ và chi tiết để đội dự án có thể đọc là làm theo

Đầu tiên, bàn một chút về khía cạnh thứ nhất: BA và khách hàng.
Nhiều khách hàng rất coi trọng loại tài liệu này và thường đọc rất cẩn thận, chi tiết. Nhưng đa phần, BA sẽ gặp những khách hàng trả lời “Anh/chị bận lắm, chưa có thời gian xem đâu em”, “Ừ, em cứ viết theo những gì mình đã chốt trong buổi họp là chị ok thôi”… Đen đủi ở đây, “OK” chỉ trên miệng, không phải lúc nào khách hàng cũng sẽ ký và xác nhận trên SRS trước thời điểm đội dự án bắt đầu phát triển. Một số sợ trách nhiệm, một số không có thời gian đọc, một số không hình dung được sản phẩm sẽ làm ra như nào, và một số thì muốn đợi đến lúc UAT, mình chưa chốt thì còn được quyền thay đổi yêu cầu. Nhiều khách hàng chỉ ký SRS khi nghiệm thu dự án (khi mà họ chắc chắn sản phẩm đáp ứng được chức năng mà họ yêu cầu. Vậy nên, dù BA gửi một tài liệu chỉn chu, đầy đủ chưa chắc đã được khách hàng chú ý và xác nhận tài liệu đó.

Với những trường hợp này, tài liệu còn không quan trọng bằng một cái “meeting note”. Thứ khách hàng dễ xác nhận hơn đó chính là những nội dung đã trao đổi giữa hai bên. Thay vì yêu cầu khách hàng xác nhận trên một bản SRS hay BRD dài cả trăm trang, thì một chiếc mail xác nhận “meeting note” có thể làm cơ sở cho BA từ chối yêu cầu thay đổi nằm ngoài phạm vi khảo sát và phạm vi dự án. Việc còn lại chính là làm sao BA đảm bảo được tài liệu như SRS, BRD khớp với “meeting note” đã được xác nhận bởi khách hàng.

Việc này đòi hỏi “kỹ năng phân tích” (yêu cầu cơ bản với mọi BA). Không xin xác nhận được tài liệu thiết kế là một rủi ro với BA, nhưng rủi ro hơn chính là BA không hiểu yêu cầu và gắn yêu cầu đó với chức năng phần mềm sẽ phát triển.

Quay trở lại câu hỏi ban đầu, “Biết viết tài liệu thiết kế” đã đủ chưa? 
Trong trường hợp này, tài liệu là kết quả, nếu chỉ biết viết thôi thì chưa đủ. Ngoài biết viết tài liệu, BA cần khai thác, tư vấn và phán đoán trước được những khó khăn đội phát triển có thể gặp phải nếu làm theo thiết kế. Và tài liệu là kết quả của quá trình đó.

Ở khía cạnh thứ hai, BA và đội dự án.
Một số công ty dev có thể không đọc SRS và không biết SRS có cấu trúc như thế nào. Một số công ty khác, dev chỉ nhìn mockup và code theo ý hiểu của họ về hình ảnh. Còn tester thì có thể lôi từ chữ sai chính tả, không hợp lý trong thông báo lỗi để hỏi lại BA. Vậy lúc đó BA làm gì nhỉ? Tiếp tục cập nhật cho đúng và hô hào đội dự án đọc SRS để code chăng? Vẫn được mà, nhưng điều đó có thúc đẩy dự án làm nhanh hơn, mọi người phối hợp với nhau tốt hơn không? Câu trả lời, chắc các bạn đi làm rồi sẽ hiểu.

Với những chức năng nhỏ, hoặc chức năng BA cảm thấy dev có thể hiểu lầm, chúng ta có thể hỏi han bạn dev làm tới đó chưa? Có vướng mắc gì không? Nghiệp vụ chỗ này có chút đặc biệt cần chú ý nè? Từ việc xây dựng niềm tin với dev, dần dần BA có thể hướng dev sang đọc tài liệu để mình đỡ mất công giải thích, chạy vòng vòng. Nhưng quan trọng, chúng ta phải có niềm tin lẫn nhau và sản phẩm nhóm mình làm ra. Dev cũng cần niềm tin SRS BA viết ra là đúng và cần thiết. Các tài liệu BA có thể nằm trong scope release của dự án, nhưng sản phẩm cuối cùng vẫn là một phần mềm. Điều quan trọng nhất là đội dự án hiểu chức năng của phần mềm và tạo ra một sản phẩm hoàn chỉnh. Tài liệu là một công cụ hữu ích để truyền đạt thông tin một cách chính xác và có hệ thống. Như câu nói “Mọi con đường đều dẫn đến thành Rome”, và tài liệu là một con đường, để đi đến đích chúng ta có thể đi theo con đường quen thuộc đó hoặc kết hợp với nhiều cách khác nhau.

Tóm lại, tài liệu là kết quả của cả một quá trình dài BA làm việc với khách hàng và đội dự án. Đó là kết quả để lưu trữ và các bên có thể giao tiếp với nhau qua văn bản. Nhưng đó không phải là phương thức duy nhất giao tiếp và trao đổi thông tin. Việc quan trọng hơn tài liệu chính là BA có thể phối hợp tốt với các bên để đảm bảo yêu cầu khách hàng được hiểu đúng và phát triển đúng.
Hy vọng bài viết hữu ích với mọi người!

__________________________________________

Đến tỷ phú như Bill Gates hay Mark Zuckerberg xuất chúng tới vậy đều tìm cho mình một Mentor để học hỏi những bài học mà không sách vở nào có. Vậy khi bạn đang mông lung, hay gặp khó khăn khi trong quá trình học hỏi các kiến thức chuyên môn, kỹ năng mà không thể tìm được ở bất kỳ cuốn giáo trình, trang website nào thì bạn làm thế nào?

Thấu hiểu được nỗi băn khoăn ấy, Mentori đã cho ra đời nền tảng Mentoring với sứ mệnh kết nối cho các bạn sinh viên đến những anh chị, chuyên gia có chuyên môn về định hướng bản thân và kiến thức trong mọi lĩnh vực, ngành nghề mà các bạn theo đuổi. Với sự tham gia của đội ngũ Mentor giàu kinh nghiệm, thành công ở các lĩnh vực: HR, Marketing, Sales, Audit & Accounting, Finance & Banking,... đến từ những tập đoàn đa quốc gia nổi tiếng trên thế giới như: Unilever, PwC, EY, BCG, McKinsey,...

TÌM KIẾM VÀ KẾT NỐI NGAY VỚI MENTOR TẠI ĐÂY!