我們做產(chǎn)品經(jīng)理，總是會面臨一個固定問題：

這個需求/功能到底復雜嗎？

評估功能復雜度是非常重要的，因為這影響了我們的需求優(yōu)先級。

同時功能復雜度如果不會評判，就會浪費團隊資源甚至是延期項目，尤其是對于老板、產(chǎn)品經(jīng)理來說很容易蒙在鼓里。稍微提一個需求就是一個月或者更長時間，難免讓需求提出人、產(chǎn)品經(jīng)理們覺得黃花菜都涼了。所以我們對于一個功能的復雜度評判的需求是非常剛需的，我們急需要一個好的技巧方法來幫助評判功能的復雜度。

掌握功能的復雜度判斷也就是知道了問題的解決成本，但對產(chǎn)品經(jīng)理來說，功能復雜程度由開發(fā)同學來評判的，自己很難有話語權。99%公司的產(chǎn)品經(jīng)理，離開了開發(fā)什么都不是，只能任其開發(fā)宰割，影響了業(yè)務發(fā)展。

都說產(chǎn)品經(jīng)理要懂數(shù)據(jù)分析、商業(yè)化、增長等多向，但我始終認為評估1個產(chǎn)品經(jīng)理評判對1個功能的復雜度能力是其核心工作價值體現(xiàn)。

其實不僅是產(chǎn)品經(jīng)理，運營等業(yè)務部門也同樣需要知道功能復雜度評判的能力，比如運營需求、數(shù)據(jù)需求，也會需要有開發(fā)介入才能完成。

為了寫這篇文章，我也查找了不少網(wǎng)上的同類文章，發(fā)現(xiàn)很少有產(chǎn)品經(jīng)理去分享這類，反而是開發(fā)同學們分析技術的多。

所以我這里分享5種方法，可以幫助你快速評判一個功能復雜度。

第一：交互越多越復雜

如下面這2個圖，一個是PMTalkApp首頁信息流、一個是提問內(nèi)容編輯頁面，看這2個頁面其實包含了多個功能。

左邊的頁面是PMTalk app的首頁，包含了推薦、作者投稿、問答、原創(chuàng)榜、本周精選功能，組件有導航欄、搜索框、文章標題、文章頭像、點贊、閱讀量等，元素比右邊多很多。

右邊則是包含了標題輸入、問題詳情描述、圖片上傳、話題選擇、還要匿名，看起來右邊的元素更少，那么你認為左邊的功能更加復雜還是右邊呢？

實際上右邊的開發(fā)復雜的多，左邊的卻簡單。

左邊的我們可以稱之為純數(shù)據(jù)展示頁面，信息流里面包含的每個元素是固定的，由后臺提供對應的接口進行數(shù)據(jù)傳輸，其余的就是重復展示工作了。

對于純展示頁面，前端開發(fā)只需要處理好頁面的樣式，就不用考慮其他問題，看起來這個文章排序很多，實際上就是相同的結構不斷重復調(diào)取接口數(shù)據(jù)。

你可以抽象為下面的樣式，是不是就很簡單了？

前端開發(fā)只需要把這個結構模版寫好，填入頭像、標題、名稱、話題、點贊數(shù)、喜歡數(shù)、封面就可以了。

交互包含兩類，一類是動畫交互效果，沒有后端服務數(shù)據(jù)；另外一類是有后端數(shù)據(jù)的交互，比如下圖會有數(shù)據(jù)的讀寫操作，就屬于這一類。

右邊的簡單的填寫框、圖片展示就是第二類交互型，開發(fā)需要處理點擊前后、懸浮、用戶輸入特殊字符、圖片插入、其他格式文件插入，用戶的這系列操作后，又需要怎么展示都需要服務端的實時數(shù)據(jù)查詢，標題輸入和問題描述輸入看起來兩個差不多的輸入框，實際需要分別校驗

輸入的字符長度 標題有沒有重復 內(nèi)容是否為空 內(nèi)容是否有違規(guī)詞（需要安全系統(tǒng)審核） 圖片是否要壓縮，什么樣的尺寸進行預覽

這都是在需要用戶行為在后臺交互的，元素少實際上開發(fā)成本高。

第二個是組件化程度越高，越簡單

做產(chǎn)品經(jīng)理的同學如果有用過原型工具應該可以快速理解這個道理，我們在做需求的時候如果涉及到導航欄、時間、篩選器、分頁這類組件，最快的方法是用現(xiàn)成的部件庫自帶組件去完成這類需求的原型設計工作。

