Nguyen Le PhongNguyen Le Phong

Sự nhẹ nhõm khi problem được gọi đúng tên

Một ghi chú reflection về cách problem được gọi đúng tên làm giảm căng thẳng bằng cách biến cảm giác rải rác thành thứ mọi người có thể cùng xem xét.

Căn phòng chỉ nhẹ lại sau khi problem có tên. Trước đó, mọi người đang cãi về symptom: meeting quá dài, spec cứ đổi, implementation nặng, review trễ. Tất cả đều đúng, nhưng không cái nào giải thích vì sao công việc bị kẹt.

Một người gom các sticky note trống rải rác vào một vòng tròn trung tâm rõ ràng có mũi tên trên bàn.
Problem được gọi tên cho những cảm giác rải rác một chỗ để tụ lại.

Một problem được gọi đúng tên không tự giải quyết công việc. Nó làm một việc khiêm tốn hơn và quan trọng hơn: cho team một shared object. Thay vì mỗi người bảo vệ frustration của mình, mọi người có thể nhìn cùng một thứ. Tension chuyển từ cá nhân sang inspectable.

Cái tên cần đủ chính xác để giảm noise. Đây không phải design problem có thể kém hữu ích hơn user đang bị yêu cầu chọn trước khi hiểu consequence. Tên thứ hai chỉ về behavior. Nó mời example. Nó làm câu hỏi tốt hơn trở nên khả thi.

Tên xấu tạo fog riêng. Gọi mọi thứ là communication issue che việc real issue có thể là missing authority, unclear ownership, conflicting incentive, hoặc absent evidence. Gọi thứ gì đó là technical debt có thể che rằng problem thật là product ambiguity. Một tên mơ hồ có thể làm problem trông như đã được quản lý trong khi vẫn chưa được chạm vào.

Có sự nhẹ nhõm trong tên đúng vì nó giảm blame. Khi problem chưa có tên, con người thường trở thành explanation. Designer quá chậm. Engineering quá thận trọng. Product cứ đổi ý. Khi problem được gọi chính xác hơn, system quanh con người hiện ra.

Tên tốt cũng tạo next step. Nếu problem là unclear decision ownership, next step không phải thêm một meeting rộng. Nó là gọi tên ai quyết định gì, trước khi nào, với input nào. Nếu problem là thiếu production-like test data, next step không phải tranh luận estimate thêm. Nó là lấy data shape.

Việc đặt tên cần patience. Tên đầu tiên thường quá lớn hoặc quá cảm xúc. Cứ viết xuống, rồi làm nó nhỏ hơn. Behavior nào chứng minh nó? Nó xảy ra ở đâu? Nếu giải quyết được thì điều gì đổi? Tên tốt lên khi team thay mood bằng evidence.

Những problem name tốt nhất nghe gần như bình thường sau khi xuất hiện. À đúng rồi, issue là vậy. À đúng rồi, cái đó giải thích rework. À đúng rồi, đó là lý do conversation cứ quay vòng. Sự nhẹ nhõm đến từ việc nhận ra work không impossible; nó chỉ blurry.

Nếu một conversation cứ xoay vòng, hãy dừng lại và hỏi problem đã có tên đủ tốt chưa. Đôi khi progress bắt đầu không phải bằng solution, mà bằng một câu cuối cùng mọi người có thể chỉ vào.

Bạn thấy bài viết thế nào?