अभी लॉगिन करें 产品规划这事，说简单也简单，说复杂也确实能把人绕进去。最近我们团队几条产品线都在重新梳理规划，我负责的是CRM这一条，正好借着这个机会，把手头的工作复盘了一下，想聊聊其中的几个关键节点，尤其是怎么避开“对着需求池瞎排优先级”那个坑。
我们公司是做互联网财税业务的，财务、税务、CRM三条产品线各有各的节奏。有的线一直在迭代，有的线中途停过一阵，换了负责人又重新启动，磕磕绊绊总算把大框架理得差不多了。这个过程让我越来越觉得，对产品经理来说，产品规划能力其实比画原型、写文档更底层。很多基本功不差的人，一到规划阶段照样会掉进几个坑里：要么把一堆需求无脑往上堆，要么一上来就扎进具体页面细节，要么优先级排出来连自己都说服不了。
所以这次复盘，我想把自己的体会整理出来。核心思路就一句话：先别急着看系统，先把业务吃透，然后把业务抽象成系统模型，最后再谈需求优先级。这条路走顺了，后面的规划不过是水到渠成的事。
下面就用我们的一条外呼型CRM系统来举例，业务本身不算复杂，正好拿来把方法讲清楚。
第一步，回到业务本身，清空所有系统印象。
很多人一上来就打开现有系统，对着菜单和页面琢磨，这很容易被已有的功能框架框住。我的习惯是，先完全抛开系统，去想这个业务到底在解决什么问题。
CRM的核心其实特别直白：销售从拿到一条线索开始，不断跟进、沟通，最终把线索转化成付费客户。展开来看，就是三个关键阶段——销售线索阶段、潜在客户阶段、客户成交阶段。
围绕这三个阶段，用户（主要是销售和营销人员）到底在做什么？线索阶段，最典型的行为就是打电话、发信息，去验证这条线索靠不靠谱。到了潜在客户阶段，用户需要持续跟进，电话、短信、上门拜访，各种方式组合着来，同时得把每一次的跟进动作记下来，不然转头就忘。等到客户确实有了购买意向，就进入成交阶段，这时候需要签合同、收款、开通服务，走一套偏交易流程的操作。
梳理下来就会发现，用户的行为其实就落在三大类上：使用各种沟通工具（电话、短信、微信、QQ等等），记录跟进动作（打过电话、上门拜访过），以及完成必要的交易程序（签合同、收款）。所以，CRM的本质并没有什么玄乎的，它就是：借助沟通工具、记录跟进动作、完成交易程序，把一条销售线索一步步推向成交客户。
这一层想清楚了，后面做系统抽象才不会跑偏。很多规划出问题，都是因为在这一步偷了懒，业务场景没吃透，就直接开始画功能列表。
第二步，从业务到系统，做一次不带偏见的抽象。
同样，这一步也先别看任何现有系统。脑子里带着前面梳理的业务场景，去推演我们需要一个什么样的系统来把这些事跑起来。
首先，系统必须能承载业务的流转。流转靠什么？靠的是流程节点和节点之间的流通规则。这里的节点，就是客户所处的不同阶段——线索、潜在客户、成交客户。每个节点都需要一个客户列表页，以及一个能看清客户全貌的详情页或客户卡，这就是流程节点信息。而节点之间的流通，则需要定义清楚：满足什么条件才能从一个节点推到下一个节点（比如必须填完哪些信息、上传哪些附件），以及流通之后有没有什么限制（比如能不能回退，哪些节点之间不能跳转）。
其次，流程不会自己动，它需要被一些核心功能模块驱动。对照前面的业务梳理，工具模块（电话、短信、QQ等通信能力）、跟进动作记录模块（跟进动态、通话记录、短信记录、上门签到等）、交易程序模块（合同管理、收费管理、产品/服务管理）就自然浮现出来了。这些模块组合在一起，才能让销售在每一个节点上都有工具可用，有记录可查，有流程可走。
另外，任何一个系统都离不开一些通用支撑功能。用户管理、权限控制、消息通知、基础设置、帮助中心这些，基本是标配。但有一个模块需要特别拎出来——数据统计。很多系统都把数据统计当成一个纯粹的管理看板，但在CRM里，数据统计不光是对业务结果的分析，它还是用户做工作计划的一个工具。比如销售每天要打多少电话、跟进多少客户，这些计划与统计功能，其实应该放在驱动流程的核心位置，它直接影响到销售的执行节奏。所以，我们在做功能抽象时，会把计划管理模块也放到核心驱动层，而不是仅仅把它当成一个管理后台的报表。
这样一步步推下来，我们就会得到一个基于业务抽象出来的功能框架，而不是照着某个竞品系统抄的功能列表。这里有一个小插曲很能说明问题：我们当时推导功能时，把线索、潜在客户、成交客户分别编号为1、2、3。那线索是怎么来的呢？从0到1的过程，其实就是线索导入。于是，线索导入功能就顺理成章地衍生出来了，不是凭空拍脑袋加的。这个思考过程，比最终多一个功能重要得多。
当然，实际CRM系统里还有大量细节，比如数据回收机制、订单流转、财务对接、移动端功能等等，但那属于具体设计，不是规划阶段要死磕的事。做规划，关键是把主线拉出来，把功能的来龙去脉想明白。另外需要提醒一点，功能拆解出来的结果，并不等于系统菜单的划分，更不等于页面设计。后续我们还需要根据功能之间的依赖关系，做收敛、合并、拆分和嵌入，重组出合理的页面模块。这个重组过程就不展开了。
第三步，从功能清单到产品规划，把需求理出个轻重缓急。
到了这一步，终于可以看系统了，但也是最后一步才看。如果是从零开始做系统，前面那张功能拆解图基本就是第一版功能清单。如果是在现有系统上迭代，就需要用这张图去对照现状，看哪些功能缺失、哪些需要优化，最后整理出一份需求池。
拿到需求池以后，怎么排优先级？我习惯依赖三个互相独立的指标：需求类型、需求重要性、需求紧急性。它们各自内部有优先级，但组合在一起时，紧急程度通常先起版本规划的切割作用，同一版本里重要性再决定先后，同级别之下再参考需求类型。
具体来说，高紧急度的需求构成最近一个版本，中紧急度放下一版，低紧急度放进远期规划。在同一版本内，按重要性从高到低排；如果重要性也差不多，那线上Bug这类需求通常会优先于新功能、功能优化和技术需求。需求类型大致就分这四类，每个公司可能略有不同，但大框架差不多。
需求重要性怎么判断？一般会看企业战略、市场反馈、系统完整性和系统健壮性这些维度。紧急性则要看它是不是在主流程或关键路径上、有没有外部依赖（比如第三方接口）、有没有时间窗口约束、用户操作频率高不高、覆盖用户范围广不广。这些标准要根据自己公司的业务特点去定义，没有放之四海皆准的公式。
这样排完一轮，还只是初步规划。最终定稿前，一定要和开发、测试团队碰一遍，把研发资源、技术可行性、测试周期这些现实因素考虑进去，再和业务方确认，才算真正落地。这个过程靠的是沟通和协作，不是单方面拍板。
回头看整个规划过程，其实每一步都离不开方法论的支持。产品设计不是凭感觉或者主观判断，它需要一套可以推导、可以论证的思考路径。每个人的方法论可能不一样，甚至同一个人在不同阶段方法也会迭代，但只有靠方法论撑着，才能把产品工作做成一个可复现、可迭代的高质量过程，而不是碰运气。
最后补充一句，这篇文章里提到的CRM系统和业务，跟我们公司实际产品关系不大，所有功能和图表都是临时拟的。我只是借CRM这个壳，把从业务概念一步步推导出系统模型、再完成产品规划的思维过程讲清楚。读者真正需要留意的，是这种推导方法，而不是CRM系统本身的功能细节。如果这种思路能对你手头的规划工作有一点启发，那这次复盘的目的就达到了。