Phản hồi Đánh Đúng Chỗ: Đưa ra và Tiếp nhận Phê bình như một Kỹ sư

Không ai dạy kỹ sư cách đưa ra phản hồi. Chúng ta dành nhiều năm học cấu trúc dữ liệu, design pattern, và deployment pipeline, rồi một ngày đồng nghiệp submit pull request làm chúng ta nghiến răng — và chúng ta không biết phải làm gì với cảm giác đó. Hoặc chúng ta không nói gì (con đường ít kháng cự nhất), hoặc chúng ta nói điều gì đó đánh như gạch: ngắn gọn, khắc nghiệt, và bằng cách nào đó mang tính cá nhân, dù chúng ta không có ý đó.

Điều tương tự áp dụng ngược lại. Khi lead nói với bạn "code này quá phức tạp" hay đồng nghiệp nói "tôi không chắc về cách tiếp cận này", hệ thần kinh của chúng ta coi nó như mối đe dọa. Phòng thủ bật lên. Chúng ta biện hộ, né tránh, hay ngồi trong oán giận thầm lặng suốt phần còn lại của sprint. Cả hai đều không giúp chúng ta phát triển.

Hướng dẫn này là cẩm nang thực địa cho cả hai phía của cuộc trò chuyện đó. Chúng ta sẽ xem xét điều gì làm phản hồi thực sự có hiệu quả, đi qua các kịch bản sẵn sàng dùng cho tình huống khó xử, và đề cập đến cách tiếp nhận phê bình mà không mất bình tĩnh. Dù bạn là sinh viên mới ra trường đang đưa ra review code đầu tiên hay staff engineer đang cố làm phản hồi cảm thấy an toàn trong nhóm, có điều gì đó ở đây cho bạn.

Tại sao phản hồi cảm thấy khó

Phản hồi là một hành động xã hội mặc bộ quần áo chuyên nghiệp. Bề ngoài nó nói về code hay quyết định thiết kế. Bên dưới, nó thường chạm đến danh tính — câu chuyện chúng ta kể về bản thân về mức độ có năng lực của mình. Khi ai đó đặt câu hỏi về công việc của chúng ta, bộ máy phát hiện mối đe dọa của não không phải lúc nào cũng phân biệt được giữa "function này quá dài" và "bạn không đủ giỏi".

Hai nỗi sợ thường chi phối:

• Sợ xung đột (với người đưa ra). Nếu họ phản đối thì sao? Nếu trở nên khó xử thì sao? Nếu họ nghĩ tôi không công bằng thì sao? Những kỹ sư có xu hướng hướng nội — và đó là nhiều người trong chúng ta — thường thích sự thoải mái tạm thời của im lặng hơn sự khó chịu ngắn hạn của sự thành thật.
• Sợ trông kém cỏi (với người nhận). Đặc biệt khi bạn là junior, hay mới trong nhóm, hay đang trong giai đoạn chứng tỏ bản thân, phê bình có thể cảm thấy như bằng chứng cho điều tệ nhất bạn nghi ngờ về mình.

Đây là sự thật khó chịu: tránh phản hồi không làm những cảm giác đó biến mất. Nó chỉ để vấn đề tích luỹ. Kỹ sư junior không bao giờ nhận được tín hiệu thành thật tiếp tục xây dựng những thói quen tương tự. Kỹ sư senior có lựa chọn kiến trúc không bao giờ bị đặt câu hỏi ship hệ thống ngày càng mỏng manh. Nhóm tránh những cuộc trò chuyện khó cuối cùng phải có chúng — chỉ là vào thời điểm tệ nhất có thể, dưới áp lực tệ nhất có thể.

Tin tốt là đưa ra và tiếp nhận phản hồi là kỹ năng, không phải đặc điểm. Chúng có thể được luyện tập, và một cải thiện nhỏ trong cách bạn đặt câu hay cách bạn phản hồi phê bình tạo ra sự khác biệt có thể đo được trong các mối quan hệ công việc của bạn.

