Vì sao dự án thường chậm lại sau khi đã bắt đầu phát triển — và requirement definition tốt giúp ngăn rework như thế nào

Rất nhiều dự án phần mềm không thất bại ở giai đoạn đầu.

Chúng bắt đầu gặp vấn đề sau khi việc phát triển đã được khởi động.

Ban đầu, mọi thứ thường trông khá tích cực:

• kickoff đã xong
• team đã bắt đầu implement
• task đã được assign
• tiến độ có vẻ đang chạy

Nhưng chỉ vài tuần sau, dự án bắt đầu chậm lại.

Câu hỏi tăng lên.
Specification liên tục thay đổi.
Developer phải chờ confirm.
QA phát hiện nhiều điểm chưa được định nghĩa rõ.
Khách hàng cảm thấy output “chưa đúng như kỳ vọng”.
Và rồi rework bắt đầu.

Đây là một pattern rất phổ biến trong system development.

Và trong nhiều trường hợp, vấn đề không nằm ở năng lực kỹ thuật yếu.

Vấn đề nằm ở requirement definition yếu.

Khi requirement chưa rõ, chưa đủ, hoặc chưa được align tốt giữa các bên liên quan, dự án có thể bắt đầu rất nhanh — nhưng sẽ chậm lại về sau, khi chi phí thay đổi đã tăng lên.

Đó là lý do vì sao upstream work lại quan trọng hơn nhiều người nghĩ.

Vì sao dự án thường chậm lại sau khi đã bắt đầu phát triển

1. Team bắt đầu build khi các quyết định quan trọng chưa ổn định

Trong nhiều dự án, coding bắt đầu khi vẫn còn nhiều điểm quan trọng chưa được chốt.

Ví dụ:

• hành vi cụ thể của màn hình
• business rule chưa đầy đủ
• edge case chưa rõ
• luồng phê duyệt chưa thống nhất
• cách xử lý lỗi chưa định nghĩa
• data definition chưa đồng nhất

Ở giai đoạn đầu, team vẫn có thể tiếp tục bằng cách tự đặt giả định.

Nhưng về sau, những giả định đó sẽ trở thành xung đột.

Khi quyết định bị trì hoãn, dự án không hề nhanh hơn. Nó chỉ đang đẩy sự không chắc chắn vào giai đoạn development.

Và sự không chắc chắn đó thường quay trở lại dưới dạng rework.

2. Các stakeholder đang hình dung các kết quả khác nhau

Một vấn đề rất thường gặp trong các dự án business system là mọi người dùng cùng một từ, nhưng lại tưởng tượng ra những kết quả khác nhau.

Ví dụ:

• approval flow
• completed order
• urgent case
• admin user
• support status

Những cụm từ này nghe có vẻ đơn giản, nhưng nếu dự án không định nghĩa rõ, mỗi bên sẽ hiểu theo một cách khác nhau.

Business team nghĩ theo operation.
Designer nghĩ theo screen.
Developer nghĩ theo logic và data.
QA nghĩ theo test condition.

Nếu không align, mỗi role sẽ đi theo một hướng khác nhau, dù tưởng rằng họ đang làm cùng một thứ.

Đó là lúc dự án bắt đầu bị lệch.

3. Càng đổi requirement sau khi implement, chi phí càng lớn

Sửa requirement trên tài liệu thì rẻ.

Nhưng sửa nó sau khi code, test case, và UI behavior đã được build thì đắt hơn nhiều.

Chi phí đó còn tăng mạnh hơn nếu:

• các function liên quan đã được implement
• API đã kết nối xong
• QA đã bắt đầu test
• khách hàng đã bước vào review

Đó là lý do vì sao requirement mơ hồ ở đầu dự án thường tạo áp lực lớn về schedule và cost ở giai đoạn sau.

Team không chỉ đang sửa một ý tưởng.
Họ đang sửa toàn bộ những thứ đã bám vào ý tưởng đó.

4. QA bị buộc phải đi tìm requirement còn thiếu

QA nên dùng requirement để kiểm tra xem implementation có đúng không.

Nhưng khi requirement yếu, QA bị đẩy vào một vai trò khác:
đi phát hiện xem requirement lẽ ra phải là gì.

Điều đó không hiệu quả.

Nó dẫn tới:

• vòng clarify lặp đi lặp lại
• acceptance criteria thiếu ổn định
• khó phân biệt bug và change request
• review cycle kéo dài
• căng thẳng giữa khách hàng và team delivery

Một dự án sẽ trôi chảy hơn rất nhiều khi QA làm việc trên một target đã được định nghĩa rõ.

