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

开发 开发工具
整个过程当中,我们在平台建设、业务支持、平台运营、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。
  • 第三级,数据训练:平台的模型符合需求,但需要提供自己的训练数据或者字典数据等,来解决具体场景需求。
  • 第四级,模型定制:平台的现场模型不太符合要求,所以要对算法参数进行配置,然后训练出符合自己需求的新模型。
  • 第五级,算法开发:最高级的情况,就是业务方懂算法、要开发新算法。平台则提供“算法开发、数据管理、模型训练、模型测试和发布”等一系列深层次的能力,来提升算法研发的效率。

上述“五级火箭”,由浅入深地满足了不同类型用户,以及同一个用户不同阶段的需求。

记得多年前,我参加了一个管理方面的高级培训班。培训有好几天,内容很多,不过几乎所有的培训内容我都忘记了——除了一位老师无意中介绍的一个“万能四步法”。

所谓四步法,就是“分类-排序-找规律-应用”这四个步骤。无论在学习新的领域知识、接手新的工作,还是来到新的环境时,都可以尝试这个万能四步法,相信再复杂的问题都能迎刃而解。

用户分层、五级火箭,就是“分类-排序”的一个应用。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 有清晰明了的产品框架

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

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

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

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

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

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

2 有顾名思义的术语体系

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

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

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

比如,同样是人机交互的指令和方式,微信的“摇一摇”就能让用户“顾名思义”,并立马有体感地照做,而我们支付宝的“咻一咻”,就比较难理解和付诸行动了。

又如,当年乔布斯发布iPod的时候,并没有直接抽象地说“存储空间高达4.8G”,而是说“把1000首歌装进口袋”。

可见,产品中的新概念命名不合理,或者将晦涩难懂的底层术语直接暴露出来,都会对用户造成很大的困扰。

再比如,在A/B实验平台中,最初的概念体系自顶而下分别是“业务域-业务线-产品-实验”。

我们发现,用户很难分清“业务域”与“业务线”的区别,里面的“产品”也不是大家所理解的“支付、借呗、花呗、余额宝”这样的产品,所以存在很多困扰。

后来,我们借助大家熟知的“物理实验室、化学实验室”这些事物,将概念体系改造成这样:达尔文是一个“实验平台”,里面可以创建“xxxx实验室”“yyyy实验室”,在每一个实验室当中,可以做各种各样的“实验”。这样,就好理解多了。

除此之外,我们还对实验室中的角色命名进行了修改。

之前实验权限管理里面,有“管理员”、“成员”这两种常见的角色设置,我们同样参照现实生活中实验室工作人员的岗位名称,将其改成了“实验室主任”和“研究员”。

有趣的是,“研究员”在阿里体系有“高P/组织部”的层级含义,这样小小的一个文案的修改,也包含着平台设计者的“人文关怀”——对那些用A/B实验来践行数据驱动创新的、追求科学严谨做事方式的同学们,给予一点点温情和荣耀。

而且,日后的运营活动也好做了,比如可以评比“十大研究员、十佳实验室”等等。

总之,在设计产品的术语体系,首先是“如无必要,勿增实体”,其次,要尽量借助大家脑海中已有的概念,而不是直接照搬技术实现,或者生造新的概念。

3 有恰到好处的帮助指引

即使你在概念设计上下了功夫,也不能保证用户不会产生任何疑问。

因此,就需要设计“帮助体系”,做进一步的解释和阐述。

这里,并不是说让你写一份冗长的产品文档。文档应该写,但它不是重点,因为大部分人并不会仔细把产品文档读完才动手操作——他只有遇到问题,才有可能去查查手册。

这里说的“帮助体系”,指的是产品化的帮助体系,即 “文档产品化”。具体来说,就是把帮助文档中的要点尽量嵌入到产品页面当中,让产品实现“自解释”,而不是放到产品体外、仅仅存到帮助文档中。

“文档产品化”,具体的措施包括如下几个方面:

页面上有辅助说明

