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