很多人在做产品之初都会遇这个问题，我其实自己也遇到了。后来仔细总结了一下方法论：
这个需求之初，作为 PM ，思考清楚了？
这个是需要在和技术人员（工程师／设计师）聊需求和方案前最重要的一步。需要思考清楚的点是什么呢？其实是 PRD 上需要写的全部内容：为什么要做这个需求？这个需求核心需要达到的数据指标是什么？为了达到这个指标，为什么选用这个方案而不是别的方案？有没有达到这个指标更好的方案了？这个方案核心的氛围，方向为什么要这样选用？
如果这些逻辑都想清楚了，确定没有问题，可以说服自己了，那么就可以开始和工程师+设计师聊了。
2. 目标方向是否传达到了？
这是在很多次沟通后才发现的，有可能是 PRD 写得不仔细，也有可能是技术人员看 PRD 不仔细。结果就是「你们很可能获取到的信息不一致」，很多时候你以为 RD 们了解了所有的背景和方案做出了否定的判断，但是实际上是你们拿到的讯息都不一致。所以导致了这个问题，在出现不一致的意见前先确保你们都有获取到一样程度的信息。
3. 哪个阶段出了问题？
聊需求的时候一定要从最初为什么有这个需求，再到最后做什么。切忌直接上来说我们要做什么。目标感很重要。很多时候 RD 不愿意做需求的原因可能是因为：为什么要做这个？收益是什么？为了这个事情付出这么多存储成本，响应时间，qps 提高 等等值得不值得？所以当不一致出现的时候，未必是最初矛盾产生的点。
4.了解清楚每个人核心的诉求
RD 可能说：这个需求做不了，太麻烦了。而你就急于说服他不麻烦，上线可以晚一点。但是实际上也许他想说的是：在这里要做较实时的数据展示，就要做缓存。而要实现缓存，我又要给你缓存这么大的数据量级附加计算逻辑。就是一件成本很高的事情。所以，这里数据比较实时的必要性是？按照天级更新是不是可以接受？听懂对方在说什么，才能更好的解决问题。
5. 让人信赖
工作核心其实是与人协作。除了一些互联网向的思考方式和诉求外。还有一个重要的就是被人信赖，愿意和你合作。那么达到这一点需要什么呢？足够专业的核心技能，足够清楚的业务逻辑，足够明确的产品目标。让人感觉和你一起做需求什么都是被考虑到的，方案是无懈可击的。
网友评论