如何从打造完整的产品

　　未来商业都是要围绕着人展开的，广义的讲所有业务的产品都可以纳入CRM，CRM将是各大平台或商家适应未来商业环境的基础标配。
　　什么是CRM
　　CRM管理又称客户关系管理，我们用对象思维解释一下：实体是公司或企业，对象是客户，手段是结果管理和过程管理，目的是转化，结合管理的定义（标准化和流程化）整合成一句话就是对客户全生命周期管理抽象特点，以赋能管理手段扩大管理能力边界和提高管理效能。
　　当前业内CRM分个方向：
　　第一是O2O销售管理内，一般内部使用偏管理；
　　第二是如电商后台客户资源管理类，会有客户管理，会员系统，自动化营销系统等，偏分析和运营类。
　　未来商业都是要围绕着人展开的，广义的讲所有业务的产品都可以纳入CRM，CRM将是各大平台或商家适应未来商业环境的基础标配。
　　虽然市场的消费水平不断提升，各种触达渠道数不胜数，但是没有对客户精细化的运营，只是不断的讲产品，服务推送给用户的转化是极其惨淡的。
　　对产品和用户的精耕细作尤为重要，单纯采用流量漏洞的流量思维在当下也显得有些不够用，需要更灵活的标签系统，会员系统，超级会员等不断完善用户画像，通过用户浏览行为数据，购买数据，收藏加车的行为进行汇总，沉淀数据池。
　　不同纬度的数据汇集成数据集市，用地域值，时间值和模型值将数据池中的数据抽离出来赋能给应用进行高效的转化。
　　那么CRM的作用在哪？数据采集方式，数据格式化，对用户和产品服务分析后输出模型值赋能给各个应用，提升转化效率的作用。
　　CRM属于前台还是后台
　　首先CRM产品一定属于业务线产品，不能单纯的用前台，中台和后台的系统架构思路进行区隔，因为一个优秀的CRM产品都是业务型产品，通过业务架构思维指导产品设计，所以对产品的展示形态没有前台那么高的要求；（但还是要比后台要求高）
　　CRM又不像CMS，ERP，MQ，AMS，FIS，甚至更底层的如订单履约系统等完全属于后台产品架构，不难区分的就是这类系统无论在哪结构都高度相似，会根据公司业务和策略调整但是底层模型不会有大的变化。
　　所以明白了吗，CRM需要你懂一些前台设计和页面交互逻辑，懂后台架构和系统交互逻辑，一切为了满足业务需求，为什么？看后面实战激动了。
　　不啰嗦了，进入实战
　　项目目标
　　项目目标从01搭建带有社群管理的CRM系统。
　　项目重点
　　没有对产品全貌想清楚，不要动手开始画原型，因为CRM重点在管理，所以各个系统模块之间的交互会比普通产品复杂的多，先想清楚你要管理什么？
　　想清楚你要管理什么（如客户还是销售）；
　　第二步就是你的管理手段和抓手在哪里（是系统自动化判断还是运营支撑）；
　　你最后要达到什么效果，也就是目的是什么（重点关注数据层能否满足）；
　　管理方案（产品方案）。
　　总结：一切围绕着业务管理，针对你的目标想管理手段，最后想清楚产品方案，看到没有，这时候都没有去想原型有什么，因为还不到时候，此时你最重要的是想清楚产品结构和数据层的设计。
　　本次项目系统模块：消息中心，社群管理，客户管理，海域管理，客户跟进。（下一篇会讲管理思路和实战设计内容）
　　产品结构之概念模型
　　使用工具：UML。
　　（内容进行小部分脱敏）
　　概念模型的核心思路是在确认产品架构（架构图）后，梳理各模块之间的关联关系，系统交互方式和数据结构层的作用。
　　梳理概念模型的时，首先确认我们有哪个系统模块，确认每个模块的拆分合并的意义，每个模块内的数据字段的含义是什么？为什么要有这个字段用来干什么？然后看整个流程是否已经可以跑通，不存在数据断层和数据冗余的问题即可。
　　最后就是开始删改，为什么？
　　因为概念模型会让你想的大而全，是否有没必要的模块和流程的其中，流程能否进行优化，简化流程。
　　发现没有？没出原型的时候你已经可以思考优化方案，流程优化的东西了，当你自己在这个阶段都优化完，思考全了，后续产出的东西你还怕被喷被返工吗？不存在的。
　　概念模型梳理完成后开始进入USERCASE阶段。
　　产品数据权限之USERCASE
　　画USERCASE原因是CRM会为多种角色使用的场景（权限系统参考RBAC模型），所以各角色的数据权限需要思考到位，比如BD能看到什么能用什么功能，BDMCM能看到什么能用什么功能，甚至财务人员，运营人员等等都需要提前考虑到位。
　　为了能清晰的表达这之间的管理使用USERCASE最为方便。
　　USERCASE的核心作用帮你梳理业务边界，在这个阶段每个功能给谁用不给谁用，每个数据给谁展示，展示多少有控制，不给谁展示，为什么不展示等都要去思考到位，并且给自己一个说的过去的业务理由。
　　产品使用之业务流程图
　　CRM这类产品一定要画业务流程图！！！功能流程图可以不画，画了也是放在详细介绍中。
　　业务流程图使用泳道图来画，因为涉及到多角色多节点多状态（除了泳道图你能用别的办法画清楚请教我）。
　　泳道图顾名思义形状像一条条泳道一样的流程图，一般我顶部标头用角色或前后台区分，左部标头用功能或者状态区分，见图：
　　这是一张涉及多角色管理，但是流程比较简单的优惠卷发放业务流程图，目的主要就是为了进行资产单品管理（优惠卷也是资产）。
　　产品视觉之原型图
　　这个阶段可以开始动手画原型图了，看着你的概念模型，USERCASE和流程图，如果能把原型图画错那是我输了。
　　产品描述之功能清单
　　我们输出PRD（需求文档）前的一步是输出FRD，就是上面几个模块加上功能清单就是一份完整的FRD。
　　功能清单主要写功能模块，功能名称，功能描述，优先级（P0，P1）和PD，只要描述清楚你要做一个什么样的功能，非常详细的内容建议放在需求描述中去写，当然某个功能是特别需要主要的，或者这个项目特别的玩法数据权限内容可以详细描述在功能清单（方案闪光点）。
　　因为可以勾引开发哟，让开发很兴奋和期待下一段的项目来临（这对你的项目能否圆满完成有重要意义）。
　　产品立项之KICKOFF
　　手里有完整的FRD文档，这时候可以拿着你的FRD去找开发和leader去评估，因为你要做什么思路和样子已经很清楚了。
　　主要告诉开发FRD里的相关内容，开发评估能否实现（一般没问题，但还是怕有人脑洞大开），最重要的是确认评审时间（看你写详细需求需要多久和开发被释放时间）和开发人员配置，这就是项目kickoff阶段。
　　kickoff后建一个项目群（一般钉钉）把相关开发来进来，写邮件确认下次评审时间，同步FRD文档，开始正式写需求文档，到确认的时间点正常评审即可。
　　为什么kickoff阶段就要建群？
　　因为项目有很多不可控因素，如果你的主开发因为其它项目被耽误无法抽身需要提前告知你，你才能提前和项目经理报备想解决办法（拉别人或者延后），群就是一个高效的信息同步渠道，同时也让所有参与者都明确自己下一段时间要干什么，日常工作中能根据自己当前的情况即使反馈。
　　产品文档之需求文档
　　这其实没什么说的，FRD详细描述就是需求文档。每个人有自己的描述方式，只要表达清楚即可。
　　总结
　　本文完全实战内容，适用各个大厂（当然大厂有产品内部评审甚至更多流程），但是一个产品的个人修养部分也是较为全面，希望同僚共同进步，如有表达，理解错误请及时指正。