讨论完这个“马后炮”的场景分析，再来说一个“构想中产品”的场景分析思路。

先简单交代下背景：前一段时间有个欧洲团队想回国内做算法落地的项目，有工作机会，所以就对接了。核心算法就一个：微表情识别，准备落地的场景是：公检法、教育、风控等方向的情绪识别，产品没看到，只看到Demo，基本和我们做目标检测的Demo差不多的效果。由于在国内的合伙人有一些公检法的资源，所以准备先在这个行业找场景落地。怎么落地，情绪识别之前玩过看了看效果，也没有做深入研究，假设我去规划这个产品落地的事情，我会怎么做？

情绪识别也就是微表情识别，开源数据集也有不少，少则5种多则7种分类，通过微表情判断情绪。通过情绪判断是否说谎，这个事情在理论上有争议，但认为可行的更多，欧盟(希腊、匈牙利、拉脱维亚)在边检试点基于情绪识别的“虚拟警察”。所以，这个需求可以认为是“刚需”，落地也有案例与场景，可以初步认定产品可以立项。
表情（情绪）+ 是否说谎 + 公检法，这几个关键词组合在一起，很自然可以想到“审讯”过程的“测谎”场景。传统的基于ECG、EEG的测谎仪由于是“接触式”相对并不“友好”，如果可以通过摄像头来解决同样的问题，那么在录制审讯视频的同时让嫌疑人“无感”的完成了“测谎”，这样的产品还是有生命力和竞争力的。所以，落地场景可以先确定在“审讯”环节的“测谎”。
如果将产品定义为“辅助测谎工具”，这个应用场景怎么分析呢？我是良民一枚，没去喝过茶也没给审讯过，我也没有机会去做调研，但是做为一个“自我感觉良好”的“优秀全干型工程师”，做这种小产品的设计，不需要调研，闭门造车就行了，毕竟，谁还没看过电影、电视剧啊，这种场景肯定看到过么。

一般情况，都是一人问，一人记录，同时全程录像
按照Demo的效果，可以拿实时视频流做推理，然后分析情绪，给出置信度

最简单的方案（这也大概就是欧洲团队目前准备卖出去的方案）：增加一个摄像头近距离对着嫌疑人的脸拍摄，审讯人员桌前放一个电脑屏幕，实时推理后，做个展示界面，把分析的的情绪展示出来。这样做和“行人闯红灯抓拍”有什么差异？做出来的东西是没有生命力和竞争力的，纯属闹着玩、做玩具。
我准备这样规划这个产品：

既然要全程录像、归档，那么就有备查和检索的需求，而且如果增加表情识别的摄像机，这一路视频理论上也需要录像、归档。
同步记录一方面需要对方签字确认，做为案件卷宗形成证据，另一方面就是备查，那么这个文本和视频应该需要有一定的关联性；
为了视频存储后方便查看与检索，这个视频是需要“结构化”的，否则要检索视频只能“快进”太没有科技含量，且浪费时间；
在案情分析的时候，可能会对嫌疑人的某几个问题的回答存疑，需要集体分析，找卷宗询问记录比较快，但是文字是冰冷的，只有配合情绪、表情与肢体动作后，语言才会鲜活起来，经验丰富的专家才会更好的作出判断。所以，能够方便的检索视频，应该是一个系统使用过程中的“次生”需求，那么这个检索方式就应该是“视频结构化”的时候需要考虑到的；
可以考虑，语音转文字，配合视频时间戳，就可以实现通过文字检索到对应视频位置；
通过情绪识别，现场可以看到在回答问题过程中的情绪波动，同样可以把“情绪”做为视频结构化的一个维度，通过时间戳与视频关联；
稍微有点常识并对这个领域做点研究，就会发现其实，视线(Gaze Tracking)、肢体语言(Pose Estimation)及语音情绪识别(Speech Emotion Recognition)与面部表情进行联合判定，似乎更有说服力，所以，系统应该预留此类推理功能，及多个视频结构化的维度；
考虑到存储越来越便宜，摄像头也不贵，可以在工程方案中设定3或者5路摄像机，分别从不同角度拍摄并录像；
审问现场的监控屏幕显示正对脸的近景和全景画面，并给出情绪波动提示；
在算力闲时，进行整体结构化、语音转文字分析和打标签；

这样做下来，整合了视频存储、结构化检索、情绪分析、测谎以及语音转文字，是不是像个有竞争力，且具备完整功能的产品了？

特别提示：上述产品设计已申请专利，如有厂商准备采用此方案做产品，请与本人联系！！！

通过两个场景分析的例子，是不是对于理解场景有点感觉了？DL的产品难就难在：任何产品化的尝试，都是创造一个全新的应用方向，用户很难给出明确的需求，要求我们的DL产品经理依据对用户场景的理解，用最合理的方式将DL嵌入用户业务，同时还要考虑清楚推理错误之后的代价。

对于有一定行业经验或者工程经验的产品经理，理解用户场景这项工作并不是非常困难，但是在增加了DL模型推理后，使场景理解这件事变得困难了。在行业内做传统的业务系统的产品经理，大多缺乏深度学习的技术背景，具有深度学习背景的产品经理，大多都是近几年才有的，也鲜有行业背景与经验，甚至对于 to B/G 领域的软件产品设计都没有相关经验。

机器学习这样一个边缘、前沿的技术领域为to B/G 产品经理带来的场景理解的难度，估计在很长一段时间都会存在的。解决方案只能是用群体智慧解决单体知识的欠缺，让“懂机器学习”和“懂行业”的两组产品经理协同工作、知识互补。这一点，对于AI领域创业公司的HR部门来说，在招聘过程的简历筛选过程中一定要意识到：虽软传统软件行业的产品经理、咨询顾问、项目经理可能不是985/211，也没有“大厂”背景，甚至年龄也过35，但是这批人具有的能力、知识点和技能，恰好是可以和DLer互补的。

挑战三：需求判断

需求判断实际上与场景理解、业务抽象属于孪生任务：要更好的理解需求以及需求会引发的潜在、次生需求，就应该先理解需求发生的业务场景；要更好的分析场景，进一步去抽象业务，那么最好先厘清在这个业务场景中有哪些具体需求，通过需求抽象业务。

嗯，绕来绕去，看起来变成鸡和蛋的“死循环”问题了，不要觉得这是“故弄玄虚”，对于理解“场景分析”的重要性，来解释下。实际上，在准备做个产品或者项目的时候，对于这个“工作场景”，一般的输入有两种可能：

Case1: 准备针对某个场景做一个落地产品

在启动阶段，产品经理得到的输入是：场景。基于这个场景去做产品落地，那么在产品启动初期，产品经理需要在充分理解场景的基础下，在场景中“挖掘”需求。

这种产品开发的场景，产品经理的第一步就是先做业务场景认知。

Case2: 拿到一组需求准备做一个落地产品

在启动阶段，产品经理得到的输入是：一个或一组需求。基于这组需求去做产品落地，产品经理就需要结合用户行业，去梳理这些需求在什么业务场景发生的，基于需求去找到“场景”。这种情况大多都是项目开发的居多，产品经理/项目经理的第一步工作就是去做找到需求的业务场景。

脱离场景谈需求，那是耍流氓。

明白了吧，因为产品立项的出发点不同，所以产品经理的需求梳理工作还是有所差异的。我们戏虐AI创业公司的行业落地是“拿着锤子找钉子，看什么都是钉子”，为什么会这样呢？依据“炼丹师”做出来的算法能解决的问题，似乎是能解决一部分“需求”的，但是这个“需求”没有“落入具体场景”，就只能把算法当锤子，看着差不多像“需求”的钉子，都去敲一下，运气好落地一个项目。但是大多数时候都是不理解行业，又要行业落地，只能是“创新业务VP”去找“钉子”。

如何去理解需求

估计看此文章的，做过B/G产品需求的产品经理比例不会太高，做过“后台”的产品经理估计会稍微多一点，但也不会太多。对于B/G领域的产品，尤其是和用户业务相关的产品都是比较复杂的，要理解业务需求、流程、权限、SSO，做的深入要和原有系统做集成的，还要在需求中明确兼容性要求（没错，尤其是To G 的产品，外网运行的还好点，尤其是涉及到内网运行的产品，在需求阶段就要明确兼容性需求，否则等到现场交付的时候就傻眼了，Win8不让用，Win10政府版还未普及，Win7是主流，XP很常见，没有到SP3的XP也不是稀罕事，所以老老实实向下兼容到IE8，告诉前端小伙伴，jQuery大法好，潮技术都用不上。）

对于产品经理来说，一方面年纪都不大，部分刚走入社会1、2年，对于B/G的基本业务流程、组织机构以及一些“通识”的概念没有认识，另一方面对于具体的行业知识、业务知识基本一片空白，这种情况下怎么去做“业务场景认知”。

