内容管理系统（CMS）的产品思维框架
#文章摘要#产品经理是一个涉猎广泛的职业人，好不夸张地讲个人知识储备是越丰富越有优势。因此，学无止境是产品经理一生的主旋律，知识永远不会嫌多。坦白讲，我是个实诚人，也非常相信规则一类的东西，比如：贝叶斯定律、经典力学牛顿三定律、质能方程（E=mc*c）等等。面对自己的知识、经验不足，显得有些不安甚至开始尝试大量的资料阅读。如果真地要较真的话，还得从我刚入门产品那会开始说起：
1、产品类型：一直从事面向C端大众消费群体的产品设计与研究，C端产品更加倾向于用户体验和商业运营，产品逻辑未占据主导地位，体现的不是不明显。换句话讲，产品业务逻辑相对比较简单，比较容易理解和解决。
2、工作内容：核心工作集中在需求管理、产品设计、产品文档、技术追踪、测试上线等产品前端工作，未能设计到产品后台业务的科学规划设计。当然，这个要感谢之前精诚合作的技术团队的同事，你们才是“最可爱的人”。
内容管理系统（CMS）的产品思维框架
这几年的产品工作，经历的很多，还是那句老话：非常感谢遇到的人和经历的事情！我觉得自己非常幸运，甚至说老天对我真的是疼爱有加。工作年限屈指可数，而主导/参与的产品还是蛮令人满意的。（有点小小的骄傲！）以产品形态为维度，大概包括：APP（工具型、内容型）、WEB（应用型、内容型[财经社区]）、H5（应用、活动、微信）、CMS（产品内容运营）。CMS（内容管理系统）是心中的痛，苦于之前公司的产品策略倾向于前台产品，核心的技术资源和资金投入也自然向面向C端产品线倾斜。当然，产品处于初期成长阶段必然决定了重视用户体验、以用户为中心的产品策略；其实还有一个更加重要的因素——业务形态，后台业务需求集中在产品内容运营。
正文
还记得，我之前写的《从一个项目实践说起，产品设计流程是什么样的》详细介绍了互联网产品设计流程，这套流程是普适的，可以应用到不同产品形态上。那么下面我就尝试着将这套流程应用到CMS（内容管理系统）的产品设计上面：
*Note：内容管理系统的产品设计思路仅限于产品阶段的思维构思过程，不涉及跨部门的交互内容。
一个完整的内容管理系统（CMS）的产品构思流程，大致可以概括为以下四个过程：需求管控、梳理流程、产品框架、迭代规划。
1、需求管控
理解需求是产品设计的第一步，如果说都没明白需求是什么，那么产品将只能摸着石头过河！不是危言耸听，而是切身体会。需求管理阶段，务必需要弄明白一下几个问题：
>提出需求的背景是什么？
>需求解决了用户的什么问题？是不是用户真正想要的？
>解决该需求有什么直接/间接商业价值？
>需求背后的商业模式和运营方式？
搞清楚了这个几个问题，在随后的产品设计中才不会一味摸瞎前进，那种感觉很艰难、痛苦，甚至会给你带来莫大的麻烦——你所做的不是需求方想要的。我能想象，此刻有一种“想死的冲动”！需求管控是产品过程的核心环节，无论哪种产品类型都很关键、都需要付出更多感情和精力。更何况是“业务逻辑”主导的CMS（内容管理系统）呢？
2、梳理流程
内容管理系统（CMS）管理的是内容，而内容来源于哪里呢？用户生产内容和运营支持内容，如何理解呢？
a. C端注册用户，在网站上生产内容。业务性的产品核心就是实现业务流的运转，上下游实现资源的有效传递，最大化压缩成本，实现利益最大化。因此，UGC为CMS内容管理的核心内容来源，也是业务驱动的产品的价值增长点。
b. 运营类型的内容网站，除了用户与后台的内容交互之外；产品本身也提供了必要的运营内容，这部分的资源也需要借助CMS（内容管理系统）实现高效配置。
c. 业务交互性内容是产品前后台最主要的数据流，还有一部分自然数据，而这部分数据恰恰又是之后数据分析、经营性分析的基础。重视自然数据的长尾价值，积累用户行为数据，挖掘用户价值。
从形式上讲，产品越流程的梳理通常借助流程图可视化，流程图又包括：状态图、业务流程图、泳道图等具体的样式。业务流程能清晰地解构出，前后台的数据之间的交互。重点关注核心业务流程，梳理次要业务流程，分清主次，抓住主要矛盾。
流程图[状态图]：
产品业务流程图之状态图
3、框架设计
前面两个步骤基本解决了“做什么”的问题，接下来就是“怎么做“的问题。理解用户用户所需，明确产品业务的核心流程，接下来就是将需求和想法进一步的可视化，而这个环节将借助：功能导图、产品原型。更高维度的信息加工，将原本复杂的产品需求进一步精化为更为立体的功能结构框架，使其更具可行性和落地性。
a. 功能导图：理解需求的基础上，抽象需求为立体的功能。需求分类、功能结构重组，搭建良好的产品信息架构（IA），行业性质浓厚的产品需要专业人员的介入，增加产品信息架构的专业度和行业边界。一眼看尽产品的宏观功能框架，对产品的每一次延展都了然于胸。
b. 产品原型：很多人都喜欢这一产品产物，甚至说很多人一上来就开始画原型，我觉得很糟糕、毫无意义。产品原型是对已经拥有明确思路和需求范围的产品构想的重现过程，是一个快速重现和迭代的过程，而不是思维的依赖。正如我之前说的，产品经理最重要的特质就是——思考。
产品框架示例：
产品原型设计图
4、迭代规划
产品框架设计本着从愿景的角度出发，确保产品本身的可扩展性、可性行的，方便产品的客气敏捷迭代。分期迭代或源于实际情况，亦或产品策略性调整，而问题的关键在于分期迭代的动机和目的。产品分期迭代升级的因素有很多，大致包括以下几个情况：
a. 客观情况：技术资源紧缺、资金投入定量，必定在客观情况上限制了周期内的产品规模和体量。我想表达的并不是“没资源就不做了！”而是最大化资源利用率，推进产品创造可能。
b. 产品规划：产品发展角度来说，周期性的迭代升级有利于产品的良性进化循环。产品需求量大迫使产品不得不依据需求的紧迫程度规定优先级，在可落地上多做尝试、多做努力。
[产品版本规划]：
产品版本规划
行文小结
这一瞬间，我似乎透彻地明白一个道理：学无止境！以怎样的方式才能洞悉世间万物呢？想必穷尽我一生的所愿都不可能实现呢... 可我还是心有不甘，尝试将自己所经历的每一个产品过程抽象为一个个具体的思维构思过程，从而让自己的身后的很多事情有一个可参考的依据和背书。以上就是我个人尝试搭建的CMS（内容管理系统）的产品构思的思考过程，业务驱动的内容管理系统（CMS）更加侧重业务流的处理，业务流程的产品逻辑重要性更加突出。
尝试着以一种科学的思维模式去构建一款CMS（内容管理系统），需求管控、梳理流程、产品框架、迭代规划，每一步都值得付出更多努力和感情！与之前写的《从一个项目实践说起，产品设计流程是什么样的》相比较，内容管理系统（CMS）的思维过程只是原有产品框架基础上的再改造，产品重心的适当调整，产品策略的场景性变化。
这也印证了一句话：每一次的努力，收获的却是全世界！
原创声明：本文章的最终解释权归产品小王所有，如需转载，请注明文章出处！谢谢...
