平台建设的7大问题蚂蚁AI平台实践深度总

简介:在支持蚂蚁几乎所有核心业务运行和发展的过程中,我们在平台建设、业务支持、平台运营、AI创新以及AI整体运营等各个方面做了很多尝试,有了不少的收获和感悟,在此分享给大家。

过去几年,我和团队一直在负责蚂蚁集团内部相关平台产品的设计和运营工作。

这些平台产品包括人工智能部的A/B测试平台、机器学习平台、金融知识图谱平台、NLP平台、智能文案平台、金融视觉(CV)平台、搜索平台、机器人平台、标注平台等,以及风控团队的相关平台产品。这些平台产品,在背后支持了蚂蚁几乎所有核心业务的运行和发展。

整个过程当中,我们在平台建设、业务支持、平台运营、AI创新以及AI整体运营等各个方面做了很多尝试,有了不少的收获和感悟。

最近,我花了一些时间,将其初步梳理出来,写成了这篇文章。

文章的内容涵盖了“需求管理、平台设计、产品验证、平台协同、人性对抗、跨界思维、挑战/成长”等7个方面,既有一些抽象的、方法层面的总结,也有很多真实的、有体感的案例。

篇幅比较长,约1.5万字。感兴趣的话,可以收藏下后面慢慢看。

希望本文对你有所启发,更期待能抛砖引玉,跟大家做深入的探讨和交流。

一、需求管理:“角色错位”与“无我境界”

1、挖掘需求,警惕“角色错位”,杜绝“闭门造车”。

做好产品的第一步,就是把握好需求,必须搞清楚每一个产品和功能的真正用户是谁。

对于C端产品,这个问题比较好解决,因为设计者和使用者往往是重合的。但对于技术平台类产品、B端产品,这两者经常是错位的,即设计者可能并不是真正的用户。

举个例子,支付宝的产品经理在日常生活当中天天用支付宝付款、理财,他就是个典型的支付宝用户,所以设计者与使用者就是同一个人。而在技术平台、B端产品当中,产品的设计者可以用自己的产品,但基本上仅限于做测试、做验证,真正的用户却是其他的人。

因此,设计者对于产品需求的一些推理判断,可能会与真实情况有差别,即使他用了,那个以测试为目的的使用和真实的使用,还是有区别的。

由此可见,正是由于技术平台类产品中这种角色的错位,就容易导致需求把控出问题。

下面,先从我们标注平台的一个小故事开始讲起。

去年12月的一天,我们标注平台的相关同学开会,进行产品设计评审。

其间,针对一个标注页面的产品设计细节问题,在坐的产品经理、UED、前端、后端各个岗位的同学各抒己见、争论得不可开交。

突然间,我意识到一个严重的问题——那就是会议室的所有同学,并不是这个feature的用户。

因为具体的标注工作,都是外包公司的数百个标注人员做的,他们才是标注页面的真正用户。

不是真正的用户、没有处在那个场景,就很难了解真实的情况。于是,大家就只能根据自己的经验和专业能力,进行判断和推演。

做产品不能闭门造车。于是,我们就随即安排相关同学去了标注外包公司做现场调研。

一开始,我们与几个标注团队的小组长进行小范围的初步沟通。当时,随口问了下产品使用情况,他们一致反馈“没什么问题,挺好用的”。

这样的回答很正常,毕竟这么简单、直接的问法,是很难获取到有价值的信息、了解到用户的需求。

在产品经理的行业,我们经常说的一句话是,在汽车被发明之前,如果你直接问用户要什么,他只能说“我要一匹更快的马”。钉钉原负责人无招同学来蚂蚁做“钉钉创业之路”的分享时,也谈到这个问题。他的观点是,见到用户不能只是“就事论事”,只问产品使用相关的浅层次的问题。(即使问这样的问题,也不能问“你有什么需求”之类很难获得真实需求的直白的问题)。正确的方式是,先把具体的产品抛下,多了解客户的背景、业务、状态等整体的、背景的、来龙去脉的信息,要表现出对客户“感兴趣”,要想成为客户的朋友。只有这样,客户才愿意跟你多聊、深聊,只有这样,你才能捕获到有价值的信息。再加上,观察客户的具体行为和操作,就能捕捉到真实的需求,才能做到有所洞察。

于是,结束会议后,我们要求上楼到标注员工的办公区,具体看看情况。

当我们站在标注人员身后,仔细观察他们的操作、与他们深入交谈后,就有了新的发现。

很多原来没有想象到的使用方法和场景、产品设计的细节问题,在标注人员的不断操作中,就显现出来了。之前产品评审会上大家争论的问题,自然就有了答案。

