Hãy cùng chúng tôi đi vào phân tích một vài vấn đề sau.
Nghiệp vụ là gì?
Nghiệp vụ hiểu đơn giản là câu chuyện mà khách hàng muốn phần mềm phải tuân theo, và người dùng sử dụng sản phẩm cũng tuân theo nghiệp vụ được thiết kế đó.
Ai là người đưa ra nghiệp vụ?
Người thiết kế nghiệp vụ là người chủ sản phẩm: có thể là khách hàng, PO (product owner) của sản phẩm, hoặc do các chuyên gia hiểu biết trong lĩnh vực đó, hoặc đội phát triển đề xuất cho khách hàng ...
Nghiệp vụ có quan trọng không?
Đối với các sản phẩm phần mềm nhỏ, nghiệp vụ không quá phức tạp thì chúng ta có thể dễ dàng điều chỉnh trong quá trình phát triển và bảo trì. Tuy nhiên đối với các hệ thống lớn, đòi hỏi tính logic và chặt chẽ cao, nếu không xây dựng nghiệp vụ logic ngay từ đầu rất dễ dẫn đến những lỗ hổng.
Vậy các nguyên nhân gây ra lỗ hổng là gì?
- Nghiệp vụ thiếu chuyên môn: chưa nghĩ ra hết các case trong vấn đề, chỉ đưa vào những ý tưởng ban đầu nghĩ ra. Chưa có hiểu biết về sản phẩm, đưa ra những yêu cầu khó có thể thực hiện đối với đội phát triển.
Trong quá trình làm việc với khách hàng, có nhiều trường hợp khi sản phẩm đã đi đến giai đoạn cuối chuẩn bị go-live nhưng khách hàng muốn thay đổi luồng của sản phẩm. Điều này ảnh hưởng đến thiết kế kiến trúc của Database cũng như đội phát triển sẽ mất rất nhiều thời gian để sửa lại. Lúc đó khi không thỏa mãn được cả nghiệp vụ và nhóm phát triển buộc phải đưa ra phương án tạm thời, chắp vá.
- Tài liệu thiếu dữ kiện, chưa khai thác được hết ý tưởng của khách hàng: Việc này có thể dẫn đến việc thiếu yêu cầu, thiếu chức năng để hoàn chỉnh 1 hệ thống. Và việc một nghiệp vụ phải làm là khai thác triệt để từ khách hàng bằng nhiều phương pháp như tổ chức cuộc họp, viết câu hỏi gợi ý, khảo sát...
Chúng ta nên yêu cầu khách hàng "confirm" liên tục, thảo luận và trao đổi nhiều giúp thông suốt vấn đề và nhìn ra nhiều khía cạnh sản phẩm.
Lưu ý: Đối với các khách hàng Nhà nước, nghiệp vụ thường gắn liền với các nghị định, chính sách... Các quy trình nghiệp vụ này không dễ dàng mô hình hóa thành các tính năng phần mềm, phải trả qua một thời gian dài để thẩm định và phân tích tính khả thi. Trong nhiều trường hợp, quá trình mô hình hóa thất bại do nghiệp vụ quá phức tạp, thiếu hợp lý.
- Nghiệp vụ và đội phát triển không hiểu ý nhau: có thể dẫn đến sai từ thiết kế hệ thống, đến khi sản phẩm phát triển theo kiến trúc đó rồi thì khó có thể quay lại để điều chỉnh.
- Nhiều bên cùng thiết kế nghiệp vụ: Có trường hợp sản phẩm do cả bên nghiệp vụ và marketing cùng phát triển, tuy nhiên 2 bên không ngồi thống nhất với nhau mà tự thiết kế và truyền đạt lại cho đội phát triển. Và việc "conflict" (mâu thuẫn) trong tính năng là không thể tránh khỏi.
Vậy rủi ro đem lại là gì?
Như mình trình bày ở trên, mọi người có thể phần nào hình dung được những rủi ro đem lại. Nhóm phát triển sẽ rất đau đầu nếu hệ thống bị "đập đi làm lại" trong phương án xấu nhất, gây tổn thất về thời gian, tài sản, thậm chí cả tinh thần làm việc trong team.
Thí dụ với dự án cung cấp dịch vụ bán hàng, nếu nghiệp vụ quy trình sale không chặt chẽ dẫn đến nhân viên sale trong công ty đó lợi dụng kẽ hở để "đánh cắp" rất nhiều đơn hàng gây thiệt hại cho công ty. Sau đó khách hàng và đội phát triển phải ngồi lại và đưa ngay ra một giải pháp nghiệp vụ khác chặt chẽ hơn.
Bởi vậy, nghiệp vụ chính xác là nền tảng cho sản phẩm phát triển thuận lợi. Nhưng chúng ta cũng biết, việc yêu cầu thay đổi liên tục trong một dự án là điều không thể tránh khỏi và mong chờ một nghiệp vụ chuẩn chỉ có trong sách vở.
