Gia công phần mềm theo yêu cầu: quy trình, phạm vi và rủi ro

Gia công phần mềm theo yêu cầu là việc đặt một đơn vị bên ngoài xây dựng hệ thống may đo theo phạm vi và tiêu chí nghiệm thu đã viết thành văn bản. Kiểm soát chi phí nằm ở việc viết đủ bốn loại câu phạm vi và đặt cổng nghiệm thu sau mỗi giai đoạn.

Tóm tắt nhanh

• Phạm vi tốt có bốn loại câu: trong phạm vi, ngoài phạm vi, giả định và phụ thuộc. Thiếu loại nào cũng sinh tranh chấp.
• Chia dự án thành bốn giai đoạn Khám phá → Đặc tả → Xây dựng → Bàn giao và đo lường, mỗi giai đoạn có một cổng nghiệm thu riêng.
• Một yêu cầu thay đổi phải được tính bằng ba phần: nỗ lực làm, nỗ lực kiểm thử lại, và nỗ lực làm lại phần đã xong.
• Rủi ro lớn nhất của gia công theo yêu cầu không phải giá mà là phạm vi trôi và tri thức vận hành không được chuyển giao.

Gia công phần mềm theo yêu cầu là gì

Gia công phần mềm theo yêu cầu là một hợp đồng theo kết quả, trong đó doanh nghiệp mô tả bài toán nghiệp vụ và đối tác chịu trách nhiệm biến mô tả đó thành hệ thống chạy được. Sản phẩm không phải một gói có sẵn được cấu hình, mà là một hệ thống được xây cho đúng quy trình của bạn.

Ba đặc điểm phân biệt nó với mua phần mềm đóng gói:

1. Phạm vi do bạn mô tả, không do nhà sản xuất định nghĩa trước.
2. Nghiệm thu theo tiêu chí bạn đồng ý, không theo danh sách tính năng của một phiên bản.
3. Quyền sở hữu phải được chuyển giao rõ ràng, vì hệ thống được tạo ra theo đơn đặt hàng.

Đặc điểm thứ ba là điểm khác biệt lớn nhất về mặt pháp lý, và cũng là điểm hay bị bỏ sót nhất khi doanh nghiệp lần đầu mua phần mềm may đo.

Vì sao "theo yêu cầu" không có nghĩa là "làm gì cũng được"

Cụm "theo yêu cầu" dễ bị hiểu thành một thoả thuận mở: bạn yêu cầu gì thì đối tác làm nấy. Cách hiểu đó dẫn thẳng tới hai kết cục xấu. Một là đối tác báo giá cho một phạm vi rất hẹp để giữ giá thấp, rồi mọi yêu cầu thực tế đều thành phát sinh. Hai là bạn liên tục bổ sung yêu cầu, tiến độ trượt, và cuối cùng cả hai bên đều mất niềm tin.

Trong thực tế, "theo yêu cầu" nghĩa là phạm vi được viết ra trước khi làm, và mọi thay đổi sau đó đi qua một quy trình có chi phí nhìn thấy được. Đây là điều phân biệt một dự án may đo chuyên nghiệp với một thoả thuận miệng.

Bốn loại câu phải có trong một bản phạm vi

Hầu hết bản phạm vi chỉ có một loại câu: "hệ thống phải làm được X". Đó là lý do phần lớn tranh chấp phát sinh ở những chỗ không ai viết. Một bản phạm vi dùng được phải có đủ bốn loại câu dưới đây.

Một ví dụ về câu phạm vi viết đúng và viết sai

Câu viết sai: "Chức năng quản lý đơn hàng hoạt động tốt." Câu này không có đối tượng kiểm tra, không có điều kiện, không có kết quả quan sát được.

Câu viết đúng: "Khi nhân viên bán hàng tạo đơn có tổng giá trị vượt hạn mức tín dụng của khách, hệ thống chặn lưu đơn, hiển thị hạn mức còn lại và cho phép quản lý duyệt ghi đè có lưu vết người duyệt." Câu này mô tả một hành vi có thể kiểm tra bằng cách làm thử, và có thể viết thành một ca kiểm thử tự động.

Sự khác biệt không nằm ở độ dài mà ở chỗ câu thứ hai có thể chứng minh đúng hoặc sai. Đây là tiêu chuẩn bạn nên áp cho mọi dòng trong bản phạm vi.

Giả định là phần dễ bị bỏ nhất

Giả định là những điều bạn tin là đúng nhưng chưa kiểm chứng, ví dụ: dữ liệu cũ sạch, người dùng có tài khoản email công ty, hệ thống hiện tại có API, hoặc phần cứng đã được mua. Mỗi giả định sai đều trở thành phát sinh, và thường là phát sinh đắt vì nó xuất hiện muộn.

Cách xử lý thực dụng: liệt kê giả định thành một bảng riêng, mỗi dòng ghi rõ ai kiểm chứng và kiểm chứng trước giai đoạn nào. Giả định chưa kiểm chứng không được phép bước vào giai đoạn xây dựng.

Quy trình bốn giai đoạn và cổng nghiệm thu

