作為TGIDEAS里的技術(shù)研發(fā)團隊，我們跟其他的技術(shù)團隊一樣對新技術(shù)、新業(yè)務形態(tài)時刻關(guān)注，面對新的應用形態(tài)，團隊結(jié)合實際業(yè)務，趕在年前發(fā)布了以下四款小程序應用：

其中“王者榮耀賽事”僅僅歷經(jīng)了1個月的開發(fā)時間，趕在小程序上線時發(fā)布；“王者榮耀官網(wǎng)”緊隨其后，在上線的第二天，也發(fā)布了。

而“火影忍者賽事”沿用現(xiàn)成的、完整的賽事直播框架，僅僅花了8天時間，完成了策劃、設計、開發(fā)和上線，這效率小伙伴們都嚇了一跳。

“鄰友趣”這款利用lbs找游戲好友的陌生人社交小程序，歷經(jīng)了一個多月的開發(fā)時間，最終也在放假前發(fā)布。

項目的輸出效率略高，這背后到底遵循了怎樣的開發(fā)流程，樓主今天拋磚引玉談一談，希望能引起大伙的一些思考，也希望能對即將或正在開展小程序開發(fā)的團隊有用。

小程序在2017年1月9號全量發(fā)布，樓主團隊在10月份開始著手研究小程序官網(wǎng)文檔，12月初團隊的第一個小程序項目---“王者榮耀賽事小程序”項目需求正式立項，12月20日第一個成型的版本制作完畢，以下開發(fā)流程示意圖：

（有同學疑問為什么是12月20制作了第一版？當時微信公開課定在28號，我們猜其可能當天發(fā)布小程序，于是原計劃定在20號時完成完整版，有充足時間提審。）

王者賽事小程序的開發(fā)流程跟網(wǎng)頁需求的開發(fā)流程很像，主要差別為：小程序多了“版本提審”階段

由于引入了審核機制，小程序的迭代并不能如網(wǎng)頁那樣只要開發(fā)者有發(fā)布權(quán)限就能馬上迭代到線上，需經(jīng)微信官方團隊審核后才能發(fā)布上線，于是，測試就變得重要了。

接下來說說王者賽事小程序的開發(fā)流程遵循了簡單原則：

一、前端主動驅(qū)動產(chǎn)品

為什么樓主建議前端主動驅(qū)動產(chǎn)品，主要原因在于：

1. 小程序開發(fā)中前端技術(shù)比重較大

對于API和組件，可由前端開發(fā)者提供可行性評估。

由于小程序大部分API和組件均屬前端范疇，前端開發(fā)者能告知產(chǎn)品經(jīng)理組件和API能實現(xiàn)到什么程度；而對于部分涉及后端技術(shù)的API，前端開發(fā)者了解整個前后端邏輯，可跟后端開發(fā)同學一起商量如何制作接口（例如用戶鑒權(quán)接口）

開發(fā)模式的轉(zhuǎn)變，前端架構(gòu)首當其沖。

小程序相比于網(wǎng)頁，前端技術(shù)形態(tài)雖然主體開發(fā)語言未發(fā)生變化，依然可以通過編寫javascript/(w)xml/css實現(xiàn)邏輯，但設計思路已發(fā)生大改，原本大部分網(wǎng)頁的前端邏輯大多為面向過程式編程，而小程序是借了 HTML5 的技術(shù)棧，卻跑的是傳統(tǒng)客戶端開發(fā)的模式，限制了javascript直接對界面進行控制，開發(fā)者只能通過數(shù)據(jù)驅(qū)動來間接實現(xiàn)界面控制。

前端開發(fā)者結(jié)合上述兩點，可進一步進行技術(shù)預研，輸出成型demo，并推廣到產(chǎn)品側(cè)，引導其結(jié)合實際業(yè)務進行需求立項，而在需求立項后的功能迭代中，又可結(jié)合現(xiàn)有API或組件的技術(shù)擴展性對立項功能的設計邏輯提出建議。

TGIDEAS的前端團隊遵循了以上方法，在10月-11月份對小程序進行技術(shù)研究，曾輸出過部分技術(shù)demo，如結(jié)合web socket的demo，以及結(jié)合實際業(yè)務數(shù)據(jù)的王者榮耀資訊demo，

為了告知相關(guān)團隊我們能利用小程序?qū)崿F(xiàn)什么，我們還撰寫專門的技術(shù)文章，最終得到產(chǎn)品和項目側(cè)的認可，進而策劃新需求，并最終決定開發(fā)；而在后續(xù)的開發(fā)中，對于視頻直播、分享邏輯等功能上均提供了技術(shù)側(cè)以及產(chǎn)品側(cè)的建議。

2. 前端開發(fā)者需兼顧整個開發(fā)流程

首先，因開發(fā)需要，小程序賬號的唯一運營者需要綁定為前端開發(fā)者的微信號。從最初的賬號申請到最終的提審發(fā)布，以及后續(xù)的數(shù)據(jù)統(tǒng)計分析階段，前端開發(fā)者都需要參與，需要兼顧整個研發(fā)、測試和發(fā)布過程。

