存档

2011年4月 的存档

细说产品魅力属性

2011年4月28日 没有评论

魅力属性”是一个常常被我用在产品设计产品体验上 的词汇。

这不是我发明的,我在上一家公司A.O.Smith热水器的时候,做了一段时间用户调研,我们的调研公司使用了一个叫“科诺(Kano)模型”的东 西帮助我们分析产品的各种属性,有关产品几种属性的内容我记下来了。很长时间以来,我发现这样的概念完全可以用在我们的互联网产品设计上,甚至在很多产品 设计上都可以套用,还很管用。

于是我在很多场合开始讲这个概念,结合我的一些经验和理解,有一些优化吧。很多人也对这个开始很感兴趣,弄得好像是我提出来的东西一样。我在这里试 图详细阐述一下吧。

在UCD年会上我分享了所谓的产品“四种属性”,当时的解释是,所有产品的属性可以分为四类,他们是:

必备属性 产品必须具备的属性。比如电视机必须能出影,比如微博必须能发布能关注,满足用户对产品最基本的需求。

可有可无属性 用户认为是产品无所谓的属性,比如电冰箱可以放音乐。

魅力属性 用户认为产品特别有吸引力的,区别于其他产品的特别属性。

不可接受属性 产品不可以具备的属性,也往往和必备属性相对立。比如在中国使用110伏电源,微博不能转发等等。

其实这是被我简化和概念化了的模型,关于这个的原始资料和相关分析方法,我们在文章后面会附上,相信对做用户和产品研究的同学会有帮助。

其他三个概念都非常好理解,唯独“魅力属性”,需要详细说说,这也是我认为最有价值的属性。更是所有产品经理在设计产品时需要考虑的东西。这东西, 没有没所谓,有了,还真丢不掉。

举例来说:

前几天子柳在微博上发的那条,在QQ邮箱,如果你写了诸如“请见附件”之类的文字,然后还忘了粘贴附件,就会蹦出一个框。够可爱吧?

这就是挺典型的魅力属性,用户会觉得这功能好贴心啊。一种让人很温暖的提醒。

用wap版的微博,如果服务器忙,会看到这一屏,让人觉得要笑出来。没什么用,但显然比只说上面一句有用,还为服务器争取了时间。

我经常会提到的苹果电脑的“呼吸灯”。苹果电脑的电源灯,待机的时候会一亮一亮,节奏和人睡着的呼吸一样,非常有趣。很多初次看到的人,都会爱上这 个“贴心”的小设计。说实话,这个功能没什么难的,但是苹果做了。后来有几部手机具备了类似的功能,比如诺基亚8600,我用过,那个灯,呼吸就太慢了, 我喜欢跟着它调整呼吸,结果每次都憋得要死。这我就会觉得,诺基亚学了,没学好。

我还一直觉得,魅力属性抓得最好的,就是苹果了。我们会在苹果的产品中发现很多打动人的小细节。比如输入时候的放大镜,比如笔记本背后的发光 logo……当我们问那些苹果用户,苹果产品最打动你的地方在哪里,除了笼统的“设计”之外,你一定会听到很多有趣的东西,这些,都是魅力属性。

当有人问你,说打算出一款冰箱,在门上印画,你会觉得怎么样?我想大多数人会选择“没所谓”,因为他们可能不打算买冰箱,就算打算买,也是关注冰箱 什么牌子多大容量是不是节能等等,没有人会提出想要一个“面板印花”的冰箱。可是我们在卖场发现,印花的冰箱很好卖,同时,西门子曾经推出印有名家作品的 冰箱,放在商场巡展,很多人都会佩服西门子的创意和文化味,那个系列也变得非常好卖。

有人会说,魅力属性就是那些小细节嘛。对了一部分。确切点说应该是一些能够打动人的小细节。正是那些打动人的小细节,为人家赢得了更多的客户,换来 更多客户主动跟朋友提起。

另一个说法是“人性化”。我觉得这和“魅力属性”不一样。“人性化”说的是把自己当人,把人当人的做法。但是“魅力属性”是做那种招人喜欢的人。

为什么要有魅力属性?魅力属性有什么特点?

如果你有男朋友,问自己,为什么喜欢他。如果有女友,又为什么喜欢她。为什么是他/她,而不是别人?他/她跟别人很多地方都一样。你一定会告诉我, 你喜欢的人有很多地方不一样,对他/她的特别之处,你会如数家珍,甚至,会以这些好处,都充满幸福感。这就是对方吸引你的地方,你所回忆起的那些,就是对 方的魅力属性。

就这么简单,当产品变得越来越同质化的时候,那些有性格,有特色,具备魅力属性的产品才会脱颖而出。比如,谁能告诉我,现在千团大战,数千个团购网 站有什么区别?这样表达可能更直接一点,同质化越严重,客户忠诚度越低。就像团购,现在流量最大的,居然是那些团购集合网站,因为消费者只为团购的内容买 单,至于从哪儿买,大家服务都一样,也没啥讲究。

所以,魅力属性是同质化最好的解药。

有没有发现,所有我们提到的,和你能想到的那些能魅力属性,你都会愿意跟人分享。我想,再没有什么事儿比客户主动帮你做宣传更爽的了吧。我会跟很多人讲友人网的筛选功能,因为它让我用起来好爽,淘宝没有实现过。我们每个人,跟人讲起那些打动过自己的产品功 能的时候,都会眉飞色舞。这些所有这些传播出去的功能,都是很简单的东西,一两句话就能说清楚的那种。

所以,魅力属性具有极强的传播力,甚至有病毒的作用。

一个很好的魅力属性,会很容易占据某个领域,让自己的这个功能,成为某一类产品或者某一个领域的标准,最后成为标配。比如“断点续传”,我不知道是 谁先用起来的,但我知道QQ在这方面最先推广起来,后来大家就都觉得QQ传文件“靠谱”啊。就算后来其他IM工具也支持了断点续传,用户会认为“这个人家 QQ早就有了”,“原来旺旺也能断点续传了呀。”一个“也”字,多少无奈。更可怕的是,MSN至今都被送一个“还”字,因为还不支持断点续传,人们会觉得 “太傻了”。甚至很多魅力属性被拿来和品牌关联起来,而且,后来者往往被认为是“学的”。

所以,魅力属性很有强独占性。

当一个魅力属性被做到极致,有时候会发生一种现象。产品属性的认知度和传播效果,远高于产品本身。我们都碰到过,想不起来某个东西,但就记住什么特 点了,就说“就是能xxx的那个xx”,就属于这样的例子。比如我现在这个X10手机,我不止一次听到有人跟别人介绍,说胖胡斐那个手机拍照很好的,啥型 号记不清了。你的男朋友可以不高不帅,也可以不浪漫,可以不这样不那样,但你还是喜欢他,因为他一定在某方面的魅力让你觉得足以弥补所有缺憾。

