我们要教会AI决策，我们就要必须弄清楚人是怎样做决策的。我们应当以实现业务价值为最终目标，专注分析业务场景中的问题。在项目早期，收集实际场景中的业务案例显得尤为重要。
我们可以将收集的案例整理成一个个表格或者卡片，包含要素有：场景概述、业务目标、业务流程、关键决策点、业务痛点、过往案例：
1. 场景概述：用最简洁的一句话说明该场景中的业务要点“谁-做什么-为什么做”，这类似于敏捷开发中的“用户故事”；
2. 业务目标：用于明确业务要达成的最终结果，并为自动决策获得一个可衡量标准。我们可以寻找业务中一些量化的KPI，这不仅是对人的考核也是对AI的考核；
3. 主要业务流程：主要是为了弄清楚当前的系统运行情况：在原有的人工的业务流程是怎么样的？现有的业务流程中有哪些优点或者缺点？4. 关键决策点：找到关键逻辑决策点，在流程中人是如何做决策的？判断的效率怎么样？判断规则是什么？要输出怎样的结果？5. 业务痛点：找到产品能够发挥价值的地方，有哪些痛点？有哪些抱怨？6. 过往的成功与失败的案例：主要是为了弄清楚一些真实情况。能否举出一个或者多个成功的案例？能否举出一个或者多个失败的案例？失败的原因是什么？会怎么样处理？在我接触过的项目中，一些业务方对表格中的问题会表现得一脸懵逼，原因很简单，自己都没有弄清楚自己业务的SOP（标准作业程序），就期望AI来帮他们解决问题。这种情况，还是需要由人类先摸索出有价值的SOP，因为人做不好的，AI肯定也做不好。如下图，CRM客户挖掘的业务场景案例：每天，客服人员需要拨打大量的电话，找到对产品感兴趣的客户，以便于销售人员跟进。对于客服人员来说，工作量大而且重复，容易让人烦躁。通过这样的收集和整理，让我们对要解决的问题和场景有一个直观的感知，但随着调查的深入我们还可能会发现新的问题。为了不遗漏有价值的信息，这个阶段我们收集的案例，应该有更多发散性。
2、绘制决策流程图通过业务案例的收集，我们可以梳理出一个业务流程图，我们可以使用“UML活动图”来绘制，并且我们还要重点标识出决策的判断点。如下图：如图所示，起点是挑选客户资料，结束点是标记出有意愿的A类的客户。为了更加明确，我们将主流程（Happy path）放到主轴上面，代表决策的菱形节点放在两边，我们可以一目了然，看到那些通向“幸福Happy”的关键决策。主流程 Happypath
《聊天机器人：对话式体验产品设计》P.219先不考虑任何实现手段，我们需要先弄清楚，每一个决策点的输入、输出和规则是什么。我们可将这些决策点整理成一份“决策用例清单”，然后再综合考虑是否合适AI自动化决策：用例（Use Case）是UML中术语，一个用例代表一个完整的系统功能单元，但不考虑该系统的内部实现细节。另外，我们还可以将此清单整理成UML用例图，这个系统参与者有三个：客服，客户，AI。
3、筛选可行性用例根据上面的用例，AI该如何与人类一起工作呢？并不是所有“决策”都是适合机器做，机器做决策的特点是效率高速度快，但应变性弱。人类做决策的特点是灵活性高，但是容易产生疏忽和遗漏等问题。我们可以用场景决策矩阵判断，如下图：按照场景和决策两个维度进行拆分，分成四个象限：常规性场景+信息性决策：对细节要求不高，学习案例多，AI学习效果较好，AI只提供信息建议，辅助人类决策，出错的风险很低，特别适合AI来做；细腻性场景+信息性决策：对细节要求极高，学习案例少，AI做出正确判断有难度，AI提供信息建议，由人类为主导AI辅助做决策，出错风险低；常规性场景+行动性决策：对细节要求不高，学习案例多，AI学习效果较好，AI代替人类做行动决策，出错有一定风险性，适合人类为主导AI做辅助；细腻性场景+行动性决策：对细节要求极高，学习案例少，AI做出正确判断有难度，让AI代替人类做行动决策有很大风险，建议人来做；我们可以将上面的决策用例做一个基础的判定：排布在场景决策矩阵如下：通过这样的分类方法，我们能很清楚的知道机器和人类应该怎样分工，案例中大部分决策用例都可以交给机器，但“询问进一步沟通的意图”是很关键一步，如果全权交给机器，效果将大打折扣。这样，我们就有了一张人与AI的分工图：这时我们有了两条思路： 第一条思路，如果AI效果好的话，那么全权负责整条链路，让人在最后一步把关，这样的好处是效率高；第二条思路，AI作为一个辅助工具，帮助客服自动化筛选**，做好通话情况记录和打分，一定程度有效提升客服效率，而且结果也可控。到底哪个方案好呢？ 一方面需要根据实际的业务需求判断，例如，针对高端人群的产品，获取客资成本高，对于这些高端客户来说冷冰冰的机器人电话显得没有诚意，但是普通话不标准的销售人员也可能让人觉得是山寨推销。另外一方面，我们需要将需求对应到不同的技术模块上，因为算法产品有一定不确定性，贸然使用不成熟的技术，也承担着巨大风险。作为产品经理，我们应积极与数据科学家和工程师沟通，或许他们也有更好的建议，对于产品经理来说，沟通永远都是第一要务。4、制定AI产品路线图AI和人一样，需要一个成长过程，这个过程中需要不断的积累数据和调整算法策略。一个好的AI产品路线图，需要给我们的产品规划一个学徒期，从简单的决策开始，再逐渐演变为更复杂的决策。
我们可以根据前面的算法模块的拆解，挑选出哪些需要优先做的模块，我们可以从影响、努力、风险三个维度考虑。我们优先选性价比高和风险较低的模块，如果是一些通用性的算法模块也可以考虑使用大厂提供的服务。这样保证产品功能完整性的同时，也降低了不确定性带来的问题。
AI产品相比传统产品更需要大量数据，我们需要提前做好数据埋点和反馈机制，确保产品上线后，能够收集足够的数据，充分了解各种决策及其完整上下文。这样便于算法工程师，持续的优化模型和算法。
另外，为了更早的发现真实场景中的问题，我们需要让用户尽早地使用我们的产品，但是由于产品还在学徒期，功能不完善、体验不确定，并不适宜大规模推广。我们可以考虑通过邀请制，让愿意尝鲜的用户先体验，这些用户往往比普通用户包容性更强也更加积极，愿意提更多的意见和想法。
基于上面的几点考虑，我将路线图中的需求分成应用层需求和算法层需求两类。
应用层主要是指直接与用户打交道的需求，这部分是偏传统的软件开发内容。细分下去包含，决定产品使用体验的功能性需求；和运营节奏息息相关的增长性需求，如邀请、裂变、积分等；还有用户看不到的但能让产品和服务变得更好的支持性需求，如产品后台、数据统计平台等。
算法层是指与自动化决策息息相关的需求。应用层与算法层通过算法服务提供API打交道，这些API需要根据应用层场景进行调整和优化。但算法只有API是不够的，还需要一些支持性的模块，例如网络爬虫和一些基础算法模型。
在产品早期，我们需要为用户搭建好基础的产品功能，于此同时我们也需要做好算法层的技术建设，然后再逐步引入种子用户。最终整理出我们的产品路线，让我们的AI产品能够从学徒期慢慢走向成熟。
三、结语在这两年的AI产品实践中，我在产品经理、设计师、工程师之间来回切换角色，不仅仅是为了打造心中所想的产品，也是为了探寻心中的一个答案：“AI时代，产品经理应该如何做产品”。
过去一年，可谓一路狂奔，将原本写产品需求的时间放到了写代码上，不知不觉中，我的github瓦片图也快要被绿色占满，但值得庆幸的是，通过亲手打造的产品，团队也成功拿到了融资。
AI产品其实并不神奇，任何产品的商业价值都在于其对人类的价值。只是不同的技术方案需要考虑的侧重点会有所不同。对于产品经理来说，科技在进步，思维方式需要迭代更新，但也不能全部舍弃，用“进化”这个词来形容我们AI时代的产品经理可能更为贴切。
如果您喜欢我的文章请继续关注我，我将继续更新我在AI产品领域的一些总结和思考。也欢迎一些志同道合的小伙伴，一起参与Mixlab的活动，一同进化。
