在项目进展的过程中，无论如何的细致，真实过程中总会出现遗漏、疏忽的地方。那么如何规避这样的问题，作者抛出了自己的一些思考。
抛出问题：项目中难以巨细兼顾
产品经理在工作中承担起一整个项目时，往往会从一个流程的角度去思考项目如何一步步开展，又如何在开展中聚集、协调资源，最终尽可能的推动去达到一个预期效果。这种思路的特点是运用自然、先后有序，已成为众多人的习惯。但大家有没有发现，无论如何的细致，真实过程中总会出现遗漏、疏忽的地方。甚至涉及到一些非常简单的细节时，在做出方案后都会让人觉着欠缺思考。
我个人的总结，这并不是单纯想的够不够细致的问题，排除因人而异的大脑思维能力–这个在我看来并不重要的因素，从客观规律角度看，最重要的原因在于按流程的思维方式来处理不同细微、宏观等类别的事情，需要大脑不断来回转换、兼顾，总难免会出现以上的问题，事情量大繁多时更易如此。所以，要予以避免这种现象发生，就必须在思考模式上改变。
解决方案：拆解项目为若干对象，各个击破
当一个项目较大时，会牵扯到方方面面，内容繁杂。产品经理在规划整体项目方向的同时，又要设计每个功能的具体细节。以我个人的经验，可以采用一种思维方式处理好这种巨细兼顾的项目：从不同层级、类别角度将整体项目拆解为各个对象，然后再针对各个对象，从不同层级、类别角度拆解为更小颗粒度的对象，直到最小化的颗粒度对象为止；对拆解的每个层级、类别的对象进行单独的规划、设计。这里的对象是指一定量的功能的集合，可以是一个系统，可以是一个页面，甚至可以是一个功能模块。当然也可以先不用管这个抽象的概念，接下来的对这个思维模式的详细说明中，大家会理解到什么是对象的。
概括：按“系统>端>功能模块>页面>内容区域>元素”六级维度，将项目从巨到细逐层级拆分为不同类别的对象。
举例：
对一个项目：可以按系统类型分拆，例如：权限系统、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.互补的意义
推进项目一定要有流程的方法去推动，把握时间点，协调项目各个实现团队的工作进程。
分析项目一定要有对象的方法去分析。结构化项目，对每个层级、类别对象各个击破。
两者结合起来，才能让产品经理更好的分析项目，最终推动项目的实现。
五、因地适宜，灵活运用
如何拆分对象，对象的属性、方法又是如何，流程和对象思维方式又是怎么样，这些都需要因地适宜，灵活运用。
因公司项目不同而灵活运用。
因团队风格不同而灵活运用。
因个人习惯不同而灵活运用。
合适的才是更好的。