所以,魅力属性的能量可以被放到很大。

还有个现象很有趣,就是一个属性一旦被认为有魅力,就不能没有了。比如当初旺旺和贸易通合并的时候,旺旺原有的“一个好友可以在多个组里”的功能被 取消,我当时就跳出来说这是一个降低魅力值的事儿。要知道,当时的IM工具里,只有旺旺能这样。后来MSN有了,QQ有了。旺旺到现在也没法一人多组,反 正我永远不会改变我的看法,那次改动很不懂事。这样的例子多得是。最有趣的是,当一个魅力属性消失,用户会想,这家企业怎么了,这个品牌怎么了,为什么没 了。说实话这很可怕。想想,你明天拿到一部苹果电脑,发现灯不会呼吸一直亮着,你会怎么想。

所以,魅力属性需要被坚持。

怎么找到魅力属性?

先问一个问题,产品经理在设计产品的时候,会考虑什么问题?会考虑客户需求是什么,然后考虑怎么满足他们的需求,对吧?然后做出一个“满足”需求的 产品。这样的产品,往往“刚好”满足客户的需求,客户不会觉得不满,但也不会觉得很爽,更不会心甘情愿的帮你宣传。

那么和上面的那些案例相比,差在哪里呢?因为上面的产品经理不光满足客户的需求,而且超出了客户的期望。客户不可能说要一个电源能呼吸的电脑,但是 他们做了,客户就爽了。而且,产品经理也很爽。

我的想法是,魅力属性不要直接问用户。

产品经理最大的问题,就是总在“分析需求 – 满足需求”中转来转去。说必应的例子,微软要做一个搜索引擎。那需求是什么?要能搜到,于是需要有爬虫,有索引有算法等等。 要很快,不能像传统微软产品那么慢,所以需要优化速度,微软也不认为页面显示“用时xxxx秒有什么意思”,所以微软需要找到用户不会抱怨的最长时间,只 要比这个快就可以了。需要把很多种搜索结果放在一起,所以有了混合搜索。这些都是需求,完成了这个,就是一个搜索引擎了,产品经理的职责也完成了。这就是 原先Windows Live Search。可是没人用,是没有广告投放的问题么?我告诉大家不是的。关键问题,是没有找到一个用户更换搜索引擎的借口,没有找到一个能够传播的魅力属 性。于是微软做了几件事:起了一个很响亮的名字Bing,然后在必应首页使用大图片的情感化运营方式,最后是 在产品上做创新,必应搜索视频,鼠标移过的时候,就会直接播放,这个真的很棒,会节约大量时间。于是很多客户开始爱上必应,跟别人分享必应的图片和体验, 很多人手机下载必应的客户端,用必应主页图片做桌面。这让我们看到搜索引擎原来可以这么玩。必应在全球很多市场的份额大涨,已经第二了。

我的想法是,产品经理需要跳出来,放开去想。

微软在几年前跟我聊,说会有一个新的搜索产品,每天会更新首页图片。我当时的反应是“神经病”,也就是我认为这个属性“可有可无”。可是后来做出 来,我倒吸一口凉气。同样,Google的logo文化人人喜欢,我至今都记得那天PAC-MAN游戏纪念,原本如果做成下面这样的图片,我们就很惊喜 了,结果发现“I’m feel lucking”改成了“Insert Coin”然后还能玩两把。整个人就抓狂了,你没有想到会有趣到这种令人发指的地步。这样的需求,永远也不会被“客户”提出来!而且,当问起用户我们在 google首页玩游戏怎么样,那用户也不会选择“很爽”,这就是可有可无。

我的想法是,试试从“可有可无”属性中挖掘可能的魅力属性吧。

说实话,我接触产品的日子,最恨的一句话就是“二期”。“二期”是我见过最好的推脱方法,因为“二期”给人一种还有希望的感觉,给人一种“有优先 级”的条理感。可是我不知道别的公司怎么样,我接触过的产品,往往“哪TM有二期!?”为什么呢?因为其他的需求排在后面,你这些被二期的需求,既然都二 期了,那就是不重要的,所以必然排不上优先级,所以不会有人理会。

事实很残酷,产品经理砍掉的那些“二期”需求,常常就是能成为魅力的东西。结果呢,就是我们花了很多精力,做出了跟别人没什么区别的,满足基本需求 的产品。然后这傻产品一上线就是一年多。例子就不举了,伤了和气。总之,我旗帜鲜明地反对所有拿二期当借口的行为。

我的想法是,从被二期的需求中,去找找能成为魅力属性的东西。

每个人每天都在接触各种产品,我们常常会想,这东西怎么不这样怎么不那样。其实这就是说,如果这样或者那样了,我们就会用的爽一点。换句话说,如果 怎么样,你自己就high了。我们很多产品经理在设计产品和砍需求的时候,我看不到他们眼睛中的亮光,说实话,一个不能让自己high起来的产品,我们怎 么指望别人能爽呢?我见过我们交易线的一个产品经理,讲到要做的东西时候,两眼真的放光,就像苹果首席设计师的Jonathan Ive的眼神一样。我那时候就跟自己说,这一定会是一个好产品,结果真是。让人遗憾的是,我们碰到的很多产品经理,会强调老板说要如何如何,然后做一做分 工就干活了,我真不指望那东西能做得如何。

因为,那样的做法,实在满足别人。只有满足自己的时候,人才会兴奋起来。你见过天天接客,还打心眼里喊爽的么?

苹果首席设计师Jonathan Ive,充满自信和热情的眼神

淘宝的TMS系统是个很好的正面案例。最早的需求是为了替换老化的TurboCMS,同时实现一些自动化的更新。后来TMS团队有几个同学很 high,比如毛哥、青云,他会每天跟运营同学沟通,看看大家用得爽不爽,把发现的问题记录下来。之后,我们发现上了定时更新,然后是版本和日志记录。发 现运营还花了大量时间在Ctrl+C – Ctrl+V,然后就设计了一个小功能,运营可以直接粘贴excel表格了,这是能让我们欢呼起来的功能。要知道,这些需求都不是主动提出来的。是因为我 们的产品同学爱自己的产品,想做得更好。

我再说一遍,整天研究产品需求的产品经理,永远也不可能找到魅力属性,更不可能做出人人称颂的产品。

我想说的是,魅力属性就是那个能让自己两眼放光的东西,放光的时候,一定要抓住。

