這幾年都在 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）
所以我會建議，等產品到達一定的穩定度之後（例如主要的功能或畫面都已經固定），再來補上測試。到時可以特地安排一段時間專心來寫測試，或是在需要重構程式的時候邊重構邊補上測試。
如果你覺得這篇文章還算有道理，那...下集在這裡