Một dự án gia công phần mềm theo yêu cầu nên đi qua bốn giai đoạn có tên gọi rõ ràng. Mỗi giai đoạn kết thúc bằng một cổng: nếu đầu ra không đạt, dừng lại và sửa, thay vì đi tiếp với một nền móng lỗi.

Giai đoạn Khám phá: chốt vấn đề trước khi bàn giải pháp

Mục tiêu của giai đoạn này không phải viết tài liệu mà là thống nhất vấn đề. Đầu ra gồm sơ đồ quy trình hiện tại, danh sách người sẽ dùng hệ thống, các điểm nghẽn cụ thể và ba chỉ số nền để so sánh về sau.

Điều bạn nên đòi: một bản tóm tắt vấn đề bằng ngôn ngữ nghiệp vụ, có tên người xác nhận. Nếu bản tóm tắt không dùng được từ nào của bạn, đối tác chưa hiểu bài toán.

Giai đoạn Đặc tả: biến hiểu biết thành thứ kiểm tra được

Đây là giai đoạn quyết định chi phí của toàn dự án. Đầu ra gồm danh mục yêu cầu chức năng, ngưỡng phi chức năng và bộ ca kiểm thử nghiệm thu cho từng luồng chính. Ngưỡng phải cụ thể: "báo cáo công nợ mười hai tháng của năm nghìn khách trả kết quả dưới ba giây và không chặn thao tác khác" là yêu cầu, còn "nhanh" thì không.

Một dấu hiệu đặc tả chưa đủ: bạn không tìm được ca kiểm thử nào cho một yêu cầu. Khi đó yêu cầu đó chưa sẵn sàng để xây.

Giai đoạn Xây dựng: đo tiến độ bằng bản dựng, không bằng báo cáo

Trong giai đoạn này, tiến độ phải nhìn thấy được qua sản phẩm chạy trong môi trường thử. Đầu ra gồm kho mã, bộ kiểm thử tự động chạy trong quy trình tích hợp, và một bản dựng có dữ liệu mẫu.

Điều bạn nên đòi: quyền vào môi trường thử và một buổi demo theo lịch cố định, có biên bản người xác nhận. Nếu tiến độ chỉ tồn tại trong tin nhắn, bạn đang quản lý dự án bằng lời kể.

Giai đoạn Bàn giao và đo lường: cổng là một ca vận hành thật

Giai đoạn này kết thúc khi đội của bạn tự chạy được hệ thống mà không cần gọi đối tác. Đầu ra gồm runbook vận hành, danh sách tài khoản bàn giao, và bảng chỉ số theo dõi sau ra mắt.

Cổng của giai đoạn này không phải một buổi demo mà là một ca vận hành thật do đội của bạn chạy: nhận một yêu cầu từ người dùng, xử lý đến khi ra kết quả, và ghi lại thời gian xử lý. Đối tác chỉ được đứng quan sát. Nếu trong ca đó phải gọi đối tác để hỏi cách chạy, cổng chưa đạt — và đó chính là thông tin cần cho phạm vi giai đoạn sau.

Quản lý thay đổi: tính đúng ba phần nỗ lực

Phạm vi trôi là rủi ro số một của gia công theo yêu cầu, và nó không xảy ra bằng một yêu cầu lớn mà bằng nhiều yêu cầu nhỏ. Mỗi yêu cầu nhỏ đều có vẻ "chỉ thêm một chút", và tổng của chúng thường vượt xa phần dự phòng.

Một yêu cầu thay đổi phải được tính bằng ba phần, không phải một:

1. Nỗ lực làm phần mới. Viết mã, viết kiểm thử, cập nhật tài liệu.
2. Nỗ lực kiểm thử lại phần liên quan. Thay đổi một luồng thường ảnh hưởng tới các luồng dùng chung dữ liệu.
3. Nỗ lực làm lại phần đã xong. Nếu thay đổi đến sau khi phần liên quan đã nghiệm thu, một phần công việc phải làm lại.

Một ví dụ minh hoạ

Giả sử một luồng nghiệp vụ được ước lượng 10 đơn vị nỗ lực và đã hoàn thành. Sau đó khách hàng yêu cầu thêm một bước duyệt trước khi lưu. Cách tính đúng không phải 2 đơn vị cho bước duyệt mới, mà gồm:

Con số này là mô hình minh hoạ để bạn thấy cấu trúc, không phải đơn giá. Điều đáng nhớ: một thay đổi "nhỏ" có thể tốn gấp ba lần phần mới, vì chi phí thật nằm ở phần bị ảnh hưởng.

Vì sao thay đổi muộn đắt hơn thay đổi sớm

Cùng một yêu cầu, nếu đặt ở giai đoạn khám phá thì gần như miễn phí: nó chỉ là một dòng trong bản đặc tả. Nếu đặt ở giai đoạn đặc tả, nó là một buổi làm việc. Nếu đặt sau khi đã kiểm thử, nó là một vòng làm lại. Nếu đặt sau khi đã bàn giao, nó là một dự án nhỏ.

Đây là lý do cổng nghiệm thu theo giai đoạn không phải thủ tục hành chính mà là công cụ kiểm soát chi phí. Mỗi cổng là một cơ hội sửa sai với giá thấp nhất.