常见的情况,是我们的页面太干净、太空了,舍不得放一句解释的话,当用户遇到问题,就不知所措了。所以,可以在标题下面做小字解释、在概念上面出tip气泡提示。对于复杂的情况,在帮助文字后面还可以加上“了解更多”链接——直接跳转到帮助文档的相应地方,而不是要用户从头查找。

新功能上线,有提示和告知

平台不断做迭代改进,但经常发现用户并不知道上了新功能。所以,可以对此做适度的提示和告知:大迭代可以蒙层弹窗、小的改动可以出小红点,等等。

4 有简单直观的全流程demo

只看教学视频学不会游泳,光学“科目一”是学不会开车的。

天花乱坠说半天,不如动手玩一遍。

现状是,很多技术平台完全没有demo和体验能力。那么,用户就很难上手。

因此,平台一定要搭建一套“全流程、有体感、简便易行”的demo,让用户亲手体验一下。

全流程,指的是你的demo要涵盖平台的全部环节和步骤。有体感,指的是要有直观的结果(而不是只显示抽象的数值、json代码输出之类)。简便易行,指的是要足够简单、几分钟就能完成(因此你需要内置几组demo的语料、图谱、数据集等等)。

举个例子,在NLP平台和金融视觉平台当中,用户可以很便捷地在线体验金融NER/文本分类、身份证/银行卡OCR的效果。

也可以全流程地完成“项目创建、数据上传、数据打标、模型训练、模型测试”等环节。

值得指出的是,对于平台的demo,一定要越简单越好,千万不要高估了人的耐心。

记得在金融视觉平台第一版全流程demo上线后,当项目组成员在具体体验时,才发现还是很繁琐,甚至要放弃。

要完成demo,你仍然需要写一堆表单,比如项目名称/简介、模型名称/简介、数据集名称/简介,而且,还要自己准备训练数据,不得不去网上搜索、下载几十/上百张图片……

后来,我们就对此做了大幅度的简化,能点鼠标的就不要让用户输字,比如自动填充各种名称和简介。此外,平台还内置一些测试数据集供用户使用等等。

经过一番简化之后,用户才能在几分钟之内,完成全流程、非常有体感的demo了。

5 有标准/统一的交互体验

在做好每一个平台的设计之外,还需要考虑不同平台的体验一致性,即平台的统一。

做好这件事情,既能让用户降低学习成本、在不同平台之间平滑切换,也能减少UED、产品经理、技术同学们的重复劳动。

首先,可以将平台通用的框架和模块,抽象出来、统一起来,包括Portal页、项目管理、权限管理、数据管理、任务管理、发布管理等等。

其次,将细节的体验也统一一下,具体到组件的设计、命名、颜色、位置等等。

当我们沉淀出一套经典的产品框架和交互标准,那产品迭代速度和用户体验,都会大幅提升。

三 产品验证:用不“深”,就做不好

1 要深度验证,而不是蜻蜓点水

产品经理要真正做好一个产品,必须要自己多用。

这个道理很简单,但这里要谈的是使用的“深度”——随便点点、看看,跟深度使用的差别是很大的。

举个例子,如果让你设计导航产品中的路口转弯提示语,你可能觉得设计成类似“前方500米路口右转”这样就没问题了。

你看,既包含距离,又说清了方向,感觉已经很完美了吧。然而,当你深入使用产品时、当你自己驾车的时候,才会发现情况并非如此——你很难精确地把握是否到了500米处,很可能在300米处的一个路口就错误地提前右转了。

所以,现在的导航提示不仅会说“前方500米第N个路口右转”,并且会在不该右转的路口提示“正在经过第N-1个路口”,只有做到这样精细,才能保证用户不会走错路。

对于我们的标注平台来说,深度使用体现在做数据标注的次数——标注几次与几十、几百次,你的感知是完全不同的。

标注页面中的一些设计的细节问题,在你做一两次标注的时候感觉不明显,当你做上几十次、上百次之后,再小的问题也都会暴露出来、被放大了。

比如,有一种图像分类任务,你只需要标注“对”还是“错”。

之前的设计,是每页展示一张大图,答完题后就切换到下一页。当我们自己亲自标注了几十张之后,就感觉这样的效率很低。