Phản hồi tốt thực sự trông như thế nào

Trước khi đến các kịch bản, sẽ hữu ích khi hiểu chúng ta đang hướng đến điều gì. Phản hồi tốt có bốn thuộc tính:

• Cụ thể. Nó đặt tên cho thứ gì đó cụ thể — một file, một function, một cách diễn đạt, một hành vi trong cuộc họp — thay vì vẫy tay về một cảm giác mơ hồ. "Service này làm quá nhiều thứ" là điểm khởi đầu; "UserService xử lý cả authentication lẫn cập nhật profile, và điều đó khiến khó test cái nào trong cô lập" là phản hồi ai đó có thể hành động theo.
• Kịp thời. Phản hồi được đưa ra ngay sau sự kiện hữu ích hơn và ít nặng nề về mặt cảm xúc hơn so với phản hồi được giao nhiều tuần sau, khi ngữ cảnh đã mờ và công việc đã tiến lên. Comment review code hiệu quả nhất khi tác giả còn nhớ lý luận. Quan sát một-một hiệu quả nhất trong tuần chúng xảy ra.
• Về hành vi hay công việc — không phải về người. Có sự khác biệt có ý nghĩa giữa "bạn luôn làm quá phức tạp mọi thứ" (tấn công tính cách) và "trong ba PR gần đây tôi thấy, logic chuyển đổi dữ liệu được chia ra nhiều lớp abstraction, khiến khó theo dõi" (quan sát về công việc). Cái đầu tiên đưa ai đó ra toà xét xử. Cái thứ hai cho họ thứ gì đó để xem xét.
• Hành động được. Phản hồi tốt ngụ ý (hoặc nêu rõ) một con đường tiến lên. "Cái này khó đọc" để ai đó bế tắc. "Extract logic mapping vào một function được đặt tên với return type rõ ràng sẽ làm cái này dễ theo dõi hơn" cho họ bước tiếp theo.

Mô hình SBI

Một cấu trúc đơn giản giữ cả bốn thuộc tính đó lại với nhau là mô hình Situation–Behaviour–Impact (Tình huống–Hành vi–Tác động), ban đầu được phát triển cho đào tạo lãnh đạo và hiện được dùng rộng rãi trong các nhóm phần mềm. Bạn không cần triển khai nó một cách cứng nhắc trong mọi comment, nhưng đây là một scaffold đáng tin cậy khi bạn không chắc cách bắt đầu.

Trong thực tế, SBI nghe như thế này: "Trong incident review hôm qua [tình huống], khi bạn ngắt lời kỹ sư on-call ba lần trong khi họ đang giải thích phát hiện của mình [hành vi], nó làm khó cho nhóm theo dõi timeline và tôi nhận thấy kỹ sư on-call ngừng đóng góp sau đó [tác động]."

Hãy chú ý rằng không phần nào trong ba phần đó phán xét ý định ("bạn đang cố kiểm soát phòng"), gán đặc điểm tính cách ("bạn coi thường người khác"), hay tổng quát hoá ("bạn luôn làm vậy"). Nó mô tả những gì đã xảy ra, một cách thực tế, và những gì theo sau từ đó. Đó là lý do nó có xu hướng không kích hoạt phản ứng phòng thủ.

Các kịch bản sẵn sàng dùng: từ mơ hồ đến cụ thể

Hầu hết chúng ta có phản ứng bản năng với công việc của người khác — cảm giác rằng điều gì đó không ổn, hay có thể tốt hơn — trước khi chúng ta có lời cho nó. Thách thức là chuyển bản năng đó thành phản hồi mà người kia thực sự có thể sử dụng. Bảng dưới đây cho thấy các phản ứng mơ hồ hay nặng nề phổ biến bên cạnh các lựa chọn thay thế sạch hơn, cụ thể hơn.

Lời khen cũng là phản hồi

