Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 5 — Khi việc được giao bị làm hỏng

Đã đọc 0/7 mục · còn khoảng 4 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Phản ứng đầu tiên quyết định lần sau

Việc bị hỏng là chuyện sẽ xảy ra. Điều bạn làm trong 24 giờ đầu quyết định hai thứ: việc này có được sửa tốt không, và lần sau người đó có dám nhận việc khó nữa không.

Phản ứng sai phổ biến nhất là tự tay làm lại rồi im lặng. Bạn nghĩ mình đang tử tế. Người kia hiểu rằng họ không được tin, và lần sau sẽ không giơ tay.

Tách ba câu hỏi ra khỏi nhau

Khi hỏng, đừng trộn lẫn ba việc này:

  • Sửa hậu quả — việc gấp, làm ngay, có thể cần bạn nhảy vào.
  • Tìm nguyên nhân — làm sau khi hết gấp, bình tĩnh.
  • Điều chỉnh cách giao lần sau — kết luận rút ra.
Trộn ba thứ này lại trong lúc đang nóng sẽ tạo ra một cuộc nói chuyện vừa không sửa được việc vừa làm tổn thương người.

Chẩn đoán: hỏng vì đâu

Bốn nguyên nhân, và cách xử lý hoàn toàn khác nhau:

  • Hỏng vì đề bài không rõ — lỗi thuộc về bạn. Phần DONE mơ hồ, hoặc bạn quên nói WHY. Cách chữa: viết lại đề bài, không phải trách người.
  • Hỏng vì thiếu kỹ năng — họ hiểu đúng nhưng chưa làm được. Cách chữa: hạ mức tự chủ cho loại việc này, ghép cặp với người có kinh nghiệm, không kết luận về họ nói chung.
  • Hỏng vì thiếu thông tin hoặc quyền — họ cần dữ liệu hoặc phê duyệt mà không lấy được. Cách chữa: đây gần như luôn là lỗi hệ thống, hãy gỡ rào cản.
  • Hỏng vì không ưu tiên — họ hiểu, làm được, nhưng không làm. Đây là loại duy nhất cần một cuộc nói chuyện về cam kết, và cũng là loại hiếm nhất. Đừng mặc định nhảy vào ô này.
Kinh nghiệm: phần lớn thất bại rơi vào ô 1 và ô 3, tức là lỗi của người giao hoặc của hệ thống. Nhưng phản xạ tự nhiên của quản lý là nhảy thẳng vào ô 4.

Cách nói chuyện sau sự cố

Mở đầu bằng dữ kiện, không bằng đánh giá:

> Sai: "Em làm việc này cẩu thả quá." > Đúng: "Báo cáo gửi đi thiếu số liệu tháng 7, khách hỏi lại. Em kể anh nghe chuyện gì đã xảy ra?"

Rồi im lặng và nghe hết. Phần lớn quản lý cắt lời ở giây thứ 20 để đưa kết luận có sẵn trong đầu. Thông tin hữu ích thường nằm ở phút thứ hai.

Kết thúc bằng một điều chỉnh cụ thể, do hai bên cùng đặt ra: "Lần sau trước khi gửi ra ngoài, em cho anh xem 30 phút trước nhé." Cụ thể, có giới hạn thời gian, và rõ ràng là tạm thời chứ không phải án chung thân.

Giữ quyền sở hữu cho họ

Nguyên tắc quan trọng: người làm hỏng nên là người sửa, trừ khi gấp tới mức không kịp. Lý do là sửa chính lỗi mình gây ra là cách học sâu nhất, và nó giữ cho họ cảm giác vẫn làm chủ việc.

Nếu bạn buộc phải nhảy vào vì gấp, hãy nói rõ ràng đây là ngoại lệ và trả lại quyền ngay sau đó: "Lần này anh xử lý phần gửi khách vì hạn tối nay. Phần sửa dữ liệu vẫn là của em, xong báo anh."

Sai lầm thường gặp

  • Tự làm lại và không nói gì — người kia mất cơ hội học và mất niềm tin.
  • Nói chuyện lúc đang nóng, trộn lẫn sửa việc với trách người.
  • Mặc định là lỗi thái độ trong khi thường là lỗi đề bài hoặc hệ thống.
  • Rút hết quyền vĩnh viễn sau một lần hỏng.
  • Nói "không sao đâu" rồi âm thầm không giao việc gì nữa.

Checklist kết bài

  • [ ] Tôi tách sửa hậu quả, tìm nguyên nhân và điều chỉnh thành ba bước riêng.
  • [ ] Tôi chẩn đoán được hỏng vì đề bài, kỹ năng, hệ thống hay ưu tiên.
  • [ ] Tôi mở đầu bằng dữ kiện và nghe hết trước khi kết luận.
  • [ ] Người làm hỏng vẫn là người sửa, trừ khi quá gấp.
Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi