看白癜风去哪里 https://myyk.familydoctor.com.cn/2831/newslist_8_1.html简介：在支持蚂蚁几乎所有核心业务运行和发展的过程中，我们在平台建设、业务支持、平台运营、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、有顾名思义的术语体系
产品的整体框架梳理清楚之后，还要重视“术语/概念体系”，即产品中的核心概念命名以及概念之间逻辑关系的设计。
这个之所以重要，那是因为，概念和术语体系是每一个领域知识沉淀的结果，也是人们学习新事物、进行沟通交流的介质。
概念复杂，产品必然复杂；概念简单，产品才能简单。
比如，同样是人机交互的指令和方式，