Rủi ro thường gặp và cách phát hiện sớm

Dòng cuối đáng chú ý: nếu hợp đồng không quy định thời hạn phản hồi nghiệm thu, một bên có thể trì hoãn vô thời hạn. Một điều khoản hợp lý là: sau khi bàn giao bản dựng để nghiệm thu, nếu không có phản hồi trong một số ngày làm việc nhất định thì được coi là chấp thuận, trừ khi có lỗi nghiêm trọng được ghi nhận bằng văn bản.

Khi nào phạm vi cố định là lựa chọn sai

Gia công theo yêu cầu với phạm vi cố định chỉ hiệu quả khi bạn mô tả được kết quả. Trong bốn tình huống sau, ép phạm vi cố định sẽ tạo ra vấn đề lớn hơn là giải quyết.

1. Bài toán còn đang được khám phá. Nếu bạn chưa biết quy trình nào cần thay đổi, hãy ký giai đoạn khám phá riêng, có đầu ra rõ, rồi mới quyết định phạm vi xây dựng.
2. Yêu cầu phụ thuộc vào phản hồi thị trường. Khi sản phẩm cần thử với người dùng thật để biết nên làm gì tiếp, phạm vi cố định sẽ khoá bạn vào giả định ban đầu.
3. Dữ liệu cũ chưa được khảo sát. Chất lượng dữ liệu là yếu tố chi phí lớn và chỉ biết được sau khi kiểm tra. Ký phạm vi cố định trước khi khảo sát là chuyển rủi ro cho đối tác, và họ sẽ định giá rủi ro đó.
4. Không có người đại diện sản phẩm. Phạm vi cố định cần một người xác nhận phạm vi và nghiệm thu. Không có người đó, mọi cổng nghiệm thu đều bị trì hoãn.

Với ba tình huống đầu, cách làm phù hợp hơn là chia dự án thành các đợt nhỏ, mỗi đợt có phạm vi cố định riêng. Bạn vẫn có cam kết về kết quả, nhưng không phải cam kết cho một phạm vi bạn chưa đủ thông tin để viết.

Nếu bạn cần so sánh cấu trúc chi phí của các cách ký khác nhau, bài chi phí phát triển phần mềm trình bày sáu yếu tố quyết định giá. Bài dịch vụ gia công phần mềm là gì giúp bạn tách gói dịch vụ thành các đơn vị bàn giao, còn bài gia công phần mềm là gì giúp bạn chọn đúng mô hình trước khi viết phạm vi.

Câu hỏi thường gặp

Gia công phần mềm theo yêu cầu khác gì mua phần mềm đóng gói?

Phần mềm đóng gói là sản phẩm đã tồn tại, bạn mua quyền dùng và cấu hình trong giới hạn nhà sản xuất cho phép. Gia công theo yêu cầu là xây một hệ thống chưa tồn tại, theo quy trình của bạn, với phạm vi và tiêu chí nghiệm thu do hai bên viết. Hệ quả là chi phí thay đổi và quyền sở hữu khác nhau hoàn toàn.

Phạm vi nên chi tiết đến mức nào?

Đủ chi tiết để mỗi yêu cầu viết được thành ít nhất một câu kiểm tra có đối tượng, điều kiện và kết quả quan sát được. Không cần mô tả cách triển khai kỹ thuật, vì đó là phần đối tác quyết định. Nếu bạn bắt đầu chỉ định bảng dữ liệu hay thư viện, bạn đã nhận lại rủi ro kỹ thuật mà không nhận lại năng lực tương ứng.

Một yêu cầu thay đổi nên được báo giá thế nào?

Nên tách thành ba phần: nỗ lực làm phần mới, nỗ lực kiểm thử lại phần liên quan và nỗ lực làm lại phần đã nghiệm thu. Cách tính chỉ gồm phần mới sẽ bỏ sót chi phí lớn nhất. Hợp đồng nên có mẫu yêu cầu thay đổi với ba dòng này để hai bên thống nhất trước khi làm.

Làm sao biết dự án đang trôi phạm vi?

Ba dấu hiệu: số yêu cầu thay đổi tăng dần mỗi tuần, các buổi demo không có bản dựng mới, và tài liệu đặc tả không được cập nhật sau khi thay đổi được chấp thuận. Khi cả ba xuất hiện cùng lúc, dự án đã trôi và cần dừng lại để chốt lại phạm vi trước khi tiếp tục.

Cập nhật và kiểm chứng

Cập nhật tháng 10/2026. Nội dung được rà soát theo thông lệ quản lý phạm vi và nghiệm thu trong các dự án phát triển phần mềm theo yêu cầu.

Nếu bạn đang chuẩn bị một dự án may đo, WinSell xây dựng phần mềm theo yêu cầu theo bốn giai đoạn Khám phá, Đặc tả, Xây dựng, Bàn giao và đo lường, với cổng nghiệm thu ở từng giai đoạn — xem dịch vụ của WinSell để biết đầu ra của mỗi cổng. Báo giá sau khi chốt phạm vi.