今天聊聊陆奇的 PPT 出错的事。
我在相关的问题下是这么回答的：
是测试版 = 有错别字就正常？这个解释很有百度特色。
说真的，我在过的公司，和我见过的公司，自我要求正常程度的，测试版的 PPT 里都不应该有错别字，尤其是重要发布会用的。
当年刘超老师的排版混乱、设计奇诡、标点错误可能意味着能力有限，但这次字都懒得写对，就真的是态度问题了。
产品文档的草稿如果也这么应付敷衍，抱着「无所谓反正不是最终版本」「无所谓反正早晚会改」「无所谓交工就好后面会有人擦屁股」的心态，是实习生我都不敢用。百度的病是进到骨子里了。
起笔就觉得今天要写的这个道理很简单，简单到中学生都可以命题作文，讲讲认真对于工作的重要性。不过我还是想多说几句，因为经历过几年的工作生活，颇深刻的体会就是，表面上无关紧要的小问题，深究的话，都是一个产品、一个公司抑或一个人成败的痕迹。
讲道理，重要的事情上出现错漏是难免的。PPT 的各种事故网上也有人总结过了，这些倒都是情有可原，未必非要上纲上线。知名的如锤子科技当年某场发布会，PPT 的故障导致三角兽出了名，也让大家惊叹老罗的圆场能力，那是源于 PPT 准备的确太过匆忙。
不过这次我反感的点在于，百度公关解释说，这是测试版 PPT。这说明至少存在两个问题：一，如此重大的发布会，没有人梳理和关注流程，而且现场发现有错，剩下的时间都没人更换；二，测试版的 PPT 制作者并不在意，也认为有错别字是正常情况。
说说我的一些感触吧。
过去有一次，技术那边实现的一个方案有误，我们追查了半天，发现是技术参考了产品经理最开始做方案的草稿，而不是最终的需求文档。这时候应该怪技术的问题吗？当然可以怪他没有仔细看方案的修改时间、看方案在 wiki 上所在的目录，但这都不是产品推卸责任的理由。错的方案和对的方案都扔在需求文档池里，别人误取了，放进去的人是不是也得负责任呢？
另外，还有一次，技术在实现某个功能时，效果跟我们想的差别很大，复盘时候发现是产品经理在写文案的时候比较随意，都用了像「这里是文本这里是文本这里是文本这里是文本这里是文本这里是文本这里是文本」和「blablablablablablabla」这样的填充，以及甚至有些错误的文案，导致技术理解有偏差。后来我的体会就是，一个合格的产品经理，不应该因为「嫌麻烦」而去随意填充文案、给未来大家理解上制造麻烦。
我在锤子科技的时候，有次因为一个表格写得表意不清而被老罗痛骂了一顿，后来我做任何演示、写任何文档，都养成了抠字眼的习惯，从来不会为了节省那么几秒钟时间敷衍，写「同上」，画明显有错的草稿，以及看到错别字也不改。老罗的很多理念我未必赞同，但这件事上我还是很感谢他，能让我养成了这样的习惯。
每次我听到下属的产品经理说，「这个是我写多了，到时候会改的」「这是原型图，UI 设计师会再改的」「这里不是这样的，先别在意，回头交互会处理」等等，我都会立刻打断他，让他当场改掉。把这种出错的机会留给以后的同事，或者留给以后的自己，就是把隐患留到后面，因为这么几秒钟的敷衍，会导致后面可能需要几天时间填的坑。
这种讲究不是傲娇和清高，追求完美什么的，而是真正提高效率，在事前把所有隐患除掉，降低日后的沟通成本和试错成本。有的人宁愿在演讲的时候花几分钟解释为什么图里有个不恰当的地方，也不愿意直接把图里的问题直接改掉，这很莫名其妙。
回过头来看百度这次 PPT 出错，显然也是这样的情况。做 PPT 的人，始终没觉得有这么严重的错别字是问题，「留给后人去解决吧」，肯定是抱着这种心态做事的。想想中国互联网 No.3 的公司，以这种心态在做事情，还是有点方的。
祝陆奇老师好运吧。
