## 產品設計體會(十六)——Feature List
這周來點實在的,這兩天主要在列新產品的Feature List,說一下自己感覺這個玩意應該怎么做,其中吸取了葉老大原來的表格還有網上一些相關文章的內容。這個表是用Excel做的,一些簡單的技巧,比如條件格式、篩選、單元格有效性、單元格鎖定、隱藏是必須的基本功,另外我比較喜歡把表格弄好看點,這樣整天對著就不會悶死嘞,見附圖。
[](http://blufiles.storage.live.com/y1p3O4KBNpz6AX2aqryPfBwg-1_Hj8HzxuFvvBWxBDas70DWgUqfryLpTNNomM0CHALr_Nl5ouzjc0)?
(看不清吧,那就對了,暫時不能讓你們看清~~~ :P)
一個feature,這次我給了它如下屬性:
模塊:一般來說,每個模塊下分3~10個子模塊是合理的,否則要考慮重新劃分(由于這個癖好,自己電腦里的文件目錄結構也是遵循這個原則的)。
子模塊:稍大一點的產品至少要給功能模塊做二級分類了,這部分其實又涉及另外一個很大的領域IA(信息構架,會影響將來產品的站點樹形結構,頁面組織,菜單層級等),最近也在看一些資料。
Feature:具體的說一點,要給用戶提供什么功能,給這個功能起個名字。
任務描述:這里可以說具體一點。
商業價值描述:通俗點,賣點是什么,可以給用戶提供什么價值。
商業屬性:簡單分為基本,擴展,增值。舉個手機的例子,打電話短信是基本功能,給電話錄音是擴展功能(和基本功能相關),而如果這個電話特別結實,可以當錘子釘釘子,那就是增值功能了。這里的區分其實沒那么決定,取決于很多因素,比如商業目的。
商業優先級:這塊是整個Feature List工作中核心的部分,判斷的準確直接影響著將來產品的方向,我們的做法是先基于自己對商業目標的理解,主觀定一個級別,所以之前的功課很重要,然后再PD團隊pk,如有必要,再去客戶處確認。
開發量:一般由技術部門的項目經理或者系統分析師/架構師來確定,這次需要勞方代表,微軟,來定了(我是資方代表哈)。
性價比:原來的體會(三、十二)中有討論過這個問題,簡單一點就是綜合商業屬性、優先級與開發量來確定。
備注:這個不說了吧。
另外,每個產品的大小、資源條件,需增需減,要靈活變通。
- 前言
- (一)——變態吧,開始帖周報了
- (二)——數據分析
- (三)——性價比:做不做?
- (四)——需求管理
- (五)——有關流程
- (六)——再談流程
- (七)——需求探針
- (八)——產品與項目
- (九)——關于學習
- (十)——團隊合作
- (十一)——市場掃描
- (十二)——少而精
- (十三)——再說需求分析
- (十四)——做過的幾個項目
- (十五)——PM、PD、UE與UI
- (十六)——Feature List
- (十七)——PD的幾種文檔
- (十八)——概念設計
- (十九)——UPA年會的流水賬
- (二十)——有關改版
- (二二)——封閉開發
- (二三)——用戶研究
- (二五)——當交互設計遇到敏捷開發
- (二六)——PD就是出來賣的
- (二七)——大產品設計
- (二八)——細節之文案
- (二九)——產品設計的五個層次
- (三十)——“體會”導讀的思維導圖
- (三二)——零散的體會
- (三三)——用戶大會
- (三四)——土老板破冰必殺技
- (三五)——QA與測試
- (三六)——再理解“敏捷”
- (三七)——可用性測試
- (三八)——項目外包!=開發外包
- (三九)——CSDN專訪精編版
- (四十)——銷售渠道
- (四一)——用戶創意無限
- (四二)——又是零散體會
- (四三)——說說評審會
- (四四)——項目外包不適合“敏捷”?
- (四五)——外行眼中的技術分工
- (四六)——UML學習摘錄(上)
- (四七)——UML學習摘錄(下)
- (四八)——資源戰爭與BRD
- (四九)——產品市場化
- (五十)——終點:Matrix
- (五一)——敏捷的估計與規劃
- (五二)——MS Office使用心得
- (五三)——產品文檔與規范
- (五四)——PD招聘廣告詞
- (五五)——項目Kick Off
- (五六)——《需求工程》培訓記錄
- (五八)——《項目化管理》培訓記錄