在项目进展的过程中，无论如何的细致，真实过程中总会出现遗漏、疏忽的地方。那么如何规避这样的问题，作者抛出了自己的一些思考。
产品经理在工作中承担起一整个项目时，往往会从一个流程的角度去思考项目如何一步步开展，又如何在开展中聚集、协调资源，最终尽可能的推动去达到一个预期效果。这种思路的特点是运用自然、先后有序，已成为众多人的习惯。但大家有没有发现，无论如何的细致，真实过程中总会出现遗漏、疏忽的地方。甚至涉及到一些非常简单的细节时，在做出方案后都会让人觉着欠缺思考。
我个人的总结，这并不是单纯想的够不够细致的问题，排除因人而异的大脑思维能力–这个在我看来并不重要的因素，从客观规律角度看，最重要的原因在于按流程的思维方式来处理不同细微、宏观等类别的事情，需要大脑不断来回转换、兼顾，总难免会出现以上的问题，事情量大繁多时更易如此。所以，要予以避免这种现象发生，就必须在思考模式上改变。
解决方案：拆解项目为若干对象，各个击破一、 按层级、类别拆解对象，结构化思考当一个项目较大时，会牵扯到方方面面，内容繁杂。产品经理在规划整体项目方向的同时，又要设计每个功能的具体细节。以我个人的经验，可以采用一种思维方式处理好这种巨细兼顾的项目：从不同层级、类别角度将整体项目拆解为各个对象，然后再针对各个对象，从不同层级、类别角度拆解为更小颗粒度的对象，直到最小化的颗粒度对象为止；对拆解的每个层级、类别的对象进行单独的规划、设计。这里的对象是指一定量的功能的集合，可以是一个系统，可以是一个页面，甚至可以是一个功能模块。当然也可以先不用管这个抽象的概念，接下来的对这个思维模式的详细说明中，大家会理解到什么是对象的。
1.逐层级拆分为不同类别的对象
概括：按“系统>端>功能模块>页面>内容区域>元素”六级维度，将项目从巨到细逐层级拆分为不同类别的对象。
举例：
对一个项目：可以按系统类型分拆，例如：权限系统、CRM、CMS等。对一个系统，可拆分为APP、M、PC、TV等对一个端，可以分拆为数据中心、支付结算、订单功能、库存管理、会员管理和权限管理等功能。对一个功能模块，可以拆分为入口、列表页、详情页、结果页等。对一个页面，可以分拆为导航栏、内容区域、工具栏、菜单栏等。对一个内容区域，可以拆分为列表、搜索筛选、批量选择等。通过这些举例，来归纳下什么是层级，什么是类别，以及如何去按层级、按类别去拆分对象。
我个人的经验来看，层级和类别都没有固定的概念。往往需要根据具体的项目和每个PM的习惯情况来定。
就好比上面的举例：
层级一般指产品形态，例如系统、端（APP端、M端、PC端等）、页面、内容区域等；类别一般指功能的类别，例如会员中心、订单中心等。在整个拆分对象的角度中，“系统、功能、内容区域”是类别关系的对象，“端、页面、元素”是层级关系的对象，它们之间相互穿插。这并不表示是逻辑混乱，反而是梳理思路、项目的思路。单纯的类别太抽象，单纯的层级太具体。我个人的想法是将功能类别和页面层级统一放在一起，这样一目了然整个项目情况。不用单独的建立一个功能结构、页面框架。当然单独建立也可以，但一个统一的思路图更容易、更便捷的纵观全局，才能更好的让PM在做项目时，从大到小逐条理清，巨细兼顾。
具体的实际中的工作中如何做呢？例如在画原型时，先将整个项目的框架按层级、类别搭建好，注意这时先不要画任何细节。每个层级、类别搭建好了以后，再在每个层级、类别下面建立下一级要拆分的对象，就这样逐级完成，直到设计页面、布局模块、添加元素。在设计页面时，完全可将某一些同类的页面放在一起，统称为某类功能；多个类别功能，又可放在一起视为一个端。这样看上去，整个原型会类目清晰，方便查看、编辑。同样在制作PRD时也是如此。如果能做好这样的过程，无论是大的功能还是小的元素，都会列在PM的工作空间中，不会漏掉。
其实大家可以看到这里的层级、类别都是大多数公司常见的产品概念，可以很好的兼容不同公司的项目。将这些常见的概念梳理一下，形成一个新的做项目的思路。这个思路只要管用，便于理解，容易运用到真实的项目，就是个好的思路。PM应该尝试去理解着运用，直到琢磨出符合自己习惯的路子，那就是真的把一种思维方式用到家了。
2.把握每个层级的核心，围绕核心全面展开拆分
概括：在按层级和类别拆分对象时，一定要把握核心的部分，围绕核心全面的展开拆分
每个层级的对象，在当前项目中，都有自己的核心部分。为了能在拆分过程中，主次分明，对核心的部分不能有疏漏，这时需要一种思维：先中心再周围。
如果在设计某个层级、类别的子对象时，不知从何角度下手，或者不知是否做到了全面的考虑，产品经理不妨先从核心的部分予以梳理，相关的方方面面按要实现的目标为基准：要实现什么，需要什么等等，予以展开梳理、拆分。例如系统拆分时，比较多的是侧重移动端APP。功能类别上拆分会将高频、刚需、痛点作为核心。页面上，把一些流量大、访问频繁的页面作为核心。而页面中，将最重要的一部分内容最大化的醒目布局。
另外，把握住核心部分，其实也是为了避免风险，别把主要的部分放在了风险的地步。其他细枝末节可以有疏漏，但核心的还是要做到万无一失。
3.将拆分对象建立在需求的基础上
其实，产品经理在拆分对象时，不能只取考虑拆分、层级、类别。这些都是形式化的东西，做产品最根本的还是要理解、实现需求。在拆分对象的过程中当然也是要时时刻刻考虑到需求的。系统类别、端层级、功能类别、页面层级、模块类别、元素层级这六级维度都要考虑。
系统类别：系统的存在是为了满足一个需求集合而存在的。系统虽大、繁杂，但离不开需求的导向。系统要满足什么需求，决定着需要哪些端。端层级：一般公司的产品是三端APP、M、PC。这些都是针对不同需求场景下的产品形态。需求是其根本。端要满足什么需求，决定着需要哪些功能。功能模块类别：功能直接是为了服务需求的，有需求才有功能。在做功能类别的拆分时，要建立在需求的基础上。哪些需求是相关联的，非常重要的，高频的，刚需的，痛点的等等。在功能类别上都要有清晰的认识。功能要满足什么需求，决定着需要哪些页面。页面层级：哪些页面是高频访问的，必须的，承载主要内容的，是做成APP原生还是H5，是浮层还是新页面等。在拆分页面这一层级时，要建立在需求的角度上予以考虑这些因素。怎么样的页面才能更好的满足需求，达到一个良好的体验。页面要满足什么需求，决定着需要哪些模块。内容区域类别：一个页面中，它包含了哪些模块，这些模块又该如何满足需求，达到良好的体验。模块放在什么位置，占位面积多大合适，以什么样的形式等等，都是需要考虑的点。模块要满足什么需求，决定着需要哪些元素。元素层级：具体的页面模块中的元素，它们的存在与否全是依靠着需求、体验的。建立在需求角度上自然是理所应当。元素可以说是最小颗粒度的满足需求的对象了。我们可以看到六级维度拆分对象时，是相互关联的，而关联的根本就是需求。
4.明确拆分对象的目的、定位
每一个层级、类别的对象都是从需求中定的，那么这些对象就应该有对应的目的、定位。明确对象的定位，可以更好的确定对象的主次位置，方向，实现手段。
假设产品经理不明确对象的定位、目的，那么甚至不能够准确的进行下一层的拆分，不能搞清楚对象应该实现什么，怎么实现。
其实，在上面讲到六级维度都建立在需求基础之上的。这个需求基础就可以引申出每级维度的对象的定位、目的。
5.拆分的意义、目的
全面、大局条理、清晰便捷、维护二、 总结对象需求属性，习惯对标1.什么是需求属性
对象的需求属性是指对象在实现时，会涉及到哪些产品需求的属性。我的观点在六级维度中，只有端、页面、元素这三个层级维度，会涉及到属性。
例如：
端层级：APP层级对象和PC层级对象属性是决然不同的。APP要分iOS和Android两端，产品需要打包上线，iOS系统比较统一，Android杂乱，适配难度大；PC顶多是浏览器兼容、适配。页面层级，APP原生的页面和H5页面决然不同。它们各自优缺点是什么，原生的整体体验要好于H5，但H5开发成本、维护成本低，升级体验好。网络异常情况的提示交互，数据为空时的提示交互。元素层级：文本框的属性包括字符限制、长度限制、校验规则。列表的属性包括表头、行、列、分页等。以上都是对象的属性。这些属性，往往会在做项目中难以做到精确细致。那么如何在巨细兼有的项目中，保证这些属性不会疏漏呢？我个人的观点没有好的方法，只有一点点的总结、积累。
2.总结、积累对象属性
汇总所接触的对象属性，形成属性池。可以用Excel表格汇集起来。这样的好处在于：
便于加深记住各种各样的产品需求属性，防止在项目实现的过程中忘记疏漏。丰富产品经理对常见产品的属性的认识，积累量达到一定程度后，自然会有不一样的效果，无论是原型图，还是PRD，都会下笔如有神，百密无疏。3.习惯对标，逐步完善需求集合
对象的属性池是为了产品经理而服务的，当产品经理靠着自己的记忆力完成了原型、PRD后，可以对着自己总结的对象属性池进行对标，看看是否存在属性池中的情况，但自己却忘记了设计对应的交互效果等。这能帮助产品经理巨细兼顾。
另外，产品经理也要不断积累、优化自己的属性池。毕竟经历的项目多了，也会接触到各种丰富的对象属性。从而更好的帮助产品经理对项目巨细兼顾。
三、 总结对象实现方法，善于调用1.什么是实现方法
当产品经理经历的项目多了以后，会发现在做其他类似的项目时，其实可以引用之前的经验、方法，这就是我要说的对象的实现方法的要点所在。
六级维度中“系统、功能、模块”才具有实现方法的特点：
系统：要实现一个需求，需要哪些系统才能配合达到满足需求的目标。这些方法，很多不同公司之间大同小异的方法。功能模块：一个行业的产品中，可以有哪些功能，这些功能应该如何实现，这也是具有经验特点的。这其中就是方法。内容区域：一个什么需求的页面，都一般会有哪些模块组成。即使没有现成的，但分析思路总会有些经验可借鉴的，这也是方法。综上所看，我个人想表达的是：方法总会存在经验性的特点，可以拿来引用。当然，也要实事求是，因地制宜。具体情况具体分析。
如何将这些方法运用好呢，也是没有更好的方法，还是总结、积累。
2.总结、积累方法
对每个接触过的项目，都要有总结分析思路、实现手段的习惯。形成一个方法库。
总结、积累出这些方法总会给你带来印象深刻的效果快速的输出一个新项目的实现方案。成熟的方法可以帮产品经理完整的去实现一个功能，也会产生避免疏漏的作用。3.善于调用方法，逐步完善方法
从积累的方法库中，不断的调取使用到新的项目中，可以带来很多效果。高效、便捷、避免疏漏。在巨细兼顾的项目中是一个不错的习惯。
当然，产品经理也要去维护、更新、优化自己的方法库。接触各种各样的项目，自然会总结到各种各样的方法；去实现各种各样的项目时，也要具体情况具体运用方法库中的方法。
四、 流程和对象两种方式有机组合1.两者的优缺点
流程优点：有顺序的感觉，和生活的事情很相似，有时间先后的特点。实现团队分工需要流程来控制输出任务内容。流程缺点：流程化一个项目，容易遗漏，不能全局的去观察项目。很多项目中的事项是平行的，结构化的。对象优点：结构化，更全面的分析项目。对象缺点：没有顺序性。2.互补的意义
推进项目一定要有流程的方法去推动，把握时间点，协调项目各个实现团队的工作进程。
分析项目一定要有对象的方法去分析。结构化项目，对每个层级、类别对象各个击破。
两者结合起来，才能让产品经理更好的分析项目，最终推动项目的实现。
五、因地适宜，灵活运用如何拆分对象，对象的属性、方法又是如何，流程和对象思维方式又是怎么样，这些都需要因地适宜，灵活运用。
因公司项目不同而灵活运用。因团队风格不同而灵活运用。因个人习惯不同而灵活运用。合适的才是更好的。
文章作者系 @中人PM 未经许可，禁止转载。
本文章地址http://www.vzeo.com/news/xuetang/800191.html 由 友站网 编辑整理，转载请注明出处
