Cần chuẩn bị gì trước một dự án phần mềm?
Một doanh nghiệp đang quản lý đơn hàng bằng Excel muốn xây hệ thống. Họ biết quy trình hiện tại mất nhiều thao tác, nhưng chưa có bản đặc tả hay danh sách tính năng. Liệu đã có thể trao đổi với đội phát triển?
Doanh nghiệp có thể trao đổi với đội phát triển từ những thông tin mình đang có. Tùy mục tiêu và quy mô dự án, mức độ chuẩn bị sẽ khác nhau; những gợi ý dưới đây giúp cuộc trao đổi ban đầu cụ thể hơn.
1. Bắt đầu từ vấn đề và mục tiêu
Trước khi bàn đến tính năng, doanh nghiệp nên mô tả công việc nào đang gặp khó khăn, những ai chịu ảnh hưởng và kết quả muốn cải thiện.
Chẳng hạn, nếu nhân viên phải nhập một đơn vào nhiều file và người quản lý khó theo dõi trạng thái xử lý, mục tiêu ban đầu có thể là tập trung thông tin đơn hàng và giảm thao tác nhập liệu lặp lại. Số liệu về thời gian xử lý hoặc số bước thủ công, nếu có, sẽ giúp mô tả tình trạng hiện tại cụ thể hơn. Nếu chưa đo lường, hai bên có thể xác định cách đánh giá khi làm rõ yêu cầu.
2. Mô tả quy trình và tài liệu đang sử dụng
Sau khi xác định vấn đề cần giải quyết, doanh nghiệp có thể tập hợp những tài liệu đang được dùng trong quy trình: file Excel, biểu mẫu, email trao đổi, hướng dẫn thao tác hoặc ảnh chụp màn hình hệ thống hiện tại. Các tài liệu này giúp đội dự án hình dung công việc đi qua những bước nào, ai thực hiện từng bước và thông tin được chuyển giữa các bộ phận ra sao.
Với quy trình đơn hàng, có thể mô tả từ lúc tiếp nhận yêu cầu đến khi đơn được xác nhận, xử lý và bàn giao cho bộ phận tiếp theo. Nếu một bước chỉ diễn ra qua email hoặc trao đổi trực tiếp, hãy ghi nhận cách bước đó được thực hiện. Như vậy, đội dự án hiểu được luồng công việc thay vì chỉ dựa vào một biểu mẫu riêng lẻ.
Tài liệu hiện tại giúp mô tả cách làm đang có; chúng chưa quyết định hệ thống mới sẽ được thiết kế như thế nào. Việc giữ, thay đổi hay bỏ một bước cần được xem xét cùng mục tiêu và nhu cầu của người sử dụng.
3. Chuẩn bị dữ liệu mẫu để làm rõ thông tin cần xử lý
Trong khi tài liệu ở mục trước giúp mô tả các bước công việc, dữ liệu mẫu giúp nhìn rõ từng bản ghi và các trường thông tin mà hệ thống cần xử lý. Chẳng hạn, một đơn hàng mẫu có thể gồm mã đơn, ngày tạo, mặt hàng, số lượng, trạng thái và bộ phận phụ trách.
Một vài bản ghi hoặc báo cáo mẫu cũng có thể giúp hai bên nhận ra những điểm cần xác minh: dữ liệu nào bắt buộc phải có, định dạng nào đang được dùng và thông tin nào cần xuất ra. Ví dụ, báo cáo theo dõi đơn hàng có thể cho thấy người quản lý cần xem trạng thái hoặc thời điểm cập nhật. Ý nghĩa và cách xử lý dữ liệu cần được xác nhận với người phụ trách nghiệp vụ.
Nếu chia sẻ dữ liệu thật, doanh nghiệp cần tuân theo quyền truy cập, chính sách bảo mật và quy định áp dụng. Khi phù hợp, có thể dùng dữ liệu giả lập hoặc mẫu đã ẩn thông tin nhạy cảm; cách xử lý nên được thống nhất trước khi gửi.
4. Ghi lại quy tắc nghiệp vụ và ngoại lệ
Bên cạnh cấu trúc dữ liệu, đội dự án còn cần hiểu những điều kiện chi phối cách xử lý công việc. Ví dụ, một doanh nghiệp có thể yêu cầu phê duyệt đơn hàng vượt ngưỡng do mình quy định, giới hạn quyền sửa giá theo vai trò hoặc xử lý khác nhau giữa đơn mới tạo và đơn đã chuyển sang kế toán. Những quy tắc này chỉ là ví dụ để minh họa loại thông tin cần làm rõ.
Doanh nghiệp nên ghi lại ai có thể thực hiện một thao tác, trong điều kiện nào và cách xử lý khi xuất hiện ngoại lệ. Nếu các bộ phận chưa thống nhất một quy tắc, điểm đó cần được ghi nhận để cùng giải quyết, thay vì để đội phát triển tự đưa ra giả định.
Để tìm hiểu cách chuyển những nhu cầu và điều kiện trên thành yêu cầu có thể thống nhất giữa các bên, xem bài liên quan:
5. Xác định hệ thống liên quan
Sau khi mô tả quy trình bên trong, doanh nghiệp cũng cần cho biết phần mềm mới có phải trao đổi dữ liệu với hệ thống kế toán, CRM hoặc công cụ nội bộ hay không. Danh sách hệ thống liên quan, loại thông tin cần trao đổi và người phụ trách từng hệ thống là những đầu vào hữu ích.
Với quy trình đơn hàng, một câu hỏi cần làm rõ là bộ phận kế toán nhận thông tin sau khi đơn được xác nhận bằng cách nào: qua file, qua thao tác nhập lại hay qua một kết nối sẵn có. Nhu cầu trao đổi dữ liệu không đồng nghĩa với khả năng tích hợp tự động; khả năng này phải được đánh giá dựa trên quyền truy cập, tài liệu kỹ thuật và giới hạn của các hệ thống thực tế.
6. Ràng buộc dự án và quyết định kỹ thuật
Thời hạn, ngân sách, hạ tầng, thiết bị, chính sách bảo mật, yêu cầu lưu trữ dữ liệu và tiêu chuẩn kỹ thuật nội bộ đều có thể ảnh hưởng đến phạm vi dự án. Nếu có yêu cầu tuân thủ áp dụng, doanh nghiệp nên nêu để đội dự án cùng xem xét.
Khi trao đổi, nên phân biệt điều bắt buộc, điều được ưu tiên và điều chưa quyết định. Chẳng hạn, thời điểm cần đưa hệ thống vào sử dụng có thể là giới hạn bắt buộc, còn một báo cáo nâng cao có thể chỉ là mong muốn. Nếu ngân sách chưa được phê duyệt, hãy nói rõ tình trạng hiện tại để hai bên đánh giá phạm vi phù hợp.
Những thông tin này cũng là cơ sở để xem xét giải pháp kỹ thuật. Doanh nghiệp không cần tự chọn kiến trúc, cơ sở dữ liệu hay công nghệ triển khai; đội dự án cần đánh giá chúng theo mục tiêu, yêu cầu, tích hợp, bảo mật, vận hành và giới hạn đã biết. Nếu công ty đã có nền tảng bắt buộc, hãy nêu đó như một điều kiện đầu vào.
7. Checklist trước buổi trao đổi
Có thể ghi lại những thông tin đã biết theo danh sách ngắn dưới đây. Các mục chưa rõ có thể trở thành câu hỏi cho buổi trao đổi:
☐ Vấn đề cần giải quyết, người liên quan và kết quả mong muốn
☐ Quy trình hiện tại cùng tài liệu hoặc dữ liệu mẫu có thể chia sẻ
☐ Quy tắc nghiệp vụ và hệ thống cần phối hợp
☐ Thời hạn, ngân sách, chính sách và giới hạn đã biết
Danh sách này không cần phải hoàn chỉnh trước khi bắt đầu. Mục tiêu buổi trao đổi là xác định điều gì đã rõ, điều gì cần xác minh và bước phân tích phù hợp tiếp theo.
8. Kết luận
Khi chuẩn bị cho một dự án phần mềm, hãy bắt đầu từ bài toán kinh doanh và quy trình hiện tại; tài liệu, mẫu dữ liệu và các ràng buộc giúp hai bên hiểu rõ hơn công việc cần hỗ trợ. Tại Fenix, thông tin ban đầu được dùng để cùng khách hàng làm rõ phạm vi và yêu cầu trước khi đi sâu vào thiết kế và lựa chọn kỹ thuật. Nếu doanh nghiệp đang cân nhắc xây mới hoặc thay thế hệ thống, có thể bắt đầu bằng một cuộc trao đổi về tình huống thực tế.
