作为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，数据有点误差，但辛运的是我们两套方案均布署了，点击流的统计方法把热区统计的数据搜集了。
上述扯谈了一下王者比赛小程序的应急开发流程和一些原则，其实在攻破这个小程序后，我们手上别的小程序项目的开发流程也就顺畅上去了，这里总结一下通用的一个流程图：
（时间的评估是以我们团队的人力情况评判的，只做参考）
预延后部份我涂灰了，并不是说这块不重要，相反楼主认为这块非常重要，前端的朋友最好在项目开始之前做一下核高基，这样有时候会事半功倍。
而在动态开发期，视觉还原环节可类比于目前网页开发中的构建环节，可对目前的构建人力进行培训因而分担该部份工作。
最后，谢谢你们关注。
「那些年腾讯游戏的刷屏过的H5」吴亦凡参军丨《火爆的“吴亦凡参军”HTML5背后有什么设计故事？》亲历者说丨《超火的故宫HTML 5背后的设计故事》薛之谦憋大招丨《刷爆网路的「薛之谦憋大招H5」，设计师是如此做下来的！》
