硕鼠的博客站

范路的博客主站,时而会发些东西。

Category : 梦想园

17Startup的移动数字阅读专场

       

参加过好几次17Startup的活动了,这是一个非常有趣的组织,一起来创业。

我参加过《美食专题》,作为主持人主持过《旅游专题》,这次又参加了《数字阅读专题》

参加的活动多了,有些有感觉,也有些没有什么感觉的。17startup的活动还都是比较有趣的,每次都是找一个主题,然后将主题相关的创业公司聚集起来,再找一些业内的成功人事和投资经理来对接。这种活动相对于一些其他的创业活动来说,效率要高得多。每次活动结束之后,看到很多参会者留下来和演讲嘉宾以及那些投资人们激烈沟通的时候,都会不由自主的想,也许又一个伟大的项目正在酝酿之中,而我们正在参与这个事情。

 

DSC_0370

上图就是投资人和演讲嘉宾共同组成的嘉宾席位。大家看看有哪些人看起来比较眼熟吗?

 

DSC_0406

这是在活动接近尾声的时候,专家和投资人的点评。

 

 

DSC_0365

本期活动还有一个合作伙伴,那就是浙报集团。浙报集团作为一个传统出版行业的老兵,在互联网和移动互联网时代带来的时候,走在了其他很多传统出版业者的前列,他们正在拥抱这些全新的阅读模式,并希望能够从中找到传统出版行业的新方向和新出路。17startup每期都欢迎相契合的企业或机构来参加,成为活动的合作伙伴。

 

 

DSC_0410

17startup的活动是在全国各大城市巡回举办的,在北京多是使用车库咖啡的场地。上面照片上的这位大叔,就是车库咖啡的老板,我们在那里做了这么多次的活动,还是第一次这位大叔愿意亲自参与一次。这主要是因为这次活动的主题是移动数字阅读,而大叔有一位朋友是做唐茶阅读的,正好和当天的主题比较契合,大叔送了一些《三体》的书签和徽章作为这一期17startup活动的奖品。我非常喜欢《三体》,当场上AppStore上付费购买了一套。

 

DSC_0360

每次活动开始之前,大家需要进行签到,车库咖啡外面签到的这块地方实在是寒酸了一点儿。看看这位美女坐在这里,是不是有一点儿《倩女幽魂》的感觉?

DSC_0364

虽然17startup活动的历史还不是很长,但每次也都是座无虚席,至少在北京我自己参加过的基本上都是这样。这有两个原因,第一、活动确实有吸引力,有很多的创业者希望能够从参与这个活动的过程中能够有所收益。另外一个原因,就是像下图所显示的那样,车库咖啡实际上是一个开放的工场,很多创业项目每天就是在这里办公的,他们可能并不是专程来参加17Startup活动的,但是在17Startup的活动中,他们应该也会有所收益的吧。

DSC_0361

 

活动开始,这一期的活动主持人是易观国际的高级分析师,专门分析数字阅读领域的孙培麟。本来我还争取来着,但是因为长得不够帅所以被残忍的拒绝了。

DSC_0369

开始的时候,孙培麟介绍了他在数字移动阅读领域调查得到的一些数据,他认为,虽然数字移动阅读确实是移动端应用中一个比较刚性的需求,但是在这个领域中存在这很多的伪命题。很多人过分乐观的看待这个市场,过分乐观的看待和移动运营商的合作。这是一个看起来很美的市场,其实,其中艰辛很多深处其中的创业者也是有苦自知。但是,他的一个观点是我无法认同的,他认为内容本身是不会受到技术的影响,技术的不断发展,只是按照不同的方式和渠道将现有的内容推送到客户面前。其实,随着技术的进步,内容的创作,包括语言文字本身也受到了很大的影响。比如起点的字数计费模式,就塑造了中国的网络文学模式。微博的兴起,更加彻底的改变了内容的创造模式。阅读肯定是会影响到创作的,那些内容的创作者,也在研究不断创新的阅读模式,他们中的很多人会尝试着去迎合这些新的模式。作为移动互联网数字阅读,不去研究新的阅读模式对内容的改变,以及在这种改变的不断影响下,移动阅读的方式和内容在向着什么方向前进,一味的相信阅读和创作之中有一部分是不会发生变化的,这是有问题的。

 

DSC_0374

第一位演讲嘉宾是多看网的。他在强调他的单本图书,多看在IOS上推出了很多的单本图书,每一本都是很精品的,排版精美。这位老兄反复强调了,看电子书一定要看有排版的。现在电子书格式分为两大阵营,一个是版式格式,代表为PDF,里面的内容就像是纸质图书一样,是有版式信息的,图片存放在什么地方,文字的大小和相对的位置都是固定的,这种图书放大缩小的时候,会整版的缩放,各个元素之间的相对位置并不会随着缩放而发生变化;另外一种,则是流式格式,代表为epub,这种格式主要是受到了网页排版的启发,里面也能够定义字体,字号,以及图片和文字的关系,但是这种流式格式的内容在放大缩小的时候,元素与元素之间的相对位置是会发生变化的。流式格式的应用中,通常会尽量保证用户所看到的不会是一页中的一部分,用户无论怎么缩放这些内容,他们看到的都会是一整页的内容,只是可能内容会随着缩放,有多有少。流式格式会随着屏幕的大小,以及用户设定的字体大小来自动重新排列内容,使其从新形成完整的一页。个人观点,在移动互联网这种个性化极强的阅读方式上,在各式各样的移动互联网终端屏幕分辨率上,流式格式最终会取代版式格式的。多看其实在android上还有另外一个产品,是一个类似与书城的产品,但是由于那个产品涉嫌盗版内容,所以在这种公开的场合下,这位老兄就只能强调其ios上的单行本了。

 

DSC_0380

酷云这个产品实在是太酷了,听得不是很明白。研发酷云的是北邮的一个实验室,他们以前是做人工智能围棋程序的,据说还取得过非常不错的成绩。他们后来将这些人工智能的算法,运用在了信息智能分析和推荐方面,研发出了这样的一款产品,可以智能的聚集、过滤信息,然后根据对用户行为的分析,向用户推荐他们喜欢或需要的信息。这应该是未来的方向吧,但是在当前的技术条件下,到底能够实现到一个什么程度,我持观望态度。

 

DSC_0384

viva杂志的分享者是一个非常有个性的家伙。他讲到:他们就是和移动运营商合作的,其实上面的多看也在和移动运营商合作。viva主要做得是杂志,他们签下了大量的杂志版权,并将精美的杂志推送到客户面前。当后面有人提问,应该如何进入这个领域的时候,他很诚恳的说,还是要有关系,没有关系这个事情比较难搞,至少一开始是要靠关系的。非常有中国特色。

我当场下载了viva的产品进行测试,确实非常精美。但是,发现这个东西使用的也是版式格式,杂志上的很多小字看不清楚,放大了之后,居然还是看不清楚。应该是扫描、存储和传输的分辨率不够吧。

 

这场活动,缺乏盛大文学的参与,总觉得缺了一些什么。真正的内容创造者没有参与到这个互动中,使得这个活动变得不是那么完美。很多人在谈论,阅读是一件高雅的事情。甚至还搬来了翻译作品时需要遵守的信达雅来充门面。其实阅读就是阅读,每一个人都需要阅读。为大众提供的阅读服务,才是真正有前景的。而将自己定位为雅人,也只希望为雅人来提供服务,甚至认为窃书不算偷的穷酸服务,很难相信他们能够走多远。

人们可以通过阅读增长知识,了解信息,愉悦身心。当前社会上,更多的人应该还是为了愉悦身心而在阅读。我个人的观点是,阅读,特别是移动数字阅读,更多的应该是一种以娱乐为目的的阅读。既可以让用户充分的使用其碎片时间,又可以让读者充分的沉浸其中。同时还要有效的兼顾内容创作者的利益,只有这样,这个生态链才能够圆满。只注重阅读,不注重创作,那么就只能去读那些几十年几百年前的东西。人们希望读到新的东西,创作者希望了解他们的读者,希望能够和这些读者产生互动,并创造出符合时代需要的作品。到会的创业者们,都希望通过满足用户的阅读需求,来得到收益。他们有些人通过和出版社签约,提供的是正版的作品,但是他们在作品的创作,特别是内容创作者和读者之间的沟通上没有什么建树。他们的经济模式并不完整,那些创造内容的人,很难从他们的模式中获得利益。也许他们以后会发生改变,当然,最终这些人中,能够成功的肯定只是很少的一部分。

我喜欢阅读,现在主要是在各种移动设备上进行阅读,希望能够看到更多的,好的服务出来。