于是,我们就改成了一页展示一二十张图片,标注人员只需要扫一眼,把其中“对”或者“错”的勾选出来,然后整体提交就好了(同时也减少了每一页刷新页面、加载图片的等待时间)。这样简单的一个改动,其实并没有什么技术难度,但标注效率直接提升了好多倍。

2 自己“做业务”,结果大不同

真正要把一个平台做好,不仅要像上面说的,自己多当“标注员”,更应该做做 “业务方”。支持业务、赋能业务,跟自己做业务,还是有很大差别的。

下面,用我们做的垃圾智能分类的项目“分类宝”这个案例来说明下。

在2019年7月份,全国很多城市开始推行垃圾分类。

我们的同学基于沉淀的图像、NLP和图谱等AI技术能力,迅速开发出了智能垃圾分类的技术和产品,项目命名为“分类宝”。用户可以通过“拍照片、语音搜索”等便捷的交互方式,在支付宝小程序以及智能垃圾回收箱IoT设备上,来体验AI垃圾分类了。

这个项目,并不是各个业务BU给我们提需求而开始做的。这一次,我们有了双重身份,我们自己既是平台方,也第一次做了“业务方”。

做起业务方之后,我们才发现,垃圾分类这个事情看似简单,实际上却包含很多复杂的环节,从“训练数据的获取、物品类目的整理、垃圾分类标准的维护、线上回流数据的订正”,到“物品类目权重和优先级的调整、标注结果的确认”,再到与内部各个部门的协同、与外包ISV的对接、节假日与特殊物品的应对,等等。

经过一番手忙脚乱的折腾,总算是把项目磕磕绊绊地做了起来。

在这个过程中,我们遇到了很多之前不知道的问题,其中既有平台设计不合理的产品问题,也有训练时间过长之类的技术问题。

更重要的是,让我们看到了不同流程、不同系统以及不同团队之间衔接的“真空地带”——这正是大公司由于分工、边界带来的,常说的“三不管、踢皮球”的问题。而这些衔接上的问题,正是隐蔽的、极大影响效率的问题,需要被发现,通过产品和流程等机制进行解决。

“自己做业务”的这一次实践,让我们平台同学换了一个视角,深刻体会到了业务同学的不易,也直接推动了平台的迭代改进,以及团队配合、流程设置的完善。

四 平台协同:连接,产生价值

前面讲了很多,但大部分还是聚焦在某一个平台的个体上。

孤立存在的平台,就可能会降级成一个工具,其价值和能量就变得非常有限。

因此,要做好、做大平台,需要跳出平台本身,以连接、全局、生态的思维来看。

如果让不同平台产生协同和连接,会产生“1+1>2”的效果。如果把封闭在平台内的“控制流、数据流”延伸出去,变成闭环,就会迸发出很多创新。

下面,介绍几个方法和案例。

交叉链接,带曝光带流量

这是最简单的一种平台协同的方法。每一个平台不仅要完成自己的使命,还应该考虑为兄弟平台做点什么,比如带带曝光、带带流量什么的。所以,我们在每个平台产品的导航栏都增加一个“AI产品矩阵”的菜单,把七八个产品的logo、名称、链接都列了上去。数据表明,这个小小的菜单,每天都能为其他平台带来可观的曝光和转化,做这个菜单的ROI非常高。

平台能力复用,杜绝浪费

平台在不断迭代升级的过程中,对于一个新需求,不要一上来就自己做,而要先看看其他平台有没有可以复用的现成的能力,哪怕是“曲线救国”或者“权宜之计”。

比如,知识图谱平台的知识更新和智能文案平台的文案发布,都需要走打标和确认流程,我们发现标注平台的标注能力就够用了。所以,我们就没有重新开发,而是在平台之间打通连接,快速解决了这个问题。

反哺和闭环,实现共同发展

如果一个平台只是单向的输出能力,而没有从下游获得反哺,没有形成闭环,那也不是个完善的系统和平台。