其次，前端橋接交互、UI和后端，是各方通信的橋梁，因此，如果前端同學在此過程中主動推動整個項目的進展，項目研發(fā)速度將會有較大提升。

二、小步快跑，敏捷開發(fā)

每個功能，每個bug，在提出后的短時間內(nèi)均快速實現(xiàn)，王者榮耀賽事小程序的開發(fā)周期之所以僅花了一個月，有賴于各方團隊的極力配合，實現(xiàn)了快速拉會，快速拍板，快速排期，快速開發(fā)等高效工作模式。

怎樣做到敏捷開發(fā)，樓主覺得只要有驅(qū)動者即可。前端可以驅(qū)動產(chǎn)品，所以這時候只要前端同學不要把自己的角色定義為執(zhí)行者，而是定義為驅(qū)動者，在遇到問題時，不是尋求方案而是先提早預想解決方案，然后引導大家對方案進行優(yōu)化即可。

三、PLAN B原則

這也是樓主在其他項目中應用的原則，意思是任何一套技術(shù)方案，最好能構(gòu)想兩套方案，一個是預想方案，一個是保底方案。

預想方案是大膽的假設方案，必須安排時間進行預研、突破和實現(xiàn)。

保底方案是必定能行的方案，一般是很簡單粗暴的方法，目的是為了保證整個產(chǎn)品邏輯起碼能形成閉環(huán)。

這么說可能有點玄乎，我舉個例子，在進行王者榮耀賽事小程序時，我們有面臨這么一個問題：現(xiàn)有資訊的數(shù)據(jù)格式?jīng)]法滿足小程序的數(shù)據(jù)格式要求。

我們制定的預選方案為：運營側(cè)或者前端側(cè)制作自動轉(zhuǎn)換接口，把原有資訊內(nèi)容自動轉(zhuǎn)成小程序格式的內(nèi)容。

保底方案為：手動轉(zhuǎn)換文章格式，并沉淀入庫，制作接口調(diào)用。

起初，運營開發(fā)對預選方案經(jīng)過初步嘗試后，并未能實現(xiàn)，于是我們快速切換為保底方案，讓項目邏輯直接往下跑，而等到后期釋放人力后，運營開發(fā)的同學其實已經(jīng)攻破了難關(guān)，原本的預選方案已經(jīng)能實現(xiàn)。

保底方案就是plan b，它不一定能用上，但它有不可磨滅的作用。

當然，這兩套方案并不是只能選其一，也能同時使用。我們對熱區(qū)數(shù)據(jù)埋點統(tǒng)計同時部署了預想方案和保底方案，

預想方案：微信提供的事件統(tǒng)計模塊

保底方案：點擊流的二次封裝接口

事實是，微信提供的事件統(tǒng)計模塊在小程序發(fā)布前期有BUG，數(shù)據(jù)有點偏差，但幸運的是我們兩套方案均部署了，點擊流的統(tǒng)計方式把熱區(qū)統(tǒng)計的數(shù)據(jù)收集了。

上述扯談了一下王者賽事小程序的應急開發(fā)流程和一些原則，其實在攻克這個小程序后，我們手上別的小程序項目的開發(fā)流程也就順暢起來了，這里總結(jié)一下通用的一個流程圖：

（時間的評估是以我們團隊的人力情況衡量的，只做參考）

預延期部分我涂灰了，并不是說這塊不重要，相反樓主覺得這塊特別重要，前端的同學最好在項目開始之前做一下預研，這樣有時候會事半功倍。

而在動態(tài)開發(fā)期，視覺還原環(huán)節(jié)可類比于目前網(wǎng)頁開發(fā)中的重構(gòu)環(huán)節(jié)，可對目前的重構(gòu)人力進行培訓進而分擔該部分工作。

最后，謝謝大家關(guān)注。

「那些年騰訊游戲的刷屏過的H5」

1. 吳亦凡入伍丨《火爆的“吳亦凡入伍”HTML5背后有哪些設計故事？》
2. 親歷者說丨《超火的故宮HTML 5背后的設計故事》
3. 薛之謙憋大招丨《刷爆網(wǎng)絡的「薛之謙憋大招H5」，設計師是這么做出來的！》

原文地址：Tgideas.qq

【優(yōu)設網(wǎng) 原創(chuàng)文章 投稿郵箱：yuan@uisdc.com】

================關(guān)于優(yōu)設網(wǎng)================
"優(yōu)設網(wǎng)uisdc.com"是國內(nèi)人氣最高的網(wǎng)頁設計師學習平臺，專注分享網(wǎng)頁設計、無線端設計以及PS教程。
【特色推薦】
設計師需要讀的100本書：史上最全的設計師圖書導航：http://hao.uisdc.com/book/。
設計微博：擁有粉絲量180萬的人氣微博@優(yōu)秀網(wǎng)頁設計 ，歡迎關(guān)注獲取網(wǎng)頁設計資源、下載頂尖設計素材。
設計導航：全球頂尖設計網(wǎng)站推薦，設計師必備導航：http://hao.uisdc.com