2.14. 技术理解力¶
2.14.1. 为何需要¶
在传统意义上，产品经理根据需求特性，抽象产品特性，思考产品逻辑，制定产品目标、愿景、实施计划，拟定详细的文档，按照交互-设计-重构-前后台开发-测试验收上线的流程，一步步推进即可。但看似合理且被大多数产品经理认为是理所当然的流程中，却隐藏着技术理解层面严重的bug。
2.14.2. 技术理解的作用 14¶
当你要做一件事，而发现程序员做不到的时候，你就很难受了，进度一定会被拉下来，甚至长时间在这里堵着，这就是技术的重要性，技术不足以决定你商业上的成功，但是它足以阻碍你成功。也就是当你发现一个商机的时候，如果你的技术并不足以支撑你去完成实现你的产品的时候，那你就只能眼睁睁地看着商机从你眼前溜走，无可奈何，然后就会发生一件事，技术和业务方互相指责，那只要到了这一步，其实你的公司离破产也就不远了，程序员聪明一点，这个时候就应该赶紧找工作了32
2.14.2.1. 了解层次¶
形成缜密的逻辑思维：PRD方案的完备要求，如果不完备，可能开发结构大大不同，造成工期延误返工的现象。 22 也要信任研发经理评估出来的工期 25
算法的适用场景：知道要做什么，风险是什么-走哪条路能到。技术给产品带来多少价值19；解决方案转化到技术的资源需求（需要更多的数据，更完善的算法模型 19），缩短研发工程师找到最佳技术方案的时间 16；考虑风险，不完全依赖AI，而是AI辅助20，如人脸识别可能被攻击，用“异步审核”策略，用人工检测的方式保证通过率和准确率，保证用户体验，降低业务风险。
技术边界、与技术团队的能力边界、技术成熟度：知道什么能做，什么不能做，技术最好的情况是如何的。——路可能有障碍但能通。开发部门可接受，使得业务可落地。哪些理论已经有了最佳实践。做法：和ML Engineers每周一起讨论AI/ML论文，研究应用到我们产品上的可行性。23
权衡技术方案（了解整个 AI 端到端产品的工具和技术24）：知道什么好做，什么不好做。——路上的障碍物好不好处理。使得业务能按时完成。也即，你知道系统中的每个模块的定位和意义（数据摄入工具（比如 Kafka）、数据处理系统（比如 Spark）以及 处理大数据的 NoSQL DBMS（比如 Cassandra）、云服务（利用 AWS、GCP、IBM 和 Azure）），并有能力以业务需求为导向协助技术人员、甚至引导技术人员完成对系统架构的优化与改造，使其在未来能够更好的满足业务发展对于技术的要求。
业务长时间可用性：知道什么该做，什么不该做。——这些障碍物究竟该怎样处理，才能让它们在最长的时间范围内不会成为干扰。当你与技术人员合作设计方案的时候，应该从业务发展的角度看待问题，帮助技术人员明确各个模块的定位，使得我们的系统能够在尽可能长的时间保证可用性，能够随着业务的发展一同成长，而不是频繁重构。
2.14.2.1.1. 懂算法的程度 20¶
以监督式支持向量机SVM为例，AI产品经理懂的SVM内容建议如下：
首先：明白SVM模型成熟的用途。
例如：
其一用于文本和超文本的分类，在归纳和直推方法中都可以显著减少所需要的有类标的样本数。
其二用于图像分类。支持向量机能够获取明显更高的搜索准确度。
其三用于手写字体识别。
其四用于医学中分类蛋白质，超过90%的化合物能够被正确分类。
其它则靠AI产品经理配合SVM算法模型专家共同探讨研究。
其次：知晓SVM的定义及核函数表达式
支持向量机在高维或无限维空间中构造超平面或超平面集合，其可以用于分类、回归或其他任务。直观来说，分类边界距离最近的训练数据点越远越好，因为这样可以缩小分类器的泛化误差。
SVM的原始问题是在有限维空间中陈述的，但用于区分的集合在该空间中往往线性不可分。为此，有人提出将原有限维空间映射到维数高得多的空间中，在该空间中进行分离可能会更容易。为了保持计算负荷合理，人们选择适合该问题的核函数 k(x,y) 来定义SVM方案使用的映射，以确保用原始空间中的变量可以很容易计算点积。高维空间中的超平面定义为与该空间中的某向量的点积是常数的点的集合。
定义超平面的向量可以选择在数据基中出现的特征向量Xi的图像的参数ai的线性组合。通过选择超平面，被映射到超平面上的特征空间中的点集 x 由以下关系定义：
如果随着 y 逐渐远离 x，k（x,y） 变小，则求和中的每一项都是在衡量测试点 x 与对应的数据基点 Xi的接近程度。这样，上述内核的总和可以用于衡量每个测试点相对于待分离的集合中的数据点的相对接近度。
第三、至于线性SVM的间隔计算可以由SVM模型算法工程专家来操作。AI产品经理明确SVM的用途、定义、和在遇到问题的时候知道这个问题是由SVM引起的或者可以找SVM专家协作解决即可。
2.14.2.1.2. 融入开发过程¶
能利用自已的行业知识帮助算法工程师进行数据预处理,获得高质量数据集。
能对解决方案所需的开发量进行进行初步估计。
能将产品需求拆分成系统模块并进行简单旳任务分解,能找到相关开发人员推动落地实施。
数据采集、数据标注、数据清洗、数据扩充、数据特征。
如何与开发高效沟通？33
需求明确
方案确定
为特殊事件做好准备，以解决方案为主要手段
时刻更新产品需求文档，并告知所有相关人员
这点在后台体现的比较多，比如一个页面上的一张图片，是取自别的地方的，但是这张图片比较小，可以使用裁剪的方式，如果不去和开发沟通，可能就不会去裁剪，导致最后图片是模糊，或者是比例失调的。而且剪裁的位置也要说清楚。
2.14.2.1.3. 协助系统架构师搭建合理的系统架构¶
明确系统中的每个模块的定位和意义
从业务发展的角度指导技术人员进行系统架构的设计
2.14.3. 产品形式¶
主流的产品有客户端、Web端（PC网页端）、移动端（WebApp、原生App、HybridApp）
2.14.4. 对软件设计的理解问题¶
面向过程，是指以任务/事件为中心，进行软件设计。
面向对象，是指以事物为中心的软件设计。
搭乘地铁从T站到F站的简单例子来说明：
如果用面向过程的设计方式，会将地铁启动、运行、到站等一系列的动作设定为过程，也许还要设定地铁维修的过程。然后将这所有的过程按照逻辑串在一起，完成一个任务。
如果用面向对象的方式设计，那直接将地铁定义为对象，地铁的颜色、形状等则为属性，地铁的运行和到站就是地铁的方法，也即地铁的行为，而不是过程。
2.14.5. 对需求实施的理解问题¶
曾因为一个简单页面的图文修改，对技术人员嗤之以鼻，但当了解内情后才发现，不仅仅是修改html的问题，还涉及到css、json、数据库读取修改以及数据字段的调整。所以对于需求的理解，从产品经理和技术人员角度而言，所看到的大小和范围，也许就像冰山一样，水面和水底有很大的区别。
在这种技术层面的改动要大于产品预期的情况，难免就会产生分歧。为了尽量使需求的实施理解，也能保持同步，可以参考以下要素：
参加技术人员的概要设计评审：当产品需求提到技术层面时，一般技术人员会对需求进行概要设计、评审、详细设计及评审、开发实施等环节。当然产品经理一般不会在技术层面介入太深，但为了尽量使需求不偏离目标，参加技术层面的概要设计评审，是很好的一个选择，虽然对于多数产品经理而言，不一定能全听懂技术在概要设计层面的讨论。参加概要设计评审可以了解需求在启动技术设计时，涉及到的相关系统、干系人、内外部团队等，大致了解技术实施层面的困难、瓶颈和资源需求。以减少用户类型、路径等环节的偏差。
提前向技术同步产品的远期愿景：同步产品愿景和长期版本目标，可以是在需求刚出现时，也可以是在交互设计时，但个人感觉最晚不能晚于技术的概要设计。提前同步产品愿景，可以在技术人员做技术设计时，能确定数据、架构、迭代以及预留字段，更能确定技术实现方式，是按照较大的系统实施，还是按照简单的逻辑实施，因为很多时候，技术的实现方式有多种选择。以免产品的期望是宏伟大厦，因为没有提前同步给技术，导致技术在打地基时，按照普通的平房实施了。
了解需求中的关键点：这一点需要在每一次技术沟通中进行确认，但尽量在技术概要设计前了解清楚，这也就是参加技术概要设计评审的重要性所在。了解需求的关键点，了解了相关困难、瓶颈、资源需求等，对于需求实施的排期、时间节点评估则会掌握的比较清晰。
2.14.6. 系统设计中需要明确的问题 12¶
在系统设计中，至少需要明确以下问题：
该系统涉及到的模块有哪些？哪些模块是已有的，哪些模块是新增的？
每个模块的定位，或者说定义是什么？在系统中扮演什么样的角色，起到什么样的作用？旧有模块的定义是否满足我们的要求，新模块的定义是否清晰明确？
每个模块的输入输出是什么？每个模块所获得的输入是否刚好满足其能完成任务的需求，既不缺乏信息，也不存在会导致依赖的信息冗余？
模块间的上下位关系是否明确，是否与该模块的原有定位相契合？
系统整体的模块的调用顺序是什么？是否拥有合理的信息通路？是否保证了模块上下位关系的一致性？是否存在下位模块僭越上位模块进行/被进行跨层级调用的情况？
2.14.7. 项目进度推进¶
产品和技术都转换思维，首先是了解对方的想法，然后是从对方角度思考，共同发掘问题和困难所在，再去解决。这样提前预估、制定时间节点、共同督促的推进方式，才能使项目推进更顺利。
了解实时进度，根据需求的关键点，把控项目进度：前文提到，了解需在技术实施环节的关键节点，目的就是为了整体把控需求，防止在关键节点掉链子。有时是需要产品协助，或是督促技术打通关键节点的问题，有时则是因为前期的评估和了解，提前将实施中关键节点可能存在的问题消化掉。
需求实施的“时间最小单元”不能太久：需求实施的“时间最小单元”，我把它定义为，需求实施过程中，可以标识为里程碑或是有明确交付物的最短时间。例如一个H5的登录注册功能的开发，判断每个输入框信息输入格式是否准确，将信息提交至数据库，数据库写入数据并返回是否正确写入，给用户对应的反馈，这些每个环节的开发所需时间，都可以理解为一个时间最小单元。按照正常的逻辑，这样的时间最小单元，建议是0.5天至3天，最好不超过3天。
时不时的讨论推进的困难和进度、调整变更需求13：对于推进实施中的需求，不能当成一个完全交出去的任务，更不能当“甩手掌柜”，而是应该参照时间最小单元，不时的讨论推进中是否存在困难，应如何解决困难，询问时间最小单元中的推进进度，如有没有进度，则可能需要调整计划了。
2.14.8. 什么是技术架构？¶
架构就是对系统中的实体以及实体之间的关系所进行的抽象描述，是一系列的决策，架构也是产品的结构和愿景。
系统架构是概念的体现，是对物/信息的功能与形式元素之间的对应情况所做的分配，是对元素之间的关系以及元素同周边环境之间的关系所做的定义。
做好架构是个复杂的任务，也是个很大的话题，本篇就不做深入了。有了架构之后，就需要让干系人理解、遵循相关决策。
2.14.9. 单体应用和微服务¶
同样的，在早期大部分应用不会考虑到技术架构，但随着用户增加和未来性能要求则需要重构，这就需要到技术资深的架构师。而市面上的架构主要分为下面三类
单体应用程序：应用程序的全部功能被一起打包作为单个单元或应用程序.这个单元可以是JAR、WAR、EAR，或其他一些归档格式，但其全部集成在一个单一的单元. 微服务：微服务是一个新兴的软件架构，就是把一个大型的单个应用程序和服务拆分为数十个的支持微服务。一个微服务的策略可以让工作变得更为简便，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。
2.14.9.1. 单体应用¶
2.14.9.1.1. 优点¶
方便调试，代码都在一起；
没有分布式开销，所有服务都在本地容器内；
中小型项目可以快速迭代，不需要太多资源。单体应用缺点：
2.14.9.1.2. 缺点¶
可复用性差：服务被打包在应用中，功能不易复用；
系统启动慢，一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动、重启时间周期过长。
线上问题修复周期长；任何一个线上问题修复需要对整个应用系统进行全面升级。
2.14.9.2. 面向服务架构（SOA）¶
2.14.9.2.1. 企业服务总线（ESB）¶
ESB是面向服务架构(SOA)的核心构成部分，指传统数据连接技术（web、xml、中间件技术）结合的产物，简单来说，就是一根管道，用来连接各个服务节点，为了集成不同系统，不同协议的服务，服务总线做了消息的转化解释和路由工作，让不同的服务互联互通；是一个具有标准接口、实现了互连、通信、服务路由。
2.14.9.2.2. 特点¶
系统集成：从系统角度讲，解决了企业系统与系统间通信问题，把原来散乱、无规划的系统间的网状结构梳理成规整，可治理的系统。在梳理时则需要引用一些产品，常用的是企业服务总线（ESB）、技术规范、服务管理规范。主要解决核心问题，无序变有序。
系统的服务化：从功能角度讲，把业务转换成可复用、可组装的服务，通过服务的编排实现业务的快速复制。目的是把原先固有的业务功能转变为通用的业务服务，实现快速复用。主要解决的核心问题，原来固有业务可复用。
业务的服务化：从企业的角度讲，把原来职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力。把一个业务单元封装成一项服务。主要解决的核心问题是高效。
2.14.9.2.3. 优点¶
数据统一，共享数据库，使服务接口使用同一的数据模型的数据，确保数据一致性
灵活性较高，缩短产品和服务的上线时间，降低了开发与改变流程的成本系统
由子系统组成，系统易于重构
2.14.9.2.4. 缺点¶
技术不匹配，在某些情况并不能轻松对操作平台进行重新打包，原因是业务功能结构需求不匹配
系统间交互需要使用远程通讯 ，一定程度上降低了响应速度
2.14.9.3. 微服务架构¶
2.14.9.3.1. 优点¶
分而治之；单个服务功能内聚，复杂性低；方便团队的拆分和管理；
单独部署，独立开发；
易于扩展，某一项服务的性能达到瓶颈，只需增加该服务的节点数即可，其它服务不改变
易于维护，每个微服务的职责单一，复杂性降低，不会牵一发而动全身
2.14.9.3.2. 缺点¶
开发难度大，前期服务的定义和拆分需要较大工作量，每个服务都需要单独部署，运维、测试成本增加；
跨服务的调用通常是不同的机器，甚至是不同的机房，开发人员需要处理超时、网络异常等问题，原来的函数调用改为服务调用。
效率相对低，团队依赖强，一个服务的版本延迟会拖慢整个应用的开发周期。
需要分布式事务的支持。
2.14.9.4. 中台 10¶
中台是随着公司业务高速发展，组织不断膨胀的过程中暴露的问题需要解决。将企业的核心能力随着业务不断发展以数字化形式沉淀到平台，形成以服务为中心，由业务中台和数据中台构建起数据闭环运转的运营体系，供企业更高效的进行业务探索和创新。包括但不限于数据中台、技术中台、业务中台、组织中台等31
中台做到前后分离，后台统一提供数据接口，前台实现业务流转。
中台与微服务的区别：
中台是提升企业的能力的复用，一种方法论/思想。
微服务是独立开发、维护、部署的小型业务组件，一种技术架构。
中台与微服务的关系：
微服务架构，是实现中台思想的落地的重要手段。
中台解决的核心问题：
为减少重复业务系统开发及实现系统数据共享一个技术平台底座，将多年技术沉淀的价值最大化，统一各个业务部门或系统重复使用、重复建设的功能和系统统一规划和管理。
什么时候需要中台：
如阿里：淘宝，有订单、库存、评价、积分、物流等业务系统。天猫也有订单、库存、评价、积分、物流等业务系统。1688，也有类似业务系统。多个系统有重复业务系统需要建设，且系统间数据不能完全共享，系统各自运行。此时使用技术中台以及业务中台，来实现业务重用及数据共享，把技术沉淀价值最大化。
AI中台，更多见：https://aieye-top.github.io/d2cl/chapter_deploy/AI-zhongtai.html
2.14.10. 与测试相关的专业名词¶
有自动化测试，接口自动化测试，功能测试，性能测试，UI自动化测试，压力测试；自动化测试完成不了的我们测试人员会编写测试用例进行测试26常见的测试工具，如jmeter，这些会些基本的测试就可以了。27
提测研发人员在开发完某个功能之后，把代码打包并提交给测试人员开始测试，就叫提测。
复现之前测试发现的Bug 再次出现，就叫复现。能否复现对于研发人员排查Bug非常重要。
测试用例测试用例是指测试人员根据PRD 撰写的测试流程及事项。例如，知乎要上线一个收藏文章的功能，点击“收藏”按钮，该文章就出现在收藏列表中，并且“收藏”按钮变为“已收藏”按钮，这就是一条测试用例；点击“已收藏”按钮，“已收藏”按钮就变为“收藏”按钮，同时该文章从收藏列表中消失，这就是另外一条测试用例。
功能测试功能测试是单一功能的测试，如某次迭代要做一个分享功能，功能测试就是测试分享这个功能是否符合PRD 的要求。
回归测试可以将回归测试理解为整体测试。例如，某次迭代要上线一个分享功能，需要测试一下这个功能是否会影响其他功能的正常使用，所以回归测试要测试的就是整个产品的所有功能。（回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。28）
测试报告测试报告是指在测试完成之后，由测试人员撰写的说明Bug 均已修复，可以上线的邮件或报告。
2.14.11. 产业生态 15¶
基于 Wintel 体系的计算机产业生态：以“Intel+Windows+软件”生态
基于 Android/iOS 体系的智能设备产业生态：以“CPU（ARM）+操作系统+开发工具+应用商店+各类应用”为核心
基于云原生（Cloud Native）体系的云计算产业生态：构建起以“云厂商+异构软硬件+云边端+Serverless 化+软件全生命周期+开发者+企业客户”为核心
2.14.11.1. 云原生¶
容器+Kubernetes 技术的逐步成熟与发展，以“云原生（Cloud Native）”为关键词的技术生态雏形基本确立。
云原生技术：让系统更加弹性可靠容错、松耦合、易管理、可观察；代表技术是容器、微服务、服务网格、不可变基础设施和声明式 API。
云原生产品：云计算平台提供的数据库、大数据、中间件、函数技术、容器服务等开放标准的原生产品服务。
云原生架构：生于云长于云，最大化运用云的能力，依赖云产品构建的 IT 架构，让开发者聚焦于业务而不是底层技术。
以容器、Kubernetes 技术为主，向下封装底层基础设施差异性，如异构环境，异构硬件，向上支撑多样性的工作负载，如新型计算等，覆盖云、边、端，赋能无边界计算、分布式云，云原生逐步成为云计算的新界面，新一代的操作系统。
从 ISV（独立软件提供商）的软件全生命周期，到硬件厂商、云厂商、ISV、企业客户之间的新一轮的软硬件的供需体系，再到云计算技术、社区、ISV、开发者之间的技术互动体系中，云原生技术作为新一代云技术操作系统
当前云原生技术发展趋势是，以容器、Kubernetes 为核心的云原生技术逐渐稳定与成熟，后期将发展为以服务治理、云边端一体化、Serverless 等上层技术栈为创新发展的核心。
2.14.12. 懂技术，更得懂AI的局限 4¶
除了基本的产品技能还要掌握AI基础技术知识，如NLP自然语言、DL深度学习、ML机器学习、大数据等
AI公司的产品里一类是应用AI技术的垂直业务产品，另外一类是AI服务的平台产品。前者负责AI能力在细分领域的应用；后者则是对AI能力的汇总和包装，例如各种AI开放平台、各种云计算平台，这就要求产品经理必须熟知公司内部的AI技术能力，还要有能力作为售前支持，为使用方提供技术咨询。
当实现一款功能的设计的时候，最基础的认知就是要首先确定什么能做什么不能做，对于可见的一些服务，比方说手机APP中的用户使用用链路来讲，一个功能能否实现是比较容易确定的。但是如果是AI类产品的设计，需要涉及到对算法以及数据的理解，只有当产品经理真正了解每种算法的玩法以及数据的使用链路，才可以将功能做活，保留高鲁棒性。
大部分的AI产品的服务对象是to B端的企业用户， B端用户和C端用户的使用行为习惯是截然不同的，所以就有很多C端的产品转向B端出现的水土不服。
2.14.13. 机器学习增加了不确定性 7¶
有了机器学习，我们通常会得到一个在统计上比简单技术更准确的系统，但也有一个缺点，那就是一小部分模型预测总是错误的，有时会以难以理解的方式出现。
这种转变需要在软件工程实践中进行根本性的改变。用看似相似的输入输出对数据集训练的相同神经网络代码可以给出完全不同的结果。相同代码生成的模型输出将随着训练数据的大小(标记示例的数量)、网络训练参数和训练运行时等内容的变化而变化。这对软件测试、版本控制、部署和其他核心开发过程有严重的影响。
对于任何给定的输入，相同的程序不一定会产生相同的输出;输出完全取决于模型是如何训练的。对训练数据进行更改，用相同的代码重复训练过程，您将从模型中得到不同的输出预测。也许差别很细微，也许差别很大，但它们是不同的。
在这种不确定性之下，开发过程本身还存在着进一步的不确定性。很难预测一个人工智能项目需要多长时间。对传统软件来说，预测开发时间已经够困难的了，但至少我们可以根据过去的经验做出一些一般性的猜测。我们知道“进步”是什么意思。使用人工智能，你通常不知道会发生什么，直到你尝试它。花上几周甚至几个月的时间才能找到可行的方法，将模型的准确率从70%提高到74%，这种情况并不少见。很难说最大的模型改进是来自更好的神经网络设计、输入特征还是训练数据。你经常不能告诉经理模型将在下周或下个月完成;你的下一次尝试可能会成功，或者你可能会受挫好几个星期。你常常不知道某件事是否可行，直到你做了实验。
2.14.14. 技术预研 21¶
当产品目标从宏观到微观都有明确的定义后，产品经理就可以开始：技术预研。人工智能产品经理要理解技术的实现过程，这就要求产品经理在关注用户体验的同时要关注这些体验的实现方式和过程。如果不懂技术原理，产品经理可能无法提出创造性和颠覆性产品创意，同时产品经理需要给研发团队提供研发阶段的帮助也需要懂技术。
2.14.14.1. 领域技术基本现状和趋势¶
用人脸识别来举例：
计算机视觉的整体发展趋势：
从“让机器看”到“让机器看懂、理解、执行”
从看图片到看视频
从分类到识别，再到理解
最终就是 图像分割 —-> 特征提取 —-> 行为识别 的整个过程。
常见的人脸识别应用：人脸图像预处理、人脸图像检测、人脸图像采集、人脸特征提取、人脸特征识别、表情识别、3D人脸重建、人脸变形。
一般的人脸识别主要有五部分：
图像采集：使用被检测物体的重要特征显现，同时过滤掉不重要特征
人脸检测
人脸图像预处理
人脸图像特征提取
人脸匹配与识别
2.14.14.2. 领域前沿技术¶
在深度学习、传感器技术、芯片的发展的当下，深度摄像头（3D传感器）成为近来机器视觉方面的投资和创业热点。通过深度相机就可以构建人脸的三位信息，在人体跟踪，人机交互，AR等领域运用广泛。
目前，比较成熟的深度方案有：
结构光：通过发射特定图形的散斑或者点阵激光红外图案，摄像头捕捉反射回来的图案，比较散斑和原始的大小测算物体和摄像头之间的距离。多用于近距离场景。
双目视觉：通过两个摄像头的视差来获得深度信息，运算量大、实时性差。适用于手势识别。
飞行时间法3D成像：通过红外光反射回来的时间差或相位差来获得深度信息。
2.14.14.3. 常见技术逻辑¶
以人脸识别在安防中的逻辑为例。 人脸图像采集：图像体积、图像分辨率、图像外部采集环境
人脸检测：人脸检测的目的是从图像中确定人脸的位置和大小。常见的算法有：Viola-Jones、Haar+AdaBoost、CascadeCNN等，产品经理需要有一套量化标准。
检测率：存在人脸且被检测出的图像在所有人脸图像中的比例。
漏检率：存在人脸且没有被检测出来的图像在所有存在人脸的图像中的比例。
误检率：不存在人脸但是检测存在人脸的图像在所有不存在人脸图像中的比例。
产品经理需要了解行业内对产品质量的衡量标准，在产品需求阶段衡量产品需求描述，量化产品目标。项目验收中用数据量化产品质量。
图像预处理：图像预处理的目的是提高图片质量，去噪，使得图像特征表现出来。主要技术手段有：人脸图像的几何校正，光照补偿、尺寸归一化、灰度变换、去噪、边界增强、提高对比度、直方图均衡化、中值滤波以及锐化。产品经理需要了解行业中特有的数据治理技术，包括不同类型数据的治理周期、需要投入的成本、数据治理过程中的阻碍等。
人脸图像特征提取：特征提取的目的是针对数据的原始特征的缺陷，降低特征维度，提高分类器的设计和性能。人工智能产品经理需要理解不同框架的逻辑以及区别，对前沿技术保持敏感度，不断优化功能和产品体验。
人脸匹配与识别：对提取的人脸数据与数据库中的特征模板进行匹配，设定一个阈值，超过该阈值即可判定为某一个人。
人脸识别：计算两张脸的相似度。主要有身份验证等。
人脸检索：给定一张脸，找出同一张脸的图片。活体检测检索，通过眨眼等动作。主要用于签到考勤、门禁闸机、安防监控。
2.14.15. 技术可行性 9¶
技术可行性是指决策的技术和决策方案的技术不能突破组织所拥有的或有关人员所掌握的技术资源条件的边界。
做技术可行性分析时需注意全面考虑系统开发过程所涉及的所有技术问题，尽可能采用成熟技术，慎重引入先进技术，着眼于具体的开发环境和开发人员，技术可行性评价等问题。
如果是技术转产品的，可能是这样：29
对前端说：这次增加了几个页面，字段、样式和交互分别是什么样，边界条件是什么；
对后台开发说，新增产品流程是什么，逻辑框架是什么样，新增了哪些字段和接口，需要找谁对接；
对测试说，这次的测试点是什么，流程有哪些，有什么风险需要注意。
2.14.15.1. 精确定义¶
“可行”的一个重要部分是精确定义。正如杰里米·乔丹所说:“一个明确定义的问题已经解决了一半。”如果你能非常精确地说出你想要完成的事情，并把它分解成更简单的问题，你就有了一个良好的开端。Jordan有一些很好的建议:从自己动手解决问题开始。如果你想帮助客户整理他们手机上的图片，花点时间整理你的手机上的图片。与真正的客户面谈，看看他们想要什么。建立一个他们可以用真实数据尝试的原型。最重要的是，不要认为“我们想帮助客户组织图片”是一个充分的问题陈述。它不是;你必须更详细地了解你的客户是谁，他们想如何组织他们的图片，他们可能有什么样的图片，他们想如何搜索，等等。
2.14.16. 数据标记¶
看看您可以多快地为ML算法构建一个带有标记的基准数据集以及明确、狭窄定义的精度目标。数据标记的便捷性是机器学习是否具有成本效益的一个很好的代理。如果您可以在产品的正常用户活动中构建数据标记(例如，标记垃圾邮件)，那么您就有机会收集足够多的输入-输出对来训练您的模型。否则，您将为标记数据的外部服务烧钱，而且在您进行第一次演示之前的前期成本很容易成为项目中最昂贵的部分。没有大量的原始数据和标注的训练数据，解决大多数人工智能问题是不可能的。
2.14.17. “BUG”一词¶
“BUG”一词在工程师与产品经理的角度中可能也存在偏差，在工程师的角度看，它是因为代码或者逻辑出错而导致的功能性错误，因为不影响产品功能的优化，所以不是BUG。而产品经理的角度看，认为是影响用户体验的产品BUG，本质上是交互设计问题，在加载过程中需要对用户有所提示使得产品体验更好。两种角度，两种观点，而书中告诉了我们解决方法。
2.14.18. 系统设计中需要明确的问题¶
在系统设计中，至少需要明确以下问题：
该系统涉及到的模块有哪些？哪些模块是已有的，哪些模块是新增的？
每个模块的定位，或者说定义是什么？在系统中扮演什么样的角色，起到什么样的作用？旧有模块的定义是否满足我们的要求，新模块的定义是否清晰明确？
每个模块的输入输出是什么？每个模块所获得的输入是否刚好满足其能完成任务的需求，既不缺乏信息，也不存在会导致依赖的信息冗余？
模块间的上下位关系是否明确，是否与该模块的原有定位相契合？
系统整体的模块的调用顺序是什么？是否拥有合理的信息通路？是否保证了模块上下位关系的一致性？是否存在下位模块僭越上位模块进行/被进行跨层级调用的情况？
做个形象点的类比，设计系统就像拼拼图。第一个问题，就是看我们手上有哪些拼图；第二个问题，就是看拼图上的画是什么；第三个问题就是看拼图的边缘是什么样的；第四个问题，就是看哪些拼图的边缘是相互契合的；第五个问题，就是拼好后，看整幅拼图是否存在不一致错误。 18
2.14.19. 技术专利¶
2.14.20. 更多¶
9个B端产品经理需要懂的技术 - 起点学院的文章 - 知乎 https://zhuanlan.zhihu.com/p/144314827