找到魅力属性的方法很简单,抬头看看,跳出去看看,再转过来看看。

实施、保持魅力属性,并形成产品特征

这个真没什么好说的。

如果你谈起一个小功能,就两眼放光,别管别的了,做吧。

如果你发现用户谈起你的小功能,就两眼放光,别管别人怎么说,保持住。

以后,这就是你的特征,别人抢都抢不走。

要注意属性的转变

这是一个非常有趣的现象。我们发现在产品的生命周期和更新换代中,产品的属性会发生变化。

一方面因为用户需求会发展。同一属性的定义不会恒定不变,当某一属性由原来的魅力属性逐渐成为行业标准的时候,它就会转化成必备属性了。比如彩色电 视机,在都是黑白的时代,彩色绝对是魅力属性,后来,谁家电视不是彩色的?又比如微博的转发并评论,没有的时候,一有就觉得无比靠谱,后来谁再做微博,要 是转发并评论放在二期,肯定会有人骂娘。

一方面因为产品自身的发展。很简单的例子,Office,升级到2007的时候,无数人骂娘,什么烂东西,想找的菜单都找不到了。因为大家都很习惯 原来2003的菜单了,2007从根本上改变了菜单组织方式,这在当时看来,快属于“不可接受属性”了。当时微软还出了一个报告,说Office2007 的用户在两个月后,效率提高超过百分之多少,我嗤之以鼻。可是当我用了两年,后来又升级到2010的时候,有一天在一台装了2003的电脑上,我死也没找 到想找的菜单,然后恍然大悟,2007的菜单组织方式,确实有助于提高效率。这就是魅力属性被慢慢认知和认可的过程。

有两种属性转变方向需要关注。

  • 魅力属性 -> 必备属性。也就是我们说的占领了一个领域,到这,就是一种“境界”了。
  • 可有可无属性 -> 魅力属性。被挖掘出来和被认可的过程。这种过程产品经理会很开心。我把这叫做“进化”

  • 必备属性-> 不可接受属性。这个不能放在图里,因为这说明产品失败了,或者作出了一个阉割掉的东西。比如淘宝08年下半年做的“限时抢购”产品,秒杀被玩起来之后有了 需求,需求上写了要实现定时改价格提前预告等等。结果开发的时候有人认为预告功能没必要,就“被二期”了。结果我告诉他们,用户不知道什么时候开始改价 格,谁会来等着,没人来等着算什么限时抢购,然后说这个阉掉的产品在没有预告之前不会获得任何推广资源。结果是产品上线推迟了将近2个月。这是个血淋淋的 例子,大家要共勉。

注意,产品属性之间的移动,是单向的。如果出现了反向的移动,很可能是需求发生了颠覆,或者演砸了。

好了,我觉得说得挺多了,魅力属性是个很有用的东西,把握好了,如虎添翼。写给愿意做好的人。

*附:Kano模型的详细信息和实施方法

对产品而言,存在三类属性:一维属性、魅力属性和必备属性。产品的功能好坏,和客户满意度之间的关系如下图。

学过高中数学的同学就应该能明白了,一维属性就是功能越好,客户约满意。而必备属性在功能完善到一定程度之后,满意度变化会趋缓。同时,魅力属性越 多,满意度会极大提升。

此外还有一个“次要属性”指那些无论功能表现如何,对满意度都不会产生影响的属性。

Kano分析技术的应用和数据采集:被访者会被要求回答一组配对的问题,数据会很多,也会很麻烦。表格比如:

如果电脑有防水键盘,你感觉如何?

  1. 我喜欢
  2. 它理应如此
  3. 无所谓
  4. 我能忍受
  5. 我不喜欢

如果电脑没有防水键盘,你感觉如何?

  1. 我喜欢
  2. 它理应如此
  3. 无所谓
  4. 我能忍受
  5. 我不喜欢

针对得到的配对问题,我们可以给每一种答案一个分类的定义,下面就是一种典型的定义分类方式:

其中A = Attractive = 魅力属性,M = Must-be = 必备属性,O = One-dimensional = 一维属性,I = Indifferent = 次要属性,R = Reflected = 与假设相反的属性,Q = Question = 有问题的回答。

然后根据统计得到的不同分值,通过一些算法,可以在上面的坐标系中标注出每一个属性的点,越高说明越重要。

除了这样的表现,还可以结合高级统计分析方法,得到一些跟深入的分析。

胖胡斐要特别强调,这只是一种分析方法而已,不要不相信分析,但也不能全相信科学。特别对魅力属性而言,相信自己更加重要。

分类: 3电动设备 标签:

小型团队快速开发方法

2011年4月26日 没有评论

1.前言

小型团队快速开发方法是力求找出中小型项目开发的最佳实践。

小型团队快速开发方法以敏捷开发为核心,结合中小型软件公司的实际情况,制作从需求调研到项目验收的“标准”过程。

小型团队快速开发方法以简明实用为主,以能够对项目小组有用、能够辅助项目顺利为研究方向。

小型团队快速开发方法也算是我从业7年来,近20个项目的亲身经历的开发总结。

  • 方法特点

1.需求用例驱动

2.原型开发

3.领域模型分层

4.职责垂直切割

  • 方法适用环境

1.3至6人的小团队;

2.有一个时间稳定、经验丰富的主力成员;

3.有至少两个在需求明确的情况下(用例完备),能独立完成模块的队员。

  • 原始研究文档

1.《数据驱动开发——对项目开发的总结和反思》(原创)

2.《快速迭代与原型开发》(原创)

3.《分层架构》(原创)

4.《彩色UML建模》

5. 腾讯敏捷框架TAPD

6.《大象UML》

2.系统分析:用例

本方法是用例驱动开发,用例 = 需求,即需求以用例的方式来表达。

本方法只需要业务用例,其它用例不使用。

业务用例的目标非常清晰,它就是用于系统分析上的,具体一点说是系统分析中的需求分析这一步。

用例不但是用来记录分析的结果,同时也是一种分析方法,它通过寻找系统边界、涉众、场景等元素,从而确定系统的业务内容,并用UML用例图绘制出来。注意,简单的用例直接用UML用例图绘制即可,复杂的用例必须适当地加上文字说明。

如何找出用例是系统分析的核心。

RUP有成熟的步骤去发现用例。

建议用RUP发现用例的手段去和领域专家研讨,但并不需要按照RUP的所有步骤去所有编写文档,只需要编写业务用例这一部份就可以了。

注意,虽然调研时最好编写领域中的所有业务用例,但其中的核心业务才需要编写详细用例。

实际上,在业务流程的背后,有一个更加根本的因素——商业需求。商业需求才是真正的需求,业务流程只是一种实现手段而已。

