警語:本人沒有合作開發經驗,只有自學、開發一些小專案,因此關於大型專案、合作開發、團隊協作的想法皆從書上以及自己推論而出,必定會有缺漏或理解錯誤的地方,請閱讀時務必小心。
先想怎麼寫這本書的心得:

一開始先用心智圖發想怎麼寫心得
因為作者是以故事的方式編寫某情境遇到的開發問題、思考,其中有內心的OS、最終的決定以及決定背後的想法。
所以決定大致先以 問題->行為->背後原因 的方式做紀錄,之後統整情境條件對應到把行為抽象後的SOP概念。
Chapter 1 特過雛型構想專案
大方向
情境──客戶想做音樂推薦系統
一、問客戶做音樂推薦系統的原因?
A:有個經營blog裡面有4000部不同屬性的影片,享用推薦系統讓閱聽者更容易探索更多內容。
二、要做獨立碼庫執行,還是整合到系統中?
A:由於現階段不確定想法是否可行,先做探索式編程,確定要執行的產品,再來思考這個問題。
三、影片直接引用自blog的,一來使用者熟悉介面且可以跟blog做連結。
四、有幾百位閱聽眾、blog經營相關者可以作回饋。
第一次迭代,最單純可行版本(註一)
一、根據大方向畫出wireframe
二、突然想到更好但比較複雜的介面?
A:為了效率,把介面最簡單化,減少開發時間,快速做出第一版產品發佈出去,得到回饋。
三、快速架設網頁,產生了奇怪的網址。
A:捨棄美觀和維護性,最快速度「取得客戶設定之目標閱聽眾的有用回饋」
四、外觀?
A:YAGNI,現階段目標是回饋,效率->產品->回饋。
五、簡單快速排版,套CSS、placeholder、grid layout。
六、在位歌名排序,用了稍長的時間,但那是浪費時間,這個階段是要驗證想法,細節不重要。
七、Code不加修飾的部屬。
A:捨棄維護性,方向還沒確定,之後不一定會用原code。
八、擔心太陽春,客戶能不能理解?
A:效率->產品->回饋,提醒回饋決定可行性(市場)。
九、Q:客戶回覆手機跑版。
A:先設計手機的wireframe作為回應,如果回饋有反應行動版問題,再優先製作行動版UI。
十、Q:想叫現在處理,之後處理會不會多餘的工作?
A:(自己猜想)介面簡單、功能不多的情況下,行動版元素刪減、更改不多,之後處理差別不大。
十一、 探索階段,要平衡 問題後果 和 處理成本 ,但要讓客戶了解如何處理之後可能遇到的問題,讓客戶安心,可以減少之後很多精力。
註一:「最單純可行版本」專注在快速實現最小產品,先做可行性測試,也可估量之後的開發狀況,之後可以研究看看一詞出處、定義。
推薦機制
在這之前都是為了找專案的切入點,現在要做正事。
一、問客戶推薦的規則。
A:希望不受他們的列表限制,並且能找到性質相同的歌曲。
二、列舉草圖觀察到,實作細節會遇到的問題。
三、先從2個簡單的開始,產生影片內嵌碼(官方支援)、產生縮圖。
四、Q:產生縮圖沒有找到官方的管道,但有找到民間的做法。
A:先用民間做法,同時詢問官方是否允許會有其他合法的管道。
五、Q:討論其他3個問題,影片要有什麼資料、如何儲存這些資料、如何用這些資料產生有用的推薦機制?隨著時間,討論越來越偏離重點。
A:最小可行版本!先從比對演出者入手,根據現在的影片,推薦相同歌手的影片。
僅推薦歌手還不夠,但目前需要的是能在螢幕上攻討論的東西。
六、Q:資料的儲存?
A:先用簡單的陣列寫一些資料集。
七、實作出了基本的 運行骨架(walking skeleton)
八、收到了關於產生縮圖的官方回答──民間做法沒有違法,但沒有支援,所以可能未來會失效,叫好的作法是在官方的開發者社群下註冊,並使用相關的API。
A:決定先暫時用民間做法,但把這個回應記錄下來,讓之後正式產品開發人員知道。
設計容易收集回饋的功能
一、感興趣側欄,一個單欄列表,顯示各個標籤,點選後會提高標籤的推薦度。
二、對於專案何時該快該鬆,何時要扎實的練習,目前交由同事判斷。
辨識碼 |
歌手 |
歌名 |
標籤 |
歌曲年代
三、資料結構
四、推出適用雛形,去獲取回饋。
建議與提醒
一、提出可以揭示專案餐與人員目標的問題。可以驗證假設,也可以更了解相關人員問題的看法。
二、用wireframe溝通,就不會陷入太多風格設計的細節。
三、開始coding要建立所有人都能互動的即時系統,只要能收集到有用的回饋就好。
四、專案初期,專注在風險高或未知的部分,驗證假設。
五、雛型可以用來找到可能的問題,但它不是最終的系統。
抽象SOP
情境:有個模糊的需求、或不確定會不會被市場接受的新功能。
採用探索式編程
先釐清方向(原因),確定能確定的事,挑出不可取代的核心功能,做為測試目標得到回饋。
製作最單純可行版本
設計->產品->回饋,一切以最快速的方式進行,並時時提醒自己。
之後最對最單純可行版本最更詳細的探討。