創過業的人都知道，創業初期是人均產出最高的時候，有時前一天大家吃飯時討論出一個想法，在第二天晚上就看到這個功能，第三天也行就上線了。那時并沒有分工一說，所有人都兼職測試、客服、市場、網維甚至前臺……總之人員足夠少的情況下似乎什么都可以干，也什么都得干。在這種時期面臨的問題也較多。比如沒有美術設計師便去找有一點設計基礎的朋友；沒錢買服務器帶寬只能”借”，說是“借”是因為不知道什么時候能“還”等。總之就是各種忙，沒有休息的時間，當時最大的希望就是盡快好起來，那樣自己能專注做一些自己更擅長的事情。
業務稍微好轉一些，有那么“幾桿槍”后創始團隊本以為會松一口氣，其實會迎來新的一輪挑戰，尤其對沒有創業經驗或者沒有高層管理經驗的團隊。因為他們總以為此時終于可以更專注于思考業務和產品，但突然發現有好多事情都想做，這也令開發團隊不知所措。不僅如此，隨著業務的增長運維問題也開始顯現。在我看來此時如果團隊能開始“精益創業”和“敏捷開發”結合起來是個有效的方案，這兩方面都有比較好的書，就不贅述了。這個發展階段下公司的抗風險能力比較差，如果開發團隊掉到“坑”里，那么公司就很危險了。而此時的研發負責人會面臨第一次管理困境——人少又沒錢找很貴的人才，如何凝聚和發揮大家的優勢便成了大問題，此時就需要找“外腦”咨詢，尤其是有創業經驗的人。
邁過上面兩個階段，當公司發展到幾十人的產品研發團隊時，呱呱曾經陷入過項目管理混亂，那時候公司的市場人員、業務人員、產品人員都給研發人員提出了需求，而且看起來似乎都是對的。直到有一天公司決策層發現重大項目推進比較慢，便開始梳理研發團隊的事情，一梳理嚇了一跳，需求多到有些都忘了是誰提出的..... 然后公司立馬決定“收權”，所有需求必須經過相關產品人員審核后才能進入研發，即使是研發內部的系統優化，如果超過一定工作量也需要經過產品經理同意。同時，公司引進了一套項目管理系統，把需求管理和研發任務納入系統，對應負責人把控里程碑，由研發及產品Leader對完成的子任務進行審核，所有人員都可以直接打開電腦看到項目的情況，也不用去挨個問了。這樣我們就很快渡過了這個階段，并保證了后續業務的拆分和發展。
從上面的幾個階段也許大家能理解為什么二次創業容易成功了，其單在如何避免研發資源的浪費上就可以帶來可觀的收益。如果沒有經歷過這個研發“從小到大”過程，比如大公司的高管去管理小團隊時容易犯的一個錯誤就是“照搬”。我就曾聽說過某知名企業高管在創業的時候把原理的項目管理流程用在了一個不到10人的團隊上，結果大家覺得所有事情大家都很清楚，卻投入大量精力去走流程，以致開發人員認為這是不信任，對團隊造成了很大的負面情緒。
其實所有流程和事情都需要針對人員的規模和水平進行調整。開發團隊人員很少或者在業務不穩定期就需要考慮設計文檔的必要性，測試用例的粒度也要根據人員的水平和業務情況進行調整。但我個人不建議省掉測試用例，哪怕只有幾條或者停留在口頭層面，尤其是開發人員同時兼任測試人員的時候，因為研發工程師的出發點就是我的程序是“沒問題的”，而沒有測試工程師那種“看我能找出幾堆Bug”的使命感。有很多人有一種理想，就是“前期規劃和設計好，后期就會如期達到目標“，而實際上項目的復雜度和不確定性是超乎一般人考慮問題的細致程度的。
組織過婚禮或者裝過修的人都能感觸到其中的各種“意料不到”，其實這些事情也是“項目”，項目周期越長越不可控所以建議吸收“敏捷”的思想。另外建議產品和研發負責人學習“精益創業”的思想，其降低研發做錯誤需求的成本和降低業務的機會成本上是非常有效的。
我們需要更多經驗分享及總結，因為犯錯不可怕，但犯別人犯過的錯很可惜。
)
