【郭林专刊】:需求把握和正确决策

标签: 需求 正确 决策 | 发表时间:2012-01-18 15:29 | 作者:guolin6315
出处:http://blog.csdn.net
 

作者:万维雅

编者按:国内互联网公司里,百度的产品一向为人称道。尤其是其搜索引擎的周边产品,比如百科、知道、贴吧等一系列产品。在不少资深互联网用户和专家眼中,这些产品应该是搜索引擎的标准配置。然而到底是什么让百度能够规划和设计出这么多优秀的产品,为什么他的竞争对手在这些领域根本无法与其匹敌?我们邀请百度的产品经理亲自为我们揭开谜底。

任何一个产品人员,要理清产品的分析和决策思路,首先要弄清楚什么是产品。产品的核心价值,是用户使用该产品的终极奥义。例如军大衣和比基尼都是用来穿的,但是前者的核心价值是御寒,后者的核心价值是性感。手机虽然变化多端,但核心价值是语音沟通,所以如果通话音质不行的话,这个手机再炫再酷,也会被用户舍弃。

互联网产品也是同样道理。很多产品在外表看起来是一样的,但是如果深挖的话,用户为什么要用?最根本的好处是什么?答案是非常迥异的。例如一个是百度知道,另一个假设是在线购物网站的疑难问答平台,产品形式可以相似,但本质完全不同。前者的核心价值在于“让人们更便捷的获取信息,找到所求”,而后者则应该是一种高效的在线客服手段。这个本质差异就导致了很多要点和细节上的产品决策差异。

所以对一个产品进行分析之前,首要问题,便是弄清楚用户为什么要用这个产品,它带给用户最根本的好处是什么。

要解答这样一个问题,并不容易,很多失败的产品在一开始就没弄明白用户用它的理由,注定了后面的失败。在产品研发前,百度搜索引擎产品人员首先要解答这个问题。

百度产品决策原则

搜索引擎产品部门在招聘产品人员时,应聘人员尤其是对互联网充满热情的学生常常积极地抛出自己的各种想法,却没有仔细分析为什么做?该不该做?

外界也常常有人提出一些疑问,为什么百度不做这个产品?为什么百度不做那个产品?

在《李彦宏的百度世界》里,阐述过百度的产品决策原则:“无论百度推出什么产品,总是遵循三个原则:有需求、有优势、有收益。”

首先是需求导向。无论是客户需求还是用户需求,归根到底都是需求。先有需求,才再有动作。借用一个经典小故事,有两个卖鞋的人去岛屿上开拓市场,一个回来后跟老板说:“那里没有市场,根本没有人穿鞋。”另一个回来后跟老板说:“那里市场可大了,大家都还没有鞋。”这个问题如果放在产品决策上,应先问需求,先摸清楚对于这群用户来说,他们穿鞋的好处、不穿鞋的好处,再决定下一步。

其次,在有效满足需求方面,我们有无优势。用户体验是一个完整的过程,对于用户的终极需求的满足,才是真正有价值的。

“视频搜索”这个想法在搜索引擎产品部很早就有考虑和接触,但早期互联网资源非常有限,资源的下载是一个致命的瓶颈,搜索做得再好,对用户最终获取并观看这个视频并无多大的帮助,因此当时没有介入;到了后期,由于专业视频分享网站的兴起,用户视频体验得到了巨大的提升,且资源众多,从用户搜索关键词里很容易能发现大量视频搜索需求,百度在搜索方面的优势能为找视频的用户提供更多更好的便利,而网页搜索通用搜索解决方案并不能完全满足视频搜索的特殊需求,因此视频搜索诞生的时机到了。后续经过产品设计、产品研发,成为一款大量用户使用的搜索产品就是顺理成章的事情了。

最后是要符合百度使命,专注于搜索,增强公司的核心竞争力,才能保持旺盛的生命力,并且推动搜索领域更深远的发展。现在大家看到,百度网页搜索、MP3搜索、图片搜索、知道、贴吧、百科等每一款产品都拥有庞大的用户群,并互相关联、互相促进——这并不是偶然现象,也不是百度为了整合产品而做的整合,而是它们的诞生恰恰就是为了有效地满足用户需求的,它们本身构成了搜索引擎的整体架构,也是百度最核心的产品竞争优势。

产品的创新思路

为什么要创新?李彦宏说过,“创新的目的是为了更好地满足需求,不为创新而创新”。产品和技术部每天都在进行着创新的尝试,但新技术、新功能、新概念只是工具或手段,产品设计更关注“为什么创新”。

