做好产品规划的3个步骤如何做好产品规划( 二 ) _产品规划

至此，我们完成了对业务到系统功能的抽象，可以看到的是我们对功能的拆解，完全是基于我们对业务抽象的思考。同时，也有一些功能是我们在做功能拆解的过程中衍生出来的功能，比如数据公海以及销售线索的领取与回收。
在此有个小插曲，我们是如何衍生出销售线索的导入这一功能的呢？
我们把销售线索、潜在客户、成交客户编个号1、2、3 。大家都知道程序员的一个梗说的是同样是数数，正常人都是1、2、3 ，而程序员则会0、1、2、3 。
回到我们的设计，我们也会想，客户是怎么就到了销售线索这个阶段（编号1）的？我们很容易就想到销售线索从0到1的过程实际就是销售线索导入的过程，从而衍生出销售线索导入这个功能。
其实，实际CRM系统设计中还存在非常多的细节。例如数据回收机制、订单流转、财务对接、移动设备功能……展开来能讲三天三夜。
【做好产品规划的3个步骤如何做好产品规划】但之前我们也说了，本文仅探讨产品规划的方法，而非CRM设计。在此再次声明需要非常强调的一点：功能的拆解不代表的系统菜单的划分，更不代表的页面的设计层级，所以我们还需要根据功能之间相互依赖的关系，来进行页面模块的拆分重组。
关于功能的拆解到页面功能模块的收敛、合并、拆分、嵌入，我们在此不做赘述。
第三步：从功能清单到产品规划这一步，我们需要开始看系统了，毕竟这都已经是最后一步了。
在这一步，我们首先需要得出功能清单。如果现在什么系统都没有，可能上述的功能拆解就是功能清单了。而如果我们是在已有系统上做迭代，那我们需要拿着上述的功能清单，比对已有的系统功能，分析哪些功能我们缺少的，哪些功能是需要优化的。最终得出一个功能清单，或者就是我们通常所说的需求池。
而下面，我们就要对需求池进行规划了。
对需求的规划，我们依赖于三个指标：需求类型、需求重要程度、需求紧急程度。三大指标间相互独立，单一指标内部存在优先级排序。
紧急度通常作为版本规划依据；需求重要性作为同一紧急度下（或者同一版本内）需求优先级依据；同一紧急度同一重要性下需求类型作为需求优先级依据。
具体来说：所有紧急度高需求构成最近一个版本需求，紧急度中需求作为下一版本需求，紧急度低需求作为未来版本需求；同一版本需求中，按照需求重要性从高到低排序；同样重要性需求中，通常优先处理线上Bug ，其他需求类型次之。

需求类型通常可以做如下划分：线上Bug、新功能、功能优化、技术需求。
需求重要性划分通常考虑如下因素：企业战略、市场反馈、系统完整性、系统健壮性等。
需求紧急度划分通常考虑如下因素：是否位于主流程/关键路径、是否存在外部依赖、是否存在时间窗口、用户操作频次、覆盖用户范围等。

当然，每个系统需求类型、需求重要性、需求紧急度划分需要根据各个公司的业务与产品自行定义，并不存在同一标准或者固定的公式。
通过以上步骤，基本我们也就完成了初步的产品规划。当然，产品规划的最终定稿还要和开发、测试团队进行沟通，结合团队研发资源进行综合考虑，最终和业务部门确认定稿，该过程我们在此不做赘述。
结语在产品工作中，我一直认为，产品设计绝不是一个依据个人感觉或者一个人的主观判断完成的工作。
产品设计、产品规划、产品沟通、项目跟踪以及产品日常工作的方方面面，都需要有方法论来支持工作的进行，有时候甚至像数学公式一样，需要经过严谨的论证与推导。
每个人的方法论可能不尽相同甚至大相径庭，同一个人的方法论也并不是一成不变。但只有通过方法论的支撑，才能推动产品设计工作高效高质的完成，进而推动业务的落地与战略目标的达成。