约玩抢座概念产品需求.docx
《约玩抢座概念产品需求.docx》由会员分享，可在线阅读，更多相关《约玩抢座概念产品需求.docx（33页珍藏版）》请在冰点文库上搜索。
约玩抢座概念产品需求
iYOParty产品需求文档
撰写：
张洪海
协助：
张懿、胡圣龙
版本：
2.0
时间：
2016年12月30日
一、远景目标：
1. 命名：
iYO！
嗳哟次世代约玩平台
2. 内涵：
打造深度整合网吧电竞群体需求的线下共聚约玩服务
3. 未来以深层次的玩伴定制为主体，整合多层次的产品需求
4. 定制：
高矮胖瘦、内向外向、萌点属性、年龄属性、衣着装扮、服务内容、技能分享。
5. 嗳哟=爱约，爱上约妹子一起出来玩儿
6. 定义为玩伴，就不是一板一眼的服务，而是在服务过程中按照定制者的需求保持高频的互动，真人线下的全程互动。
7. 现阶段功能目标：
在当天选择一位妹子去网咖参加一场数字与荷尔蒙的嘉年华
二、目标市场和客户：
1. 目标市场：
（1）从南昌市600家网咖中挑选最优质的资源，驻点落地。
（2）服务北上广深一线城市大学城、CBD商圈周边网咖。
（3）从大学生群体中挖掘有服务品质的玩伴。
2. 客户定位：
（1）目标用户定位标签：
文艺=内涵、小资=享受、装逼=腔调、自我=主见。
（2）人群描述语：
有主见有腔调享受都市快生活的时尚icon。
（3）月可支配收入水平：
3000-5000元
3. 功能支撑
（1）服务定制平台
（2）玩伴信息录入和管理平台
（3）玩家支付平台
4. 服务重心
1.同类产品特征简述：
（1）轻量级的线上预约服务管理功能，作为整个产品环节的第一入口，辅助玩伴的定制和订单流程。
（2）线下由驻点+服务内涵组成整个产品的交互体验核心。
竞争对手分析
A.目前市面上以“陪玩”为核心功能的产品，以鱼泡泡为代表（从产品知名度、产品功能设计、UI界面设计、内容资源、项目背景、推广手段等都最有优势）其他产品从功能上基本都是“模仿”。
B.虽以“电竞陪玩”为切入点（噱头），但都无法做到单一以“陪玩打游戏”产生更多订单（目标客户有限）。
C.产品多以社区社交、LBS定位服务为主，用户按个人兴趣爱好选择服务提供者。
D.付费门槛和服务门槛因素，线上服务明显“短（订单响应速度）、频（下单数）、快”
E.线下无指定服务场景（除鱼泡泡）
F.提供服务者服务质量参差不齐，基本主打个人技能特长及迎合消费群体喜好为主。
G.各平台无显性（直接）的收益模式，除鱼泡泡用会员机制绑定客户（会员充值优惠），其他平台仅是作为服务提供者和消费者之间的中间平台。
2.自有产品、竞品相同点和不同点
（1）【相同点】同样以“电竞”为切入点（仅以“电竞陪玩”做比较）
（2）【不同点】
A.iYOParty目标客户群体以游戏爱好者为主（前期定位的用户消费场景决定了用户群体结构），其他同类产品目标客户群体覆盖面更广（服务类型多元化）。
B.iYOParty更趋向于垂直服务平台，其他同类产品更趋向于“社区社交、lbs定位服务”模式。
C.同类产品还是主打线上服务（线下服务综合操作门槛高）。
D.iYOParty主打基于用户消费场景的线下服务，更直接的提高用户体验同时降低了用户的消费门槛。
三、产品功能:
1.简述
因为这个是有一定基础功能的迭代版本，现在只对预约玩伴和个人中心两个模块的流程进行阐述：
（1）预约玩伴模块：
A.登录和注册：
当用户进入预约玩伴模块是，这个过程是静默的，用户在不感知的情况下进行了注册和登录，程序实现了登录和注册，当然用户第一次登录的时候要填写一些基本的信息，比如昵称和电话号码。
（2）选择玩伴
B.统计每个玩伴的加权得分，通过linux的crontab的定时任务每24个小时统计一次。
算法为：
妹子的加权得分=妹子平均得分*[妹子的评价人数/（妹子的评价人数+排名前1/10的最低评价数）]+[排名前1/10的最低评价数/（排名前1/10的最低评价数+妹子的评价数）]*所有妹子的平均得分
C.根据妹子的的状态（离线，在线，被预定，服务中）和随机算法刷选出妹子列表，加权得分高，随机概率越高。
D.选择项目，选择妹子之后，根据妹子在后台添加的项目，在前端显示，供玩家选择
E.选择网吧，根据妹子填写的服务地点，玩家可以自由选择，（这里按照地理位置的远近是根据是根据离妹子的远近还是离玩家的远近，有待商量）。
F.生成订单，插入数据库，如果存在同一时间下订单，比较订单金额高低，金额相同，随机选择一个，显示预定成功，反之失败。
G.进入支付流程，具体的参照战服模块。
H.妹子确定订单或者妹子取消订单，妹子确定订单后，修改订单预定中。
I.妹子开始服务，直到服务期结束把订单状态改成保护中，到服务期前10分钟提醒玩家是否延期。
J.玩家发起延期，在10分钟之内，该妹子不能被预定。
K.推送玩家延期提醒，妹子确定延时服务，一直循环，知道这个订单完成为止，妹子订单状态就成在线，可以被其他玩家预定。
（3）评价流程：
对订单进行评价，或有福利，福利机制暂缓
（4）个人中心
A.玩家中心玩家信息编辑，玩家的订单列等等
B.玩伴中心玩伴信息的编辑，比如电话，昵称。
玩伴订单的管理等等，比如接单，取消订单等等。
（5）界面刷新机制：
A.用户订单相关状态改变时刷新界面。
B.评分状态改变刷新界面。
2．功能要求
（1）玩家定义：
客户主体消费人群
（2）玩伴定义：
平台线下服务主体
（3）玩家角色功能点：
信息输入-输入性别、昵称、手机联系方式。
时间选择：
需要预约服务的时间。
（只可预约当天的服务）
玩伴选择：
根据平台推送的玩伴进行选择。
（刷新机制）
玩伴确认：
确认玩伴，进行服务设定和选择。
选择服务：
选择玩伴预设的服务项目。
抢约座位：
预约陪玩上线的服务位置。
订单生成：
（a）同时有若干人预约，则费用最高的人成功。
（b）同时有若干人预约，且费用相同，则系统随机选择一名用户成功。
支付：
支付生成的订单费用。
等待订单确认：
订单生成后，等待玩伴确认订单。
预订期：
期内退款根据时间长度，可退款的金额递减。
服务状态：
（a）服务状态内不可取消订单。
（b）可延长服务的时间。
服务完结：
（a）有10分钟的订单保护期，可用于延长订单。
（b）超过10分钟后，订单结束。
申请服务延长：
只可新增服务项目和延长时间。
等待确认延长服务：
延长服务的确认必须通过玩伴。
订单失效：
（a）玩伴超过30分钟没有接单。
（b）玩伴拒绝接单。
（c）玩家用户取消订单。
支付流程
（4）玩伴角色功能点：
状态管理：
（a）Online-可接单。
（b）Offline-a.未上线不可接单。
b.已接单，订单尚未结束。
（包含预约期）
确认订单：
在操作界面确认玩家发起的订单。
确认延长服务：
在操作界面确认玩家发起的延长服务申请。
个人信息管理：
录入个人信息。
服务项目管理：
选择可服务的项目。
服务地点管理：
选择可服务的地点。
（5）评价：
玩家和玩伴的评价体系共用一套规则。
4.后台开发要求
（1）服务项目管理建立服务项目模型：
项目ID，项目名称，项目价格等等，
（2）玩伴订单管理：
建立订单模型，管理玩伴的订单，查询等等。
（3）玩伴管理玩伴模型建立的审核，玩伴的禁用，启用，玩伴的信息的查询等等。
5.兼容性要求
H5页面窗口自动调整到设备宽度，并禁止用户缩放页面
（部分安卓手机的UC浏览器写完以后还是可以放大缩小）
忽略将页面中的数字识别为电话号码
（ios上会明显有时候会把数字当成电话号码）
忽略Android平台中对邮箱地址的识别
viewport模板
//主要I是强制让文档的宽度与设备宽度保持1:
1，最大宽度1.0，禁止屏幕缩放。
//这个也是iphone私有标签，允许全屏浏览。
//iphone的私有标签，iphone顶端状态条的样式。
//禁止数字自动识别为电话号码，这个比较有用，因为一串数字在iphone上会显示成蓝色，样式加成别的颜色也是不生效的。
webkit表单元素的默认外观怎么重置
.css{-webkit-appearance:
none;}（ios上的下拉框会有圆角，所以要写border-radius:
0）
在input框获得焦点时文字被清空用value在input框输入文字时被清空用placeholder
webkit表单输入框placeholder的文字能换行么？
ios可以，android不行~,在textarea标签下都可以换行~
html,body{
overflow:
hidden;/*手机上写overflow-x:
hidden;会有兼容性问题，如果子级如果是绝对定位有运动到屏幕外的话ios7系统会出现留白*/
-webkit-overflow-scrolling:
touch;/*流畅滚动,ios7下会有滑一下滑不动的情况，所以需要写上*/
position:
realtive;/*直接子级如果是绝对定位有运动到屏幕外的话，会出现留白*/
}
手机上的flex布局时会有兼容性问题，只用新版本的会出现安卓手机不识别的现象
.box{
display:
-webkit-box;/*老版本语法:
Safari,iOS,Androidbrowser,olderWebKitbrowsers.*/
display:
-moz-box;/*老版本语法:
Firefox（buggy）*/
display:
-ms-flexbox;/*混合版本语法:
IE10*/
display:
-webkit-flex;/*新版本语法:
Chrome21+*/
display:
flex;/*新版本语法:
Opera12.1,Firefox22+*/
}
.box>li{
-webkit-box-flex:
1.0;
box-flex:
1.0;
-webkit-flex:
1.0;
flex:
1;
width:
0;/*解决兼容性问题*/
}
输入框的兼容性解决
input[type="text"],
input[type="date"],
input[type="tel"],
input[type="email"],
input[type="password"]{
-webkit-appearance:
none;
display:
block;
width:
100%;
height:
0.8rem;
line-height:
normal;/*手机上的line-height不能写成和height的值一样，会出现再次输入光标靠上的现象*/
background:
none;
font-size:
0.32rem;
padding-left:
0.28rem;
border-radius:
0;
-webkit-border-radius:
0;
border:
1pxsolid#d5d5d5;
-moz-box-sizing:
border-box;
-webkit-box-sizing:
border-box;
box-sizing:
border-box;
outline:
none;
-webkit-transform:
translateZ（0）;
-moz-transform:
translateZ（0）;
-ms-transform:
translateZ（0）;
-o-transform:
translateZ（0）;
transform:
translateZ（0）;/*解决加入js后input框输入瞬间变白的现象*/
}
禁用radio和checkbox默认样式
input[type="radio"]:
:
-ms-check,input[type="checkbox"]:
:
-ms-check{
display:
none;/*这样就可以用class自定义样式*/
}
webkit表单输入框placeholder的颜色值
input:
:
-webkit-input-placeholder{color:
#999;}
input:
focus:
:
-webkit-input-placeholder{color:
#999;}
手机上的多行省略
.overflow-hidden{
display:
box!
important;
display:
-webkit-box!
important;
overflow:
hidden;
text-overflow:
ellipsis;
-webkit-box-orient:
vertical;
-webkit-line-clamp:
4;/*第几行出现省略号*/
/*text-align:
justify;不能和溢出隐藏的代码一起写，会有bug*/
}
文本标签line-height：
1或者是line-height等于height文字会被切掉
手机上浮动元素能写宽尽量写宽不然很容易出现兼容性问题,尽量不要写高，因为内容多少不固定
给不同屏幕大小的手机设置特殊样式
@mediaonlyscreen and（min-device-width:
320px） and（max-device-width:
375px）{}
元素一定要写上type属性不然会默认提交表单，出现想不到的bug
某些安卓手机的自带浏览器不识别onkeydownonkeypressonkeyup事件，这些事件会导致不能输入汉字
input框若是不想输入文字只能读不能写可以加readonly属性
手机上用背景图写运动，如果需要背景图定位来实现运动效果可以用rem进行计算后加上basckground-size:
图的个数*100%0；
写背景图时最好加上topleft或者00不然写运动效果时容易出现跳
弹层的关闭事件容易触发弹层关闭后下一层的事件所以要给弹层关闭事件加上event.preventDefault（）
弹层弹出后不允许屏幕滚动给弹层加mousemove事件event.preventDefault（）
面包屑导航如果按照bootstrap给li加：
after伪元素的话在其他浏览器和在UC浏览器中表现的不一样，UC的的会比其他的浏览器宽，所占位置更多
如果一个手机看到的和其他手机不一样会比其他的手机大或者小，查看他的浏览器字体设置是否正常，应该是他把手机浏览的字号调小或者调大了（坑人的所谓的bug）
IOS手机中如果出现一个元素的层级非常高可还是被别的元素遮盖的，那么就将该元素与别的元素同级
苹果手机固定定位有bug检查html和body是不是设置了overflow-x:
hidden;
6.性能要求
（在第一阶段的开发中已经确定了标准）
7.扩展要求
（在第一阶段的开发中已经确定了标准）
8.产品文档要求
（1）数据说明文档
（2）产品开发文档
（3）后台使用文档
9.原型设计概念
（1）性别选择
（2）手机号码
（3）昵称设定
（4）主界面
（5）玩伴选择
（6）玩伴资料
（7）服务地点选择
（8）服务定制
（9）支付
（10）等待确认
（11）预约期
（12）服务中
（13）服务即将结束
（14）延长服务
（15）服务评价
（16）用户中心
（17）订单
（18）收藏
（19）个人信息
（20）玩伴首页
（21）玩伴订单信息
（22）玩伴确认订单
（23）玩伴确认开始服务
（24）玩伴确认延长服务
（25）评价顾客
（26）个人信息录入
（27）服务项目录入
（28）服务地点录入
四、产品发布要求:
1.产品支持
（1）需要组建专门的运营组。
包括（不仅）以下：
A.平台管理员2名
B.客服若干
C.玩伴10名
D.线下支撑（根据驻点网咖的数量而定）
（2）需要延伸通知呼叫服务。
包括（不仅）以下：
A.短信通知
B.客服人员电话通知（早期）
2.培训要求
A.后台使用培训
B.玩伴用户使用培训
3.其他说明
五、实现进度安排及方案:
1.人员配置：
（1）产品经理：
张懿、张洪海负责：
整体开发进程监督和配合，解决开发中的困难，整合需求和资源。
（2）开发负责人：
胡圣龙负责：
整体开发过程中的技术实现。
（3）前端开发：
1人负责：
前端显示、交互、流程的开发实现。
（4）服务器开发：
2人负责：
后台的功能实现、数据互通以及后台管理工具实现。
（5）UI／UX：
胡明昊、张洪海负责：
产品视觉和交互输出。
2.时间安排：
（1）UI设计：
1月3日出成品。
BUG量：
基本视觉输出不存在问题，不存在尺寸问题。
设计上允许微调。
（2）前端：
1月23日出可预览操作的版本。
BUG量：
基本实现交互。
允许适配和尺寸安放问题。
少量逻辑错误。
（3）服务器／完整Alpha版本：
1月23日出基本可交互／数据互通的版本。
BUG量：
大体可以交互。
（4）完整Beta版本：
年后2-3天内出可进行内测的版本。
BUG量：
可完整跑通产品流程。
（5）公测Release版本：
年后一周内。
BUG量：
只允许管理后台存在问题。
六、用例:
iYO平台是针对于微信用户开发的一个平台，每一个微信用户可以是玩家，或者玩伴，所以对平台来说，分为两种角色，一种是玩家，一个是玩伴。
从用例分析上面讲分3个模块：
1. 玩家模块，也就是就是一期设计的战服模块，从这个模块进去的微信用户默认的角色是玩家。
2. 预约玩伴模块，从这个模块进去的默认角色也是玩家，玩家可以在这里预约到自己喜欢的妹子。
3. 个人中心，在这个模块里面，分为玩家中心管理，和玩伴中心管理，用户可以编辑自己两种角色的信息。
七、线下操作替代方案:
1.预设客服2名：
客服A（负责处理订单）、客服B（负责客户关怀）。
2.设置客服微信工作号*2。
3.玩家通过二维码扫码添加客服A。
4.客服A将可含有预约玩伴的信息表提供给玩家预约。
（只可以预约当天的玩伴）
5.预约过程以问答的形式进行。
6.确认订单，计算价格后，玩家发红包给客服A。
7.客服A与玩伴联系，确认订单。
8.将玩伴从可预约的名单中剔除。
9.向玩家告知订单已确认，并申明规则。
10.玩伴到店后前往水吧前台签到。
11.玩家到店后开始服务。
服务期间需要延长服务，玩家需要向客服A申请并且发相应金额的红包。
12.玩伴也向客服A确认延长服务的请求。
13.玩家和玩伴的互相评价都向客服A提交。
备注：
1.玩家必须向客服A提供基础信息才可以预约。
2.玩家在约定时间内未到店，玩伴必须在网吧等待到服务时间结束。
除非玩家申请取消服务。
（不退款）
3.玩伴需向客服A提供个人的相关信息。
4.玩伴是否可以接单（请假）需向客服A申请。
5.玩伴离店也需要在前台签字。
异常处理：
1.玩家可向客服B提出投诉及意见。
2.玩伴可向客服B提出投诉及意见。
3.异常的订单处理向客服B提交，由客服B处理。
4.客服B需要将玩家和玩伴双方的评分汇总，每日中午12时更新一次。
5.客服B需要在一些业务纠纷中，到现场处理。
6.如果遇到冲突订单客服A按照递交订单的时间顺序选择。
升级会员 