Case xuyên suốt: rút 3 engineer khỏi dự án Nhật

Kho học liệu có nhiều công cụ — tư duy máy móc, CLD, stakeholder map, các tầng học tập, BSM, VSM và decision record. Bài này minh hoạ một trình tự ứng dụng do người biên soạn đề xuất, không phải trình tự đã được giảng đủ trong lớp.

Trạng thái bằng chứng. Đây là case giả định đặt trong bối cảnh Ominext. Nhân vật, số liệu, timeline, quan hệ nhân quả và chẩn đoán đều là dữ liệu tổng hợp để luyện tập; không được dùng như sự kiện vận hành thật. Mỗi bước tạo một giả thuyết cần kiểm chứng bằng dữ liệu và người trong cuộc.

Case

Dự án mới của một khách hàng lớn cần gấp 3 engineer giỏi. Ban điều hành quyết định rút 3 engineer khỏi dự án đang chạy cho khách Nhật của Ominext để chi viện. Đến tháng thứ 3 sau quyết định: dự án Nhật trễ SLA hai lần liên tiếp, khách bắt đầu chuyển yêu cầu mới sang vendor khác, và một engineer chủ chốt của team còn lại nộp đơn nghỉ.

Quyết định hợp lý — dự án mới quan trọng, 3 người là “dư địa tối ưu”. Vậy sai ở đâu?

Bước 1 — Nhận diện phản xạ máy móc (Chuyên đề 1)

Phản xạ ban đầu có thể là tìm bộ phận hỏng — “PM quản lý kém” → thay PM; “team thiếu kỷ luật” → thêm quy trình báo cáo ngày. Tư duy máy móc giúp nhận diện phép quy giản này. Giả thuyết thay thế là vấn đề nằm ở quan hệ giữa năng lực, khối lượng cam kết, OT, chất lượng và niềm tin khách hàng; giả thuyết đó vẫn phải được kiểm tra.

Dấu hiệu để tự bắt mình: nếu giải pháp đầu tiên bạn nghĩ đến có dạng “thay X” hoặc “thêm quy định Y” — dừng 5 giây, hỏi “cấu trúc nào đang tạo ra hành vi này?”

Bước 2 — Nhìn mẫu hành vi, không nhìn sự kiện (Chuyên đề 2)

Trong dữ liệu giả định, chất lượng bàn giao giảm từ tháng thứ 2, OT tăng và tốc độ phản hồi khách chậm dần. Behavior-over-time graph giúp chuyển câu hỏi từ “ai gây ra sự cố tháng 3?” sang “mẫu nào bắt đầu khi nào?”. Quyết định rút người là một giả thuyết có dấu thời gian phù hợp, chưa phải nguyên nhân được chứng minh; cần kiểm tra thay đổi phạm vi, năng lực PM, yêu cầu khách và các yếu tố đồng thời.

Bước 3 — Stakeholder map: ai có mặt trong quyết định, ai không

Khi quyết định được chốt, trong phòng họp có: ban điều hành, giám đốc dự án mới. Không có mặt: PM dự án Nhật (được thông báo, không được hỏi), team còn lại (gánh OT), khách hàng Nhật (phát hiện qua chất lượng giảm), OmiJapan (mất uy tín cross-sell khi khách phàn nàn trong network), gia đình các engineer (gánh hệ quả OT), và HR (nhận yêu cầu tuyển gấp sau đó 3 tháng). Sơ đồ mẫu đầy đủ — kèm chiều ảnh hưởng và các bên không có tiếng nói — nằm trong Khung ra quyết định toàn hệ thống.

Bài học một dòng: hệ quả chạy qua các bên không có mặt trong phòng họp — đúng chỗ bản đồ tư duy của người quyết định trống.

Bước 4 — CLD: hai vòng giả thuyết

Diễn đạt bằng lời (sơ đồ vẽ chuẩn quy ước nằm trong Các khái niệm cốt lõi, dùng đúng case này):

Vòng tăng cường R1 — “xoáy rework”: rút người → áp lực tiến độ tăng → OT tăng → mệt mỏi/lỗi tăng → rework tăng → khối lượng thực tế tăng → áp lực tiến độ càng tăng. Kiểm tra bằng dữ liệu giờ làm, defect, rework và lead time; đừng coi mũi tên là bằng chứng.
Vòng cân bằng B1 — “vá bằng người”: áp lực tăng → xin bổ sung người → (độ trễ giả định 2–3 tháng: tuyển + onboard + học domain) → năng lực tăng → áp lực giảm. Cần xác minh độ trễ và việc thêm người có thực sự tăng năng lực ròng trong giai đoạn quan sát.

Cấu trúc được giả thuyết theo hướng Fixes That Fail: giải pháp mang lợi ích ngắn hạn ở dự án mới, trong khi hệ quả phụ có độ trễ làm suy giảm dự án cũ. Muốn gọi đúng archetype, CLD phải thể hiện cả vòng lợi ích ngắn hạn lẫn vòng hệ quả phụ và có bằng chứng đủ cho các quan hệ.

