Vì sao feedback rất quan trọng?
Bài viết được sự cho phép của tác giả Huy Trần
Có một điều chắc các bạn cũng nhận ra, là khi làm việc với nhiều khách hàng Âu Mỹ hay Nhật, họ thường rất chịu khó đưa ra lời khen ngợi khi chúng ta làm gì đó tốt, thậm chí là chưa tốt, và họ cũng không ngần ngại chỉ trích hay góp ý khi có điều gì đó ngứa tai gai mắt.
Đây là một kĩ năng communication rất quan trọng. Gọi là Giving Feedback.
Xem thêm tuyển dụng C++ hấp dẫn trên Station D
Feedback có thể hiểu là đưa ra ý kiến phản hồi cho một ai đó về một cái gì đó sau một chuyện gì đó.
Có 3 loại feedback thường thấy, đó là:
- Positive Feedback: phản hồi
dương tính, à nhầmmang tính tích cực, đưa ra để cho đối phương biết mình ghi nhận những cố gắng của họ, rằng đang làm tốt một việc gì đó, khích lệ họ để keep it up. - Constructive Feedback: phản hồi mang tính xây dựng, đưa ra với mục đích cho đối phương biết hành động của họ cần phải thay đổi.
- Destructive Feedback: đây là thể loại constructive feedback phiên bản lỗi, được đưa ra một cách vội vã thiếu tế nhị, không đúng nơi đúng chỗ, hoặc đúng người nhưng sai thời điểm. Cũng là loại feedback phổ biến nhất ở trên đường, cũng như ở trên mạng. Tác dụng của nó là zero, còn tác hại thì vô cùng. Mình nghĩ người ta hay đưa ra kiểu feedback này chỉ vì ngứa mồm. Ở nhiều nơi mà cuộc sống khắc nghiệt, thì người đưa ra feedback có khả năng nhận được gói mát xa tẩm quất miễn phí chỉ cần trả tiền viện phí.
Ví dụ ở đoạn mở bài có nhắc tới, bạn làm gì cũng đc khách hàng khen, kể cả trễ deadline, thì đó gọi là positive feedback. Khi đồng đội mình hoàn thành dự án và launch thành công thì các sếp thường mở launch party và đọc tên từng người để ghi nhận công lao, đó là positive feedback. Coi Rap Việt ta thường thấy các bạn thí sinh shout out to my teacher Binz hay to anh em homie DCOD thì đó cũng là positive feedback.
Khi bạn thấy một ai đó làm gì sai, bạn muốn họ sửa, hoặc bạn tìm ra một con bug của một phần mềm nào đó và bạn viết bug report, bạn muốn đưa ra một ý tưởng gì đó để cải thiện, cũng lại coi Rap Việt bạn thấy Binz hay đưa ra phân tích về flow, vần của thí sinh, hay bạn thấy anh em WeBuild đưa ra feedback là ko biêt bao giờ huytd lại drop project, phần lớn trong số đó là constructive feedback mặc dầu tùy theo cách đưa ra feedback, nó sẽ trở thành destructive feedback.
Vậy thì phải đưa ra feedback như thế nào?
Có 2 yếu tố quan trọng khi đưa ra feedback đó là:
- Be specific: đưa ra feedback đúng nơi đúng chỗ và đúng nội dung, và feedback như nào để người ta có thể take action được. Bạn không nên thấy một người mới start một cái side project và bay vào nói “Để xem khi nào anh drop”, vì nó ko add thêm value gì cho anh ấy cả, và khi nghe feedback như thế thì bạn expect họ sẽ làm gì?
- Be timely: Thường thì real time feedback là tốt nhất, nhưng nếu tình thế ko cho phép thì cũng nên đưa ra feedback trong vòng 48 tiếng đồng hồ (ví dụ các bạn gái khi thấy người yêu mãi chơi game ko lo xếp quần áo, thì thay vì chạy tới rút dây máy PS5, nên bình tĩnh chờ người ta đánh xong ván đã, rồi hãy bắt úp mặt vô tường quỳ gối, nhưng cũng đừng nên chờ 1 tuần sau mới lôi ra nhắc lại chuyện cũ để rồi bị nói là nắng mưa vô cớ).
Để đưa ra feedback một cách tốt hơn, người ta nghĩ ra rất nhiều mô hình, các bạn có thể search thêm với từ khóa “Feedback Model”, hoặc đọc thêm tại đây hoặc đây.
Nhìn chung, các mô hình này đều xoay quanh 4 yếu tố:
- Context: Nói về tình huống khi bạn nhìn thấy sự việc xảy ra.
- Behavior: Nói về hành vi của những người liên quan đế vấn đề bạn đang feedback. Nói một cách khách quan nhất, và đừng có đánh giá gì về hành động đó cả.
- Impact: Nói về ảnh hưởng mà hành động đó gây ra, và nó tác động đến bạn hoặc những người xung quanh như nào.
- Follow Up: Đưa ra gợi ý về những gì người nhận feedback cần hoặc nên làm.
Ví dụ, bạn đang review code và phát hiện ra một vấn đề gì đó nên sửa:
- “Code như cức, senior rồi mà còn code như này à?!” – Destructive feedback
- “Tôi thấy chỗ này bạn xài let với const hơi lộn xộn, nó không ảnh hưởng gì nhiều về mặt logic nhưng làm vậy code style sẽ trở nên thiếu đồng nhất, tôi nghĩ bạn nên sửa hết về let, ý bạn sao?” – Constructive feedback
Một ví dụ khác, bạn Tèo vừa bỏ ra 1 ngày trời để setup mấy cái github actions giúp tự động chạy unit test trên mỗi PR của team, giúp nâng cao chất lượng code của cả team, là một teammate, bạn có thể làm gì?
- Lên slack và post: “Shout out to my Tèo homie, cái github actions tự động chạy test của bạn ấy giúp cho cả team mình thấy yên tâm hơn khi fix code. Keep it up man!” – Positive feedback
- Im lặng ko nói gì – No feedback = Destructive feedback, đến kì lương sau thì ko ai thấy Tèo đi làm nữa.
Một ví dụ khác nữa, lên WeBuild thấy một bạn thành viên mới post lên rằng: “Hi @channel, mình là mem mới, rất vui được làm quen với các bạn”, phản ứng của mọi người là:
- Đồng loạt thả những cái reaction giận dữ, vào comment: “Bớ admin ơi có đứa tag channel!!!”, “Bà nội mày ai cho mày tag channel!!!!”, rồi thi nhau leave room – Destructive feedback, bị chửi bạn mem mới kia sẽ lồng lộn lên chửi lại rồi bỏ WeBuild mà đi, có khi đi nơi khác mà chửi WeBuild ko thương tiếc.
- Vào comment hoặc ping riêng một cách nhã nhặn: “Bạn ơi, vừa rồi mình thấy bạn tag channel ở #general, đây là public channel nên có mấy nghìn thành viên lận, tag vậy sẽ làm phiền mọi người đấy, bạn edit lại đi nha.” – Constructive feedback, nếu nhận được phản hồi như thế này, mình không nghĩ có ai cảm thấy offense và sẽ vui vẻ sửa sai ngay.
Các bạn thấy đấy, việc đưa ra feedback là rất quan trọng và cần thiết, và đưa ra feedback như nào lại quan trọng không kém. Cái ranh giới giữa constructive feedback và destructive feedback nó chỉ cách nhau một cái ngứa mồm và một nhịp cảm xúc.
Be a good communicator, don’t be that person.
Bài viết gốc được đăng tải tại thefullsnack.com
Có thể bạn quan tâm:
- Con đường trở thành Business Analyst của Tester
- Nếu một ngày tôi không còn mặn mà với lập trình nữa?
- Product Manager là gì? Có gì khác biệt trong công việc của Owner Product với Product Manager?
Xem thêm tuyển dụng các vị trí CNTT hấp dẫn trên Station D
