产品汪与程序猿

在很多人眼里，产品汪与程序猿是一对天生的冤家，加上一些不明内情的、非互联网圈人的传播，这种矛盾被无限的夸大，比如:“哥们，我这里再小小改个需求……”，“我刀呢？”。

事实上，产品和技术的关系远没有那么夸张啦，要真是这样那还想不想干了？在公司里面，我看到过一些喜欢呛火的同事，但是鄙人和研发的兄弟一向相处的比较愉快，这里面固然有我的人格魅力原因（咳咳，要脸不？），更多的还是源于平时的一些沟通技巧和对自己的严格要求。

咱们今天列举几条由产品经理挑起战争的话，然后逐一去分析个中原因，帮助大家有效避开这些隐忧。

1你为什么不按我的需求开发？这不是白做了吗？

首先，没有人会故意跟你对着干，故意不按需求走。这种情况下，主要原因是双方对某需求产生了两种理解，我们可以将其归纳为“误差”一类的问题。

我们说，汉语实在是博大精深。平时喜欢在网上看段子的童鞋应该容易理解这句话，什么“我去，我不去”之类的，同一句话真的会理解出两种意思来。我们承认误差不可避免，但可以尽量缩小，比如产品在制作原型的时候，文字性说明要使用短句，而非长句（长句子有时候断句位置不同都能产生好几种理解），碰到复杂逻辑时，适当辅助一些表格、流程图、红蓝颜色来让自己的表达更清楚。在进行原型评审的时候，假设一个场景，举实例说明，比起干巴巴的描述更容易理解。

在刚开始配合的时候，由于双方沟通习惯不同，历史的项目经验不一致，前一两个月可能这类问题会出现的比较多，这就是所谓的磨合期了，团队配合从“1+1<2”到“1+1>2”是需要一定过程的，随着彼此逐渐了解，可以渐渐消弭此类问题。

2神马，你现在跟我说这个功能不能实现？原型评审的时候你怎么不说？

“原型评审”，我们可以换四个字，叫“纸上谈兵”。

在评审的时候，技术们眼睛看着原型图，耳朵听着产品经理的讲解，脑中想着这一块的技术逻辑框架，这其实和小时候咱们上课听讲挺类似的，谁规定所有的问题都是课堂上听不懂就立即发问的，有许多问题不都是课下钻研的时候才发现的么？一名技术，只有当他的机器连上了开发环境，屏幕上充满了代码，才能100%的进入状态，评审的时候技术们基本只能发挥50%的实力，很多需求从表面上看确实是没破绽，所以在开评审会的时候他当然不会提出疑问，实际开发中才发现原来这个需求和某历史功能有矛盾、或是当前架构不支持这样的修改等等。还有一点就是评审会的时候，其实产品经理是主角，我第一次召集弟兄们开评审会的时候，大脑几乎属于空白状态，说话语无伦次（那时候的自己真是弱爆了，汗。。。），技术们当时心情应该是“天哪，赶紧让这评审会结束吧，我们下去内部好好研究研究”。

事实上，就算是懂技术的产品经理，也不敢保证输出的每个需求都能被实现，纸上谈兵就是纸上谈兵，和实战是两码事，研发以原型为标准，但原型并非不可修改，既然技术逻辑解决不了，那就只好修改产品逻辑。

3我就加了点东西，你稍微改一下就行，很快的。

嗯，这句话说完估计技术在心里已经鄙视了你一万遍。产品逻辑和技术逻辑差别是很大的，有的需求在产品这边就是一句话的事，比如“用户启动后，如果在wifi情况下，则自动下载某某插件”，一个简单的静默下载需求，但是技术确要考虑“我要先判断出用户是否已经下载了”“在下载过程中，用户尝试使用这个插件我该怎么提示”“静默下载如果执行了一半突然断网了，下次进来怎么处理”一系列问题，这个真的不是“稍微改一下就行的”。

所以说，一旦进入开发阶段，产品不要随意地改需求（除非是像第2条说的，技术主动发起的修改请求，这时候不得不改了），一遍一遍地改需求只能说明你想问题还不够全面，还木有升级到“优秀”的这个层次。如果真是迫于某种压力非改不可的，那也要和技术进行充分的讨论，评估对项目周期的影响，然后产品经理通发需求修改邮件，相当于你重新输出了一遍需求。

今天就写这么多，以后试试写写程序猿主动发起战争时说的话~~

Thank you for reading!