Bước 5 — Ba vòng phản hồi: tổ chức đang học ở tầng nào

Vòng 1 (làm đúng cách): thay PM, thêm báo cáo ngày — chuẩn giữ nguyên, chỉ siết thực thi. Tổ chức này đã dừng ở đây.
Vòng 2 (đặt lại giả định): “quy trình điều người giữa các dự án của chúng ta dựa trên giả định nào? ‘Engineer là nguồn lực hoán đổi được’ — giả định đó có đúng với dự án cần domain Nhật không?”
Vòng 3 (đặt lại quyền định nghĩa): “vì sao chỉ ban điều hành và giám đốc dự án mới có mặt khi chốt? Ai nên có quyền phủ quyết một lệnh rút người — và PM dự án bị rút có tiếng nói không?”

Bước 6 — Câu hỏi BSM: lăng kính Phật học

Bốn câu từ bộ 36 câu “gõ” mạnh nhất vào case này:

Lăng kính	Câu hỏi	Nó mở ra điều gì
Chánh tinh tấn (B1.6)	Có sự né tránh nào đang diễn ra? Ai nên tham gia?	PM dự án Nhật biết trước rủi ro nhưng “không tiện nói” — văn hoá tránh vấn đề đúng nghĩa
Chánh niệm (B1.7)	Có bóp méo nào trong cách khung vấn đề? Đã hỏi ai để kiểm chứng chưa?	“3 người là dư địa” là ước lượng của người ngoài team, chưa từng được kiểm chứng với người trong
Nhân–Duyên–Quả (B1.10)	Nhân + duyên nào cùng tạo quả này?	Nhân (rút người) chỉ cho quả xấu vì duyên: domain khó thay người + khách Nhật nhạy chất lượng + không có buffer. Đổi duyên (bàn giao dần, thuê ngoài phần non-core) thì cùng nhân đã cho quả khác
Thời gian (B1.12)	Các bên đang sống trong khung thời gian nào?	Ban điều hành: quý. Khách Nhật: quan hệ 10 năm. Engineer: sự nghiệp. Quyết định tối ưu cho khung quý đã phá giá trị ở hai khung kia

Bước 7 — Chẩn đoán VSM: chức năng nào có thể đang yếu

Soi bằng 5 hệ thống S1–S5 — dưới dạng giả thuyết chẩn đoán cần kiểm chứng, đúng cách VSM được dùng thật:

Giả thuyết về S3/S3*: quyết định phân bổ người là chức năng S3 — nhưng nó được chốt mà không có S3* kiểm chứng thực địa (“dư địa 3 người” chưa từng được xác minh với người trong team).
Giả thuyết về S2: xung đột nguồn lực giữa hai dự án không có kênh điều phối ngang nào ngoài “lệnh từ trên xuống” — dấu hiệu S2 vắng mặt hoặc quá yếu.
Giả thuyết về kênh tín hiệu: tín hiệu sớm từ khách Nhật (tần suất phàn nàn tăng, giọng email đổi) có tồn tại ở tầng vận hành nhưng không có đường chính thức chạm tới quyết định phân bổ — cần kiểm tra xem đây là lỗi kênh S1→S3 hay S4 không theo dõi môi trường khách hàng.

Điểm mấu chốt: chẩn đoán VSM không phải để dán nhãn “thiếu S mấy” cho xong, mà để biết phải đi kiểm chứng cái gì trước khi thiết kế lại.

Bước 8 — Quyết định lại bằng khung toàn hệ thống + kế hoạch hành động

Nếu chạy case qua decision record 12 trường trước khi chốt, một phương án có thể là: hỏi PM và team, xác minh độ trễ tuyển/onboard, định nghĩa điều kiện bàn giao, rồi thử thay đổi nhỏ thay vì rút ba người cùng lúc.

Một probe chỉ được gọi là safe-to-fail khi có: phạm vi thiệt hại được khoanh, owner giám sát, chỉ báo sớm, ngưỡng dừng, phương án rollback và chấp thuận của bên chịu rủi ro. Ví dụ “rút một người trong bốn tuần” chưa tự động an toàn nếu SLA, an toàn người bệnh, compliance hoặc quan hệ khách hàng có thể bị ảnh hưởng không đảo ngược.

Điều cần nhớ

Tám bước trên là một workflow tham khảo để mở dần ranh giới: từ “linh kiện hỏng” → mẫu theo thời gian → bên bị bỏ quên → vòng lặp → giả định và quyền lực → lăng kính BSM → chức năng VSM → quyết định có điều kiện dừng. Không phải case nào cũng cần đủ tám bước hoặc đi đúng thứ tự; hãy chọn phương pháp theo loại vấn đề, rủi ro, bằng chứng và năng lực facilitation.