举个例子,我们的标注平台已经累计对上亿条数据进行了打标,这些标注数据使得各类模型的训练变成了可能。正所谓,没有人工,就没有智能。

在这个过程中,标注平台只是输出价值、为智能化助力,自己并没有从智能化中获益。

后来,我们就考虑把这个链条形成闭环,即让打标数据训练出的模型反哺回标注平台,从而实现“智能辅助标注”。

这样,将整个平台从“纯人工标注”,转变为了“智能辅助标注”,大大提升了标注效率、降低了标注成本。

沉淀数据资产,创造更大的价值

如果一个平台有数据的沉淀,那么这些数据就需要深度挖掘,从而产生更多、更大的价值。

比如,每个业务最开始接入知识图谱平台,为了解决自己的业务问题,就得从头建Schema、导数据。但随着平台的发展,沉淀的知识越来越丰富。那么,后续的平台就能直接受益于之前沉淀的知识,而不一定要自己重新建设了。这就是,平台数据沉淀出的价值。

再比如,标注平台里的标注数据,在完成模型训练之后,生命周期就终结了,躺在那里没有人管了,这是很可惜的。

现在我们计划将这些数据沉淀下来、开放出去,让数据产生更大的价值。

首先,标注数据对内开放。在业务刚接入AI平台,存在一个冷启动的阶段,最缺的是打标的数据。所以,可以将标注平台中海量标注数据梳理和开放出来,让业务可以先到平台里面搜索下,看看有没有已有的数据,有的话,就可以复用。如果没有,再考虑重新建数据。

其次,标注数据对外开放。我们可以把一些不涉及隐私、不牵扯我们核心技术能力的部分数据开放出去,为社会创造更大的价值。

比如,在智能垃圾分类“分类宝”项目中,沉淀了数十万打标的垃圾图像数据。在我们开放了相关模型API之外,再把其中一部分数据开放出去,就会对整个社会的垃圾智能化处理,贡献蚂蚁的一份力量。

接入开放平台,实现强强联合

这里,再说说开放的具体做法。如果自己直接对外开放,做起来就比较麻烦,有很多对接和维护的事情。应该考虑将自己的能力接入到现成的、大的平台,比如支付宝小程序平台/开放平台、阿里云平台等等。借助这些大的平台,很多获客、对接、运维的事情,就有兜底了。

这里,再分享一个考虑平台协同创新的思路,那就是“图解法和穷举法”。

一开始,平台协同创新都是散点发生的,想到一个就做一个,很不系统和体系化。后来,为了把所有“连接”和“协同”的可能性都穷尽,我们就画了一张系统协同大图和矩阵图,把所有的平台都放进去,全方位地思考平台之间有什么没有打通的,有什么协同创新的可能性。

 

这个方法,大家在做其他工作时也可以参考。

五 平台中的人性对抗

大家常说,有人的地方就有江湖。一个平台,也是一个江湖。

不同角色、诉求的人参与其中,人性就展示出来了。

因此,就需要思考人的事情,就需要对平台进行运营和治理。

1 平台的误用

首先,要纠正平台上出现的不正确的用法。

为什么会存在这种情况呢?

原因在于,尽管产品经理在产品设计的时候,本身就会尽力杜绝大部分错误的发生,在平台的玩法中也有相应的规则告知到用户,但大家并不会像你想象的那样“守规矩”,他们会有意无意地“妙用”、“错用”甚至“滥用”。

比如,在我去年负责A/B实验平台的时候,我们曾经对平台中所有实验进行深入分析,结果就发现了很多惊人的现象。

  • 数百个实验只有一个版本:正常来说,需要两个或者更多的版本来进行对照实验,但很多实验竟然只有一个版本,其中一个很大的“妙用”或者“误用”,是用户仅仅把平台当作灰度平台来使用了。
  • 数百个实验内流量为0:有的用户并没有使用平台的分流能力,而是自己做分流,这也是我们没有料想到的。
  • 数百个实验运行时间小于3天或者大于30天:正常来讲,实验需要运行一周左右。但很多同学将实验运行一两天,一看到数据有变化就把实验推全或者下线了,这其实是不科学的。有的实验运行了好几十天,原因竟然是有人忘记处理了,可能实验场景都不存在了。
  • ……

