## 產品設計體會(三)——性價比:做不做?
有了前面的周報中收集到的用戶需求和數據分析的結果后,我們就要做決定了。其實并沒有一個功能是沒有價值的,也并沒有一個功能是做不了的,某個功能到底做不做?至少要從兩個方面來考慮。
?
第一,商業價值。在我們公司的團隊構架里,“運營——產品——技術”是三條明顯的線,和用戶、商業層面直接發生關系的是運營,我把這看作是前端的內容。那么這里的商業價值也就是對用戶意義的大小、以及對公司目標意義的大小。這里需要PD和運營積極配合,充分分析功能給用戶/公司帶來的利益,但不是說利益大的就做,先把這個分析結果存著備用。
?
第二,實現難度。換句話說是開發量,需求+開發+測試+硬件等等一共需要的資源。這是技術層面我把它看作是后端,絕對不能因為一個功能很容易實現就馬上去做,也不能因為另一個功能很麻煩就不做。
?
現在可以做決定了,我們做性價比(商業價值/實現難度)高的。無論任何事情都是一個性價比的問題,前段時間工作中,由于一直和工程師直接接觸,所以綜合考慮時有點傾向于做實現難度小的,這是今后需要改進的。
?
再說開一點,談一下對商業價值的一個判斷因素,功能的商業屬性:雪中送炭 or 錦 上添花。雪中送炭是基本功能,對用戶很有用的,產品缺了這個功能根本不可能運行,比如網店版的“我要付費”模塊;“錦上添花”的功能是指用戶用得到的,但 沒有時用戶也不會跳起來的,也許現在的“客戶關懷記錄”可以算這類。我們在論壇上會很明顯的感受到這兩種需求的不同,有一點像“bug”和“需求”的區別。我是一個不那么激進的人,覺得要把“雪中送炭”的商業價值調高,穩定和諧壓倒一切。情愿把一半的功能做到盡可能完美也不要把全部功能都做到半吊子(有點扯遠了)。
?
另外可能還有些無法控制的因素影響這“做不做”的決定,比如國家、公司的政策指向,這里說了也白說就不說了。
- 前言
- (一)——變態吧,開始帖周報了
- (二)——數據分析
- (三)——性價比:做不做?
- (四)——需求管理
- (五)——有關流程
- (六)——再談流程
- (七)——需求探針
- (八)——產品與項目
- (九)——關于學習
- (十)——團隊合作
- (十一)——市場掃描
- (十二)——少而精
- (十三)——再說需求分析
- (十四)——做過的幾個項目
- (十五)——PM、PD、UE與UI
- (十六)——Feature List
- (十七)——PD的幾種文檔
- (十八)——概念設計
- (十九)——UPA年會的流水賬
- (二十)——有關改版
- (二二)——封閉開發
- (二三)——用戶研究
- (二五)——當交互設計遇到敏捷開發
- (二六)——PD就是出來賣的
- (二七)——大產品設計
- (二八)——細節之文案
- (二九)——產品設計的五個層次
- (三十)——“體會”導讀的思維導圖
- (三二)——零散的體會
- (三三)——用戶大會
- (三四)——土老板破冰必殺技
- (三五)——QA與測試
- (三六)——再理解“敏捷”
- (三七)——可用性測試
- (三八)——項目外包!=開發外包
- (三九)——CSDN專訪精編版
- (四十)——銷售渠道
- (四一)——用戶創意無限
- (四二)——又是零散體會
- (四三)——說說評審會
- (四四)——項目外包不適合“敏捷”?
- (四五)——外行眼中的技術分工
- (四六)——UML學習摘錄(上)
- (四七)——UML學習摘錄(下)
- (四八)——資源戰爭與BRD
- (四九)——產品市場化
- (五十)——終點:Matrix
- (五一)——敏捷的估計與規劃
- (五二)——MS Office使用心得
- (五三)——產品文檔與規范
- (五四)——PD招聘廣告詞
- (五五)——項目Kick Off
- (五六)——《需求工程》培訓記錄
- (五八)——《項目化管理》培訓記錄