一般对于To B/G 的产品，谈到使用场景的时候，不能忽略一件事：一切业务、流程，都是和管理相关的，而管理都是有“目的”的。

往下看之前，建议细细品味以下这句话，这句话并非笔者创造的，是我入行的时候我的师傅说的，他让我仔细琢磨这句话，能想明白了，就能“开窍”了。这一章到这里估计要有九千字了，估计都看累了，休息下，带大家回顾一个老段子，来品味下上面这句话的味道。

深圳有家奇葩的网络公司，下午五点半下班，六点半有班车，八点有东来顺的工作餐，十点以后打车报销。

还记得鹅厂的这个段子么？这种安排，真的是为了实现“管理的目的”。大多数互联网公司都是免打卡的弹性工作制度，那么下班就安排班车，意味着会有部分人实际工时不足的，那么延后一小时会解决很大的工时不足问题；如何能在“不官宣、不强制”的情况下让码农们多干几个小时呢？那就8点给管饭吧，反正光棍回去也没地方吃饭；如何让不要吃饱了就跑，再多干点活呢？那就10点报销打车吧。看见没，“巧妙的制度安排”是能悄悄从员工手里“偷出来4个多小时的”。除去吃饭、休息、聊天时间，就算加了2个小时班，也不计较加班2倍工资的事情了，各位鹅厂码农，请心理默默算一下你的日薪的1/4是多少，这就是“管理的艺术”。管理的“目的”显然是降成本，提高人均产值，要实现这个目的，最简单直接的办法就是招技术好的，然后加加班，这样人效比最高。如何才能避免加班导致的员工不满情绪呢？提供看起来诱人的福利（这种套路，我在管理的时候也用……Emmm我也是坏人）再打打鸡血、聊聊福报，这个福利成本对比应支付工资，那是太划算了。

提鹅厂的段子，仅仅是为了用身边的小故事来说明白复杂一点的东西而已，望鹅厂海涵，不要人肉我啊。

现在是不是对当年我师傅教给我的“哲理”有点理解了。所以，我们理解需求的时候，一定要在场景中去理解；我们去理解场景的时候，一定要去研究场景中的业务流程、业务需求对应的管理目标是什么，这个管理的真实目的是什么。当年我师傅手里同时有3个人，我只是其中之一，别人怎么理解这话的我不知道，但是以我的自身认识来看，通过不断的自我训练，当能做到：快速熟悉一个行业，看到需求就去琢磨需求的业务场景，琢磨需求的管理意义，琢磨需求的管理目的的时候，基本上是可以“本能”的去判断需求的实际意义、价值和背后隐藏的真实需求。死不要脸的吹个牛：不止一个人（包括曾经的一位“打工皇帝”）问过我基本类似的问题：你怎么什么都知道，你都没做过的事情，上手干不犯错，结果不比有经验的人做的差，你是怎么做到的？

分享一些我过去使用的、也教过不少入门产品经理使用的方法。