百度产品体系的重大创新是搜索社区,百度的贴吧、知道、百科、空间等,构建了一个完整的搜索社区体系,我们回顾一下当年贴吧上线时首页的那句话:互联网上的信息,和人脑中的信息相比,只是沧海一粟——百度过去几年的经验证明,类似贴吧这样的搜索社区模式,在将人们的隐性知识转化为显性知识,并借以提升搜索引擎的核心价值方面,是极其成功的。所以,贴吧是一个伟大的创新,相对全球而言更是独一无二的,而贴吧所代表的搜索社区的产品创新模式和不懈实践探索,更是百度对搜索领域做出的杰出创新贡献。

有些人认为横空出世的东西才是创新,只有推倒重来的东西才是创新,但是不要忽略一点,有些创新是“润物细无声”的,有些创新是细节的,但它们至关重要,同样推动着某一领域的进步。

比如在图片搜索领域,很多人都会觉得以图搜图、颜色筛选、人脸识别这些内容识别技术看起来很新颖,认为只有提供了这样的功能才是创新。在百度产品部的图片搜索组,早期几乎每一位新同事都对这些服务好奇,但经过了一段时间的用户行为分析和思考,才能理解使用筛选功能并不一定是有效解决用户问题的最好方法,应用各种用户需求识别技术、图片识别技术优化搜索结果排序,将用户更需要的图片直接排列在用户的眼前,这也是重要“润物细无声”创新。

对产品的正确决策

产品经理或产品设计师的责任就是保证产品的成功,从产品的决策到产品是否能符合预期地完成开发上线,当然最核心的是在前期需求,解答一个产品为什么做和做成什么样子。

产品人员在把握产品决策原则的基础上,要有敏锐的洞察力,要能作出正确的判断,还得具备两个必要条件。

第一,他自己就是产品的忠实的用户。百度产品部门的每位同事,对互联网应用充满热情和兴趣,主动地成为相关产品领域最熟练的一线用户,带着真实的使用目的,能和用户站在一起,而不是带着审视检查的角度,后者往往当局者迷,不能洞悉真正的需求。比如贴吧的产品人员在学生时代不是骨灰级论坛潜水者就是知名论坛的风云人物;网页搜索的某位产品人员搜索引擎爱好者,进入百度前就热衷于发现各种搜索引擎妙用。

第二,他必须能站在大多数普通用户的角度去思考问题。百度产品部门不要求任何专业背景、技术背景,只要你能精确地把握和尊重普通用户的体验,在这一点上的要求近乎苛刻。你不能因为你懂得各种搜索技巧,就期望普通网民像你一样。当设计常用功能时,这样的思考是被拒绝的:“如果用户不明白,可以去看帮助文档”“这个问题用快捷键去解决”……而实际上面临的判断要难得多。

当然,搜索引擎作为信息获取的入口点,汇集千千万万网民的需求和使用习惯,百度的产品人员更能通过直接的数据来分析用户的行为,从他们比较集中的搜索请求中发现产品问题和产品诉求。这也是制胜的法宝之一。

有很多不明白互联网产品工作的人问:“怎么保证你的想法是客观的?”“怎么保证你需要的就是大众需要的?”面对这样的问题,很容易让人想到去做调研,调研的方法很容易让人想到是问卷调查。但实际上,产品设计和改进的很多方面是你没法通过直接问用户得到你想要的答案的,就像你没法通过直接询问用户的每一次搜索需要什么来指导搜索结果更准确。其实,用户实际的行动已经实实在在地告诉了产品人员,比他自己说得更多、更真。当互联网产品的用户群体达到一定规模,他们的行为数据具备统计意义时,会比纯粹的市场调研行为更加可靠和直接,那是非常珍贵的财富。

举个例子,我们通过用户行为的数据分析,发现网页搜索的用户行为与图片搜索的用户行为不一样:网页搜索的用户大多有特定目标,我们帮助这些用户快速地找到他想要的那条搜索结果以完成这次搜索,比如某某版本软件下载;而图片搜索很大比例的用户并无特定目标,他想欣赏一组图片搜索结果,比如某个旅游城市。这个时候,对每个图片搜索结果都要一一点击,打开新窗口不适应连续浏览体验,于是我们在搜索结果打开的模式上做了改进,这里面也有大量的数据分析,来决定什么样的模式对全体用户的总收益是最大的。

(本文来自《程序员》杂志0910期)

作者:guolin6315 发表于2012-1-18 15:29:51 原文链接
阅读:8 评论:0 查看评论

相关 [需求 正确 决策] 推荐:

【郭林专刊】:需求把握和正确决策

- - CSDN博客推荐文章
编者按:国内互联网公司里,百度的产品一向为人称道. 尤其是其搜索引擎的周边产品,比如百科、知道、贴吧等一系列产品. 在不少资深互联网用户和专家眼中,这些产品应该是搜索引擎的标准配置. 然而到底是什么让百度能够规划和设计出这么多优秀的产品,为什么他的竞争对手在这些领域根本无法与其匹敌. 我们邀请百度的产品经理亲自为我们揭开谜底.

