为什么我们害怕说真话？#
在东方的职场文化中，「和为贵」 的思想根深蒂固。我们害怕冲突，害怕得罪人，害怕因为一句批评而破坏了同事关系。
于是，在 Code Review 时，我们明明看到了一坨「屎山」 ，却委婉地说：「这个逻辑是不是可以再优化一下？」在需求评审时，我们明明觉得这个功能毫无价值，却沉默不语，心里想着：「反正产品经理让做就做呗，到时候没人用也不关我事。」
这种「一团和气」的背后，是对产品、对团队、对公司最大的不负责任。这是一种伪善。我们是否真的能做到在关怀与挑战之间找到平衡，让团队敢于直言不讳，共同成长？
什么是「直言不讳」？#
「直言不讳」 （Radical Candor）不是让你做一个只会喷人的「杠精」，也不是让你进行人身攻击。它包含两个核心要素：
-
个人关怀（Care Personally）：你必须发自内心地关心对方，希望对方成长，希望项目成功。
-
直接挑战（Challenge Directly）：在关怀的基础上，直接指出问题，不拐弯抹角，不留情面。
这两者缺一不可。
-
只有直接挑战没有个人关怀，那是恶意攻击（Obnoxious Aggression）。
-
只有个人关怀没有直接挑战，那是滥用同情（Ruinous Empathy），这是最常见的职场烂好人，最终会害了对方。
-
既没有关怀也没有挑战，那是虚伪操纵（Manipulative Insincerity），纯粹的职场厚黑学。
为什么产品研发需要「直言不讳」？#
软件工程是一个极其复杂的智力活动，没有人是全知全能的。
-
纠错成本：一个架构设计的缺陷，如果在设计评审阶段被指出，改动成本可能只是几句话；如果在代码写完后被指出，成本是几天；如果在上线后才暴露，成本可能是巨大的经济损失和品牌信誉。直言不讳能将纠错点尽可能前移。
-
激发创意：最好的创意往往是在激烈的思想碰撞中产生的。如果大家都唯唯诺诺，只会产出平庸的产品。
-
建立信任：这听起来很反直觉，但真正的信任不是建立在客客气气上，而是建立在「我知道你会为了我好而告诉我真相」上。当你可以放心地把后背交给战友，相信他会在你犯错时第一时间拉你一把，这才是最坚固的信任。
如何践行「直言不讳」？#
1. 对事不对人#
这是老生常谈，但很难做到。批评时，请聚焦于具体的行为和结果，而不是对方的性格或能力。
-
错误示范：「你写的代码太烂了，你是不是没带脑子？」（攻击人）
-
正确示范：「这个函数的复杂度太高了，嵌套了五层，导致可读性很差，且难以测试。建议拆分成几个子函数。」（讨论事）
2. 接受被怼的雅量#
作为团队的 Leader 或资深员工，你要带头接受批评。当新人指出你的错误时，不要急着辩解，先听完，如果是对的，公开承认并感谢他。
在 ThoughtWorks，我们有一种文化叫「No VIP」 。无论你是刚刚入职的毕业生，还是工作二十年的总监，在技术真理面前，人人平等。如果架构师的设计有漏洞，应届生完全可以跳起来反对。
3. 赞美要公开，批评要私下？不一定。#
传统的管理学建议「公开赞美，私下批评」。但在高绩效的技术团队中，对于技术问题、设计方案的批评，公开进行往往更有效。因为这不仅仅是纠正一个人的错误，更是一次全员学习的机会，也是树立技术标准的时刻。
当然，如果涉及到个人态度、职业素养等敏感问题，仍然建议私下沟通。
结语：良药苦口#
直言不讳就像是一剂中药，入口虽苦，却能治病救人。
在一个充满不确定性的商业世界里，我们就像是一群在迷雾中探险的旅人。只有每个人都敢于大声喊出自己看到的悬崖和陷阱，我们这支队伍才能走得更远。
别做那个为了「面子」而眼睁睁看着船沉没的水手。