小步快跑才是王道
———別總想搞個大新聞
功能人天價值a
105b10
5c52
d53假如有abc三個功能需求，等待我們開發，相關數值如圖所示，你會怎麼畫原型，安排開發？
傳統軟體開發：先做a和
b,到第20天
,可以發布乙個價值為
5+5=10
的產品。
敏捷開發：先做a,再做
b。這樣,到第
10天,就可以發布乙個價值為
5的產品，再做
b，到第
20天依然可以發布乙個使用者價值為
5+5=10
的產品。
到了這時在，有人能明白這兩種開發方式的優劣了嗎？
採用傳統軟體開發方法，我們再做c功能,用時
5天，花了
15天，得到乙個價值為
5+5+2=12
的產品，能理解吧？
採用敏捷開發的時候，我們通過第1個
10天，發布了乙個版本，開始收集資料，再用第2個
10天，繼續收集資料，用比採用傳統軟體開發模式多出的
10天，通過資料分析，發現乙個用時大約
5天，但價值為3的
d功能， 這個
d功能是新的，以前不知道的。這樣，我們還是花了
25天，得到乙個價值為
5+5+3=13
的產品。
在兩樣的25天時間裡，我們獲得了比原計畫價值更高的產品，收集了更多次數的資料，獲得了更多試錯機會。一年有
12個月,如果
1月迭代一次,則有
13次改正的機會
,如果半月迭代一次,就有
26次試錯後改正的機會，所以為了發揮敏捷開發的優勢，所以我們要有懂得放棄一些功能，不管有沒有票，先上車再說。當然，這裡的放棄不是要把更多功能丟掉
,而是不要集中完成
,分批次地迭代實現。
這裡借用乙個真實的案例:qq,當時還叫
oicq
，因為各種考慮和限制，無法全部實現，如果是你，你會怎麼去規劃安排。怎麼選？
,我們不去回答什麼是標準答案，但我們可以通過分析下面的
12個功能的意義，來理解乙個產品到底應該如何去進行功能的選擇和迭代，從而知道：哪些功能我們應該先做
,哪些功能該緩一緩。
序號名稱
序號名稱
1**頭像
7聊天記錄管理器
2不可竊聽的安全通訊8語音
3聊天室94
很小的exe
檔案10
5**skin
11傳檔案
6速度超快0.5
秒反應12
qq表情
第1個功能「**頭像」,是
qq比較早做的
那個年代,使用者在大多數網路應用裡只有乙個
id,分不清男女老少。要知道
,那會兒還很少有數位相機和攝像頭
,更別提可以拍照的手機
,所以真人頭像很難實現。
qq的**頭像
,讓使用者活了起來。當時
,頭像用了一批迪斯尼的**動物和漫畫人物，喚起了早期使用者對小時候看過的動畫片的記憶乙
,產生了情感連線。而使用者自己選擇的頭像
,也幫助使用者在溝通時能大概知道對方的性格、性別、年齡
,是個萌妹子
,還是女漢子
,是個小鮮肉還是個成熟大叔
第2個功能「不可竊聽的安全通訊」
,安全通訊主要用於商務場合的
,對資訊保安要求比較高;而
qq,其實是乙個偏娛樂、生活化的產品，早期對安全的要求並沒有想象得那麼高。
第3個功能「聊天室也是最核心的基礎功能，也確實是
qq最早就有的。社交次品都要解決使用者在網上如何找到第一批聊天物件的問題
,第一版
qq的使用者大多是孤獨的極客
,缺少足夠的熟人使用者
,所以要解決「能找到陌生人聊天」這個迫切需求。而聊天室正好可以提供乙個有共鳴的主題
,讓彼此陌生的人在一起天南海北地聊。很多人的打字速度都是當年在聊天室裡練出來的。
早期的網路使用者,更熟悉的是
web聊天室這種陌生人交友模式
,很難在遷移到客戶端的聊天工具qq時
,一下子習慣熟人社交。所以先從聊天室開始
,這樣更尊重使用者習慣
,讓他們適應起來更加順暢。陌生人聊熟了
,再互加一下好友
,也解決了使用者
qq上沒有好友的問題。一旦有了好友
,使用者就會被黏住
,有了持續使用
qq的動力
,也是很早實現的特性。因為原因與上乙個類似
,所以提前說一下
qq是即時通訊工具
,強調實時性。要立即找人聊天,,
,,還經常被早期使用者用來定向新增好友
,比如設定好友查詢條件為「北京市海淀區」
+「女」+「
18到22歲」。
(是不是和後來的陌陌很像
?)第4個功能「很小很小的
exe檔案」
,是乙個並不需要投入太多資源去做的特性。
當年的電腦、網路效能確實很差,要求安裝檔案盡可能小一點。但
qq的第乙個版本
,沒有經過任何版本迭代
,安裝檔案只有幾百
k,優化的必要性和空間都很小。真正需要優化安裝包大小
,要等到若干版本之後
,exe
檔案膨脹到幾十m時
,才值得專門投入資源去做的。
第5個功能「**
skin",
明顯是乙個錦上添花的功能。
我一直有個觀點,當乙個產品開始考慮「換膚」
,就說明這個產品進入了成熟期
,可以把資源抽調出來去做更重要的事情了。
段子裡是這樣說的:
公司有個技術牛人,某產品助理向他提需求
,牛人一看內容很扯
,質問「你覺得這個需求有價值嗎?」
對方誠懇回答:「沒價值
,但是我總得寫週報啊。」
牛人想了一分鐘,回答說「好吧
,我幫你做
,因為我也得寫週報啊。」
而「換膚」就是這樣的需求,
乙個能滿足產品技術團隊「寫週報」的需求
,能滿足老闆「識別投入過剩」的需求。
第6個功能「速度超快
0.5秒反應」
,是針對網路的優化
,需要盡早做。
當年很多人家裡還在使用33.6k、
56k的貓°
,訪問網路速度慢、不穩定。當時的網路的確有明顯的延時
,哪怕是用
qq傳輸文字。所以
,將網路優化的優先順序設為很高是合理的。
第7個功能「聊天記錄管理器」
,早期並沒有做。
仔細區分一下,聊天記錄其實有兩種
,儲存在客戶端的本地聊天記錄和儲存在伺服器端的漫遊聊天記錄。限於當時的網路頻寬,,
只能考慮客戶端聊天記錄的備份和管理。但
,那個時候很多使用者都沒有個人電腦
,去網咖上網是常態。因為經常需要換電腦
,儲存本地聊天記錄並無實質意義。更為甚者
,當時很多使用者聊一次
qq就重新註冊乙個qq號
,完全不理解「個人賬號」的含義
,以為和登入某些
web聊天室
,進房間之前取個暱稱是一樣的
,也就更不會有對備份「聊天記錄」這種個人資訊的強需求。
第8個「語音」、第911
個「傳檔案功能」
,都很類似
,沒有在早期做。以當時的網路速度
,這些功能就算實現了也不會有很好的使用者體驗
,要等到寬頻普及才有必要考慮。
第12個功能「
qq表情」
,因為滿足這個需求有可替代的現行途徑
-顏文字
,,所以也可以先擱置。
顏文字,可以用標點符號及英文表示一些十分簡單的面部圖案。
每次的需求管理，功能管理，都.要足夠輕，輕到能套用敏捷開發，太「重」的產品，會拉長開發周期，會影響團隊的敏捷靈活，一但迭代後使用者不喜歡，損失就會更大，所以敏捷開發成為了目前化聯網行業非常流行的開發方式，而能讓產品少做點堆疊的功能，多做點簡單但實用的功能才會考驗乙個產品經理高超藝術的標準。
部分素材引用自蘇傑的《人人都是產品經理》
小步快跑 快速迭代 整理
1 快速迭代首先是一種產品研發理念。在快速迭 念支援下的產品研發是 上線 反饋 修改 上線 這樣反覆更新內容的過程，形式非常適合網際網路產品或者移動端，通過收集資料或使用者反饋迅速知道改進的結果，用快速迭代的方式可以立即在使用者之間找到平衡點。與快速迭代關係最密切的是敏捷管理。具體是故事牆 每日晨會...
小步快跑是這樣玩的（下）
同時，我們發現，過去只需gethour 就足夠，而現在卻需要getmonth 與getday 隨著程式複雜度的提公升，我們適時進行了一次重構，將與時間相關的程式抽取到乙個新類dateutil中，就可以順利地改寫原有的時間問候語程式 the utility of time author fangang...
談談我對「小步快跑」的理解
看到書中第三章的標題，已經隱隱知道作者要講述的情節。看完全章節後，果然不出所料，同時產生強烈地共鳴。下面從三個方面來闡述自己對於軟體開發小步快跑的理解。一 開發方式中的小步快跑 在軟體開發中，選用傳統瀑布模型的開發方式越來越突顯它的弊端。現在更易為專案組所認同的是敏捷迭代模型的開發方式。迭代的特點就...