對待產品項目，PM如何巨細兼顧？

在項目進展的過程中，無論如何的細緻，真實過程中總會出現遺漏、疏忽的地方。那麼如何規避這樣的問題，作者拋出了自己的一些思考。

拋出問題：項目中難以巨細兼顧

產品經理在工作中承擔起一整個項目時，往往會從一個流程的角度去思考項目如何一步步開展，又如何在開展中聚集、協調資源，最終儘可能的推動去達到一個預期效果。這種思路的特點是運用自然、先後有序，已成為眾多人的習慣。但大家有沒有發現，無論如何的細緻，真實過程中總會出現遺漏、疏忽的地方。甚至涉及到一些非常簡單的細節時，在做出方案後都會讓人覺著欠缺思考。

我個人的總結，這並不是單純想的夠不夠細緻的問題，排除因人而異的大腦思維能力–這個在我看來並不重要的因素，從客觀規律角度看，最重要的原因在於按流程的思維方式來處理不同細微、宏觀等類別的事情，需要大腦不斷來迴轉換、兼顧，總難免會出現以上的問題，事情量大繁多時更易如此。所以，要予以避免這種現象發生，就必須在思考模式上改變。

解決方案：拆解項目為若干對象，各個擊破一、 按層級、類別拆解對象，結構化思考

當一個項目較大時，會牽扯到方方面面，內容繁雜。產品經理在規劃整體項目方向的同時，又要設計每個功能的具體細節。以我個人的經驗，可以採用一種思維方式處理好這種巨細兼顧的項目：從不同層級、類別角度將整體項目拆解為各個對象，然後再針對各個對象，從不同層級、類別角度拆解為更小顆粒度的對象，直到最小化的顆粒度對象為止；對拆解的每個層級、類別的對象進行單獨的規劃、設計。這裡的對象是指一定量的功能的集合，可以是一個系統，可以是一個頁面，甚至可以是一個功能模塊。當然也可以先不用管這個抽象的概念，接下來的對這個思維模式的詳細說明中，大家會理解到什麼是對象的。

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 原創發佈於人人都是產品經理。未經許可，禁止轉載。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！