Từ quy trình thực tế đến phần mềm: Bắt đầu từ đâu?

Thay vì bắt đầu bằng câu “chúng tôi cần một hệ thống quản lý”, hãy bắt đầu bằng một tình huống xảy ra trong công việc hằng ngày. Ai đang làm gì, ở thời điểm nào, họ cần thông tin gì và đâu là điểm khiến công việc bị chậm hoặc khó kiểm soát?

Ví dụ, với quy trình xử lý đơn hàng, một mô tả cụ thể có thể là: nhân viên kinh doanh nhận đơn, kiểm tra tồn kho, xác nhận với khách hàng, chuyển yêu cầu cho kho và theo dõi trạng thái giao hàng.

Cách mô tả này giúp đội dự án nhìn thấy một chuỗi hành động thực tế thay vì một yêu cầu quá rộng. Từ đó, các câu hỏi tiếp theo cũng rõ hơn: bước nào đang làm thủ công, thông tin nào cần hiển thị và ai cần quyền thao tác ở từng giai đoạn.

Mức độ hữu ích của phần mềm phụ thuộc một phần vào việc nó có hỗ trợ đúng nhu cầu và quy trình thực tế hay không. Vì vậy, trước khi liệt kê chức năng, doanh nghiệp nên xem lại luồng công việc và xác định những vai trò tham gia ở từng bước.

Trong ví dụ xử lý đơn hàng, nhân viên kinh doanh, bộ phận kho, kế toán và quản lý có thể cùng sử dụng hệ thống nhưng với nhu cầu khác nhau. Người bán hàng cần biết tồn kho và trạng thái đơn; kho cần biết đơn nào phải chuẩn bị; quản lý cần nhìn tổng quan tiến độ và các trường hợp bất thường.

Việc tách rõ vai trò giúp xác định nhóm người dùng nào cần xem hoặc thao tác với loại thông tin nào. Quyền truy cập và nội dung hiển thị cần được thiết kế theo yêu cầu nghiệp vụ, bảo mật và trách nhiệm của từng vai trò, thay vì mặc định một giao diện giống nhau cho tất cả người dùng.

Khi luồng nghiệp vụ đã được mô tả rõ hơn, từng bước trong quy trình có thể cung cấp đầu vào để xác định các chức năng cần xem xét. Đây là một trong những bước chuyển từ ý tưởng kinh doanh sang nội dung có thể tiếp tục phân tích, thiết kế và phát triển.

Chẳng hạn, từ bước “kiểm tra tồn kho trước khi xác nhận đơn”, hệ thống có thể cần hiển thị số lượng khả dụng theo sản phẩm, cập nhật sau mỗi giao dịch và cảnh báo khi tồn kho không đủ.

Từ bước “chuyển đơn cho kho”, có thể phát sinh các chức năng như thay đổi trạng thái, phân công người xử lý, ghi lại thời gian cập nhật hoặc gửi thông báo cho bộ phận liên quan.

Điểm quan trọng là mỗi chức năng đều cần gắn với một bước hoặc nhu cầu cụ thể trong quy trình. Nếu chưa chỉ ra được chức năng đó hỗ trợ ai và ở thời điểm nào, có thể nó chưa cần nằm trong phạm vi đầu tiên.

Phân tích yêu cầu là gì?

Chức năng chỉ là phần dễ nhìn thấy. Để hệ thống vận hành đúng, doanh nghiệp còn phải làm rõ dữ liệu nào cần được lưu và những quy tắc nào quyết định cách hệ thống xử lý.

Ví dụ, một đơn hàng có thể cần thông tin khách hàng, sản phẩm, số lượng, người phụ trách, trạng thái thanh toán và trạng thái giao hàng. Mỗi loại dữ liệu lại cần xác định ai được xem, ai được sửa và khi nào được cập nhật.

Bên cạnh đó là các quy tắc nghiệp vụ. Đơn hàng có được xác nhận khi tồn kho chưa đủ không? Ai có quyền hủy đơn? Khi nào hệ thống gửi cảnh báo? Trường hợp nào cần quản lý phê duyệt?

Những câu hỏi này là đầu vào quan trọng để xác định logic xử lý của hệ thống. Nếu còn điểm chưa rõ, các giả định cần được ghi nhận và tiếp tục xác nhận trong quá trình phân tích, thiết kế hoặc phát triển, tùy cách triển khai dự án.

Khi bắt đầu mô tả quy trình, doanh nghiệp thường phát hiện rất nhiều nhu cầu có thể đưa vào hệ thống. Tuy nhiên, không phải tất cả đều cần xuất hiện trong phiên bản đầu tiên.

Một cách thực tế là tách chức năng thành hai nhóm: phần bắt buộc để quy trình chính hoạt động và phần có thể bổ sung sau. Với hệ thống đơn hàng, việc tạo đơn, kiểm tra tồn kho, cập nhật trạng thái và theo dõi xử lý có thể là phần cốt lõi; báo cáo nâng cao hoặc tùy chỉnh sâu có thể để lại cho giai đoạn tiếp theo.

Phạm vi phiên bản đầu tiên được làm rõ có thể hỗ trợ việc ước tính thời gian, chi phí và phạm vi kiểm thử. Nếu dự án được chia thành các giai đoạn phù hợp, doanh nghiệp cũng có thể kiểm chứng một phần giải pháp trước khi mở rộng sang các phạm vi tiếp theo.

Phần mềm có sẵn hay phát triển riêng?

Mức độ đặc tả cần có trước khi trao đổi hoặc bắt đầu phát triển phụ thuộc vào loại dự án, phương pháp triển khai và các ràng buộc liên quan. Trước khi đi sâu vào thiết kế và phát triển, những thông tin ảnh hưởng trực tiếp đến phạm vi đang xử lý cần được làm rõ ở mức phù hợp để hạn chế các giả định không được kiểm chứng.

Những câu hỏi thường cần được làm rõ gồm: ai sẽ sử dụng hệ thống, quy trình chính diễn ra như thế nào, dữ liệu quan trọng là gì, các quy tắc bắt buộc nào cần tuân theo và phạm vi đang xem xét cần giải quyết điều gì.

Khi các yếu tố này được làm rõ ở mức phù hợp, đội dự án có thêm cơ sở để phân tích yêu cầu chi tiết, thiết kế giao diện, xác định cấu trúc dữ liệu và ước tính phạm vi. Mức độ làm rõ vẫn có thể tiếp tục thay đổi trong các phương pháp phát triển lặp.

Tại Fenix, giai đoạn đầu tập trung vào việc chuyển bối cảnh nghiệp vụ thành một cấu trúc đủ rõ để đội kỹ thuật có thể tiếp tục. Mục tiêu không phải là yêu cầu khách hàng chuẩn bị sẵn mọi chi tiết, mà là cùng làm rõ những thông tin cần thiết trước khi bước vào phát triển.

Xem dịch vụ phát triển hệ thống của Fenix

Biến một quy trình nghiệp vụ thành phần mềm không phải là việc chuyển thẳng từ ý tưởng sang danh sách chức năng. Trước hết cần hiểu tình huống sử dụng, người dùng, luồng công việc, dữ liệu và những quy tắc chi phối cách công việc diễn ra.

Khi các yếu tố này được làm rõ, đội dự án có thêm cơ sở để xác định chức năng và phạm vi phiên bản đầu tiên, đồng thời liên kết từng phần của giải pháp với người dùng và nghiệp vụ mà nó cần hỗ trợ.