注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

坏脾气的小肥

寂静岭的向阳岸

 
 
 

日志

 
 

灵活不灵活  

2010-04-03 09:13:13|  分类: 产品 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
1、打码专家
我虽然不怎么玩网络游戏,但在网游相关行业里待了五年半,也算是略通一二。挂机,挂机你知道吧。厂商不乐意,不乐意怎么办呢?外挂封不住,就用了验证码。每个把小时弹个验证码出来让你选ABCD,证明是朵活人。我看过几个游戏验证码,其一是四个卡通人物,问,哪个人背对着你?其二是一串歪歪扭扭的英文,问,n是第几个字母?

这时候如果我是外挂作者,必定气得目斜口歪,跳在半空中骂:n是第几个字母?是你老母!很显然验证码都是随机生成的图片,类别还很多,甚至有填空题……

换成是我的话,那就败了,再高明的技术手段也破不了这种验证码啊。就算是Google首席工程师来也不行,不不不,就算是整个Google开发团队派过来也不行。结果呢,我上周亲眼看见它被破解了,完美破解!网游公司气得目斜口歪,鼻血都喷了出来。

干这票的是一支十人小组,乍一看,其貌不扬,极具网吧气质,可见大隐隐于市。他们干活儿的工具是一段代码,把游戏验证码远程读到本机上来,大老远的弄过来干什么呢?你猜对了,远程答题。一个人回答1000个挂机玩家的问题,一天要回答10000道题,十个人能帮10000个玩家挂机……

他们被称为打码员,高效率人肉答题机器。我初次听说这事儿的时候,目瞪口呆,嘴巴都合不拢,闹着去现场看看。走进他们的工作间,发现大家神色淡然,屏幕上有两个窗口,左边是答题窗口,答完一道题自动换下一道;右边是在线电影播放窗口。打码员的视线在两个窗口之间不停飘移,一边看电影,每3秒钟准能按一个键答一道题。一分钟答20道,一小时答1200道,一天八小时答9600道,正确率在98%以上……

当时,我充满敬畏之心地站在他们身边。那些题目果然都很刁钻,我往往连题目都没看清楚,3秒钟不到,他们就按一个键换下一道题,疾如闪电(同时还在看电影)。我只好谦恭地请求他们慢一点,我跟不上时代节奏。一个网吧男模样的年轻人轻蔑地看了我一眼,把速度放慢到5秒钟,刚够我看完题目和答案,正琢磨着选哪个好呢?颇费思量……瞬间他就按到下一道题去了,举重若轻,神乎其技。我眼泪都快流下来了,哑着嗓子说:牛逼呀!他娘的怎么能如此快!

有人冷哼了一声,对我说,你来坐在这里,一天答10000道题,只有20个题目类型,你也能答这么快。

联想到那个用风扇吹走空肥皂盒的故事,都是中国式的智慧。

2、自定义目录
有件事情,我犯蠢了,事后后悔得紧。不妨拿出来说说。

在国内我一直信不过Tag,一提起就大摇其头,所以在PP上坚持用目录来进行分类。目录又分成一二三四级,基本上都由运营人员预设好。显然我们无法预设所有的目录,比如风景下面有西藏,西藏下面有拉萨,但拉萨有几个著名景点呢?我知道的不全。所以得开放用户自定义目录。完全由用户自设我信不过,就算不捣乱,也可能把层级逻辑给搞混掉。管理员审核后开通新目录是必然的设置。

于是我们做了一个设计,比如用户在展示相片的同时,他申请给该相片开通一个三级目录:西藏区下面的林芝。这个请求被发到后台,在审核通过前,他的相片暂时放在西藏区展示。如果审核通过,林芝区开通,相片便自动挪动到林芝了,再发条系统通知给他。审核通不过也发系统通知,告诉他林芝区没开,你的相片会放在西藏区。这个设置是不是很合理?

合理归合理,有技术开发成本啊,程序员又特别少。结果因为杂七杂八的原因,一拖就是……1年半。偌长时间都没开发这个功能,哭成泪人儿。可单单由管理员来预设目录,很明显顶不住,相片分类一直很少很粗糙。

后来,无意间看见POCO的处理方法,特别特别简单。他也上四级目录,但在四级目录末尾放了个填写框,让你填“其他”分类,爱填不填。填完了技术上什么都不用做,只管把填写内容发到后台。管理员看着顺眼,合理,就给手工开个新目录。靠这个土办法,POCO的风景目录比我们全太多了,什么旮旯地方都能找到。

我脑子一定是锈掉了,没错,锈得厉害。

3、反馈处理流程
最近我们上了一套新的用户反馈系统,在后台处理反馈时可以打两个标签,第一个叫“状态”,说明处理状态;第二个叫“类别”,对重要反馈进行归类统计。此外还安排了反馈值班,5个产品人员,每人每周值一天班,回复反馈并标记状态类别。确保策划能接触到鲜活的用户感触,不脱离群众。

问题就出在这个轮班上面。最开始状态标签是4个:“策划关注/技术关注/已处理/忽略”,看似很合理,执行起来发现不对头,大部分反馈都语焉不详(有填写提示但用户不鸟),必须发信息过去追问用户详细情况。结果问题处理不连贯,一个用户在追问下接连反馈3次,周三周四周五,可能由当天值班的3个产品人员去处理,秩序很乱,状态标签也很乱。

为此花了两周时间来调整,最后定了一套改良方案。状态标签重新划分为5个:“WW关注/补充资料中/用户联系中/已处理/忽略”。凡是值班人员能当场解决的问题,就标记“已处理”。当场处理不了,需要跟进解决的,统一标记为“WW关注”。WW是专门负责解决用户反馈的产品人员。

然后WW每天会在后台搜索一次,把“WW关注”的反馈都搜出来,用统一格式给用户发信息,追问详细情况,并把反馈状态改为“补充资料中”。同理,用户再次反馈后,值班策划也标记为“WW关注”,WW再根据进度标记为“用户联系中/已处理”。既实现首问负责制的效果,又让所有产品人员轮流值班面对用户,分担专人处理全部反馈的压力。

每个人值班结束后,把今天遇到的有价值的反馈整理一份简单的邮件,群发整个部门,策划和程序员都能收到。而WW则每周整理一份反馈周报,包括归类统计与问题解决情况简述。

到这一步,我觉得差不多了。一开始制定的流程看似科学合理,其实没什么可操作性。实战中“理想化”的情况太多,即重视理论逻辑不重视实用逻辑。所有的合理性都要在复杂环境中去考验过才算数。如果预设一套方案,觉得自己考虑特周全,调研特充分,上线就甩手不管了,多半是要栽跟头的,摔倒在地上还要骂别人执行不力。然则战胜理想化最好的方法,不是“想清楚再做”,而是“快速发现敏捷调整”。
  评论这张
 
阅读(5517)| 评论(7)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017