影响架构决策的非功能性需求

- - 博客园_知识库
  英文原文: Non-functional Requirements in Architectural Decision Making.   本文由《IEEE Software》杂志首发,现在由InfoQ和IEEE Computer Society联合向您呈现.   在软件工程中,非功能性需求(nonfunctional requirements,简称NFRs)与软件架构(software architectures,简称SAs)之间存在着紧密联系.

确定,分解,评估,决策:四步走推进你的需求分析

- 京哲 - 所有文章 - UCD大社区
确定需求往往是承接需求调研而来,目的是搞清楚产品部门究竟要解决的是什么问题,有时候业务部门会要求你能为他们做到些什么,但这种要求往往过于含糊,你还需要再和他们多了解一些信息,才有可能真正了解他们希望得到是什么,避免发生买个MBP回来只为装了winxp玩扫雷这样的杯具……. 在确定环节中,这只完成了一半的工作;接下来我们需要知道对应这个需求,会有哪些角色来使用,我们需要能够对这些角色涉及到的不同需求做出细分.

再谈需求

- - 人月神话的BLOG
谈需求工程方面的文章前面写过很多,本文仅做最近思考的一些点滴记录. 首先我们谈下业务建模层面,对于从用户提出最初的业务需求到交付一个完整的系统,在建模层面涉及到两个层面的抽象,其一就是业务建模解决现实世界本身的抽象描述,其二就是软件架构设计,解决从业务模型到IT架构模型的第二次转换. 在早些时候我们看到这两个层面的建模内容都由系统分析员承担或完成,在岗位不断细分后我们看到反而会出现忽视了业务建模的问题.

正确理解ThreadLocal

- - Java - 编程语言 - ITeye博客
转自: http://www.iteye.com/topic/103804. 首先,ThreadLocal 不是用来解决共享对象的多线程访问问题的,一般情况下,通过ThreadLocal.set() 到线程中的对象是该线程自己使用的对象,其他线程是不需要访问的,也访问不到的. 另外,说ThreadLocal使得各线程能够保持各自独立的一个对象,并不是通过ThreadLocal.set()来实现的,而是通过每个线程中的new 对象 的操作来创建的对象,每个线程创建一个,不是什么对象的拷贝或副本.

需求变化与IoC

- - 酷壳 - CoolShell.cn
【感谢 Todd投递本文 – 微博帐号:@ weidagang 】. 程序员XX遭遇车祸成植物人,医生说活下来的希望只有万分之一,唤醒更为渺茫. 可他的Lead和亲人没有放弃,他们根据XX工作如命的作风,每天都在他身边念:“XX,需求又改了,该干活了,你快来呀. ”,奇迹终于发生了,XX醒来了,第一句话:“需求又改了.

进化而来的需求

- - 极客公园-GeekPark
[核心提示]需求是可以创造,可以进化的. 在需求的“博尔赫斯库”中,我们要做的,仅仅是模拟规则,让需求,优胜劣汰. 如果本文的标题和导语引起了坐在电脑前的你的兴趣,同时又产生了些许的疑惑,那么恭喜我自己,我的目的达到了 (真是恶趣味……). 那么,在对它们进行解释之前,还容我卖个关子,先从几个有趣的见闻讲起.

谈需求和设计

- - 人月神话的BLOG
在这里再谈下需求和设计的边界问题,我们最终的业务系统实现出现的偏差,究竟是需求的问题还是设计的问题. 如果边界不清楚则很难明确的区分. 对于需求本身有原始需求,用户需求,产品需求和系统需求的各种阶段;而对于需求的过程也本身存在原始需求的收集,需求分析,需求挖掘,和需求相关的业务建模. 而对于设计同样存在总体的企业架构设计,到单个应用的总体设计和架构设计,概要设计和详细设计.

解决方案与需求

- - 扯氮集--上海魏武挥的博客 - 扯氮集--上海魏武挥的博客
曾经有一个很有名的段子,大致意思就是说在汽车尚未出现的马车时代,你去做消费者调研,只会得到这样的答案:我需要一匹更快的马,而不会得到:我需要汽车. 因为对于消费者来说,他从来没有看到过汽车,怎么可能回答你需要汽车呢. 这个段子,似乎充分说明了,创新,尤其是颠覆式创新、破坏性创新是不可能通过需求调研出来的.

如何做需求分析

- - 人人都是产品经理
这段时间我做了两个大项目,其中一个项目算是商业模式上和使用规范上的调整,另一个项目是之前功能的重做,为什么重做我下面会说到. 关于需求分析,我认为把需求抽象成产品功能花费的时间占到了软件开发周期的40%,产品设计到评审完的时间大概是20%,也就是说实际开发之前产品团队介入的工作占据项目的60%,在需求分析阶段我有一些个人观点.