5. Tiến độ có vẻ nhìn thấy được, nhưng độ chắc chắn lại yếu đi

Đây là một trạng thái rất nguy hiểm.

Team trông bận rộn.
Task vẫn đang chạy.
Screen vẫn đang được build.
API vẫn đang được nối.

Vì vậy mọi người cảm thấy dự án đang tiến lên.

Nhưng nếu nền móng requirement yếu, activity nhìn thấy được không đồng nghĩa với certainty thật sự.

Thậm chí, có những dự án càng chạy nhanh lúc đầu thì càng rủi ro hơn, vì requirement baseline chưa được align đủ.

Khoảng trống càng được phát hiện muộn, chi phí càng cao.

Một bản requirement definition tốt cần có gì

Một tài liệu requirement definition tốt không chỉ là danh sách chức năng.

Nó cần giúp giảm ambiguity và tạo shared understanding trước khi đi sâu vào implementation.

Một bản requirement definition tốt thường làm rõ được các điểm sau:

1. Scope và non-scope

Team không chỉ cần biết cái gì nằm trong phạm vi, mà còn phải biết cái gì không nằm trong phạm vi.

Điều này giúp ngăn các giả định âm thầm phình ra trong suốt dự án.

2. Business flow

Dự án cần làm rõ người dùng, dữ liệu, và các quyết định đi qua quy trình như thế nào.

Không có business flow, các feature thường bị rời rạc.

3. Role và permission logic

Rất nhiều vấn đề phát sinh từ việc role không rõ.

Ai được xem gì?
Ai được approve gì?
Ai được sửa, huỷ, hay override?

Những điểm này nên được thống nhất từ sớm.

4. Main case và exception case

Team thường mô tả normal flow, nhưng lại bỏ qua các điều kiện bất thường.

Trong thực tế, hệ thống thường fail ở edge case:

• request trùng lặp
• thiếu input
• timeout
• status chuyển sai
• xử lý dở dang
• approval bị từ chối

Nếu các case này không được định nghĩa sớm, chúng sẽ quay lại về sau dưới dạng bug hoặc rework.

5. Acceptance criteria

Một feature không phải là “done” chỉ vì nó đã được code.

Nó chỉ thật sự done khi hai bên cùng đồng ý:

• điều gì phải xảy ra
• trong điều kiện nào
• output mong đợi là gì
• thế nào mới được coi là thành công

Đó là lý do acceptance criteria nên được viết ra trước khi implementation đi quá sâu.

Requirement definition không phải là giấy tờ cho có

Một số team xem requirement definition như paperwork làm chậm delivery.

Nhưng trên thực tế, requirement definition kém làm chậm delivery nhiều hơn bất kỳ tài liệu tốt nào từng làm.

Mục tiêu của requirement definition không phải là tạo thêm file.

Mục tiêu là giảm:

• khoảng trống giả định
• thay đổi không cần thiết
• chậm quyết định
• sự lẫn lộn trong QA
• rủi ro delivery

Upstream tốt giúp downstream chạy nhanh hơn.

Đó không phải bureaucracy.
Đó là project discipline.

Cách thực tế để cải thiện chất lượng requirement

Team không cần tài liệu hoàn hảo ngay từ đầu.

Nhưng họ cần đủ cấu trúc để ambiguity không lan rộng.

Một cách làm thực tế gồm:

1. Làm rõ business terms từ sớm
   Định nghĩa key term trước khi bàn tới screen hay API.
2. Tách confirmed item và open item
   Không trộn assumption với approved decision.
3. Review workflow trước khi đi vào UI detail
   Quy trình đúng quan trọng hơn màn hình đẹp quá sớm.
4. Định nghĩa exception handling rõ ràng
   Edge case nên được bàn trước khi coding đi sâu.
5. Align acceptance criteria trước khi QA bắt đầu
   QA nên xác nhận hành vi đã được chốt, chứ không phải đi tìm target.

Kết luận

Dự án thường không chậm vì coding khó.

Chúng chậm vì sự không chắc chắn được phép đi vào dự án quá sớm — và ở lại quá lâu.

Khi requirement definition yếu, rework gần như là điều tất yếu.

Khi requirement definition mạnh, delivery ổn định hơn, QA rõ ràng hơn, và việc align với khách hàng cũng dễ hơn nhiều.

Những dự án nhanh nhất không phải là những dự án lao ngay vào development.

Chúng là những dự án biết giảm ambiguity trước khi complexity phình ra.

VAON hỗ trợ system development từ upstream đến downstream — giúp team làm rõ requirement, giảm rework, và delivery với độ tin cậy cao hơn.