Thinking in Systems của Donella Meadows: cuốn sách giúp FDE tách bài toán mơ hồ của khách

Khách hiếm khi mang tới cho FDE một bài toán đã được định nghĩa sẵn. Phần lớn chỉ kể một cảm giác: ticket tồn ngày càng nhiều, khách hàng của họ phàn nàn nhiều hơn, đội ngũ thì mệt.

Muốn tách loại bài toán này ra, hãy đọc Thinking in Systems: A Primer của Donella H. Meadows, tác giả chính của báo cáo The Limits to Growth năm 1972.

Bạn sẽ không học được API hay framework nào từ cuốn này, nhưng sẽ học được cách đặt câu hỏi để buổi discovery tiếp theo không dừng lại ở triệu chứng.

Một cuốn sách người viết không kịp in

Bản thảo của cuốn sách đã được lưu hành từ năm 1993. Meadows mất năm 2001, và cuốn sách được hoàn tất sau khi bà qua đời: Diana Wright biên tập, Chelsea Green Publishing ở White River Junction, Vermont, xuất bản năm 2008.

Donella Meadows Project, tổ chức gìn giữ di sản của bà, gọi đây là một cuốn primer, tức sách nhập môn. Đúng tinh thần đó, lời khuyên đáng nhớ nhất của Meadows rất giản dị: trước khi tác động vào hệ thống theo bất kỳ cách nào, hãy quan sát xem nó vận hành ra sao.

Với FDE, câu này đổi hẳn hướng của buổi phỏng vấn khách. Thay vì vội hỏi “anh chị muốn tool làm gì?”, bạn hỏi “cái gì trong quy trình này đang tự nuôi vấn đề?”.

Ý thứ nhất: tìm vòng nào đang tự củng cố

Meadows viết rằng vòng phản hồi dương là nguồn của tăng trưởng, bùng nổ, xói mòn và sụp đổ trong hệ thống. Loại vòng tự củng cố này tăng theo cấp số nhân, và nếu không ai chặn lại, nó có thể gây thiệt hại nghiêm trọng, không đảo ngược được.

Thử hình dung đội support ở trên, và giả sử nhân viên của đội được thưởng theo số ticket đóng mỗi tuần. Ticket tồn nhiều thì nhân viên phải trả lời vội. Trả lời vội thì câu trả lời kém, khách mở lại ticket, và lượng ticket tồn lại tăng thêm.

Đây là một vòng tự củng cố, và nó giải thích vì sao “mọi thứ tệ dần” chứ không chỉ “tệ”. Khi đã gọi tên được vòng này, bạn có một giả thuyết để kiểm tra bằng dữ liệu: tỷ lệ mở lại ticket có tăng cùng lượng tồn hay không.

Ý thứ hai: hỏi về độ trễ

Meadows viết rằng một hệ thống không thể phản ứng với những thay đổi ngắn hạn khi nó có độ trễ dài hạn. Trong đội support, ticket bị mở lại thường quay về muộn, nhiều ngày sau câu trả lời vội.

Thử hình dung đội đó chỉ xem báo cáo chất lượng mỗi quý: lúc thấy số liệu thì tình hình đã khác, nên họ dễ phản ứng muộn hoặc chỉnh quá tay.

Trong deployment, độ trễ còn quyết định cả cách bạn chứng minh giá trị. Một thay đổi phải mất sáu tuần mới thấy kết quả thì không thể được đánh giá trong một pilot dài bốn tuần. Vì thế hãy hỏi khách ngay từ đầu: thay đổi một thứ thì bao lâu sau họ biết nó có tác dụng?

Ý thứ ba: chỉnh con số là đòn bẩy yếu nhất

Ý này đến từ bài luận Leverage Points: Places to Intervene in a System của Meadows, trong đó bà xếp các chỗ có thể can thiệp vào hệ thống thành một danh sách. Ở bậc 12, thấp nhất và yếu nhất, là hằng số, tham số và con số như trợ giá, thuế, tiêu chuẩn.

Bà nói rõ tham số đứng “chót bảng” trong các can thiệp mạnh, và rằng con số hiếm khi làm thay đổi hành vi. Các bậc cao hơn trong danh sách vì thế là những chỗ can thiệp mạnh hơn.

Meadows không viết về đội support, nên bảng dưới đây chỉ là một phép áp thử. Dòng đầu khớp thẳng với bậc 12 của bà; hai dòng sau là những hướng đi không dừng ở con số, chưa được gán vào bậc cụ thể nào trong danh sách.

Can thiệp thử áp	Có phải chỉ chỉnh con số?	Điều có thể xảy ra với vòng
Thêm người, nâng SLA	Có, đúng loại bậc 12	Vòng chạy chậm lại, nhưng vẫn còn đó
Cho nhân viên thấy ticket nào bị mở lại	Không, đổi thông tin người trả lời nhận được	Người trả lời biết ngay câu trả lời của mình có hỏng không
Thôi thưởng theo số ticket đóng	Không, đổi cách đội được đánh giá	Gỡ bỏ lý do khiến mọi người phải trả lời vội

Giờ thử hình dung bạn được giao xây một agent soạn sẵn câu trả lời cho chính đội support này. Nếu agent chỉ giúp trả lời nhanh hơn, về bản chất nó đang chỉnh một con số: tốc độ, trong một vòng vẫn đang hỏng.

Cũng agent đó có thể làm nhiều hơn, chẳng hạn đưa tín hiệu mở lại ticket về đúng người đã trả lời. Khi đó nó chạm vào cấu trúc của vòng, chứ không chỉ làm vòng quay nhanh hơn.

Có một lưu ý. Thứ tự trong danh sách chỉ nên xem là gợi ý, và giới phê bình cho rằng nó đơn giản hóa quá mức sự phức tạp của các hệ thống xã hội. Nên dùng nó để mở rộng các phương án bạn nghĩ tới, đừng biến nó thành checklist.

Nên đọc theo thứ tự nào?

Bắt đầu bằng bài luận Leverage Points, đăng trên trang của Donella Meadows Project và từng được Nonprofit Quarterly đăng lại. Bài này ngắn và cho bạn ngay cái thang để dùng. Sau đó đọc trọn cuốn sách để nắm vòng phản hồi và độ trễ cho chắc.

Cuối cùng là Dancing With Systems, đăng trên trang của Donella Meadows Project năm 2012, nơi có lời khuyên quan sát hệ thống trước khi động tay. FDE nào từng thấy một deployment hoàn hảo trên giấy bị quy trình thật của khách bẻ cong sẽ hiểu vì sao bài này nên đọc trước mỗi lần lên site.

Đưa vòng phản hồi vào CV thế nào?

Ví dụ đội support ở trên cũng là một dòng CV tốt. Thay vì viết “đã triển khai agent cho đội support”, thử viết: “Phát hiện vòng tự củng cố giữa lượng ticket tồn và tỷ lệ mở lại; đưa tín hiệu mở lại về cho người trả lời; đặt mốc đo tỷ lệ mở lại sau sáu tuần vì độ trễ của vòng.”

Dòng đó kể đủ ba ý của cuốn sách: vòng phản hồi bạn tìm ra, chỗ can thiệp bạn chọn, và độ trễ bạn đã tính khi đặt mốc đo. Trong vòng phỏng vấn case study, kể lại theo đúng ba bước ấy.

Lần tới khách nói “mọi thứ đang tệ dần”, câu đó đã là manh mối đầu tiên: rất có thể đang có một vòng tự củng cố chạy đâu đó, và việc của bạn là tìm ra nó.