产品需求从无到有，经历了头脑风暴、调研沟通、业务讨论、架构讨论、产品评审、开发评审。沟通无处不在，和业务人员、架构师、产品人员、技术人员、领导的各种沟通协调、汇报，一路下来梳理些沟通的方式方法，自勉和改进。
1、心态： 一句很感同身受的话：开放的心态是我们要做的第一件事情，全局控制的想法其实是错觉。你不能控制人或者任何事情。你可以影响他们，但绝不是控制。
2、与业务、产品的沟通：
1.沟通业务背景，了解产品流程背后的原因。
2.沟通产品故事，了解产品为用户带来什么价值。
3.讨论产品方案，建设性提问并带自己的建议方案。
4.涉及外部接口的交互及约束，从后端产品往前端产品推进、沟通。推进的方式：
1）从性能指标考量的角度，在前端产品尽可能少调用接口次数和中台提供接口范围不过分超出产品架构定义之间做好权衡。
2）从产品职责定位的角度，上游产品传给下游产品的接口信息中不够下游产品用的，原则上由上游产品提供，上游产品提供不了的从产品定位考虑是否由上游产品提供还是下游产品根据上游产品的传参自己去其他平台获取。
5.和每个对接产品的人员单独建群沟通，形成问题讨论小组。
6.产品需求沟通、确认的完成度达90%以上时发正式邮件给所有干系人并告知开发团队已开始着手产品开发。同时附上待确认的问题清单请相关方同步知悉。
3、与架构师的沟通： 1.先谈业务，再谈产品，接着谈流程，最后沟通系统边界。
2.有较清晰的产品需求和流程后再和架构师沟通。
备注：架构师在有较清晰产品需求前提下主持产品职责定义及各产品边界划分，输出应用架构规划与设计方案作为产品需求的参照。
4、与领导的沟通、汇报： 1.产品调研汇报时，哪些调研过、哪些没调研过、哪些暂时没有调研清楚的，客观说明。
2.决策请示时，从业务角度出发，不要请领导确认产品细节、更不要技术细节，提出问题的同时带建议解决方案（如：确认一期是否要做XX产品功能，解决方案要素含：竞品是否也有做？我们做有什么价值？如果做该如何做？涉及哪些产品改造？上线时间节点下现有资源是否足够？不足还需要多少资源？需要和其他部门做哪些配合和协调？）
5、与开发沟通：
讲产品故事（讲述业务背景）、画草图（讲业务故事的同时黑板画上下文流程图）、解疑问（解答开发的问题）、当前遗留问题（自己当前还没有想明白的产品流程可以邀请开发参与沟通）。其中：
1.业务需求讲解要点：
1）为什么有这个产品
2）产品做什么的
3）产品所处的业务上下文
4）有哪些业务场景会经过产品，经过时的数据流向。
2.产品需求预审：
1）需求增量编写过程中质量优先，明确一部分，提前请开发人员预审一部分，划分好产品需求和概设/详设的边界。
2）需求增量给开发后，请开发提意见并开展沟通，正式评审前，澄清一些开发人员的疑问。
3.产品需求评审要点：
1）需求文档结构介绍（分哪几章节、各章节的含义及章节间的区别）
2）产品的功能结构图
3）每个章节的功能需求描述、产品流程、对外接口描述
4）每个章节介绍完毕，请开发提问，产品答疑，问题批注到文档。
5）评审完毕后及时将修订的产品需求发给开发并说明已明确的内容、待定的内容，列出修订记录。
6）对于未能确定的需求，评审过后与技术沟通，请开发把握好概设/详设的度。
posted on 2015-04-11 11:20
cheng 阅读(4573)
评论(0) 编辑 收藏 所属分类:
互联网产品