产品规划是一件说难不难、说简单不简单的事情，笔者复盘了一次CRM系统的产品规划，分享了其中对于关键节点的把握，以及做好一次产品规划都要注意些什么事情。
目前在一家互联网财税公司负责核心业务产品，手头主要三大产品线：财务线、税务线以及CRM线。最近带着各产品线负责人完成了三大产品线的产品规划，有些产品线是一直在持续迭代，有些产品线则是停滞了一段时间，换了产品线负责人重新上手，整体上来说已经整理的七七八八了。
过程中深感对于一名产品经理来说，产品规划能力的重要。而很多基本能力较为扎实的产品经理在做产品规划的时候也会陷入盲目堆需求、直接设计细节、优先级排期混乱等问题上来。
在此将自己的一些实操经验拿出来与大家分享。
做产品规划，说简单也很简单，把握关键节点，整理梳理出需求的轻重缓急即可。说难也很难，系统的现状、市场的诉求、研发的资源、需求类型划分、排期优先级无一不是要纳入考虑的要素。
如何在千丝万缕的线索中抽出一条清晰的脉络，我的理解，最为关键的一点在于做好业务深入理解和业务到系统的抽象。做好这一步，产品规划和需求排期最终不过是水到渠成的事情。
本文我们以外呼型CRM系统为例（CRM较为普遍同时业务较为简单），进行一次产品规划的复盘。
第一步：理解业务本质
这一步先不要看任何系统，清空一切系统的影像。
首先，我们先思考，CRM业务的核心是什么？
CRM的核心很简单，就是销售用来挖掘跟进销售线索并最终实现到成交客户转化的过程。
这就是CRM的核心，围绕这个流程，用户（主要为市场销售人员）有哪些行为和场景？
在销售线索阶段，用户主要行为就是挖掘验证线索，最典型的行为就是打电话；
在潜在客户阶段，用户主要行为就是对销售线索转化而来的客户进行跟进，方式包括不限于电话沟通、上门拜访等；
在成交客户阶段，客户基本确认了购买意向，用户需要完成合同签署、收款等行为。
从上面的一段场景描述中，我们发现涉及的用户行为包括沟通工具的使用（电话、短信、微信、QQ等）、用户跟进动作的记录（打电话、上门拜访等）、交易达成必要手续（合同签署、收付款等）。
至此，我们可以总结下，CRM的本质是：通过沟通工具的使用、跟进动作的记录、交易达成必要手续来推动销售线索到成交客户转化完成。
第二步：业务到系统的抽象
这一步还是不要看任何系统，清空一切系统的影像。
通过上面对业务的梳理，我们可以开始思考一个问题，要完成上述的业务，我们需要怎样的一个系统。
第一，这个系统需要帮我们完成流程的流转。而流程的流转，无非要完成两件事，在流程节点信息以及节点到节点之间的流转。
流程节点信息是什么？
节点就是客户所处的不同阶段，即销售线索、潜在客户以及成交客户三大客户阶段，流程节点信息具化开来就是每个客户阶段客户列表页以及客户详情页/客户卡片。
流程节点到节点之间的流转要做什么？
需要制定流转的前提条件（如需要添加哪些信息、上传哪些文档，生成哪些记录等）以及流转后的限制（只能哪个节点到哪个节点、流转是否可逆等）。
第二，流程不会自我流转，而是通过一些核心功能模块，来驱动流程的流转。
对照上图，我们很容易拆分出沟通工具模块（电话功能、短信功能、QQ等）、跟进动作的记录（跟进动态、电话录音、短信记录、外勤签到等）、交易达成手续（合同模块、收费管理模块、产品/服务管理等）。
第三，作为一个系统，还需要一些通用功能来支撑用户的基本操作和管理。
我们可以把常用的系统功能拉出来看看是否我们系统都会用到，如用户管理、权限管理、消息管理、基础设置、帮助中心、数据统计……我们似乎发现了一个不太一样的通用模块——数据统计。
数据统计对很多系统来说，是一个通用的管理功能。但是对于CRM来说，数据统计不仅是对业务数据结果的分析，还会应用到对用户工作的规划统计和推动，即计划模块。所以，我们要把计划管理放到推动流程流转的核心功能中。
我们对上述功能抽象的结果做一个整理，如下：
至此，我们完成了对业务到系统功能的抽象，可以看到的是我们对功能的拆解，完全是基于我们对业务抽象的思考。同时，也有一些功能是我们在做功能拆解的过程中衍生出来的功能，比如数据公海以及销售线索的领取与回收。
在此有个小插曲，我们是如何衍生出销售线索的导入这一功能的呢？
我们把销售线索、潜在客户、成交客户编个号1、2、3。大家都知道程序员的一个梗说的是同样是数数，正常人都是1、2、3，而程序员则会0、1、2、3。
回到我们的设计，我们也会想，客户是怎么就到了销售线索这个阶段（编号1）的？我们很容易就想到销售线索从0到1的过程实际就是销售线索导入的过程，从而衍生出销售线索导入这个功能。
其实，实际CRM系统设计中还存在非常多的细节。例如数据回收机制、订单流转、财务对接、移动设备功能……展开来能讲三天三夜。
但之前我们也说了，本文仅探讨产品规划的方法，而非CRM设计。在此再次声明需要非常强调的一点：功能的拆解不代表的系统菜单的划分，更不代表的页面的设计层级，所以我们还需要根据功能之间相互依赖的关系，来进行页面模块的拆分重组。
关于功能的拆解到页面功能模块的收敛、合并、拆分、嵌入，我们在此不做赘述。
第三步：从功能清单到产品规划
这一步，我们需要开始看系统了，毕竟这都已经是最后一步了。
在这一步，我们首先需要得出功能清单。如果现在什么系统都没有，可能上述的功能拆解就是功能清单了。而如果我们是在已有系统上做迭代，那我们需要拿着上述的功能清单，比对已有的系统功能，分析哪些功能我们缺少的，哪些功能是需要优化的。最终得出一个功能清单，或者就是我们通常所说的需求池。
而下面，我们就要对需求池进行规划了。
对需求的规划，我们依赖于三个指标：需求类型、需求重要程度、需求紧急程度。三大指标间相互独立，单一指标内部存在优先级排序。
紧急度通常作为版本规划依据；需求重要性作为同一紧急度下（或者同一版本内）需求优先级依据；同一紧急度同一重要性下需求类型作为需求优先级依据。
具体来说：所有紧急度高需求构成最近一个版本需求，紧急度中需求作为下一版本需求，紧急度低需求作为未来版本需求；同一版本需求中，按照需求重要性从高到低排序；同样重要性需求中，通常优先处理线上Bug，其他需求类型次之。
需求类型通常可以做如下划分：线上Bug、新功能、功能优化、技术需求。
需求重要性划分通常考虑如下因素：企业战略、市场反馈、系统完整性、系统健壮性等。
需求紧急度划分通常考虑如下因素：是否位于主流程/关键路径、是否存在外部依赖、是否存在时间窗口、用户操作频次、覆盖用户范围等。
当然，每个系统需求类型、需求重要性、需求紧急度划分需要根据各个公司的业务与产品自行定义，并不存在同一标准或者固定的公式。
通过以上步骤，基本我们也就完成了初步的产品规划。当然，产品规划的最终定稿还要和开发、测试团队进行沟通，结合团队研发资源进行综合考虑，最终和业务部门确认定稿，该过程我们在此不做赘述。
结语
在产品工作中，我一直认为，产品设计绝不是一个依据个人感觉或者一个人的主观判断完成的工作。
产品设计、产品规划、产品沟通、项目跟踪以及产品日常工作的方方面面，都需要有方法论来支持工作的进行，有时候甚至像数学公式一样，需要经过严谨的论证与推导。
每个人的方法论可能不尽相同甚至大相径庭，同一个人的方法论也并不是一成不变。但只有通过方法论的支撑，才能推动产品设计工作高效高质的完成，进而推动业务的落地与战略目标的达成。
声明
本文所提到的CRM系统以及相关业务，与我司的CRM系统与业务基本无太大关联，所有功能以及图示都是在编写此文时临时编制出来。
本文只是借CRM系统来做一个示例，从一个业务概念出发，如何逐步推导CRM系统基本模型，从而完成产品规划与需求排期。