半天下来,我们总共记录下数十个有价值的反馈和发现,并在后续工作中,一一做了处理和跟进。

可见,如果你不是真正的用户,你没有亲眼观察真正用户的操作,很多问题你是无法预料到的。

大家IQ都不差,遇到问题,我们往往习惯于谈方法、讲逻辑,经常在会议室里面唇枪舌战甚至拍桌子瞪眼睛,最后谁也说服不了谁,得不到有效的结论。

在这时,不妨先问下自己“真正的用户是谁?”,再试试“笨办法”,走出办公室,走到客户那里,去问问他们、跟他们聊聊天,看看他们怎么用我们的产品。

那时候,很多问题便豁然开朗了。

2、满足需求,不断“由浅入深”,修炼“无我境界”。

接着,让我们的思考再深入一些。

现在,假设你已经明确了用户是谁、摸到了需求的大概脉络,那也要考量“对需求理解是否深入”的问题,即浅层需求和深层需求的问题。

换句话,也是手段和目的的问题——“浅层需求”往往只是手段,而“深层需求”才是目的。

举个例子,对于我们负责的金融视觉平台,有用户反馈“我需要模型报告”,即模型训练出来后,将一些“准确率、召回率、AUC之类”的指标,用图表的方式展示出来。

如果你只是将这个需求做了,那是不够的。

为什么呢?因为用户要的模型报告,只是“浅层需求”——他的确需要看各种指标,但他最想要的是,在新模型训练出来后,他要对不同版本的模型效果进行对比——不仅要知道指标是多少,更想知道指标的具体变化,哪些升了、哪些降了以及具体数值是多少。

只有这样,才算是满足了深层需求。

道理是相通的,类似问题在C端产品中也会碰到。

如果你留意的话,你会发现很多电商网站、汽车导购产品的产品经理已经摸到了深层需求。

比如,汽车网站里面基本都有一个“车型对比”功能:不仅能将不同车型的各项配置、参数,用表格逐项列出来,而且还提供了“高亮不同配置、隐藏相同配置”等贴心功能。这就是深层次地满足了用户的需求。

因此,对于一个需求,多问几个为什么,多问自己“这是用户的真实目的吗?他用这个功能到底想干什么”等。只有这样,才有可能触及到用户深层次的需求,才有可能做出让用户感到很贴心的功能。

对于深入满足用户需求,除了做浅层、深层的分析之外,还可以采用“分而治之”的思路,将产品从模块和功能上分层,即分出“N级火箭”,每一级“火箭”用来满足不同类型的用户需求,或者同一用户在不同阶段的需求。

举个例子,尽管我们的图谱、NLP、CV、搜索、机器人、标注等几个平台产品的功能各不相同,但我们还是找到了共性,即抽象出了需求分级和业务赋能的“五级火箭”,包括“功能嵌入、API调用、数据训练、模型定制、算法开发”等五级。业务方可以根据具体情况,来选择不同的接入方式。

第一级,功能嵌入:通过iframe等实现成本最低的手段,将平台的某个功能模块嵌入到自己的系统当中。第二级,API调用:直接调用平台提供的成熟API,比如调用身份证、驾驶证之类的OCR识别的API。第三级,数据训练:平台的模型符合需求,但需要提供自己的训练数据或者字典数据等,来解决具体场景需求。第四级,模型定制:平台的现场模型不太符合要求,所以要对算法参数进行配置,然后训练出符合自己需求的新模型。第五级,算法开发:最高级的情况,就是业务方懂算法、要开发新算法。平台则提供“算法开发、数据管理、模型训练、模型测试和发布”等一系列深层次的能力,来提升算法研发的效率。上述“五级火箭”,由浅入深地满足了不同类型用户,以及同一个用户不同阶段的需求。

记得多年前,我参加了一个管理方面的高级培训班。培训有好几天,内容很多,不过几乎所有的培训内容我都忘记了——除了一位老师无意中介绍的一个“万能四步法”。所谓四步法,就是“分类-排序-找规律-应用”这四个步骤。无论在学习新的领域知识、接手新的工作,还是来到新的环境时,都可以尝试这个万能四步法,相信再复杂的问题都能迎刃而解。用户分层、五级火箭,就是“分类-排序”的一个应用。

谈完“需求/用户分层、五级火箭”了,那是否就是对用户需求度、无死角地满足了呢?

答案是否定的,因为我们还没有做到“无我境界”。

所谓“无我”的境界,就是满足用户需求的时候,不能只考虑“我是谁、我有什么”,而要忘掉自己,去看用户需要什么,什么东西对用户最有用。

