這幾年都在 start-up 打滾，跟著做了一些產品，也有一些小小心得，就紀錄下來跟各位分享討論。
不要一開始就寫程式
你（或你們公司）想到了一個好點子，這時你要做的第一件事是什麼？馬上捲起袖子把點子實作出來嗎？千萬不是！你們要做的第一件事是確認真的有客戶需要這個點子，而不是草率投入大量時間、人力、金錢成本，最後做出來的東西卻可能沒人要。
或許你會想說東西都還沒做出個雛形來，怎麼知道有沒有客戶呢？方法有很多種，例如你們可以把點子解釋給陌生人聽，看看對方的反應如何。或是先快速開發一個 landing page 來介紹你們的點子，並收集使用者的回饋。
確定真的有人需要這個點子，並且確定這個點子真的需要寫程式之後，再開始動手寫。
寫好 User Story
你可以不寫 Spec，但千萬不能沒寫 User Story。User Story 的寫法很簡單，長得大概就像這樣：「為了解決什麼問題，身為一個使用者，我希望在某種情況下，能夠做某件事」。
寫 User Story 有幾個好處：
- 可以讓所有人都看得懂因為 User Story 就是用大家都明白的語言，把想要做的事寫出來，所以無論是不是技術背景的人，都可以看懂「為何需要這個功能、這個功能是為了解決什麼問題」。
- 可以幫助整理思路因為你得把你在什麼情境底下想要完成什麼功能寫出來，在寫的過程當中就可以整理自己的思路，檢查這樣的需求是否合理。然後因為大家都能看懂，所以無論是否有技術背景的人，都可以一起來討論，這樣就可以幫忙找出盲點，並且完善整個需求。
- 可以讓開發者用最適合的解法解決問題為什麼我會覺得不需要寫 Spec 呢，因為寫 Spec 的人不一定是要開發的人，所以很容易就寫出很莫名其妙的 Spec。更糟糕的是，有可能一開始就寫 Spec，少了互相討論完善的階段，結果最後整個歪掉。所以我會說不要寫 Spec，寫 User Story 就好，然後把 User Story 寫完整。有經驗的開發者看到 User Story 自然就會找出最適合的方式去解決問題。千萬不要外行領導內行，亂下指導棋。
- 方便驗收既然 User Story 都寫得那麼完善了，要驗收的時候只要一一對照 User Story 就可以知道是否完成所有需求。對驗收人員來說，看 User Story 就會知道這個功能到底是什麼，也就代表很容易就能理解要驗收什麼。
一定要使用版本控制系統
版本控制系統的好處我就不多說了，無論是單打獨鬥或是團隊合作都應該要用版本控制系統。我個人最推薦的當然是 Git，雖然它的入門門檻頗高，但熟悉它之後所帶來的好處真是讓人無法抗拒的。
近年來 Git 有越來越多好用的 GUI，已經大大降低初學者上手的難度，SourceTree、Tower、GitUp 都是不錯的選擇。至於要如何將版本控制系統整合到你的開發流程，可以先參考 Git Flow 跟 GitHub Flow，再逐步調整成適合你們團隊的作法。
有了版本控制，當然就得記得要下版本號，如果不知道該怎麼決定版本號，可以參考語意化版本號的作法。
不必一開始就寫測試
可能有些人覺得這是邪魔歪道，不過我真心這麼覺得：「你應該寫測試，但你不應該一開始就寫測試」。
身處在 start-up，無論前期的思慮有多麼周到，產品的需求還是很容易就會變更。如果採用「測試先行」的話，最後你會發現絕大多數開發的時間都拿去寫測試了，而且因為需求在前期很容易變更，所以你的測試也很容易一改再改因而難以重複使用。（P.S. 降低需求變更機率的一個方法就是好好寫 User story）
所以我會建議，等產品到達一定的穩定度之後（例如主要的功能或畫面都已經固定），再來補上測試。到時可以特地安排一段時間專心來寫測試，或是在需要重構程式的時候邊重構邊補上測試。
善用追蹤工具
做任何決定之前都要有所本，不要突然「通靈」了就做出莫名其妙的決策。那要根據什麼做決定呢？很簡單，讓數據說話。善用至少一款追蹤工具（GA、Mixpanel、Flurry、Kissmetrics、Keen IO、Customer.io、Segment 等等）並在上線第一天就開始追蹤使用者的行為，這樣才能知道有多少使用者在用你的產品，以及如何用你的產品。總之，就是要透過數據收集與分析，來了解你的使用者。
日後當你要做 growth hacking 的時候，追蹤工具更是不可少，你會需要這些追蹤工具來幫你統計，看哪些修改會有助於你的業務成長，哪些修改反而會讓業務衰退，以及成長或衰退了多少。
如果有開發 APP 的話，你也會需要想辦法取得 crash log，這樣才知道程式掛在哪，我推薦使用 Crashlytics 幫你收集分析這些 crash log，它非常的好用。
愛用第三方元件
近年來 open source 越來越受到歡迎，網路上有各式各樣的第三方元件讓你取用，所以真的沒必要每一樣功能都自幹，如果有現成的可以符合你的需求，就大膽的用吧。再加上第三方元件的管理程式（像是蘋果開發者常用的 CocoaPods 跟 Carthage）也越做越好，早期會遇到的第三方元件版本控管問題已經很少見了，所以我建議各位可以盡量用第三方元件，或是將第三方元件修改成符合自己需求，沒事不要自己造輪子。
方便的更新機制
隨著時間過去，你的產品需求一定會有所變化，該怎麼向後相容以及如何要求使用者升級就變成一件不得不面對的問題，這裡我有幾點建議讓你參考。
- 設計 API 的時候要考慮版本化同一支 API 背後的商業邏輯很有可能會變化，如果一開始設計的時候沒有考慮版本化，你就會為了 API 名稱而大傷腦筋：可能原本的叫做
checkout，後來叫做 checkout_new，再後來叫做 the_new_checkout。但如果一開始有考慮版本化的話，你就可以一開始叫做 checkout/v1，後來叫做 checkout/v2。或是直接改 API end point，例如一開始的 end point 是 api.myserver.com/v1/，後來的是 api.myserver.com/v2。
- 呼叫 API 的時候附上環境參數雖然現在送 request 的時候，大部分都會在 header 附上 client 的一些資訊，但每個 client 送出的 request header 格式有可能並不統一，所以要 server 去 parse header 來取得所需資訊，其實成本蠻高的。比較方便的方法是，client 每次在呼叫 API 的時候就主動附帶一些參數讓 server 好判斷。例如可以送
platform 參數指明是 ios / android / web，device 指明是 phone / tablet / desktop，version 表示程式的版本等等。Server 就可以根據這些參數有不同的邏輯與回應資料，例如根據 device 回傳不同尺寸的圖片網址，或是根據 version 來得知對方是否使用最新版本。
- In-App Announcement如果一開始就有設計 in-app announcement 機制的話，就可以更輕易讓使用者得知最新消息。例如有新版本可以下載了，讓使用者知道有什麼新功能並引導使用者去下載。或是有在舉辦什麼活動的時候，也可以透過這個機制讓使用者知道（例如 Uber 時常會舉辦不同活動，車子圖示也會跟著變）。或是有什麼新貼圖、新佈景主題、新內容，也可以讓使用者知道（例如 Line 或各款遊戲）。
- 儲存資料的時候要考慮版本化有很多時候我們必須儲存一些資料在本機，可能是透過寫入設定檔或是寫入資料庫，如果儲存資料的時候有考慮到版本化，之後要處理資料相容或是要將舊資料轉換成新資料的時候，都會相對簡單許多。
寫文件
所有人都知道寫文件的重要，但是大概沒人會喜歡寫文件，但其實文件沒那麼難寫。文件存在的理由是什麼？不就是為了日後的查詢參考嗎。
所以 User Story 就是文件的一部分，你一邊設計產品的同時，就一邊在寫文件了。這樣有沒有覺得寫 User Story 很划算，會不會更有動力寫好它！
程式碼註解也是文件的一種，現在有很多工具能夠將註解轉換成說明檔，日後只要註解有所變動，說明檔就會自動更新，這可以幫忙省下超多時間。像我們的後端都會在程式碼裡頭註解說明這支 API 的用途是什麼、傳入的參數是代表什麼意思、是什麼型態、是否可以不傳、回傳值是什麼、有可能產生哪些 error，對應的 error code 是什麼等等。我個人覺得，維護程式碼的註解比額外維護一份說明文件（可能是 wiki 或是 doc 等等）簡單多了。
文件也不是寫完丟在一旁就算了，它是讓人日後可以查詢參考的，所以最好可以把所有文件統一放在一個地方，然後有個方便的作法讓人查詢（可能是規劃良好的目錄結構，或是提供搜尋功能等等）。
簡單來說，文件有三大重點：要完整、要保持最新版本、要讓人找得到。
畫 Wireframe
通常設計師會畫好 wireframe 讓工程師知道整個使用流程，明白該從哪個畫面跳到哪個畫面。如果很不幸的，你們公司沒有這種東西（可能是不見了或根本就沒有），那 APP 開發工程師就認份一點自己畫一個吧。對工程師來說，畫這個並不難，只要把 APP 每個畫面都擷取下來，然後用箭頭把彼此之間的前後關係串起來就可以了。
擁有一份完整的 wireframe 的好處在於，當你們想要增刪或修改某些功能的時候，可以把 wireframe 拿出來，看看增刪或修改這個功能之後，整個使用流程是否順暢合理。千萬不要功能都做完，才發現流程變得卡卡的，這樣浪費的成本太高了。
老實說，就算每一點都做到了，也不保證你的產品會成功，但絕對會讓你開發一款新產品時比較不會走歪，就算歪了也可以早一點救回來，降低你犯錯的成本。
實用軟體介紹 (12)