在互联网安全领域，有一种被大公司广泛接受的文化：灰帽子黑客——那些发现漏洞并主动向企业报告的人，往往可以获得奖金、致谢，作为对他们工作的肯定。因为他们发现的安全缺陷，哪怕只是某个不易察觉的参数注入点，也可能避免巨额损失、挽回公司信誉。然而，如果针对产品的「修复问题」「改进体验」，当你不是提交一份漏洞报告，而是反馈产品体验改进建议，情况就截然不同了：你可能被无视，被敷衍，甚至被当成「惹麻烦的人」「吹毛求疵者」，保守嘲讽。那些建议不但不会被奖励，最多是收到一句冷冰冰的回复——「谢谢反馈，我们会考虑的」——然后石沉大海。漏洞的后果是可见的、可衡量的、带着损失的可能；而产品体验的改进则属于另一类——模糊、长期持续、无法即时量化的收益。在管理学上，这叫做「可见性偏好」（Visibility bias）。优化一个更顺畅的注册流程、一个用户使用起来更为习惯的功能改进、一次界面交互的迭代，可能短期内不会「救火」，也不会出现在季度报表上。更糟的是，有时意味着需要部门协作、资源调整、产品路线的重新审视——所有这些，都是大公司的「聪明员工」不愿碰触的麻烦。被奖励的行为会被重复。组织行为学理论认为，行为会因为随之而来的奖励或惩罚而被强化或削弱。回想起在大公司工作的那些年，每逢季度末或年度评奖，公司总是更愿意给那些启动新项目、大项目的团队发奖。恕我直言，新项目大项目有些最后也没有达到预期的收益，为数不少都是草草收场，但即使如此，而从未见过有人因为「把老产品做得更好」而获得表彰。激励导向非常明确：要出业绩，去做新的；不想背锅，别碰旧的。于是，员工都学会了策略性地选择任务：与其修修补补，不如做个新产品、搭个新功能。那些已经发布的产品，即便还有数百万用户在使用，也被选择性的忽视，逐渐无人问津——除非有人足够天真，或足够固执。我记得有一位年轻的同事，技术能力出色，逐渐接手了绝大多数的 Bug 修复工作。他做了许多没人愿意做的「脏活累活」，为产品的改进默默贡献。然而这些工作在绩效考核中几乎没有权重。他从未得到过晋升，直到有一天，他提出了离职，去了一家顾问公司。许多同事都替他惋惜，但也无能为力——因为在那套激励逻辑里，他的工作是「必要的」，却不是「值得奖励的」。在错误的激励模式下，即便是在做正确的事，人也很难长期保持热情。为什么那些大公司的产品，即使还有大量用户在用，但也显而易见的疏于维护，不再更新，日渐荒芜，杂草丛生。当然有历史遗留的技术债务困境，新人不敢碰。但更重要的原因还是在于，做这样的事情不会得到内部的激励和认可。产品团队的资源往往倾向于做「新东西」，因为只有新东西才更容易被看见，容易写进季度 KPI、OKR，容易成为汇报材料上的亮点。至于那些仍在默默运转的老系统，哪怕它们是公司现金流的基础，也可以是「等一等」「下个季度再说」。我们经常听说某大公司把年度「创新大奖」颁给某某团队，但从来没听说哪家公司颁发一个「翻新大奖」。激励结构决定组织的行为。一家企业究竟是在不断修补漏洞的循环里原地踏步，还是在迭代优化中持续进化，很大程度上取决于它是否愿意为「改进」付出与「创新」同等的尊重和回报。当企业的奖赏只流向「防止损失」和「启动新事物」的时候，「把已有的东西做得更好」自然就成了无人问津的事情。那时，产品的衰老就不再是技术问题，而是一种不可避免的命运。 文章原文