Release lại trễ. Cuộc họp rút kinh nghiệm kết thúc bằng ba việc quen thuộc: nhắc mọi người chủ động hơn, thêm một checklist và hẹn một cuộc họp nữa. Hai sprint sau, nhóm vẫn trễ — chỉ khác là lần này ticket mang tên khác. Cái được sửa hôm trước hóa ra chỉ là chỗ đang đau, không phải thứ gây đau.
The Art of Thinking in Systems giúp mình gọi tên tình huống ấy rõ hơn. “Mọi thứ liên quan đến nhau” là một câu đúng nhưng chưa đủ dùng. Điều đáng nhìn là cấu trúc cụ thể: ai có thông tin, ai có quyền quyết, hành vi nào đang được thưởng, phản hồi quay về nhanh hay chậm, và đoạn nào khiến cả dòng việc phải đứng xếp hàng.
Vì vậy, tư duy hệ thống thường bắt đầu bằng việc khoan tìm người để trách. Nhóm hay trễ chưa chắc vì lười. Backlog có thể luôn bị nhồi quá mức. Estimation có thể bị ép cho đẹp. Một người duyệt cuối luồng có thể đang thành bottleneck. Hoặc người báo rủi ro sớm từng bị xem là “tiêu cực”, nên giờ ai cũng đợi tới phút chót mới nói. Nếu vòng lặp này còn nguyên, một bài diễn văn về trách nhiệm chỉ làm căn phòng căng thêm.
Một cách mô tả cơ bản của hệ thống là stock (lượng tích), flow (dòng chảy) và feedback (phản hồi). Stock là thứ tích lại: technical debt, niềm tin, tiền mặt, kỹ năng, năng lượng hay bực bội. Flow là những dòng làm nó tăng hoặc giảm. Phản hồi là tín hiệu quay về để hệ thống tự chỉnh. Nghe hơi sách vở, nhưng ra văn phòng lại rất đời: bug vào nhanh hơn khả năng sửa thì backlog phình; lời hứa vào nhiều hơn năng lực giao thì niềm tin rút dần.
Độ trễ làm mọi thứ khó hơn. Hôm nay bỏ QA, release có thể vẫn chạy và dashboard còn xanh. Hệ quả chỉ đến vài tuần sau qua ticket hỗ trợ, rework và khách hàng bớt tin. Vì tín hiệu tới muộn, quyết định ban đầu trông như đã thành công. Ta rất dễ tăng liều đúng thứ đang gây vấn đề.
Chuyện học cũng có cùng cơ chế. Mười lăm phút tiếng Anh mỗi ngày chưa chắc tạo cảm giác tiến bộ sau một tuần. Nếu phản hồi duy nhất là “mình vẫn dở”, người học dễ bỏ trước khi kỹ năng kịp tích. Đổi tín hiệu sang số câu nghe hiểu, số lần dùng đúng một cấu trúc hay số ngày giữ được nhịp sẽ đưa phản hồi lại gần hơn. Mục tiêu không đổi, nhưng hệ thống bắt đầu biết nuôi hành vi.
Ở công việc, những giải pháp dễ gây nghiện nhất là giải pháp làm hôm nay đẹp lên bằng cách gửi hóa đơn cho tháng sau. Thêm người vào dự án trễ có thể làm giao tiếp và khâu đón người mới nặng hơn. Cắt QA có thể cứu một mốc rồi tạo thêm việc hỗ trợ. Bỏ hết cuộc họp có thể trả lại vài giờ, nhưng nếu thông tin không có đường khác để đi, bug và hiểu nhầm sẽ thu lại số giờ ấy với lãi.
Đòn bẩy tốt vì thế thường nằm ở một quy tắc nhỏ, một điểm đo hoặc một vòng phản hồi ngắn hơn. Muốn mọi người báo rủi ro sớm thì đừng thưởng người giấu được lâu hơn người nói thật. Muốn chất lượng tốt thì đo cả rework, chừa thời gian duyệt và cho người thực thi quyền từ chối đầu vào chưa rõ. Khẩu hiệu không sửa được cơ chế khuyến khích.
Một vấn đề lặp lại thường không phải nhiều tai nạn giống nhau. Có thể hệ thống đang cho ra đúng kết quả mà cấu trúc hiện tại khuyến khích, dù chẳng ai chủ ý thiết kế nó như thế.
Cách nhìn này không miễn trách nhiệm cho con người. Có người làm ẩu, có quyết định sai và có lúc chỉ cần sửa đúng một bước. Nhưng với chuyện đã quay lại lần thứ ba, kết luận về phẩm chất thường quá rẻ. Trước khi kết luận, hãy kiểm tra ba chỗ: đường làm đúng có quá nhiều ma sát, sự im lặng có an toàn hơn nói thật, và người duyệt có đủ thời gian. Ba chỗ ấy khó sửa hơn một lời nhắc, nhưng ít nhất chúng chạm vào nguyên nhân.
Cuốn sách không làm vấn đề đơn giản đi; nó làm mình bớt tin vào lời giải quá đơn giản. Lần tới khi một lỗi cũ khoác áo mới xuất hiện, có lẽ nên khoan thêm checklist. Vẽ luồng việc ra, đánh dấu độ trễ, nhìn cơ chế khuyến khích, rồi đối chiếu xem hệ thống đang âm thầm dạy mọi người làm gì trong khi lời nói chính thức lại yêu cầu điều ngược lại.