可见,大家对A/B实验的了解还是很不够的,导致在平台上出现了各种“奇特”的用法。那么,需要在平台培训和产品设计等方面,做更多的工作。

除了A/B实验这样的平台,在我们的金融知识图谱等平台上,也发现很多问题。

我们知道,在知识图谱的Schema规范当中,同样一种实体只能有一种类型。

比如,对于“公司”这个金融领域最常见的实体类型来说,全局定义一个名为“Company”之类的类型就可以了。不同的业务域,可以有不同的业务场景,但类型应该共享一个。

然而,现实情况是,业务同学为了简单、好把控,往往都想自己创建一个类型。于是,在平台上就出现了类似Company1、Company2这样重复的类型。

在图谱平台上,除了Schema重复,数据也存在重复、不一致的情况,这些都需要一个一个进行治理。

然而,平台治理这件事,既是科学也是艺术——既不能放任自由,也不能卡的太严。尤其是在平台建设的初期,如果限制得太死,业务方是很难理解和配合的,甚至会丢掉客户。

所以,要把握好力度。

2 “滥用”与“违规”

上面提到的这些平台治理的问题,其实还不算太糟糕。

接下来,给大家介绍一些需要高度重视和严肃处理的“滥用、违规”的行为。

分别是标注平台中的两个真实案例:“任务释放”和“串通磨洋工”。

先说第一个,“任务释放”功能的滥用。

考虑到外包标注人员变更比较多,所以产品经理在标注页面上设计了一个“任务释放”的按钮,用于防止任务卡在一个人手中。

然而,后来标注小组长们反馈“希望取消这个按钮”,说这个按钮被不少标注人员用来“挑活”:当遇到难度较大的标注题目,他们就点击“任务释放”给跳过了。

于是,我们就把这个功能从一线的标注人员那里收回,只给小组长开放了(这个问题也是去外包公司实地调研时发现的,之前团队同学们都没有料想到)。

第二个是违规行为,说的是人员串通起来“磨洋工”。

有一段时间,算法同学反馈标注速度下降了。我们分析了下报表,发现个别小组的多个标注人员的标注速度都降低了,包括之前做的比较快的人员。

经过调查发现,原来是有个别害群之马不光自己偷懒,还教唆、串通其他人,一起降低标注速度,来集体“磨洋工”。

当然,“串通磨洋工”这个问题最根本的原因,在这些标注人员的绩效管理方案上——之前采用的是月薪制而非计件制,有绩效奖金但微乎其微。

最近,我们在专项建立任务难度分级标准,并在完善外包人员的整体管理方案。

3 “太智能”了,也不行

最后,再说一个非常有趣的事情。

我们知道,如果一个产品不够贴心,不够聪明和智能,那用户肯定不喜欢,但反过来,如果“太智能”了,那有时候也不行。

人是不安的、焦虑的,如果让他感到“太过于神奇、不知道里面发生了很么”,他就不敢用。

举个例子,在模型服务平台的产品当中,有同学设计了“模型一键部署”功能,即把离线模型部署到在线过程中的复杂、繁琐的特征处理等工作自动化了。

然而,当大家花几个月开发出来后,却发现根本找不到一个业务方,因为大家都说不敢用。最后,这个“智能”的一键部署功能只能无奈地下线了。

(要说明的是,并不是说“简化模型部署”这个产品方向有问题,而是上述“黑盒的、让用户心里没有底”的方案,需要多斟酌,要多站在用户的角度来思考)

六 跨界、跨界、跨界

所谓跨界,就是突破原有行业惯例和常规,通过嫁接其他行业的理念和技术,从而实现创新和突破的行为。

世界著名投资家、沃伦·巴菲特的黄金搭档查理芒格,是一个极具智慧的人,他非常推崇跨界的思考方式,他指出:

  • 你必须以跨学科的方式思考。
  • 你必须经常使用所有可以从各个学科的大一课程中学到的概念。
  • 如果能够熟练地掌握这些基本概念,你解决问题的方法将不会受到限制。