注意,需求调研要避免掉进“业务流程”调研的陷阱。用例是以问题域/商业模型为核心的,它是领域模型的基础,而业务流程是商业模型的实现手段,是为商业模型的服务的。业务流程是企业当前的实践方法,而有时候业务流程受其它因素干扰(可能是电子信息化水平低下,或者是行政法规等),导致当前的业务流程并不是最佳实践。我们要在调研的过程中分析出用例,然后再构造出用例之间的关系,这样就会得到最佳的业务流程。当然,我们也会不可避免地遇到外界因素干扰,导致理想化的业务流程不合实际,但我们继续不断地沟通,对流程进行重组,就可以让流程不断地贴近最佳实践。

3.系统设计:领域模型

用例之后就是建模。

FDD是横跨系统分析和领域建模的轻量方法。

FDD中根据模板(其实就是动宾短语)寻找概念类,和RUP中“用例必然以动宾短语形式出现”的意思完全一致——我们的用例就是FDD的概念类。从这方面看,FDD是系统分析的一种方法。

FDD不使用用例,它直接进行概念建模。系统分析师与领域专家提炼出特征,然后系统分析师就开始总体建模。总体建模采用的是四色原型法,四色原型的本质是描述“什么人(PPT-party)在一个什么时间(MI)以一种什么身份(Role)做什么样的事情(PPT-thing)”。从这方面看,FDD又包含了系统设计。

FDD的最大优点就在这里:我们可以依据FDD的模板指导,把用例平滑转为概念类。

4.使用RUP & FDD进行系统分析和设计

4.1. 总体流程

我们用RUP的步骤发现和编写用例(客户需求),然后通过FDD的模板(动宾短语)进行概念类建模,最后我们根据分析模式,把概念类转为领域模型。

4.2. 发现需求和用例

因为RUP明确提出了“用例 = 需求”,RUP里有非常详细的发现客户需求的方法,准确地说,RUP里有如何发现用例的步骤:

1.确定系统边界。

2.确定参与者(涉众)。

3.确定参与者的目标。

4.定义满足参与者目标的用例,根据其目标对用例命名。

这些步骤包括了客户访谈、有效用例测试等实用的手段。

FDD可以看作是确定参与者目标的一种简洁有效的方法。FDD根据RUP确定出来的系统边界和涉众,通过与领域专家交流(客户访谈),确定用户的目标。

4.3. 把用例映像为模型

把需求表述为用例不算太难,因为用例基本上算是用文字忠实描述用户的需求,并且用例的格式很简单,非常容易掌握。

用例真正的难点是如何发现用例,而不是描述用例。

不过把用例映像为模型(概念模型)就很有难度,这个难度表现在两方面:

模型的阻抗、模型的可实现性。

4.3.1. 业务模型与计算器模型的阻抗

因为模型是计算器抽象出来的,而用例是现实世界中具体存在的,这是两种完全不同的东西。用例的信息和关系必须通过一定的规则转换,才能映像为模型。如果是数据模型,那么就是ER规则;如果是领域模型,那么就是OO规则。

阻抗不是这么容易消除的,UML总结了大量的模式,可以作为参考。

4.3.2. 模型不能直接实现

当我们没有有效方法的时候,把用例映像为模型很大程度上依赖系统分析师的经验和水平。不过即使两个水平相近的分析师,他们做出来的模型(UML表达)也会相差很大——这会导致使用者对设计者的意图理解错误。

那么,有没有一种方法可以让用例能够平滑映像为模型,并且模型能够遵循一定的范式(Pattern),使得设计者与使用者能够理解一致?

四色原型和DDD的分析模式就是为了这个目标而提出的。

四色原型与FDD同出一门,FDD的“特征”在很大程度上是四色原型的文字表达方式,而四色UML类图是四色原型的图表表达方式。基本上用文字描述的“特征”与用UML类表现的类图,两者能够做到信息无损转换。

因为我们在定义用例的时候,已经使用了FDD的特征(动宾短语)进行分析,而特征本来就是四色原型的“用例”,所以从用例映像为四色原型是非常容易的,而且其中也有规律可寻。

四色原型离领域模型已经很接近了,只不过四色原型更注重业务模型,而领域模型更趋于计算机模型。四色原型并不一定能够直接被OO语言实现,而领域模型会遵循DDD的分析模式,一定能够直接被OO语言实现。

在这里“直接实现”的意思是,模型在不作修改的情况下,被程序员用代码表达出来,并且代码完全没有违背模型的地方。

所以我们只要按照DDD的分析模式对四色原型进行“修正”,就可以得到领域模型。

5. 使用敏捷指导软件开发

XP和FDD侧重于软件开发,而Scrum侧重于项目管理。

RUP太重了,不适合小团队的开发。

5.1. 关于结对编程

结对编程不容易推广,因为绝大数的程序员有天生的反感,况且选择合适的结对对象也不容易,搞不好两个人还会产生矛盾,影响团队团结。所以轻易不推荐结对编程,但如果有新人加入,可以考虑用结对编程,以熟手带新手。

虽然不推荐结对编程,但也不能完全让一个人独立写代码,一定要让两个人互相依赖对方。这样做的目的是为了防止有人偷懒,也是为了防止技术狂人为钻研高深技术而忽略了实现业务。

横向切割的MVC/MVP模式是一种方法,一个人写Presentation层,另一个人写Controller/Presenter层,可以互相依赖。但MVC/MVP模式本身有一定的技术深度,不经过培训及一段时间的培养是无法使用的。

基本上没有太好的办法,每日代码检查和每日例会虽然可以这个解决问题,但这样会加重主力成员的工作量。

6.使用Scrum指导项目管理

7.文檔

多用单元测试代替编程文档。多为代码加上注释。只有业务非常复杂,代码和注释都无法清晰地表述的时候,才使用图表和文字编写文文件表达。

8. 总结

从繁杂的需求到健壮的代码,这是我们的最终目标,而这一系列的步骤给人的感觉很流畅,并且每一步都有规范的指导,不再是只凭经验行事。

注意,这种方法注重于项目开发(分析、设计),我们还需要一种注重于项目管理的方法。

分类: 3电动设备 标签:

关于腾讯敏捷框架TAPD

2011年4月26日 没有评论


腾讯是一家典型的互联网企业,互联网行业有其鲜明的特点:
1.关注用户行为
2.追求创新(腾讯有一个创新中心部门)
3.需求不确定性高
4.快速适应变化
5.快鱼吃慢鱼