Kỹ sư thường thoải mái hơn khi chỉ ra vấn đề so với thừa nhận những gì đang hoạt động. Nhưng phản hồi tích cực — khi nó cụ thể — là một trong những thứ có đòn bẩy cao nhất bạn có thể cho đồng đội. Nó cho họ biết tiếp tục làm gì, điều cũng hữu ích như biết phải dừng điều gì.

Bẫy là lời khen mơ hồ. "Làm tốt lắm với migration" tốt hơn không có gì, nhưng không dạy ai điều gì. Điều gì cụ thể là tốt? Tính kỹ lưỡng của kế hoạch rollback? Cách bạn truyền đạt trạng thái cho stakeholder? Thực tế bạn chạy migration trong canary trước khi đụng đến production? Mỗi cái trong số đó là một bài học khác nhau, và đặt tên cho nó làm nó có thể lặp lại.

Một vài nguyên tắc cho lời khen thực sự có tác dụng:

• Cụ thể về hành vi. Dùng cùng cấu trúc SBI: "Trong incident review hôm thứ Tư, khi bạn đi qua failure mode từng bước một, nó đã giúp cả nhóm hiểu root cause nhanh chóng."
• Đặt tên tác động. "Kế hoạch rollback rõ ràng bạn viết có nghĩa là khi chúng ta gặp edge case, kỹ sư on-call biết chính xác phải làm gì. Điều đó đã tiết kiệm chúng ta ít nhất 40 phút nhầm lẫn."
• Làm nó công khai khi xứng đáng. Lời khen riêng tư thì có ý nghĩa. Lời khen công khai — trong kênh nhóm, trong retrospective, trong group code review — báo hiệu cho cả nhóm biết xuất sắc trông như thế nào. Nó cũng có ý nghĩa rất nhiều với người nhận, đặc biệt nếu họ là junior hay mới với công ty.
• Đừng trì hoãn nó. Lời khen suy giảm giá trị giống như phản hồi mang tính xây dựng. Nếu bạn nhận thấy ai đó làm điều gì đó tốt, hãy nói trong tuần đó.

Có lý do tốt khiến hướng dẫn về văn hoá review code thường đặc biệt nhắc đến tầm quan trọng của comment tích cực: một PR chỉ bao giờ có quan sát phê bình bắt đầu cảm thấy như bãi mìn, dù tất cả quan sát đều công bằng. Một comment nói "tôi thích abstraction này — sạch" tốn bạn năm giây và có thể thay đổi toàn bộ tông cảm xúc của một review.

Tiếp nhận phản hồi tốt

Nếu đưa ra phản hồi tốt là khó, tiếp nhận nó tốt có thể còn khó hơn. Phê bình đến khi bạn đang đầu tư cảm xúc vào công việc. Đôi khi nó đến với cách trình bày kém — cộc lốc, không rõ ràng, hoặc thậm chí không tử tế. Và khoảng cách giữa "ai đó đang chỉ trích code của tôi" và "ai đó đang chỉ trích tôi" hẹp hơn chúng ta muốn, về mặt thần kinh học.

Đây là thực hành năm bước giúp ích:

