Nhiều dự án phần mềm không chết vì đội làm kém, mà chết vì thay đổi diễn ra tự do, không có cơ chế phê duyệt, không có người chịu trách nhiệm và không ai nhìn lại tác động thật sự. Founder thường nghĩ mình chỉ đang tinh chỉnh cho sản phẩm tốt hơn. Nhưng nếu thay đổi đi thẳng vào backlog hoặc đi thẳng vào tay đội kỹ thuật mà không qua một lớp kiểm soát, chính founder là người dễ làm vỡ dự án của mình nhất.
Vấn đề không nằm ở việc có thay đổi hay không. Phần mềm luôn thay đổi. Vấn đề là thay đổi nào được phép đi vào sprint hiện tại, thay đổi nào phải tạo change request, và thay đổi nào phải được xem như một scope mới hoàn toàn. Khi thiếu cơ chế này, dự án rơi vào scope creep: phạm vi cứ nở dần, cam kết cũ mất giá trị, còn hai bên bắt đầu tranh cãi xem cái gì là nằm trong thỏa thuận ban đầu.
Phân biệt 3 mức thay đổi để không tranh cãi cảm tính
Một cách đơn giản là chia thay đổi thành 3 mức:
- Thay đổi nhỏ: chỉnh câu chữ, đổi màu, sửa nhãn nút, tinh chỉnh logic rất hẹp, không làm thay đổi luồng chính, không ảnh hưởng kiến trúc, không kéo theo kiểm thử diện rộng.
- Thay đổi lớn: thêm bước trong quy trình, đổi logic nghiệp vụ ở một màn hình quan trọng, thêm vai trò người dùng, thêm báo cáo, thêm điều kiện phê duyệt, hoặc thay đổi làm ảnh hưởng nhiều màn hình và test case.
- Thay đổi làm vỡ phạm vi: thêm module mới, đổi mô hình dữ liệu cốt lõi, đổi từ một quy trình đơn giản sang nhiều cấp duyệt, tích hợp hệ thống thứ ba, đổi cấu trúc phân quyền, hoặc bất kỳ thay đổi nào làm cam kết build ban đầu không còn đúng nữa.
Nếu không gọi tên được mức thay đổi, hai bên sẽ rất dễ dùng cảm giác để tranh luận. Founder thấy đó chỉ là một ý nhỏ. Đội triển khai thấy đó là thay đổi Level 3 vì nó kéo theo chỉnh database, API, quyền truy cập, migration dữ liệu và regression test. Cùng một ý nhưng nhìn ở hai tầng khác nhau nên mâu thuẫn là điều gần như chắc chắn.
Vì sao càng đổi muộn càng đắt
Một thay đổi đến càng muộn thì chi phí càng cao vì lúc đó hệ thống đã có nhiều ràng buộc hơn: dữ liệu đã hình thành, luồng nghiệp vụ đã nối với nhau, tài liệu đã chốt, code đã đi qua nhiều lớp, test đã viết, và có thể người dùng nội bộ đã bắt đầu làm quen.
Thay đổi muộn đắt ở ít nhất 5 chỗ:
- Đắt ở phân tích lại: phải xem thay đổi chạm vào đâu, ảnh hưởng đến ai, có phá giả định ban đầu không.
- Đắt ở thiết kế lại: nhiều thứ tưởng chỉ sửa một màn hình nhưng thực tế phải sửa cả cấu trúc dữ liệu hoặc quyền.
- Đắt ở lập trình lại: code đã viết phải bẻ hướng, phần cũ có thể bị bỏ.
- Đắt ở kiểm thử lại: không chỉ test phần mới mà phải regression test các phần liên quan.
- Đắt ở chi phí niềm tin: khi deadline cũ không còn giữ được, hai bên bắt đầu nghi ngờ nhau.
Đó là lý do build-commit brief rất quan trọng. Trước khi làm, hai bên cần chốt rõ đang build cái gì, commit ở mức nào, tiêu chí nghiệm thu ra sao và điều gì nằm ngoài phạm vi. Không có brief kiểu này, mọi thay đổi về sau đều dễ bị hiểu nhầm là đương nhiên phải có.
Quy trình 4 bước để mở scope mới mà không phá dự án đang chạy
Muốn dự án vẫn tiến về đích mà không chặn sáng tạo, hãy dùng một quy trình change control rất đơn giản:
- Ghi nhận thay đổi bằng văn bản. Mọi yêu cầu mới phải được ghi thành một change request ngắn: mô tả thay đổi, lý do, lợi ích kỳ vọng, mức độ gấp, và tác động nếu chưa làm ngay.
- Đánh giá tác động. Đội thực thi hoặc product owner phải trả lời được 4 câu: ảnh hưởng đến phạm vi nào, ước lượng thêm bao nhiêu effort, làm trễ hạng mục nào, và có phát sinh rủi ro kỹ thuật hay không.
- Ra quyết định rõ ràng. Chỉ có 3 lựa chọn hợp lệ: đưa vào scope hiện tại, hoãn sang phase sau, hoặc mở scope mới với timeline và chi phí riêng. Không nên tồn tại kiểu đồng ý miệng rồi để đội tự xoay.
- Cập nhật cam kết chính thức. Nếu thay đổi được duyệt, phải cập nhật lại brief, backlog, mốc bàn giao và tiêu chí nghiệm thu. Nếu không cập nhật giấy tờ, dự án sẽ sống với hai bộ sự thật khác nhau.
Điểm quan trọng nhất là: mọi thay đổi đều phải đổi lấy một thứ gì đó. Nếu thêm tính năng mà không tăng thời gian, chi phí hoặc cắt bớt thứ khác, dự án đang bị ép vào tình huống phi thực tế.
Mẫu trao đổi khi có thay đổi
Founder có thể dùng một mẫu rất ngắn để giữ cuộc nói chuyện tỉnh táo:
Mẫu với đối tác thi công hoặc đội nội bộ:
Chúng tôi muốn bổ sung hạng mục này vì tác động trực tiếp đến mục tiêu kinh doanh. Nhờ đội đánh giá giúp đây là thay đổi nhỏ, thay đổi lớn hay mở scope mới. Vui lòng phản hồi tác động đến timeline, effort, các hạng mục bị ảnh hưởng và đề xuất một trong ba phương án: đưa vào phase hiện tại, chuyển sang phase sau, hoặc tách thành change request riêng để phê duyệt.
Mẫu này giúp đổi cuộc trao đổi từ cảm xúc sang quyết định có cấu trúc. Bạn không còn nói kiểu làm giúp thêm cái này nhé, còn bên kia cũng không phải đoán xem nên chiều hay nên từ chối.
Một thay đổi tưởng nhỏ nhưng kéo theo chi phí lớn
Ví dụ một founder đang làm hệ thống bán hàng nội bộ và nói: chỉ thêm giúp tôi một bước quản lý duyệt đơn trước khi xuất kho. Nghe có vẻ nhỏ. Nhưng thực tế thay đổi này có thể kéo theo:
- Thêm trạng thái đơn hàng mới.
- Thêm vai trò người duyệt và phân quyền tương ứng.
- Đổi logic tồn kho vì hàng chưa duyệt thì có được giữ chỗ hay không.
- Thêm thông báo cho các bên liên quan.
- Đổi báo cáo doanh thu và báo cáo vận hành.
- Chỉnh API và tích hợp nếu có kết nối hệ thống khác.
- Viết lại test case cho toàn bộ luồng đặt hàng đến xuất kho.
Một ý tưởng nhìn như thay đổi giao diện thực ra là thay đổi nghiệp vụ lõi. Đây chính là kiểu việc cần được xếp vào Level 3 hoặc mở scope mới, không nên chen vào giữa sprint như một việc lặt vặt.
Cách founder tự bảo vệ dự án của mình
- Chốt build-commit brief trước khi bắt tay làm.
- Định nghĩa rõ đâu là in scope và out of scope.
- Yêu cầu mọi thay đổi phải đi qua change request.
- Không duyệt việc mới nếu chưa biết nó đổi timeline, chi phí hoặc ưu tiên ra sao.
- Giữ một danh sách parking lot cho các ý hay nhưng chưa nên làm ngay.
- Review scope định kỳ theo mốc, không sửa ngẫu hứng mỗi ngày.
Kỷ luật thay đổi không làm dự án chậm đi. Ngược lại, nó giúp đội đi nhanh hơn vì ai cũng biết cái gì đang được cam kết, cái gì đang chờ đánh giá và cái gì thuộc phase tiếp theo.
Kết luận
Founder không cần ngừng nảy ra ý tưởng mới. Founder chỉ cần ngừng ném ý tưởng mới thẳng vào dự án đang chạy mà không qua cơ chế phê duyệt. Khi phân loại thay đổi rõ ràng, dùng change request, cập nhật cam kết và biết lúc nào cần mở scope mới, bạn sẽ tránh được scope creep và giữ được niềm tin giữa các bên.
Nếu muốn giữ kỷ luật quyết định ngay từ đầu, hãy dùng AI Tạo Phần Mềm để làm rõ bài toán phần mềm, chốt scope theo từng Level, tạo build-commit brief và kiểm soát thay đổi dự án trước khi nó kịp làm vỡ kế hoạch.
