精华内容
下载资源
问答
  • 因此,知识将成为数据更为重要的资产 。前几年大数据时代到来的时候,大家都说“得数据者得天下”。去年,微软的沈向洋博士曾经说过“懂语言者得天下”。而我曾经论述过,机器要懂语言,背景知识不可或缺。因此,...

    640?wx_fmt=jpeg

    CSDN 出品的《2018-2019 中国人工智能产业路线图》V2.0 版即将重磅面世!

    V1.0 版发布以来,我们有幸得到了诸多读者朋友及行业专家的鼎力支持,在此表示由衷感谢。此次 V2.0 版路线图将进行新一轮大升级,内容包括 3 大 AI 前沿产业趋势分析,10 位 AI 特邀专家的深度技术分析,15 家一线互联网企业的 AI 实力大巡展,以及 20 个 AI 优秀应用案例,力求为读者呈现更全面的中国人工智能产业发展概况和趋势判断。

    V2.0 版将于 11 月 8 日举办的 2018 AI 开发者大会上正式发布,在此之前,我们将不间断公布精要内容,以飨读者。此为 V2.0 版中深度技术分析系列稿件第 3 篇,作者为 CSDN 特邀 AI 专家——复旦大学教授肖仰华。

    作者简介:肖仰华博士,复旦大学计算机科学与技术学院教授,博士生导师,知识工场实验室负责人。

     

    一、什么是知识图谱

     

    ▌1.1 知识图谱的定义

     

    知识图谱是什么?本质上是一种大规模语义网络。理解知识图谱的概念,有两个关键词。

     

    首先是语义网络。语义网络表达了各种各样的实体、概念及其之间的各类语义关联。

     

    640?wx_fmt=png

    图1. 知识图谱示例

     

    比如“C罗”是一个实体,“金球奖”也是一个实体,他们俩之间有一个语义关系就是“获得奖项”。“运动员”、“足球运动员”都是概念,后者是前者的子类(对应于图中的subclassOf 关系)。

     

    理解知识图谱的第二个关键词是“大规模”。语义网络并非新鲜事物,早在上个世纪七八十年代知识工程盛行之时,就已存在。相比较于那个时代的语义网络,知识图谱规模更大。

     

    从2012年Google提出知识图谱直到今天,知识图谱技术发展迅速,知识图谱的内涵远远超越了其作为语义网络的狭义内涵。当下,在更多实际场合下,知识图谱是作为一种技术体系,指代大数据时代知识工程的一系列代表性技术进展的总和。去年我国学科目录做了调整,首次出现了知识图谱的学科方向,教育部对于知识图谱这一学科的定位是“大规模知识工程”,这一定位是十分准确且内涵丰富的。这里需要指出的是知识图谱技术的发展是个持续渐进的过程。从上个世纪七八十年代的知识工程兴盛开始,学术界和工业界推出了一系列知识库,直到2012年Google推出了面向互联网搜索的大规模的知识库,被称之为知识图谱。

     

    ▌1.2与传统知识表示的区别

     

    理解今天的知识图谱内涵,是不能割裂其历史脐带的。上世纪七八十年代的各种知识表示与我们今天的知识图谱到底有着本质差别。传统语义网络与知识图谱的差别首先表现在其规模上。

     

    知识图谱是一种大规模语义网络,与上世纪七八十年代的各类语义网络相比较,最显著的差异就是规模差异。推而广之,以知识图谱为代表的大数据时代的各种知识表示与传统的知识表示的根本差别首先体现在规模上。传统知识工程一系列知识表示都是一种典型的“小知识”(smallknowledge)。

     

    而到了大数据时代,受益于海量数据、强大计算能力以及群智计算,我们如今能够自动化构建、或者众包构建大规模、高质量知识库,形成所谓的“大知识”(bigknowledge,合肥工业大学的吴兴东教授在很多场合下也提到类似观点)。所以知识图谱与传统知识表示在浅层次上的区别,就是大知识与小知识的差别,是在规模上的显而易见的差别

     

    更深刻地进行分析就会发现,这样的一个知识规模上的量变带来了知识效用的质变

     

    知识工程到了上世纪八十年代之后就销声匿迹了。根本原因在于传统知识库构建主要依靠人工构建、代价高昂、规模有限。举个例子,我国的词林辞海是上万名专家花了10多年编撰而成的,但是它只有十几万词条。而现在任何一个互联网上的知识图谱,比如DBpedia,动辄包含上千万实体。人工构建的知识库虽然质量精良,但是规模有限。有限的规模使得传统知识表示难以适应互联网时代的大规模开放应用的需求。

     

    互联网应用的特点在于:

     

    • 一、规模巨大,我们永远不知道用户下一个搜索关键词是什么;

    • 二、精度要求相对不高,搜索引擎从来不需要保证每个搜索的理解和检索都是正确的;

    • 三、简单知识推理,大部分搜索理解与回答只需要实现简单的推理,比如搜索刘德华推荐歌曲,是因为知道刘德华是歌星,至于“姚明老婆的婆婆的儿子有多高”这类的复杂推理在实际应用中所占比率是不高的。

     

    互联网上的这种大规模开放应用所需要的知识很容易突破传统专家系统由专家预设好的知识库的知识边界。这一定程度上回答了,为何谷歌在2012年这个时间节点推出知识图谱,利用一个全新名称以表达与传统知识表示毅然决裂的态度。

     

    二、知识图谱的重要性

     

    知识图谱是实现机器认知智能的基础。机器认知智能的两个核心能力:“理解”和“解释”,均与知识图谱有着密切关系。首先需要给机器“理解与解释”提出一种解释。我认为机器理解数据的本质是建立起从数据到知识库中的知识要素(包括实体、概念和关系)映射的一个过程

     

    比如如果我说到“2013年的金球奖得主C罗”这句话,我们之所以说自己理解了这句话,是因为我们把“C罗”这个词汇关联到我们脑子中的实体“C罗”,把“金球奖”这个词汇映射到我们脑中的实体“金球奖”,然后把“得主”一词映射到边“获得奖项”这个关系。我们可以仔细体会一下我们的文本理解过程,其本质是建立从数据(包括文本、图片、语音、视频等)到知识库中的实体、概念、属性映射的过程。

     

    再来看人类是如何“解释”的。比如我问“C罗为什么那么牛?”,可以通过知识库中的“C罗获得奖项金球奖”以及“金球奖地位影响力最大的足球奖项之一”这两条关系来解释这一问题。

     

    这一过程的本质就是将知识库中的知识与问题或者数据加以关联的过程。有了知识图谱,机器完全可以重现我们的这种理解与解释过程。有过一定计算机研究基础的,是不难完成上述过程的数学建模的。知识图谱对于机器认知智能的重要性也体现在下面几个具体方面。

     

    ▌2.1 知识图谱使能机器语言认知

     

    知识图谱对机器认知智能的必要性还可以从若干具体问题来进行阐述。首先,我们来看机器认知的核心能力之一:自然语言理解

     

    我的观点是机器理解自然语言需要类似知识图谱这样的背景知识。自然语言是异常复杂的:自然语言有歧义性、多样性,语义理解有模糊性且依赖上下文。机器理解自然语言困难的根本原因在于,人类语言理解是建立在人类的认知能力基础之上的,人类的认知体验所形成的背景知识是支撑人类语言理解的根本支柱。

     

    我们人类彼此之间的语言理解就好比是根据冰山上浮出水面的一角来揣测冰山下的部分。我们之所以能够很自然地理解彼此的语言,是因为彼此共享类似的生活体验、类似的教育背景,从而有着类似的背景知识。冰山下庞大的背景知识使得我们可以彼此理解水面上有限的几个字符。我们可以做个简单的思想实验,假如现在有个外星人坐在这里听我讲报告,他能听懂么?我想还是很困难的,因为他没有在地球上生活的经历,没有与我相类似的教育背景,没有与我类似的背景知识库。

     

    再举个很多人都有体会的例子,我们去参加国际会议时,经常遇到一个尴尬的局面,就是西方学者说的笑话,我们东方人很难产生共鸣。因为我们和他们的背景知识库不同,我们早餐吃烧饼、油条,西方吃咖啡、面包,不同的背景知识决定了我们对幽默有着不同的理解。所以语言理解需要背景知识,没有强大的背景知识支撑,是不可能理解语言的。要让机器理解我们人类的语言,机器必需共享与我们类似的背景知识。

     

    实现机器自然语言理解所需要的背景知识是有着苛刻的条件的:规模足够大、语义关系足够丰富、结构足够友好、质量足够精良

     

    以这四个条件去看知识表示就会发现,只有知识图谱是满足所有这些条件的:知识图谱规模巨大,动辄包含数十亿实体;关系多样,比如在线百科图谱DBpedia包含数千种常见语义关系;结构友好,通常表达为RDF三元组,这是一种对于机器而言能够有效处理的结构;质量也很精良,因为知识图谱可以充分利用大数据的多源特性进行交叉验证,也可利用众包保证知识库质量。所以知识图谱成为了让机器理解自然语言所需的背景知识的不二选择。

     

    ▌2.3 知识图谱使能可解释人工智能

     

    知识图谱对于认知智能的另一个重要意义在于:知识图谱让可解释人工智能成为可能

     

    “解释”这件事情一定是跟符号化知识图谱密切相关的。因为解释的对象是人,人只能理解符号,没办法理解数值,所以一定要利用符号知识开展可解释人工智能的研究。可解释性是不能回避符号知识的

     

    我们先来看几个解释的具体例子。比如,我若问鲨鱼为什么可怕?你可能解释说:因为鲨鱼是食肉动物,这实质上是用概念在解释。若问鸟为什么能飞翔?你可能会解释因为它有翅膀。这是用属性在解释。若问鹿晗关晓彤前些日子为什么会刷屏?你可能会解释说因为关晓彤是鹿晗的女朋友。这是用关系在解释。我们人类倾向于利用概念、属性、关系这些认知的基本元素去解释现象,解释事实。而对于机器而言,概念、属性和关系都表达在知识图谱里面。因此,解释离不开知识图谱。

     

    ▌2.4 知识引导将成为解决问题的主要方式

     

     知识图谱的另一个重要作用体现在知识引导将成为解决问题的主要方式。前面已经多次提及用户对使用统计模型来解决问题的效果越来越不满意了,统计模型的效果已经接近“天花板”,要想突破这个“天花板”,需要知识引导。

     

    举个例子,实体指代这样的文本处理难题,没有知识单纯依赖数据是难以取得理想效果的。比如“张三把李四打了,他进医院了”和“张三把李四打了,他进监狱了”,人类很容易确定这两个不同的“他”的分别指代。因为人类有知识,有关于打人这个场景的基本知识,知道打人的往往要进监狱,而被打的往往会进医院。但是当前机器缺乏这些知识,所以无法准确识别代词的准确指代。很多任务是纯粹的基于数据驱动的模型所解决不了的,知识在很多任务里不可或缺。比较务实的做法是将这两类方法深度融合。

     

    ▌2.5 知识将显著增加机器学习能力

     

    知识对于认知智能又一个很重要的意义就是将显著增强机器学习的能力。

     

    当前的机器学习是一种典型的“机械式”学习方式,与人类的学习方式相比显得比较笨拙。我们的孩童只需要父母告知一两次:这是猫,那是狗,就能有效识别或者区分猫狗。而机器却需要数以万计的样本才能习得猫狗的特征。

     

    我们中国人学习英语,虽然也要若干年才能小有所成,但相机器对于语言的学习而言要高效的多。机器学习模型落地应用中的一个常见问题是与专家知识或判断不符合,这使我们很快陷入进退两难的境地:是相信学习模型还是果断弃之?机器学习与人类学习的根本差异可以归结为人是有知识的且能够有效利用知识的物种

     

    我相信,未来机器学习能力的显著增强也要走上充分利用知识的道路。符号知识对于机器学习模型的重要作用会受到越来越多的关注。这一趋势还可以从机器智能解决问题的两个基本模式方面加以论述。

     

    机器智能的实现路径之一是习得数据中的统计模式,以解决一系列实际任务。另一种是专家系统,专家将知识赋予机器构建专家系统,让机器利用专家知识解决实际问题。如今,这两种方法有合流的趋势,无论是专家知识还是通过学习模型习得的知识,都将显式地表达并且沉淀到知识库中。再利用知识增强的机器学习模型解决实际问题。这种知识增强下的学习模型,可以显著降低机器学习模型对于大样本的依赖,提高学习的经济性;提高机器学习模型对先验知识的利用率;提升机器学习模型的决策结果与先验知识的一致性。

     

    因此,知识将成为比数据更为重要的资产。前几年大数据时代到来的时候,大家都说“得数据者得天下”。去年,微软的沈向洋博士曾经说过“懂语言者得天下”。而我曾经论述过,机器要懂语言,背景知识不可或缺。因此,在这个意义下,将是“得知识者得天下”。如果说数据是石油,那么知识就好比是石油的萃取物。如果我们只满足卖数据盈利,那就好比是直接输出石油在盈利。但是石油的真正价值蕴含于其深加工的萃取物中。石油萃取的过程与知识加工的过程也极为相像。都有着复杂流程,都是大规模系统工程。知识工程的鼻祖,费根鲍姆曾经说过的一句话“knowledge is the power inAI”。

     

    三、知识图谱的生命周期

     

    640?wx_fmt=png

    图2. 知识图谱的生命周期

     

    知识图谱系统的生命周期包含四个重要环节:知识表示、知识获取、知识管理与知识应用这四个环节循环迭代。

     

    知识应用环节明确应用场景,明确知识的应用方式。

     

    知识表示定义了领域的基本认知框架,明确领域有哪些基本的概念,概念之间有哪些基本的语义关联。比如企业家与企业之间的关系可以是创始人关系,这是认知企业领域的基本知识。知识表示只提供机器认知的基本骨架,还要通过知识获取环节来充实大量知识实例。比如乔布斯是个企业家,苹果公司是家企业,乔布斯与苹果公司就是“企业家-创始人-企业”这个关系的一个具体实例。

     

    知识实例获取完成之后,就是知识管理。这个环节将知识加以存储与索引,并为上层应用提供高效的检索与查询方式,实现高效的知识访问。

     

    四个环节环环相扣,彼此构成相邻环节的输入与输出。在知识的具体应用过程中,会不断得到用户的反馈,这些反馈会对知识表示、获取与管理提出新的要求,因此整个生命周期会不断迭代持续演进下去。

     

    ▌3.1 知识表示

     

    在知识表示方面,常用三元组(主语、谓词、宾语)表示知识图谱。如三元组<七里香,歌曲原唱,周杰伦>表示“七里香这首歌曲的原唱是周杰伦”这一知识。需要强调一点,知识图谱只能表达一些简单的关联事实,但很多领域应用的需求已经远远超出了三元组所能表达的简单关联事实,实际应用日益对于利用更加多元的知识表示丰富和增强知识图谱的语义表达能力提出了需求

     

    这一趋势首先体现在对于时间和空间语义的拓展与表达方面。

     

    有很多知识和事实是有时间和空间条件的,比如说“美国总统是特朗普”这个事实的成立是有时间条件的,十年前美国的总统不是特朗普,十年之后应该也不大可能是特朗普。还有很多事实是有空间条件的,比如“早餐是烧饼与油条”这件事,在中国是这样,但是在西方并非如此,西方的早餐可能是咖啡、面包。

     

    从时空维度拓展知识表示对很多特定领域具有较强的现实意义。比如在位置相关的应用中,如何将POI(Point of Interest)与该POI相关实体加以关联,成为当下拓展POI语义表示的重要任务之一。比如将“邯郸路220号”(复旦大学地址)关联到“复旦大学”是十分有意义的。在互联网娱乐领域,粉丝们往往不仅仅关心某个明星的妻子是谁,可能更关心明星的前任妻子、前任女友等信息,这些应用都对事实成立的时间提出了需求。

     

    第二、增强知识图谱的跨媒体语义表示。

     

    当前的知识图谱主要以文本为主,但是实际应用需要有关某个实体的各种媒体表示方式,包括声音、图片、视频等等。比如对于实体“Tesla Model S”,我们需要将其关联到相应图片和视频。知识图谱时空维度拓展在物理实现上可以通过定义四元组或者五元组加以实现。跨媒体表示可以通过定义相关的属性加以实现。知识图谱的语义增强总体上而言将是未来一段时间知识表示的重要任务。知识图谱作为语义网络,侧重于表达实体、概念之间的语义关联,还难以表达复杂因果关联与复杂决策过程。

     

    如何利用传统知识表示增强知识图谱,或者说如何融合知识图谱与传统知识表示,更充分地满足实际应用需求,是知识图谱领域值得研究的问题之一。在一些实际应用中,研究人员已经开始尝试各种定制的知识表示,在知识图谱基础上适当扩展其他知识表示是一个值得尝试的思路。

     

    ▌3.2 知识获取

     

    640?wx_fmt=png

    图3.知识获取的基本步骤

     

    知识的获取是个系统工程,流程复杂,内涵丰富,涉及到知识表示、自然语言处理、数据库、数据挖掘、众包等一系列技术。知识获取的基本步骤如图3所示:

     

    第一步是模式(Schema)设计这一步是传统本体设计所要解决的问题。基本目标是把认知领域的基本框架赋予机器。在所谓认知基本框架中需要指定领域的基本概念,以及概念之间subclassof关系(比如足球领域需要建立“足球运动员”是“运动员”的子类);需要明确领域的基本属性;明确属性的适用概念;明确属性值的类别或者范围。比如“效力球队”这个属性一般是定义在足球运动员这个概念上,其合理取值是一个球队。

     

    此外,领域还有大量的约束或规则,比如对于属性是否可以取得多值的约束(比如“奖项”作为属性是可以取得多值的),再比如球队的“隶属球员”属性与球员的“效力球队”是一对互逆属性。这些元数据对于消除知识库不一致、提升知识库质量具有重要意义。

     

    第二步是明确数据来源。在这一步要明确建立领域知识图谱的数据来源。可能来自互联网上的领域百科爬取,可能来自通用百科图谱的导出,可能来自内部业务数据的转换,可能来自外部业务系统的导入。应该尽量选择结构化程度相对较高、质量较好的数据源,以尽可能降低知识获取代价。

     

    第三步是词汇挖掘。人们从事某个行业的知识的学习,都是从该行业的基本词汇开始的。在传统图书情报学领域,领域知识的积累往往是从叙词表的构建开始的。叙词表里涵盖的大都是领域的主题词,及这些词汇之间的基本语义关联。在这一步我们是要识别领域的高质量词汇、同义词、缩写词,以及领域的常见情感词。比如在政治领域,我们需要知道特朗普又被称为川普,其英文简称为Trump。

     

    第四步是领域实体发现(或挖掘)。需要指出的是领域词汇只是识别出领域中的重要短语和词汇。但是这些短语未必是一个领域实体。从领域文本识别某个领域常见实体是理解领域文本和数据的关键一步。在实体识别后,还需对实体进行实体归类。能否把实体归到相应的类别(或者说将某个实体与领域类别或概念进行关联),是实体概念化的基本目标,是理解实体的关键步骤。比如将特朗普归类到政治人物、美国总统等类别,对于理解特朗普的含义具有重要意义。实体挖掘的另一个重要任务是实体链接,也就是将文本里的实体提及(Mention)链接到知识库中的相应实体。实体链接是拓展实体理解,丰富实体语义表示的关键步骤。

     

    第五步是关系发现。关系发现,或者知识库中的关系实例填充,是整个领域知识图谱构建的重要步骤。关系发现根据不同的问题模型又可以分为关系分类、关系抽取和开放关系抽取等不同变种。关系分类旨在将给定的实体对分类到某个已知关系;关系抽取旨在从文本中抽取某个实体对的具体关系;开放关系抽取(OpenIE)从文本中抽取出实体对之间的关系描述。也可以综合使用这几种模型与方法,比如根据开放关系抽取得到的关系描述将实体对分类到知识库中的已知关系。

     

    第六步是知识融合。因为知识抽取来源多样,不同的来源得到的知识不尽相同,这就对知识融合提出了需求。知识融合需要完成实体对齐、属性融合、值规范化。实体对齐是识别不同来源的同一实体。属性融合是识别同一属性的不同描述。不同来源的数据值通常有不同的格式、不同的单位或者不同的描述形式。比如日期有数十种表达方式,这些需要规范化到统一格式。

     

    最后一步是质量控制。知识图谱的质量是构建的核心问题。知识图谱的质量可能存在几个基本问题:缺漏、错误、陈旧

     

    先谈知识库的缺漏问题。某种意义上,知识完备对于知识资源建设而言似乎是个伪命题,我们总能枚举出知识库中缺漏的知识。知识缺漏对于自动化方法构建的知识库而言尤为严重。但是即便如此,构建一个尽可能全的知识库仍是任何一个知识工程的首要目标。既然自动化构建无法做到完整,补全也就成为了提升知识库质量的重要手段。补全可以是基于预定义规则(比如一个人出生地是中国,我们可以推断其国籍也可能是中国),也可以从外部互联网文本数据进行补充(比如很多百科图谱没有鲁迅身高的信息,需要从互联网文本寻找答案进行补充)。

     

    其次是纠错。自动化知识获取不可避免地会引入错误,这就需要纠错。根据规则进行纠错是基本手段,比如A的妻子是B,但B的老公是C,那么根据妻子和老公是互逆属性,我们知道这对事实可能有错。知识图谱的结构也可以提供一定的信息帮助推断错误关联。比如在由概念和实例构成的Taxonomy中,理想情况下应该是个有向无环图,如果其中存在环,那么有可能存在错误关联。

     

    最后一个质量控制的重要问题是知识更新。更新是一个具有重大研究价值,却未得到充分研究的问题。很多领域都有一定的知识积累。但问题的关键在于这些知识无法实时更新。比如电商的商品知识图谱,往往内容陈旧,无法满足用户的实时消费需求(比如“战狼同款饰品”这类与热点电影相关的消费需求很难在现有知识库中涵盖)。

     

    经历了上述步骤之后得到一个初步的知识图谱。在实际应用中会得到不少反馈,这些反馈作为输入进一步指导上述流程的完善,从而形成闭环。此外,除了上述自动化构建的闭环流程,还应充分考虑人工的干预。人工补充很多时候是行之有效的方法。比如一旦发现部分知识缺漏或陈旧,可以通过特定的知识编辑工具实现知识的添加、编辑和修改。也可以利用众包手段将很多知识获取任务分发下去。如何利用众包手段进行大规模知识获取,是个十分有意思的问题,涉及到知识贡献的激励机制,我前几年有个题为《未来人机区分》的报告,专门讨论如何利用知识问答形式的验证码来做知识获取,可以搜索此文获取更多信息。

     

    ▌3.3 知识管理

     

    知识图谱的管理主要图谱的存储、检索等问题。通常这些问题的解决需要数据库系统的支撑,因而系统的选型也是知识图谱管理的一个重要问题。这里主要讨论能用于知识图谱管理的数据库系统选型以及知识图谱查询语言。知识图谱存储是个较为专业化的问题,此处不再深入讨论。

     

    知识图谱管理系统的选型知识图谱本质上在表达关联,天然地可以用图加以建模,因而很多人想到用图数据库对领域知识图谱加以存储。图数据库的确是知识图谱存储选型的重要选择,但是不是唯一选择。传统关系数据库,近几年充分发展的其他类型的NoSQL数据库在很多场景下也是合理选择。那么数据库的选择考虑的要素是什么呢?有两类重要的选型要素:图谱的规模以及操作复杂度

     

    从图谱的规模角度来看,百万、千万的节点和关系规模(以及以下规模)的图谱对于图数据库的需求并不强烈,图数据库的必要性在中等或者小规模知识图谱上体现并不充分。但是如果图谱规模在数亿节点规模以上,图数据库就十分必要了。

     

    从操作复杂性来看,图谱上的操作越是复杂,图数据库的必要性越是明显。图谱上的全局计算(比如平均最短路径的计算),图谱上的复杂遍历,图谱上的复杂子图查询等等都涉及图上的多步遍历。图上的多步遍历操作如果是在关系数据库上实现需要多个联结(Join)操作。多个联结操作的优化一直以来是关系数据库的难题。图数据库系统实现时针对多步遍历做了大量优化,能够实现高效图遍历操作。

     

    除了上述因素之外,还应该充分考虑系统的易用性、普及性与成熟度。总体而言图数据库还是发展中的技术,对于复杂图数据管理系统的优化也是只有少部分专业人员才能从事的工作。在数据库选型时需要充分考虑这些因素。我们实验室在实现CN-DBpedia(2000万实体、2.2亿关系)在线服务系统时先后采用了RelationalDB、Graph DB、MongoDB,最后出于综合考虑选用的是MongoDB,已经稳定运行了三年,累计提供10亿多次API服务。

     

    知识图谱查询语言。通常对于表达为RDF形式的知识图谱,可以使用SPARQL查询语言。SPARQL语言针对RDF数据定义了大量的算子,对于推理操作有着很好支撑,因而能够适应领域中的复杂查询与复杂推理。从应用角度来看,也可以将知识图谱仅仅表达为无类型的三元组。对于这种轻量级的表示,关系数据库与传统NoSQL数据库也是较好选择。那么此时,SQL语句就是比较好的选择。SQL十分成熟,语法简单,用户众多且有着几十年的成功应用基础。

     

    很多领域图谱上的查询是相对简单的,以单步或者两到三步遍历居多。此时,SQL完全能够胜任。但是不排除有一些特定场景,特别是公共安全、风控管理等领域,通常需要进行复杂关联分析,需要较长路径的遍历,需要开展复杂子图挖掘,此时SQL的表达能力就显得相对较弱了。

     

    四、知识图谱的发展现状及应用

     

    ▌4.1知识图谱的应用

     

    知识图谱的应用场景非常广泛,除了通用应用外,在金融、政府、医疗等领域也有特殊的应用。

     

    640?wx_fmt=png

    图4. 知识图谱的应用

     

    通用领域的应用主要包括精准分析、智能搜索、智能问答、智能推荐等。在精准分析方面,当认识到王宝强和宝宝是指同一个人后,就可以合并“王宝强离婚”和“宝宝离婚”两个事件,得到一个统一的热点分析。

     

    在智能搜索方面,通过知识图谱建立起实体及其之间的关系,可提高搜索引擎的理解能力。例如建立代码知识图谱,自动理解代码的上下文信息,如建立起“quicksort”和“快速排序”、“QS”等的等价关系,以及“quick sort”是一种排序算法的isA关系等。这样一来,当用户搜索“排序算法”时,能把代码中包含“quick sort”、“快速排序”的内容都搜索出来。实现代码的精准、高效搜索。

     

    在智能问答方面,系统降低了人机交互的门槛,非常适合成为互联网的新入口。相较于传统的用户输入问题,搜索引擎返回网页的方式,智能问答系统可以直接通往答案。例如复旦大学知识工场实验室推出的“不倒翁问答”,是一个基于知识图谱和互联网内容作为答案来源的问答系统,能回答各类事实型问题。系统接收自然语言问句作为输入,通过深度学习的方法,从知识图谱和互联网中找到相应的答案进行解答。支持单知识问题、是否问题、比较问题、枚举问题、常识问题以及多知识问题等。

     

    在智能推荐方面,可基于知识图谱构建场景,提供基于场景的推荐。例如在电商领域,通过用户已购产品推断其购物场景,并推荐其他相关场景产品成为一个热门需求。

     

    金融领域的应用主要包括风险控制和智能投顾等。在风险控制方面,通过构建工商知识图谱,可以将人、公司的信息用可视化的方式清晰的展示出来。一来可以用于人的特征的不一致性检测;二来可以进行异常节点分析,如正常借贷人只用一个手机号在一个金融产品中进行借贷,而异常借贷人会使用多个手机号在多个不同的金融产品中进行借贷;三来很多欺诈团伙组织会通过一系列的复杂操作来持有公司,利用知识图谱的可视化可以发现其中的潜在风险。

     

    在智能投顾方面,通过对金融数据进行结构化提取和智能化分析,根据客户自身的理财需求,实现自动理财顾问。

     

    政府领域的应用主要包括数据治理、司法智能辅助审判和智能情报研判等。在数据治理方面,可将所有政务公开数据进行融合,构建政务知识图谱,为用户提供统一的政务数据访问服务。

     

    在司法智能辅助审判方面,通过建立司法知识图谱,建立了一套智能判案辅助机器人系统。为当事人提供专业的案件咨询,案件风险评估,法院服务和法律援助等。提高简单案件的审判效率,减少宝贵的司法资源的浪费。

     

    在智能情报研判方面,主要对公安情报数据进行智能整合,将真实世界的海量异构碎片化数据等价转换为一张唯一的关系大网,与真实世界的人事地物组织对象一一对应,类似于“公安大脑”。构建完成后,每个民警都可以借助这个“公安大脑”来进行情报分析,准确做出判断。

     

    医疗领域的主要应用包括智能辅助问诊和导诊和医药研发等。在智能辅助问诊和导诊方面,通过构建医疗知识图谱及相应的虚拟助手,实现对患者进行自动问诊并生成规范、详细的门诊电子病历。同时,根据患者的病历,自动对其进行导诊。

     

    在医药研发方面,传统药物研发需要经历靶点筛选、药物挖掘、临床试验、药物优化等阶段,耗时十分巨大。通过从海量医学文献、论文、专利、临床试验信息等非结构化数据中抽取出可用的信息,构建生物知识图谱,可加快医药的研发速度。

     

    五、知识图谱面临的挑战

     

    知识图谱技术的挑战主要表现在知识表示、知识获取和知识应用等三个方面。

     

    在知识表示层面,越来越多的领域应用不仅仅需要关联事实这种简单知识表示,还要表达包括逻辑规则、决策过程在内的复杂知识;需要同时表达静态知识和动态知识。单单知识图谱已经不足以解决领域的很多实际问题。如何去增强知识图谱的语义表达能力,如何综合使用多种知识表示来解决实际应用中的复杂问题是非常重要的研究课题。

     

    在知识获取方面,领域知识图谱一般样本很小,如果需要构建抽取模型,那就需要基于小样本构建有效的模型。目前基于小样本的机器学习仍然面临巨大挑战。解决这一问题的思路之一就是利用知识引导机器学习模型的学习过程。具体实现手段已经有不少团队在开展相关的探索工作,比如利用知识增强样本、利用知识构建目标函数的正则项以及利用知识构建优化目标的约束等等。总体而言,这仍然是个开放问题需要巨大的研究投入。

     

    在知识的深度应用方面。如何将领域知识图谱有效应用于各类应用场景,特别是推荐、搜索、问答之外的应用,包括解释、推理、决策等方面的应用仍然面临巨大挑战,仍然存在很多开放性问题。

     

    六、知识图谱未来的发展趋势

     

    从2012年发展至今,知识图谱技术发生了一系列的变革。从两个方面来讲,一方面是应用场景,另一个方面就是技术生态。随着应用场景和技术生态的变化,整个知识图谱面临着全新的挑战,以前的技术手段在应对现在智能化大潮给我们提出的挑战的时候,已经有些力不从心,所以我们要研发一些新技术。

     

    从应用的角度来讲,知识图谱的应用趋势越来越从通用领域走向行业领域,现在的局面是通用与行业应用百花齐放,各行各业都在讨论适合自己的知识图谱。

     

    今天展示给大家的是我们自己实验室的知识图谱,在通用领域,我们实验室有CN-DBpedia,Probaseplus。CN-DBpedia是一种通用百科知识图谱。通用知识库在通用人工智能中扮演着重要的角色,是未来竞争的战略制高点,即掌握了通用人工智能技术,可以从一个战略制高点向下俯冲,这样收获领域知识图谱的成果是相对容易的。但是如果只具备领域人工智能的能力,未必可以掌握通用人工智能能力。

     

    虽然领域/行业人工智能技术更容易落地,但是从战略层面上来讲,一定要对通用人工智能予以高度的关注。领域人工智能在很多领域已经落地开花,但领域图谱的应用也不是简单的事,还具有很多挑战性的研究问题,领域知识库构建的语料往往比较稀疏,比如在某个领域提到某个事实,某类关系的样本非常少,这个时候利用关系去构建有效的抽取模型就会变的十分困难,在样本稀疏的环境下去做领域知识图谱的自动化构建仍然是件非常困难的事情。

     

    第二个应用场景发生变化是从搜索延伸至推荐、问答等复杂任务。举个例子,用知识图谱帮助搜索代码,如果能利用知识图谱理解搜索意图,并返回准确的代码,这样效率将大有提升。用户搜索输入关键字,机器给出答案,还可以为用户做智能推荐。将来更智能的形式就是直接问答,我们实验室研发的“小Cui问答”就是这样的问答系统。整个知识图谱将来会在越来越复杂和多元的场景下发挥重要的作用。

     

    再进一步就是交互方式发生变化。以前的交互方式更多是基于关键字,现在越来越多的是自然语言的处理,对话式的处理,像GoogleNow,Apple Siri,Amazon Alexa等等,很多大公司都在研发自然语言交互的产品,这意味着自然语言交互成为未来人机交互的主流方式。对知识图谱提出的挑战就是,对自然语言的认知到了一个新的高度,需要能够利用知识图谱帮助平台和系统更好地理解问答,上下文对话等等。

     

    进而就是从用户提的问题来看,呈现出从简单的陈述类问题到解释类问题的变化趋势。以前用户喜欢问“what”、“who”、“when”、“where”这样简单陈述性问题,现在越来越多的问“why”、“how”。用户对系统智能性的期望越来越高,很多用户在Google上问why类问题,但是很遗憾,Google还不能进行回答,只能回答陈述类问题。随着“why”、“how”问题越来越多,解释就变的很重要,可解释是未来人工智能发展的核心诉求之一,是人机互信的前提。

     

    再进一步就是,以前在实体之间找到一些简单关系就行了,比如王宝强的老婆是马蓉,但现在不满足于简单关系的揭示,而是希望能够推理出一些深层关系,比如王宝强离婚案,为什么王宝强会请张起淮当律师?王宝强和冯小刚是好朋友,冯小刚有个御用演员叫徐静蕾,张起淮是徐静蕾的法律顾问,所以王宝强会请张起淮当律师,这个就是深层关系推理。隐式关系发现、深层关系推理将成为智能的主要体现之一。

     

    再从技术生态的角度来看,人工智能也发生了很大的变化。从机器学习来看,虽然深度学习发展非常迅速,并且在样本数据丰富的场景下取得了很好的效果,但是机器学习仍然存在很多问题,小样本学习、无监督学习手段有限,现有模型难以有效利用大量先验知识。再从自然语言处理角度来看,虽然自然语言处理在深度学习的推动下取得了很大的进展,但是自然语言处理离实际应用需求还很远,还只是在处理阶段,远远谈不上理解。从知识库本身来看,英文图谱积累迅速,发展得相当成熟,并且在很多应用中发挥了巨大的作用,但是其他语种的知识图谱十分缺乏。

     

    虽然现在知识图谱很多,但是大部分都侧重在简单事实,对于常识的覆盖仍然十分有限。很多知识图谱都是依赖手工构建的,如何从大规模数据里用数据挖掘的方法自动挖掘出知识图谱的手段仍然缺乏。

     

    总体而言,知识图谱技术的落地应用前景是光明的,但是也需要充分意识到知识图谱落地的巨大挑战。

     

     

    2018 AI开发者大会

     

    AI技术年度盛会即将开启!11月8-9日,来自Google、Amazon、微软、Facebook、LinkedIn、阿里巴巴、百度、腾讯、美团、京东、小米、字节跳动、滴滴、商汤、旷视、思必驰、第四范式、云知声等企业的技术大咖将带来工业界AI应用的最新思维。

     

    如果你是某个AI技术领域的专业人才,或想寻求将AI技术整合至传统企业业务当中,扫码填写大会注册信息表,我们将从中挑选出20名相关性最高的幸运读者,送出单场分论坛入场券。大会嘉宾阵容和议题,请查看文末海报。

     

    640?wx_fmt=png

     

    此外,如果你想与所有参会大牛充分交流沟通,点击阅读原文购票,使用优惠码:AI2018-DBY 购买两日通票,立减999元;此外大会还推出了1024定制票,主会+分会自由组合,精彩随心。

     

    展开全文
  • 主流云计算厂商产品服务介绍

    千次阅读 2018-06-25 17:26:28
    整体来看,云计算市场产品线大致分为:计算、网络、存储、安全、CDN、中间件、数据库、大数据、AI,再加个IoT。本文主要以产品类型为目录进行介绍,不做过多技术性解释,只做基本的产品描述以及适用场景,能对市场...

     

     

    整体来看,云计算市场产品线大致分为:计算、网络、存储、安全、CDN、中间件、数据库、大数据、AI,再加个IoT。本文主要以产品类型为目录进行介绍,不做过多技术性解释,只做基本的产品描述以及适用场景,能对市场产品有个整体的理解。

    整个云平台都是基于虚拟化技术实现,计算虚拟化、网络虚拟化、存储虚拟化等,技术细节不再赘述。

    文中涉及难免不够全面,但大致反映出目前云计算市场上的需求产品以及未来发展方向,鉴于个人水平有限,文中难免有理解偏差甚至错误的地方,如有错误还望各位指正。

    计算

    标准云主机:

           基本的主机功能,配置不算太高,很多配置在16核、64G以下,当然阿里腾讯这种大平台支持超高计算能力的。

    GPU计算主机:

           配置基本非常高,关于GPU与CPU概念区别如下:

    CPU类似以为老教授,从最基础的1+1到微积分等什么计算类型都能做,全能型;

    GPU类似一个教授带了一群小学生,教授负责分发任务,小学生只管简单的加减法。

           目前性能最强悍的应该是阿里的GN6,这个主要用在图片视频处理场景较多。

    物理服务器:

           这个没什么太多介绍的,就是物理机嘛,看各家介绍和服务了,支持的最高CPU和内存差别较大,比如阿里神龙最高可以支持96核,768G(没用过,具体可能不准确)

    分布式高性能计算:

           高性能的并行计算服务,可以理解为是一个云平台上的管理服务,能够实现任意调用各种异构实例进行计算,将多实例组合起来,类似超算中心的概念,但是比超算中心更灵活。比如微软对于此服务的描述:

    • 几分钟内创建上百个相同的虚拟机
    • 快速扩展你的大计算和大数据应用程序

    还有种批处理服务,类似这种,但是批处理一般适用于单个任务批量并行处理,适用场景还是有所区别。也就是创建一个分布式计算集群或者批处理后,不需要你手动再一个一个申请虚拟机了,平台会直接帮你把所需要的vm申请完成,你只管提交需要执行的任务,平台自动给负载到不同的vm进行计算,然后输出结果。

    应用平台:

    可以进行一键部署各语言平台的应用环境,.net,java,php,python,Node.js等,厂商直接将应用环境准备好,你开通后直接部署应用即可,省去了部署应用环境的工作。

    容器服务:

    基于Docker的容器管理服务,有专业的容器服务提供商,比如灵雀云。

    网络

    虚拟网络:

    云上的私有网络,可以将你的所有主机实例放在一个逻辑隔离的虚拟网络中,相当于在物理机房中由交换机和路由器构成的自有网络。并且能通过VPN网关与企业IDC组成混合云。

    VPN:

    提供一个VPN接入网关,传统的IDC VPN网关一般在防火墙或路由器上实现不同地域分支机构间的互联互通,常用的IPSEC协议类型, VPN网关实现本地IDC与公有云加密传输。

    负载均衡:

    支持基于 TCP/UDP 的协议的负载均衡,四层和七层负载,较常用。

    应用网关类:

    Web应用交付网关,根据HTTP请求进行负载,类似硬件F5、A10、深信服等厂商的产品,既能进行API级别的路由和负载,还能进行一些SSL的加解密工作等。目前看只有AWS和azure有这个产品,国内阿里和腾讯暂时没发现,类似的功能很多互联网公司会通过nginx实现,效率也很高,关键是硬件应用交付产品太贵了。

    存储

    对象存储:

    简言之:就是将文件保存在云上,然后可以通过http协议进行访问。AWS的S3行业内最早实现的产品,目前特别适用于大量音视频和图片的场景。

    块存储:

    就是云盘,能挂载到系统上的存储盘,主要就是卖容量,关键指标是IOPS和吞吐量,最常用的一种存储类型,云主机标配,类似于服务器直接插上一块硬盘。

    文件存储:

    采用NFS或CIFS命令集访问数据,以文件为传输协议,通过TCP/IP实现网络化存储,可扩展性好、价格便宜、用户易管理,如目前在集群计算中应用较多的NFS文件系统。相当于系统中的一个共享目录。

    上云产品:

    提供数据从本地上传到云上的解决方案,为什么会出现这种服务,一般情况下,直接将本地数据通过公网拷贝到云上即可,但在数据量大的时候,通过公网上传数据简直就是噩梦,就算500GB的数据,按出口100Mbps专线带宽来算,就得将近12个小时,这还得保证云上带宽也得是100Mbps,成本非常高,何况TCP协议的效率还无法充分利用带宽。如果是TB或PB级别的那基本不要去尝试了,时间成本都超高,所以一些云厂商提供了数据上云方案,比如Amazon的Snowball(一种硬件存储设备,相当于一个超级大容量的移动硬盘), 是一种PB 级数据传输解决方案,阿里的闪电立方服务,腾讯也有CDM。

           目前大数据上云的最终途径还是人力快递,在数据量超过一定级别后,现有的网络传输能力还无法支撑,成本随着数据量的增加就会变得越来越高,再举个例子,有很多影院在新片上映的时候,高清片源很多都是快递邮寄硬盘到全国各地,就是因为目前互联网传输能力还不能满足部分大数据传输的场景。带宽成本和时间成本都很高,还不如邮寄硬盘来的省事。

    最常用的三种存储类型:块存储、文件存储、对象存储。其他还有表存储、队列存储等,也算作存储类型的产品吧,比如redis,kafka,这一大类产品服务,消息中间件类的,后文统一归类到中间件章节介绍。

     

    安全

    WAF:

    Web放火墙,不做太多介绍,硬件能实现的,云上都能实现,但是这个并不是完全替代硬件的方案,这就好比一个国家打仗一样,战场最好是在远离都城的区域,要是敌人都打到家门口了,那显得是不是有点被动了,这就好比公网的放火墙一样,遇到攻击首先在公网上就开战了,如果实在打败了(云放火墙没抗住)或者将军叛变了(云防火墙出问题了),那敌人直接打到了城门口,这时候至少还有一道硬件放火墙替你扛着。

    所以公网上的放火墙能拒敌于千里之外,内网的放火墙能决定你生死!

    高防DDoS:

           DDoS流量清洗,防御SYN Flood、ACK Flood、ICMPFlood、UDP Flood、NTP Flood 、SSDP Flood、DNS Flood、HTTP Flood、CC攻击。这些都是很基础的服务,最开始传统的CDN厂商一直在做,加速的同时提供流量防御。

    场景也是跟WAF一样,公网和内网相结合更保险。

    其他安全产品:

           比如鉴黄服务,图片或视频鉴黄,现在网络监管严,很多互联网UGC的平台非常注重涉黄问题,前几年一些大点的互联网公司需招聘几百人每天进行人工鉴别,成本非常高。

           其他入侵检测、堡垒机、安全众测、APP加固、https加密等常见的,还有一些云厂商独有的,比如腾讯的活动防刷、游戏防作弊这些。

    CDN

    网页加速

    基于http和https的网站加速产品,关键技术就是缓存,其他能抗高并发,抵御突发流量等等一些附带的服务。这是比较专业的一块内容,这里不再多介绍,一两句话介绍不完。

    流媒体加速:

           直播或点播的加速,点播是在CDN节点上直接把视频转码成不同的格式,供用户访问

    ;直播涉及推流、转码、拉流三个过程,每个过程都可以分开作为单独的产品服务。

    整体来说,CDN这块并不是市场或技术难点,传统的CDN厂商都已经做了很多年了,现在只是在原来公有云的基础上做成一种附加的产品服务,目前市场上没有技术门槛的只有这两种类型的CDN加速,也是最来流量的,同时也是最赚钱的,当然传统的专业CDN厂商提供有很多比较深入的产品,比如底层TCP层的加速服务,大数据传输的加速等等,有些是技术门槛、有些是资源门槛导致新来的无法复制,当然这些细分的并不是最能来钱的,所以新进来的厂商都集中在最赚钱的这两类加速服务上。当然还有类似迅雷的P2P CDN这种,并不是市场主流,有很多不确定性,企业级市场首选还是追求业务稳定性,这种技术还需要企业市场进行验证。

    中间件

    消息中间件:

    消息队列(Message Queue,简称MQ)是一项高可用、高并发、高可扩展、低延时的分布式消息队列服务,解耦消息的生产与消费,多进程可以同时读写、互不干扰,为企业级架构的核心产品之一。

    各家使用的基础组件不太一样,Amazon使用Apache的ActiveMQ,阿里自己开发的RocketMQ,腾讯也是自己开发的CMQ等;还有以开源kafka为基础的消息组件,或专用于IoT的微消息队列。

    至于产品的性能以及稳定性的话,相对来说阿里和腾讯是在自身大并发平台上试验过的,相对于其他开源产品更有优势。

    微服务中间件:

    基于SpringCloud的微服务架构平台,还有阿里开源的Dubble服务,腾讯的TST服务等等。

    数据库

    数据库就比较容易理解,将传统的数据库产品做成SaaS服务的形式按需取用。

    关系型数据库:

    常见的MySQL、SQL Server、MariaDB,PostgreSQL,MongoDB。

    其他就是各家自研的分布式数据库了,比如阿里的DRDS、腾讯的TDSQL

    非关系型数据库:

    一类是基于redis、memchached开源产品,一类是自研的非关系型数据库,兼容开源协议。

    其他类型:

           Hbase分布式存储、时序数据库、数据仓库等。

    大数据

    大数据计算:

    大数据的基础基本都为Hadoop体系,都是在此基础上进行一些定制化的优化集成,让数据处理更灵活,兼容性更强,省去了不少自己开发的精力和成本。

    还有一种是大厂自用的大数据套件,现在开放出来作为一种服务,这种最开始也是基于Hadoop体系来做的,只是不断根据自身业务进行了大量的定制化工作,就成了自己的东西,比如阿里的MaxCompute,腾讯的TBDS。

           大数据计算场景大体上分为两类:1,离线计算;2,实时计算。

    离线计算:就是用于实时性不很高的场景,比如百度收录一个网站后不需要即时能在搜索引擎中被检索到,先离线处理后,过几天才能被检索到,类似这种就是离线计算,并且最初的Hadoop套件本来就是Google用来作为基础计算的,并不是为了实时计算场景而设计的。但后来又衍生出来的一些套件可以基于Hadoop进行实时计算,所以目前的所有关于大数据计算的组件统称为Hadoop体系。

    实时计算:需要实时展现处理后的数据,用于实时推荐、用户行为分析、实时营销、物联网数据分析(如常用的地图交通数据)等场景。比如一般使用spark作为实时计算模块,本来的MapReduce(简称MR,MR2版本升级后又命名为Yarn)也可以作为实时计算,但这个效率不如Spark。这个可以详细了解下MR原理就知道为什么效率不如Spark这种实时流计算模块高了,在此不再赘述。

    数据仓库:

    这个概念很好理解,可以类似理解为一个大容量的数据存储中心,各家产品架构和功能并无较大差别,都是兼容SQL语法并且能兼容BI工具,剩下的就是兼容性、稳定性、性能的差距了。

    Amazon的RedShift,百度的Palo服务,其他如阿里腾讯都有各自的服务,数据仓库在某种程度上类似大数据集群,只是场景不同,产品定位不太一样,就好比在用户行为分析场景中,本身就是一个大数据计算的平台,不仅需要实时计算,还需要离线计算,处理过的数据存储后,也可以将其他数据源比如业务数据导进来结合分析,这也是数据仓库。所以可以这样理解,大数据计算平台侧重点在于计算(实时或离线),数据仓库侧重点在于存储分析(兼容不同数据源和分析工具),他们的基础组件和架构可能都一样,只是设计的侧重点不同。实现的基础组件可以是关系型数据库,如Greenplum、Vertica、Exadata,也可以是大数据集群存储,如HDFS结合Hive分析工具等,也可以是云存储,总之底层实现架构各有各的套路,总体上实现的功能目标都是一致的。

     

    分析检索:

    这一类的服务也较常用,特别对于越来越大的数据量,检索查询性能显得格外重要,就好比百度搜索,检索一条关键字肯定都是毫秒级,海量数据检索性能直接关系产品服务的用户体验,在讲究效率的互联网时代,时间显得格外重要。

    看各家产品,Elasticsearch(简称ES)是最常用的产品,检索性能非常给力,目前最常用的海量数据检索工具。比如ELK是开源的日志分析平台,目前市场上大部分日志平台都是基于ELK进行二次开发的,ELK中就集成了Elasticsearch用于存储分析检索。这里举个例子,本公司曾经使用mysql作为数据存储,在一般场景查询性能还能满足要求,后来随着客户体量增加,数据量级越来越大,再使用mysql这种关系型数据库查询就有很大的瓶颈,查询一个较大的报表需要几十秒,这种等待是不可被客户接受的,后续更改了架构,加入了ES组件,将数据分离,基础数据存入mysql,剩下的详情数据都存入ES中,极大地提高了查询性能,查询同样一张报表缩短至2秒以内。

    BI分析:

    这个就是一套工具,各厂商基本一致,可以支持接入不同的数据源,并自定义分析展示报表,基本都是通过sql语句实现定制报表的展现,主要看产品兼容性和性能。

    AI

    在人工智能领域,首先看国内BAT,百度最早开始把重心放在AI上,完全把自身定位为人工智能公司,显然产品也是国内最领先的,阿里和腾讯进度半斤八两,并通过并购投资行业内一些垂直行业独角兽完善布局。国外的布局较早的公司主要还是集中在Amazon、Google、微软、IBM、苹果等巨头。每家擅长方向不同,根据自身业务类型在AI上的发力点也会有所不同,阿里AI较早应用在电商平台,Google将深度算法、机器学习领域运用到搜索上,IBM在机器人领域从上世纪的沃森就已经开始领先。不论国内还是海外,都是巨头通过不断并购完成自己的产业布局,目前市场估计已经快到了并购的尾期,格局正在形成。

    再从整体技术平台上来分,人工智能分为三大领域:

    1, 机器人:这个领域国外起步很早,最早是工业机器人的应用,用于生产制造,但是这些年国内很多行业巨头开始发力追赶,或者直接通过收购国外行业巨头来补充自身技术劣势,去年美的收购库卡等。其他行业,比如教育机器人、安防机器人、物流机器人、陪护机器人、医疗机器人等等,甚至还有很多研究出的高仿真xxoo机器人,很多行业都已被渗透,只是在各行业应用的成熟度不同。最大的工业机器人应用公司应该就是富士康了,没有之一。

    2, 平台系统:包括硬件操作系统等,如百度的apollo系统(自动驾驶)和DuerOS(物联网设备,包括家电、家具、车载设备、随身设备等等),Amazon的Alexa系统也已应用到echo音响上面并向市场开放(像福特和华为这样的巨头也加入了Alexa系统,还有其他很多的传统制造业,灯泡、开关等等)。占领底层的操作系统能够打造出一个完整生态,就好比上世纪的windows一样,所以这方面的竞争显得至关重要,曾经的Android就成了革命性的经典,物联网所描述的万物互联的世界正在一步一步地实现。

    3, 软件应用:目前国内独角兽企业大多都集中在应用领域,文字识别、语音技术、视频技术、计算机视觉、人脸识别等领域,国内较多AI公司重点应用也在于软件层面的应用上,IoT市场也正在成为各家巨头争夺的焦点,物联网规模过于庞大,绝对会成为各家竞争的重要战场,但具体未来能发展成什么样,现在下结论还为时尚早。应用最广泛的语音技术和视觉技术,国内出现了不少独角兽,商汤科技(SenseTime)、旷视科技、格灵深瞳、Video++、地平线。还有一块也比较重要,也是资本市场非常关注的领域:AI医疗领域,目前国内用场景主要包括医疗机器人、医疗影像、远程问诊、药物挖掘等,知名企业有华大基因、碳云智能、麻省理工学院的达芬奇外科手术系统。

    文字识别:

    OCR技术应用,这个技术并不是新技术,只是之前应用的领域较少,在当前特别用户追求体验的环境下,此类技术才得以广泛应用,各种证件照识别、车牌、表格等还可以自定义识别模板,自动识别省去了很多工作量,就像最简单的绑定个银行卡,以前手动输入卡号还容易出错,现在直接拍个照自动识别,准确率也很高。

    图像识别:

    类似文字识别,换成了识别图片上的图像,比如动植物、车型logo等 。百度搜图功能可以通过你上传的图片即时识别出为各种植物或动物等,其他应用比如在内容推荐功能,根据用户浏览图片中的物体来判断用户的喜好。

    还有一类图像审核应用,头像审核甚至鉴黄服务等属于此类应用。

    语音技术:

    这个技术也是非常早出现的了,国内的科大讯飞在这方面具有很强的技术积累,主要应用科大的翻译笔,在去年火了一把。这个技术也是目前各家能实现产品落地的非常好的入口,各种智能音响层出不穷,阿里有天猫精灵,京东有叮咚、百度有小度在家、亚马逊的echo、谷歌Home、苹果的HomePod等等,都是语音交互类应用的具体落地产品,也是物联网较容易入门并且较有市场的产品。

    视频技术:

           视频处理技术里包含文字识别、语音识别、图像识别、人脸识别,应用场景也较多,像最基础的鉴黄服务,目前的的直播平台非常注重此类服务,以前是人工鉴黄,现在用工具实现极大地降低成本;同样在智慧城市安防领域应用也最多,并且也最前卫,结合大数据平台进行一些特殊场景的应用。目前实现视频分析的技术基本都是通过将视频拍照还原成图片,然后再进行识别,所以归根结底还是图片识别技术,只是这个数据量较大,比如在视频鉴黄服务中,就很难做到实时分析,一般都是离线分析,用户先上传完视频后,平台才启动鉴黄程序进行监测,这个中间一般都会有个时间差,就是因为数据分析量过大不能完全达到实时监测,当然也能实现实时,只是成本很高,需要大量计算资源,看业务是否需要实时。

    人脸识别:

    人脸识别将是应用最广泛的技术之一,早前支付宝和微信已经集成了社保和公积金查询服务,即通过人脸识别直接确认身份信息。包括微信公众号里各种通过头像判断颜值年龄等,刷脸考勤、会员认证;应用最多是在安防监控领域,特别是公安很早就开始采用人脸识别协助搜集违法人员信息,锁定一个人脸能实现全城摄像头联动;再举个人脸识别的场景,据说某城市所有娱乐场所(特别是某些会所类)摄像头都已经接入公安平台,公安通过人脸识别统计所有出入这些场所的人员形成人脸库,然后从这些人脸库中分析出哪些人经常出入娱乐会所,还有一些抓嫖分析技术应用,分分钟定位到你在哪在干嘛,这也是在安全城市应用中的一个场景。深圳前段时间就启用人脸识别监测闯红灯,当然虽说这个技术很高级,但是只需要一个口罩就能破解,目前人脸识别还无法识别带着口罩的场景,但还有其他更高明的手段,比如监测步态,公安破案中通过走路步态就能锁定唯一犯罪嫌疑人。很多技术手段都是在政府公安领域首先应用后才普及到民用市场。

    单就说安防领域的话,像国内海康大华技术应该比较领先,早就引入此类技术应用在监控摄像头上,当然各有各的侧重优势,传统的应用厂商也跟新兴的AI公司进行技术合作,技术上都是取长补短。

    在人脸识别中,还能识别情绪,像微软的情绪识别,你识别出来你的喜怒哀乐。

    自然语言:

    自然语言,一般指计算机领域人与计算机交互的方法,俗称人机对话。也可以这样理解,就是人的语言。经过处理后怎么让机器理解,也就是自然语言理解。

    针对文本信息进行语义分析、词汇分析、句法分析、词义解析、评论观点分析、情感倾向分析、词性标注等。基于这些功能(不限于以上列出功能,目前自然语言处理还在应用发展阶段),可以适用于很多场景,如智能客服、搜素引擎(根据分词提高搜索结果)、舆情评论分析(通过分析用户评论信息智能判断出用户对于产品服务的满意度)、内容推荐等。这块应用场景一般都是结合语音文字视频图像等,也是目前比较难的一块技术,需要有很多积累和练习,才能让自身的平台更智能。

    总结一下,自然语言就是处理人机交互问题,所以涉及人机交互领域都需要进行自然语言处理。不论是软件机器人还是硬件机器人,都需要与人交互,应用最广泛的聊天机器人,苹果的Siri,微软的小娜,百度的小度等。

    VR/AR:

    目前看百度开放了AR的SDK接口,还有Amazon也有对应的SDK,其他厂商未开放对应的服务,这个也是前几年炒的厉害,具体应用并不是很实用,并且需要技术硬件设备等整个生态配合,所以市场反应并没有那么强烈。

    题外话:

    人工智能,特别是在计算机视觉领域,其实应用最成熟的行业就是安防监控,这也得利于大部分技术需要应用在公安政府等领域,方案落地也较早,并且一直处于技术发展前沿。但是有个比较尴尬的问题就是,目前的云计算处理能力还真的无法完全胜任安防监控这个领域,为啥呢?云计算不是很强大吗?你可以想象一下一个市区有多少个摄像头,并且还得把这些摄像头视频全部进行处理后再分析,里面涉及的图片视频处理是最耗计算能力和存储能力的,技术问题像人脸识别等技术在早十几年前就开始应用了,但关键是计算能力,不过这个也在慢慢改善。

    物联网

    云计算厂商能提供的产品服务从物联网架构上来分为三类,可以提供全端接入的解决方案,架构图参考如下:

    1, 感知层: 即设备采集端。

    首先就是物联网系统,比如结合人工智能的百度的DureOS、Amazon的Alexa系统以及专用于物联网设备的FreeRTOS系统等,帮助设备端实现物联网化,为什么系统比较重要,如果占领了系统层对以后的生态至关重要(硬件不是关键),就好比Android一样,百度还有直接提供集成电路板,基于ST的B-L475E-IOT01物联网开发套件,板子集成了WiFi模块、蓝牙模块、NFC模块等,能直接实现网络传输。还有一类是提供软件SDK,基于目前互联网上的平台将现有的互联网设备转换为IoT设备,针对Android或IOS设备的SDK,或C、JAVA平台的,是将传统的互联网设备变成物联网设备,因为越来越多的传统设备会采用开源系统比如Android,目前大部分家电都预装Android系统并集成WiFi模块。相对于百度的DureOS,Android只缺少了智能性,但是这些智能模块都是可以集成到Android系统中的,所以在某些场景下,特别是家电物联网,Android系统的可扩展性更强,而像一些小型设备比如音响则采用DureOS更合适。

    甚至Amazon还直接提供硬件,如AWS IoT Button就是一款类似小U盘的产品,可以自行开发进行场景定制,车钥匙、呼叫器、灯泡开关等等,相对小型设备较适用。

    2, 网络层:即网络传输。

    主要负责传输数据,传统的设备是没有网络能力的,需要集成无线通信模组和其他有线传输模块。

    无线模组类:即通过OTA传输。一种是终端设备直接具有网络能力,比如传统的家电设备、穿戴设备等,单独增加一个无线通信模组,实现成类似手机的上网功能,现在很多家电都是集成WiFi模块,连接固网实现传输。阿里也有这样的产品,比如广域网通信模组合宙(Luat),有方(Neoway),支持GSM/GPRS网络;百度提供SIM卡方式帮助终端设备实现网络传输(天工物联卡),这些硬件产品将传统的设备具备基本网络能力。另一种是终端设备没有网络能力,而是智能网关具有,所有设备数据汇聚到网关后,统一回传至数据平台。运营商有专门的物联网卡,电信NB-IoT网络是目前国内商用最早、覆盖最全的运营商网络,套餐费每年每户才20块。无线传输网络,有专用于物联网的NB-IoT网络,还有传统的通信的2G,3G,4G,5G等,详情可以自行查找资料学习。

    有线传输类:比如WiFi或有线网卡等,智能网关路由器等设备,通过以太网进行网络传输。比如最常见的温湿度探头,首先这些探头需要有线通过modbus协议直连在modbus网关(一般是将modbus协议消息转成TCP)上,然后网关统一处理后通过TCP协议回传至数据中心,当然还有另外一种模式,这些探头本身就是自带无线WiFi模块或RJ45接口,显然也比较贵,根据不同的环境进行选择,不适合布线的环境就采用无线方式。

    其他传输:蓝牙、NFC等方式。

    总结下传输方式,大部分基于无线通信模式(OTA:2G/3G/4G/NB-IoT等)或者以太网传输模式(WiFi、双绞线等),常见的物联网传输协议基于MQTT、COAP(基于UDP)、HTTP(S)、XMPP或WebSockt等。不同的协议应用的场景不同,在此不再赘述!

    3, 应用层:即数据接收处理中心

    最前端为消息服务器并集成设备管理、安全权限控制等平台,常用的物联网传输协议MQTT,是基于C/S架构,需要有MQTT服务器接入消息(当然也可以通过HTTP等协议实现),实现数据接入、解析、管理,然后再结合云平台各种产品实现大数据分析及其他应用场景;

    国内厂商中,看BAT布局,阿里和腾讯产品在感知层设备端做的比较深,而腾讯则只有几个平台的SDK,不提供硬件或网络接入能力,百度和阿里都有硬件产品,虽然是与其他厂商合作,但也可以看出这两家很关注整个物联网生态,而不是仅仅提供基于云平台的数据接入分析应用服务。

    国外厂商中,Amazon产品线覆盖较全,不仅有物联网操作系统,还有基于人工智能的Alexa系统,硬件的按钮设备等,网络层倒是没有过多关注。微软提供的主要也是应用层的服务,当然也有设备端的SDK(基于windows、Linux和实时操作系统,支持C、Python、Node.js、Java、.Net环境)。

     

    其他

    各家云平台还有一种产品服务是专门针对媒体视频类的,视频处理技术,视频防盗链加密、水印、转码、音视频提取、截图处理、画质增强、智能审核(鉴黄等)、人脸识别、语音识别、文字识别等。这些技术都是之前产品技术的集合,所以说视频多媒体服务单从技术上说是一种解决方案,并非某种技术实现。

           还有些比如管理监控类附加产品,这些可以做基本的管理监控用,特别运维监控这块也是个单独的专业细分市场。云厂商产品真的是包罗万象,还有更多传统的产品服务被云化后陆续上线中,但是云计算的最基础能力还是计算、网络、存储这三方面。其他所有产品服务都是基于这三大基础能力实现的,不论是大数据还是AI,或是IoT。

           剩下的产品服务都是各家特有的,像阿里有较多的移动端产品,钉钉这些,这并不是各家云厂商通用的主流产品,在此不再做过多介绍。

     

     

    展开全文
  • 第一部分 To B or not to B 1 B 端产品经理 如何理解B端产品? B端产品主要分为两大类: 为公司的管理服务,如:HR系统、OA系统;...两类都是为企业流程效率服务,让分散的、低效的个体,好地连接合作,...

    很幸运的是2019年3月份读完了这本B端产品经理必修课,今天也就是2019年11月25日整理书籍再次拿出来看的时候,自己已经身在小米,主要是我当时忘记这本书的作者就是现在的同事宽同学了,了解其人,更要从书中再去品味。

    产品经理的沟通技巧:沟通、说服、谈判、演讲、辩论。

    ABC理论:假设影响行为,行为最终影响结果。在沟通过程中要以结果为导向,抛弃偏见,以开放的态度与每个人沟通。

    绊倒产品经理的6个绳索:

    1. 太在意过程。要明确目标,以结果为导向。
    2. 胡言乱语。要明确沟通目的。
    3. 不推不动。积极主动是一个好习惯。
    4. 不学习。多读书、看新闻、参加沙龙,不要停止好奇与学习。
    5. 焦头烂额:要学会时间管理,分清优先级。

    产品经理:为创造价值而生。案例:《未来的传奇——波音747的故事》

     

    第一部分 To B or not to B

    1 B 端产品经理  

    如何理解B端产品?

    B端产品主要分为两大类:

    • 为公司的管理服务,如:HR系统、OA系统;
    • 为公司的运营服务,如:供应链系统、ERP系统的。

    B端产品即要符合商业组织的战略要求,能够满足商业用户需求,将已有商业运行逻辑进行系统化、信息化、高效化处理。两类都是为企业流程效率服务,让分散的、低效的个体,更好地连接合作,发挥集成化的、系统化的更大作用。

    相较于C端产品,B端产品最大的特点是:面向特定领域用户,且数量少得多,但更注重对用户专业领域操作流程的深度挖掘——也就是专业性更强,与业务的结合更紧密。

    2  B 端产品经理的职业生涯

    B端产品经理工作:

    B端产品经理技能树:

    B端产品经理职业生涯:产品专员/产品助理>产品经理>高级产品经理>产品总监

    • 1.产品专员/产品助理:关注具体执行层面的协作,对产品的需求细化,以及对原型的设计和文档的整理
    • 2.产品经理:主要关注推动产品迭代、产品的实现与效果、数据和业务、感知业务和产品的发展方向。
    • 3.高级产品经理:主要关注商业价值和模式,以及和产品的全生命周期思考问题。
    • 4.产品总监:主要关注战略规划、业务发展以及团队管理。

    在这条职业发展路径的每个阶段关注的重点不同,要掌握的技能虽多,但不是每一种都需精通,可借鉴“二八原则”:真正重要的知识,或者在实践中被反复使用的知识,只占全部知识的20%。也就是说,20%的知识是需要反复修炼形成骨架的,剩下的80%在此基础上不断更新迭代。所以产品人要一直学习在路上。

    3  以精益思想为产品方法 

    花更少的人,更少的设备,更少的时间和空间为客户提供真正想要的东西。

    • 理念一:快。快时成本与效率的解决之道。
    • 理念二:流动产生价值。长时间没开发的需求就慢慢变得不实用要定期回顾他的价值或重新设计。
    • 理念三:采用最简单的方案。面对各有优劣方案举棋不定面对复杂流程而苦恼时,选取简单的方案是最优选择,结构简单的系统往往是最可靠的。
    • 理念四:处在联系中的事物才能被简化。简化不是减少,将需要简化的部分在系统中进行了转移。
    • 理念五:不害人的需求不是完整的需求。无论多坏的改变,都会有一些人收益;无论多好的改变,都会使一些人受损。在设计规则时,要多角度的考虑获益或者受损的角色。
    • 理念六:化散乱为规律,化应急为预测。懂得预测需求,否则就会疲于奔命。
    • 理念七:只可图示,不可言传。能用图表示的会更直观,更有助于发现问题。
    • 理念八:让公路排满车,就是堵车。将工作焦点转移到重要不紧急的事情上去。
    • 理念九:聚焦目标才能带来明确的结果。做产品如果想讨好所有的用户就会分散目标,变得平庸。
    • 理念十:持续改进,不忘初心。做出的产品方案需要不断优化,同时不断回顾最初目标防止跑偏。
    • 理念十一:细节体现专业。对事物的不断细分才能体现专业性。
    • 理念十二:不要造永动机。思考产品要从整体思考,不要陷入细节。
    • 理念十三:先准确,后精确。探索需求,先力求需求准确,再在此基础上精确的探索需求。

    第二部分 单个产品管理流程

    B端产品经理的工作流程归纳为五个阶段:

    • 产品规划→产品设计→产品研发→数据监控

    1. 规划阶段:基于组织的目标和战略,获取并分析需求,规划B端产品的发展方向和路径

    我们要从规划阶段开始设计我们的B端产品,在规划阶段,我们要开展市场调研、用户调研、产品路线规划、需求分析、需求管理等活动,这些活动分布在《用户体验要素》的战略层和范围层,即主要关注目标和实现目标的边界。

    这一阶段主要是产品经理要考虑的,作为刚入门的产品小白来说,可以先从了解行业动态开始,通过“人人都是产品经理”网站、喜马拉雅“36氪”等各种途径来了解,可以在茶余饭后与同事朋友聊聊,开拓思路。

    2. 设计阶段:基于需求和规划,设计产品信息架构、原型、交互、UI方案等

    在设计阶段,我们要开展设计信息架构,设计产品原型、设计交互、设计UI等活动。这些活动分布在《用户体验要素》的结构层、框架层和表现层,即要在界定的边界内勾划出最终输出物大体轮廓和具体执行方案及最终的输出物—产品。

    这一阶段涉及到具体执行层面,也是产品专员或产品助理应该重点关注的环节。目前阶段产品经理已经通过规划和分析需求了解到用户想做什么了,这一阶段即让概念进入产品化阶段。先不要急打开axure,我们需要先梳理出业务流程图和信息架构图,在此基础上再去进行细化,为了防止我们画原型时缺页面可以先梳理出页面流程图,最后再一气呵成完成你的原型设计。

    3. 研发阶段:根据已经设计好的产品方案,设计技术实现方案及推动产品研发。

    我们完成了设计阶段的工作后,将进入到研发阶段。在研发阶段,产品经理要协助研发开展产品开发工作。这个活动分布在《用户体验要素》的表现层,即关注最终的产出物—产品。虽说产品经理不需要写代码,但要承担项目管理、协助研发理清需求、协助测试开展测试以推进产品开发。

    在这个过程中,需要随时随地解答技术人员对需求的疑问以及协助测试人员将优化和bug分类整理,并安排优先级进行分批处理。

    4. 发布阶段:制订产品发布前的部署和培训计划,推动产品上线。

    B端产品在完成研发后,将进入发布阶段。在发布阶段,产品经理要开展制定产品发布方案、发布产品的活动。这些活动分布在《用户体验要素》的框架层和表现层。即关注具体的业务流程和最终的产品。

    在这个阶段前,要确认以下信息做好充分准备:

    • 1.产品是否具备待上线条件,比如是否有测试报告,是否得到使用方的验收通过;
    • 2.产品的操作手册和培训安排是否完成;
    • 3.产品上线时间是否合适,确保不要影响其他业务的操作。其他细节这里不赘述。

    5. 监控阶段:监控产品上线后的效果,收集并分析用户反馈的信息,并形成新的需求。

    在发布B端产品之后,产品经理将进入监控阶段。在监控阶段,产品经理要开展制定关键指标、收集及分析反馈信息的活动。这些活动分布在《产品体验要素》的框架层和表现层,即主要关注具体的业务流程和最终的产品。在监控阶段,产品经理要使用数据来监控产品上线后的效果,以及收集用户的反馈意见,最终为开启新的单个产品管理流程做准备。

    上线一段时间后,需要产品经理写上线邮件,主要目的有三个:

    • 1.总结与记录:总结项目过程,未来翻查资料速度超快;
    • 2.项目推动:产品上线后才是开始,需要推动、协调各方资源;
    • 3.团队润滑剂:给参与者帮助你的人正面反馈。监控阶段手机的新需求和反馈进行整理分析,用于后期优化产品。

    总体来说,B端产品经理主要关注3个方面:表现层、领域层、数据层。

    • 表现层:即用户界面,用户直接与系统进行交互和操作;
    • 领域层:是商业和业务逻辑,是核心关注点;
    • 数据层:关注是系统之间的交互与数据存储,系统之间会以接口的形式传送数据,关注接口传输性能、传输内容等。

    4 规划阶段:产品设计的开始 

    一、产品规划:调研市场→调研用户→规划产品路线→分析需求→管理需求

    在规划行动方案之前,一定要记得先问自己:有什么事情我“今天”做了,可以让“明天”更好,或者至少让“明天”不会更糟。

    1.调研市场:找B端竞品。

    目的:分析产品可能存在的盈利点,获取行业经验和方向

    需要:产品创意、行业信息

    方法:商业模式画布、SWOT分析、竞品分析

    指标:竞品分析报告、商业需求文档

    • 明确目的。想清楚你要查询的信息,定好方向再起步。
    • 与业务同事沟通。咨询业务同学竞品名字。
    • 了解专有名词。如ERP、WMS,通过搜索专有名词找到可用资料。
    • 找到同类SaaS产品。
    • 搜索信息渠道。知乎、简书,知网、万网。

    2.调研用户:倾听用户声音。

    目的:分析和研究产品使用者

    需要:竞品分析报告、商业需求文档、产品创意

    方法:用户研究方法(问卷调研、用户访谈等)

    指标:用户调研报告

    • 用户的话不能全信。为了引起重视而故意夸大,害羞或怕说错话不去表达真实想法。
    • 能有的功能,用户都希望有。人性贪婪。
    • 明确词语含义。“我希望报表更快一点”“更快一点”就需要进一步明确。
    • 尽量不要问有固定选项的问题。列选项即使没有他也会选择。不认让用户给选项打分0-10分。
    • 重述用户所说。将用户的话用产品经理的语言再说一遍,让用户判断说的对不对。
    • 别让用户预测。不要让用户设计产品,与未来相比用户当下的行为更有准确性。

    师徒制,三段式问法:请教>刨根问底>核实

    1)发现问题:你正在做什么事情?做的过程中有什么不舒服的吗?遇到了什么问题?

    2)分析流程:你现在用什么方法来解决整个问题?

    3)探索机会:为了更好的解决整个问题,你认为有什么方法可以帮到你?或者哪些地方可以优化下?

    3.规划产品路线:缩小现在与未来的差距  

    目的:规划产品路线、节奏

    需要:竞品分析报告、商业需求文档、产品创意、用户调研报告

    方法:

    • ①列出为了缩小差距所要做的事情
    • ②目前产品的约束条件,找出其中能做到的事情
    • ③预测这些事情会使产品有怎么样的结果
    • ④给这些结果排序,给他们加上一个期望日期

    指标:产品发展路线图Roadmap(实现时间、名称、目标、功能、优先级、度量标准)

    • 时间:完成时间是什么时候
    • 名称:实现的产品名称和版本号是什么
    • 目标:要实现什么样的目标,以及想要获得的收益
    • 功能:实现的功能是什么优先级这些功能的优先级是什么指标用什么标准来衡量已经完成并实现的计划

    有产品目标后要做好目标管理,规划行动方案,实时反馈并验收成果。

    1、分析和预测需求。

    产品经理首先要明确与产品成败相关的因素。要了解用户对各因素的期望。之后用现在和未来的时间维度去分析获得信息。从现在和未来的角度发现差异,目前用户从我们产品获得什么?是否让其满意?接下来用户还希望产品有哪些功能?

    2、现状分析。

    分析目前自己的产品处于什么状态。目前该产品与行业优秀产品有什么区别?

    3、缩小差距。

    • a、用头脑风暴列出为缩小差距所要做的事情。
    • b、思考从目前的约束条件列出清单中可以做的事情。
    • c、已经选出的事情会使产品有怎样的结果,最好能够测量。
    • d、给结果排序,列出优先级及期望实现日期。

    4.分析需求:用图形代言需求   

    目的:将需求具体化

    需要:竞品分析报告、商业需求文档、产品创意、用户调研报告

    方法:筛选需求(需求蛋模型)→思考需求(D×V×F>R)→解析需求(UML统一建模语言)

    指标:需求说明文档

    需求应有的特征:

    • 痛点:好的需求犹如根治用户痛处的良药。B端产品通过调研用户基本可提炼出痛点。
    • 收益:需求应有可量化的结果导向。
    • 明确、可行、简单的第一步:挖掘需求就是降低需求中的含混性,使之明确。如果在需求落地成型阶段才发现含混性,这个时候的改正成本实在是太高了。

    需求的变革公式:不满情绪*变革愿景*初步实践>变革阻力。对现状的不满、对变革的期盼、愿意迈出明确的第一步等其中任何一个因素没做到将导致变革失败。

    • 需求的可行性=(需求的当前价值+未来价值)/(需求的实现成本+维护成本)
    • 解析需求:数据驱动,行为产生数据,数据联系行为。数据流动形成数据流,从而把业务中的人联系在一起。

    举例设计一个咖啡馆的管理系统

    • 1、画流程图先把主要流程总结出来。

    进店——点餐——下单——制作食物——送餐——就餐——结账——离店

    • 2、对主要流程进行细化。如果流程图中的活动数量超过7+-2的范围,则颗粒度太细或太粗。

    比如将点餐流程进行细化

    • 3、实体关系图(ER图)

    数据之间三种对应关系:一对一、一对多、多对多

    • 一对一:顾客就餐完成后需要支付自己的账单。顾客1——1账单
    • 一对多:服务员工作可以为多个顾客服务。服务员1——n顾客
    • 多对多:面包、咖啡等可以被不同客人点单。菜品n——n顾客

    数据对象的属性也是一类数据,用来描述数据对象,并且多个数据对象可以包含相同的属性。如何区分数据对象和属性:xx单、xx表一般都是数据对象,数据对象区别于其他实物独立存在的个体,数据对象一般能用量词“类”来形容。数据对象的属性数据可被用来增删查改,可以通过该来查漏补缺。

    • 4、数据流程图

    数据:表示数据流,连接数据流程图的各元素。

    外部实体:外部实体表示系统之外的人或事物,它可以成为整个数据流的起点或者终点。

    数据储存:存储数据的区域。在现实中,可能是单或者表格表格。

    活动操作:对数据进行操作,包括数据的流入和流出。

    • 5、用例图

    用例是对产品功能需求的描述。

    需求文档

    • 1、需求名称
    • 2、背景
    • 3、目标与收益
    • 4、功能需求。业务概念、流程展示、需求描述。
    • 5、非功能需求

    5.管理需求:打造简单可实践的需求池 

    目的:将需求具体化

    需要:产品发展路线图、需求说明文档、产品创意

    方法:需求收集(急诊模式)→需求设计(登机模式)→需求研发(看板模式)

    指标:需求池、需求排期计划

     

    需求的重要性:为了区分同一优先级的多个需求,可以用重要性来辅助优先级管理需求。

    重要性就是对需求进行打分,分数范围是1—100分(根据5个优先级可以分成5等分),每个需求的分数是唯一的。优先做分数大的需求。

    优先级和重要性一旦确定,所有的资源将向这些需求倾斜。处理跨部门的需求时,使用优先级尤为重要,但重要性的分数不能跨部门比较。

    5 设计阶段:产品从概念到解决方案

    产品设计:设计产品架构→设计产品原型→设计交互→设计 UI

    1.设计产品架构:设计让产品立得住的骨架 

    需要:产品发展路线图、需求说明文档、需求排期计划

    方法:   设计信息架构(三要素:情景、内容、用户)→输出站点地图(UML)

    指标: 站点地图

    信息架构(收纳信息)

    • 信息架构三要素:情景,内容、用户。
    • 信息架构五组件:组织系统、标签系统、导航系统、搜索系统,
    • 组织信息:根据时间字母等对信息进行组织分类。
    • 给信息加标签:用一个名称对大量的信息进行概括,就是给信息加入了标签,便于快速查询。
    • 设置找到信息的路径:导航
    • 搜索信息:搜索功能
    • 描述信息的特征:通过各种条件筛选数据。

    站点地图(原型设计起点)

    • 各页面的层级关系。b端产品的四种基本页面类型:表单页、详情页、列表页、Dashboard页
    • 表单页:用户向系统增加、删除、提交信息的操作页面。
    • 详情页:展示详细信息。
    • 列表页:向用户展示结构化的数据信息。列表页的设计大部分来自用户对实际数据的操作和展示。
    • Dashboard页:仪表盘,监控系统运营情况。

    2.设计产品原型:高效产出原型的方法

    需要:站点地图、需求说明文档

    方法:   交互设计、排版、axure 技能、

    指标: 产品原型、PRD 文档

    模式思维

    模式,指可以重复使用的方式和方法。类似于乐高积木原理。

    以厨房设计为例,厨房空间需要炉灶、水槽、食物储存区、操作台四个区域。以上四个部分距离不能太大在3m以内,操作台的范围大致在1.2-3.6m。要在一个页面上满足用户多种活动需求,比如信息查看、搜索、下载等,每种活动对应一种解决方案,这个解决方案就是模式。设计模式是由组件组成,组件是构成设计模式的基本元素。

    因此设计产品原型的流程:

    • 1、根据站点地图,找到要设计的页面类型。(列表页、表单页、详情页、Dashbard页等)
    • 2、根据页面类型对应用户操作行为,思考出各自对应的模式。
    • 3、用组件搭建成对应的模式。各种模式的布局和组合最终形成产品原型。

    总结属于自己的设计模式

    • 1、模式名称:给自己的模式起个名称,便于管理交流。比如,搜索单据。
    • 2、概念和价值:描述清楚这个模式是什么,即给模式下一个定义。写清楚给用户带来什么价值。
    • 3、使用范围:该模式相关的边界条件。比如在用户登录情况下,向用户推荐常用信息。
    • 4、模式描述:用文字图片等形式描述清楚模式由哪些组件构成及该模式是如何运行的。如:用户在输入框录入关键词时,会实时展示提示信息,便于用户选择。
    • 5、相关模式:与这个模式相关的模式还有哪些。

    三种精度的产品原型展示

    • 低精度原型:即页面流程图,展示页面中的关键组件及页面之间的跳转流程。
    • 中精度产品原型:像照片一样,展示包含所有组件的页面,主要展现页面布局。
    • 高精度产品原型:详细展示原型中各个组件在不同操作下所展示的信息。

    需求文档加上 网站地图及产品原型就为产品需求文档。

    3.设计交互:让B 端产品简单易用  

    B端产品更加偏重于工具属性,注重帮助用户完成工作效率和效果。所以,设计C端产品的交互更像是设计一本赏心悦目的小说,设计B端产品更像是一本产品说明书,需要追求使用的高效和易学性。

    4. 设计UI:如何与设计师高效沟通 

    跟设计师的合作注意以下几点:

    1. 主动学习设计知识,如:常逛逛Dribble、优设、站酷之类的设计网站,提高自己对设计的认知。同时,了解公司或团队的设计规范。
    2. 明确指出设计重点,表达顺序。明确页面中重点功能是什么,使用者在什么场景下使用,以及希望用户重点使用的界面组件和信息有哪些。
    3. 给出设计案例。可以找一些比较好的设计案例给设计师参考,指出案例中哪些元素可以参考。

    尼尔森十大可用性原则

    • 系统状态可见:用户能够随时获得产品反馈的信息,会让用户产生对产品的信任和安全感。
    • 系统与真实世界匹配:要参考真实环境使用的单据和报表,将其映射在产品中。
    • 用户掌控和自由操作:用户可以自由退防护或者结束当前任务。
    • 一致性和标准化:让界面元素和操作形成一套让用户可识别、可学习的标准,并且在产品的任何地方都可以应用。
    • 避免错误:需要检查一下界面的按钮是否可能产生误触。
    • 直接识别比记忆好:产品要减少用户的记忆负担。
    • 灵活高效地使用:要不断地提高界面使用效率
    • 美观和简约的设计:设计要简明突出。
    • 帮助用户识别、诊断和解决错误:着重关注给用户反馈的操作信息,且尽可能以友善的态度表达。
    • 帮助和文档:需要在界面上提供必要的使用帮助,并整理出专门的产品使用文档帮助用户学习。

    6 研发阶段:产品方案的实现

    产品研发:项目启动→规划→执行→监控→收尾

    1.项目启动

    说明项目目标、阶段划分、组织结构、管理流程等关键事项

    2.规划

    明确研发工作内容以及各需求点的研发、测试负责人,评估研发时间,制定排期计划表

    c74f78d09f414bb4c6fdc280e845e405-picture

    3.执行  (一个Java项目的标准开发流程

    总体设计→概要设计→详细设计→编写代码→代码审核→单元测试→集成测试→系统测试→发版上线

    4.监控

    对项目输出成果或者阶段性成果进行检查,看看是不是我们想要的或是缺少了什么

    PS:需求看板可以有效管理各需求进度,防止需求堆积拥堵导致项目不能按时交付

    deabb9c4f7e461fec6e0088f7e51a8b6-picture

    5.收尾

    试用、培训、维护、项目回顾复盘

    项目管理

    在研发阶段,产品经理需要承担起项目管理的义务,协助研发和测试同事,以推进产品开发。

    项目管理的四个维度:范围、时间、质量、成本。

    可对应的项目目标:多、快、好、省。

    1、核心问题,什么是项目?项目是为创造独特的产品、服务或者成果而进行的临时性工作。据此对项目有三个定义。

    • 项目有明确的开始和结束,也就是项目有明确的开始时间和结束时间。没有明确开始时间和结束时间的活动称之为运营。运营是一个通过连续不断的工作来交付成果。
    • 项目会产生成果。最终提供用户使用的产品功能。
    • 项目计划随着项目的开展而逐渐详细。项目会随着计划的开展展现很多之前未考虑到的细节

    2、项目目标,多、快、好、省在将要延期的情况下可以考虑砍掉部分功能而不要增加开发资源。

    3、项目计划:

    项目风险管理:

    项目风险:如果发生不确认的条件和时间,会对一个或多个项目目标造成影响。

    项目沟通:

    原则:不论采用何种手段,邮件、微信、电话、面谈,信息的发出方一定要保证接收方能够收到并且理解信息,做出反馈。

    项目推进:

    推进项目的重要基石是:标准化——标准化指完成某项工作的最佳工作方法。

    产品经理可以将项目过程遇到的问题及处理方法、人员配合方式、项目流程等经验或文档分享给其他项目成员,推而广之,达成大家的共识。

    比如:

    • 项目会议纪要模板:帮助大家高效输出内容完备的会议纪要。
    • 上线验收清单模板:让大家按照清单和步骤执行可以减少出错、提高效率。
    • 项目工作流:明确各自角色的任务及配合时间点,团队配合更紧密。

    标准化可以避免项目再次陷入相同的错误中。沿用成功的工作方法、经验,让项目不断被顺利推进。

    而在研发日常跟进中,可以采用看板模式来记录和跟进。看板管理需要注意的就是:避免某个阶段的需求出现拥堵,或者是一旦发现拥堵,要及时疏解。

     需求卡片可以包含如下信息(工具Trello、Teambition)

    • 1、需求名称
    • 2、需求的相关人:需求人、负责人、产品经理、研发工程师
    • 3、需求类型:如需求涉及哪些系统、哪些部门等
    • 4、需求完成时间
    • 5、需求描述:可以附上产品文档
    • 6、需求优先级

    7 发布阶段:产品上线的临门一脚

    上线前需确认的信息:

    1. 产品是否具备上线条件,比如:是否有测试报告,是否得到使用方的验收。
    2. 产品的操作培训是否完成,或者是否至少有使用说明文档。
    3. 产品上线时间是否合适。产品上线的时间点是否会影响其他业务操作,是否需要配合整体的运营计划。

    产品发布:

    产品推广产品,可运用营销推广模型的核心思路:描述一个重要的问题,并让大家认同,之后介绍产品给出的解决方案。

    营销推广模型分7步:

    1. 背景介绍:介绍所发布产品的背景信息,比如:时间、地点、任务、事件等信息,便于大家了解背景知识,从而减少认知负担。
    2. 描述阻碍:描述用户目前会遇到的问题,并让大家认同该问题确实会给自己带来不便。
    3. 点燃希望:向大家说明这个问题有解决方案,引起打击的期待和注意。产品经理客户可以介绍这个问题的解决方案,及概念或者同行业对这个问题的解决思路。
    4. 震撼登场:抛出问题的解决方案——即发布的产品是什么。
    5. 展现价值:描述这样的解决方案和产品会给用户带来怎样的价值和收益,可以配数字,这样会更有说服力。
    6. 精雕细琢:介绍产品重要的细节、工作原理。
    7. 给出诱惑:给大家送一些福利,让大家快来体验产品。这里可以根据实际情况来选择使用。

    发布一款产品或者介绍一个功能并不都需要发布会的形式,产品经理可以应用简单有效的演讲框架快速打动用户。

    8 监控阶段:让产品不断生长  

    8.1 制订数据指标及目标:产品演进的航标  

    • 8.1.1 数据指标的黑箱和二律背反  
    • 8.1.2 关键成功因素法:制订数据目标的方法  

    8.2 收集及分析反馈信息:整装待发  

    • 8.2.1 零基础快速入门SQL 的方法  
    • 8.2.2 与用户座谈的产品回顾会  

    数据监控:制定关键指标→收集分析反馈信息

    1.制定关键指标

    方法:关键成功因素法,输出OGSM表(如图)

    定位长期目标→制定对应的短期目标→找到实现短期目标的关键成功因素(CSFs)→确定 CSFs 实施的测量方法

    5fcd58bd96f7eb1cdf86b13847f05510-picture

    2.收集及分析反馈信息

    产品回顾会:制定会议章程(会议邀请邮件)→展现事实(影响/问题)→集思广益(问题&方案)→决定做什么(总结行动项、负责人、deadline)→总结和公告(整理会议纪要)

    产品监控数据指标:

    数据监控应该监控什么才有意义,从黑箱、仪表盘和二律背反理论中我们可以得到一些启发。

    • 黑箱:

    我们只能输入和输出,而并不知道事物真正运行的原理是什么,比如:电商网站的输入是用户进站浏览,输出是订单。那用户在浏览网页所做的行为和决策就是黑箱。 通过研究黑箱,我们可以提升用户转化率。

    • 仪表盘:

    通过汽车的仪表盘速度、耗油量等数据指标,随时反馈出汽车的状态。没有仪表盘的汽车随时都有失控的危险。对系统运行状态的监控也是,数据指标要尽可能覆盖全面,比如:出现问题的次数、加载时间、业务相关数据等。

    • 二律背反:

    二律背反指规律中的矛盾,在互相联系的两种力量的运动规律之间存在的相互排斥现象——即两种事物此消彼长、此长彼消、相背相反。

    因此,我们除了关注数据指标之间的相关性,更需要找到这些处在二律背反的指标,然后进行指标配对。通过指标配对,防止过度监控或者提升一个指标而带来副作用,用另一个指标来辅助分析和监控,从而权衡出好的办法以解决问题。

    德鲁克说:如果没办法计量就没办法管理。数据指标就是管理量化的表现。监控部分数据指标来监控系统的运行状态,如B端产品数据指标包括出现问题的次数、加载时间、以及业务相关数据指标。

    制定数据目标思路:关键成功因素法

    • 定位长期目标。产品经理找到组织或者团队的长期目标是节省成本。
    • 为了实现长期目标,需要制定对应的短期目标。如在长期目标的基础上拆解出短期要完成的目标是减少包装成本。
    • 找到实现短期目标的关键成功因素。如实现减少包装成本的短期目标可以做的工作是系统推荐使用的包装盒形状等。
    • 确定关键成功因素实施的测量方法。找到所要实现目标所要做的事情后,需要一个标准来测量是否施行到位。如,我们使用推荐准确率达到90%的指标来监测。

    数据采集:

    SQL是查数据和做报表的工具,建议产品经理都要学:

    • SQL可能是最容易入门的编程语言。因为他书写出来的代码,完全是按照英语语法,是初中语法中最简单的部分。只要学习非常少的SQL知识,或者说是几个英语单词,就可以快速在工作中使用。
    • 使用频率非常高。
    • 有助于产品经理理解数据分析的思路。

    SQL 入门手段:

    • 《SQL基础教程》,这本书内容实用且基础,适合零基础的人学习,且它描绘了很多使用场景。
    • 学习编程的网站,如http://www.w3school.cn/ ,这里的教学内容简约便捷,可以当成SQL使用的工具字典
    • 找一名程序员同事当老师,随时实践、随时请教问题。

    在监控指标时需要注意的细节:

    制定数据目标的原则:具体、可衡量、可实现、有相关性、有截止时间。

    根据关键成功因素的分析思路最终输出OGSM表。OGSM是Obiective(长期目标)、Goal(短期目标)、Strategy(策略)、Measurement(测量方法)名词的首字母。形成另一种展现形式长期目标:节省成本短期目标策略/关键成功因素测量方案行动方案减少包装成本系统推荐包装盒形状系统推荐率达到90%的指标Q1完成功能研发产品回顾会

    • 制定会议章程。会议前产品经理发送邮件包括开会目标、会议议题、时间地点、会议流程、参与人员、准备资料等。产品经理要保障会议内容简单明了,以及重要人员可以出席。会议开始后产品经理也要重申会议章程内容,让与会者明确会议议题。
    • 展现事实。阐述与产品相关的实际情况,上线后对业务运营数据的影响,或产品出现的问题和故障有哪些?记录会议内容,控制好节奏。
    • 集思广益。陈述完事实后,讨论找到解决方案。
    • 决定做什么。讨论完成后产品总结会议后的行动项,以及行动的负责人和完成时间,便于会议内容的追踪和落实。
    • 总结和公告。会议收尾时,产品经理作为主持人要总结本次会议所有参会人都同意的重要结论。散会后将结论总结为会议纪要发给相关人来备忘。

    第三部分 产品经理的自我管理

    1、帕金斯定律人在做一件事情时,耗费的时间越长就会感到越累。

    2、产出=活动*杠杆率越符合组织、团队战略或目标的活动越具有高杠杆率。

    3、提升工作速度

    • 建立收件箱:产品经理不要被当前来的事情打断,让当前来的事情进入收件箱,然后分配时间去处理。
    • 把场景相同的活动放在一起做:把类似的事情集中在一起做,减少任务切换的时间。
    • 找到关键路径:产品经理在必须做的事情中可以插入可以并行的工作。
    • 制定每天的活动计划:每天开始要预想一天的工作,哪些是重点工作,哪些是可以放到一起做的工作。但也不要把每天的工作排的非常满,导致没有时间应对紧急情况。
    • 合理拒绝别人的猴子:对于做不了或者暂时没时间做的工作坚决说不。如果在接受事情前,没有评估好是否能保质完成,那就违背产品经理的职责。
    • 学会番茄工作法:没工作一段时间就休息一会。

    不主动,工作没有重点,求大求全是产品经理的绊脚石。

    4、产品力

    产品经理的技能可以分为硬技能和软技能。

    • 硬技能包括:用户调研、产品规划、需求分析与管理、产品方案设计、数据分析等。
    • 软技能包括:项目管理能力、时间管理能力、沟通能力等。

    5. 产品力的获得途径

    作者的个人情况或习惯:

    • 喜欢看书、涉猎历史、哲学、科学、经管、互联网、技术等各个领域的书籍。
    • 把写书列为一个长期的目标,规划了5年左右的时间。
    • 因为B端产品经理的知识没有成型理论和体系,所以,作者立志填补这项空白。期望自己的总结和思考,为中国产品经理职业发展提供理论和实践的支持。
    • 为了写书,查阅大量现有的互联网、经管类书籍,还有大量的软件工程类书籍,以及学术论文。
    • 查阅资料注重追溯知识本源,了解知识的核心要义。
    • 本书展示了作者对B端产品经理的理解,介绍了B端产品经理的工作流程、工作方法、工作场景,以及作者在工作中的经验总结。
    • 喜欢跟研发同事散步聊产品和设计,在无拘无束的畅谈中总结自己对产品的看法和观点。

    以上,可以了解到作者身上几个难能可贵的品质:

    • 对世界充满好奇。在好奇心的驱动下,习得的知识非常宽广。
    • 对产品工作发自肺腑的热爱。兴趣让学习、规划和实践更加纵深。
    • 目标驱动、规划落地。目标明确,为达目标时刻准备。
    • 喜欢追根溯源。了解知识时追求本源,学习知识时抓核心要义。
    • 持续学习,知识内化,不断总结和输出。工作实践不断总结成经验和方法,形成自己的理论体系,揉碎成通俗易懂的生活例子阐释。
    • 寻求好的实践经历。在好的项目、工作环境中迸发出更多的灵感和提升。

     

    展开全文
  • 产品思维的修炼–技术的必修课

    千次阅读 2018-07-25 08:15:38
    作为写了十多年代码的技术表示:产品思维程序员们想象中重要得多!掌握了产品思维的程序员能力可以double!我把产品思维的养成要点,从我的认知上提炼了下,供大家参考。 理解产品思维前,首先需要了解产品经理是...

    作为写了十多年代码的技术表示:产品思维比程序员们想象中重要得多!掌握了产品思维的程序员能力可以double!我把产品思维的养成要点,从我的认知上提炼了下,供大家参考。

    理解产品思维前,首先需要了解产品经理是一群什么样的人;其次我们再来看产品思维的本质;再次看看程序员们的技术思维有什么特点;最后谈谈技术人员如何具备产品思维。

    1、产品经理是一群什么样的人?

    1)产品经理必须能保护技术人员!

    需求是混乱无序的,需求有来自管理层关于公司长期目标的、有来自合作伙伴的诉求、有来自销售和市场对新客户的功能代言、有来自运营对存量用户使用体验的代言、有来自品牌对活动运营的诉求,还有来自所谓“用户”由产品经理代言的需求,因为用户种类很多,且随着时间而变化,所以最后这个代言非常难。如果让这些需求直接砸到技术,那么技术是没办法设计、开发、按时交付产品的。产品经理需要把混乱的需求翻译成技术可以看得懂、可以执行的产品需求、可以迭代的版本!所以,如果一个产品经理不能够保护技术直面混乱的需求,那么这不是一个好产品经理!产品经理通常会很在意自己的“人品值”,每当他们没有保护好技术,使得技术在多个版本里返工,推倒原先的代码和功能实现,这就在消耗他们的人品。当技术对产品经理完全不信任时,这个产品也就该走人了。

    2)产品经理是解决问题、而不是提出问题的人!

    如果在产品评审会,产品经理抛出了许多没有解决方案的问题,那么他不是一个优秀的产品经理。所有人都有无数的idea,每个人都可以很挑剔,提问题的人应当是产品经理以外的所有人!产品经理的核心职责是解决问题,给出问题的解决方案(当然,产品经理可以私下与专家讨论,汇聚想法,而不是在需求评审会里提问题)!

    3)比技术更懂运营的人!

    互联网行业与传统的IT行业最大的差别在于,前者提供的是服务,是持续交付的,而后者提供的是软件,是一次性交付的!因此,互联网产品非常需要运营,它与产品是共生的!而运营需要考虑行业蓝图,谁是敌人?谁是友军?公司的资源在哪?我处在供应链的哪个环节?谁是惹不起的?BAT哪家有红利可以使用?哪里投入产出比最高?产品现在是早期、增长期还是成熟期?是应该不计成本的投入给种子用户,还是该规模化拉大众用户进场了?这些离研发似乎有些远,但确是产品经理得懂的必知必会。

    4)与逻辑较真,但也能与天马行空的设计师、不专业的用户、不关注细节的老板、目标导向侵入性强的销售、思维严谨保守的技术聊得嗨!

    产品经理非常需要严谨的逻辑,因为他需要设计流程,而流程是不能容忍“例外”的!同时,他还需要与各种角色沟通,并能够从沟通中获取到自己需要的信息,同时准确、讲究方式方法的把信息传达给目标角色。

    5)产品经理是用户代言人!

    对互联网产品来说,每个人都是用户!但用户作为群体是没办法发声的,产品经理必须为用户群体发声!当然,这需要强大的能力,包括用户调研、前端埋点、数据分析等各种招数。

    简单的聊完产品经理,我们再看看产品思维是什么。

    2、产品思维是什么?

    1)大局观:操盘思维

    首先要把自己放在产品的操盘手位置上去思考。例如下面的金牛瘦狗图,横坐标是市场占有率,市场占有率高(左边)当然最好!

    纵轴表示需求增长率,上方表示需求增长很快,这表示我们必须花更多的资源才能满足用户。所以,左上角就是明星产品,它值得花大力气去研发,而下方的金牛则是可以考虑变现,潜力不足但市场占有率很高。对于右上角市场占有率低且需求增长很快,则明显是个“鸡肋”,这种问题产品应该尽快放弃掉。

    能像以上这样思考问题,就有了行业视角、老板视角,这样的大局观是高级产品经理必须具备的。或者使用下面的SWOT态势分析法,从战略层面上定位自己的产品。

    现在我们再来看很多问题就一目了然。比如,互联网的商业模式要么是to C从用户那里收费,这要求我们的用户体验必须是第一流的,就像腾讯!

    要么是to B从服务的企业那里收费,这要求我们的技术能力必然远强于企业客户,所以我们要在技术能力上下大功夫,就像百度;

    要么是在B to C商家向用户出售产品的过程中收取服务佣金,这要求我们的运营能力必须非常强,能够整合商家到平台上,吸引用户消费,就像阿里。

    所以,你的产品的商业模式到底是什么?最大的成本花在哪里了?

    2)用户体验思维

    本质上,互联网产品需要取悦用户,由用户的微笑价值进而才能产生商业价值。

    这要求我们必须具备从用户体验出发的设计思维,就像下面这张图,从用户体验的5个层面上思考产品的设计:

    界面好看不好看,从来不是决定一个产品成功或者失败的关键因素!所以,上面这张图越是下面的层次越是重要!

    3)互联网式的产品迭代思维

    互联网行业最擅长快速迭代的交付产品,这是有原因的:

    1、快速交付产品可以减少版本风险!时间跨度越长,交付的产品与我们的预期差距越大,版本风险越大!

    2、互联网产品有许多都是从0到1的突破性产品,而不是从1到N!这样,在探索期内,降低试错成本非常重要,产品必须灵活的快速尝试简单、实现迅速的功能,由种子用户的运营中反馈到版本迭代中去,进而修正产品,这样最有效。

    而快速迭代也不能乱来,就像下图中的MVP最小化可实行产品设计。当我们想造一辆汽车,不能第1个版本先迭代造出轮子,第2个版本选出车身,第3个版本集成,这可以是快速迭代,但它不是MVP。

    以滑板车、自行车、摩托车、汽车的方式迭代,这才是MVP,才能给用户提供微笑价值!

    5)有运营视角

    产品经理需要有运营视角,因为需要从迭代中要数据,从数据中去迭代。在产品的不同发展周期,用户群体也是不同的,如下图所示。

    产品早期愿意尝鲜的用户是创新者,他们是不走寻常路的,广告投放对他们无效。而对他们则应该增加投入成本,找到可以解决用户痛点的引爆点,从而使用户增长斜率从小于1到大于1!而且这些用户就像恋爱理论里的18岁红颜(“我要我要我就要”),“懒惰而贪婪”,是产品经理(“我给我给我全给”)最理想的用户,从他们身上可以最快速的试错。而这些用户最不吝于用口碑去宣传产品,只要产品能给他们惊喜!一定要珍惜这样的用户,千万不能让他们跑了!!

    在增长期才应该在媒体上投放广告轰炸,给大众用户以“大家都在用XXX”的感觉,大众用户走的是群体思维,爱从众。

     

    下面再来看看技术思维的不同之处。

    3、技术思维有什么特点?

    1)讨厌不确定性!

    技术人最讨厌的就是不确定性。如果产品经理在跟技术阐明需求时,表达出各种不确定性。特别是,即使某个需求点可能有变化,但变化的趋势也完全不确定时,技术就要抓狂了!

    2)严谨的工程师思维!

    产品经理讲述概念、场景时最喜欢类比,因为讲故事这个能力产品经理很擅长!但是请记住,工程师不吃这套!比如产品经理为了说明需求,可以拿一个完全不同的故事来说事,因为这两件事有共同点,这样表述重点突出也更性感生动(在产品经理看来)。但工程师的思维很严谨,他的潜意识会优先判断这两件事有没有可类比性!通常,产品经理只是为了让故事服务于他的观点,而所有的“故事”都是不严谨的,所以产品经理一旦想拿“故事”与工程师沟通,首先就会遭遇“穷举法”的为难,找例外嘛,这是程序员非常擅长的事!当然,程序员的招还有很多,因为所有的设计模式准则都能套用在现实世界。所以,如果产品经理理论功底欠缺,或者拿与其他角色沟通的方式与程序员交流,就会陷入困境。

    3)重视数据与逻辑!

    技术人员非常讲究逻辑、数据、方法,包括在很感性的人际交往中。而产品经理遭遇的局面往往错综复杂,在信息不足时非常需要产品经理基于经验和方法论的主观判断能力。这时,由于产品经理拿不出论据,在与技术沟通时就会非常吃力。

    4)聚焦在实现上

    技术人员谈需求时下意识的就会讨论各种实现方案的成本与优劣!所以,技术人员很容易陷入在局部细节中,而忽视了总体目标与整体结构,缺乏计划性。

    5)完美主义

    技术人员非常在意自己的代码是否优美,可扩展性好不好,像不像一件艺术品。通常又懒于关注他人,于是特别喜欢重构新接手的他人代码,当然自己的代码也超爱重构!完美主义极易导致设计过度,忽视了项目的成本和进度。

     

    技术人员在具备了产品思维后,就可以直接对自己的产品负责,进而同时为产品设计、测试、运营赋能。而且可以从任务导向转为目标导向,大幅提升效能,优化产品的招数套路也会更多!下面我们来看看如何具备产品思维。

    4、技术人员如何具备产品思维?

    1)调整视角,目标导向

    把任务导向调整为目标导向,不再仅仅去看产品经理PRD文档上的需求,而是去看产品的生命周期与发展,关注行业、公司、部门、团队的总体目标,这样就能理解产品思维。当然,屁股决定脑袋,因为职位与职责所以不用为决策(如果有的话)的后果负责(通常,互联网公司都不会让技术对失败的产品负责),所以技术尤其不应当固执(!!!),保持头脑的极度开放,从长远目标看任务。

    2)培养用户体验导向的思维

    这是互联网服务下必修的技能,网上各种文章,不再赘述。

    3)了解点基因、神经科学、心理学

    程序员非常需要学点心理学知识并践行,比起机器来人性很复杂,无论是了解产品用户还是与同事协作,都需要食点人间烟火。而学习心理学上的很多系统性理论能够降低未知恐惧感,特别是近来非常流行的基因、神经科学与心理学的交叉理论知识。

    4)广泛了解各类互联网产品

    不能因自己的喜好就抗拒使用新类型的互联网产品,好奇心是掌握产品思维的必要条件!

     

    技术人员天天爱看的文章、视频都是关于数据库、分布式框架、消息系统、算法、神经网络、爬虫这样的纯技术知识,当然,如果你有非常紧迫的任务,可以立刻提升工作效率那另说。从长远看,沉下心学学与技术不那么相关的产品知识,其实对我们的未来发展更好!就像产品经常说的两点之间曲线最快(最速曲线,如下图),我们的职业生涯也是一样,下面这条红色的曲线和蓝色的直线,小球沿线下落时红线是最快的。

    这其实要求我们多蓄点势能再出发,到达终点的时间会更短些!

    本文其实是笔者最近看完后显慧的《产品的视角:从热门到门道》一书有感而作。笔者从资深后端架构师,跨度为创业公司的联合创始人,翻完这本薄薄的小书后,豁然发现这两年自己踩了无数的坑,于是写下本文给团队的研发小伙伴们看看,如何快速提升自己的产品思维,也希望能给广大的互联网从业者们以启发。最后附上我的读书笔记思维导图供大家快速查阅。特别欣赏这本书序言里的一句话:你所做的一切,都是为了明天的某个时刻做准备!所以,程序员们,学点与技术无关的知识吧!

    展开全文
  • DDD-领域对象与领域服务

    千次阅读 2019-02-20 21:31:05
    问题 什么是领域对象 什么是领域服务 领域对象的行为,与领域服务的行为区别 ...但是最近在推动产品进行DDD业务建模,发现这个问题非常重要,关系到代码是否清晰表达了业务,这个也是我们进行DDD的初衷。 定义 领域...
  • 为什么读大学时做学术搞项目重要

    千次阅读 热门讨论 2013-09-20 10:54:30
    众所周知,大部分国人的动手能力在读大学之前是比较欠缺的,因此很多人读大学时开始参加大量的实践项目、校园活动,这是值得赞扬的,但是如果把这些能力作为大学的主要目标...我认为,读大学时,做学术搞项目更重要
  • 计算机专业就业方向总结(选择也许更重要

    万次阅读 多人点赞 2016-09-21 15:34:41
    特别是随着消费家电的智能化,嵌入式重要。像 我们平常常见到的手机、PDA、电子字典、可视电话、 VCD/DVD/MP3 Player、数字相机( DC)、数字摄像机(DV)、U-Disk、机顶盒(Set Top Box)、高清电视(HDTV)、游戏...
  • 序论 一个企业怎样才能做到赋予员工大的权利的同时,降低成本,提高数据的质量呢?建立“员工自助系统”就是其中的一种解决方案。目前,许多知名的企业都已经建立了自己的“员工自助系统”与企业中最重要的财富 ...
  • 看了《在销售铁卷的过程中,我遇到的一些常见的问题》一文,有些话不吐不快。... 要求选择性加密某些企业在选择电子文档防泄密产品的时候,会提出这样的要求:对于同一种类型的文档,我希望能由我们来选择哪些文档是
  • 本书针对上述问题提出了新颖的观点:用户并不关心产品本身有多棒,而是关心使用产品后自己有多棒。作者利用其多年的交互设计经验,生动阐释了这一观点背后的科学。可贵的是,本书并不止步于解释“为什么”,还清晰...
  • 从事IT行业5年以来,我经常看到不少人持有这样一个观点:“技术不重要,关键是业务。”曾经有一段时间,我也是这样认为的。那么,这个观点正确吗? 1、观点的源头  那么,我们从头开始捋,看看这个观点是如何产生...
  • 产品原则和产品评审团

    万次阅读 2012-06-19 12:48:03
    Marty Cagan是享有世界声誉的产品管理专家,曾经担任网景副总裁、eBay产品管理及设计高级副总裁。本文是他回顾自己二十多年来...它体现了产品团队的目标和愿景,是产品战略的重要组成部分。从形式上看,它是一系列明
  • 运维服务外包的难点

    千次阅读 2010-02-16 13:19:00
    前段时间一位朋友说了一个观点,运维服务是自动化程度最低的一个行业,很有意思的观点,那会不会同时运维服务也是管理最薄弱的一个行业呢?我接触运维服务的时间并不长,但是我个人总觉有时候我们把运维服务搞得复杂...
  • 其实每一个产品经理的内心深处,都有着一颗文艺青年的心灵,也正是拥有了这样一颗感受丰富、体验细腻的产品之心,才使得我们能够对产品设计的细节有着更为透彻和深入的理解。
  • 软件的竞争就是服务的竞争

    千次阅读 2008-06-12 10:52:00
    阿蒙曾多次搬起石头砸自己的脚,喜欢将中国软件比作中国足球,是扶不起的阿斗,是大环境所污染的,并非换教练换领导就能解决的,中国软件就象中国足球一样在国际上毫无地位与...那我们就只有来谈谈服务了,如果服务再不
  • 麦中凡教授的精彩观点

    万次阅读 热门讨论 2007-06-30 23:37:00
    其中有一些观点,我认为很有必要让多的人知道,所以根据自己的记忆将讲座中的一些精彩观点记录下来。由于没有经过麦教授 的审订,可能有不准确的地方,待将来向麦教授请教以后再修正。 1. 谈到软件工程作为一个...
  • Android产品研发系列

    万次阅读 多人点赞 2016-06-12 19:51:13
    本个系列的文章主要是讲解android产品研发过程中一些需要注意的技术技巧与实践。其主要面对产品研发,对App稳定性,友好型,兼容性要求较高的App
  • YES!产品经理(上、下册)

    千次阅读 2011-10-14 16:19:47
    产品经理(上、下册)  汤圆 编著 ISBN978-7-121-14107-2 2011年9月出版 定价:128.00元(上、下册) 16开 904页 内 容 简 介 这是一本融合了经管、工具和职场小说特点的图书,作者是国内产品经理咨询界...
  • 观点、情感以及与之相关的许多概念,如评价、评估、态度、感情、情绪和心情,与我们主观的感觉和感受密切相关。这些是人类心理活动的核心要素,也是影响人们日常行为的关键因素。情感分析也称为观点挖掘,是一个旨在...
  • TUP:分享产品背后的技术和用户体验

    万次阅读 2010-07-21 13:59:00
      上期程序员杂志做了《互联网产品十年》的特别报道,本期又推出TUP专栏,CSDN的线下活动也已冠以TUP, TUP是技术(Technology),用户体验( User Experience),产品(Product)英文的简写,TUP宗旨是...
  • 产品读书」俞军产品方法论

    千次阅读 2017-05-31 19:36:22
    在阅读这本书之前,第一个能想到的同等的产品书籍就是网易的《幕后产品》,对于我来说,网易的产品一直是我最为钦佩和喜欢的,但是互联网界的产品名声最大的除了张小龙,我估计就是俞军了,读这本书之前我提前看了...
  • 谈谈对大数据的八个观点分析

    千次阅读 2019-05-17 20:22:09
    越来越多程序员也涌入大数据行业,但是仔细问一些从业人员什么是大数据...每个人都有自己的观点。最核心的问题还不在数量和种类,而是价值(Value)。什么是大数据的价值?如何体现它的价值?如何衡量它的价格 ?它能够变...
  • 腾讯产品宝典:产品手记全纪录

    万次阅读 2017-09-12 23:04:24
    一款产品,从脑袋里的一个想法变成真正让千万用户使用并创造价值的产品,往往要经过一个繁杂和漫长的过程,移动终端的产品遵循一个“快”字。项目周期要短一些,但只是相对时间缩短,完整的流程和环节却一个也不能少...
  • AI产品经理,如何面对数据挖掘?

    万次阅读 2019-05-25 15:03:05
    本文分别先从AI产品需求发现阶段、再从AI产品需求设计制造阶段对数据挖掘的利用,然后落地到数据挖掘具体的案例解析,最后得出AI产品大数据观点。 经过多年互联网和移动互联网的飞猛发展,科技网络产品发展到焦虑的...
  • 某工业企业公共服务平台架构设计

    千次阅读 2011-01-26 14:51:00
    这就转化成为实际的市场优势,因为它能够使产品服务比竞争对手快速地推向市场。 组织结构的改变 -  在每个  SOA  的中心都有一个卓越中心( COE )。 COE  就是一个...
  • soso的产品思考者

    千次阅读 热门讨论 2010-07-08 10:48:00
    文/腾讯soso李京 <br /> 个人简介...相信互联网创造美好生活,搜索引擎会带给人类快速、便捷、准确的信息服务。 <br />精彩观点:  搜索,是一个以技术为平台的产品。但是,搜索又是一个
  • 观点来源于:极视角科技联合创始人 罗韵 CVaaS 就是 Computer Vision as a Service, 我们把 CV 的部分标准化成为了一种服务,而每一个行业可以在这里找到自己行业需要的和图像处理、视频处理、计算机视觉相关的算法...
  • 产品经理这份工作将涉及大量选择,本质上,是需要“输入→内视→输出”的环节多,所以为了好的去进行“输出”,学习“输入”(AI基础认知、产品认知、技术通识)以及“内视”(认知框架)的重要性就不言而喻了...
  • 下面的两篇文章对所有同事都有帮助: 什么是产品运营及如何写产品运营报告,其中很多观点都适合于社交游戏。社交游戏是运营出来的!以前网络游戏出生的时候(上线)就是一个成年人了,而社交游戏出生后才是一个...
  • 观点、情感以及与之相关的许多概念,如评价、评估、态度、感情、情绪和心情,与我们主观的感觉和感受密切相关。这些是人类心理活动的核心要素,也是影响人们日常行为的关键因素。情感分析也称为观点挖掘,是一个旨在...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 71,397
精华内容 28,558
关键字:

产品比服务更重要的观点