Article Outline
一个很有争议性的话题是“产品经理要会写代码吗”？
写代码不是产品经理的核心能力，会不会写代码，都不会影响你做好需求。
但会写代码能让你做得更好。
代码，帮你思考
在之前写的文章“过度设计的原因不是想得太多，而是想得太少”中，我说：
过度设计并不是想得特多，而是想得不够。
会写代码的产品经理有机会想得够多。
首先，在思维模式方面，如果产品经理会写代码，会更容易理解自己业务的“真实”逻辑。
所有互联网产品的下层都是计算机系统。
无论你设计出多么花里胡哨的功能、策略，往下都是机器学习炼金术、增删改查 PHP 是最好的语言、顺序条件循环递归、或门与门非门异或门。
理解代码就具备穿透高层抽象看到底层逻辑的能力。如果两层之间存在逻辑纰漏，既理解业务又理解技术的人会更容易发现问题。
其次，在成本方面，会写代码的人，在产品设计上能够更准确地评估成本，知道了成本，对需求排期、做取舍也更加准确。
设计产品不是写 PRD 和画图。一个完备的产品方案背后，包含对用户需求、项目成本、商业模式、收益回报等多方面的深入思考。
其中，对成本、风险、收益的评估决定该方案是否可行。能写代码的人，在成本、风险、收益评估上，能比其他人得到更精确的结果。
做与想的差异
有意思是，“会写代码”和“真的去写”之间还有很大的区别。
上周我做了一个新需求，让用户能够在群中给指定人（例如群主）打赏。这个方案分几部分：
- 群主有独立的页面管理打赏对象
- 群主可以添加/删除打赏用户
- 群主可以设置用户是否可以被打赏
- 打赏可以选择打赏对象、设置金额、货币单位
- 打赏消息会出现在群聊天中
- 打赏的支付状态
- 打赏后会展示打赏是否成功的状态
总之，这是一个完备的打赏方案，整个方案该如何实现，接口如何设计，业务流程如何运作，我非常清楚。
后来由于资源问题，工程师没有时间做这个项目，我就花了一天时间把它做完了。完成后，我回头一看：
- 独立管理页面没了，群主可以在打赏界面直接添加/删除打赏对象；
- 设置用户是否可打赏也没了。设置打赏是一个低频操作，可以用添加、删除打赏对象代替；
- 打赏的支付状态没了。因为聊天中的打赏消息可以成为打赏是否成功的反馈。
因此以上的六个部分，我只完成了 2、4、5 这三点。
不实现完整的方案，是因为在“做”的过程中，才真的意识到了“哪些事”是必须做，“哪些事”是可以不做。完成这个功能的成本是我的时间，而时间宝贵，需要再次量化成本，再次做出取舍。
写代码在于创造
在我离开微信时，张小龙前辈跟我说了一句话：不要放弃写代码。
Good Point。但是我很快发现，不同人口中的“写代码”含义是不一样的。
能完成一道教科书习题、学完一门 Python 课程、实现一个快速排序、解决一题 LeanCode，嗯，虽然是在写代码，但不是在创造。只能说是在为创造做准备。
如果你的代码解决了一个问题，或者满足了一个需求，那这是创造。
写代码必须创造。
很多产品经理都喜欢称自己为“手艺人”，讲“三个石匠“的故事：
有人问三个石匠他们在做什么。第一个石匠回答：“我在养家糊口。”第二个石匠边敲边回答：“我在做全国最好的石匠活。”第三个石匠仰望天空，目光炯炯有神，说道：“我在建造一座大教堂。”
— 德鲁克《管理的实践》
德鲁克认为第三个石匠是真正的管理者，我们则觉得自己有第三个石匠的心。
但这个故事的问题就在于，它太简单了。第三个石匠不会告诉你，要想造大教堂专心当石匠是不够的。你还得学习很多其它的技能，比如绘图、计算、选材、财务记账、客户沟通、气候分析、生产规划、质量检查、团队管理…… 当然，也包括写代码。
何况，现在小学生都在学而思写寻路算法了，一个成年人会写点代码很稀奇吗？
附：对产品经理写代码的误解
误解 1：懂技术的产品人员在工作中容易陷入技术细节而忽略最开始的用户需求
忽略需求是是产品经理自己的问题，这么沙雕不要做产品经理是对社会的贡献。
误解 2：过多干涉技术方案从而影响技术同学决策、让技术同学对你不爽影响工作。
让工程师对你不爽么说明你不但在技术方面确实很沙雕，还不懂技术，而且还缺少工作能力。
误解 3：该去学习一些技术让下面的人服你
工程师不会尊敬功底三脚猫的工程师，凭什么要尊敬功底三脚猫的产品经理？想被人尊敬，就做出正确的决策来。
误解 4：会写代码我还当什么产品经理？
哈哈哈哈哈。