要做好技术平台的设计、运营和推广工作,你也需要跨界的思维和打法——比如,你可以把营销思维与产品、技术跨界地结合起来。

所谓营销思维,简单来说,包含“认知规律、品牌体系、素材载体、传播路径”等几个关键点:首先,要服从人们对新事物的认识规律(简单、直观),搭建起一套品牌识别和记忆的体系(logo、命名),不断策划出有创意的活动和素材,并在合适的地方进行曝光和传播。

那么,对于技术平台的运营和推广,也可以跨界地使用上述营销领域的理论和方法。

具体来说,可以从以下几个方面着手:

平台产品需要品牌

我们对所有的平台的品牌识别体系进行了梳理,参照“阿里动物园”的惯例,分别命名为知蛛金融知识图谱平台、鲸语NLP平台、图鹰金融视觉平台、千鲟搜索平台、灵犀机器人平台,每种动物的选择都尽量体现了该平台产品的特点(毕加索智能文案平台、AlphaQ智能标注平台的名称已经有一定认知度,就未做修改)。

除了名称之外,我们给力的UED同学们还设计出了非常有区隔度、记忆度,异常精美的logo。有了名称和logo,交流、传播和推广的时候,就好办多了。

产品体系需要品牌

不光要给予每一个平台以记忆度和识别度,还要考虑多个平台作为一个整体,如何记忆和传播。同样是考虑到阿里的武侠文化,我们就包装出了“AI中台天龙八部”的整体品牌概念,来传播八大AI技术平台产品。后来发现,这个“天龙八部”的在内部的影响力很高,很多人都用“天龙八部”来整体指代AI技术平台家族。

运营活动需要品牌

做运营、做推广,也需要有一个品牌的体系。所以,我们构造出了一个“AI特派员”的形象。对于我们对内发布的所有文章、视频和海报,都纳入到这个体系当中。比如,所有的内网文章标题、文章的首尾都统一格式,加入“AI特派员”的名称和形象,这样既方便形成统一认知,也方便大家日后检索信息。

此外,在运营活动和物料的设计中,也有品牌营销思维,技术和平台再高深,传播的时候也必须考虑互动、创意和趣味。

为此,我们定制了印有平台名称和slogan的有趣的可乐瓶,为标注产品体验的同学颁发“聘书”等等。

由此可见,将营销与技术、产品跨界融合,站在用户角度进行产品品牌体系和运营活动、素材的设计,就会收到较好的效果。

七 平台产品经理的挑战和成长

读到这里,你可能觉得做平台挺有趣、挺容易。

其实不然,大家都难。

对于技术平台的产品经理来说,会面临“心、脑、体”全方位的挑战。

在专业技能方面,除了要有产品经理岗位必须的“需求管理、产品设计、项目推动”等能力之外,还需要“懂技术”。要懂研发流程,要懂各种算法、模型的术语和原理,因为你不仅要与平台的开发团队对话,你还要跟平台的用户进行对话——这些用户大部分也是技术同学。

这并不是要求你比技术同学更懂技术、代替技术同学去做技术的事情,而是要求你要理解技术点的本质,要知道这个技术能做什么、不能做什么,这项技术与其他技术的区别是什么,这个技术大的发展脉络是什么。

当你下功夫搞清楚了这些问题之后,才不至于处于太过被动的局面。

但是,“缺乏主动权、成就感不强”,还是困扰着技术平台的产品经理同学。

要解决这个问题,可以从如下几个方面来考虑。

深入了解业务需求,提升业务sense

平台最终是为业务服务的,平台再牛逼,对业务没有帮助,也是不能立足的。因此,当你对业务需求有十足的把握,就能有理有据地规划平台建设的方向,就有成就感。

考虑自己能为团队带来什么独特价值

一个项目的成功、一个平台的成功,除了专业能力之外,还需要有足够沟通、协调、推动、BD、销售的能力。毫不夸张地说,要做好产品,产品经理不只是产品经理,更要有产品的“小CEO”的角色。当你通过自己的多方努力,把一件事情做成,自己就会很开心,也会赢得团队的认可。