期待下一期17startup,不知道下一次在北京会是什么样的主题。

读《简约至上》有感

s4592217

自从开始看网络小说之后,真的是很长事件没有读过纸质书了。对于那些大部头的东西,看着都觉得头疼。
最近,图灵出版社的谢工和我们联系,他们要借用盛大创新院北京office的会议室来做读者活动,根据计划,第一次读者活动应该是在6月份吧。作为答谢,图灵出版社送给我们一批图书。其中有一本《简约至上》,非常薄的一本书,印刷非常精美,每一页,都是左侧文字,右侧图片。文字的部分看起来十分简洁,很多地方看起来更像是一些提纲或目录的样子。

由于工作的原因,看了不少的应用,也看到了不少的设想或应用的雏形。对于很多和设计、用户体验方面的东西,也有了一点点模模糊糊的想法。看了这本书之后,感觉再看身边正在开发的一些应用的时候,好像能够看得更加清晰一些了。

 
该书首先讲解了为什么要进行简约的设计,这里面我看了感觉印象比较深刻的有两点。第一就是用户分类,大部分用户是典型用户,他们没有时间去研究各种复杂的功能;而那些提出最多意见的往往是精英用户,这些用户的意见往往是最应该被忽略的。另外一点,就是要到用户使用软件的现场环境中去观察用户的行为,用户的使用环境通常是很嘈杂的,很多软件是必须挤占用户的碎片时间来为用户提供服务。
这些东西,现在听起来好像是很有道理的。但是,有一点很重要,真理都是有其适用环境的,当真理脱离了其适用环境之后,就不再是真理了。简约的设计,是在近几年特别流行的一个词,这其实是随着移动互联网应用,特别是IPhone应用广受好评之后才开始流行起来的。简约设计应该是非常适合现在以普通大众为目标用户群体的互联网,以及移动互联网应用的设计。对于那些传统软件,或者我们平时所说的行业软件来说,上面那两个点就不能够完全成立了,对于行业软件来说,使用人群都是经过培训的员工,他们通常是坐在办公室里面来使用这些软件的。行业软件应该也是需要简约设计的,但简化的方向和力度肯定和那些面向普通大众的应用是有所差异的。书中也举了一个汽车销售软件的例子,由于销售经理经常需要冲出办公室,去为那些想要买汽车的用户进行解说,所以他们的工作经常被打断。这应该是行业软件中一个非常特殊、非常极端的特例吧。

在介绍了为什么要进行简约设计之后,作者介绍了四种进行简约设计的方法。分别是删除、组织、隐藏和转移。其中删除讲得最为详细,将不太需要的东西删掉。这一部分主要讲的是如何选择需要删除的东西,里面给我印象最深刻的地方有两点。第一、很多项目会将不容易实现的部分删掉,这导致了一些基本需求无法得到满足,用户故事不完整,错删也是非常麻烦的事情。第二、删除的过程经常是非常血腥的,不要去理会“如果用户要如何如何”的假设,也不要太顾忌那些已有功能被删除之后,用户的愤怒和抱怨,只要核心功能完整,用户会逐步接受,而且新用户会更加喜欢简约的设计。

 
在删除之后,就是组织。将相同或相近的功能组织在一起。其中讲到了标识统一,也就是说同类型的东西要具备统一的标识是非常重要的。另外就是通过颜色来进行信息和内容的分层,作者是以伦敦地铁线路为例说明了这个问题,不过,个人感觉需要将地铁图那样信息密集的东西推送到用户面前本身就是一件非常难以想象的事情,用户必须看地铁图是因为他们必须乘坐地铁,很多人到了陌生的城市后,会选择更加昂贵的出租车,最主要的原因就是出租车司机认识路,乘客不需要自己去学习地图。而在互联网、移动互联网应用中,很少有什么是用户必须要做的。

这本书越往后章节就越短,关于隐藏功能,主要是如何隐藏、隐藏哪些、以及这些隐藏的东西,何时出现。作者对于那些能够适时自动闪现的隐藏功能十分推崇。当阅读软件中,当选中了一段文字之后,搜索的功能会自动的跳出来。

 

关于转移,也就是说将一部分功能转其他平台上去。这部分的内容,作者只是提了一下。 关键在于将合适的功能,转移到合适的平台上去。当然,前提是应用一定要是跨平台的。

在这本书中,反复提到的使用简短的语言去描述用户故事,是非常重要的。另外就是,用户调查应该是确认用户需求的比较重要的手段,可惜在身边好像没怎么看到过这种东西。

 

在看本书之前,我不是一个设计人员,所以看过之后,我肯定也还是不具备做设计的能力。只是感觉对于一些产品的设计有了更加清晰的体会。建议所有和产品发生关系的人,不论是不是设计,都能够看看这本书,会对今后的产品生涯有所帮助的。

Cloud Jam 北京站活动总结

1 、缘起

2011年11月,我们举办了“盛大云计算创意&开发大赛”,意在吸引国内的开发者来了解什么才是真正的、开放的、适合他们的云计算,因为此前“云计算”的概念在国内已经被严重误导——就连淘宝上搜云计算也能搜出一大把来——而我们认为,只有IaaS(平台即服务)才是真正的云计算。

为了让大赛更刺激更有趣,我们决定增设一个名为Cloud Jam的挑战赛,要求开发者在33小时内当场完成基于云计算的项目创意、开发、部署。其刺激之处在于对开发者的实力有要求,面对面的较量和对着屏幕较量是完全不同的感觉;有趣之处则在于,参赛者还可以现场寻找志同道合的人进行组队,隐有人潮人海觅知音的感觉。

最后,比赛的时间定在了2012年4月7日至8日,周末两天,33小时,现场组队,现场开发,现场评审,现场发奖。

clip_image002

2、 准备工作

其实决定办Cloud Jam的时候距离比赛只有一个月左右,时间非常紧迫。

