Dự án phần mềm càng mơ hồ thì càng đắt. Đây không phải khẩu hiệu để dọa người mua, mà là cơ chế rất thực tế xảy ra mỗi ngày ở các dự án SME: mục tiêu chưa rõ, quy trình chưa chốt, dữ liệu chưa hiểu, người quyết định không mô tả đủ bài toán, nhưng vẫn muốn vào ngay giai đoạn build. Kết quả là chi phí không chỉ tăng ở phần lập trình, mà tăng ở mọi điểm: phân tích lại, sửa đi sửa lại, chờ quyết định, đổi ưu tiên, test lại và thậm chí phải làm lại từ đầu.
Nhiều founder non-tech nhìn bảng báo giá ban đầu và tưởng rằng đó là chi phí của sản phẩm. Thực ra, nếu bài toán chưa được làm rõ, báo giá ban đầu thường chỉ là giá để bắt đầu bước vào vùng mơ hồ. Từ đó trở đi, mỗi khoảng mờ trong yêu cầu sẽ biến thành một khoản chi phí mới dưới tên gọi khác nhau: change request, phát sinh, tích hợp thêm, UX sửa lại, logic nghiệp vụ đổi, dữ liệu chưa chuẩn, hoặc scope mở rộng ngoài dự kiến.
Dấu hiệu cho thấy dự án của bạn đang mơ hồ
- Bạn mô tả sản phẩm bằng tính năng bề mặt như “làm app quản lý”, “có dashboard”, “có phân quyền”, nhưng không nói rõ ai dùng, dùng lúc nào và để ra quyết định gì.
- Đội làm hỏi sâu hơn về quy trình thực tế thì câu trả lời thường là “để làm rồi tính tiếp”.
- Nhiều bên liên quan trong doanh nghiệp cùng góp ý nhưng không ai chốt ưu tiên cuối cùng.
- Bạn muốn “build bản cơ bản trước” nhưng chưa xác định rõ bản cơ bản phải giải quyết đúng vấn đề nào.
- Mỗi buổi trao đổi lại xuất hiện thêm use case mới, ngoại lệ mới hoặc phòng ban mới cần tham gia.
- Không có định nghĩa thành công cụ thể: tiết kiệm bao nhiêu thời gian, giảm bao nhiêu lỗi, tăng bao nhiêu đơn, hay bỏ được bước thủ công nào.
- Vendor hoặc đội nội bộ đã bắt đầu estimate nhưng đầu vào vẫn chỉ là vài ý tưởng rời rạc, chưa có scope rõ theo Level 3.
Vì sao founder non-tech và chủ SME hay bỏ qua vấn đề này
Có ba lý do rất phổ biến.
Thứ nhất, người mua phần mềm thường nhìn sản phẩm ở lớp giao diện, không nhìn ở lớp logic nghiệp vụ. Họ thấy một màn hình đăng nhập hay một form nhập liệu có vẻ đơn giản, nhưng không thấy toàn bộ luật xử lý phía sau: quyền ai được sửa, trường hợp ngoại lệ nào phải chặn, dữ liệu nào cần đồng bộ, báo cáo nào cần đúng theo ngữ cảnh kinh doanh.
Thứ hai, nhiều SME quen giải quyết việc bằng con người linh hoạt. Khi chuyển sang phần mềm, họ vô thức giả định rằng hệ thống cũng sẽ “linh hoạt như nhân viên lâu năm”. Nhưng phần mềm không thể đoán ý. Cái gì không được nói rõ thì hoặc bị bỏ sót, hoặc bị làm theo một giả định nào đó, và cả hai đều tạo ra chi phí.
Thứ ba, áp lực tốc độ khiến người mua tin rằng làm rõ bài toán là chậm. Trên thực tế, bỏ qua bước làm rõ chỉ chuyển thời gian suy nghĩ từ trước sang sau, và khi đưa sang giai đoạn build thì mỗi thay đổi sẽ đắt hơn nhiều lần vì kéo theo code, test, dữ liệu và phối hợp đội ngũ.
Cơ chế đội chi phí mà nhiều người không nhìn ra
Chi phí không tăng vì coder ngồi lâu hơn một chút. Chi phí tăng theo chuỗi.
- Mơ hồ tạo ra giả định. Khi brief chưa rõ, đội làm buộc phải tự điền vào chỗ trống bằng kinh nghiệm của họ.
- Giả định tạo ra lệch kỳ vọng. Sản phẩm được làm đúng theo giả định đó nhưng không đúng với vận hành thực tế của doanh nghiệp.
- Lệch kỳ vọng tạo ra sửa đổi. Khi demo hoặc UAT, người mua mới nhận ra “không phải cái mình cần”.
- Sửa đổi tạo ra scope trôi. Mỗi lần sửa không chỉ thêm một tính năng, mà thường chạm vào logic liên quan, dữ liệu liên quan và quy trình liên quan.
- Scope trôi làm estimate mất hiệu lực. Kế hoạch ban đầu không còn đúng, dẫn đến kéo tiến độ hoặc phát sinh ngân sách.
- Kéo tiến độ làm tăng chi phí cơ hội. Đội nội bộ phải họp nhiều hơn, chờ nhiều hơn, và cơ hội kinh doanh bị lỡ vì hệ thống chưa dùng được.
Điểm nguy hiểm là người mua thường chỉ thấy dòng phát sinh ở cuối, nhưng không thấy nguyên nhân gốc là brief chưa đủ rõ ngay từ đầu. Vì vậy họ tưởng vendor “đội giá”, trong khi thực chất dự án đang trả học phí cho sự mơ hồ của chính đầu vào.
Khung 7 câu hỏi để tự kiểm tra trước khi build
- Bài toán kinh doanh cụ thể là gì? Không phải “cần phần mềm quản lý”, mà là “đang mất gì, chậm ở đâu, sai ở bước nào”.
- Ai là người dùng chính và quyết định nào họ cần hỗ trợ? Mỗi nhóm người dùng phải gắn với hành vi và mục tiêu rõ ràng.
- Quy trình hiện tại đang chạy như thế nào, gồm ngoại lệ nào? Nếu quy trình ngoài đời chưa rõ, phần mềm sẽ không thể rõ.
- Phiên bản đầu tiên phải giải quyết được điều gì trong phạm vi hẹp? Đây là cách khóa scope để tránh biến MVP thành “làm luôn cả hệ thống”.
- Dữ liệu đầu vào lấy từ đâu, có sạch không, có ai chịu trách nhiệm không? Rất nhiều dự án trễ không vì code, mà vì dữ liệu và mapping dữ liệu.
- Tiêu chí nghiệm thu là gì? Nếu không có tiêu chí cụ thể, mỗi lần demo sẽ thành một vòng tranh luận cảm tính.
- Những gì chưa rõ hôm nay đã được ghi nhận thành danh sách cần làm rõ chưa? Câu hỏi này cực quan trọng để phân biệt giữa “đã biết là chưa rõ” và “chưa biết mình chưa rõ gì”.
Nếu bạn chưa trả lời được phần lớn các câu hỏi trên, khả năng cao dự án của bạn chưa nên bước vào build-commit brief theo nghĩa chốt ngân sách và timeline đầy đủ. Trước đó cần một giai đoạn làm rõ đủ sâu để đưa bài toán lên mức có thể estimate thực tế, tức gần với Level 3 về scope và đầu ra mong đợi.
Ví dụ thực tế ở một SME Việt Nam
Một doanh nghiệp phân phối muốn làm app cho đội sales thị trường. Brief ban đầu rất ngắn: check-in, tạo đơn hàng, xem công nợ, báo cáo doanh số. Nghe có vẻ đơn giản. Nhưng khi đi sâu mới lộ ra hàng loạt câu hỏi: một khách có nhiều điểm giao hàng hay không, giá bán có thay đổi theo khu vực hay chương trình khuyến mãi, đơn nợ xấu có được tạo tiếp không, đội giám sát có được sửa đơn hay chỉ duyệt, hàng đổi trả đi vào kho nào, doanh số tính theo thời điểm tạo đơn hay thời điểm xuất kho, dữ liệu công nợ lấy từ phần mềm kế toán nào, đồng bộ theo thời gian thực hay theo lô.
Nếu không làm rõ từ đầu, đội phát triển vẫn có thể build được một app “chạy được”. Nhưng đến lúc pilot, doanh nghiệp sẽ thấy hàng loạt điểm không dùng được ngoài thực tế. Khi đó, mỗi chỉnh sửa không còn là sửa giao diện, mà là sửa logic bán hàng, sửa phân quyền, sửa đồng bộ dữ liệu và sửa báo cáo. Chi phí vì thế tăng theo lớp, không tăng theo một dòng việc đơn lẻ.
Sai lầm phổ biến khiến scope trôi dần
- Nhầm giữa ý tưởng sản phẩm và đặc tả sản phẩm.
- Cho rằng vendor sẽ tự hiểu ngành của mình mà không cần bóc tách quy trình.
- Để quá nhiều người góp ý mà không có một người chốt cuối cùng.
- Vừa build vừa khám phá bài toán cốt lõi nhưng lại kỳ vọng báo giá cố định.
- Đồng ý làm “cho nhanh” những phần chưa rõ và hẹn xử lý sau.
- Không có build-commit brief đủ chặt để khóa phạm vi, giả định, tiêu chí nghiệm thu và phần loại trừ.
- Xem nhẹ bước chẩn đoán trước khi build, dù đây là nơi rẻ nhất để phát hiện sai.
Khi nào nên dừng để làm rõ trước khi build
Bạn nên tạm dừng việc chốt build nếu đang gặp một trong các tình huống sau: đội làm hỏi sâu nhưng câu trả lời còn cảm tính; mỗi lần họp lại đổi mục tiêu ưu tiên; chưa xác định được bản đầu tiên phải tạo ra kết quả kinh doanh nào; hoặc báo giá giữa các bên chênh nhau quá lớn vì mỗi bên đang hiểu một bài toán khác nhau.
Lúc đó, việc đúng hơn không phải là ép chọn vendor nhanh hơn, mà là quay lại làm rõ bài toán phần mềm. Một quy trình chẩn đoán như AI Tạo Phần Mềm có giá trị ở chỗ nó biến nhu cầu mơ hồ thành scope có thể kiểm chứng: mục tiêu, người dùng, quy trình, dữ liệu, giả định, phạm vi và tiêu chí nghiệm thu. Khi đầu vào đủ rõ, bạn mới có cơ sở để quyết định nên tự build, thuê ngoài, hay chia nhỏ thành từng giai đoạn hợp lý.
Kết luận ngắn gọn: đừng chỉ hỏi “build bao nhiêu tiền”. Hãy hỏi trước “mình đã hiểu đúng bài toán chưa”. Vì trong phần mềm, thứ đốt tiền nhanh nhất không phải là code khó, mà là sự mơ hồ được mang vào giai đoạn build.