任何一件事情,都有创新和提升的空间

对于标注平台,你可以沿着“人工标注”的老路子去做,也可以朝着“智能辅助标注”的方向去创新。对于智能文案平台,你可以只依赖算法提升的路径,也可以主动创新,把领域知识和行业经验产品化,来实现产品经理驱动。对于用户反馈的获取和产品的迭代进化,你可以使用“当面交谈、问卷调查”的传统方式,也可以尝试“分析用户日志,使用大数据+AI”的新手段。要相信,只要以终为始,从业务出发,从用户出发,就能找到产品创新的机会。

时刻敬畏产品、敬畏用户,认真做每一件事

我们曾经用这样一句话,来鼓励自己团队的同学:我们要用做几亿DAU产品的心态,来打磨几百、几千DAU的技术平台。认真的人不会吃亏,你今天的每一个付出,都会产生价值,都会提高自己。人生没有白走的路,每一个“需求”都算数。

八 结语

总算到结尾了,在这里,再对文章的内容做一个小结:

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

越基本、越简单的问题,却越难回答,也越容易被有意、无意地忽略。做产品第一步,就是要回答这些基本问题:搞清用户是谁,搞清楚用户的真实需求是什么。要深度满足用户需求,要多问为什么,了解用户真实的目的。还要忘掉自己,多从用户角度去思考。

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

如果一个产品一眼看过去,都乱七八糟的,搞不清楚怎么回事,那基本上就很失败了。因此,要从“产品框架、概念体系、帮助体系、demo体验、交互统一”等多个方面着手,来实现“秒懂”。

产品验证:用不“深”,就做不好

想做好产品,就要做好产品验证,产品经理要想方设法去高频、深度地使用自己的产品。有机会的话,还要自己“做点小业务”,你才会惊叹“啊,原来还有这么多问题”。在这个过程中,你自己还会有很多意想不到的收获。

平台协同:连接,产生价值

单个平台的价值和能量是有限的,当你突破平台的界限,创造更多的连接和闭环,你就会打造出一个欣欣向荣的系统和生态。

平台中的人性对抗

有人的地方,就有人性。对于多种角色参与的平台来说,要做运营、引导和治理,这样才能让整个平台平稳、健康发展。

跨界、跨界、跨界

面对复杂多变的环境,需要多元化的人才、互补的技能,需要不同行业和领域进行跨界融合。跨界会产生化学反应,跨界会产生创新。

平台产品经理的挑战和成长

成年人的字典里,没有容易二字。有问题有困难,平台、团队和个体才能提升和发展。产品经理岗位是个复合体,不是单个技能就能立足,产品经理同学需要不断迎接挑战,不断修炼自己。 相信平台的力量,相信产品的力量。

我们刚刚起步,我们继续前行。

 

责任编辑:武晓燕 来源: 51CTO专栏
相关推荐

2012-04-23 21:51:14

Android

2019-08-16 11:48:53

容器云平台软件

2017-12-10 20:53:56

Docker持续交付容器

2023-02-28 07:01:11

分布式缓存平台

2022-12-29 09:13:02

实时计算平台

2021-01-08 13:42:28

爱奇艺机器学习深度学习

2024-03-12 17:13:51

2023-06-05 07:36:30

数据湖大数据架构

2023-01-27 19:33:10

消息中心管理平台

2012-02-08 11:15:43

云计算微软

2013-01-14 10:02:10

云安全云计算

2009-02-27 09:43:50

软件开发平台化配置化

2016-09-12 17:17:06

OpenStack云计算私有云

2009-12-08 14:42:30

Windows 7操作

2010-04-13 11:36:01

2024-07-05 09:24:11

2020-12-10 15:28:29

知乎CTO平台

2023-03-30 07:40:03

FeatHub 项目特征工程开发

2017-10-13 13:13:14

人工智能深度学习微博

2022-05-25 12:07:09

开发单元测试软件
点赞
收藏

51CTO技术栈公众号