比如,虽然你是做AI技术平台产品经理,但你眼里不能只有AI、算法、模型——要做到“无我”,就是要做到:如果有一种非算法、非AI的产品策略,若能切实帮到业务,那也应该去做。

在业务同学的眼里,有没有算法没关系,是不是高科技不重要——而有没有业务效果才关键。正所谓,不管白猫黑猫,抓到老鼠才是好猫。

比如,我们的智能文案平台,能够智能生成千人千面的营销文案。过去,一直在迭代产品、提升算法能力,力图生成更加智能、精准和个性化的文案。

然而,大家知道,算法的提升不可能一蹴而就,算法效果都是慢慢地打磨和优化的。

在这个过程中,产品经理同学不能干等。

于是,我们就在思考,不管多么高深的算法、多么智能的平台,我们生产的仍然是文案。而文案这个岗位,随着广告行业的发展已经存在了数百年,那么,一定有成熟的方法论和模式。

作为互联网从业者,我们崇尚创新和颠覆,但我们还必须对行业保留敬畏之心。

于是,我们的产品经理同学就去把一些市场营销、广告文案经典书籍研读了一番,总结出了所谓“18种优质文案句式/模板”,这里面既有文案从业者的经验总结,也有广告学、心理学等领域的科学原理。

将这些“优质句式”、“文案法则”产品化之后,配合算法和技术,就能给业务输出更有效果的文案。

我们相信,机器不能完全代替人,机器智能和行业知识、专家经验等人类智慧,一定会相得益彰、交相辉映。

二、平台设计:平台产品,也必须“秒懂”

讲完需求,再来说说设计。

在互联网行业,面向C端用户的产品不仅供给充裕、极大丰富,而且普遍都免费,获取成本基本为0。

没有付出,就不会“珍惜”。

所以,对用户来说,产品必须容易上手,即必须“秒懂”。如果用户几分钟甚至几十秒看不懂、不会用,那他基本就放弃了,产品就没有机会了。

对于中台、平台产品来说,其实也是这样的,只不过用户遇到不爽的体验只能忍忍,因为使用你的产品来解决他的业务需求,这是他的本质工作。

但是,这并不意味着产品随便搞搞就行,因为他还可以有别的选择。你要知道,公司内部往往也有类似的产品,更不用谈外部的、免费开源或者收费的解决方案了。

所以,你在平台设计上,也要下功夫,必须能快速抓住用户,让用户迅速上手、接入、上线,帮助业务拿到业务结果。

如何才能做到“秒懂”呢?可以从“产品框架、术语体系、帮助指引、产品demo、统一交互”等几个方面来考虑。

1、有清晰明了的产品框架

用户一打开平台的页面,就应该清晰地感知到平台能做什么,产品框架是什么样的,包含什么功能模块,模块之间的关系(包含、先后等),第一步做什么、第二步做什么,等等。

这一点看起来没什么深奥的,但常见的问题是,产品经理在产品设计前期,对框架的思考不够充分。经常是到了PRD、视觉评审阶段,才发现模块设计不合理、流程不清晰等等。这时,再返工、改动,成本就大了。

更为糟糕的是,频繁的返工和变更,会让产品经理个人的专业性和权威性丧失殆尽。以后,还怎么向技术提需求、磨资源?

为了避免这样悲惨的事情发生,产品经理要在台下多下功夫。

一个好的习惯,是先在脑中重建,再动笔绘制。很多产品经理习惯一上来就画demo,这是不对的——大脑的认知和计算资源是有限的,顾“此”就会失“彼”,当你陷入种种细节后,就不可能从根本上、框架上思考问题了。

那怎么办呢?可以用充分使用脑图这种工具。具体来说,你先不要考虑任何demo图,而是先把整个平台产品层级结构全部理出来,包括各级导航和模块、每个模块包含的页面及核心功能板块。画好脑图之后,站在用户的角度,反复梳理和模拟,直到横向、纵向的逻辑和流程都没有问题了,再动手做具体的demo、PRD。

2、有顾名思义的术语体系

产品的整体框架梳理清楚之后,还要重视“术语/概念体系”,即产品中的核心概念命名以及概念之间逻辑关系的设计。

这个之所以重要,那是因为,概念和术语体系是每一个领域知识沉淀的结果,也是人们学习新事物、进行沟通交流的介质。

概念复杂,产品必然复杂;概念简单,产品才能简单。

比如,同样是人机交互的指令和方式,


转载请注明:http://www.aierlanlan.com/rzdk/2356.html