Giả sử bạn ngồi trong một cuộc họp chỉ để chốt một câu tưởng đơn giản, cột này để mấy số thập phân, dev bảo ít là đủ, user muốn nhiều hơn vì sợ sai số làm tròn, cuối cùng cả phòng gật đầu để nhiều cho chắc rồi ai về nhà nấy, không ai ghi lại đã chốt gì và vì sao. Một quyết định nhỏ như thế, nhân lên hàng trăm lần trong một dự án ERP, là decision debt.
Theo mình decision debt là thứ tích tụ khi dự án trì hoãn những quyết định kinh doanh quan trọng rồi lấp chỗ trống bằng giả định tạm, và nó còn nguy hiểm hơn technical debt, vì gần như chẳng bao giờ xuất hiện trên risk register hay dashboard nào.
decision debt là gì#
Nói nôm na, decision debt là khoảng cách giữa “mình biết cần quyết cái gì” và “mình thật sự chốt được nó”. Trong một ERP program, nó tích tụ khi team hoãn một quyết định architecture vì để sau go-live tính, chọn giải pháp tạm vì deadline đang dí, không chốt được business rule vì stakeholders chưa đồng thuận, hay cứ lấy assumption thay cho data để đi tiếp.
Mỗi quyết định bị hoãn là một khoản nợ, và lãi của nó là rework, dev code xong theo assumption thì user mới ơ, hồi đó nói vậy thôi chứ đâu phải vậy. Trong bài tại sao dự án ERP thất bại mình có nhắc chuyện sponsor vắng mặt làm mọi quyết định bị treo, theo mình đó chính là decision debt, dự án hỏng không phải vì chọn sai phần mềm, mà vì không ai chốt quyết định đúng lúc.
vì sao nó nguy hiểm hơn technical debt#
Technical debt còn có công cụ đo, SonarQube cho bạn biết code quality đang ở đâu, bạn lên kế hoạch refactor dần, tính được cả lãi suất. Decision debt thì vô hình, chẳng có dashboard nào báo bạn đang nợ chừng này quyết định, rework ước tính chừng kia giờ, nó như tảng băng trôi, không thấy cho tới lúc đâm vào.
Nó còn ngấm ngầm hơn nhiều. Một quyết định sai thì dễ sửa, quay lại chốt lại là xong, nhưng hàng chục quyết định bị hoãn, mỗi cái dựa trên một assumption khác nhau, tới lúc chúng va vào nhau là dự án vỡ, dev bảo em code theo assumption A, business bảo bên em muốn B, còn BA lúc đó mới ngã ngửa ra là mình quên chốt A hay B từ mấy tháng trước.
ba dấu hiệu nhận ra#
Dấu hiệu số một là họp liên tục mà không có decision log, họp xong ai cũng gật, nhưng không ai viết ra đã quyết XYZ, tuần sau họp lại hỏi lại đúng câu đó, không ai nhớ.
Dấu hiệu thứ hai là assumption checklist dài hơn cả requirement list, decision log toàn “giả định là…”, “chờ confirm với…”, “tạm coi như…”, tức là bạn đang nợ, vì assumption là một khoản nợ chưa đáo hạn.
Dấu hiệu thứ ba là dev bắt đầu code trước khi BA kịp confirm, phải tự đoán business logic vì BA chưa chốt được với stakeholder, lúc đó decision debt đang đẻ lãi, mà lãi thường rất cao.
BA làm được gì#
Mình nghĩ BA có trách nhiệm chặn decision debt từ sớm, chứ không chỉ ghi requirement rồi bàn giao. Một việc mình làm thật là khi khách đổi ý ngay trong cuộc họp, mình không chốt tại chỗ, mình ghi nhận yêu cầu, đánh giá ảnh hưởng, rồi hẹn họp sau để quyết, nghe thì chậm, nhưng tránh được kiểu quyết vội rồi lại thành nợ.
Ngoài ra theo mình có mấy việc nhỏ đáng thử. Giữ một decision log, sau mỗi workshop ghi lại vài decision đã chốt dù nhỏ, decision còn pending, người chốt và deadline, gửi sớm sau buổi họp, làm đều không bỏ phiên nào. Đặt deadline cứng cho mỗi decision quan trọng, quá hạn thì escalate lên sponsor, không để pending kéo dài vô thời hạn. Coi mỗi assumption là một risk, cái nào để lâu chưa verify thì đưa lên báo động. Và vẽ một cái dependency map cho stakeholders thấy quyết định A chưa chốt thì module B không thiết kế được, team C ngồi chờ, nhìn tận mắt cái giá của việc trì hoãn thì người ta chốt nhanh hơn hẳn.
Bài scope creep, chuyện kinh điển và cách sống sót cũng có góc nhìn tương tự, càng ngại chốt quyết định thì về sau càng tốn rework.
không ai về được số không#
Nói thật thì tránh tuyệt đối decision debt là không thể, ERP program phức tạp, có những quyết định cần thời gian, cần dữ liệu, cần người duyệt đang vắng mặt, cần thử mới biết đáp án. Mục tiêu không phải là zero decision debt, mà là quản lý nó như một loại risk chính thức, biết mình đang nợ gì, ảnh hưởng ra sao, trả dần thế nào. Cũng giống chuyện mình viết trong bài tích hợp trước AI, bài học từ dược phẩm và quốc phòng, cái móng mới quyết định kết quả, chứ không phải tốc độ.
Decision debt không hiện trên dashboard, không có số, không có biểu đồ, không có alert, nhưng theo mình BA nào đi qua một dự án ERP cũng cảm được nó, chỉ là có dám nhìn thẳng vào hay không. Dự án bạn đang làm có bao nhiêu quyết định đang chờ confirm, và đã chờ bao lâu rồi?
