起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識需求是一個天坑，里面塞滿了各種功能
經歷過產品任何階段的人都對產品需求有深刻的印象，每個周期都會堆了很多很多需求，產品的BUG還沒解決就又冒出各種各樣的新需求，伴隨著需求的不斷增加，產品的問題也越來越多。最初小而美的產品經過幾次大迭代就變得復雜臃腫，難以駕馭。
其實各種問題的根源基本上都能追述到產品規劃階段的需求整理階段。這個時期也是各個類型工作混雜在一起，使得所有人焦頭爛額的階段，這個時候不僅會有一個勁兒只強調大方向的偽指揮官，還有死盯著細節不放的小嘍啰，更多的是只把自己當標準用戶的麻煩制造者。
需求匯總啟動前要明確幾點功能與需求之間的關系。
一、基礎功能不等同于基礎需求
基礎功能是軟件定位中最重要的部分，雖然基礎功能是從基礎需求中誕生的，但完整的基礎功能并不是跟基礎需求一一對應的，這個話看起來有點繞，舉個比較簡單的例子，比如，基礎需求是閱讀書籍、新聞資訊、笑話段子，這里對應的基礎功能就是一個——內容展示。這個基礎功能的細節可能會有文字、圖片、視頻等要素，其中文字顯示又分標題、內容、注釋等等。
因此，這里要注意在獲取需求的時候，哪些需求是獨立的，哪些需求是可以合并的，是除了定義基礎需求后關鍵的一環。產品經理要以需求分析的身份進入到產品之中，分析需求與功能之間的隸屬結構。
這里有人會問，這個工作有什么用。一個一個需求提，一個一個功能做不也是可以么？
的確可以，在客戶端使用上從視覺效果看起來沒有什么不同。后面開發就完全不一樣了，同一個功能因為不同需求用不同代碼寫，重復工作且不提，還會引起各種BUG，客戶端體積龐大，運行速度慢，版本管控難度增加，新人更迭時會造成很多技術上的混亂與模糊。
一個簡潔的功能架構，對軟件以后的發展起著至關重要的決定性作用。不論多么龐大復雜的需求文檔背后的功能都應該是一張清晰的網，而不是一團理不清的亂麻。
二、亮點功能不等同于用戶需求
經過幾年的工作，發現很多領導和運營人員總是喜歡提出“我們要有亮點功能”。有些認為只要擁有亮點功能才能吸引用戶，用戶才會長期呆在里面。這若不是臆想就是看洗腦的軟文看多了。所謂的亮點功能這本身就是一個偽命題，功能永遠只是功能，是用來用的，那個亮點是功能的展現方法。也就是說亮不亮看打扮，但用不用還是回歸到功能上。一只猴子打扮再時尚也是猴子，不是人。與基礎功能關聯度過低的功能再亮也是沒用的功能。
在談亮點功能的時候一定要從用戶需求，也就是用戶需要的角度考慮，而不是以為同類產品沒做，就憑空造出一個，或隨手拿來一個，按在上面就算是亮點了。從用戶需求出發的功能必然會集中到基礎功能之中，在結構腦圖中是基礎功能項目中延伸出來的分支，不可能獨立為一體。
“想當然”是在說亮點功能時候經常犯的毛病，當然這里面不乏很多人是為了向老板交差，硬擠出來一些生搬硬套的亮點。當領導的沒怎么用過相關產品也容易被忽悠，這個矛盾現階段看來是無法調和的，只能拼雙方的配合和職業素養的底線了。
三、功能需求與交互需求是不同的
這個問題反復說，但又經常被遺忘，功能是功能，功能的展現是交互。腦袋里想的、眼睛看到的跟手上用的不是同一個事情。想的是功能、眼睛看的是效果圖、手上用的是交互，后兩者統稱UI。
提出人闡述新需求的時候如果說“我要可以這樣這樣，那樣那樣?！蓖翘岢鲂鹿δ?，如果說“這個地方我要這樣這樣用，那樣那樣翻?！敝傅氖墙换?。一般情況下都是先確定了功能細節再考慮交互方案。功能上的邏輯會直接影響到交互上的展現方法，但交互也是有一定靈活性的，有些功能不能滿足的細節可以用交互填補完善
在產品規劃的文檔中，盡可能不要過早提及交互，所有交互方案都歸交互文檔說明，或者在定稿版本的產品需求說明文檔中詳細闡述。這是因為互聯網發展很快，交互的發展也是日新月異的，在功能不變的情況下，交互表現各式各樣，到底怎樣最好、最新、最順暢，都是跟隨這環境變化和技術方案變化而不斷優化的。
一旦有人在討論功能的時候提及交互，請先記下，且暫不做考慮。規劃期間單純再單純地討論功能才是順暢前進的路徑。
四、雞肋功能不等同于偽需求。
在基礎功能的延伸分析中，總會碰到一些功能很雞肋，棄之可惜但又理應存在，這里的常用方法并不是刪除，而是降級隱藏，把關鍵位置留給更價值的功能。有些頁面寧愿有大部分的留白，或者將主體內容范圍區間變大，也不要堆積各類功能造成視覺噪音。
頁面內功能多一個，用戶的操作就更分散，重要功能關注度隨之被削弱。也是因為這個道理，現階段很多國際上的產品頁面越來越簡潔，功能按鈕越來越少，入口模塊相對多起來。能替用戶做掉的就先做掉，能不讓用戶選擇就不要選。這樣才能讓操作和時間都集中在關鍵事件上。
雞肋功能是必要的，因為它們是協助完成功能閉環不可或缺的組成部分，只是用戶不經?；虿槐仨殨玫剑绻麤]有這些雞肋功能會造成一些不可調和的BUG，往往發生在各類設置相關的功能上。
相對的是可以刪掉的偽需求，可以被現有功能代替，刪掉后不影響主體功能，不影響用戶使用，不與其他任何功能緊密相關、僅在交互操作上的多重方式的需求基本上都可以算是偽需求。最典型的就是搖一搖搜索，搖一搖換一批，搖一搖刷新更換皮膚等眾多完全跟搖一搖這個交互無必然聯系的需求。
在產品規劃的過程中，分析是不可被代替的，更不能省略的步驟。分析的過程中盡可能完整的保存文檔是很必要的，雖然這些文檔可能以后不會用到正式場合，但在后續的優化需求和版本升級過程中，都將是極具參考價值的原始資料，它能明確的在產品建立之初，這個產品是什么，從哪里來，要做什么，和將發展到哪里去。
本文由 @開言扯空-為產品經理（公眾號：kaiyanchekong-PM） 原創發布于人人都是產品經理?，未經許可，禁止轉載。
- 目前還沒評論，等你發揮！