保持好奇心。只要没事干，就看点东西，看什么无所谓，不求甚解，看懂多少无所谓，能多留点印象就好；
养成“类比”的习惯。新知识、新东西可能学习理解比较吃力，但是能在过去的知识中找到“类比”可能理解起来就快很多（我是用了PID控制中的“反馈控制理论”（还好自动化专业没全忘了）去类比了“反向传播”，才算把BP想明白了。），而且这个习惯会帮助你用对方听得懂的“简单”语言，把复杂的事说明白（这个能力对咨询顾问非常重要）；
善用工具，勤于知识体系整理。Google的技巧，合理的目录组织，各种离线阅读工具，笔记工具等，能在日常去做一些系统的整理、收集工作，哪怕稍后阅读变成“再也不读”也没关系，在整理过程中，至少意识到了“资料的重要性”才会去收集（这也是收获），真有用到的哪一天，对这个知识点多少有印象，再去检索也目标清晰；
日常的点点滴滴的收获，在进入新行业的时候，也许就是“快速学习新行业知识”的N把入门钥匙；
B/G领域只要涉及到流程与管理，那么如“作业指导书”、“岗位说明”、“国标/行标/企业标准”这些类似的文档肯定是有的，对于门外汉来说，看起来很枯燥还很多看不懂，但是一定要“津津有味”的去读，因为所有的流程、场景、管理要求都在里面，所有的需求都是这些“规则”的执行需要而已；而且，做工业企业的项目（比如瑕疵检测、巡检机器人）如果精力允许对于生产流程、工艺流程这些东西，能了解多少也去了解多少，因为这些都是“管理的目的”。我做电力项目的时候，学了整个发电工艺流程，看了锅炉、汽机、电气、热控、化学水、燃料各专业的东西，就为了和人家做流程的需求调研的时候明白人家在说什么；做石化项目，愣是抱着人家的几大本立项说明书看完了炼化厂的工艺流程；做烟草项目，看完作业指导书，让人带着我从烟叶拆包到最后装箱，车间里面跑一圈都看看……自动化专业的优势在这里很明显，理解这些真的快。
有机会去做用户现场需求调研的时候，一个需求涉及多个岗位之间的流程的，一定要每个岗位都问到，而且最好再去这帮人的领导那里去调研下，不一定要详细调研流程，但是要问清楚管理目标和意义（不要问为什么，照着做就是了，屁股决定脑袋，这里面的血泪教训能随便写几千字。），这叫：交叉验证；
需求调研的时候，不要胆子太小，多看多问，看看人家桌子上要处理的工作是什么，条件允许，对于需求涉及到的场景去实地看看，对于需求涉及到的工作流程，跟着流程去跑几圈，看看人家日常怎么做的；
刚开始很可能吃不准需求背后的管理诉求与管理目的，没关系反正人家也知道你不懂，大胆问“这个需求的目的是解决什么问题。”，问错了怎么办，说了外行话怎么办，丢人呗。没有里子就没有面子，不怕丢人才学的快啊。
在对需求开始理解的基础上，多反问自己，这个需求不这样做行不行（相信我只要你坚持在B/G做下去，总有一天你能听到这句话：你就按照我这需求做，做出来就是行业标准，你们公司就能拿到别的地方去卖了。）；
理解了工艺流程，业务流程，作业指导书的作业要求，也去业务场景实际看过了，也做过需求调研了，需求明确了之后，开始“幻想”：用思想做需求实现后的用户场景的沙盘推演，判断需求合理性，以及交互是否友好。刚开始做不到一个人的“思想推演”，那就喊小伙伴们一起做沙盘推演。这个环节非常重要，因为做为ITer很多我们以为是“常识”、“合理”的东西，在用户场景下就不一定了，有些需求实现看起来很“完美”，但是实际推演会发现“根本没法用”。我的产品经理的需求评审和原型评审环节，被我骂的最多的就是：你自己把你当用户，你每天都要用，这就是你的工作任务，你这个系统拿过去是添乱还是添堵还是帮人降低劳动强度？细节是魔鬼！
需求确定，也基本明确了怎么实现是合理之后，去研究这个需求的“管理意义”。比方说8点管晚餐的管理意义就是“主动加班”。只有去研究需求背后的管理意义，那么就会去琢磨这个需求的产生背景，管理要实现的目标，那么就会大概率发现这个管理目标实现后，会潜在“诱发”的新需求以及这个需求是否能满足管理目标。这样就能解决需求管理的最容易出现的两个问题：需求不全面，有漏项；隐性需求在上线后才会出现，要实现系统需要大改动。说个“鬼故事”：在某个公司辞职大概两年后，接到老同事的电话，问我一个需求文档的事情。大致意思是，产品需要升级改版，调研后采集了一些需求，在公司文档服务器上找参考资料的时候发现了一个旧需求文档，内容基本覆盖了目前的需求，因为这些事情当年是我负责，问我这个文档谁写的，当年为什么没有用。答案很简单：五、六年前写的隐性需求，用户就没有提，增加工作量的事情，评审的时候给毙了呗。
基于业务场景，对需求的分析能做到这一步的时候，基本上如果是“伪需求”就自然而然的会给识别出来。

挑战四：锚定价值

锚定效应（Anchoring effect）智库百科的定义是：指当人们需要对某个事件做定量估测时，会将某些特定数值作为起始值，起始值像锚一样制约着估测值。在做决策的时候，会不自觉地给予最初获得的信息过多的重视。

产品Slogan是用简短、浓缩且具有冲击力的文字，表达品牌主张或产品的特性、优点及价值的商业用语。产品经理在定义产品目标时，实际上就是在构思Slogan雏形与方向。

通过产品的Slogan，我们试图准确的向用户传递产品的价值，以锚定用户对产品的认识与期望。当产品经理在产品中导入机器学习技术的时候，首先需要思考的问题就是：如何向用户传递机器学习技术在产品中的价值。只有锚定机器学习技术导入后对传统技术的指标提升或者具有传统技术的不可替代性，且这种指标提升和不可替代性具有可直观感知的价值，产品才更“说服力”或“接受度”。否则产品形态很可能是“为了AI而AI”，无法让用户“买单”，所以落地困难。

