Hotline

0963 801 047
Apex Global
ACADEMY FOR PROFESSIONAL EXCELLENCE

Làm sao để có requirement?

2020-05-14 

Đợt WFH vừa rồi có một bạn BA ở ngoài Hà Nội inbox cho tôi và hỏi như sau:

” Thấy anh chia sẻ kinh nghiệm thực hành BA nên em muốn nhờ anh tư vấn. Hiện tại em đang gặp phải vấn đề về requirement của sản phẩm của công ty. Em mới được tuyển vào một công ty phần mềm và đảm nhận công việc IT BA. Em được yêu cầu làm việc sớm đội kinh doanh để phát triển thêm một số tính năng mới và nâng cấp một số tính năng hiện có theo yêu cầu của khách hàng. Trước đây cty có 2 bạn BA và báo cáo trực tiếp cho sếp bên kinh doanh. Giờ cả hai đã nghỉ việc mà không để lại tài liệu gì nhiều. Hỏi các bạn Dev, quản lý của Dev thì mọi người khó chịu. Em rất bối rối và chưa biết bắt đầu từ đâu? Em chia sẻ em cũng mới làm BA được 1 năm nên còn non kinh nghiệm trong việc này. Rất mong nhận được phản hồi của anh”.

Hình ảnh lớp học Business Analysis in Practice tháng 2/2020 ở Hồ Chí Minh

Tương tác một hồi thì cũng hiểu thêm được bối cảnh:
– Đây là doanh nghiệp phát triển giải pháp CRM
– Quy trình phát triển phần mềm ngầm hiểu và linh hoạt (mỗi người hiểu một kiểu và linh hoạt sao cho hoàn thành việc mình là được). Quản lý không đưa ra chiến lược rõ ràng để quản lý yêu cầu phần mềm.
– BA không trực tiếp làm việc với khách hàng. Sales nhận yêu cầu rồi chuyển cho BA làm việc với Dev. Miễn sao đúng phần mềm được khách hàng chấp nhận là được.

Đây là tình huống ở các doanh nghiệp nhỏ, làm việc theo kiểu tự phát và nặng về cảm hứng. Hứng thì làm, không hứng thì đùn đẩy. Trước tiên để giải quyết vấn đề thì bạn cần làm:
– Trao đổi với quản lý về vấn đề hiện tại đang đối diện và cũng nói cho quản lý các hậu quả có thể diễn ra: thay đổi tính năng, lỗi cũ sẽ xuất hiện, phát triển tính năng mới thì có xu hướng mất động bộ với tính năng đang có trong việc tích hợp…
– Cần một chỉ thị của Sếp để xin ngồi làm việc với Sales và tập trung khơi gợi Sales chia sẻ lại quy trình làm việc trên sản phẩm hiện có.
– Mô hình hoá lại quy trình làm việc và các business rules.
– Cần một chỉ thị khác của Sếp để ngồi làm việc với Dev và tập trung verify lại với source code đã có.
– Quy trình, hay tính năng nào ưu tiên thì làm dứt điểm trước khi qua quy trình khác. Trong vòng 1-2 tuần em sẽ hình dung ngay được phần lõi của sản phẩm. Từ đó đắp thêm rất dễ dàng và có thể quản lý requirment được tốt hơn.

Thế đó, đây là lỗi của ông Sếp khi không thiết kế hệ thống làm việc tốt nền để xảy ra tình huống “người ra đi, know-how cũng đi theo người”.

Cao Trần,