那些年，开发与产品撕过的逼

在文章之前，分享一个场景吧。某天共同负责一款App的产品和开发相遇了。

产品：我们希望在首页放一个数据模块。

开发点点头：什么样的？

产品：我们公司每天的订单很多，我们希望将这些订单数据进行可视化分析，分成不同纬度，不同要求将数据生成图表、图形界面进行展示，并且每笔订单都要是实时的，也能展示我们公司的实力。

开发：可以。你调查过并发量吗？

产品：啊？

开发：找过dba调研了吗？订单是查询数据库还是数据埋点？并发量多少？

产品：啊？不可以从数据库推到前端吗？实时显示的那种。

开发：你先去说服dba吧，他估计不同意。

产品：啊？这个很简单啊。不能做吗？

开发：嗯。

几天后的产品需求迭代会上，产品、开发、测试、dba全部到场，一场撕逼大会开始了。

产品总是在想，为什么开发总说这个做不了，明明很简单的一个功能，花个一个星期就能做出来的东西，总是要撕逼呢？

而开发一直在想，为什么产品说需求的时候总是张开那张嘴就在那说，不调研，不审需求，不拆需求，原型画的还那么抽象，不考虑性能，迭代和架构的吗？

我是一名不太合格的软件开发，经常也有这样的经历，但是我在上学期间也在企业里面做过产品，现在我分享一下怎样能做好一个产品经理。

1、与开发的恩怨情仇

打铁还需自身硬

听说开发很懂技术，作为产品对技术的了解自然不能比开发差太多。原型要画的漂亮，需求文档要拆分的仔细，写一个需求之前调研用户，分析并发量，选择性能最好的方式实现，竞品分析要有独到地方。做好属于自己的本职工作。

需求明确理由到位

产品找到开发沟通需求敲定开发计划时候，一定要明确需求，做成什么样子一定有有自己的理由，而且是非做不可的理由，说服开发，沟通便到位了。

如果自己没想清楚就找开发沟通，在讲的过程中漏洞百出，对方随便问几个问题都答不出来或说不清楚，基本上这个事情也就黄了。而且如果你经常出现这种情况，会给开发留下能力不行的印象，后面即使你有合情合理的需求也很难推动下去。

逻辑清晰思维缜密

我想一个互联网公司没有一个工种会比开发的逻辑性更强，开发特点就是性格单纯，逻辑性强，较真。所以你的原型、需求和编写的文档必须要逻辑清晰，思维缜密，可能出现的情况一定要罗列出来。

程序就是0和1的组合，开发的时候必须要考虑的这么详细，那么你设计的原型和文档也必须要这么详细，尽量不要出现让开发边猜边做的情况。对于开发有疑问的地方，要做好解释和完善，并及时更新文档。

了解技术

设计的过程中不要天马行空，如果不确定技术是否能实现，可以向开发人员咨询，不要出现神剧中扔手榴弹炸下飞机、手撕鬼子的情况。开发人员不会反感你向他们咨询、请教技术问题，因为这体现了你对他们的尊重，他们反感的是你讲需求时在不懂技术的情况下，直接要求他们拿狙击枪打死几公里外的模糊目标。

所以不懂技术，尽量不要跟开发说，“这个东西不是很简单嘛”，不然你会很受伤。

语言艺术

不懂技术千万不要对开发人员直接说这不行那不好，不然只会换来“你行你来”，自讨没趣。即使懂些技术，也不要对技术选型、开发难度、开发周期等方面指手画脚，因为你是产品经理，不是技术经理，狗拿耗子多管闲事，还容易招人烦。

不要说“这个东西不是很简单吗”、“今晚加班不”、“这是做的什么呀”之类的话，也不要天天跟在开发后面问进度，这些做法都会让开发产生反感。

2、产品经理的专业技能

产品原型

产品原型是开发开发过程中重要的参照物，一款App的首页做成什么样子，需要什么样的交互都会绘画成这样一张几乎可以以假乱真的产品原型，如果你不仔细看，很容易将产品原型当做真实的用户界面，因为原型你也可以进行一些必要的交互操作。会有专业的软件来帮产品经理完成交互性极高的产品原型。下图就是一些很真实的原型图：

PRD（需求文档）

需求文档是产品经理在了解客户需求之后，通过深挖需求、细化拆分需求得来的文档类产出。需求文档必须逻辑性极强，开发、UED、测试在阅读了需求文档之后都知道怎么入手做事情才是最好的，漏洞百出的需求文档会让开发、UED绝望的。产品撰写一份PRD文档的原则是完整、准确、清晰、简洁、稳定、可执行，这样对产品相关的各岗位工作都有帮助，让自己不再“背锅”。

竞品分析

你的产品不可能是地球上第一次提出的，市场上肯定会有和你具有竞争的同类产品。了解竞品特点，优缺点，超越他们。极强的竞品分析能力是必要的。

产品运营统筹策划能力

产品和运营不分家，一个不懂运营的产品经理不是好产品经理。一切能够帮助产品新迭代方向让更多人知道，促进用户使用，提高用户认知的手段都是产品运营。其中好的产品内容可以让用户对产品形成依赖，有趣的活动可以让用户更加活跃，及时唤醒召回老用户。这就需要在产品设计的规划中提前思考产品的新功能该如何运营推广和促活，从而收集用户反馈。