移动互联网产品开发与运营[笔记]
做好产品的五要素：需求、产品、渠道、运营、数据。
一、需求
* 明确为什么要做此产品
1、产品的需求来源于什么？
2、产品解决的问题是什么？
* 明确目标用户群
* 明确Road Map (发展趋势)
* 明确初期产品功能
- 优先实现核心功能
- 开发周期要短（2周一更新）
- 做竞品分析
- 承担试错的责任
二、产品
（一）设计流程
1、需求表 ——>产品需求表 工具:excel
2、交互表 ——>Visio 或 RP
3、需求文档
（二）产品需求评审
1、产品需求初期评审
参与人员：项目经理、产品经理、技术总负责人
讨论目标：*技术实现成本 *开发时间成本
2、产品需求中期评审
参与人员：项目经理、产品经理、UI设计师、所有开发测试人员
准备材料：产品经理需要准备 PRD（功能及交互图）
讨论目标：与开发小组内所有人员确定功能及技术上是否存在障碍
最后结论：确认所有需求，无异议后由UI开始设计界面
3、产品需求正式评审
参与人员：项目经理、产品经理、UI设计师、所有开发测试人员
准备材料： PRD 及 全套UI设计图
讨论目标：与开发人员最后确认本次迭代产品的功能
最后结论：形成本次迭代版本进入的功能列表
（三）、产品开发流程
1、产品需求初期排期
参与人员：项目经理、技术负责人
准备材料： PRD 及 全套UI设计图
讨论目标：确定产品功能的初步排期及每个功能的责任人
最后结论：形成本次迭代版本的初期排期时间表
2、产品需求正式排期
参与人员：项目经理、技术负责人、所有开发测试人员
准备材料： PR、全套UI设计图、产品功能拆分表、产品初步排期表
讨论目标：由对应功能开发和测试人员分别给出具体的开发测试排期
最后结论：确定本次迭代的产品分工及排期表
（1）、FC时间 （2）、RC时间 （3）、预留buffer后的发布时间
（四）、产品开发
*每天早上要进行站例会，时间应控制在15分钟左右
*项目经理需要随时跟踪每个人的进度
*功能模块尽量结对开发
*功能模块完成后需要自测（RD负责）
*自测无误且产品经理确认功能完成后，提交进行模块测试
*FC版本完成后即可进行 show case
开发管理工具
*版本控制 —— Git
*CodeReview —– Gerrit
*自动化编译&DailyBuild —— Hudson 或 BuildBot
*文档管理 —– Wiki
*Android代码混淆 ——- Proguard
（五）、测试流程
1、测试人员需要全程参与设计开发
2、测试人员需要完全理解产品设计需求
3、测试人员需要对功能实现机制了解
4、在需求评审及排期完成后，需要立即组织测试case评审
5、测试人员需要在模块开发完成后就介入
6、测试人员需要在产品完成后进行多轮集成测试
7、测试人员需要参与决定最终发布标准
测试管理工具
* 测试Case管理 —– TestLink
* Bug管理 —— Bugzilla或Jira
（六）、产品发布流程
1、产品经理需要确认每个功能模块是否符合产品设计要求
2、测试人员需要确保总体Bug数量符合发布标准（AB = 0 C<5）
3、设计师需要确认产品UI实现是否符合设计要求
4、服务器端项目经理需要确认服务端线上环境测试部署完毕
5、运营人员需要确认运营服务准备完毕
6、运维人员需要确认升级服务器、CDN准备完毕
7、如以上都OK的话，项目经理确认项目符合发布要求
8、对最终版本签署公司正式签名，并进行根据要求升级和渠道上线
9、产品经理根据需要确定是否需要灰度发布
三、渠道
（一）、线上渠道
1、大渠道覆盖（百度手机助手、360手机助手、腾讯应用宝、豌豆荚等）
2、全渠道覆盖（安卓市场、91手机助手、安智市场、小米商店、机锋市场等）
3、合作换量：与目标用户群重叠的产品进行合作换量，相互利用资源
4、新媒体：微信公众号推广、微博大号推广、网红推介等
5、通过应用渠道号统计，计算最有效率的渠道，重点投入资源推广
（二）、线上渠道转化率
1、渠道属性：百度推广、广告联盟、应用换量、应用市场具体分类
2、使用成本：安装、激活流程复杂度
3、包大小：减少下载流量、提高下载成功率
4、渠道推广方式：用户意愿、恶意推广
5、其他：名称、描述、截图、图标等
（三）、线下渠道
1、能覆盖目标用户群的渠道：电梯、楼宇、大屏幕、户外广告、洗手间
2、刷机渠道：知名厂商合作内置、运营商内置、山寨机内置、终端零售刷机等
3、线下媒体：报纸、电视
4、线下媒体也需要渠道号
（四）、渠道相关
1、渠道号
渠道号主要用于标识应用分发的渠道，通过客户端上报，服务端收集后汇总计算
2、Token
Token用于唯一标识用户安装应用所使用的设备，主要用于统计
3、帐号
帐号用于在业务上对用户行为进行区分，方便运营及行为统计
四、运营
（一）、线上运营
1、维护产品主页、微博账号、微信公众帐号
2、收集各种渠道的用户反馈，并与用户互动
3、周期性进行各类活动（如抽奖），提高用户粘性
4、借助各种公共事件进行运营
5、与微博大号、微信公众账号、各类有资源的群体合作
6、与各类互联网媒体合作，发PR稿，提高关注度
7、利用各种突发事件进行高效运营
8、利用版本升级进行运营
*线上运营活动流程
1、活动发起
一般由运营人员发起，目的在于通过各种运营活动或配合渠道批量获取或召回用户，提高用户活跃度。
2、运营产品设计
运营人员设计整个运营活动，产品在应用中设计全套运营活动流程。
3、开发测试
开发人员评估需求的实现成本和开发周期，实际开发并提交测试上线。
4、效果评估
活动进行时需要通过数据实时评估活动效果，并针对问题做有效调整，活动结束后需要评估获得用户量及单位用户成本。
（二）、线下运营
（三）、收入模式
1、广告收益（闪屏、通知、Banner、弹窗等）
2、App推广收益（应用墙、榜单）
3、淘宝或其他O2O平台代购（蘑菇街、美丽说）
4、应用换量
5、应用内合作推广运营
6、直接收费（包含内购）
（四）、运营支撑系统
1、升级服务（渠道升级配置、AB测试升级配置）
2、推荐服务（通知栏推荐、消息推荐、弹窗推荐）
3、运营服务（应用内活动配置、广告位配置、应用推荐配置等）
4、运营效果统计服务（通过运营数据实时评估运营效果）
5、渠道上线系统（编译渠道包、自动上线渠道）
五、数据
（一）、数据分析
1、新增（日新增、周新增、月新增、渠道新增等）
2、留存（日留存、周留存、月留存、渠道留存等）
3、活跃（日活跃、周活跃、月活跃、渠道活跃等）
4、行为（用户使用应用时各种行为数据的上报）
5、设备信息（用户所持有的设备屏幕分辨率、型号、内存、性能、价格等）
6、其他信息（用户手机内应用、开屏频次、日使用时长、Crash信息）
附，安卓几个版本的名称及发布时间：
Android 1.5 Cupcake(纸杯蛋糕)2009.4.30
Android 1.6 Donut(甜甜圈)2009.9.15
Android 2.0/2.0.1/2.1 Eclair(松饼)2009.10.26
Android 2.2/2.2.1 Froyo(冻酸奶)2010.5.20
Android 2.3 Gingerbread(姜饼)2010.12.7
Android 3.0 Honeycomb(蜂巢)2011.2.2
Android 3.1 Honeycomb(蜂巢) 2011.5.11
Android 3.2 Honeycomb(蜂巢)2011.7.13
Android 4.0 Ice Cream Sandwich(冰激凌三明治)2011.10.19
Android 4.1 Jelly Bean(果冻豆)2012.6.28
Android 4.2 Jelly Bean(果冻豆)2012.10.30
Android 4.3 Jelly Bean(果冻豆)2013.7.25
Android 4.4 KitKat(奇巧巧克力)2013.11.01
Android 5.0 Lollipop (棒棒糖) 2014.10.16
（二）、数据用途
1、新增、留存、活跃（图）
评估整个产品的状态，渠道新增和留存可用于评估各个渠道的质量，及时发现产品、渠道存在的问题。
2、用户行为数据（图）
用于分析用户的类型、使用习惯、偏好，记录产品的使用轨迹，分析产品新功能的使用率等。
3、运营数据
用于评估运营活动的效果，广告效果
4、机型数据（图）
分析主流用户的类型、分类用户、提高应用适配率等。
5、崩溃数据（图）
6、其他数据
