對待產品項目,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.總結、積累對象屬性
匯總所接觸的對象屬性,形成屬性池??梢杂肊xcel表格匯集起來。這樣的好處在于:
- 便于加深記住各種各樣的產品需求屬性,防止在項目實現的過程中忘記疏漏。
- 豐富產品經理對常見產品的屬性的認識,積累量達到一定程度后,自然會有不一樣的效果,無論是原型圖,還是PRD,都會下筆如有神,百密無疏。
3.習慣對標,逐步完善需求集合
對象的屬性池是為了產品經理而服務的,當產品經理靠著自己的記憶力完成了原型、PRD后,可以對著自己總結的對象屬性池進行對標,看看是否存在屬性池中的情況,但自己卻忘記了設計對應的交互效果等。這能幫助產品經理巨細兼顧。
另外,產品經理也要不斷積累、優化自己的屬性池。畢竟經歷的項目多了,也會接觸到各種豐富的對象屬性。從而更好的幫助產品經理對項目巨細兼顧。
三、 總結對象實現方法,善于調用
1.什么是實現方法
當產品經理經歷的項目多了以后,會發現在做其他類似的項目時,其實可以引用之前的經驗、方法,這就是我要說的對象的實現方法的要點所在。
六級維度中“系統、功能、模塊”才具有實現方法的特點:
- 系統:要實現一個需求,需要哪些系統才能配合達到滿足需求的目標。這些方法,很多不同公司之間大同小異的方法。
- 功能模塊:一個行業的產品中,可以有哪些功能,這些功能應該如何實現,這也是具有經驗特點的。這其中就是方法。
- 內容區域:一個什么需求的頁面,都一般會有哪些模塊組成。即使沒有現成的,但分析思路總會有些經驗可借鑒的,這也是方法。
綜上所看,我個人想表達的是:方法總會存在經驗性的特點,可以拿來引用。當然,也要實事求是,因地制宜。具體情況具體分析。
如何將這些方法運用好呢,也是沒有更好的方法,還是總結、積累。
2.總結、積累方法
對每個接觸過的項目,都要有總結分析思路、實現手段的習慣。形成一個方法庫。
- 總結、積累出這些方法總會給你帶來印象深刻的效果
- 快速的輸出一個新項目的實現方案。
- 成熟的方法可以幫產品經理完整的去實現一個功能,也會產生避免疏漏的作用。
3.善于調用方法,逐步完善方法
從積累的方法庫中,不斷的調取使用到新的項目中,可以帶來很多效果。高效、便捷、避免疏漏。在巨細兼顧的項目中是一個不錯的習慣。
當然,產品經理也要去維護、更新、優化自己的方法庫。接觸各種各樣的項目,自然會總結到各種各樣的方法;去實現各種各樣的項目時,也要具體情況具體運用方法庫中的方法。
四、 流程和對象兩種方式有機組合
1.兩者的優缺點
- 流程優點:有順序的感覺,和生活的事情很相似,有時間先后的特點。實現團隊分工需要流程來控制輸出任務內容。
- 流程缺點:流程化一個項目,容易遺漏,不能全局的去觀察項目。很多項目中的事項是平行的,結構化的。
- 對象優點:結構化,更全面的分析項目。
- 對象缺點:沒有順序性。
2.互補的意義
推進項目一定要有流程的方法去推動,把握時間點,協調項目各個實現團隊的工作進程。
分析項目一定要有對象的方法去分析。結構化項目,對每個層級、類別對象各個擊破。
兩者結合起來,才能讓產品經理更好的分析項目,最終推動項目的實現。
五、因地適宜,靈活運用
如何拆分對象,對象的屬性、方法又是如何,流程和對象思維方式又是怎么樣,這些都需要因地適宜,靈活運用。
- 因公司項目不同而靈活運用。
- 因團隊風格不同而靈活運用。
- 因個人習慣不同而靈活運用。
合適的才是更好的。
本文由 @中人PM 原創發布于人人都是產品經理。未經許可,禁止轉載。
我做產品時,就是通過思維導圖整理模塊、功能點及模塊間的關系,Excel細化需求,最后出產品原型。
我借鑒借鑒你的方法