“这是产品经理要考虑的，我只管写好代码就好了”，我曾有过这种想法。产品经理就要把所有产品逻辑考虑清楚，然后交付PRD给开发人员进行研发，瀑布or迭代研发一个个里程碑。不过想法总是美好的，现实是大家总是刀剑相向。
产品经理如何惹怒开发人员?
- 业务不清晰，研发人员不懂业务语言，产品经理不能把业务讲明白;
- 产品深度太浅，经不起推敲，研发人员觉得是敷衍，不专业;
- 产品流程不顺甚至复杂，用户体验糟糕;
- 不听开发人员建议，觉得他们没有产品思维;
- 状态设计不全，还坚持己见;
- 没有完整的PRD，把想法告诉研发直接开始码代码，没有评审;
- 没有数据指标，乱拍脑袋定东西;
- 这么简单的功能，怎么需要这么久;
- 着急上线，不给开发人员留思考时间，实际上并没有那么着急;
- 把需求扔给开发人员就不管了，不追进度，不看效果;
- 非功能性需求根本不考虑;
- ……
开发人员如何惹怒产品经理?
- 一味追求技术，不学习业务语言，不学习领域知识，听不懂需求;
- 评审PRD时不提出问题和风险，等项目快上线了才暴露出来;
- 码代码前不好好读PRD，出问题直接怪产品;
- 以为技术是***的，不去拒绝一些不合理的需求，***做砸了;
- 数据状态和异常流程这事需要好好跟产品经理梳理，产品经理没我们想的全这是一定的，不要怪他们;
- 只为代码负责，用户体验不是我们要考虑的;在涉及到网络、设备等方面的用户体验，我们比产品经理更懂;
- 遇到问题不找产品沟通，随意定方案;
- 代码一团糟，不可维护，不可扩展，新需求迟迟做不了;
- 老出问题，怪产品经理设计不合理，考虑不全;
- 很明显的产品体验问题，不提出来，不解决;
- ……
产品经理应花大部分时间在商业画布、产品规划、产品逻辑、产品运营、用户体验上。涉及到具体功能点应该大致给出研发方向，不然研发是没有方向的，很可能导致不断地返工。
业务开发人员、系统开发人员、SRE或运维人员，其实已经有产品思维了，比如我们梳理业务架构、系统架构、功能点、系统流程、异常流程、数据流程、数据状态、系统配置等等，这些不都是产品的一部分吗?只是这些跟技术绑定的比较紧密而已。
产品经理在产品细节、异常流程、数据状态等方面很可能不如研发人员。这个时候需要大家一起坐下来沟通并梳理。我的观点是：越透明，越高效。
我们首先应该是一名产品经理，然后才是一名开发人员。而且我们是一个团队，应该一起考虑如何做好产品。不过我们应该把自己的专业度提高，否则产出的方案经不起推敲，老是产出残次品，大家的信任危机接踵而来，谁也说服不了谁，决裂厮杀，最终产品失败。
小马哥说过：产品经理要把自己当做一个“最挑剔的用户”。开发人员要用心思考产品，而不是公事公办的态度。你要知道用户、同行会关注你的产品，在这种驱动下开发人员要有责任心去主动完成。不能说等到产品做好了，流水线一样送到面前再做。40%~50%产品的最终体验应由开发人员决定的。
【本文是51CTO专栏作者张开涛的原创文章，作者微信公众号：开涛的博客( kaitao-1234567)】
