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