腾讯在敏捷开发方面的实践大致包括3个部分:
1.产品
采用FDD,即产品特性开发驱动的一种模式,腾讯的产品会有一个明确的产品经理这样一个角色,他会负责整个产品,包括产品的验证、产品的方向、市场调研、用户调研等。FDD模式是一种非常适合产品经理来对产品做一些滚动的要求,腾讯在产品设计上引入了类似FDD这样的模式,但是也不完全是FDD,只是参考FDD,所有的开发团队都是由产品经理所归纳出来的产品特性去驱动整个产品的研发。

2.项目管理过程:腾讯采取了SCRUM,但也不完全是SCRUM,有腾讯根据自己的特点去总结的一些实践,大概的项目管理过程同SCRUM的过程是比较类似的,包括每天的晨会、迭代、timebox、每个迭代完成的时候会有showcase、回顾总结等。
3.开发实践:参考了很多XP的实践,就XP完整的实践来说会比较理想化,很多东西不一定在实际开发中能够采纳,所以腾讯也是采纳其中的某些实践,比如自动化测试和持续集成,通过这样的实践就能保证产品有一个快速发布的过程。

在腾讯的敏捷实践中,具体的实践情况是这样的:
1.故事墙:就是白板story wall,平时工作中很多团队都会使用,这些团队会把每天开发的一些产品特性采用story的方式每天都在白板里面展示出来,整个团队每天都会围绕这个白板能够清晰的看到整个产品或者整个项目的一个过程,包括整个产品特性的过程。
2.迭代总结:在每一个产品发布的时候都会有一个总结。具体的做法是,把做得好的、不好的总结出来,做得好的在下一次迭代发扬光大,做得不好的在下一次迭代就要注意改进。这样的总结是要求项目的所有成员都必须参加,包括项目的开发人员、测试人员、QA、项目经理、产品经理等,每个人都要去去总结他在上一个迭代中碰到了什么问题,通过便签纸的方式贴出来,项目经理实际上可以看成是SCRUM M a s t e r,包括站起来总结这样一些东西,包括我们下一次迭代继续发扬什么,必须要注意什么东西,最后就会得出一个excel的文档,包括上一个迭代中出的问题,具体的解决办法,都会有。
3.每日晨会:每个团队每天大概花15-30分钟,回顾昨天做了什么、昨天有些什么问题、同时也会介绍每个人今天计划做些什么工作(特点:是站着开会)。最早是通过白板的方式去做,就是每天项目经理组织团队成员对着白板,白板上体现项目的进展情况,通过会议可以很明确的知道昨天大家做到什么样子,今天大家计划做什么,最早的时候每个成员都是口头汇报的。实践一段时间就发现了一些问题,第一、对于一个20、30人的团队,每天要怎样做晨会,这是目前遇到的比较大的困惑;第二、晨会很容易形式化,究竟带来什么样的效率和效果,目前也在通过一些方式去研究,去探讨。第三、有一些形式上的呆板,刚开始做会觉得比较有意思,觉得这跟传统做法不一样,每天这样做并且做多了就感觉很枯燥,这也是面临一个挑战。后来腾讯也做了一些改进,比如为了让成员的参与程度更强一些,包括形式上会更强一些,现在有些团队就会采取每个人轮流主持的方式,刚开始晨会的时候我们也会通过一些好玩的东西去刺激一下某些东西,但是现在看来的话,感觉改进的还是不是很透。在腾讯内部有一个交流通信的软件,有些项目也开始不采用站起来开晨会的方式,觉得站起来效率也高,就会通过即时通信软件每天去交流,最后由一个人去统一输出,这样能解决一些分布式团队的合作。所谓分布式团队就是这个团队中有些同事在这个大楼,有些同事是在那个大楼,通过这种实时交流的方式可以解决一些问题。
4.结对编程:并没有很好的实施开来,但是在一些团队里面还是一直在尝试着做结对编程的工作。一个在编写程序,旁边还有一个人,同时记录编写过程、编写思路、碰到的问题、自己的想法,编写完以后一段时间他们会交换一下,就是互相交换着进行编程,这是一个结对编程的一个过程。
5.时间盒:timebox,在腾讯的产品研发中,产品的每一个迭代都有一个明确的时间盒。在每一次迭代开始的时候会召开一次IPM会议,即本次迭代的计划会议,会议中团队中的所有成员包括产品人员、开发人员、项目经理、总监、部门领导,一起去敲定本次迭代要完成的任务,一旦任务敲定下来,本次迭代就会严格按照这个去落实执行。
6.一个完整的迭代过程:包括概念、设计、开发、测试和发布五个过程。在概念阶段,会采用FDD里面提到的一些好的最佳实践来支撑到我们怎么样去敏捷的做需求开发,会制定一些产品发布的计划,比如产品在未来,某个迭代什么时候发布,要发布哪些产品特性,都是在这个阶段做的。在设计阶段,会做产品原型上的设计。对于互联网产品说更多的是通过快速原型法快速的让产品在不同范围内去做一些体验,比方产品在某个迭代的一个小迭代里面,可能会在一个团队里面先去体验,可能就会采取发布到公司某一个部门去体验,或者发布到整个公司范围去体验,它会是一个不断放大的一个过程。在开发和测试阶段,更多的采取XP的一些实践,包括编码规范,代码走读,比如1

分类: 3电动设备 标签: ,

CSM(Certified Scrum Master)敏捷总结

2011年4月25日 没有评论

2011年4月14-15日,有幸参加全球敏捷联盟的CSM(Certified Scrum Master)培训,虽然我们在平时工作中一直使用Scrum开发模式,但是对Scrum的理论我还不是十分的清楚,两天全英文的培训使我全面了解了Scrum的基本流程,总结一下培训重点,希望和更多使用Scrum模式的人共同交流探讨,某些术语翻译的不准确,希望批评指正。

1.Scrum简介: Scrum一词来自橄榄球运动,在软件工程中,Scrum是以经验过程为依据,采用迭代、增量的方法来提高产品开发的可预见性并控制风险的理论,Scrum不是一种过程,也不是一项构建产品的技术,而是一个框架,在Scrum框架中可以应用各种过程和技术,Scrum的作用是让开发实践方法的相对功效显现出来以便随时改进。

2.敏捷开发中的Scrum模式:

Scrum是敏捷(Agile)开发的一种实践模式,敏捷开发强调拥抱需求变化,快速响应不断变化的需求,并尽可能快地提供可以工作的软件产品,敏捷最强调的是可以正常工作的软件产品,文档等不是非常的强调(并非不要文档,只是需要必要的文档),敏捷理论认为面对面的沟通交流远比文档更有效。

敏捷开发的Scrum模式是以价值驱动(Value-Driven)的开发模式,即认为用户的需求并不一定需要100%实现,最重要的是将对用户最有价值的功能实现并交付.

