四、产品经理的工作挑战
3.机器学习项目团队组成 <-- | --> 5.项目售前与解决方案
正如There are a thousand Hamlets in a thousand people's eyes.一样，对于“产品经理”的职责与定义存在有多种版本的解释，我们来看一下：
在英文wikipedia 中： A product manager is a professional role which is responsible for the development of products for an organization, known as the practice of product management. Product managers own the business strategy behind a product (both physical and digital products), specify its functional requirements and generally manage the launch of features. They coordinate work done by many other functions (like software engineers, data scientists and product designers) and are ultimately responsible for the business success of the product. Definition：A product manager considers numerous factors such as intended customer or user of a product, the products offered by the competition, and how well the product fits with the company's business model. The scope of a product manager varies greatly, some may manage one or more product lines and others (especially in large companies) may manage small components or features of a product.
在中文wikipedia中： 产品经理（英文：Product manager，缩写：PM）也称产品企划，是指在公司中针对某一项或是某一类的产品进行规划和管理的人员，主要负责产品的研发、制造、营销、渠道等工作。产品经理是很难定义的一个角色，如果非要一句话定义，那么产品经理是为终端用户服务，负责产品整个生命周期的人。 产品经理需要考虑目标用户特征、竞争产品、产品是否符合公司的业务模式等等诸多因素。一般而言，产品经理管理的是一个或者多个有形产品。但是，产品经理也可以用于描述管理无形产品如音乐、信息和服务的人。有形产品行业产品经理的角色与服务业中项目总监类似。 产品经理的职责描述目前仍然分歧很多，因人、因公司而异。即使是在相对较为一致的高科技行业，不同公司中的职位描述也是很不同的。但通常认为产品经理的职责主要包括：产品经理负责调查并根据用户的需求,确定开发何种产品, 选择何种技术、商业模式等。并推动相应产品的开发组织, 她或他还要根据产品的生命周期,协调研发、营销、运营等,确定和组织实施相应的产品策略,以及其他⼀系列相关的产品管理活动。
在百度百科中： 产品经理（Product Owner）是企业中专门负责产品管理的职位，产品经理负责市场调查并根据产品、市场及用户等的需求，确定开发何种产品，选择何种业务模式、商业模式等。并推动相应产品的开发组织，他还要根据产品的生命周期，协调研发、营销、运营等，确定和组织实施相应的产品策略，以及其他一系列相关的产品管理活动。
定义的百家争鸣与无法取得共识也从侧面印证了产品经理是一个极具挑战的岗位，虽然“人人都是产品经理”，但优秀的产品经理实际上凤毛麟角。本文并不打算全面的讨论产品经理工作内容与职责，仅从AI产品落地这个视角来探讨产品经理的工作难度与需要面临的挑战。此外，对以下两种产品经理对工作模式，也不在本文讨论范围内：
“对标”友商产品，做像素级功能“复制设计原型”的产品经理
“老大”提要求，就按要求做产品设计；老大没要求就不知道怎么做产品设计的产品经理
注：构思本章的内容安排，卡了两天。一方面觉得有关产品经理的工作内容和思考方法可以说的太多，很难在较短篇幅内做取舍；另一方面，“产品思维”是一个很大的话题，从逻辑思辨到人性把握到商业伦理这些“高深”的知识都与产品经理的思想高度与产品思维体系建立相关，很难用简单的文字体系化的说清楚到底什么是“产品思维”；第三，事实上大多数公司对于“产品经理”的认识与要求还是较“低”的，而建立成熟培训体系的则更少。所以，纠结于写的太深，会引起“故弄玄虚”的效果，写的太浅，于事无益，对于大家可能并不会有多大帮助。最后的决定是：为了整体进度，先阐述本人的关键认识完成本章，根据反馈（如果有的话）后期再重构本章的内容。
开胃菜
在正式开始之前，我们来看两个简单的DL产品的例子。
用户现有系统是在居民身份证数据库中检索某人的身份证信息： query('姓名')，高概率有重名，结果不唯一； 可以query('姓名'&'身份证号')，有小概率结果不唯一； 进一步query('姓名'&'身份证号'&'户籍地')，那么只有极小概率结果不唯一;
上述的这种结果不唯一，可以通过增加查询条件过滤，实现精准查询，且结果不唯一的原因是“可解释”的，如果出现查询返回结果错误，那么我们可以很快定位其原因：查询条件输入错误还是数据库信息错误。
用户提出需求，录入查询信息太麻烦了，你们不是有人脸识别么，用人脸来查询多方便。 作为产品经理，评估这个需求，需要考虑哪些问题？
返回的结果在Top5，但不是Top1，如何解释比较合理，交互和页面如何设计比较友好、直观；
与“底图”年龄跨度大之后的精度是否满足；
小孩的人脸识别准确度是否满足；
现场摄像头怎么安装，光照条件有没有干扰；
是不是可不去做“为了AI而AI”的事情，建议用户装一个“二代身份证读卡器”解决输入问题；
上述“人脸”这个场景，算法出错的导致的“后果”可能没有太强的“感觉”，因为结果即使出错也没有较大“副作用”。那么我们把场景换一下，换到医疗的X光片或者CT的“AI肿瘤识别”产品场景。
首先需要明确的是：这个场景下，DL出错是要“死人的”，产品经理需要考虑什么？
1 - 理解算法指标的“查准”与“查全”；
2 - 理解“漏报”的代价；
3 - 理解这种“小负样本”数据集对于模型训练精度的影响；
或许有“机灵”的产品经理会说，我们的“AI肿瘤识别”仅仅是辅助手段，还是建议专业医生对结果进行复核，这样就能规避算法错误后的法律风险。但是，如果算法不能做到“判断没有肯定没有，判断有不一定有”这个结果，不能协助医生筛选出一部分“肯定可以”不需要人工复核的数据，AI的意义何在？
所以，这也是目前“人脸”能大规模落地“医疗”很少有听到落地的最核心的原因所在：对于误判“会死人”的场景，大家都是极其慎重的。所以某独角兽曾经有段时间在拿到一轮投资后高举AI医疗方向的大旗，然后落地做的还是智慧城市的事情就比较好理解了。
希望开胃菜有助于各位理解在产品层面引入了DL之后，给产品经理工作带来的挑战性这个话题。
挑战一：理解技术
一直在反复说这句话：AI或者机器学习技术，是一门综合的边缘技术领域，涉及到多种技术的交叉，做为参与者如果对于相关技术基础没有概念，那会很难去顺利、准确的开展工作。一般情况下，对于产品经理的技术背景并没有“强烈”的要求，没有技术背景并不会是“硬伤”。当引入了深度学习之后，需要产品经理理解深度学习技术基本原理、了解不同任务领域的发展现状及SOTA、理解制约深度学习发展的因素、理解数据集对于深度学习的重要性等。
过去产品经理设计产品functions只需要明确输入/输出/交互/UI的要求，代码实现只要没Bug，那么一个function在同样的输入情况下，运行多少遍，结果都是应该可预测和一致的（可以用“函数式编程”的思想来类比理解下），但是当输入/输出之间是DL算法时，严肃的新问题就来了：结果是一定概率下的准确，且对于结果的错误难以预估与解释。当然Grad-CAM、Grad-CAM++给我们提供了更好的CNN模型预测的视觉解释性，但是我们依然无法解释“为什么会是这个结果”。
正是这样一个结果“不确定性”的因素的引入，就需要产品经理能够去在一定程度上去理解深度学习，最好能去动手做一些简单的分类任务，去理解机器学习、深度学习、CNN、RNN、LSTM、GAN等常用的基础知识。只有在理解的基础上，才能对“不确定性”有一定的“定性”的理解，而这些理解，才能更有助于产品经理去判断需求的可实现性、对错误的容忍度以及如何去理解场景（尤其是CV类）与边界条件等等。接着“开胃菜”的“AI肿瘤识别”产品来说，产品经理如何去理解这句话：“判断没有肯定没有，判断有不一定有”。
这句话的表达的意思是：如果模型判断没有恶性肿瘤，那么判断的准确性是100%；如果模型判断有肿瘤，则不一定真的有。如果还觉得理解有困难，用大白话翻译就是：“宁可错杀一百，不可放过一个”。懂了么，要想深度学习“可信”的参与医疗领域落地，对模型的技术指标要求之一就是“可以错判，但不能漏判”。要理解这句话背后“隐藏”深度技术知识，就要从最基本分类评估的混淆矩阵开始。
“炼丹师”、“调参侠”对这个混淆矩阵的含义是非常清楚的，以防产品经理有不清楚的，简单解释下基本术语。假设我们的分类目标只有两类，计为正例（positive）和负例（negative）分别是：
True positives(TP): 真正例。被正确地划分为正例的个数，即实际为正例且被分类器划分为正例；
False positives(FP): 假正例。被错误地划分为正例的个数，即实际为负例但被分类器划分为正例；
False negatives(FN): 假负例。被错误地划分为负例的个数，即实际为正例但被分类器划分为负例；
True negatives(TN): 真负例。被正确地划分为负例的个数，即实际为负例且被分类器划分为负例。
对于分类准确性的度量指标常用的有以下几种：
正确率（accuracy）
最常用的评价指标，正确率是被分对的样本数在所有样本数中的占比，通常来说，正确率越高，分类器越好。accuracy = (TP+TN)/(P+N)，
错误率（error rate)
错误率则与正确率相反，描述被分类器错分的比例。error rate = (FP+FN)/(P+N)，分对与分错是互斥事件，所以：accuracy = 1 - error rate。
True灵敏度（sensitivity）
sensitivity = TP/P，表示的是所有正例中被分对的比例，衡量了分类器对正例的识别能力。
特异性（specificity)
specificity = TN/N，表示的是所有负例中被分对的比例，衡量了分类器对负例的识别能力。
精度（precision）
precision=TP/(TP+FP)，精度是精确性的度量，表示被分为正例的样本中实际为正例的比例。
召回率（recall）
召回率是度量有多个正例被分为正例，recall=TP/(TP+FN)=TP/P=sensitivity，可以看到召回率与灵敏度是一样的。
F1-score
也称为综合分类率，综合考虑查准率与查全率：
$F1=\frac{2 \times precision \times recall}{precision + recall}$。
我比较喜欢用“话糙理不糙”的比较接近“人类”语言的方法去解释一些东西，上面这几个指标的含义可以这么理解。accuracy：预测和实际一致的水准；precision：预测是正例中真的是正例的水准；recall：实际的正例被准确预测出的水准，所以，precision一般称之为“查准率”，recall一般称之为“查全率”。如果还不理解，那么建议你去看看Google机器学习速成课程，有中文版，而且图文并茂解释的通俗易懂，确实是入门好课程。
说了这么多，就为一件事，假设我们有三个models，其查准与查全指标如下表。
Models | Precision | Recall |
Model 1 | 0.89 | 0.57 |
Model 2 | 0.81 | 0.72 |
Model 3 | 0.58 | 0.92 |
怎么选？“科学”的建议肯定是算F1-score，哪个高用哪个,如果真是这样，我费力码字是为什么？回头再来看看之前提到的“AI肿瘤识别”例子中的一句话“判断没有肯定没有，判断有不一定有”。如果我们把“有恶性肿瘤”定义为正例（Positive），那么这句话就可以翻译成：对FN的期望为0的基础上Precision越高越好，FN如果为0，那么Recall=1。所以在这个场景下，我们选择模型的思路是Recall最高的情况下选择Precision高的，而不是去用F1-score求综合最佳。
Models | Precision | Recall | F1-score |
Model 1 | 0.89 | 0.57 | 0.69 |
Model 2 | 0.81 | 0.72 | 0.76 |
Model 3 | 0.68 | 0.92 | 0.71 |
理解了么？再用大白话解释一下。这个场景的分类任务，模型一旦预测错误，结果可能会“死人的”，所以，“漏报”是不可接受的，“漏报”在上面的混淆矩阵中就是出现了FN（假负例），所以我们希望FN越小越好，理想值为0 。所以在上面的三个模型中，显然我们应该考虑使用Model 3，而不是F1-score最高的 Model 2。而且，后期我们优化方向应该是优先解决FN下降的问题。
一句话总结：F1-score是学术界为了综合评估模型的一个指标，在我们实际业务场景中，产品经理一定要能判断对模型的需求是查准还是查全，千万不要教条主义。
有人可能会有疑惑，这些内容不应该是ML Researcher、ML Engineer去考虑的么，为什么需要产品经理去理解这些技术细节？
从工作分工来说，产品经理要确定业务场景以及对模型指标要求的大致范围，所以产品经理至少需要明白：
错误预测带来的风险有多大；
业务场景的需求是“准”还是“全”，其中哪一个是关键指标，可接受下限是多少；
如何去和用户沟通“准”和“全”之间的“跷跷板”关系，让用户理解这种“不完美”的结果已经是现阶段最佳；
模型训练阶段，通过误差分析，定位到数据集的问题，是否能够理解并与用户沟通“脏数据”的问题；
产品立项阶段，能否客观的预估出一个合理、可实现、可接受的性能指标；
顺着这个思路，做智慧城市、公安图侦的产品经理，琢磨下ReID（行人重识别）这个刚需和不同场景的人脸呗。
如果产品经理对于机器学习的技术难度、原理与SOTA没有一定认识，那么对于和ML结合的需求评估和分析，如何才能保证准确、无偏差并且没有“不当承诺”？
比如，你是“人脸独角兽”之一的产品经理，去做用户需求调研，用户说“你们公司人脸那么厉害，给我们做个ReID吧。”你一听这东西公司有小组在做啊，肯定没问题，果断答复没问题，可以做。用户说，人脸你们准确度都99%不止了，这个准确度做到98%没问题吧。怎么回答？
说，没问题。那你就是“真傻”，不当承诺的后果，就是回公司之后，给“科学家”们一顿“怒怼”。
说，不知道能做到多少，让客户等下，你出去打个电话问问。
说，估计98%有点悬，目前主流的ReID数据集是DukeMTMC-reID和清华大学的Market-1501数据集，数据集都不算太大，而且也没有实战中需要考虑的“换衣重识别”等场景，在这个上面先在最好的mAP是……，top1是……，top5是……，这已经是实验室的最佳水平了，我理解的ReID这个事情比人脸识别难度大在于以下几个方面“……”，考虑到实际现场场景肯定比校园校园复杂，指标肯定会下降，但是具体能到多少我也说不好，要回去请教科学家们，要不给我拷点咱们的视频，我回去安排做个测试，结果出来给您个准确数字。
哪一个答复最好？显然是最后一个，一方面体现了专业性，一方面体现了严谨性，运气好还能给公司带回去一批数据，即使你给不出用户想要的数据，用户也是会相信你不是在“忽悠”。有关此部分需求沟通对内容，会在第五章再补充。
软件部分对需求，不管多离谱，理论上都是时间和成本对问题，不能实现的可能性并不高；但是机器学习领域的需求，在现阶段，确实还存在“给多少钱也搞不定”的情况。所以，产品经理要能够比较得心应手的做好需求管理工作，一定要有一些相关技术背景知识。
有关为什么需要ML产品经理具有一定的技术的背景的原因，暂且到此，不再继续展开。
挑战二：场景理解、业务抽象
在讨论场景理解之前，先说一个工程领域的Fail-Safe机制。Wikipedia的解释为：In engineering, a fail-safe is a design feature or practice that in the event of a specific type of failure, inherently responds in a way that will cause no or minimal harm to other equipment, the environment or to people.简单来说就是：故障不可避免，重要的是故障之后保证安全。Fail-Safe的机制放在机器学习的落地应用设计中，应该会这样考虑：预测错误不可避免，重要的是预测错误后代价可接受。
考虑到ML领域大多都是计算机、CS、自动化等专业技术背景居多，对于工程的概念可能不多，举一个可能天天都在接触的场景的例子来加强理解。大多数公司的玻璃大门都用的“电磁锁”，可以很方便的和刷卡、指纹等门禁系统集成。有没有人考虑过一个问题：如果停电了，这个电磁锁是什么状态，开锁还是锁止？按照消防要求，这种电磁锁一般都是失电开启。你想啊，大楼有火警、同时也停电了，你公司的大门打不开了……这多可怕，所以“Fail-Safe”机制一定是失电开启才安全。那么对于非火灾等意外状态下的失电情况下，这种锁岂不是就没有安全性了？所以“Fail-Safe“机制是，在安装的时候配一个小UPS电源来应对意外的停电情况，保证门是锁止的。如果长时间停电，UPS还是会没电的，这种情况怎么办？答案很简单：“铁将军”上场，回忆下是不是每次放长假的时候，行政小姐姐是不是都会最后走，给大门挂上“铁将军”（或者给加班的小哥哥卖个萌，让他走的时候一定帮忙锁好门）。
这种设计，就是典型的Fail-Safe机制：失电 --> UPS后备供电 --> UPS失效 --> 门锁开启。
正是因为这种Fail-Safe机制的设定，考虑的是故障后门可以打开保证人身安全，所以不能考虑财产安全，这种门锁也只能应用于写字楼的办公场所，因为写字楼有物业和保安，故障失效后的安全保证还有这一道防护。
现在是不是对于工程领域的Fail-Safe机制有点概念了？有人或许会疑惑，难道没有机器学习的时候，软件系统就不需要关注这个问题么？当然需要，但是没有深度学习的时候，Bug除外，程序本身的运行是鲜有故障的（比如内存泄露，爆掉了，所以C/C++难啊）。故障一般都出现在操作系统、网络、服务器、存储层面，所以我们会有负载均衡、主从、集群、高可用、故障自动转移、RAID、多链路、冗余、两地三中心等等这些耳熟能详的“容灾”策略。当然，这些都不在本文的讨论范围内，本文仅关注“机器学习推理错误”之后的处理策略。
回到“开胃菜”的两个简单应用场景讨论，来分析下“理解场景”有哪些难度。
对于“人脸识别”技术来说，不论是SDK还是Serving系统提供APIs，对于业务系统来说“看起来”就是一个需求确定之后的调用问题，并没有什么特别之处。回顾下在第一章中引用的一张图片。
这个场景的需求，可以用一句话描述：行人闯红灯抓拍后，通过人脸图片查询身份信息，分别推送人脸图片、全景图片与身份信息（部分隐藏）到大屏显示，起到警示教育作用。
图片的“人工智障”效果就是“按照需求”设计产品，并没有对场景进行分析与推敲，更没有对边界条件与推理错误的后果进行评估与处理。从结果看，技术没问题：要人脸检测，检测到并且推送了；错在产品对场景理解不足，事后诸葛亮的详细分析下。
指标选择。这个场景就是人脸检测任务，SOTA精度足以满足这种场景使用，检测结果也不需要做为输入去触发其余业务系统，所以在算法层面，选择F1-score最高的检测算法足矣。
Fail-Safe机制。由于此系统的使用是公众场合，产品经理“应该”预计到误报之后的结果有可能变成新闻热点，进而影响公司技术形象。为了避免“误报”，应该要求后端业务系统设置一个较高的“置信阈值”。
异常分析。场景需求是对“行人在斑马线闯红灯”抓拍，那么检测区域是“斑马线”，检测目标是“闯红灯行人”。检测区域可以通过代码来控制，能够规避异常状况。如图，公交车身广告的“人脸”在红灯时段出现在“检测区域”，所以检测到后做了展示推送，这属于一种异常，产品经理首先要预估到这种异常可能，另外要给出这种异常的处理方案。同理，可以“预测”某人拿一个有人脸广告易拉宝之类的东西闯红灯，显然也是会误报一张人脸的。去研究这些肯能存在的“误报”情况，可以提取出一个共性：非活体人脸的误报。
边界分析。基于对异常对分析，那么似乎把检测边界设定为：斑马线、闯红灯、活体、人脸更为合理。
技术方案。在这种非约束场景下，如何做活体验证？支付宝之类的眨眨眼、扭扭头，显然不可能了。那么加一个目标检测呢？如果检测到有汽车，然后人脸坐标落在汽车对Box，则认为是异常。这样是可以屏蔽上图的错误，但，如果恰好有人闯红灯，身后通过一辆公交车，这就要漏报了。有没有更好但方案呢？应该有。行人闯红灯过马路，这是一个连续的动作，而非静态动作，而且这个时间长度是几秒以上，我们可以从这里下手。一是可以考虑增加“姿态估计”的联合判断，找到“人体”，通过姿态估计判断是在行走，再去检测人脸；二是可以考虑“轨迹”，检测到第一张人脸后不做推送，而是继续检测，如果连续检测到同一张脸（1:1的识别，计算量也不大，边缘设备也能搞定），而且，计算坐标后可以判断是“过马路”行为，那么再去推送（公交车是横向移动，并非纵向移动），但这种处理，是无法解决“易拉宝上但人脸问题”，所以最优解应该还是考虑姿态估计。还有一种可考虑的方案就是引入深度信息，进行多模态方向的人脸识别。
考虑到还需要检索身份信息，这个1:N的人脸任务并不难，但是产品经理需要明确的是底库的库容多大，是百万级还是千万级还是亿级。另外就是要和用户约定好查询返回为空的时候，显示的占位信息是什么。这种小细节最容易忽视，都不提，程序猿小哥哥顺手给你返回个“未检索到记录”怎么办？
所以，通过场景分析，对于这个“行人闯红灯抓拍”项目，我更倾向于将这个项目需求定义为一个“姿态估计+人脸检测/多模态人脸识别”任务。
讨论完这个“马后炮”的场景分析，再来说一个“构想中产品”的场景分析思路。
先简单交代下背景：前一段时间有个欧洲团队想回国内做算法落地的项目，有工作机会，所以就对接了。核心算法就一个：微表情识别，准备落地的场景是：公检法、教育、风控等方向的情绪识别，产品没看到，只看到Demo，基本和我们做目标检测的Demo差不多的效果。由于在国内的合伙人有一些公检法的资源，所以准备先在这个行业找场景落地。怎么落地，情绪识别之前玩过看了看效果，也没有做深入研究，假设我去规划这个产品落地的事情，我会怎么做？
表情（情绪）+ 是否说谎 + 公检法，这几个关键词组合在一起，很自然可以想到“审讯”过程的“测谎”场景。传统的基于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行业摸爬滚打多年做项目的候选人，不拘一格降人才，用他们的行业理解加速深度学习技术的导入，除此之外，只能“赌命”期望几个“产品天才”了。
案例分析
计划结合上述五个挑战，找一个产品来具体说明下产品经理具体该如何思考、工作，确保设计的产品具备可交付、可落地的要求，但是时间有限，准备将这个案例先放一放，后期再补，先开始下一篇。
Last updated
