上周在公司给大家进行新需求评审，由于 PRD 搞得有些草率，引发了开发伙伴们的强烈不满，有位大佬也直接说我不懂软件工程，连个用例图、状态图都画不好，好吧，不写代码以后，我确实忘了很多软件工程的东西，但以前还是适当用过一些的。
大佬觉得我不懂，是因为我的 PRD 里没有他想看到的东西，或者他觉得他应该看到的东西。
所以要跟我们划分严格的上下游关系，给我们的产研协作立下各种条条框框的规矩，从而让自己后面的研发工作中占据主动地位。
这件事情让我觉得有些不安，我认为是各自视角和信息差的问题，导致了大家的目标不一致，所以决定写一篇文章，来跟程序员伙伴们聊聊创业型互联网产品经理。
之前我写过一篇不就是改个需求吗，至于拿刀砍我？>，目的是让一些没做过研发的产品经理了解程序员们的工作，那么今天这篇文章，则是为了帮助程序员们适当了解产品经理的工作。
1、产品经理的工作都包括哪些？
还记得 2017 年我第一次转产品的时候，是老板钦点的，本来我那会儿正在自学 Spring Boot、Spring Cloud，微服务搞得正爽，根本没想做产品。但有时候命运就是这样，我的一个无心之举（给技术总监写了封邮件，谈了谈对微信小程序的看法），竟然开花结果了。
这封邮件，后来技术总监转给了老板，老板看完，沉思良久，嗯，这小伙子是个做产品的好苗子。
于是我被赶鸭子上架，做了一个多月产品的工作。当时我觉得做产品没什么难的，不就知道要做个什么事儿，把原型画出来就行吗？
然后就风风火火开干了，什么市场分析，用户分析，竞品调研，统统都没有。就觉得小程序是未来，那我们就做个微信小程序出来，至于做出来给谁用，怎样获取种子用户，怎样进行用户增长，都没有想过。
可以说，我那会儿还没有摸到产品经理这行的门槛。那时候的我，认为产品的主要工作，就是把原型画完，然后让程序员们去干出来。
后来我觉得做产品有些无聊，就选择了继续回去做程序员，写代码。
本来以为自己就这样开开心心写代码，未来混个架构师当当，几十年职业生涯一晃也就过去了。
但是后来我加入了一个教人赚钱的神奇社群，抱着通过这个社群快速的赚到钱的心态，我竟然慢慢开了“钱眼”。
我大量阅读大家分享的网赚案例，创业案例，在这里吸收了大量的商业信息和流量玩法，渐渐的开始能闻到钱味儿了。
自己的思维方式也随之改变，看到一个生意就开始思考这件事是怎么赚钱的，固定成本都有啥，月盈利多少，是否可持续赚钱，天花板有多高，自己能不能做…
所以当我用这样一个思考维度去审视自己的工作内容，就会发现很多以前看不到的问题。
我终于明白，之前自己引以为豪的代码规范也好，高可用架构也好，如果不能跟业务结合，给团队带来实打实的利益，那和玩物丧志没有本质的区别。
后来我做到了开发组长，开始带人写代码，自己则不断地了解业务，学习产品思维和产品技能，慢慢转到了产品岗。
在有了商业思维之后，再来做产品，就像开了天眼。
因为我能站在老板的角度看问题，想他所想，忧他所忧。
我开始思考职场的本质，明白打工人如果带着创业者的心态，那就不是在给老板打工，而是给自己。
坦白说，公司赚了钱，老板确实是第一受益人，你可能觉得自己干多干少都是拿固定工资，操那么多心干啥？
但是，谁说我们现在的努力，就会立即兑现呢？
你所做的每一件事，付出的每一滴汗水，都会写在你的简历里，写到共事者的心里，或许下一次的涨薪名单上就有你，或许很快你就能积累到更好职场机会，让子弹飞一会儿。
开发在与产品经理的合作中，最关注的是我要什么，就是最后那个 PRD 。
但，对于产品经理来说，PRD 的背后，其实是有完整的商业模式、产品战略和公司规划等一系列冰山下的工作。
如果开发不知道产品经理背后这一系列工作的话，那么对于开发来说，就会觉得产品经理没什么难的，不就做个 PRD 么……
所以在开发的认知里，产品经理的工作 = 动动嘴 + PRD。
对产品来说，最主要的工作是想清楚为什么，就是我们为什么要做这件事情，通过为什么来引出最终我们要做什么。
而开发是从做什么开始，引申到怎么做的问题上，开发所有的工作都是去想，我要用到什么技术，如何去把这件事做出来。
这就导致开发工程师很少关注产品想的那个为什么。
所以，最终产生的结果就是，程序员们认为，自己才是这个公司的灵魂，因为产品经理只是动了动嘴，做了张皮，而真正把事情实现的是我们伟大的程序员。
这种信息缺失，就是程序员对产品经理产生偏见的根本原因。
所以对于开发来说，解决偏见的根本方法，就是要扩充自己的信息边界，多了解兄弟部门都在做些什么。
2、需求为什么会变？
正常来讲，导致产品需求改变的只有两个原因：
- 产品经理自己没考虑清楚；
- 市场变了。
第一个原因很容易理解，产品经理也是人，是人就会犯错。
解决方案有两种：
- 不允许产品经理犯错，那么产品经理每次提需求都战战兢兢，都担心自己考虑不清楚，怕出错，然后多花一倍的时间去反复推演，反复琢磨；
- 出了错误，及时发现，及时反馈，及时改正。
这两种解决方案，哪一种更好？没准儿，需要分情况。
在大公司，每一个决策行为，每一个功能改动，都可能影响到成千上万的用户体验，那么大公司做功能就需要非常慎重。
而在草莽创业阶段，一个 PM，可能要同时对接十几二十个研发，PM 这么干浪费的是大家的时间，浪费的是公司的市场先机，在创业公司，还是应该把精力放在开疆扩土上，而不是搞形式主义。
第二个原因，市场需求变了，怎么理解？
就拿我们现在的 SCRM 产品来说，是最近两年随着企业微信的发展新兴起的一个赛道，而私域运营这件事，本身也是个脏活累活，每个行业，甚至每个品牌的玩法都不一样，我们如何靠一套通用的工具去满足所有客户呢？
所以前期就是要有大量的市场调研，需求探索，甚至昨天的客户想要的是这个功能，改天过来个钱多的客户，又想要另外一个功能。
以前我做程序员的时候也很讨厌业务方改需求，但后来我发现，在如今这个互联网市场里淘金，改需求是正常的，而需求一成不变才是危险的。
因为市场一直在变化，业务负责人也一直在进步，市场变了，人进步了，只有落实在产品决策上，才能发挥最大价值。
3、为什么产品经理的 PRD 总是缺斤少两？
在理想情况下，一个完整的 PRD，可能需要有 Use Case，有 User Story，有业务流程的表达，比如活动图、状态图，有业务架构与概念模型，有高保真原型界面……
但现实中，有时候 PM 甚至会直接拿着自己赶出来的线框图，就去找到对应的研发口述需求。
原因也有两种：
- 产品经理本身能力不行，或者态度不行，不愿意做；
- 需求紧迫，前线销售等着产研部门生产弹药，一切章程从简，能快则快。
第一种情况我们就不说了，该换人换人对吧，遇到第二种情况怎么办？
还是需要调整自己的心态，跟上公司的大方向和大节奏。
学院派没有问题，我很尊重学院派，在实际的工作中，学院派可以告诉大家，正规军是怎么样打仗的，在现有的情况下，我们应该规避哪些问题，以及出了问题，我们应该如何去积极解决。
但你不能说，我打仗就需要准备好飞机大炮机关枪，需要给每个士兵配新衣服新棉被，否则我就无法好好打仗。
当初蒋介石就是这么干的，要钱有钱，要装备有装备，但最后不还是败给了八路军。
土八路也有土八路的打法，共产党带领土八路，小米加步枪创业成功，才有了如今的人民解放军，才有了阅兵场上的飒爽军姿。
4、产研是一家
程序员在心态上不要把产品经理当成上游、甲方和找茬的，而应该把产品当成一起并肩作战的战友，一起改变世界的伙伴。
然后在工作中，尽量不要严格划分上下游界限，说你们产品就应该怎么怎么样，做不到我们就不配合……
不要凡事公事公办留证据，大家想一个场景，如果两个人互相信任，那我跟你说个什么事儿，你答应了，那就是答应了，如果你没做到，可能是忘了，也可能是被其他事情给耽搁了。
把事情沟通清楚就好了，并不会产生什么严重的后果。
但如果你们互相留沟通的证据，发个邮件，@下领导之类的，那意味着产研之间的隔阂已经建立，是一个非常危险的信号。
未来这个团队想推进什么事情，可能都会阻力重重。
还有在提建议的时候，要有两个原则：
- 本着帮对方把事情做好的目的。
- 可执行的。
所有的程序员都怼过产品，所有的产品应该也都被研发怼过，但大家要清楚一点，沟通的目的，是为了把事情做成，而不是为了搞定对方，也不是为了证明自己多么牛逼。
最好的办法，就是跟产品交朋友，建立私下的沟通渠道。
没事就跟产品唠唠嗑，了解下最近的市场环境，又积累了哪些需求，后面打算做什么新东西。
也可以把技术相关的东西，比如框架、架构、历史遗留问题，都去跟产品讲，想办法让产品了解自己的工作，这样当你们互相配合默契之后，产品甚至会主动帮你扛事情。
当双方知道了对方在干什么，也就消除了信息差，你们之间也就容易产生共情。
这样下去，团队才会越来越好，工作效率和工作满意度也才会越来越高。