敏捷开发中Scrum开发流程如下:

3.Scrum框架元素:

Scrum框架的主要元素有:

(1).3种角色:

a.Scrum Master

b.Scrum团队。

c.产品负责人(Product Owner)

(2).4种会议:

a. Sprint规划会(Sprint Planning Meeting)

b.每日站会(Daily Scrum Meeting)

cSprint评审会(Sprint Review Meeting)

dSprint回顾会(Sprint Retrospective Meeting)

(3).2Backlog列表:

a.产品需求Backlog列表(Product Backlog list)

b.Sprint Backlog列表。

(4).2个燃点图:

a.产品发布燃点图(Product release burndown chart)

b.Sprint燃点图(Sprint buirndown chart)

4.Scrum角色介绍:

(1).Scrum Master:

Scrum Master的主要职责是:

a.排除产品开发和产品负责人之间的障碍,确保产品负责人直接推动开发工作;

b.教授产品负责人如何实现投资回报最大化,以及如何利用Scrum达成目标;

c.激发创造力和放权,从而改善开发团队的环境;

d.千方百计实践和工具,确保每个功能增量都具备潜在可交付行;

e.向各方确保团队工作进展实时更新并高度可视;

(2).Scrum团队:

Scrum团队是Scrum框架的核心,Scrum团队是一个自我管理的组织(Self Organize Team)Scrum团队不需要命令,成员根据自己的兴趣任意选取Sprint Backlog中分解的任务,整个团队为了在Sprint迭代开发周期中提交可工作的软件产品目标而相互合作,Scrum团队的特性:

a.具有不同特长的团队成员,人数控制在5-9个左右。

一个Scrum团队中,开发,测试等人员都需要有,人数不能太多,否则沟通成本太高。

b.确定Sprint目标和具体说明的工作成果。

c.在项目向导范围内有权利做任何事情已确保达到Sprint的目标。

d.高度的自我管理能力。

e.Product Owner演示产品功能。

Scrum团队的成员们必须有这样一个意识:整个团队要么一起成功,要么一起灭亡,没有个体的概念,每个成员只要为了Sprint目标,可以做什么事情。

(3).产品负责人(Product Owner)

产品负责人(PO)负责收集客户需求,并根据产品功能点对用户需求的价值,将客户需求排列优先级形成产品Backlog作为Scrum团队Sprint开发周期的输入。产品负责人的特性如下:

a.确定产品的功能。

b.决定发布的日期和发布内容。

c.根据市场价值确定功能优先级。

Value-Driven,根据功能客户的价值/投资回报率对来确定优先级。

d.Sprint周期内调整功能和调整功能优先级。

e.接受或拒绝接受开发团队的工作成果。

5. Scrum4种会议介绍:

在介绍Scrum4种会议之前,首先介绍Scrum中一个很重要的概念——Sprint.

Sprint是一个固定时间段的迭代开发周期,一般为2-4周,最长不要超过一个月,Sprint太长风险不易控制,太短则Sprint会议会占用大量时间。一个SprintSprint规划会、每日站会、Sprint评审会和Sprint回顾会组成,Sprint的输入是产品Backlog,输出是包含了Sprint提交的可运行的软件。

(1).Sprint规划会(Sprint Planning Meeting)

Sprint规划会议制定迭代计划,Sprint计划会议的内容包括以下两个部分:

a.产品负责人告诉Scrum团队决定Sprint做什么:

产品负责人把具有最高优先级的产品Backlog呈现给Scrum团队,并一起决定接下来的Sprint中开发什么功能。

b.Scrum团队研究如何实现功能:

Scrum团队根据Sprint规划会议第一部分的产品Backlog,将产品Backlog分解成具体的开发任务,即Sprint Backlog,并估算完成每个任务所需要的大概时间。

这个阶段的会议不要超过4个小时。

(2).每日站会(Daily Scrum Meeting)

一旦Sprint计划阶段结束,2-4周的Sprint就开始了。Scrum Master需要组织团队成员每天开站会. 这个会议是用最多15分钟的时间来让大家过一下scrum的状态。在会上,每个团队成员需要问3个问题:

a.我昨天做了什么.

b.今天做什么.

c.遇到哪些障碍。

谁都可以参加这个会议,但只有Scrum团队成员有发言权。这个会议的目标是得到一个项目的全局观,用于发现任何新的依赖,定位Scrum成员的要求,实时的调整当天开发计划.

注意:每日站会时,只通报进展情况,不做讨论,深入具体的讨论在会议结束之后找时间进行。

(3).Sprint评审会(Sprint Review Meeting)

Sprint结束的时候召开Sprint评审会,这个会议最多不超过4个小时.Scrum团队演示在这个Sprint中开发的产品功能给产品负责人.产品负责人会组织这阶段的会议并且邀请相关的利益相关者参加。业务,市场,技术都要做相关的评审。由产品负责人来决定Product Backlog中的哪些功能已经开发完成 。

(4).Sprint回顾会(Sprint Retrospective Meeting)

Scrum MasterScrum 团队一起回顾当前的Sprint。团队评估大家在一起的工作方式,找出好的方式以后继续发扬,找出需要做的更好的地方,想办法提升。Sprint评审会结束后,新一轮的迭代又继续开始(中间最好修整半天或者隔个周末),迭代会一直继续,直到开发了足够多的功能去交付一个产品。

Sprint回顾会时,汇报经理和产品负责人一般不被邀请参加,主要是为了给Scrum团队一个安全的、畅所欲言的开放环境,毫无顾虑地提出意见帮助Scrum团队更好地工作。

Sprint回顾会时,最好Scrum选择一个好的方面,一个不好的方面讨论,容易在有限时间里充分讨论形成一致意见,并确定责任人执行。

6.ScrumBacklog

Sprint中有两种Backlog:产品BacklogSprint Backlog.

(1).产品Backlog

在产品/项目开始的时候,产品负责人要准备一个根据商业价值排好序的客户需求列表。这个列表就是Prodct Backlog,一个最终会交付给客户的产品特性列表,它们根据商业价值来排列优先级,是Scrum团队每个Sprint的输入。

Scrum团队会根据Product backlog来做工作量的估计。Product backlog应该涵盖所有用来构建满足客户需要的产品特性,包括技术上的需求。高优先级的一些产品特性需要足够的细化以便于我们做工作量估计和做测试。

产品Backlog列表中的最小单位为用户故事(User story),用户故事的需要必须独立、可评估大小(用户故事的相对大小),对于用户故事的估计方法如下:

a.选择用户故事大小参照物。

