產品設計體會（五一） 敏捷的估計與規劃

前段讀了《敏捷估計與規劃》，這本書很適合開發經理看，我只是很快的瀏覽了一下，摘錄一些體會。 ø

敏捷的里程碑是功能驅動的，先完成可交付的最「重要」功能，重要取決於功能商業價值、生命週期、實現難度等綜合的結果。而傳統的瀑布模型的里程碑是任務階段驅動的，到了專案

50%的時間，可能進入「編碼」，但對客戶來說，等於

0%。而且這樣的模式會陷入「實現難度決定開發順序」的不合理模式，因為這裡有個不合理的假設前提：所有功能都能夠完成、必須完成，中間過程對客戶是透明的。 ø

專案估計的不確定性是會累積的，

80%×

80%×……，所以開始訂的專案計畫，在乙個月後已經面目全非，強行的遵守是沒有意義的，而應該不斷的修正計畫，當然，更好的做法是一開始的計畫中間留有一些柔性的內容。 ø

隨著時間變化，必然有新的資訊出現，特別是瞬息萬變的網際網路業界，死守著開始的專案計畫不調整是沒有邏輯的做法，敏捷的迭代剛好權衡了變化的成本和不變的成本，就是：不變本次迭代，更新下次迭代，這是乙個將專案計畫細化粒度的做法。 ø

需求唯一不變的特徵就是「不斷變化」（

plus

不斷細化），敏捷的思想就是歡迎變化，擁抱變化。瀑布模型一次性完成的需求分析，會存在「過度需求」的問題，降低整體效率。

專案管理理論的發展，從開始混亂，每個專案自有一套，每個

pm自有一套；到後來人們非常想訂出乙個統一的簡單的流程，減少人為影響（瀑布模型等出現），；再後來進入靈活的敏捷，看似又變得混亂，實則有序。又是宛如那個哲學的三段論：見山是山

à見山不是山

à見山還是山；也如管理的三個境界：人治à法治

à無為而治。

產品設計體會（五一） 敏捷的估計與規劃

前段讀了 敏捷估計與規劃 這本書很適合開發經理看，我只是很快的瀏覽了一下，摘錄一些體會。敏捷的里程碑是功能驅動的，先完成可交付的最 重要 功能，重要取決於功能商業價值 生命週期 實現難度等綜合的結果。而傳統的瀑布模型的里程碑是任務階段驅動的，到了專案 50 的時間，可能進入 編碼 但對客戶來說，等於...

產品設計體會（二九） 產品設計的五個層次

其實這篇是 使用者體驗的要素 的讀後感，其實讀了已經快2個月了，剛讀完寫讀後感會比較全面，而事隔一段時間再寫就能看出哪些是真正沉澱下來的要點了，也算是給自己找個偷懶的理由吧。大產品設計決定使用者體驗，而小產品設計又分為五層，帖一張業內著名了好幾年的圖。戰略層 明確商業目標和使用者目標，重點是解決兩者...

產品設計體會（6018）用自己的產品

產品要用才能感覺出好壞，特別是自己做的產品，不用的時候總覺得那麼完美，呵呵。2007做了 版，賣360塊一年，給自己免費開通，用它管理自己的 小店，賣了乙個多月的巧克力 2008做了企業郵局，賣1000塊一年，給自己免費開通，不過email位址沒放出去，也就沒啥實際用處 2008年做了e網打進 賣2...