1. Giả định thiện chí cho đến khi được chứng minh ngược lại. Hầu hết kỹ sư để lại comment review phê bình đang cố làm code tốt hơn, không phải cố làm bạn cảm thấy tệ. Hãy bắt đầu từ đó. Nếu cách trình bày thô, hãy tách cách trình bày khỏi tín hiệu — một cái có thể kém trong khi cái kia có giá trị.
2. Tạm dừng trước khi trả lời. Nếu bạn cảm thấy một đợt phòng thủ, đó là thông tin: phản hồi đã chạm vào điều gì đó thật. Đừng phản ứng từ đợt đó. Thở. Đọc lại comment sau 10 phút. Nếu là cuộc trò chuyện trực tiếp, hoàn toàn ổn để nói "để tôi suy nghĩ về điều đó".
3. Đặt câu hỏi làm rõ. Nếu phản hồi mơ hồ — "cái này cảm thấy overengineered" — bạn có quyền hỏi về sự cụ thể. "Phần nào cụ thể cảm thấy overengineered với bạn? Đó là số lượng abstraction, interface surface area, hay điều gì khác?" Đây không phải là thách thức; đây là cách bạn nhận được phản hồi có thể hành động theo.
4. Tách tín hiệu khỏi cách trình bày. Ai đó có thể đúng về bản chất và sai về cách họ nói. Công việc của bạn là trích xuất tín hiệu hữu ích và quyết định có hành động theo không. Bạn không phải thưởng cho cách trình bày kém, nhưng bạn cũng không phải để nó ngăn bạn học được điều gì đó thật.
5. Nói cảm ơn. Dù bạn không đồng ý với phản hồi, thừa nhận rằng ai đó dành thời gian đưa ra một quan điểm là thực hành tốt. "Cảm ơn đã chỉ ra — tôi sẽ suy nghĩ về điều đó" thành thật và đóng vòng lặp mà không cam kết bạn đồng ý.

Đưa ra phản hồi lên trên và cho đồng nghiệp

Hầu hết hướng dẫn về phản hồi được viết từ quan điểm của người cấp trên đưa ra phản hồi cho người cấp dưới. Nhưng hai trong số những hướng quan trọng nhất — và ít được thảo luận nhất — là ngang hàng và hướng lên.

Phản hồi đồng nghiệp

Đưa ra phản hồi thành thật cho đồng nghiệp cùng cấp có thể cảm thấy khó xử vì không có thẩm quyền chính thức để dựa vào. Nó có thể cảm thấy như đang vượt quyền. Nhưng không phải vậy. Phản hồi đồng nghiệp, được trình bày tốt, là một trong những thứ được đánh giá cao nhất trong nhóm hiệu quả cao.

Một vài điều giúp ích: đặt nó như một câu hỏi khi bạn không chắc ("Tôi nhận thấy X — đó là chủ ý không?"), đưa ra trong ngữ cảnh một-một trước diễn đàn công khai, và tập trung vào công việc chứ không phải người. Nếu bạn có mối quan hệ công việc liên tục, đầu tư vào phản hồi thành thật xây dựng tin tưởng theo thời gian. Người luôn nói với bạn những gì bạn muốn nghe thì dễ chịu; người nói sự thật thì hữu ích.

Phản hồi hướng lên

Đưa ra phản hồi cho manager hay tech lead của bạn thực sự khó hơn. Có sự bất cân xứng quyền lực, và ngay cả nhóm an toàn về mặt tâm lý nhất cũng không thể xóa hoàn toàn điều đó. Một số cách tiếp cận thực tế:

• Dùng một-một. Cuộc trò chuyện riêng tư là địa điểm đúng. Đừng đưa ra phản hồi chạm đến hành vi của manager trong cuộc họp nhóm — điều đó không công bằng với họ và tạo ra khán giả không ai trong hai bạn cần.
• Tập trung vào tác động, không phải tính cách. "Khi phạm vi sprint thay đổi trong hai ngày cuối, tôi thấy khó ưu tiên tốt — có cách nào để lock phạm vi sớm hơn một chút không?" dễ nghe hơn "bạn tiếp tục thay đổi phạm vi vào phút chót". Cái đầu tiên mô tả vấn đề để giải quyết cùng nhau; cái thứ hai nghe như cáo buộc.
• Cụ thể và hướng đến tương lai. Đặt tên những gì đã xảy ra một hoặc hai lần — không phải một pattern tổng quát — và mô tả điều gì sẽ giúp ích. Leader nhận phản hồi theo cách này hầu như luôn phản hồi tốt hơn so với sự bất mãn mơ hồ.
• Chọn thời điểm của bạn. Đừng đưa ra phản hồi hướng lên khi manager đang ở giữa khủng hoảng, dưới áp lực deadline, hay rõ ràng đang căng thẳng. Một-một bình tĩnh — không phải cái năm phút trước cuộc họp board — là khi nó tiếp nhận tốt.