b.Scrum团队使用扑克牌估计用户故事的大小,尽可能意见比较一致或相近。

c.使用菲伯纳西数列:123581321……表示用户故事的相对大小。

d.对于过大的用户故事需要拆分成小的用户故事。

(2).Sprint Backlog

Scrum团队选择并承诺了产品Backlog中要递交的一些高优先级的产品功能点后,这些功能点就会被细化成为Sprint Backlog:一个完成Product Backlog功能点的必需的任务列表.这些点会被细化为更小的任务,工作量小于2天。Sprint backlog完成后,Scrum团队会根据它重新估计工作量,如果这些工作量和原始估计的工作量有较大差异,Scrum团队和产品负责人协商,调整合理得工作量到Sprint中,以确保Sprint的成功实施。

7.2个燃点图:

(1).产品发布燃点图:

产品发布燃点图记录在一段时间内产品Backlog的总剩余估算工作量,估算工作量是以Scrum团队和组织决定的单位为标准,时间是以Sprint为单位。产品发布燃点图是产品剩余工作量趋势图。

(2).Sprint燃点图:

Sprint燃点图展现的是当前Sprint内剩余的Sprint backlog工作量,创建该图需要通过累计Sprint中没人Backlog估算来确定剩余工作量,Sprint内剩余工作量就是所有Sprint Backlog的剩余工作总量,Scrum团队在每日站会过当前Sprint工作状态时,会同步更新Sprint燃点图,时刻显示剩余工作量。用线将图上的点连接起来,团队就可以控制完成Sprint工作的进程,所耗时长并不属于Scrum的关注范围,剩余工作量和完成日期才是利益相关因素。

Sprint燃点图以及Sprint任务分解的重点不是关注是否精确,而是确保Scrum团队可以保持一个稳定的开发速度和产出效率,Scrum团队通过长期对Sprint燃点图的统计分析可以估算出团队的乐观速度,悲观速度和平均速度,在Sprint规划会时可以给出Sprint可以完成的Product Backlog乐观的、悲观的和平均的估计。

8.定义完成(Definition of Done)

Scrum要求团队在每个Sprint内构建可交付的软件产品功能增量,因为对于产品Baclog的功能是否完成每个人的理解可能不同,因此需要定义完成的含义,定义完成由Scrum团队和产品负责人一起讨论决定,只有所完成所规定的工作全部完成时,产品Backlog才算完成,未完成的产品Backlog导入到产品Backlog中,继续下一个Sprint迭代。

 

分类: 3电动设备 标签:

小米的猜想

2011年4月25日 没有评论

如何最快找到知名投资人雷军?不是电话也不是微博,而是一款基于手机通讯录的聊天工具—米聊。

这位中国最成功的天使投资人之一几乎时刻挂在米聊上。一位百度工程师对本刊表示,他和雷军并不认识,但在加了雷的米聊号后,很意外地看到对方主动过来说“hi”,紧接着被问道:“你上面有多少好友?”

“他都快成我们的免费客服了。”小米科技负责技术的副总裁黄江吉和负责产品的副总裁洪锋在听到这个故事后,不约而同地对《环球企业家》笑言。过去半年里,小米科技无疑中国科技圈内最被关注的角色之一。这个针对移动互联网的创业公司有着堪称“豪华”的团队—雷军是天使投资人,也将绝大部分精力投入这个项目;CEO林斌原为谷歌中国工程研究院副院长;联合创始人兼副总裁黄江吉、洪锋分别来自微软和谷歌:黄江吉曾在微软亚洲工程院任开发总监,负责Windows Mobile项目,而洪锋则是原谷歌中国最优秀的产品经理之一,参与了谷歌输入法、谷歌音乐等本地化产品的开发。

让业界更为震动的是,2010年12月,有消息称刚成立才半年多的小米科技融资3500万美元,估值高达2亿美元。

小米科技正在用行动力证明自己“物有所值”。在当下群雄割据的状态,最快的反应速度和执行力至关重要。接近小米科技的人士称,它倾向于用最有吸引力的薪酬招最好的人员,以最快的速度推进项目:每周上六天班,工作时间为每天12小时,从早上10点到晚上10点。以米聊为例,它遵从快速迭代的产品改进方式,每周进行一次大的版本更新:周五发布新版,周六周日收集用户反馈,周一到周五进行开发和测试。

事实上,洪锋和黄江吉之前并不认识,和雷军等人也并不熟悉,林斌是这群人之间的共同纽带。在谷歌时,洪锋和林斌曾在谷歌音乐项目中有过良好合作。而黄江吉和林斌是微软的同事,五六年前,正是时任微软亚洲工程院工程总监的林斌说服黄从美国回到微软亚洲工程院。 2010年,林斌从谷歌辞职后,选定的创业方向正是在谷歌时负责的移动互联网领域。此时,iPhone和Android手机等新型终端的普及让智能机时代的大潮势不可挡,基于网络的数据传输也可能会改变以往短信、电话、视频、游戏等多种用户行为。就这样,大家一拍即合,成立小米。

之所以取名“小米”,是取Mobile Internet的首字母。这个看似简单的名字还包含了这个公司的雄心:米是中国人的必需品,他们希望自己的产品成为未来手机上的装机必备,就像PC时代的QQ。同时,他们希望米聊未来有机会在手机上颠覆QQ。

并非另一个Kik

虽然选定移动互联网作为创业方向,但当林斌、洪锋、黄江吉等人离职聚在一起时,具体做什么产品并未规划好。

唯一的办法是先多方尝试。小米读书、小米分享、小米司机、小米便签,都是在这个摸索过程中的产物。这些产品虽然都满足了某些需求,也赢得不错口碑,但当去年年底的一天,大家用上了一位同事做出来的米聊,顿时觉得眼前一亮。

米聊正是受了当时用户数飞速上涨的新兴应用Kik的启发,加拿大人Ted Livingston带领团队所做出的这款手机通讯录聊天应用于去年10月19号发布,在发布后 15 天内就达到了100 万用户,今年1月用户数超过300万。

Kik所带给小米团队的最大启发,无疑是和手机通讯录的紧密绑定:当一个人使用Kik之后,只要他手机通讯录中有好友正在使用Kik,就能自动添加为好友。这相当于省略了一个相互询问账号再添加的复杂过程。而且,无论一个用户使用多少社交网站,一共有多少好友,但是进入他通讯录中的肯定都是最核心的那一群。

“对比5年前的手机和现在的手机,平台、功能等方面已经是天壤之别,手机通讯录却基本没有任何改进。”洪锋说,这让他们觉得大有所为。

做了一些市场调研和头脑风暴之后,小米团队决定尽可能地把资源投入米聊的开发,其他几款产品降低更新速度。

