今年5月底，我加入一家創(chuàng)業(yè)型公司，在我加入之前公司只有3位同事：企業(yè)負責人，HR和一位產(chǎn)品經(jīng)理。那個時候產(chǎn)品的原型還沒最終確定。
我加入之后的首要工作就是組建一支App的研發(fā)團隊，因為我們要做的產(chǎn)品就是一款App的社交平臺。本文我將從總結的角度去回顧我們是如何組建團隊并順利進入產(chǎn)品攻堅戰(zhàn)，重點闡述我在這個過程中的所做所思所想。
一、需求原型確定
企業(yè)負責人、產(chǎn)品經(jīng)理和我經(jīng)過長時間的產(chǎn)品評審，終于確定了V1.0.0版本的產(chǎn)品原型，原型一旦確定也就是需求確定，那么接下來的工作就是進入UI設計和產(chǎn)品研發(fā)。
而對于一家創(chuàng)業(yè)型公司，在研發(fā)人員還未到崗之前必須要做的事就是研發(fā)成本評估，我們當時的成本評估是以年為維度去做的，每個季度可以允許調(diào)整一次。
二、V1.0.0版研發(fā)成本評估
我們的成本主要分為系統(tǒng)成本（各種云服務器）、人力成本（研發(fā)測試人員）、開發(fā)配置成本（開發(fā)電腦和測試手機）以及數(shù)據(jù)采集成本（我們采用的是Python開發(fā)和神箭手配合的方式）。
系統(tǒng)成本主要有應用服務器、RDS數(shù)據(jù)庫、對象存儲OSS、阿里大于、https證書、云數(shù)據(jù)庫redis以及其他需要做消息推送圖片鑒黃負載的各種服務器；人力成本主要有Java工程師、IOS工程師、Android工程師、前端工程師以及爬蟲工程師；開發(fā)配置主要包括各種Win開發(fā)電腦、IOS開發(fā)電腦、IOS開發(fā)者賬號、各種測試手機等。
成本評估之后就是確定產(chǎn)品研發(fā)推進計劃。
三、提前確定開發(fā)規(guī)約，常規(guī)約定以及性能檢測方式
JAVA方面的規(guī)約我是基于《阿里巴巴 JAVA 開發(fā)手冊》編寫了一份適合我們自己的規(guī)約，性能方案我是直接用Coding.net去做代碼分析的，重點在檢測代碼的圈復雜度。
移動開發(fā)方面主要參考網(wǎng)易的代碼規(guī)范，同時開發(fā)階段就接入了騰訊bugly，目的倒逼app相關開發(fā)人員去減少app的崩潰次數(shù)。
服務端api這塊也很早做了一些約定：返回的數(shù)據(jù)中正確值和空值的類型必須一樣。舉例來說，用戶名的字段是｛“name”：“xxx”｝，如果名稱為空時，則應該返回｛“name”：“xxx”｝。如果返回值是一個數(shù)組類型，空數(shù)據(jù)則返回一個空數(shù)組，絕對禁止返回null值（app 70%的崩潰都源于服務端接口返回null）。API版本升級時，需要注意兩點：V2版本的API的Controller必須要繼承V1版的Controller，這樣V2版本的API只重寫需要改動的API；在線API測試文檔中詳細標明返回內(nèi)容，方便App客戶端人員的調(diào)試。
四、列出所有的技術難點，并一個個去攻克
我們列出了20多個技術難點，按照緊急度&重要度做了梳理，并加上處理時間的截點。
五、產(chǎn)品研發(fā)推進計劃
所謂的產(chǎn)品研發(fā)推進計劃就是把產(chǎn)品的需求打散，按照每一個模塊每個功能點去拆分評估時間，得出一個最快可以上線的時間。再然后根據(jù)產(chǎn)品設計的優(yōu)先級去確定月計劃和周計劃。我在定產(chǎn)品研發(fā)推進計劃時研發(fā)部一位同事都沒有，這是一個坑，我在幾位在移動研發(fā)領域摸爬滾打多年的朋友幫助下保證了坑不是太深。
在人員來齊之后，我們的產(chǎn)品研發(fā)推進計劃在形式上依賴于禪道，我在禪道上創(chuàng)建team每個開發(fā)者的任務：在禪道“項目”創(chuàng)建產(chǎn)品的模塊（一般是按照網(wǎng)站或App的tab模塊去拆分創(chuàng)建），在對應的產(chǎn)品模塊中創(chuàng)建對應的任務，每個任務對應產(chǎn)品經(jīng)理制作的《產(chǎn)品版本功能管理表》中的每個功能點，并設置好截止日期、任務執(zhí)行人、任務完成的預計完成時長（默認每個任務1小時，便于做項目的進度把控）。
這里需要注意的兩個點，我再重復下：
1、一定要把每個功能點都記錄到禪道，記住是每個功能點，特別是在時間很緊迫的時候，你無法保證你的小伙伴會認真仔細地看原型，并且還可以通過原型提取那么多功能點。
2、每個任務都需要有截止時間，沒有截點的任務就不是任務。
這么做的原因主要是為了達到兩個目的：保證產(chǎn)品研發(fā)的每個參與者明確自己的所有任務，明確每個任務的時間截點；方便產(chǎn)品研發(fā)負責人對產(chǎn)品做過程驗收。
六、研發(fā)負責人的過程驗收（一般為1周一次）
對于產(chǎn)品研發(fā)的負責人，至少每周要進行一次過程驗收，特殊情況需要一天一次。
我在每周六（我們當時是9 10 6）下班前要對本周每個人的任務完成情況進行一個驗收，驗收的過程主要是對照禪道上的任務表進行查看。
驗收參考項：每個單個功能點一定要調(diào)通［必須］，保證每個功能點中的頁面不會出現(xiàn)空數(shù)據(jù)（不利于驗收）［必須］，根據(jù)具體情況對用戶體驗提些要求（比如App中在驗收時發(fā)現(xiàn)很多按鈕的點擊范圍太小，很難點中）［非必須］，保證整個操作的連貫性，如果有相關的功能點時邏輯要走通［非必須］。
我會對驗收結果進行判斷是否需要再加班趕進度。
同時我對每個組員的代碼質(zhì)量進行review，這塊可以利用Coding.net自帶的代碼分析功能，有問題需要在周會上及時提出來進行討論。
七、產(chǎn)品負責人的階段性驗收（一般為1個月一次）
我們每個月進行一次階段性驗收，驗收的過程主要是對照禪道上的任務表、產(chǎn)品原型、產(chǎn)品效果圖進行查看，這塊前期需要在研發(fā)部由產(chǎn)品研發(fā)負責人進行內(nèi)部驗收，再提交到產(chǎn)品部和產(chǎn)品經(jīng)理一起驗收。
驗收參考項：每個單個功能點一定要調(diào)通［必須］，保證每個功能點中的頁面不會出現(xiàn)空數(shù)據(jù)（不利于驗收）［必須］，根據(jù)情況對用戶體驗提些要求（比如App中在驗收時發(fā)現(xiàn)很多按鈕的點擊范圍太小，很難點中）［必須］，保證整個操作的連貫性，如果有相關的功能點時邏輯要走通［必須］（確定1-3條檢測標準，即是否可以走通本月計劃中的主要流程，在這過程中一般會包括“管理后臺＋前臺網(wǎng)站”或“管理后臺＋App客戶端”）。
我和產(chǎn)品經(jīng)理在驗收之后需要出一份驗收報告，同時在驗收過程中發(fā)現(xiàn)的bug需要及時記錄到禪道上，便于研發(fā)人員及時修復。
我和產(chǎn)品經(jīng)理對驗收結果進行判斷是否需要加班趕進度或緊急調(diào)整項目計劃，并告知其他相關部門人員。
八、驗收時的問題
1. 我們在做周驗收和月度驗收時經(jīng)常會遇到有些小伙伴沒有按時完成任務，但是也沒有特別的嚴重，那么怎么辦呢？
我定的方案是我和產(chǎn)品經(jīng)理每天晚上對之前的任務和正在進行的任務進行每天測試，測試出來的問題相關的開發(fā)人員在第二天上午進行修復這些bug，下午和晚上該做什么就做什么，按照既定計劃往前推進。他們每天把修復bug的項目打包上傳，我當時用的是fir.im。
2. 因為我們在趕項目，很多時候無法避免會選擇比較次的方案去實現(xiàn)某個功能點，當然我們在做的時候是知道有更優(yōu)的方案，但基于時間的考慮，我們會選擇次的那個方案。那么這種情況怎么辦呢？
我的方案是我在禪道上新建了一個“研發(fā)部問題看版”項目，每個組員需要那種情況就把問題記錄到這個項目下，我們在后面時間寬裕的時候再一個個去解決，不過這里需要說明的是，如果可以有更優(yōu)的方案盡量就用更優(yōu)的方案一次性解決，而不是每次都用次的方案。
九、如何輸出相應的文檔
我們都知道，在我們從0開發(fā)一個項目時，總有一些不緊急但很重要的事，其中最典型的就是各種文檔的編寫，比如設計文檔。特別是當我們忙的不可開交時，不可能強制要求開發(fā)人員去寫這些對我來說很重要對他們來說有點浪費時間的事。那么怎么辦呢？
我的做法是為他們弄了一個文檔范例，讓他們分階段去增加內(nèi)容，比如在做A模塊時，讓他們增加A模塊的內(nèi)容，增加什么開始不限制，可以是一些思路，可以是問題點。等后面有空的時候再整理。
十、重視交互評審
除了研發(fā)部本身的一些評審之外，與協(xié)作部門——產(chǎn)品部需要的評審主要有3個：原型評審、交互評審和UI評審。
原型評審和UI評審這個每個公司基本上都是有的，但是交互評審就不一定有啦。我之前沒有經(jīng)驗，一開始我沒要求產(chǎn)品部去做交互稿這塊，導致我們研發(fā)人員在做功能交互的時候各種猜測，最后做出來的交互不滿足要求，同時IOS和Android兩位客戶端的交互差別太大，不得不返工。
交互主要分為頁面交互（也就是頁面操作流程）和功能交互。
頁面交互代表主體流程，主體流程決定代碼結構，客戶端一些交互流程的細微變化，對代碼結構、可維護性、后面是否因流程有坑而需要重構，影響都比較大。交互階段，比如會考慮到一些loading和過渡狀態(tài)，比如開發(fā)會知道哪些是耗時的操作，從而影響到流程的可行性。從另一個角度講也能防止開發(fā)階段發(fā)現(xiàn)流程有坑從而讓UI返工。
功能交互主要是指對于一些復雜的操作動效需要有一個可以參考的標準，而不是靠客戶端開發(fā)人員自己猜。
總體來說，交互的意義是讓研發(fā)人員對整體工作量有個大概的預估，不遺漏頁面流程，對功能交互沒有歧義。
我們的產(chǎn)品研發(fā)還在進行中，在這過程中有太多經(jīng)驗和教訓，之后的一些感悟我還會不定期更新到這篇文章中。
歡迎一起交流學習。