Phản hồi theo ngữ cảnh và quy mô nhóm

Không phải mọi phản hồi đều xảy ra trong cùng bối cảnh, và cách tiếp cận đúng thay đổi tùy theo nơi bạn ở.

Trong code review

Code review là kênh phản hồi phổ biến nhất đối với hầu hết kỹ sư, và nó có chuẩn mực riêng. Comment viết là không đồng bộ, có thể đọc lại, và vĩnh viễn — có nghĩa là chúng cần thêm sự quan tâm, không phải ít hơn. Một comment có thể ổn khi trực tiếp ("cái này hơi dài") có thể đọc là lạnh lùng hay coi thường trong PR. Thêm một câu ngữ cảnh ("cái này hơi dài — extract logic validation vào function riêng có thể giúp khả năng đọc") tốn ít và giúp nhiều. Xem bài đồng hành về review code nhã nhặn để đi sâu hơn vào ngữ cảnh cụ thể này.

Trong một-một

Một-một là ngôi nhà tự nhiên cho phản hồi mang tính cá nhân hơn, nhạy cảm hơn, hay theo chiều thời gian hơn — các pattern theo thời gian, hướng nghề nghiệp, động lực liên cá nhân. Tính đồng bộ, riêng tư có nghĩa là bạn có thể theo dõi người kia đang tiếp nhận thế nào và điều chỉnh. Chuẩn bị một hai điểm cụ thể thay vì đến với danh sách các bất bình tích luỹ nhiều tháng.

Trong incident review (post-mortem blameless)

Incident review là ngữ cảnh phản hồi chuyên biệt với một quy tắc không thể thương lượng: blameless. Mục tiêu là hiểu những gì đã xảy ra và cải thiện hệ thống, không phải gán lỗi cho cá nhân. Trong thực tế, điều này có nghĩa là phản hồi được hướng đến quy trình, tooling, và khoảng trống kiến thức — không phải đến con người. "Alerting của chúng ta không bắt được memory leak đủ sớm — chúng ta có nên thêm threshold alert không?" là đúng giọng điệu. "Tại sao bạn không bắt được cái này?" thì không. Các nhóm thành thạo retrospective blameless trở nên tốt hơn đáng kể trong việc học từ thất bại.

Theo quy mô nhóm

Các nhóm nhỏ (dưới mười người) thường có văn hoá phản hồi không chính thức — mọi thứ được nói trong cuộc trò chuyện, trong thread Slack chung, hay lúc ăn trưa. Sự không chính thức đó là ưu điểm: phản hồi xảy ra nhanh và thường xuyên. Rủi ro là nó cũng có thể trở nên không nhất quán hay không bình đẳng, nơi một số người nhận được nhiều input thành thật và những người khác không nhận được gì. Khi nhóm lớn lên, cấu trúc nhẹ — một-một thường xuyên, thời gian retro rõ ràng, chuẩn mực PR viết ra — giúp đảm bảo phản hồi được phân phối công bằng thay vì chỉ chảy theo các đường xã hội hiện có.

Văn hoá phản hồi được xây dựng từng cuộc trò chuyện một. Bắt đầu với PR tiếp theo bạn review: thêm một comment tích cực cụ thể bên cạnh các phê bình của bạn, và thử đặt một quan sát theo SBI. Trong vài tháng, thói quen đó thay đổi cách cả nhóm giao tiếp. Khi bạn sẵn sàng đầu tư sâu hơn vào phía con người của kỹ thuật, hãy tiếp tục với Cố vấn Kỹ sư — cái nhìn về cách giúp ai đó phát triển theo vòng cung dài hơn của nghề nghiệp của họ.