但毫无意外的,米聊团队被问到最多的一个问题是:我们为什么需要米聊?

Kik在美国崛起的原因可以归结为:手机通讯录转移关系;跨运营商与手机平台;可以查看已发与已读状态;;国外短信昂贵,登录Kik只需要很小的流量但能免费发信息,很有吸引力。

在国内,短信费用并不高。更重要的是,很多用户已经把熟人关系链全部迁移至QQ,他们能在QQ上找到从小学同学到合作伙伴的几乎所有关系,腾讯的这种优势自然顺延到了手机QQ。

但洪锋反问,那为什么大家换号之后,还需要在QQ上跟别人说,我换号了呢?

的确,QQ在人际沟通中发挥了重要作用,但是当你的好友没登录QQ你又想联系他时,弊端就显示出来了。洪锋理想中的手机沟通工具,便是和通讯录紧密相连,换号之后不用群发信息告知,别人一样能在上面找到你,给你发短信打电话不受任何影响。

于是,对米聊团队来说,Kik带来的只是最初始的启发,后续仔细研究用户习惯,打造一个适合中国用户的移动沟通工具才最重要。因此,现有的米聊版本某些基础功能和Kik一样:同样是和通讯录紧密绑定,可以设置头像,显示信息“发送”、“已读”,还加上了对方“正在输入”的状态。这些小细节能够带来网络聊天时难得的互动感,“就像你面对面跟一个人说话,他点了点头或笑了一下,你知道他听见了。”黄江吉说。

但很多地方已经不尽相同。比起Kik,米聊有更完整的即时通讯体验:显示好友的在线状态和上次在线时间,随时随地把手机上拍的照片和音乐,甚至录一段声音分享给好友。

更重要的是,安装米聊之后,它会引导你从开心或人人导入个人资料和好友关系、制作自己的“名片”—这些实名制的社区通常能有用户的姓名、照片、工作单位或者学校。如此一来,米聊也相当于一个实名制的数据库。它不仅实现了好友推送:“你可能认识的人”,也就是通讯录中有你的手机号、但你可能已经丢了他号码的朋友。用户也可以根据米聊号、用户名、学校、单位等信息来进行查询。

另一个问题是,单一的聊天功能可能会导致活跃度下降。为了制造话题,增加用户之间的交流和互动,米聊添加了广播墙的功能,类似于微博。不同之处在于,当下的微博是按媒体形态运作,每个人发微博时都会很有压力,想发“有意义”的内容。但米聊上的广播只是针对封闭链条的好友,可以随心所欲地记录生活琐事。如果用户看到好友转发了别人的消息,还可以点过去看到那人的名片,决定要不要添加好友。

这些看起来,像是一个移动SNS和即时通讯工具的结合体?

洪锋并不愿意给米聊打下任何标签。在他看来,米聊不应该自我局限,现在的设想是希望让用户在米聊中顺畅完成诸多沟通事宜:了解好友动态和近况,聊天,发信息,传图片,即便好友不在线,信息能马上转换为短信发出去。但未来仍要不断探索和满足移动时代的用户需求。

成为商品

创业以来,让黄江吉最深有感触的是计划永远赶不上变化。

起初,他们想做的其实只是基于Android和iPhone平台的应用,可是当决定投入资源开发米聊之后,才发现这种基于关系链的产品,必须要做全平台,覆盖尽可能多的用户群。毕竟,一个用户使用一个新聊天工具的最大理由,是身边有足够多或足够重要的好友在使用。

如此一来,塞班平台的人员招聘和产品开发仓促上马。iPhone和Android版本于2010年12月底就已经推出,而塞班V3版和V5版则晚了不少,分别在今年1月12日和1月26日上线,人手不足导致它们的第一版本的界面都极其简陋。直到一个多月后新版陆续开发出来,黄江吉才舒了口气:起码终于能显示个性化头像了。

人手不足的压力一直让黄江吉的技术部门处于紧张状态,很多功能虽然规划好,但是起初暂时没有实现。比如米聊以前是单向添加好友、无非对方验证,现在终于进化为双向验证,保证私密性。有的方面就暂时舍弃:针对Android,米聊只开发适配Android2.1及以上的版本,放弃了大概15%的用户市常

但这并没有让他们放松更新频率,他们坚信互联网时代的产品策略:迅速推出,快速迭代。好处是,在迅疾变化的移动互联网行业,时时收集用户反馈能够降低试错成本,迅速作出调整。

最开始,米聊的设计是让米聊号码和手机、手机号同时绑定,而非基于同一ID登录。这意味着当一个用户换手机后,会分配一个新的米聊号,得重新添加好友。这让很多用户非常困扰。得到这种反馈之后,新的设计和调整已经完成。

不过,对于黄江吉团队来说,最大压力是如何让米聊在各种复杂的网络环境中,能稳定、实时的传输信息。QQ的多年探索已经在这方面积累了深厚的技术。这注定是个漫长而艰难的过程。这种强大的挑战却让团队更为兴奋,正如同雷军在微博上所说,“我理解的极致就是做出超越自己能力的东西,只有极致的东西才能超越用户的想象,才会有良好的口碑”。 如今,若是仔细观察,米聊和腾讯旗下的微信已经走出不同路径。米聊更偏重于即时通讯的体验;而微信主要立足于QQ的用户群,为他们提供一个轻量级的应用选择,它更试图探索介于即时通讯和邮件之间“短邮”路径:和腾讯微博私信打通,也不透露信息是否已读,降低用户的收信压力。

但这注定不是两款单一产品的较量。未来,米聊如何与小米科技旗下其他产品相整合值得期待、迄今为止,除了米聊、小米读书、小米分享、小米司机、小米便笺之外,小米团队并未将其他项目公开。但坊间消息表明,MIUI、迷人浏览器等产品都是小米科技旗下。一个可以参考的数字是:小米科技现在有130人左右,米聊研发团队规模只为30余人。

在小米科技的论坛里,有人曾问:UCWEB将自己定位为终端和云端的管道工,你们的定位是什么?小米科技的回答是:他当马里奥,我做任天堂。大家猜测,这意味着小米科技可能会进军硬件领域,开辟如iPhone那样的产业链。

有消息称,在今年年中,小米科技将会有重要的战略发布会,发布全公司战略。在2011年4月6日小米科技成立一周年时,雷军也在微博上表示“我们即将正式发布我们的产品,行百里者半于九十,最重要的关头来了”。看起来,谜底要到一两个月后才会揭开。这大概是近期中国移动互联网行业最有想象空间的事。

分类: 9其他 标签: ,

无觅相关文章插件,快速提升流量