一篇文章读懂程序猿和产品经理的爱恨情仇.pdf

一篇文章读懂程序猿和产品经理的爱恨情仇 记得之前参加团建活动，是真人 CS 。我们一共没几个产品经理，但有几十个程序员。所以场面估 计你也能想象出来了 …… 并不是刺激的对战，而是惨绝人寰的群殴。 被 BB 弹打成狗（哎，原来不就是狗吗）的一个产品经理急中生智，大喊：『我以前也写过代码！ 我是自己人！』 其他正在施暴的程序员面面相觑，表示十分感动，但仍然拒绝了他的求情，继续按在地上打了半个 小时。 …… 我在哈工大读书，学的是计算机，写了六年代码，毕业后做的却是产品。 所谓对程序员和产品经理之间的调侃，主要原因无非就在两方经常有矛盾出现，而矛盾出现显然是 因为双方一边是需求提供方，一边是需求实现方。矛盾的类型也简单，就是大家提到的这么几种。 同时写过代码，又做过产品的我，实际上仍然没有很好的通用法则，能解决所有矛盾。 不过做过产品总监一职后，的确理解完全不同了。产品工作和研发工作都是我的管理范畴之内，看 事情的角度就完全不一样。 过去做程序员，总觉得提供的需求更改很烦、给的需求不合理很烦、给的截止时间不合理很烦。 做产品经理的时候，也会觉得程序员总是推卸责任、完成得不及时或者不够好。 其实从整体的工作配合上来看，出现问题是难免的，关键是如何预防、如何解决。 …… 以下是一些切身体会得出的经验性建议： 对于研发人员： 做好更改需求的准备 很多固执的程序员会把改需求当成错事。 实际上，在互联网产品这个领域内，改需求肯定会是家常便饭。 我没有做过统计，但我接触到的已经成立一年的公司，几乎都经历过大改版，也就是代码全部重写 。这对研发团队来说自然很痛苦，但却是不可避免的。 互联网的需求更替是频繁的，一方面是大环境随时在发生变化，去年你还在刷微博，今年已经是朋 友圈了。另一方面，需求获取的渠道也是多样的，产品经理可能会有新的发现和新的判断，未必都 是之前没想清楚。 当然，如果需求都是老板从什么《易经》中得到感悟、从云卷云舒花开花落里得到启示，让你手忙 脚乱给他改来改去，那也没意思了。 既然改需求是经常会出现的，那就要求还是得做好更改需求的准备。有这么几种方法： 1.1 提高代码的可复用性、可扩展性等等 让一些产品中很可能会用得到的各种控件、功能模块做成可复用性很强的代码，在产品增加类似 功能，或者修改原有类似功能时，将会大有裨益。 可扩展性则是各种接口、数据库以及底层结构不要写死，尽量用可扩展的方式写。比如现在有五个 分类，不要写死就五个，要写成 n 个分类，目前是五个。 嗯，这是常识了，但有的程序员还是会比较随意，写代码没有远见。 其他的代码特性，如果有利于降低产品的更改和优化成本，也要加深关注。 1.2 根据产品规划来做好充分准备 每个功能的实现方法都有很多，怎么选择并不是只看当下的成本如何，而是要关注未来产品的整体 规划。 可能目前要完成功能 A ，有 1 、2 、3 多种方案，方案 1 成本最小。但未来要完成 A 、B、C 、D 很多 功能，方案 3 更有利于整体成本最小。那就要选方案 3 未雨绸缪。 多跟产品团队交流，了解未来产品要做成的样子、哪些功能会是必须的、哪些功能是可能会有的， 多从长远来看。 1.3 合理预留出修整的时间 首先，不要把研发时间就当作完成时间。研发功能只是一部分，测试、改 BUG 以及处理意外情况 的时间都要预留出来。 有两种情况要多预留出修整的时间。 一种是研发团队自己对功能没有把握，可能是全新的功能，可能是比较难做的功能，可能出现许多 BUG 和功能实现糟糕的情况，那就要多预留出时间。 另一种是产品团队表示对功能也有疑虑，比如在提供需求时表示这个功能很有可能要调整，或者对 功能本身信心不足，那也要多留时间做调整。 理解需求，防止返工 研发团队通常会缺少对需求的理解，尤其会出现这种情况的就是外包团队。我听说过太多花了几十 万请外包团队，结果开发的结果特别不满意，不能拿来用。合同又已经签好，还得给钱，就是赔了 夫人又折兵。 有的技术团队和产品团队都坐在同一间办公室了，居然都经常缺乏沟通。技术团队不知道当前做的 功能是给谁做的、是提供什么功能、满足用户什么价值的。 这些不是很高深的理论，也不需要深入学习，只需要通过产品经理做些了解，就能少挖一些坑，也 就不会轻易返工。 比如，有的产品页面可以是提前加载缓存，也可以是每次都刷新，但要看用户平常是在