首先?；锇閭冃履昕鞓?！接下來進入正題。

作為TGIDEAS里的技術研發團隊，我們跟其他的技術團隊一樣對新技術、新業務形態時刻關注，面對新的應用形態，團隊結合實際業務，趕在年前發布了以下四款小程序應用：

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

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

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

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

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

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

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

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

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

一.前端主動驅動產品

為什么樓主建議前端主動驅動產品，主要原因在于：

1.小程序開發中前端技術比重較大

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

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

開發模式的轉變，前端架構首當其沖

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

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

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

為了告知相關團隊我們能利用小程序實現什么，我們還撰寫專門的技術文章，最終得到產品和項目側的認可，進而策劃新需求，并最終決定開發；而在后續的開發中，對于視頻直播、分享邏輯等功能上均提供了技術側以及產品側的建議。

2.前端開發者需兼顧整個開發流程

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

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

二.小步快跑，敏捷開發

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

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

三.PLAN B原則

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

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

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

這么說可能有點玄乎，我舉個例子，在進行王者榮耀賽事小程序時，我們有面臨這么一個問題：現有資訊的數據格式沒法滿足小程序的數據格式要求。

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

保底方案為：手動轉換文章格式，并沉淀入庫，制作接口調用。

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

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

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

• 預想方案：微信提供的事件統計模塊
• 保底方案：點擊流的二次封裝接口

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

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

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

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

而在動態開發期，視覺還原環節可類比于目前網頁開發中的重構環節，可對目前的重構人力進行培訓進而分擔該部分工作。

作者：花叔

本文由 @花叔 原創發布于人人都是產品經理。未經許可，禁止轉載。