今年5月底，我加入一家創(chuàng)業(yè)型公司，在我加入之前公司只有3位同事：企業(yè)負(fù)責(zé)人，HR和一位產(chǎn)品經(jīng)理婆排。那個(gè)時(shí)候產(chǎn)品的原型還沒最終確定。
我加入之后的首要工作就是組建一支App的研發(fā)團(tuán)隊(duì)笔链，因?yàn)槲覀円龅漠a(chǎn)品就是一款A(yù)pp的社交平臺段只。本文我將從總結(jié)的角度去回顧我們是如何組建團(tuán)隊(duì)并順利進(jìn)入產(chǎn)品攻堅(jiān)戰(zhàn)，重點(diǎn)闡述我在這個(gè)過程中的所做所思所想鉴扫。
一赞枕、需求原型確定
企業(yè)負(fù)責(zé)人、產(chǎn)品經(jīng)理和我經(jīng)過長時(shí)間的產(chǎn)品評審坪创，終于確定了V1.0.0版本的產(chǎn)品原型炕婶，原型一旦確定也就是需求確定，那么接下來的工作就是進(jìn)入U(xiǎn)I設(shè)計(jì)和產(chǎn)品研發(fā)莱预。
而對于一家創(chuàng)業(yè)型公司柠掂，在研發(fā)人員還未到崗之前必須要做的事就是研發(fā)成本評估，我們當(dāng)時(shí)的成本評估是以年為維度去做的依沮，每個(gè)季度可以允許調(diào)整一次涯贞。
二、V1.0.0版研發(fā)成本評估
我們的成本主要分為系統(tǒng)成本（各種云服務(wù)器）危喉、人力成本（研發(fā)測試人員）宋渔、開發(fā)配置成本（開發(fā)電腦和測試手機(jī)）以及數(shù)據(jù)采集成本（我們采用的是Python開發(fā)和神箭手配合的方式）。
系統(tǒng)成本主要有應(yīng)用服務(wù)器辜限、RDS數(shù)據(jù)庫皇拣、對象存儲OSS、阿里大于列粪、https證書审磁、云數(shù)據(jù)庫redis以及其他需要做消息推送圖片鑒黃負(fù)載的各種服務(wù)器谈飒；人力成本主要有Java工程師、IOS工程師态蒂、Android工程師杭措、前端工程師以及爬蟲工程師；開發(fā)配置主要包括各種Win開發(fā)電腦钾恢、IOS開發(fā)電腦手素、IOS開發(fā)者賬號、各種測試手機(jī)等瘩蚪。
成本評估之后就是確定產(chǎn)品研發(fā)推進(jìn)計(jì)劃泉懦。
三、提前確定開發(fā)規(guī)約疹瘦，常規(guī)約定以及性能檢測方式
JAVA方面的規(guī)約我是基于《阿里巴巴 JAVA 開發(fā)手冊》編寫了一份適合我們自己的規(guī)約崩哩，性能方案我是直接用Coding.net去做代碼分析的，重點(diǎn)在檢測代碼的圈復(fù)雜度言沐。
移動開發(fā)方面主要參考網(wǎng)易的代碼規(guī)范邓嘹，同時(shí)開發(fā)階段就接入了騰訊bugly，目的倒逼app相關(guān)開發(fā)人員去減少app的崩潰次數(shù)险胰。
服務(wù)端api這塊也很早做了一些約定：返回的數(shù)據(jù)中正確值和空值的類型必須一樣汹押。舉例來說，用戶名的字段是｛“name”：“xxx”｝起便，如果名稱為空時(shí)棚贾，則應(yīng)該返回｛“name”：“xxx”｝。如果返回值是一個(gè)數(shù)組類型榆综，空數(shù)據(jù)則返回一個(gè)空數(shù)組妙痹，絕對禁止返回null值（app 70%的崩潰都源于服務(wù)端接口返回null）。API版本升級時(shí)奖年，需要注意兩點(diǎn)：V2版本的API的Controller必須要繼承V1版的Controller细诸，這樣V2版本的API只重寫需要改動的API沛贪；在線API測試文檔中詳細(xì)標(biāo)明返回內(nèi)容陋守，方便App客戶端人員的調(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)去拆分評估時(shí)間疗涉，得出一個(gè)最快可以上線的時(shí)間拿霉。再然后根據(jù)產(chǎn)品設(shè)計(jì)的優(yōu)先級去確定月計(jì)劃和周計(jì)劃。我在定產(chǎn)品研發(fā)推進(jìn)計(jì)劃時(shí)研發(fā)部一位同事都沒有咱扣，這是一個(gè)坑绽淘，我在幾位在移動研發(fā)領(lǐng)域摸爬滾打多年的朋友幫助下保證了坑不是太深。
在人員來齊之后闹伪，我們的產(chǎn)品研發(fā)推進(jìn)計(jì)劃在形式上依賴于禪道沪铭，我在禪道上創(chuàng)建team每個(gè)開發(fā)者的任務(wù)：在禪道“項(xiàng)目”創(chuàng)建產(chǎn)品的模塊（一般是按照網(wǎng)站或App的tab模塊去拆分創(chuàng)建），在對應(yīng)的產(chǎn)品模塊中創(chuàng)建對應(yīng)的任務(wù)偏瓤，每個(gè)任務(wù)對應(yīng)產(chǎn)品經(jīng)理制作的《產(chǎn)品版本功能管理表》中的每個(gè)功能點(diǎn)杀怠，并設(shè)置好截止日期、任務(wù)執(zhí)行人厅克、任務(wù)完成的預(yù)計(jì)完成時(shí)長（默認(rèn)每個(gè)任務(wù)1小時(shí)赔退，便于做項(xiàng)目的進(jìn)度把控）。
這里需要注意的兩個(gè)點(diǎn)证舟，我再重復(fù)下：
1离钝、一定要把每個(gè)功能點(diǎn)都記錄到禪道，記住是每個(gè)功能點(diǎn)褪储，特別是在時(shí)間很緊迫的時(shí)候卵渴，你無法保證你的小伙伴會認(rèn)真仔細(xì)地看原型，并且還可以通過原型提取那么多功能點(diǎn)鲤竹。
2浪读、每個(gè)任務(wù)都需要有截止時(shí)間，沒有截點(diǎn)的任務(wù)就不是任務(wù)辛藻。
這么做的原因主要是為了達(dá)到兩個(gè)目的：保證產(chǎn)品研發(fā)的每個(gè)參與者明確自己的所有任務(wù)碘橘，明確每個(gè)任務(wù)的時(shí)間截點(diǎn)；方便產(chǎn)品研發(fā)負(fù)責(zé)人對產(chǎn)品做過程驗(yàn)收吱肌。
六痘拆、研發(fā)負(fù)責(zé)人的過程驗(yàn)收（一般為1周一次）
對于產(chǎn)品研發(fā)的負(fù)責(zé)人，至少每周要進(jìn)行一次過程驗(yàn)收氮墨，特殊情況需要一天一次纺蛆。
我在每周六（我們當(dāng)時(shí)是9 10 6）下班前要對本周每個(gè)人的任務(wù)完成情況進(jìn)行一個(gè)驗(yàn)收，驗(yàn)收的過程主要是對照禪道上的任務(wù)表進(jìn)行查看规揪。
驗(yàn)收參考項(xiàng)：每個(gè)單個(gè)功能點(diǎn)一定要調(diào)通［必須］桥氏，保證每個(gè)功能點(diǎn)中的頁面不會出現(xiàn)空數(shù)據(jù)（不利于驗(yàn)收）［必須］，根據(jù)具體情況對用戶體驗(yàn)提些要求（比如App中在驗(yàn)收時(shí)發(fā)現(xiàn)很多按鈕的點(diǎn)擊范圍太小猛铅，很難點(diǎn)中）［非必須］字支，保證整個(gè)操作的連貫性，如果有相關(guān)的功能點(diǎn)時(shí)邏輯要走通［非必須］。
我會對驗(yàn)收結(jié)果進(jìn)行判斷是否需要再加班趕進(jìn)度堕伪。
同時(shí)我對每個(gè)組員的代碼質(zhì)量進(jìn)行review揖庄，這塊可以利用Coding.net自帶的代碼分析功能，有問題需要在周會上及時(shí)提出來進(jìn)行討論欠雌。
七抠艾、產(chǎn)品負(fù)責(zé)人的階段性驗(yàn)收（一般為1個(gè)月一次）
我們每個(gè)月進(jìn)行一次階段性驗(yàn)收，驗(yàn)收的過程主要是對照禪道上的任務(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)中的頁面不會出現(xiàn)空數(shù)據(jù)（不利于驗(yàn)收）［必須］桂塞，根據(jù)情況對用戶體驗(yàn)提些要求（比如App中在驗(yàn)收時(shí)發(fā)現(xiàn)很多按鈕的點(diǎn)擊范圍太小凹蜂，很難點(diǎn)中）［必須］，保證整個(gè)操作的連貫性阁危，如果有相關(guān)的功能點(diǎn)時(shí)邏輯要走通［必須］（確定1-3條檢測標(biāo)準(zhǔn)玛痊，即是否可以走通本月計(jì)劃中的主要流程，在這過程中一般會包括“管理后臺＋前臺網(wǎng)站”或“管理后臺＋App客戶端”）狂打。
我和產(chǎn)品經(jīng)理在驗(yàn)收之后需要出一份驗(yàn)收報(bào)告擂煞，同時(shí)在驗(yàn)收過程中發(fā)現(xiàn)的bug需要及時(shí)記錄到禪道上，便于研發(fā)人員及時(shí)修復(fù)趴乡。
我和產(chǎn)品經(jīng)理對驗(yàn)收結(jié)果進(jìn)行判斷是否需要加班趕進(jìn)度或緊急調(diào)整項(xiàng)目計(jì)劃对省，并告知其他相關(guān)部門人員。
八晾捏、驗(yàn)收時(shí)的問題
1. 我們在做周驗(yàn)收和月度驗(yàn)收時(shí)經(jīng)常會遇到有些小伙伴沒有按時(shí)完成任務(wù)蒿涎，但是也沒有特別的嚴(yán)重，那么怎么辦呢惦辛？
我定的方案是我和產(chǎn)品經(jīng)理每天晚上對之前的任務(wù)和正在進(jìn)行的任務(wù)進(jìn)行每天測試劳秋，測試出來的問題相關(guān)的開發(fā)人員在第二天上午進(jìn)行修復(fù)這些bug，下午和晚上該做什么就做什么胖齐，按照既定計(jì)劃往前推進(jìn)玻淑。他們每天把修復(fù)bug的項(xiàng)目打包上傳，我當(dāng)時(shí)用的是fir.im市怎。
2. 因?yàn)槲覀冊谮s項(xiàng)目岁忘，很多時(shí)候無法避免會選擇比較次的方案去實(shí)現(xiàn)某個(gè)功能點(diǎn)辛慰，當(dāng)然我們在做的時(shí)候是知道有更優(yōu)的方案区匠，但基于時(shí)間的考慮，我們會選擇次的那個(gè)方案。那么這種情況怎么辦呢驰弄？
我的方案是我在禪道上新建了一個(gè)“研發(fā)部問題看版”項(xiàng)目麻汰，每個(gè)組員需要那種情況就把問題記錄到這個(gè)項(xiàng)目下，我們在后面時(shí)間寬裕的時(shí)候再一個(gè)個(gè)去解決戚篙，不過這里需要說明的是五鲫，如果可以有更優(yōu)的方案盡量就用更優(yōu)的方案一次性解決，而不是每次都用次的方案岔擂。
九位喂、如何輸出相應(yīng)的文檔
我們都知道，在我們從0開發(fā)一個(gè)項(xiàng)目時(shí)乱灵，總有一些不緊急但很重要的事塑崖，其中最典型的就是各種文檔的編寫，比如設(shè)計(jì)文檔痛倚。特別是當(dāng)我們忙的不可開交時(shí)规婆，不可能強(qiáng)制要求開發(fā)人員去寫這些對我來說很重要對他們來說有點(diǎn)浪費(fèi)時(shí)間的事。那么怎么辦呢蝉稳？
我的做法是為他們弄了一個(gè)文檔范例抒蚜，讓他們分階段去增加內(nèi)容，比如在做A模塊時(shí)耘戚，讓他們增加A模塊的內(nèi)容嗡髓，增加什么開始不限制，可以是一些思路收津，可以是問題點(diǎn)器贩。等后面有空的時(shí)候再整理。
十朋截、重視交互評審
除了研發(fā)部本身的一些評審之外蛹稍，與協(xié)作部門——產(chǎn)品部需要的評審主要有3個(gè)：原型評審、交互評審和UI評審部服。
原型評審和UI評審這個(gè)每個(gè)公司基本上都是有的唆姐，但是交互評審就不一定有啦。我之前沒有經(jīng)驗(yàn)廓八，一開始我沒要求產(chǎn)品部去做交互稿這塊奉芦，導(dǎo)致我們研發(fā)人員在做功能交互的時(shí)候各種猜測，最后做出來的交互不滿足要求剧蹂，同時(shí)IOS和Android兩位客戶端的交互差別太大声功，不得不返工。
交互主要分為頁面交互（也就是頁面操作流程）和功能交互宠叼。
頁面交互代表主體流程先巴，主體流程決定代碼結(jié)構(gòu)其爵，客戶端一些交互流程的細(xì)微變化，對代碼結(jié)構(gòu)伸蚯、可維護(hù)性摩渺、后面是否因流程有坑而需要重構(gòu)，影響都比較大剂邮。交互階段摇幻，比如會考慮到一些loading和過渡狀態(tài)，比如開發(fā)會知道哪些是耗時(shí)的操作挥萌，從而影響到流程的可行性绰姻。從另一個(gè)角度講也能防止開發(fā)階段發(fā)現(xiàn)流程有坑從而讓UI返工。
功能交互主要是指對于一些復(fù)雜的操作動效需要有一個(gè)可以參考的標(biāo)準(zhǔn)引瀑，而不是靠客戶端開發(fā)人員自己猜龙宏。
總體來說，交互的意義是讓研發(fā)人員對整體工作量有個(gè)大概的預(yù)估伤疙，不遺漏頁面流程银酗，對功能交互沒有歧義。
我們的產(chǎn)品研發(fā)還在進(jìn)行中徒像，在這過程中有太多經(jīng)驗(yàn)和教訓(xùn)黍特，之后的一些感悟我還會不定期更新到這篇文章中。
歡迎一起交流學(xué)習(xí)锯蛀。
