第三章 定义人工智能产品需求
产品经理是公司产品的负责人，而产品又可以为用户解决某种特定的需求，在人工智能时代，产品依然是围绕用户需求来定义的。互联网时代的产品经理构建的是基础设施，产品经理主要关注的是入口及流量的走向。人工智能时代的产品给人类带来的是技术创新驱动下的产业升级，本质上是关注产品本身的价值。
3.1 重新定义需求分析
人工智能技术的飞跃发展为产品设计和需求定义带来了新的思路和逻辑，被总结为以下六个方面：
- 产品逻辑化繁为简，用户学习成本降低。
人工智能产品的目标之一就是降低用户的使用门槛，尽量减少用户的交互流程，降低使用难度，让产品的使用过程接近用户的自然行为。 - 从用户角度考虑投入产出比
人工智能产品由于具有更复杂的系统架构和实现逻辑，某一功能的实现往往伴随着高昂的代价，而与此匹配的功能价值在很多情况下却不与之成正比。人工智能产品的研发投入尽管很高，但产生的直接回报对于用户来说仍然非常划算，产品经理应该在所处的行业中找到效果比较直观，产品价值相对显性的场景。尤其当产品或功能还没有被用户任何，或者当产品属于一个新的市场时，最终的实现效果和价值都很难预估，产品经理应选择用户最“痛”的点或者直接和利益挂钩的点作为需求切入点。 - 算法可解释性差，产品经理需要逐渐获取用户的信任
使用到复杂算法模型的人工智能产品对于用户来说大多属于“黑盒产品”，工程师或产品经理均无法很好的解释实现的原理。人工智能产品经理首选需要通过某个具体场景中的预测和推断能力证明技术实力，进而树立领域专业形象，步步为营地争取用户的信任。尤其当公司和品牌都处于刚起步的阶段时，更忌讳大步向前，因为那样反而容易遭到用户的抛弃。 - 传感器技术的飞速进步，带来了多元化交互行为
日新月异的传感器不仅在机器人，无人驾驶领域有广泛成功的应用案例，而且可以为产品设计和定义提供更大的想象空间。产品经理应学会合理利用多种传感器设备，创造更多交互方式来满足用户的需求。 - 产品的需求并不一定来源于确定的因果关系
在过去，产品经理根据用户明确的需求设计产品，产品研发出来的结果会和原型设计保持一致。但是人工智能产品需要完全不同的思维，产品经理的需求未必是确定的页面，可能是一堆规则和策略。产品经理不再花大量的时间和资源来寻找确定的因果关系，而是通过大量的数据挖掘手段探索出设计与需求的相关性，并用数据指导产品设计。 - 产品经理在开始需求定义前应充分了解目前技术水平和资源的局限性，避免定义一些研发很难实现的需求
由于一个完整的人工智能产品体系的搭建通常需要考虑基础设施、数据采集、数据处理、推理和决策等等若干环节，产品最终的实现效果取决于上面所有因素的协同。另外，在不同场景中对算法模型的准确率、召回率的要求大相径庭，需要在进行需求设计时区别规定不同场景对算法的衡量标准。
3.1.1 从围观、宏观两个角度定义功能性需求
产品功能性需求描述了某一具体的行为或功能，描述的内容往往与使用的技术无关。主要描述研发人员需要实现的功能，以便用户能够完成自己的任务，进而满足业务需求。产品经理可以从微观和宏光两个角度展开功能性需求的定义。
- 宏观：产品经理应首先对公司的整体产品架构有清晰的认识，在这个框架体系内，评估具体场景下的业务需求及功能使用场景，是否符合公司的整体战略规划，以及当功能性需求被满足后是否可以为整个产品架构甚至公司带来益处。这样的思维模式有助于在需求定义之前将一些不满足公司整体战略目标的候选功能需求筛掉，并给出定义需求的优先级。同时，有了这样的“上帝视角”也有助于得到老板、投资人的认可，最终让公司从上至下达成一致。
- 微观：产品经理一旦从宏观角度筛选出了优先级较高的功能，就可以从微观角度定义具体的功能描述了。产品经理应尽量给出明确的业务背景和业务目标，并且可以将目标进行量化。产品经理需要和算法工程师一起在功能性需求定义阶段明确功能哪些指标可以被量化，以及算法依赖什么样的数据，并提供明确的验证方法。
3.1.2 越重要，越容易被忽视：定义非功能性需求
非功能性需求通常被描述为一款产品的“质量属性‘’、”质量目标“或”非行为需求“‘，通常被用来评估一个系统或软件的运行、服务情况。产品非功能需求定义在很大程度上影响产品的功能性需求定义，是支撑产品功能性需求的重要因素。同时，非功能性需求是成功的人工智能软件/硬件架构必须关注的关键要素。非功能性需求用来规范和约束一款产品在设计和实施过程中的条件，通常是架构设计师需要关注的部分，而往往是产品经理或需求人员所不擅长的方面，正因为如此，架构设计师应尽早参与到需求分析中，通过分析需求的技术可行性，尽早考虑非功能需求，根据这些需求进行架构设计。针对人工智能产品，下面列举了5种非功能需求，每个产品的非功能需求都与行业背景，用户特征有关，因此产品之间不存在相同的非功能性需求，需要产品经理有针对性地进行这方面的设计。
- 安全性
可得性：产品的数据和功能是否可以按照明确的权限系统控制访问权限，并且有效地拒绝未授权的访问。另外，机器人在未来还需要通过识别人类的情绪和生理状况判断指令的合理性。
私密性：产品存储的数据收到保护，不会被没有授权的人得到。 - 可用性
可用性是从用户角度看产品质量，及用户能否用产品完成他的任务，效率如何，主观感受怎样。产品的可用性需求需要对用户有深入的了解，了解他们的使用习惯，对产品的期望，他们需要用产品完成的最终目标，以及他们使用产品时的真实场景等。
易用性：通常包含产品被理解、学习、使用和吸引用户的能力。产品的易用性需要产品经理具备换位思考的能力，真正站在用户角度设计用户能理解、好用和有吸引力的产品。另外，产品的易用性是产品化过程中不可少的因素，易用性较强的产品使产品可以快速被用户理解，接受并感受其价值。
一致性：产品经理通常从流程、页面，到具体的按钮和操作都要有强烈的一致性。具备一致性的产品不仅会让用户获得比较自然的使用体验，而且更加容易建立用户的使用习惯。通常一致性原则包含但不限于三个方面：设计目标一致性、外观元素一致性、交互行为一致性。
外观需求：需求中是否描述了产品外观风格、特征及意图。人工智能产品通常融合了颠覆性的创新技术手段，观感需求对于产品品牌的建立和识别非常重要。
- 可靠性
产品可靠性是产品在规定的条件下和规定的时间区间内完成规定功能的能力。通常人工智能产品的可靠性可以从条件、时间和功能三个方面展开。条件是指直接与产品运行相关的，系统的状态和输入条件，或统称为产品运行时的外部输入条件；时间是指软件的实际运行时段；功能是指为用户提供给定的服务时，产品所必须具备的功能。常见的可靠性包含如下内容：
出错频率：是否已经明确了产品在使用过程中多长时间内的故障率的上限是多少，是否明确了故障的严重程度。
自我恢复速度：一旦产品出现系统奔溃的现象，是否要在特定的时间内恢复正常。
人工智能产品经理应特别留意积累工程实践中产品的运行风险，并有针对地提出可以被量化的可靠性需求，用明确的需求指引架构师和测试团队制定专门的工作流程和目标。
- 性能
一款产品的性能通常是在需求设计阶段就应该明确的一项指标，其很重要但通常被忽视，若在性能报告中发现某些指标不满足需求时，而那时候系统的架构设计已经无法大范围的变更了，因此需要产品经理在需求设计阶段将产品的性能指标定义清楚。产品针对性能需求的检查通常会包含但不限于以下几个方面。
相应时间：是指系统对请求作出相应的时间。对于系统响应时间，有一个普遍的标准——2/5/10秒原则。在2秒内响应客户，被认为是“非常有吸引力”的用户体验，在5秒内响应客户，被认为是“还算不错”的用户体验，在10秒内响应客户，被认为是“系统很慢但也可以接受”的用户体验。
吞吐量：是指系统在单位时间内处理请求的数量，是产品性能承载能力的关键衡量指标之一。吞吐量在不同情况下用不同的指标单位进行衡量和描述。产品经理应明确提出产品在不同场景中的吞吐量需求。
并发用户数：并发用户数是指在同一时间段内访问系统的用户数。需要注意的是，用户在使用软件的不同模式或场景下对服务器产生的压力是完全不同的。
资源利用率：一款软件产品的性能通常受到服务器资源利用率的影响，软件的需求中如果能明确约束资源利用率的上限，在配套硬件设备的时候就能有意识的进行选择，最终可以应对软件性能瓶颈的意外来临。通常在描述的时候，要将预期的最高并发量同时进行声明。
以上有关产品性能的需求描述对产品经理提出了新的挑战，一方面产品经理需要了解不同条件中的产品可能受到承载的压力。另一方面，在资源利用率方面需要有粗略的预估，这需要产品经理洞察用户在使用不同功能时，以及进行交互操作时的习惯（方式、时间、时常等），只有了解用户的使用习惯，才可能预判出系统可能达到资源瓶颈的时机。这些认知不一定要求精确的量化，但至少需要对各项性能指标有原理或理论上的理解。
- 可支持性
可扩展性：即变更需求的时候是否影响非常大甚至需要推翻重来。产品经理和架构师需要针对产品的未来规划提前沟通，即在设计产品的时候保持前瞻性思维。要考虑未来的产品功能扩展的大致方向，并提前预判出某些未来一定会上线，但是不在当前迭代中的功能。对产品的前瞻性会极大地影响产品前期架构设计，并为未来进行功能扩展做好铺垫，从而降低推倒重来的可能性。
可维护性：指产品可被修改的能力。可维护性可能直接影响产品在整个研发周期中的研发投入量。在人工智能产品设计中，要站在整体产品架构层面全面考虑可维护性。以某个智能服务机器人产品为例，产品的可维护性至少要考虑5个方面：1、用户行为数据、外部业务系统数据的可维护性。2、数据/计算平台的可维护性。3、预测模型的可维护性。4、包含规则引擎、数据拉取等基础服务的可维护性。5、推送消息的可维护性。
可安装性：软件的可安装性，代表着在不同环境下部署安装产品所需要付出的代价。
无论功能性需求还是非功能性需求，产品经理对需求的描述应尽量避免掺杂技术解决方案。掺杂了解决方案的需求往往禁锢了研发人员和设计人员的思路。
3.2 量化需求分析
3.2.1 为什么要量化需求分析
人工智能产品的本质是通过概率思维来解决问题，由于基于深度学习技术的研发过程中，算法的可解释性差，产品的展现形式好似“黑盒”，因此产品经理必须将需求进行量化表达，这样才便于对工作成果进行衡量。一般情况下，产品经理需要在迭代开始之前就提出量化标准，算法团队根据被量化后的业务目标进行技术可行性预研，得出调研结论后再和产品经理讨论。
工程实践中可能出现多种可能性，产品经理需要总结类似的量化评估经验，通过和研发团队沟通，了解团队技术积累现状以及算法能力的边界，这样才能保证在下一次的需求描述中将量化变得更靠谱，尽量减少需求变更和申请额外资源的情况。量化需求不仅在前期技术预研和项目评估各方面有好处，而且对产品研发、测试及上线后对产品功能的表现经过可以进行精准的验证。当一个功能被设计出来后，是否有合理的量化标准是对产品经理的一种需求，当需求被合理地量化出来，研发人员可以根据量化的标准去实现产品，测试人员可以通过明确的测试目标进行算法能力的测试。团队都会养成用数据说话的习惯，功能设计得好不好，合理与否，需要用数据说话，而不是任何人拍脑袋想出来的。
3.2.2 怎么量化需求
量化需求显然对产品经理提出了更高的要求，因为产品经理不仅要熟悉产品使用场景，还需要了解技术的边界，对产品进行量化定义。下面以机器学习的产品举例，列出几个量化需求的关键步骤：
- 明确需求符合产品愿景
要明确产品的业务需求，业务需要包括：业务机会、业务目标、成功标准以及产品愿景。功能需求和非功能性需求必须与业务需求建立的背景和目标达成一致，任何无助于业务需求目标达成的需求均不宜列入研发计划中。在项目进行中增加任何新的需求，都需要对照业务需求进行检查，保证产品不至于偏离轨道。
- 找准需求的场景
确定了产品的宏观和微观目标，产品经理需要分析每个目标对应的使用场景。由于目前人工智能的科研及应用都可以被称为“弱人工智能”，即机器不具备意识、自我创新思维，而且单个产品只能在某一个特定的具体任务上表现出应用价值，因此，如果不能将产品愿景拆分成具体场景目标，是无法对需求进行量化的。
- 定义场景中的可量化标准
确定了具体的的微观目标，并从产品的微观目标中拆分出不同的场景目标，下一步就该定义可量化的标准了。即使在同一个领域中，不同场景对算法的评估标准都完全不同。以眼科疾病筛查为例，定义场景中需求有如下步骤
- 考虑内部因素
- 考虑外部因素
- 参考同行业表现
- 输出对模型预测精度的合理期望
- 根据具体场景定义算法特殊指标
量化需求不意味这当前的人工智能技术和产品能完全替代人的工作和能力，在绝大多数场景中其知识起到辅助作用。产品经理需要深入了解自己所在行业的用户特点，并对产品进行合理的包装，产品追求的不是完美，而是商业价值和变现能力，用户的认可才是评判标准，如果一味追求模型精度而忽略了成本、市场实际、竞争格局，产品一样会失败。产品经理需要能站在公司角度考虑产品的ROI。