我们最开始选择新浪微博的“微活动”作为活动平台,并在17StartUp、ITEye及iWeekend等社区进行宣传。结果后来才发现微活动的功能不够完善,很多必须的统计信息无法收集,于是又重新设计了比赛页面(http://v.to/cloud)并新增了抢座网的报名通道。事后来看,选择活动平台的失误还是对大赛造成了一定的影响。

在线上紧锣密鼓宣传的同时,我们也利用IT龙门阵、CTO俱乐部、PMI项目经理活动、Cloud Foundry等 线下活动进行了现场的宣讲,效果也非常不错。这也算是一种O2O吧?

为了让参赛者能够心情愉悦地参赛,我们准备了独立的WiFi网络,采购了大量的食品和饮料,甚至还准备了一些舒缓轻松的音乐和搞笑的视频短片,以便选手们短暂休息之需。

clip_image003

3、 激情33小时

Cloud Jam的开始时间为4月7日上午10点,但是早在8点半,就有一位参赛者从天津赶至会场;10分钟后,上海也有选手到场。

活动正式开始时,北京赛场已有30多位参赛者。比赛进行中,有些团队呼叫了场外支援,其中还有一位美女设计师……这是后话,暂且按下不表。

开场演讲由气场十足的范路(@LukeFan)主持,他向参赛者介绍了盛大云、盛大云计算创意&开发大赛、Cloud Jam规则与日程以及注意事项等。

clip_image004

随后是参赛者进行自我介绍。他们中有来自百度、雅虎、IBM等 大公司的,也有在校学生,当然还有一些创业者;其中多数人是程序员,前端技术以AIR和HTML5为主,后端则有PHP、JAVA和Ruby on Rails等,此外还有QA、PM、UI等 角色。

个人介绍之后,我们留了5分钟时间让参赛者以“组队”为上的进行沟通。事实再度证明,程序员其实一点儿也不宅,和陌生人“搭讪”的能力还是相当强的。 ^^

再接着就是有项目的人介绍项目,并且进行现场招募——这也是Cloud Jam有趣的地方之一,比赛结束后,很多人都很兴奋在这里找到了新的队友,而且有些项目就是在组队后才经过讨论最终确认成型的。

最后,北京一共组成了15个团队,最大的一个团队有5个人,而“个人团队”竟然有6个!

上午11点,各团队已进入开发状态。

下午一点半,来自五道口“奥巴巴”的比萨终于送到,所有参赛者再次聚到一起,一边吃饭一边交流问题,其乐融融的景象很有几分学校的感觉……

吃饭的同时,有团队开始呼叫场外支援,参赛者总人数再度增加。

clip_image005

clip_image006

期间发生了两个小插曲:一是有个团队使用C#,但盛大云没有提供C#的例程和相关文档,盛大云的志愿者斯文同学帮助解决了;二是有个团队的云主机重启后发生问题,于是我们找盛大云24小时在线客服进行解决,得到迅速解决,也让参赛者意外体验了一下盛大云的服务。

第一天晚上,一部分参赛者回家睡觉,而一些项目紧张或者离家比较远的参赛者决定留下来通宵工作。我们的志愿者也有一些留下来陪着大家,在办公室的沙发上过了一夜,也算是体验了一把创业的艰辛。

clip_image007

虽然当时不是很冷,但是为了大家的健康着想,我们还是要求所有人都睡觉,结果有个参赛者说,这是他最近一段时间睡的最早的一天了……当时已经过了凌晨12点。

我们真心地劝慰每一位朋友,身体永远是本钱,即使是创业,要是把身体拼垮了也是一件得不偿失的事情,身边已经有太多的案例。

好在第二天,所有参赛者都又生龙活虎地上场了。

经过一天一夜,大家都互相比较熟悉了,于是第二天出现了一些跨团队、跨项目的合作,这让我们非常开心 ,“友谊第一比赛第二”的口号在这个物欲横流的时代、在一群成年人身上得到体现,真的很难得。

评审环节从第二天下午3点开始。这个环节采用了类似比赛中少见的异地视频同步方式,上海和北京的参赛者同聚一堂,向其他参赛者和5位评委老师介绍项目并作现场演示,并回答评委提问,由评委和其他参赛者共同打分,最后选出优胜者。

这个时候,团队架构是否完整的差异就体现出来了。一些配置比较齐全的团队,比如产品经理、设计师、程序员等角色完备的团队,产品的完成度和完美度要更好一些,在讲解和演示时也更从容一些。相比之下,一些纯工程师组成的团队在讲解环节就吃了亏。

令人感动的是,有些参赛者在最后离场之前还主动和志愿者们一起清理了这两天留下的生活垃圾,相信这种细微之处的责任心,一定会在未来帮到他们。

4、 获奖项目

整体而言,很多项目都做得非常不错、非常有创意,参赛者也都竭尽可能地利用33小时做出尽可能完善的作品。当然,每次比赛总会有一些团队准备得更加充分,比别人更加努力,这也是比赛的意义所在。这并不是说那些没有得奖的项目不好,但总会有些人做得更好一些。

北京的获奖项目:

冠军:泡泡大对战。一个结合LBS的移动端游戏,让一定范围内的用户自动组合在一起,进行跨平台的点泡泡比赛。他们准备在这次比赛之后继续完善项目,并争取尽快将其推上AppStore,然后通过道具付费的方式实现盈利。值得一提的是,这个团队的成员在参加比赛之前很多人互不相识,却在比赛后走上了共同创业的道路。

clip_image009

亚军:猎影。一个使用AIR平台开发的跨平台MMORPG游戏引擎。团队利用两天时间完成了这个引擎,但是没来得及开发出第一款完整的游戏。这个项目向大家展示出,现在完全可以在各种移动平台上,做出以前只有在PC上才能实现的重型MMORPG游戏。使用这套引擎,再做一些设计,就可以得到一个完整的跨平台移动端MMORPG。这个项目也会在比赛之后,继续向着商业化的道路前进。

clip_image011

季军:云端纪念册。这是一个利用云存储技术,将某一类特定人群的某一类特定信息进行聚合的SNS项目。这是一个由年轻人组成的团队,他们中大部分人都是刚刚走出校门的学生,他们希望能将在校期间很多难忘的回忆记录下来,于是就做了这么一个项目。

clip_image013

上海的获奖项目:

冠军:V2EX。一个开源问答、论坛平台,这个项目提供了一套基于云的开源社交平台,任何人都可以使用这套源代码,在盛大云上部署出自己的社交平台来。V2EX和传统的论坛以及问答网站的差异就在于,可以在内容和用户比较少的时候得到很好的聚集,并通过一些算法和策略,自动提升内容的质量,让优质内容可以被更多的人看到。

亚军:Weipage,将微博内容进行聚集。微博中存在海量内容,但是用户希望找到自己想看的内容还是有一定难度,毕竟微博中的信息流是以人为单位的单向关注为基础。这个项目要做的就是将内容以事件分类,然后放置在其他网站上,让用户能够集中看到一类信息,而不用管这些信息是由谁产生的。

季军:Do Him,一个有趣的HTML5小游戏。在移动互联网时代,很多应用都不赚钱,特别是Instagram被成功收购之后,移动互联网应用不赚钱好像更加成为了天经地义的事情。不过Instagram毕竟只有一个,大部分应用和服务还是需要靠自己赚钱养活自己的,而最清晰的移动互联网商业模式莫过于游戏。HTML5游戏的最大优势就在于,可以跨平台,可以在不同的移动客户端上运行。

5、 经验教训

我们经常说,所有的事情都是看起来容易做起来难,但这不应该成为我们没做好一件事情的理由。这次比赛中的亮点不少,但是经验和教训也一样很多,将之罗列出来以自勉。

a. 报名平台。对于一个偏技术的活动,新浪微博可能并不是最佳的平台,抢座网相比之下要好很多,如果条件允许的话,做一个自己的活动报名网站更理想。

b. 宣传渠道。之前太过侧重网络宣传,而从这次的比赛来看,借助各种与比赛目标人群相吻合的线下活动进行宣传,可能带来意想不到的宣传效果。

c. 评审环节。对于一些Cloud Jam的参赛者而言,33小时开发出作品可能不是很难,但是要在5分钟内清晰地讲解、演示作品就不是那么容易了,以后的活动中应该适度增加讲解时间,并且提前组织参赛者排练讲解环节。

d. 项目太多。应该在比赛开始的阶段,狠心砍掉一些项目,建议参赛者组队来实现完成度更高、价值更高的项目。

6、活动的意义

举办这次Cloud Jam的初衷有两点:一是让大家知道真正适合创业者和中小团队的云计算是什么样子,在比赛的过程中进行体验;二是提供一个让开发者互相认识、交流的平台,一个面对面交流的机会,如果能够找到未来创业路上的同伴则是再好不过了。

从结果来看,这两个目的都达到了,这就是这次活动的意义。

好奇怪的一个标题啊?事情是这样的,几个月前,我进行了一次工位的调整。在这个过程中,遇到了一些不是很爽的事情,虽然过去了这么长的时间,但每次想起还是觉得不爽。最近看了很多的产品,感觉有些很有趣,也有些看起来很不爽。看着看着,就想起了我那次不爽的工位搬迁经历了,并在其中找到了一些共通之处,在这里写一写。另外,可能和某些社会现象也有一些共通之处,如果有人看到了,觉得有所触发,那么很好;如果有些人看到了这篇文章,觉得不爽,那么只能说:如有雷同,纯属偶然。

首先还是先来介绍一下事情的经过吧。

几个月前,被通知需要调整工位,在大公司里面这是很正常的事情,长期不动地方,说明公司缺乏活力。好了扯远了,我接到了通知,于是就进行了搬迁。但是调整之后,却发现,我的分机号码变了。办公室购买的是昂贵的avaya IP电话机,电话号码是跟着电话走的,只要把电话从这边网线上拔下来,到那边插上,号码是不会变化的。但是在搬迁了工位之后,却被告知,我一定要更换一个分机号码,感觉非常的不解、不爽。

我已经将这个分机号码印在了名片上,印着原来那个分机号码的名片已经发掉了一盒,还剩下一盒。我还将这个分机号码标注在了我的邮件签名里面,应该也发出了几百上千封的邮件了吧。在我将那么多带有分机号码的邮件和名片发放出去之后,在保留分机号码那么方便的情况下,为什么一定要挑换呢?由于工作的需要,我们需要挑换工位,这没有问题。外面那些需要联系我的人,并不知道我的工位在什么地方的,但是分机号码就完全是另外一个问题了。需要联系我的人,是需要打那个分机来找到我的。

我感觉非常不爽,于是我就去抗争了。我先找到了行政人员,行政人员告诉我,这是IT部门的规定,于是我就又找到了IT人员,他们一开始告诉我,为了他们自己管理方便,所以才这么规定的。然后,我说,现在的设备,只要每个人抱着自己的电话机换工位,就不会有问题了啊,不会有任何不方便的地方啊?然后,IT人员又告诉我,这个规则是以前在行政岗位上的一个人,和他们一起商量确定的,就一直这么执行下来了。然后,我又找到了以前的那位行政人员,她告诉我说,她也没有此类的经验,这个规则是在办公室装修,设备还没有采购回来之前制定的,她也不了解现在话机的功能。而且,她已经离开了原来的岗位,如果其他人发现现在情况变化了,完全可以进行调整啊。最终,IT和行政人员还是在我的抗争下屈服了。但是,只有我一个人得以保留了原来的分机号,其他参与那次工位调整的同事,都换了新的分机号。以后再有调整工位的同事,我没有询问他们的情况,估计那个莫名其妙的规定应该还在执行着吧。也许部分去抗争了的人,能够保留自己的分机号码吧。

故事有些绕,但基本就是这样的了。在这个事情中,有人有错误吗?有那种需要承担责任的错误吗?应该说没有,但又应该说所有参与这个事情的人,都有一定的责任。

现在的行政人员,在发现情况发生了变化的时候,为什么没有去调整政策呢?也许他们以前并没有发现情况发生了变化,但是在有人抱怨了之后,他们选择了维护那个谁也搞不清怎么回事的规定继续运行下去,当有人来抗争的时候,就小范围的调整一下,息事宁人之后,继续保持原有政策的运行。

制定这个规则的时候,首先应该考虑的肯定是办公方便,业务方便。毕竟大家坐在这里是为了做事情,做业务的,那些管理部门存在的原因是维持业务的运转。而不是反过来,我们所有人坐在这里是为了被管理的。这里并不是要求完全不顾管理难度,一味的追求业务方便。而是应该达到一个平衡,在管理服务能够支撑的范围内,最大限度的为业务提供方便。至少在这一条规则的制定上,考虑管理方便的因素就大大的超越了业务方便。我以前的公司,换座位的时候,就会去调整程控交换机,最大限度的保证业务的连贯性。而在这里,在设备升级换代,大家只要抱着电话换工位,就可以达到不换分机号的情况下,制定规则的人,已经完全忘记了他们存在的意义是服务于业务,而是将自己摆在了一个管理者的位置上,为了管理方便而牺牲业务连贯性的需求。而且制定这个规则的时候,当时的行政人员没有经验,但是IT人员却是一个老IT了,他不可能没有相关经验的。

这里不是写批判文章。让我们看看在产品开发过程中是不是也会出现类似的问题呢?

一个产品的设计,目的肯定是要解决用户的一些需求。然后,还会有很多其他需求,比如做产品的人需要吃饭,需要有下载量,需要有点击数。需要用户支付等等。这就是其实也是一个平衡。前面的人可能还在做平衡,当团队大了之后,是不是会有人为了盲目的维护原来的一些策略,而放弃用户需求呢?会不会有人将产品本身的生存需求,放到了比用户需求更高的位置上了呢?

一个产品,其实有两块需求,用户需求和产品生存发展本身的需求。这就像是刚才说的例子一样,应该在保持产品生存和发展的条件下,尽最大可能的去满足用户的需求。而且,应该在做出每一个判断的时候,进行每一项功能取舍的时候,都从这个最原始的出发点来考虑问题。时时刻刻的反省,是不是条件发生了变化,在新的条件下,是不是应该调整原来设定的一些策略?

先举几个例子吧。

第一,原来一个sns网站,开放了API,让其他人在上面做游戏。他们看到那些用户做了游戏,赚到了钱,于是他们自己也开发游戏。然后,他们发现自己开发的游戏,没有用户开发出来的同类游戏赚钱,于是他们封闭了同类的游戏。后来,他们发现好像还是不怎么赚钱,于是他们就再去抄袭另外一个他们认为赚钱的游戏。周而复始,很快他们的平台上就没有人在上面开发游戏了。

第二,另外一个sns项目,运营的人发现互动太少,里面的游戏没有什么人玩儿,于是就不断的发大量的游戏信息出来,并且不断的提醒用户你的好友在邀请你玩儿什么什么游戏。很快这个平台上面的信息流就被游戏信息给淹没了,用户也快速的流失掉了。

第三,一些做电子阅读器的人,为了能够让用户购买他们的阅读器设备,不在客户端软件上放置阅读功能。他们担心如果用户在pc端软件上阅读了,就不会再购买阅读器了。其实他们要解决的问题不是买阅读器,而是让用户在任何时间和环境下都可以阅读。后来他们还是推出了一个单独的pc端阅读器软件,生生的将用户割裂开来。

第四,一个用户多媒体内容分享和传播的应用,在用户希望进行微博分享的时候,为了迫使用户点击微博中的链接,故意将某些内容截留下来,最终阻碍了用户希望信息得到传播这个需求的满足。发出去的微博本身的感染力也下降了,被转发和引起互动的能力下降。

上面都是一些反例,也有做得很好的。

第一,facebook为了保证用户收到信息的质量,限制了广告。

第二,google将广告放在搜索结果的外面,决不让广告污染搜索结果。

第三,一些轻博客网站,在分享内容到微博的时候,会按照最有吸引力和表现力的方式来摆放图片,从而提升微博的传播力。只有在需要的时候,才放链接进去,比如内容超过了微博允许的范围的时候才放链接,其他时候就不放链接。

关于如何区分不同的需求之间的平衡性的问题,故事讲了,道理也讲了。

下面讲另外一些故事。

当项目中发生争执的时候,经常会听到这样的话。这个事情是以前就是这么定下来的(虽然我说不清为什么),所以就是不能改。当有人要求修改的时候,,他会告诉你,以前出过故事的,你会比以前那些人更加了解情况吗?你会比以前那些人更聪明吗?而这个时候,以前那些人往往已经身居高位了。这就像上面那些人做得事情一样,规则有了,虽然我们搞不清当初为什么制定这个规则,那么好吧,让我们将这个规则执行下去吧。

不记得是在哪篇古文里面看到过这么一句话:上胡不法先王之法。意思就是说,国君为什么不取法古代帝王的法今制度呢? 以前旧的规则,肯定是会有人去维护的,有些人是从自身利益出发,或者经过反复思量之后决定保留那些古法的。但是也总是有些人,会无条件的遵循固有的东西。并不是说打破古法就是对的,而是说一定要经过自己的思考,再决定是不是要执行还是改变固有的规则。

现在是互联网时代,各个团队的发展速度都是很快的。如果一个团队突然成功了,那么这个团队可能还没有来得及去总结到底哪些策略带来了他们的成功,他们所经历过的一切就都会变成先王之法。而很多曾经从不同的侧面了解到这些内容的人们,就会把这当作先王之法认真的执行下去,但这些人又往往是瞎子摸象、管中窥豹。现在流行的一种说法,说某某公司具备或不具备什么什么基因,这些基因就是这么形成的。

复制别人的成功为什么那么难?由此可见一斑。这个法先王之法的现象所造成的另外一个结果就是富不过三代。还有一个典型的例子就是邯郸学步了,现在copy to china蔚然成风,但是又有多少人真的学会了邯郸人走路的姿势了呢?

故事讲得差不多了,希望以后做产品的时候,能够时刻清醒的认识到,到底哪些需求是产品生存的需求,而哪些才是真正的用户需求。时刻注意自省每一个功能或策略到底是在满足用户需求,还是满足产品生存的需求。满足产品生存需求的时候,是否伤害了用户的根本需求。在当前的生存环境下,产品是不是已经最大化的满足了用户的需求,是不是可以做得更好一些。过去制定的各种策略和措施,在当前环境下,是否还适用,是否需要做出调整。如果需要的话,就及时的进行调整。

 

标题里面还有“其他”。那么最后讲一点点其他吧。涉及这个话题的社会现象通常都比较敏感,这里就讲一个比较不那么敏感的。

我们的手机号码是属于移动运营商的,不属于我们这些出钱的人。我们不能将号码从一个运营商转到另外一个,这就是一个典型的产品生存需求侵占用户需求的案例。当然,这还不算过分的,我们在同一个运营商那里,不可以将一个地区的号码迁移到另外一个地区去,这是一个典型的法先王之法的案例,以前由于计算能力有限,对号码进行了分地区的限定,为每个地区分配号段,现在技术进步了,计算机的运算能力增强了,既然我们能够实现手机的漫游,那么为什么不能实现跨地域的手机号码迁移呢?最后一个案例,是这两种弊端的结合,我们没法使用一个传统2G的号码,在同一个城市的同一个运营商那里开通3G服务。如果要使用3G号码,就必须要换一个3G的号码。这是当前技术无法解决的问题吗?很显然不是,那么为什么要这样做呢?理由很可笑,第一、以前就是这么干得,第二、这样可以发放出更多的3G号段的号码。

这个“其他”肯定还包含很多很多社会上的东西。这里就不列举了。我上面的那个亲身经历的故事里面,肯定还有很多其他有趣的东西值得挖掘,比如当发现问题的时候,私下向喊得最大声的那个低头,将事态控制在最小范围,维持大范围的稳定等等。以后有空再拿出来写吧。

活动日记——IT龙门阵

2012年的3月20日,是IT龙门阵第一次走进盛大创新院。也是IT龙门阵的技术专场的第一次活动。这期活动,演讲的嘉宾,分别是来自盛大多媒体创新院,负责人脸识别技术开发以及应用的单霆先生和来自腾讯研究院的负责手机人机交互方面研究的陈波女士。这一期活动的主题,是移动终端上多媒体模式识别技术的应用。

IMG_9286在开始之前,主办方先请单霆先生和陈波女士这两位来自不同公司的多媒体模式识别和人机交互方面的专家,做了一个小范围的沟通会。他们交流了一下各自在这个领域中的一些经历和看法。

这次的活动还是吸引到了不少专业技术人员的参与。IT龙门阵已经很久没有做过这么技术的话题了,平时很多都是媒体方面的人来听一听各个公司的大佬们来讲故事。据说还有人是专门从南京过来这边参加活动的。我在现场还碰到了专门赶过来的天津大学老师。看来纯正的技术话题,对专业人士的吸引力还是很大的啊。

我作为这次活动的主持人,也是倍感荣幸。可以主持这么专业的技术研讨,感觉压力还是很大的。

IMG_9155

讲演过程中,单霆先生回顾了他的创业经历,他很早就开始从事人脸识别技术在应用方面的尝试,以及投资界对于这个领域是多么的热切。然后又讲解了人脸识别的具体算法和这些算法的演进历史。很遗憾,算法的这一部分我没怎么听懂,这 一部分的内容确实有太专业了。不过看样子其他的那些听众还是听得很有感觉的。希望他们能够从中有所收益吧。IMG_9192

单霆先生在讲完了技术之后,还介绍了两个应用人脸识别的技术的产品。其中F ace-API是比较有趣的,直接将人脸识别技术封装成API放在云端,提供给那些想要使用这个技术的团队或个人使用。现场就有不少听众找他们要邀请码,希望进行尝试。

在正式的IT龙门阵活动之前的小范围沟通交流会上了解到,腾讯的陈波女士和他们的团队,也已经申请了Face-API的试用邀请码,并在Face-API的即时通讯群组中潜伏一段时间了,当天其实是单霆和陈波以及腾讯研究院的这个团队里面的一些成员的第一次线下网友见面,这个圈子看来还真是小啊。

陈波的演讲范畴要更加宽泛一些,包含多媒体模式识别和人机交互的很多领域。这位腾讯研究院的美女专家,首先纠正了大家的一个误解,她说腾讯现在已经改变了很多,现在腾讯已经是一家非常开放的公司了,愿意开放出很多的资源和数据,和大家一起创造财富。以前创业者总是担心会遭到腾讯同类产品的竞争,现在这种状况已经发生了变化,腾讯正在逐渐向着开发者和创业者的朋友的方向转变。IMG_9216

在陈波的演讲中,介绍了模式 识别和人机交互的发展历程,以及腾讯在这方面的一些尝试。她反复的强调,很多人现在对于模式识别的应用抱有过高的期望,这是不正确的。模式识别技术,还远远没有达到能够让计算机或智能设备达到人类识别事物的能力,在短期内,这还是很难实现的。但是,现在,特别是元计算的到来,为模式识别带来了重大的发展和机遇。使用现有的技术,已经可以做出很多有趣的,改变人们生活的应用了。腾讯利用这些技术,实现了手写和语音的输入,并通过图像识别技术,开发出了QQ慧眼这种有趣的产品。这个产品可以让人们在旅游的时候,看懂外文的路牌。QQ慧眼就是陈波女士的团队自主开发的。他们还有很多技术,被应用到了腾讯的其他产品之中。腾讯也会逐步的将这些技术,开放出来供更多的开发者使用。

两位专家结束了演讲之后,会场上的听众们向他们提了不少问题。这里面有些非常专业的技术问题,更多的则是现有技术的一些应用前景相关的问题。过程非常热烈,由此可见,大家对于多媒体模式识别技术在移动互联网领域的应用还都是非常感兴趣的。

最后单霆先生做的总结是:多媒体模式识别技术,可以是人机交互摆脱语言和文字的束缚,重新回归的更加贴近自然的状态。这就是在这个领域里面努力着的人们的共同目标。

IT龙门阵下一场的技术活动还在规划之中,现实增强、虚拟现实,或者云计算等主题,还没有确定下来。请大家拭目以待吧。

个人信誉追踪系统

好像有很长一段时间没有更新博客了。

最近在忙着一些社区活动的事情。后面的社区活动会越来越多。而且,周末时间还需要陪儿子玩耍,是不是能够抽出时间来写博客,还不一定。抽空写吧。

今天下午有PMI项目管理俱乐部的活动,上午就跑来办公室,趁着这一点点的时间,写一些吧。

最近组织、协办、参加了一些社区活动。也有了一些想法。现在先来写其中的一个。

 

所有公司里面和宣传,公共关系相关的部门,都刚刚度过了我们一年之中最重大的一个节日,这个节日是所有做公关的人都是又狠又爱的,那就是315。所有的中国公司,对于315这种东西的心态都是非常矛盾的。既希望315能够搞定竞争对手,同时也害怕315找上自己。这就体现了一个问题,所有公司都知道自己在诚信方面有所亏欠,但又都寄希望与老天睁一只眼闭一只眼放过自己,或者想着,我们只是为了一些小恶,社会上比我们罪大恶极的家伙多去了。这次不会轮到我头上的。

315也算是一个大话题了,这里要阐述的是另外一种比较小的诚信问题。那就是个人诚信、个人信誉。

诚信问题,分为很多方面。特别是有一些银行方面的信息,属于个人隐私,是不适合进行公开的。所以我所设想的个人信誉追踪系统,所追踪的也仅仅只能是个人或一些机构发表的公共言论,以及向公众所表达的一些观点的追踪和回溯。机构可以通过换人来快速的改变其信誉,但是个人不论走到什么地方,其信誉状况应该是不会发生跳跃性的变化的。所以我感觉,个人要比机构的信誉状况更加值得追踪。

记得很早以前在电视上看过一位大神级人物,讲解什么是诚信,那位大神讲道:为了远期利益,而放弃近期利益的方式,就是诚信了。诚信归根结底还是为了利益,并不是为了什么道德或真理、正义之类的东西。现在,很多的专家、学着、名人,在利用他们的声望,说着或做着一些事情,即使事后被证明了,这些事情可能有问题,他们也会放出,人总是要犯错误的之类的言语,来为自己辩解。甚至还有些可笑的人,做了不诚信的事情之后,堂而皇之的说,这是在牺牲小我,成就大我;牺牲个人荣誉,成就更大的利益。

这是为什么呢?为什么我们感觉有越来越多的个人或机构,变得不诚信了呢?我们无法相信社会,无法相信专家,无法相信其他的那些机构或管理者呢?当然,信任都是相互的,我们不信任别人,也不指望别人相信我们。归根结底,不诚信的成本太低了。诚信是为了远期利益,而牺牲近期利益的行为。那么不诚信就应该是不顾远期利益,而争取近期利益。但是如果人们在不择手段的获得近期利益的时候,对其远期利益基本没有损害,甚至还有所帮助,那么就不会有人选择去遵守诚信了。因为那是非常不划算的一件事情。

社会为什么需要诚信,这里就不讲了,相信大多数人都非常清楚。那么我们怎么得到一个诚信的社会呢?大的方面肯定轮不到我在这里胡说,那是党和政府考虑的事情。我们只能从一些小处着手,增加一部分人不诚信行为的成本。

我的想法是,建立一个跨平台的网络应用,能够让所有的用户讲他们看到、听到的事情记录下来。然后利用语义分析工具和人脸识别技术、声纹和语音识别等技术,对这些凌乱的信息进行整理,将信息以人为单位,以时间为顺序,进行归并。系统仅分析和记录那些公众场合发表的信息,图片、视频和语音信息,用户可以从各种新闻媒介摘要上传信息到系统中来。

对于一个事件,在系统的数据模型上,会形成一个节点。各个专家和学着、机构对于这个事件的观点会汇集在一起。系统可以自动的筛选出一些对于这个事件比较热心的用户来维护这个节点。并使其具备比较高的可读性。以方便其他用户的阅读并进一步的补充内容进来。用户可以在不同的时间段,对同一个事件,同一个人在这个事件中所起到的作用进行评判。社会大众在不同的阶段,对于同一个事情有不同的看法也是正常的,毕竟通常是需要日久见人心的。

人们也可以自己去上传一些自己的事件。大家可以去纠正那些错误的信息,这需要共识,然后找到一些共同关心这个事件的用户认可之后,才可以进行修正。被修正的内容,也不会被删除,而会作为被证实是虚假的信息,存放在系统中,用户仍然能够看到。

这个系统会通过众包的形式,搜集社会新闻媒体上面的公开新闻,然后让人们在不同的时期对新闻人物在新闻事件中所起到的作用进行评判。当事件随着时间的发展,前面那些人所说过的话,发表的意见,做过的事情,旁观者可能会给出不同的评价。这个系统存在的目的,就是为了让大家记住。记住那些人,在过去的那些事情上都做过些什么,让这些人的远期利益和他们现在的一些作为挂钩,让他们在做事情的时候,能够有所顾忌。让那些有信誉的人,能够享受他们牺牲掉近期利益所博得的远期利益,让那些没有信誉的人,在远期利益上能够受到相应的损失。

这个系统,是很理想化的,是否可行,是否有可能在现在的社会形态下出现,这都很难说。至少从技术上,是没有任何问题的。现在的微博数据,就完全可以支撑这种系统的运转。但是微博做得是严格的恪守时间线,如果出现了什么不好的事情,就可以通过另外的一些更加热点的事情,来增快用户遗忘的速度。只要将吸引力转移了,大家很快就会将事情忘掉的。当然也有一些认真的人,喜欢抓住别人的小辫子不放,比如方舟子之流。

我所设想的这个系统,就是希望能够有更多的人,能够通过系统来部分的实现方舟子那种很有研究能力的人才能实现的事情。方舟子在打假的时候,还是很有选择性的,这没有什么可批评的,毕竟他也要在这个社会下生存的。有了一套系统之后,大家通过众包的方式来搜集信息,搜集信息的时候,可以使用实名用户或匿名用户提交的信息,但信息必须是在公共媒体上发表的内容,或者是实名用户自己相关的内容。这样的话,那些提供信息的人们也就没有什么风险了。很多考证的事情,可以等到信息搜集起来之后再说,具体是采用人肉的方式,还是计算机算法,或者最有可能的是计算机算法和人肉相结合的方式,都是可以的。

那些曾经不诚信的人,或者是被其他人误解了的人,也可以到系统里面来解释,或者找其他人来帮其证明。

知错能改善莫大焉,总要给大家改过自新的机会。系统存在的目的不是为了让那些不诚信的人永远不溶于社会。而是希望能够起到一个威慑的作用,并能够告诉大家,善有善报恶有恶报。

此类系统到底有没有社会需求,这个事情很难说,但是从商业模式上来说,肯定是比较麻烦的。也许,能够用来作为某些诚信者记录自己工作生活状态的地方吧。最终成为一种媒体。

这个系统,只是我的一个设想,是不是有过类似的东西,本人不考证。设想这个系统的目的就在于:首先将现在发生的事情,记录下来。以后这些内容就是历史,不可磨灭的历史。让后人可以通过这些历史的记录来对参与到现在这些历史事件中的人们进行评判。

LBS应用中的签到到底有什么用

今天下午去参加NTalks的活动,一群人坐在一起聊一个务虚的话题,那就是明年创业到底应该做什么方向。具体的内容,大家去关注NTalks吧,这里就不阐述了。

记得在最后,有一位先生站起来,问了嘉宾一个问题。在LBS中,签到的作用到底是什么呢?现在,一说到LBS,好像就必然有签到的功能。而签到好像也成为了LBS应用的一个标志性功能。但是,签到到底能够为LBS带来些什么,好像谁也说不大清楚。

那位VC嘉宾,作答。他说,他也曾经为此困惑过,于是就跑到foursquire去询问。却被告知,签到对于foursquire的作用很简单,就是快速的矫正POI。签到本身并不重要,重要的是持续的低成本保持POI信息库的及时性和准确性。

那位提问的先生还在不断的表述,签到是多么的有趣,大家如何比赛,如何在twitter上建立四方党,然后互相比较签到的次数,互相炫耀通过签到所得到的荣耀等等。

由此可见,签到并不应该成为LBS的标志性,甚至核心性的功能。但是通过增加游戏性,甚至直接通过一种签到游戏,来低成本的,依靠众包的方式建立其POI信息库,这是一件非常有趣的事情。对于LBS应用来说,不断的更新和矫正POI信息库,无疑是最重要的。国内的项目,当然可以用签到的方式来达到这个目的,但也可以想出一些其他的,更有趣的方式,来实现这个目的。重要的在于游戏性,而不是签到本身。通过在更新和矫正POI信息库的这个众包过程中加强游戏性,来调动用户的积极性,使得他们愿意参与到这个过程中来,不厌其烦的,一次又一次的提交POI信息数据,这才是最重要的事情。

国内的LBS应用,多是采用爬取或购买的方式,来实现初始POI信息库的构建。然后问题就出现了,用户矫正的信息,是否应该快速的替换和矫正那些购买到的信息呢?换种中国人比较容易接收的说法,是不是要用免费得来的信息,去替换那些花钱买来的信息呢?由于数据分析和过滤的能力不强,所以在取舍的时候,大家都很纠结。到底是相信用户的数据,还是相信买回来的数据?

记得以前使用切客的时候,由于POI推荐算法极烂,基本上当前所在的位置,很难出现在第一屏的推荐列表里面,于是大家就都喜欢开荒,最终的结果就是,对于一个poi,会有很多很多的地名指向它。

总之:去重、搜索、过滤和推荐,应该是维护POI信息库的最基础算法了。如果这些算法最终无法达到比较好的用户体验,那么设计再有趣的游戏,意义也不是很大。当能够满足基本需求的时候,就需要设计一些有趣的,游戏性极强的方式,来调动用户的积极性,维护和更新POI信息库。

对于国内的LBS应用来说,首先应该注重服务本身,也就是Service。在服务的体验能够让用户满意的情况下,再想办法设计一些小游戏,让用户帮忙提交POI信息。从重要程度上来分析,第一重要的是服务本身,然后是服务的体验,再然后,才是如何增加用户使用过程中的游戏性,使得用户能够主动的参与到POI搜集和维护的行列中来。签到,仅仅是这其中的一种形式而已。

关于RSS系统

RSS阅读,对于我们这些人来说肯定是一天都离不开的,但其实这也是一个小众应用。
我个人对于RSS阅读的需求是这样的:

  • 多平台的书签同步,标记那些读过,哪些未读。
  • 不论源提供的是什么样的,所有的内容都分为标题、简介和全文三种状态,也就是说对于那些不提供简介的,要自动生成简介,对于那些不提供全文的要自动提供全文。
  • 移动端的图片,进行预先的处理,下载的内容预先压缩,比如生成类似于epub的格式。
  • 自动去重,如果我订阅的各个源之间,都报道了同一事件,那么就要去除重复的内容。
  • 智能内容推荐,推荐那些热门的内容,推荐那些我好友关注的内容,推荐那些有趣的,新的源。
  • 智能过滤,当我的时间比较紧张的时候,按照优先级和重要度,筛选比较重要的内容发给我。
  • 提醒,当某些特殊事件发生时,主动的提醒我。
  • 归纳总结,定期,比如一天、一周、一个月,出一份总结性的杂志。可以离线阅读。
  • 分享和关注,分享我的阅读体验,关注我好友的阅读过程
  • 将所有源的所有内容,按照类别进行分类、去重,然后按照类别进行阅读

我目前主要在使用Google Reader,IOS端使用的是Reeder。主要的功能是可以满足的。但是Google Reader是按照时间和源为基础来管理内容的。我希望能够安装状态和优先级、类型来进行组织和排列。

希望能够有跨平台的RSS离线阅读工具。
较为重度的RSS阅读者,对RSS阅读提出的想法。

关于排队系统

现在有各种各样的稀缺资源,比如说高峰时间的餐位。那么就需要排队系统。来帮助用户和商家进行双向选择,以实现各种稀缺资源有序的分配。

现在有很多预约系统来解决这种问题。

但是,商家所需要的其实并不是简单的预约系统,而是解决两个问题:
第一、削峰填谷
第二、有效的选择客户
第三、降低赚取同样资金所消耗的时间和其他相关成本
削峰填谷自不必说,高峰时期接待能力是有限的,商家肯定希望在低谷时期能够多有一些人来消费服务。

下一件事情也就显而易见了。既然在高峰时期,服务接待能力是有限的,那么就需要选择用户了,让有限的资源尽可能为更合适的用户服务,以便赚取更多的利润。目前商家通常是通过三种形式来选择客户的:

  1. 熟客,熟客肯定是需要优先服务的,即使为了他们牺牲一部分服务时间,只要是预约,那么就必须让服务资源空闲下来,在外面有人排队的情况下,等待预约的客人。这是不划算的,但是熟客的预约在使商家承受这种损失的同时,达到了广告的效果,可以让熟客的忠诚度和黏着度进一步提高,因为熟客享受到了特殊的服务,在别人排队的时候他先进去享受服务了,这是一种身份的尊崇,也是商家提高自身地位的一种手段。这是一种榜样的力量,可以促使其他用户成为熟客。最后,熟客还会经常在非高峰时段过来消费,这也可以弥补一定的损失。
  2. 有偿预约,上面说了,空出服务资源来等待预约的客人,这本身是有成本的。那么如果客人愿意支付这个成本,空着也就空着了。
  3. 客户选择,单位时间内并不是接待的客户越多,就越赚钱。每个客人的消费能力不同。所以,应该是在单位时间内,接待的消费能力高的客户越多,就越赚钱。商家总是在想方设法的选择那些消费能力更强的客户,比如在高峰时段提高价格,比如为预约的客户设定消费下限,等等。

在高峰时段,如果已经选择好了客户,那么还能做的最后一件事情就是尽量降低为这些客户服务的时间和其他成本。这个放在饭店里面来说,叫做翻台。也就是一桌客人吃完了,将桌子清理干净,再请下一桌客人用餐。提高翻台率就是各个饭店在高峰时段所期待的东西。饭店通常是通过推荐推荐当日特色菜,建议用户点选某些可以快速烹调的食物,在高峰时段不为那些非预约的用户提供那些难以在短期内完成的食物,比如正宗的佛跳墙,等手段来实现这个目标的。

推荐的特色菜,通常是需要较长时间烹饪的,饭店会统一准备好一大批成品或半成品,然后希望用户尽量集中的点选这些食物,以缩短服务时间。另外一个饭店里面经常采用的方法,就是让用户在等位的时候,完成点菜,甚至是付款,这样也可以有效的缩短每一桌客人的服务时间。
预约服务,其现金流通常是来自于商家。所能够为商家提供的服务,分为三个层次。
最低层次、帮助那些即使在高峰时段也没有用户登门的商家做广告,告诉用户周六的午餐,旁边那家不需要排队。
中间层次、帮助商家向用户收取有偿预约的费用,最后和商家进行分成。不过这个盈利方式有违目前的消费习惯,很难大范围的推广。
最高层次、帮助商家筛选客户,将消费能力高的客户筛选出来,并帮助商家培养忠实的熟客。引导客户在非高峰时段,享受一些高峰时段难以享受到的服务。

附加的服务,则是帮助商家向用户推荐商家希望推荐的某些特定服务,帮助用户在预约的时候,就直接将各种所需的服务做好选择。

这里只说了为商家服务,却没有提到为客户服务。这是从现金流的角度出发的。这是属于矛盾的两个方面,如果一个服务和应用,没有用户来用,那么对于商家来说也就是没有意义的。为用户提供准确的信息,做出能够实现的承诺,完成用户所需的服务,这是必不可少的。但设计的初衷,还是应该为商家服务。因为,预约服务,都是在消费高峰期才需要的,而消费高峰期的时候,通常是卖方市场,首先是商家挑选用户,然后才是用户的双向选择。

希望能够有一个非常棒的预约服务,来帮助我选择中午去什么地方吃饭。

帮助人们实现梦想的系统

前文已经写了很多内容,那里面其实已经将系统的结构和工作方式都讲过一些了,但是这里还是想再将这两个部分分拆开来,分别讲述一下。

本文主要是想要讲解帮助人们实现梦想的系统,可能会拥有哪些模块,哪些参与者,以及这些模块和参与者之间是如何在系统中进行互动的。

本文包含的内容,应该会比use case稍微丰富一些吧。

以后应该还会找时间再写一写这个系统的开发、发布和运营的步骤,也就是说如何一步一步的开发并推广这个系统。

1 系统结构

1.1 梦想故事展示

这应该是一个用于展示梦想和成功故事的portal类网站,依靠SEO,吸引那些有梦想或对相关主题感兴趣的人们,进入系统。

1.2 计划的录入

用户可以自己编制并录入一个计划,也可以是一些专门提供计划协助的个人或机构,提供相关的计划。

同一个项目,可以有很多并列的计划被录入进来,比如学习英语,会根据目的、时间、地域等条件进行细分。每一个细分,也都可以有很多不同的协助者,提供不同的计划。

用户可以将自己执行成功的计划,也分享出来,供其他人尝试。

1.3 测评系统

系统提供用户测评的功能,并能够帮助用户了解其自身在某一特定领域的知识或技巧掌握的程度。系统可以允许那些提供计划辅助的个人或机构,根据格式要求,录入新的测评项目和题目。测评的结果,可以是系统自动评定,也可以由特定的测评人给出主观评定。

测评系统仅仅是提供一个测评的规则体系平台。

1.4 计划的搜索和推荐

当用户有了某方面的梦想或对某些梦想感兴趣之后,系统会根据梦想的描述,给出实现该梦想的计划列表,并在列表中对提供计划辅助的个人或机构进行筛选、排序和推荐。

1.5 计划任务系统

根据用户的生活、工作情况,根据附近计划协助个人或机构的服务能力和排期,根据用户所选择的计划,进行细节调整。并确定最终要执行的计划。

监督用户执行计划,询问用户计划执行过程中的反馈,并根据反馈,必要的时候,在计划协助个人或机构的协助下,调整后续计划。

1.6 Social分享

根据用户的设定,将计划执行过程中的信息,分享到social network中去。

2 相关的人和角色

2.1 提供计划的人

提供计划的人,也就是上面所说到的计划的协助个人或机构,比如培训机构、健身教练等。他们将是这个系统的受益人。

2.1.1 提供计划

提供计划的人,要做的第一件事情,就是提供计划。一个驾校可以培养驾驶员,那么他们就需要录入一些培训计划。比如多长时间,多少钱,在什么地方培训,培训的相关条件,自己的资质,历年的通过率等等信息,以便用户进行挑选。

2.1.2 辅助用户执行计划

在线上或线下协助用户完成计划。比如培训或训练等等。

2.1.3 对用户在执行计划中的成就进行评定

录入评测系统中的评测项目和评测题目,评测方法。让用户可以自主或在协助下进行评测,衡量自己在某一个领域的知识、技能或体能等其他可以进行评测的项目的水准。

某些评测也可以在线下进行,然后将成绩记录到系统中也是可以的。比如驾校的交规是可以进行线上模拟的,而真正的交规考试、桩考和路考则必须是在系统外进行的,然后登记成绩。

2.1.4 提供成功故事

提供一些成功故事,以便在用户选择的时候提高被选中的机会。

2.2 浏览和讨论梦想故事的人

总有一些好事者,是会跑来看热闹的,看看有什么有趣的东西。他们不会很深入的参与到系统中去,但他们也是有可能转换成用户或计划提供者的,虽然转换率可能会低得惊人。系统的一些PV、IP、广告栏位价格等,可能也需要靠这些人来冲击。

2.2.1 通过SEO或Social Network进入

这些人通常是通过搜索或社交网络上相关的信息,进入系统的。所以系统的SEO和Social Network分享做得好不好,就是能够吸引到多少路人甲的根本了。

2.2.2 浏览梦想故事

这些人可能会浏览梦想故事,评论梦想故事,并根据系统的格式要求记录自己的梦想故事,然后再分享出去。

当某些梦想故事非常吸引人的时候,这些路人甲也可能订阅这些故事,时刻跟踪故事的最新进展,比如美国的地狱厨房和减肥达人等真人秀节目,其实就是这种可以被订阅的故事。

2.2.3 用户转化

如果这些人受到梦想、成功故事的感召,也想要实现一个什么计划。这个时候,就需要录入详细的身份信息,完成注册的过程,成为一个用户。

当路人甲也希望能够录入一个计划,并协助其他人来经过这个计划实现某种梦想的时候,这些人就会转化为一个计划录入者。

2.3 用户

大多数系统总是喜欢将那些支撑整个系统运行、支付费用的家伙,叫做用户。系统设计的目的,就是为了这些用户服务的,再决定功能的取舍时,唯一需要考虑的问题,就是这个功能是不是用户的根本需求,或这个需求是否会影响到用户的最终体验。

这是一个帮助其他人实现梦想的系统,那么用户自然就是那些有梦想,并愿意在系统的协助下实现梦想的人们了。

2.3.1 搜索相关的计划

用户会提出一些梦想,也就是搜索一些计划。系统会根据用户的梦想,向他们推荐一些可供选择的计划。

2.3.2 选择并调整计划

选择了计划之后,下一件事情就是需要根据用户和计划协助个人或机构的安排,进行计划细节的调整了。比如用户某一个阶段比较忙,或者身体状态不是很好,那么就需要进行调整。并不是所有的计划都需要其他人的协助,可能大部分计划都是用户自己就可以自主完成的。但是那些需要其他人协助的计划中,计划协助个人或者机构作为任务系统中的一种资源,肯定不可能是无限的。比如羽毛球教练、场地就需要进行事先的预定。驾校里面的师傅和教练车肯定也是有承载限制的。

系统在这个时候就要协助用户调整计划。并最终确定下来计划的各个细节。比如:学习驾驶需要非连续的40天时间,系统会帮助用户和驾校协调具体是从什么时候开始的哪40天时间里,来完成这个训练。

2.3.3 执行计划

这部分应该和传统的任务系统基本是一致的,提醒用户按照计划进行执行。询问用户或计划辅助个人或机构,用户执行计划的情况。

和普通任务系统不同的地方在于,普通任务系统如果发现任务的执行情况和计划不符,则会自动对计划进行调整,任务系统的管理者会在他认为必要的时候,主动的去修改后续计划。而这个系统里面没有管理者,所以系统就会根据计划执行的情况,询问用户和计划辅助个人或机构,是否需要调整后续计划。用户和计划辅助个人或机构会在协商之后,对计划后面的部分进行得到双方确认的调整。

2.3.4 参加测评

用户有了梦想,在选择计划,选择计划的不同阶段(比如围棋初级、中级、高级班),选择不同的服务商的过程中,计划执行的过程中,或计划结束的时候,都需要对自己的水准进行评测。以便准确的掌握自己在梦想之路上的具体位置。

2.3.5 向协助者支付费用

这个系统的现金流应该有两个源头:

第一个是辅助性质的,也就是广告收入。帮助那些提供培训服务的机构和个人,宣传他们的计划。广告和搜索推荐算法是绝对隔离的,不会出现广告影响推荐结果的情况。因为那并不符合用户的需求,会降低用户的使用体验。

第二个,也是支撑这个系统运转的根本将是用户向提供培训服务的机构或个人支付的费用。系统将从这个费用中进行非常低比例的抽成。

为了避免线下交易,必须是完成线上交易的用户才能对培训机构进行点评,而这个点评的结果将计入推荐算法,影响推荐算法上面的排名。

这个系统中的计划,大部分应该是免费的,是不需要用户支付费用的,也没有专人在计划执行的过程中提供很多的线上或线下的辅助。那些培训机构也可以提供以培训视频和自主测评为基础的免费培训计划。也可以在培训过程中提供一些纸质书籍或材料,通过培训课程在线上销售这些培训资料。

对于那些需要辅助人员参与的,需要付费的培训课程,也可以提供一些免费的试用体验课程。体验课程可以是视频教学,也可以是定期的线下示范课。

计划的辅助个人或机构,可以通过线上或线下的方式,为用户提供培训或教育。并通过测评的结果,来评定培训的成果。

计划的付费可以分为几个类型:

  • 完全免费的线上学习,可以使用一些智能程序来进行线上辅助,也可以辅以很少量的线上专人辅助。
  • 少量付费,有专门线下资料的培训,辅以大量的线上资源和线上专人通过IM或VoiP、视频通话等方式提供的辅助。
  • 适中付费的线上专人课程。
  • 较高付费的线下课程和活动。

几种方式可以结合进行,比如先进行完全免费的试用和体验,然后根据用户的要求对几种课程进行调配。

2.3.6 将计划执行过程中的成就分享到Social Network

用户可以设定,将计划执行过程中的信息,分享到那些Social Network上面去。系统会在用户完成某一阶段的计划之后,或参加了某些测评之后,提示用户进行分享。

2.3.7 横向的比较,得到更多的成就感和游戏性

学车的时候,是有师兄弟的。在学习过程中,在Social关系谱中,在同一个计划的同学中、在同类计划、同地域的学习者中,就可以进行比较。比如某某人时在学开车过程中,某某地区、某某驾校,或亲朋好友之中,是学习倒库速度最快的一个家伙。可以将不同时间段学习同一个课程的人放在一起比较,也可以将不同地区的人放在一起进行比较。

总之是希望增加用户在执行计划,实现梦想过程中的成就感和游戏性。从而促进用户更好的实现梦想。

系统可以组织类似于地狱厨房或减肥达人那样的淘汰赛事,从而实现更加彻底的游戏性。

2.3.8 完成计划,并将过程自动汇总到梦想故事中

在计划完成之后,系统会自动的将用户实现梦想的过程汇集成梦想故事。并在用户允许的情况下,发送给用户指定的人群。系统可以将故事按照不同的详细程度公布在梦想故事的模块中,比如完整的故事,或去掉名字的完整故事,或仅仅是成为某个培训机构的一个统计数字。

2.3.9 用户和协助其完成计划的个人或机构,进行相互点评

要实现系统的平衡,那么就需要有一套点评系统。用户和培训服务机构之间的双向点评。这些数据将协助双方进一步的进行选择。用户会选择那些优质培训机构,而培训机构也会去优先选择那些优质的,诚信的客户。

3 任务系统中计划的描述方式

3.1 计划就是一个个的状态机

计划将是一种穿插着自我学习、辅助学习和各种测评的状态机。

计划可以是封闭或开放的。所谓封闭计划,就是那种有终点,执行完成之后,进行考核的计划。开放式计划则是没有终点的,可以一直坚持下去,也可以由用户自主的选择放弃执行。

计划可以分层次,可以设定基础计划和后续推荐计划。比如,如果想要学习Android开发,则必须要熟悉Java语言编程。学习过了Android开发之后,还可以推荐一些更进一步的学习计划。

3.2 计划的标定方式

计划可以进行描述和标签标定,这些标签有些是可以量化的,有些则不是。比如下一期还可以接受多少学员,就是一个量化标签,通过率也是量化指标。讲解清晰,资深专家等等就是非量化标签。对于那些非量化的标签,可以通过自评和用户的点评,通过加一减一的方式,来实现量化。然后根据所有量化的指标,在用户搜索计划的时候进行推荐和排序。

4 成功故事的形成

4.1 将用户执行计划过程中的故事,穿插成一个完整的脚本

系统会在用户执行计划的每一个环节,都去鼓励用户保存一些他们的感受。如果他们将这些感受分享到了Social Network上,那么还会自动的收集这些信息在Social Network上所得到的反馈。

系统会自动记录用户计划执行过程中,得到的各种成就。

成功故事就是根据用户在执行计划的过程中保存下来的感受,分享出去得到的反馈,以及执行计划过程中该所得到的各种成就,自动生成的。在生成的过程中,用户可以自己进行加工和调整。成功公式是以脚本的形式来存放的。即使是一篇完整的成功故事也是可以根据脚本重新拆解成一个个节点和片段的,进行重新的组合和排列。

成功故事是可以续的,当一个人学习了初级厨师、高级厨师、中式面点、西式面点之后,他的成功故事应该是一个完整的故事,而不应该是一个个分离的故事。当这个人取得了有某个已经实现了的梦想相关的成就时,也可以将这个成就补充到那个成功故事之中去。比如某人学会了飞行驾驶,然后驾驶单人小飞机穿越了什么什么地方,并拍摄了什么什么照片或影片。这些就可以记录到那个学习飞行的梦想故事后面。

4.2 计划提供者可以提供一些符合格式要求的成功故事

那些提供计划的人或机构,也可以提供一些没有经过系统,而是完全在线下培训过程中发生的成功故事。

4.3 对故事中的环节提出异议,并进行讨论

如果某些人对梦想故事中的某些节点存在异议,可以对其提出异议,大家可以针对某一个节点,进行讨论。

4.4 允许浏览者提交其他成功故事

即使不是用户,也可以提交一些他们自己的成功故事。并不一定非要进行注册。

5 总结

好像又停更很长时间了。最近在忙盛大云计算大赛的事情,我负责去点评所有的作品。里面有不少作品都提到了学习和帮助别人实现梦想。看来这是一个很多人都在关注的热点啊。

不能保证下一篇什么时候出来,只能说我也是希望尽快的。本文讲了系统的一些基础架构,下一篇希望能够讲一讲这个系统的实现过程。当然也可能下面会写一些其他的东西,然后再继续写这个系统的下一篇博客。

Close Bitnami banner
Bitnami