换句话说，任何机器学习技术无法锚定到产品价值，就是“玩具”。当然，这句话删除“机器学习”四个字，依然是成立的。

理解了价值锚定这件事，就可以理解为什么当下AI的落地是“人脸”、“推荐”、“机器翻译”、“风控”、“目标检测”、“OCR”等方向是最好的。在这些场景中，机器学习的价值可以很“显性”的在场景中的业务中体现。而“自动驾驶”为何看起来非常热闹，初创公司拿钱毫不手软，真批量落地的只有特斯拉一家呢（你要说蔚来也算批量落地，也行，咱讨论的是“自动驾驶”部分不是“电动汽车”部分，不杠）？用我的逻辑来分析下：

抛开中美之间的车辆密度、驾驶习惯等前提，避免进入意识形态、崇洋媚外的讨论；
不管“吹”到L几、路测视频如何看起来不错，但是实际上ACC、车道保持、自动刹车这种L3级别的事情，也到不了99%；
某小*的广告也好，发布会也好，总体在强调“自动泊车”，国内大城市现在的停车环境如此恶劣，好不容易找到个狭窄车位，R档一挂，12个雷达一半都开始报警了，这种场景“老司机”都要靠手艺“多揉几把”才能停进去，“自动泊车”揉一个试试，典型的看起来很美，到哪里找满足条件的停车位呢？实际没啥用的“玩具”功能；
百度无人车是在某些园区运行了，体验过的都清楚是什么状况（不知道的自己Google吧）；
伦理和立法问题没有解决，特斯拉事故出了之后，都是系统无责任，那么用户花钱买了你的“辅助驾驶”，意义是什么；

当然，自动驾驶也不是现阶段就没法落地，在“非开放场景”中自动驾驶实际上已经挺好用了，比如：无人码头、自动化仓库等。只不过，在“开放场景”中，我是短期内不看好L3以上可真实落地应用的。

说实话“锚定价值”这件事，并不容易，要准确的在各种场景中发现技术的可用性并确定技术的“价值”对于产品经理来说，就是一个修炼与成长的过程。如何去修炼呢？建议从“创造性思维”开始。

挑战五：创造性思维

任何事情，第一个“吃螃蟹”的人，都是伟大的。比如我们中学学习的“几何”，基本还是是公元前300年欧几里得的《几何原本》中的东西，这个创造性思维有多恐怖？

机器学习技术本来已经是一个多学科交叉的边缘学科，当我们试图将其取得的成果导入到现实世界中去应用，实际上都在在做一件“创造性”的事情。在 B/G 领域试图将深度学习技术的成果导入时，以下几个问题必须要解决：

理解深度学习技术可以解决的问题“边界”；
意识到这些“边界”是和 B/G 某些业务场景有“契合度”的；
可以准确判断出算法错误后在这些场景中的“代价”；
能够基于场景设计出Fail-Safe完备的机器学习技术导入模型；
能够将上述模型在不增加（最好是降低）业务复杂度、成本可控的基础上，抽象、整合入用户现有业务场景；
对于新增机器学习技术的业务场景，可以明确其“价值”与“意义”；
提供功能完备的完整解决方案而非“功能点”；

说到创造性思维，必须要表扬下字节跳动的AI Lab、产品和美术团队，真的是把“人脸”、“分割”、“OpenCV”有关的技术在抖音上“榨”的淋漓尽致。

上述7个问题对于产品经理来说，每一项任务都是挑战，做好、做对都不容易，尤其是“价值”与“意义”的抽象与提炼，这个工作的效果，将会直接决定产品“能否卖得出去”。这些问题要很好的解决，需要的综合能力，而综合能力的养成，绝非一日、一时之功。一方面产品经理的综合能力需要时间去磨练，一方面AI创业公司需要抢时间去落地，这件事似乎是个“悖论”，也许这就是当前“AI落地难”的最核心问题：产品力不足以匹配机器学习技术力。

这个事情是比较难解决，也不是无解。只要以“科学家”为主的创始人、高管团队能够意识到“传统IT行业”人才的价值，去发现一批在B/G行业摸爬滚打多年做项目的候选人，不拘一格降人才，用他们的行业理解加速深度学习技术的导入，除此之外，只能“赌命”期望几个“产品天才”了。

本文转载自知乎专栏：不如无书

原文链接：

https://zhuanlan.zhihu.com/p/78042456

创作场景

AI 项目落地应用指南 --4. 产品经理的工作挑战（下）