Lỗ hổng nghiệp vụ và những rủi ro cho sản phẩm

Như chúng ta đã biết, bất kỳ một sản phẩm nào được thiết kế đều có nghiệp vụ riêng của nó. Đi từ nghiệp vụ đơn giản đến phức tạp, từ nghiệp vụ quen thuộc áp dụng trên toàn các sản phẩm đến các nghiệp vụ được xây dựng thiết kế riêng... Vậy chuyện gì xảy ra nếu chúng ta đi sai nghiệp vụ???

Cùng đi vào phân tích một vài vấn đề nhé !!!

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ế đó.

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 ...

Đố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.

- 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, mình từng gặp phải trường hợp khi sản phẩm đã đi đến giai đoạn cuối chuẩn bị golive nhưng nghiệp vụ 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ưng độ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à dev, chúng ta buộc phải đưa ra phương án tạm thời.

- 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 1 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.

- 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ụ: mình đã từng gặp 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 conflig (mâu thuẫn) trong tính năng là không thể tránh khỏi.

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. Anh em dev 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. 

Mình từng tham gia 1 dự án cung cấp dịch vụ bán hàng, do 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 1 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ờ 1 nghiệp vụ chuẩn không cần chỉnh cũng là một điều ước khá xa xỉ. 

Vì vậy để điều đó giảm thiểu rủi ro ít nhất có thể, chúng ta cần bỏ ra 1 lượng thời gian lớn để đầu tư vào nghiên cứu và thiết kế nghiệp vụ, đó hoàn toàn là việc đầu tư có ích cho 1 dự án.