聊聊程序员的知识诅咒问题
关于知识诅咒
张一鸣在字节跳动9周年年会上，特意念了一段他从字节跳动双月会的材料里摘出来的一段话，以此来讽刺所谓的“互联网黑话”。在这段话里，不乏“生态闭环”、“服务链路”、“赋能”、“场景价值”、“价值链路”等词汇。他最后告诫大家很多重要决策并不需要那么复杂的描述。这就是一个典型的“知识诅咒”，在程序员的世界里更加容易出现知识诅咒，这篇文章我想聊聊这个话题。
知识诅咒
知识诅咒最早是在《Made to stick》里提出来的，关于知识诅咒书里面是这么解释的：
“如果我们很熟悉某个对象的话，那么我们会很难想象，在不了解的人的眼中，这个对象是什么样子的。我们的知识水平会对我们产生影响，使我们不能从别人的角度看世界，不能准确评估别人知道、理解多少。我们被我们所掌握的知识「诅咒」了。”
程序员的“知识诅咒”
对一件事越是熟悉就越容易陷入“知识的诅咒”，就像程序员经常抱怨“连这么简单的操作都不会！”。
在计算机的专业领域里，程序员往往是非常擅长的，无意之中忽略了其他人对计算机理解程度。更进一步，程序员在产品思考、方案设计、代码开发的过程中也会在不经意间以自己的技术栈（甚至技术审美）为“标准”形成个人的技术判断，并由此开展程序研发的工作。
我记得有这么一句话，大概意思是：一个项目它的第一行代码就是它的技术负债的开始。以个人的技术判断来展开程序研发工作，大概率会增加项目的负债，处于这种情况的时候，整个项目就像被“诅咒”了一样变得越来糟糕。我相信这种被瘟疫蔓延的状态就是程序员的“知识诅咒”。
P.S. 如果你是一位 geek，程序员的知识诅咒可能对你并不适用，大多会被知识诅咒的程序员还是那种希望通过自己的程序/项目给别人带来价值的人。
“克服”知识诅咒
目前我有限的认知中这种知识诅咒无法避免，程序员大多都有技术情怀和追求，这注定程序员们从基因里面就是追求专精的，以自己专业的视角看世界是无法避免。但是我想说的，在产品的设计开发过程中通过一些“规范流程”来及时地帮助纠偏会很大程度上减轻甚至消除程序员的知识诅咒。
关于程序设计开发的这个“规范流程”有下发几个步骤：
- 建立用户画像
- 准确的用户表达
- 建立反馈机制
- 重复重复再重复
用户画像
程序员在开发设计中非常容易出现一个偏差：陷入自我为中心的“智力优越感”，这是一切知识诅咒的开端，所以要从源头就开始遏制。在开始动手做具体的事情的时候，问自己一个问题“我做的这件事情，它是为谁服务的？如果我是这个服务对象，我会有什么核心诉求？”。这两个问题不需要回答给任何人，答案唯一标准就是你自己扪心自问是否认可。
为什么会是这两个问题呢？其实是想从同理心的角度来看看自己的这个事情，是否是真正被期望的样子。而站在服务对象的角度来评价这个事情是一个好产品、好设计、好技术的黄金准绳。
“说人话“
大厂黑话估计作为程序员多少都有耳闻，除了调侃之余，我在这里也找到了解决关于程序员的知识诅咒的关键方法之一——“说人话”。程序员之所以会陷入信息不对称盲区，是因为表达不清晰。所以，在交流时一定要准确表达，尽量用最简单的语言，准确的数字，让别人明白你想表达什么，你的意图是什么，别让对方去猜。准确表达的另一个层面是，一定要“说人话”，要用通俗易懂的语言来进行沟通，而不是堆砌抽象的专业术语，让人看不明白。
无论在哪一步骤中，“说人话”地准确表达是真实思考和判断的前提，建立用户画像如此、寻求反馈如此、反馈分析更是如此。在构建用户画像的时候，包括以从用户视角考察用户真正的核心诉求以及服务的好坏，
寻求反馈
德鲁克在他的书《21世纪的管理挑战》自我管理一章里说过：要发现自己的长处，唯一途径就是反馈分析法（feedback analysis）”，关于“反馈分析法”的定义比较简单：
“反馈分析法。无论做出什么样的关键决策，采取什么关键措施，我们都要写下我们希望看到的结果。9～12个月以后，我们就可以将实际的结果与预期的结果进行对比。”
程序员在产品设计开发的过程中也需要进行自我管理，从而更加深刻地了解自己做的事情，所以可以先挑选自己拟定的用户画像和核心诉求付诸实践，一段时间后再将具体的方案、代码等等是否跟当初的思考分析（或者期望）进行对比。这样一套反馈机制可以帮助程序员不忘初心，逻辑自洽并不代表项目产品是自洽的，对无意识的技术审美进行纠偏及时调整产品项目的不足之处才是正途。
重复的力量
在程序员的知识系统里面，被认为是很简单的道理或者事情，对于别人来说，也可能是一件根本就无法理解的事情。所以，基于用户画像和反馈分析基础上得出的结论和预期是自洽的，但是这样的自洽需要放到更大的范围进行推广和验证，所以一定要不断重复，减少信息偏差，最后触发行为。 我想产品项目的成功协作大概就是需要这样的重复吧！
Public discussion