功能的開發(fā)復雜度也是一樣，越是組件化程度越高的需求，功能開發(fā)越簡單。比如上傳文件、彈窗、toast提示等等，都是一套組件，可以大大提升開發(fā)效率。

尤其是我自己用的組件庫，就是經(jīng)過工作幾年積累的，覆蓋了B端、C端各類功能，你可以在本篇公眾號回復：“Kevin的部件庫“獲得下載地址。

第三點：瀏覽器/設備終端兼容

這一點是僅針對前端、客戶端同學來說，比如WEB類產(chǎn)品，我們經(jīng)常會出現(xiàn)要求網(wǎng)站瀏覽不是適配的情況，而在非IE瀏覽器就正常，是因為這類WEB產(chǎn)品沒有對IE做兼容處理，導致出現(xiàn)功能缺失、頁面展示不正常。

凡事需要IE兼容的需求都不簡單，建議盡可能不要提出滿足IE瀏覽器兼容，因為IE瀏覽器對某些交互動效難以運行，即使支持了也會渲染慢，很多頭部門戶類產(chǎn)品會放棄對IE的支持。

設備終端的App也是同樣道理，尤其是安卓機型海量，我們難以有精力去做每個設備的屏幕、尺寸進行適配，所以這類涉及到對多樣終端兼容的需求也很復雜。

第四：橫向跨系統(tǒng)數(shù)

一個功能如果剛開始就涉及橫跨多個業(yè)務系統(tǒng)，那這個工程也是浩大的，比如一個用戶登錄注冊的賬戶體系，公司必須要考慮未來會有其他業(yè)務線會使用這套賬戶，因此賬戶體系往往開發(fā)時間都會要在1個月左右。

如果賬戶體系涉及到權限、第三方登錄、用戶信息錄入、用戶管理、數(shù)據(jù)統(tǒng)計開發(fā)時間就更長了。

跨系統(tǒng)同樣還有跨功能數(shù)，功能之間是否有權限、有二次認證等。往往不同的功能服務業(yè)務不一樣，所以我們還要考慮對方使用的技術框架、功能邏輯，保證用戶體驗一致。

所以在涉及到的需求盡量少橫跨系統(tǒng)。

第五：是否需要硬核技術

在做產(chǎn)品設計的時候，為了符合時代需求，我們總需要一些新技術的能力，比如我們提到的AI、音頻識別、直播、圖片識別、云存儲這類，這類99%的互聯(lián)網(wǎng)企業(yè)都會選擇第三方進行采購。

因為自己研發(fā)的成本太高了，所以才會有所謂的saas、開放平臺，通過付費接入的形式獲得穩(wěn)定的能力，比如保利威直播提供了直播相關的SDK，允許企業(yè)快速接入。

這類功能就不需要自己研發(fā)了，而且就算做出來了也難以達到主流的用戶體驗。

如何提升自己判斷功能復雜度的能力？

如果你問我，怎么總結出來上面5個點的，其實方法很笨，但是也很簡單，那就是多體驗產(chǎn)品。每做一個需求之前除了體驗競品，還要在日常生活里養(yǎng)成拆解產(chǎn)品的習慣。

當然隨著工作時間久了，我們也能積累功能復雜度的經(jīng)驗，但這是被動的經(jīng)驗獲取，因為你需要不斷的花時間在工作里做需求，踩坑后就可以知道了，自然就做過各種各樣的功能，尤其是對于5年以上的產(chǎn)品經(jīng)理，你很難給他去溝通擅長什么樣產(chǎn)品設計，因為5年后的產(chǎn)品經(jīng)理做的多，也體驗的多，什么C端產(chǎn)品、B端產(chǎn)品、還是數(shù)據(jù)產(chǎn)品無非就是代碼來實現(xiàn)的，因此都擅長。

同時有開發(fā)基礎的產(chǎn)品經(jīng)理是非常好的優(yōu)勢，尤其是有后臺開發(fā)的產(chǎn)品經(jīng)理，這將幫助你快速評判功能的復雜度，增加和開發(fā)溝通的效率。

即使技術在瞬息萬變，我們也能用不變的開發(fā)基礎來進行溝通。

還有一種就是不斷的打怪，隨時把自己的工作投入在產(chǎn)品研發(fā)中，就可以積累不少功能的復雜度評判經(jīng)驗。

參考圖示：

functional complexity mesureme

關鍵詞： 如何判斷