近日，脑机接口公司 Neuralink 宣布，其植入式脑机接口设备首次人体临床研究已被准许启动。遥想当年，我们还嘲讽罗老师「动嘴做 PPT」，谁曾想不久后我们可能连嘴都不用动。

脑机接口何时会引爆人机交互革命尚未可知，但是 ChatGPT 已然掀起了大家对「软件交互革命」的热烈讨论；甚至有些观点认为，ChatGPT 强大的自然语言处理能力会颠覆现有的图形交互，带来更智能、体验更好的软件系统。

作为时刻冲在人工智能吃瓜第一线的 LigaAI，我们也了解了很多朋友对这件事情的看法。大部分人认为，对话式交互是目前综合能力更好、更便捷的交互方式，也很有可能成为未来软件交互的主流。

但是，当我们分别和几位 UX 设计师朋友聊起此事，他们却不约而同地提出了反对意见；甚至口出暴论「现在的对话式交互太智障了」。

「你觉得 ChatGPT 一类的 AI 工具对产品交互设计有啥影响吗？」

「没啥影响……甚至在看到 Mid Journey 魔咒后，还有一种倒退回命令行时代的感觉。」

专业的 UX 设计师为什么「唱衰」对话式交互？被黄仁勋称为「AI 的 iPhone 时刻」的 ChatGPT 在 B 端场景里可能存在哪些机会或缺陷？当下这波 AGI 浪潮会给 To B 产品带来多大的影响？

我们和前华为、腾讯留英设计师、用户体验专家、公众号「体验进阶」主理人 ZoeYZ 聊了很多。

01 ChatGPT = AI + 对话式交互

LigaAI：作为 UX 设计师，你怎么看待这波由 ChatGPT 引发的全行业大震动？

ZoeYZ：ChatGPT 可以拆成 AI 和对话式交互两个部分来看。它的出现肯定是一个很大的变革，这种变革性主要来自于 AI 而不是对话式交互。对话式交互并不是一个新鲜的东西，Siri、智能语音助手、机器人客服都是相当成熟的产品，但过去它们并没有带来很大的影响。

在我看来，ChatGPT 之所以爆火，是因为它让很多人第一次真正感受到了 AI 对自己的价值。尽管 AI 已经发展了很多年，也早就被字节跳动、百度等企业应用在各种产品中，但普通用户隐约知道它的存在，却不能清晰感知其价值；

而 ChatGPT 展示出的生成式 AI 或者 AGI 的能力，让 AI 成为了一个平价亲民、易感知的东西——这是它能够引起轩然大波的原因。

LigaAI：目前 ChatGPT 的能力集中体现在内容生成方面，比如文字和图片的生成；也有人会用它完成语义的分析和查询。对于 LigaAI 这样面向开发者的 SaaS 工具，它可能会带来怎样的机会？

ZoeYZ：ToB SaaS 产品之前在信息生成方面做的没那么多。LigaAI 作为一个项目协作平台，可以尝试的方向包括无需用户配置直接生成周报/工作报告，或者提供一些产品文档方面的信息组织和校验能力等等。

LigaAI：前者会有助于产品的冷启动吗？用户无需学习或适应产品，直接输出自己的诉求就能快速使用功能，例如我跟 AI 说「创建一个 Tech Lead 适用的仪表盘」，然后它会为我生成合适的面板。

ZoeYZ：「直接告诉 AI 我想要什么」，这其实是一个非常大的问题。现在的对话式交互最大的问题就是它要让用户主动说，但是用户在表达时，则会想「AI 究竟能不能够做到」。

一方面，用户很可能不知道该怎样让 AI 工作（难以找到准确的 prompt）；另一方面，多数用户对 AI 的能力边界是没有感知的。他不知道产品能做什么、不能做什么、能做到什么程度。哪怕 ChatGPT 现在这么火爆，大家也还处在探索阶段；面对不确定的输出结果，我们始终需要不断地试错、调优，才能得到好的内容。

而且很多时候，我们只有在得到 ChatGPT 的答案后，才会发现遗漏了一些关键信息，然后自己再加进去重新生成。这也是对话式交互不太擅长的，它没办法像真正的智能助手一样追问你、提醒你，而是只能根据你的内容机械地给出回应。

尽管对话式交互看上去很理想，但在实际使用中存在很多问题。一旦我们将一个大模型真正落地到一款 To B 工具内，上述问题会更清晰地展现出来。

02 对话式交互不是万能的

LigaAI：在 B 端产品的使用场景里，对话式交互还有哪些缺点或者优点？

ZoeYZ：对话式交互本质是一种一维交互，好比你看文字、看图表还是看动画。信息量不大或者选择比较少的情况，用对话式交互处理会比较轻松。

它的缺点也很明显：如果没有一个类似图表的可视化载体，用户想要了解到产品的整体布局或者全貌，就需要将所有东西都对话一遍。

举个例子，你去奶茶店点奶茶，对话式交互相当于你同店员来回的交流：

你：“你好，要一杯波霸奶茶。”

店员：“请问是大杯还是中杯？”

你：“大杯。” 店员：“糖度需要调整吗？”

你：“少甜吧。” 店员：“那冰度正常吗？”

你：“嗯，标准冰就可以。”

店员：“还需要加其他小料吗？”

……

你发现在处理大量信息的时候，自己可能更愿意看图表。但对于那些特别简单的场景，比如在飞机上点饮品——只有可乐、果汁、咖啡、牛奶这几个选项，也没有其他糖度、冰度、小料等等复杂配置，那直接告诉空乘「我想要什么」就是最快的。

所以对话式交互并不像很多人想得那么酷炫，那么方便。只是之前 B 端产品更多地把对话式交互抛在一边，而现在 ChatGPT 的能力涌现又将它拉回到大家的视野之中。

LigaAI：对话式交互复兴的本质是自然语言处理（NLP）能力的进步。现在蛮多人会畅想一个可以直接用母语支配产品的交互新时代。

在你看来，现在这个由图形界面主导的产品世界可能被对话式交互或者自然语言交互颠覆吗？

ZoeYZ：我觉得语言是一门很难的学问。如果 AI 能把自然语言处理得很好，那肯定会有很大的影响，但现在哪怕是 ChatGPT 也没有能够把自然语言处理得很好。网上也有很多的评价说它生成的内容缺乏重点、全是车轱辘话，让人很抓狂。

之前为了避免这种情况，我们会发明各种各样支持自定义的模板和图表，自然语言也可以被模板化，只是相对会更难一些。但我认为：未来的优秀 B 端产品不该过度依赖自然语言交互这种方式，AI 能力也不一定非要通过对话式交互来体现。

对话式交互不是万能的。如何组织信息让用户一眼看懂？不同形式的内容在展示时应该遵循哪些标准？这些都要具体情况具体分析。

LigaAI：可以举几个例子吗？比方说，哪些情况采用自然语言交互会更好？哪些情况应该用其他的数据呈现方式？

ZoeYZ：对话式交互可能更适用于信息足够简短的场景。因为不管是做 PPT 还是做界面设计，凡是要写字的地方，我们都要求它一定要简短，要控制在两到三行以内。

B 端产品需要培养一些内容判断的能力，这也是现在很多产品所欠缺的。拿生成周报举例子，理想的情况是产品能够按照给定的标准，结合实际情况自动判断应该应用文字还是图表，然后智能整合并配比信息，让数据呈现最好的效果。

如果可以实现这个效果，那将会带来很大的价值，但现在的工具在信息可用性、可读性方面其实没有兼顾得很好。

LigaAI：你前面讲到，B 端产品很喜欢用模板。这算不算是一种比自然语言交互和图形界面交互都要更简单、更快速的交互方式？因为不管是点击，还是对话，都不会比套模板，改改配置来得更快。

ZoeYZ：是的。我甚至觉得在 AI 落地的早期，B 端产品会依赖模板和经验分析更多一些。这里跟 To C 的场景不太一样，C 端产品面向的用户种类和数量非常庞大，很难依靠模板完成分析，所以它们在 AI 大数据分析的赛道上切换得特别快。

B 端产品面向的场景和用户会更加明确，几乎所有企业服务商都会提供一套基于行业理解的解决方案，而这正是目前 AI 所缺乏的垂直领域的经验。AI 的能力优势在于它能够快速分析大量信息，而 B 端产品很可能会在模板和经验的基础上，利用 AI 增加助力。

03 AI 提供的 B 端产品设计新思路

LigaAI：讲到 AI 助力，你觉得当下 AGI 或者 AIGC 的能力可能会给 B 端产品带来哪些核心改变？

ZoeYZ：它很可能会改变 To B 做产品的思路。以前我们总在想「产品如何辅助员工」，但现在刻薄一点说，我们可以考虑「产品如何替代员工」。比如写文档，前者会给员工提供更精准的素材，而后者可以直接帮他完成部分文档工作。

另外，在能力范围之外，还有一种新的产品形态上的思路：不要把产品当做工具或者机器。B 端产品完全可以利用 AI 的能力，用更加有创意、更加意想不到的方式赋能客户，解决他们更高维度的企业问题。

就像《钢铁侠》里的 J.A.R.V.I.S 一样，它可以是有智商、有情商、全能的智能助理，也可以是垂直领域里经验丰富的真人助手。

LigaAI：在具体的使用场景里，类真人的智能助理是怎么工作的？

ZoeYZ：真人顾问在给企业提供服务或者建议时，首先会观察组织的架构、成员情况、工作流程，了解组织的工作方式，然后发现问题，分析问题，最后解决问题。产品定位往真人助理的方向上靠拢意味着，它能够像真人一样结合实际情况，提前预测客户的需求并提供帮助。

以 LigaAI 为例。客户在系统里规划了很多工作，但是我们基于对他的了解，率先判断出他当前的规划存在问题，甚至可能导致目标无法达成。于是，我们主动向他提供了更好的规划建议，或者任务拆分的指导；进阶一点，还可以结合已知的工作量和优先级，直接帮他把任务规划的框架搭建好，任务拆分和指派也一并到位。

我觉得没有人天生就是合格又成熟的管理者，特别在开发者圈子里，大家都是从管理小白逐步成长蜕变成管理大佬的。过去，这个过程更多依赖自己的摸索、学习和经验总结，但是现在结合 AGI 的能力，产品可以告诉我「应该做什么」以及「如何更好地工作」。换句话说，AI 可以帮助企业培养技术管理者。

LigaAI：这个观点特别好，而且跟 LigaAI 的想法不谋而合。我们自己在回答「LigaAI 今后该往哪走」时，也是希望能够通过 AI，帮助新晋的技术管理者更好地实现个人成长。

从负责三五个人的技术组长，到领军百千的技术总监，再到独当一面的 CTO，我们希望帮助他们和企业识别数据反映的问题和瓶颈、理解数据分析和决策背后的方法，并在尽可能早期的阶段，将这套方法论应用到企业中，进而促进整个组织的变革，实现更快、更好地工作。

这可能是 AI 和各种其他能力综合在一起的结果。但不管是基于规则的 AI，还是生成式 AI，我们始终要解答——如何更快地沉淀数据、分析数据，并为企业提供可以推进决策的建议——它会敦促我们完成产品能力的变更。

ZoeYZ：是的。B 端产品最终都应该明确「要为用户提供什么价值」。不管是成长指导，还是决策辅助，又或者其他，具体的实现形式可以很灵活，但最终产品都要以交互的形式展示给用户。

所以，如果产品能力出现了巨大的变革，那么交互的革命自然也就来了。

彩蛋：为什么把 AI 和交互分开聊？

LigaAI：我们今天一上来就把 ChatGPT 拆成了 AI 能力和对话式交互两部分在聊。但现在很多应用了 AIGC 或者 GPT 能力的产品，它们几乎都是对话式的。好像现在做 AI，如果不做自然语言交互或者不是对话式的，就完全 Out 了。

ZoeYZ：对人类来说，语言交互确实是最直白、最简单的方式，所以在创造新产品时，我们可能第一反应就是要做成对话式交互的，因为它最简单。

就像当初计算机系统也被命令行界面的 DOS 统治了很多年，但最后还是慢慢地演变成了现在的图形界面。AI 的发展很有可能也是这条老路。

LigaAI：确实是的。回顾之前的几次交互形态变革，从 CLI 到 GUI、从 PC 端到移动端、从键盘交互到触控交互，我们一直在见证更好的交互方式伴随技术成熟出现后，逐步替代旧主流，引领时代变革。

或许接下来我们也会在 AI 的身上看到人类逐步将 AI 能力应用得更好的过程。但是，最适合的人机交互范式是怎样的？这远没有到可以下定论的时候。

ZoeYZ：对。AI 的发展肯定会超乎我们的想象，很有可能以后都没有人会再提 AI，就像大家现在不提 DOS 一样。未来 B 端产品的 AI 能力很可能就像水煤电一样平常，每个功能的基础配置就是 AI，任何表单起码要支持 AI 自动填写、智能分析、一键查询等等才行。

甚至以后的产品交互起点就是对话式交互，当然还会有其他各种各样的交互形式分别适配不同的场景。这些都可能变成产品的基础能力。

LigaAI：没准哪天大家都拥有脑机接口了。

以上就是本期 #Liga妙谈 的全部内容。如果你对 AIGC 和 GPT 的能力边界以及场景落地感兴趣，也欢迎阅读以下内容：

AIGC火了，人类又得到了什么？

对话 ChatGPT：现象级 AI 应用，将如何阐释「研发效能管理」？

人类 vs AI：玩梗大作战，看看谁是最后的赢家？

LigaAI 将持续分享深度观点、前沿技术动态和研发管理提效等内容干货，请持续关注我们。欢迎点击「LigaAI-智能研发协作平台」申请试用我们的产品，一起做大变强！

你很难找到一个组织，可以让你按照最初的设想构建产品。通常，你需要做出一些妥协（有时甚至是很大的让步）来适应组织并维持自己的收入。

你会发现有一些人总在妥协，而他们的特点也非常明显。一种是灭火达人。 产品着火了，利益相关者上火了，产品经理也火烧屁股了。他们每天被战火纷争的会议塞满，却完全没有交付价值，只是被推着不停修复 Bug 并匆忙上线。

另一种是产品交付师。 他们的主要工作是交付，而不是思考。他们与完美无缺的待办列表和精美的用户故事一起工作，一个接一个地发布功能；没有价值评估，也不收集反馈，只是不断地发布、发布、发布……

不要变成他们，他们已经被抨击得够多了；你应该努力尝试摆脱它们。这两种是很容易识别的错误类型，你都不需要阅读其他文章来了解它们。今天，我想说明一些不那么容易识别的错误示范——它们看起来很像产品管理，但其实不是。

你通常可以在产品成熟度较高的公司中发现它们，而且很少有人愿意指出或批评这些问题，因为这会触动一些人的神经。但，管它呢，我爱干这种事。

第一类：产品学者 Product Scholar

这是一个经典类型，可以在 Medium 或 LinkedIn 上找到（很多）。产品学者总是讲很多，但交付得很少。 讲学是一件相当容易的事情，但他们似乎忘了「知道怎么做」并不等同于「能够做得到」。

产品学者们经常会在会议上丢出知识炸弹，比如「我们不能依赖假设」或「我们必须确保向用户交付价值」。之后，他们挥一挥衣袖，消失在迷雾中，而工程师和设计师则被留下做真正的决策。

他们大力提倡「持续发现」和「价值主张设计」，却没有可以展示的 KPI；只提供理论和指导，然后让小组里的 Tech Lead 或设计师为其工作。产品学者是产品经理里的「嘴强王者」，在业务上的表现却相当糟糕。

第二类：探索经理 Discovery Manager

与产品学者相比，探索经理说得并不多。事实上，他们非常害羞——他们会将话语权范围限制在创造假设上，从不承诺解决方案。这种类型的行为红线是，一个人应该与问题作伴而不是与解决方案。谈论「要交付什么」似乎成了他们的禁忌。

他们对任何事情都没有信心，从不承诺；他们避免大规模交付，因为他们没有承担风险的能力。 这些专业人士让业务内非技术垂直部门的同事不喜欢「探索」这个词。

探索经理将拥有一个美丽的机会解决方案树，但他们永远不会把它交付出去。他们只实现那些被告知要做的事情，或者到处灭火。

第三类：数字经理 Data Manager

不要将它和数据产品经理弄混，后者很好。数字经理是盲目追随数据的产品经理；如果没有数据，他们就无法完成工作。

如果说「灭火达人」和「产品交付师」是一种极端，那么「数字经理」和「探索经理」则是另一种极端。任何没有数据支持的反馈都该阅后即焚，不管它是客户要求的、老板指定的，还是从知识中获取得到的。

数字经理没有恶意，但他们常常因为缺乏灵活性，而对存在于数字外的机会和问题视而不见。数据驱动是指尽可能地诉诸数据，而不是完全依赖数据。

许多我们今天认为很棒的产品都不是建立在大样本 A/B 测试上的，它们也没有庞大的用户群组可以用于行为跟踪；而数字经理似乎忽视了这一事实。

第四类：产品巨星 Product Superstar

这是一个复杂的类型。理论上，产品巨星做的一切都是对的，问题出在他们的目标/出发点。

产品巨星对向用户提供价值，为业务负责并不感兴趣，他们关心的是「哪些交付能让他们成为焦点」。 有时候这两件事是一致的，但有时候不是。

产品巨星有耀眼的 KPI 可以展示，通常是基于技术细节的对象。尽管企业有负面新闻但 NPS 异常高，或者一个产品不为人知却增长惊人，都可能是由产品巨星掌控的。

不要误会，在工作中寻找发光的机会是可以的。产品巨星的问题在于，他们将这种雄心壮志视为优先级矩阵的一部分。并非所有发光的机会都是充满吸引力的，而巨星们永远不会去碰这些。

第五类：产品狂热者 Product Zealot

产品狂热者也是产品经理；事实上，还是很好的产品经理。他们的过错不是提供了预期外的表现，而是不能接受——如我开头所指出的——在工作中妥协和让步。

在科技行业大裁员之前，他们处于相当安全的位置。托 Cagan、Perry、Ries 和 Torres 的福，非技术部门不得不忍受他们以「用户价值」和「增长」为由，否决大部分功能和需求。

现在，世界变了，那些曾经遭受压迫的人重新拿到了话语权。创新和增长失去了在谈判桌上的位置，而那些真正能够带来稳定的、可靠的收入的人成为了交易者。

产品狂热者常常忽略一件事情：产品团队创造的所有增长和价值，只有在用户愿意为它买单时才有意义。 有时候你不得不因为大客户的一句话，就去灭火或者交付一个未完成的功能——没关系的！亚马逊被认为是最好的产品领导组织之一，哪怕是他们，也会在老板的命令下推出失败的产品——Fire Phone。

写在最后

在这些原型中看到其他人很容易，但你自己能「对号入座」吗？我很确定，你很可能是其中一个或多个类型的结合体（就像我自己一样）。

不需要遮遮掩掩，我们都是一样的。成为一个小小的「学者巨星」会让你有更多的机会；在组织中，当一名「数字经理」或「探索经理」也可能完全够用，不要为此感到沮丧。

无论你是否认为自己是产品经理，想要获得团队和整个组织的身份认可，下面这三点非常重要：

1. 承担起负责任的风险，抓住机遇。

2. 实现高效和有效的交付。

3. 与其他部门沟通和同步风险及交付情况。

（原文作者：Antonio Neto；文章出处：Medium)

>> LigaAI 往期精彩阅读 <<

什么是研发 Lead Time？我终于掰扯明白了！

研发效能管理中的经典度量——DORA 指标

清单推荐：常见的研发效能度量指标（科学管理版）

新任技术管理者如何更快更好地适应角色转变？

LigaAI 将持续分享更多成长经验、研发效能管理实践，陪伴每一个研发团队和开发者成长。欢迎关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

写在前面：本文译自 Jason Doherty、Kelsey Stevenson 和 Thomas Vela 于「2019年丹佛创业周」发表的「Outcome Based Roadmaps」主题演讲实录；原作者为 Jason Doherty。

如何制定产品路线图（上篇）中提到，今天优秀的产研团队不只关注功能的上线交付，还更加在意功能交付后是否达成了预期的结果，而结果（Outcome）是功能所产生的、可测量的、与企业目标一致的用户行为的变化。

跟随路线图制定的前四部曲，我们设立了一个产品愿景，多个目标、结果和机会。在敲下第一行代码或键入第一个词语之前，我们先明确了「什么是产品成功」，并清楚地指出实现目标所需关注的一系列事情。

你可能不信，大多数团队并不这么工作。他们实施的功能通常来自 CEO 或 SVP 在晨间沐浴时蹦出的想法——典型的 HiPPOs（Highest Paid Person’s Opinion，最高薪人士意见）现象。Jez Humble 在 2012 年的一项研究中指出，超过 60% 的产品团队会通过 HiPPOs 决定待构建的事项。

产品成功被定义为「功能上线」，而只有七分之一的功能实现了「创造可量化的影响」的目标。

得到一个想法，非常容易。

解决用户问题并实现目标，却很困难。

一个可以衡量成功与否的战略框架，能够让拥有授权的跨职能组织不断迭代功能并解决问题，直到预期目标达成。

01 结果导向的路线图

路线图是一个与领导层和产研团队沟通的战略工具。它阐明了

• 愿景和目标是什么？
• 想要达成什么结果？
• 如何衡量「成功」？
• 当前的重点是什么？
• 有哪些重要的时间节点？

路线图侧重于产品愿景、目标、成果和机会，而发版计划则描述了故事、功能、解决方案和想法。

02 最容易实现目标的是跨职能团队

就像前面说的那样，过去大多数功能都是由高高在上的企业领导者所指定，与产品战略毫无关联。产研团队像外包供应商一样，不断实现功能；无论功能是否达到预期，我们只衡量工程师团队的开发速度和已交付的功能，接着便能宣布成功。

更快地交付错误的功能，依然没有交付价值。

现在，高效能的产研团队使用数据和用户反馈，衡量功能是否达成预期目标。每个功能在发布时都是可量化的，并且都有一个预期的结果。团队会不断迭代功能（使用精益创业技巧，如「构建-评估-学习」循环）直到成功为止——大家都知道什么是成功，也清楚目标应该长什么样子。

企业中最有能力达成结果和目标的人，是那些实现功能和离用户最近的人；他们通常是产品团队、产品经理、工程师和运维团队。 理想情况下，他们应该处在一个跨职能团队中，而不是孤立地分布在各个部门里——如果这正是你所在团队的组织形式，那么结果导向型管理恐怕不太适用。

03 机会 > 想法 > 解决方案 > 功能

跨职能的研发团队如何以结果为导向，确保发版计划与路线图的目标一致，并将价值交付落实到研发全流程中？

制定产品策略图的第 5 步：将「结果」同步给跨职能团队，让他们：

结合共同商讨出的机会，提出想法（Idea）；

使用数据和用户反馈，验证哪些想法真正解决了用户问题；

根据已完成验证的用户问题的解决方案（Solution），创建功能（Feature）；

迭代功能，直到真正获得成功。*

强烈推荐使用 Theresa Torres 的「机会解决方案树」工具，它可以清楚地展现结果和解决方案之间的联系。

机会解决方案树要弄清楚三个问题：

1⃣ 有哪些想法可以解决这个机会？

2⃣ 曾经尝试过哪些实验、假设或可能的解决方案？

3⃣ 实验的结果如何？是否要推进该功能/放弃这个想法，或者展开新的实验以改进该想法？

实践中，应该明确地向管理者表达自己看法，承担起自己的责任；在大公司里，随着时间推移，也可以在团队间交流彼此的学习经验。

通过实验验证想法后，再推进下一步工作，创建功能和用户故事，并构建生产就绪的代码。优秀的产研团队总是避免构建没有价值的功能。

机会解决方案树有助于让高层领导们更具体地理解实验和学习成果。Dave Chalmers 在《一个前「功能工厂」的 PM 自白》中，也提供了一些能让机会解决方案树在组织内具象化的实用建议。

04 Current, Next and Future 模型

尽管我很反感在路线图上设置时间点，但现实情况是我们需要为企业高管们提供一些时序计划的指导；可以使用「Current, Next and Future」模型，列出时间线。

别忘了要在路线图上列出产品愿景和目标，以确保结果与目标紧密相关。如果需要，也可以将结果按主题（Theme）分组，这有助于战略的具象化。

将所有内容放在一起，就会得到一张结果导向的产品路线图：

一个非常有用的小技巧：只罗列出「Current」列中正在开发的功能，让企业高层们了解「目前正在进行的工作」和「下一季度或以后的战略」。

由 Todd Lombardo、Bruce McCarthy、Evan Ryan 和 Michael Conners 合著的 Product Roadmaps Relaunched 一书中也有许多很棒的案例，推荐大家阅读。

总结一下

以结果为导向，管理产品是一个难题。我们必须建立一个清晰的产品愿景和战略；必须拥抱变化，接受不确定性；必须放弃传统的项目制管理，转向结果导向的怀抱。

我们要组建和培养一支能够掌控结果的团队，授权他们解决问题，并不断迭代直到产品成功；还要构建 DevOps 文化，以便在生产中安全地与真实用户一起测试想法，获得反馈和数据。

别担心组织规模太大或限制太多而无法开展以结果为导向的管理工作，因为亚马逊、谷歌、Netflix 和 Facebook，甚至英国政府，都是这么工作的。

在工作实践中逐渐向结果导向转变，尤其是销售主导或工程主导的团队。可以慢慢地从小规模改变开始，关键在于要结合产品路线图，围绕产品的共同愿景，建立起一致性。

>> LigaAI 往期精彩阅读 <<

从 Netflix 传奇看，结果导向的产品路线图如何制定？（上篇）

Outcome VS. Output：研发效能提升中，谁会更胜一筹？

对话 ChatGPT：现象级 AI 应用，将如何阐释「研发效能管理」？

「钞能力养成指北」前传：开年变富，如何迈出第一步？

了解更多研发管理、敏捷开发、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

原则上，践行敏捷开发很简单：构建一个增量；测试这个增量；了解需要改变的信息；将信息反馈到第一步中，并重复步骤。

整个过程可以从两个方面，将敏捷开发与瀑布开发彻底区分开：第一，尽早且频繁地交付小批量的可工作的产品；第二，根据（一）得到的新变化和信息，对产品进行恰当的调整。

如下图所示的敏捷路线图很常见。时长一年的甘特图上堆满了功能，并提前完成了任务分配。研发团队只能在一个个不间断的迭代中，实现所有的功能；他们还没有机会总结已交付的工作并作出调整，就必须立刻进入下一个功能开发。

如果前两个产品功能交付后被证明是错误的（这非常有可能发生），难道我们还要按原计划迭代下去吗？继续遵循上面的甘特图，可能会一错到底。因为计划好的路线图无法帮助我们评估交付效果，识别问题并及时调整。

敏捷开发刻意只关注下一次迭代的即时计划，但许多团队构建了一年甚至更长时间的甘特图，并且罗列了无数个待开发功能和完成截止日期。这样怎么会敏捷呢？

01 前瞻性计划：敏捷刻意忽略的部分

除了当前迭代正在构建的产品外，敏捷方法论不太关注前瞻性的计划。因为只有这样才能做到「实时计划」——我们应该看到什么是可行/不可行的，并根据反馈的数据决定下一步该怎么做。

敏捷意味着「能够快速轻松地行动」，而敏捷开发需要被持续引导，逐步提供价值，再根据市场反馈的情况快速调整策略和方向。这是一个建立在洞察与反应几乎同步的快速反馈周期，而不是基于前期的大计划。

但是，组织（尤其是大型或传统组织）通常不喜欢没有计划地工作。没有计划的组织会陷入「计划缺失焦虑症」；更准确地说，组织的领导者会很焦虑。因此，他们会制定一个功能列表，提前做好分配，以确保每个人都能按预定的方式有序地工作。

敏捷的组织应当正面解决计划缺失的焦虑，但许多团队没有这样做。反而是领导者们认为，过去路线图和甘特图很有用，那就应该继续使用它们。慢慢地，敏捷就变形成「Water-Scrum-Fall」，就像下图这样。

不幸的是，敏捷的核心——灵活自由地根据新信息进行调整——被完全忽略了。许多团队实践的敏捷并不是真的敏捷，而过去的瀑布式任务列表也演变成了「用户故事」列表。

02 SAFe：敏捷适配器

敏捷框架没有提供任何当前迭代以外的具体规划建议，而扩展框架正填补了这一空白。SAFe 有一个优点：作为从前期瀑布式大计划到团队敏捷执行的适配器，它可以很容易地被理解。

使用 SAFe（或其他扩展框架），产品管理团队提出功能，设计团队绘制 UI 模型，再发送给管理层审批。当工程师开始编写代码时，管理层会很放心。因为他们已经做好了充分的计划，而成百上千名程序员都会尽职尽责地工作。通过敏捷扩展框架，管理人员可以看到所有计划中的功能，而开发人员可以在迭代中专注地写代码。

这也是敏捷扩展框架受欢迎的原因：它们将领导者熟悉的大型计划，转换为研发团队可执行的敏捷迭代。在一些高级管理者看来，这就是最重要的。事实上，工程团队已沦为「功能工厂」，他们几乎失去了所有学习、快速调整和改变的能力。管理者却真诚地相信，团队已经完成「敏捷转型」。

03 敏捷性需要空间来操作

回到前面提到的两个决定性敏捷特征：尽早且频繁地交付小批量的可工作的产品；根据（一）得到的新变化和信息，对产品进行恰当的调整。

第一点比较好理解，几乎所有资料也都集中在这上面；能够正确掌握第二点的人要少很多。如果团队没有从早期部署的迭代中学习，也没有将洞察力融入后续的迭代优化，那么就没有正确地践行敏捷——这其实只是「增量瀑布」。

正确的敏捷要求组织多次发布和重新发布相同的功能，并且每次都要从早期的经验中吸取教训，使该功能更易于使用、更强大、性能更好或在某些方面更好。这需要时间，而且这些时间无法在前期被充分估计和预先承诺。因此，要想成功地洞悉变化，完成迭代优化，团队需要在计划中做到以下三点。

1. 计划实现的路径必须是可塑的。定义一个愿景或最终目标，但允许具体的功能和内容在执行时可以有所变化。我们无法准确预测一个功能会如何运转，所以需要测试它。敏捷团队要允许每个功能能被反复加工、打磨或扩展几次，直到真正实现它。
2. 计划需要为调整和优化留出弹性空间。如果时间已经全部按计划分配完，就需要删掉一些东西。正确的策略是在一开始就不要填满所有时间，让它保持开放状态；可以为新想法整理一个新队列，直到时间允许，再进入迭代分配。后文的 「Now-Next-Later」也会详细讲解这一方法。
3. 领导的支持。这通常是三点中最难实现的。

04 领导力是敏捷性的关键

最具影响力的成功因素是组织展示和激励的领导范式。—— Agile 2

很多领导层都认为敏捷是团队内部的事情。这种假设肯定是错误的，而领导们也需要以敏捷的方式行事。在项目过程中，如果要为团队提供调整的空间，领导者就要接受临时的计划。「可塑性强的路径」和「允许调整的弹性空间」印证了这点。

管理者要有足够的勇气和决心，才能对团队说：“我们不打算在这个迭代将你们的工作填满；你们需要跟着数据走，看看自己的工作成果。” 如果领导者要真正拥抱敏捷，他们就需要做出根本性的改变。这遵循精益创业的精神：建立一个项目、测试它、从数据中学习、并将这些经验直接反馈到后续的项目中。

同时，领导者也要有勇气，接受这些事实：团队不会在外部干扰下提前确定工作，也不会一轮接一轮无缝地进行功能开发。团队需要更多实验性、创造性和跨职能的工作。

这同样意味着，领导者需要快速响应、批准通过更多碎片化的需求变更。他们要探索出更灵活地工作方法，以便为团队提供及时审批。这无疑会打破官僚主义的枷锁，而由领导者们组成的小团队则能更快、更独立地监督和批准自己团队的工作。

05 Now-Next-Later 模型

更常用的敏捷路线图工具是「Now-Next-Later」模型。甘特图中层层叠叠的功能集可以归纳总结为三个模块。

• Now：我们正在积极工作的事情。
• Next：「Now」完成后，即将开始的工作。
• Later：其他所有未分配和未承诺的功能。

将新的需求、功能和工作按模块规划好，比挤进拥挤的甘特图要容易得多。我们可以很轻松地在每个模块中留出弹性容量空间，以便后续根据最新信息做出调整。

可以看到，「Now」中的项目定义得比「Next」更加详细，「Later」是定义和描述最少的。每个模块的时间跨度可以自由决定，但最好跨度大一些，尽量覆盖多个迭代和优化周期；建议的时间周期是每个模块 6 周或者一个季度。

正确地使用「Now-Next-Later」，既能让我们适应短期变化，为后续工作和 Bug 修复留出空间，也能适应长期变化，改变我们对哪些功能要从模块中取出的想法。

但它不会消除干系人要求尽快交付功能的压力。这也是为什么领导者需要自己拥抱敏捷，才能让团队成功。领导者需要通过自己的努力，倡导敏捷的工作方式，并以同样的标准要求自己。

06 结论

许多自称敏捷的组织，他们提前计划了大量功能列表——通常提前一整年——并告诉团队要以小批量的方式交付。这不是敏捷，这是增量瀑布。

敏捷开发的核心特征是小批量地交付可工作的产品，从早期迭代中获得洞察力，并在后续迭代中进一步完善和优化相同的功能。其中的关键在于我们无法预知和确定什么是可行的，什么是行不通的；这需要洞察和跟踪数据。打造一款优秀的产品，我们要一边走，一边制定计划。这与一年长的甘特图完全不同。

「Now-Next-Later」只有与团队自主权相结合时才有意义。这样才能使团队发现计划的调整空间，及时做出应对。想要灵活地工作，在做计划时要注意建立高度灵活的路线图、留出充足的弹性空间用于响应调整，以及获得领导层的积极支持。利用好这三点，就可以持续地引导项目，而不是在前期就将它固定下来。这就是敏捷真正的意义所在。

原文作者：Raj Nagappan

文章出处：Medium

>> LigaAI 往期精彩阅读 <<

多个服务器如何跨命名空间，访问公共服务？

半个月上线一个新产品，猴子无限是怎么做的？

如何基于GitHub Pages+Hexo，搭建个人博客？

多测试环境的动态伸缩实践

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

致力于打造新一代智能研发协作平台，LigaAI在不断强化自身智能化能力的同时，也持续关注着整个「AI+协作」领域的发展。

Gartner在《 2022 年重要战略技术趋势报告》中指出，未来三到五年内，智能决策、分布式企业和生成式AI等 12 大技术趋势，将成为数字业务和创新力量的增速器。其中，生成式AI（Generative AI）和AIGC（AI-Generated Content）已然成为最引人注目、最「出圈」的人工智能技术之一。

与外界广泛讨论「AIGC会否取代画师」的角度不同，AI创业者们认为，AIGC商业化有着更具想象的空间：企业级智能设计协作。

本期「Liga妙谈」，我们有幸邀请我们有幸邀请猴子无限（http://frame.infmonkeys.com）CEO尹伯昊，以从业者视角分享他对AIGC的理解，并与我们一同探讨「AI+协作」的无限可能。

1. 「人工智能+企业协作」的新模式
2. AIGC驱动的组织生产力特点
3. 生成式AI对工作模式的改变
4. AIGC商业化模式与价值验证

01 信息共享是高效协作的基础

LigaAI：从创业Day 1 起，你就选择用LigaAI进行研发协作。你怎么看待「协同协作」这件事情？

猴子无限-尹伯昊：人类生存就是要靠协作的。人类社会由能量和信息组成，人靠信息交换而活，这是最底层的逻辑。

本质上，协同和协作是通过建立一种通畅的信息流通机制，让全员参与决策。就像网飞（Netflix）和字节跳动强调的「Context, Not Control」一样，管理者将信息共享到团队里，让组织中优秀的成员参与决策，才能达成最大的管理效果。

LigaAI：建立信息共享渠道，让研发协作更高效，是LigaAI的设计初衷之一。我们通过强大的aPaaS能力，辅助开发者们形成信息自由流通、高度共享自驱的环境；自然而然地，团队决策效率和开发效率也都会因此得到提升。

猴子无限如何基于生成式AI，解决企业的设计协作问题呢？

猴子无限-尹伯昊：跟研发一样，创作也是天然需要协同的，Figma、Canvas等产品的大热都是基于这个前提。猴子无限只是在用全新的生成式AI的手段，解决过去既存的创作者经济的问题。

现有的AIGC无法成为协作工具的大部分原因在于：基于通用的Stable Diffusion训练集，创作者很难生成基于特定对象的图像，比如一个穿着钢铁侠战衣的我自己。

但是，猴子无限通过大模型Fine Tune，将少量的个性化数据，比如我的照片、特定商品的图片，训练到已有的大模型中生成新的大模型，再让个性化大模型帮我们创作，实现企业级的设计协作。

举个例子：在电商团队里，可以将一个SKU作为设计中心，让AI学习品牌的设计风格，通过调参实现批量生成商品海报样稿、周边物料设计草稿等「重体力」的设计诉求。

LigaAI：今天的设计协作很多是基于分层素材的框架进行的，就目前的AIGC能力来看，大家普遍认为生成式AI无法解决「分图层文件」的难题。

甚至有人认为：AIGC要么需要专业、复杂、需要懂点代码才能生成优质作品；要么它就是个面向个人的大玩具。你怎么评价这些观点？

猴子无限-尹伯昊：确实很多人会说「AIGC现在是个玩具，以后也是玩具」，但大模型连蛋白质折叠都能解决，为什么会解决不了一个本就由人类定义出来的分图层问题？

生成式AI最核心的能力是，有机会让机器创作出所有过去只能由人创作出来的模态，而大模型就是让机器将未被发掘的统计学规律萃取出来。

所以，理论上只要有足够多的分图层PSD文件，AIGC就可以解决分图层的问题。它现在可以生成单图层文件，未来就一定可以制作分图层的。

向内引入更多的数据来训练AI，一定会带来颠覆性的改变。这也是猴子无限在努力的方向。

02 商业闭环是生产力的核心纽带

LigaAI：现在的AIGC还是存在很多技术限制，你认为它依然可以快速服务于企业的生产力提升吗？

猴子无限-尹伯昊：当然。不是只有 100 分或者全能的工具，才能成为企业的生产力；一款工具，只要能很好地解决当下企业遇到的一部分问题，就在为企业带来帮助。

在过去大家都用Photoshop做设计，显然Photoshop也解决不了所有事情，但不妨碍大家使用它。AIGC同理，就像LigaAI也不能解决一个公司的所有管理问题，但你们能为研发管理提效，就能为我们提供价值。

LigaAI：判断一个东西能否真正构成生产力，可能有一个简单粗暴的标准：有多少完全不了解技术的人开始讨论「我不想被机器替代」。

猴子无限-尹伯昊：确实是这样。我们判断生产力的标准是，它能否构建完整的商业价值闭环。

我们发现，在任何一代科技革命中，只有那些成功建立商业闭环的人和企业，才能引领变革成功。爱迪生不是第一个发明电灯泡的人，但他发明了可应用于商业的白炽灯，还成功打造了「白炽灯+配电系统」的商业闭环并产生了价值。

所以，只有建立生成式AI的商业闭环，产生商业价值，才能真正成为专业创作的生产力。而大模型Fine Tune（基于已有的数据，插入新的数据）正是其中不可或缺的核心纽带。

03 要让机器帮助我们工作

LigaAI：你怎么评价「AIGC终有一天会替代传统画师」？

猴子无限-尹伯昊：这很残酷，但是新技术出现一定会带走一些传统的东西，这是无可争议的事实。

从生产力的角度解读，从前艺术家们只能卖作品，但是现在可以将画风提取出来，支持画风的售卖，或者让机器根据艺术家的画风智能生成 1000 张图像。这都是新的机会。

在工作场景中，人和机器从来不是替代关系，应该是共生关系。大家面对新的技术变革，其实不用担忧「机器会在哪天把我干倒」，而是应该思考「如何让机器为我做事情」。很多历史证据都证明，机器和新技术完全有机会成为人类的助手。

LigaAI：智能协作，与技术共生，也是LigaAI想传递给所有开发者和研发团队的理念。

我们坚信，开发者的精力不应该放在信息同步、完成状态勾选、进度同步等「啰里吧嗦」的小事上。机械重复的流程化的事情就应该交给机器、交给AI去完成，而真正富有创造力的开发者们可以认真、专注地分析需求、研究数据结构，心无旁骛地探索和创造更具远见的创新性产品。

理想中，枯燥无味的重复性工作应该借助机器完成，以此获得更高的生产效率。

猴子无限-尹伯昊：比如让AI写代码吗？说起来，AI自动写代码应用的ASM技术也算生成式AI的一种。你们怎么看GitHub Copilot这个工具？

LigaAI：早在很多年前，大家就开始讨论纯文本的AIGC，比如小冰写诗，后来发展到AI文本续写，再到现在的AI写代码。

跟图像图层一样，编程语言也是在人类社会的数字化浪潮中被定义出来的范式，没有哪种自然语言比代码的语法更清晰、更规范化。

「让AI写代码」在这一逻辑下，似乎就是必然会到来的事情。但是如何基于业务、产品、功能的需求，分析和设计代码背后的逻辑结构，是复杂的，是需要人去发挥创造力的。

就好比在过去，没有构图、配色、艺术审美基础的人想用绘画表达自我，绝非易事。而AIGC在一定程度上构建了一个「表达自由」的世界。这大概也是AIGC于普通人而言最大的价值。

猴子无限-尹伯昊：是的。即便当下关于生成式AI的争议很多，但我们依然对它很有信心。生成式AI还是有无限的潜力和机会的。

04 机会面前，快鱼吃大鱼

LigaAI：说起来，最开始接触你们的时候，团队在做的是智能生成PPT。但是现在的猴子无限已经是一个相当完整的AIGC类产品了。为什么团队可以在如此短的时间内，完成产品的重定位和重塑？

猴子无限-尹伯昊：修正产品赛道主要原因是，我们发现想让机器做幻灯片，一定要做自己的垂直模型。那反正都要做大模型Fine Tune，不如把它抽离出来，直接做成「Fine-tune as a Service，调优即服务」。

我们希望通过大模型Fine Tune，让每一个品牌、创作者、艺术家、甚至科学家拥有自己的专属大模型。在高效完成内容创作与协同的同时，打造AIGC驱动的业务增长核心，让生成式AI成为真正能产生业务价值的生产力。

而且，最早跑通商业闭环的公司会赢者通吃。在一个巨大的结构性机会面前，正是「快鱼吃大鱼」的时候，所以我们「掉头」地超级快。

LigaAI：猴子无限接下来有什么计划？

猴子无限-尹伯昊：基于整个产品逻辑，未来猴子无限会将更多的数据插入已有的大模型里，包括视觉、文本、DNA、RNA、蛋白质药物等等。

同时，我们已经与多家头部广告公司、消费品牌以及AIGC应用达成合作，通过B端C端联动的商业模式，完成专业内容生产和企业级协同合作。接下来会在多个场景遍地开花，逐步验证Fine Tune在企业级设计协作中的价值潜力。

# 写在最后

2022 年被称为「AIGC元年」，生成式AI探索出全新的内容创作模式，同时也为更多企业和创作者带去新动力引擎。

新的技术应用带来生产力变革，而「人工智能+团队协作」也延伸出无限的可能性，而LigaAI也将持续关注AI生态，探索并挖掘更多 「AI+协作」的可能性，以赋能所有开发者团队。

>> LigaAI 往期精彩阅读 <<

多测试环境的动态伸缩实践

被忽悠入坑后，我如何让产品「起死回生」？

研发效能应该如何管理与度量？

如何让敏捷小组在迭代回顾会上「知无不言」？

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

10月13日，LigaAI受邀参加2022亚马逊云科技中国峰会，并发表了题为「利用亚马逊云科技AI/ML服务开启新一代智能研发协作的大门」的主题演讲。聚焦数据驱动，本文将与大家分享「数据驱动+AI+研发协作」模式下的创新火花。

一、当前研发管理正在面临什么难题？

这个问题可以从开发团队、管理者和协作工具三个维度解读。

01 开发团队维度

• 很难与业务团队和管理者在目标上达成一致；
• 不认为进度上报、工时登记等属于本职工作，因此完成积极性通常不高；
• 与其他团队协作缺乏有效沟通机制。所有事情依靠人推动，一旦忘记或遗漏就会受到阻碍；
• 大量时间耗费在与开发本身无关的任务上，导致难以专注。

02 管理者维度

• 基于开发团队现状，难以获取真实进度数据。大部分进度数据滞后，或需依靠人工干预；
• 研发产出难以通过现有数据衡量。后补的数据失真严重，而原始数据的处理又十分依赖个人的分析和决策能力；
• 日常管理动作所需的进度跟进、沟通、任务分派、各方协同等微观管理，劳心劳力。

03 协作工具维度

• 灵活性较差。团队只能按照工具本身的方式工作，不能随意适配现有的流程；
• 开放程度低。没有丰富的API和数据同步机制，很难与其他系统打通；
• 自动化程度低。所有的事情必须通过人力手工处理，增加了使用负担，也导致团队不愿意使用工具，进一步加剧数据失真。

以上三方面原因综合导致研发效能提升困难。

二、更好的研发协作方式是什么？

传统研发项目管理中，协作过程串行化严重，团队内部的大量空转造成了巨大浪费，同时也产生了很大的项目延期风险。

LigaAI认为未来更好的的协作形态应该是「赋能型管理+自驱型团队+智能化工具」的有机结合。

新一代研发协作模式具有业务导向、目标导向、全员参与等特点。要实现以上效果，需要组织文化与团队成员配合作战；

此外，合适的工具也能帮助团队更快地实现目标，二者缺一不可；而风险预警、智能协作等场景也非常适合通过 AI 提效。

让机器处理机器擅长的事情，让人回归到更有创造力的本职工作，这就是「数据+AI」驱动的下一代研发协作。

三、为什么要构建数据驱动型企业？

01 对内全面提效

从企业内部看，数据驱动的研发协作等于全面提效。通过数据驱动，LigaAI希望达成以下目标：

· 提高组织内部透明度。让各个部门可以随时了解其他部门在做什么、进度如何；保证各部门可以顺畅协作，减少信息损耗，提高流转效率。

· 培养数据人才和数据意识，让大家养成关心数据、使用数据的习惯。

· 提高研发团队的业务参与度。缩短研发团队与业务的距离，让研发成员了解用户对自己研发的产品的使用情况和满意度。

· 提升开发人员的成就感。与业务参与度相伴而生，要让大家更愿意主动地解决业务问题。

· 企业内部各部门在内部决策时，可以有所依据，降低决策难度和决策成本。

最后，全面提升业务敏捷性。

02 对外增强产品竞争力

ToB SaaS企业内部提效最终要表现在外部市场。从SaaS客户的视角看，数据驱动的研发协作意味着产品竞争力增强。

· 于SaaS产品而言，用户体验是重要指标。通过数据驱动，可以提升用户体验和客户满意。

· 提供个性化的服务支持。采用「数据+AI」的模式，学习不同用户的使用习惯，推荐更适合的流程，为不同用户提供针对性的服务；还能降低上手成本，让产品陪伴用户成长。

· 传统工具常提供大量原始数据，需要用户自己进行分析解释；LigaAI以「数据+AI」的方式，为用户提供辅助的决策建议，实现数据洞察。

四、如何构建数据驱动型研发协作和企业？

下图的金字塔自上而下是一个由虚转实的过程，四层内容分别代表愿景、目标、实施和数据利用。

下面以LigaAI为例，展开分享如何按照金字塔步骤，搭建数据驱动型企业。

01 管理愿景

数据驱动是一种理念、战略。企业需要先在内部达成统一的认识，形成自上而下的、一致的数据愿景。

02 企业效能目标

确定愿景后，定义阶段性目标。LigaAI聚焦研发协作，当前阶段最主要的目标就是企业效能提升，那么「企业效能提升」就是数据驱动的目标。

以下是一些推荐的效能目标。

03 可扩展的数据架构

明晰目标后，就可以实施。LigaAI先搭建了一个最小化的可扩展数据架构（下图是简化版的核心架构图），从左至右分别是数据源、数据处理、数据存储和数据服务。

LigaAI的数据源包括Aurora关系型数据，以及非结构化的文档数据、日志数据、队列数据等；

根据业务情况，数据源处理分为实时和离线处理：实时数据处理一般使用DataSync服务，而非实时数据则采用传统的ETL程序进行处理；

所有处理好的数据会统一放到基础的数据存储平台，LigaAI选择的是DocumentDB和S3 ；

最后，数据服务分为两个部分：已经处理好的数据，通过查询服务直接对内部、外部应用提供接口；

与AI相关的服务，LigaAI以SageMaker为核心，搭建了一套AI工作流程，并实现AI数据训练、模型发布、模型部署等自动化处理。

04 构建数据驱动的正循环

将架构和平台应用结合，构建数据驱动的正向循环。

LigaAI的数据驱动正循环以团队为核心，团队在LigaAI平台上使用产品并产生数据、数据驱动算法、算法改进平台。平台、数据、算法三者相互驱动，形成「效率提升内循环」，这是对平台客户的价值；

在企业内部，LigaAI形成了以产品、客户体验、反馈池、研发迭代为主体的「价值滚动外循环」。

内外两个循环共同组成我们的价值飞轮，最终提升产品竞争力。

五、 关于数据驱动提效的建议

构建数据驱动时，可以从价值比较高的具体场景，或比较容易出效果的场景切入，增强团队信心；

也可以利用云产品快速搭建合适的数据架构，实现快速启动；

启动后，需要关注数据生产、使用、改进的正循环。只有不断改进，才能走得更远；

最后，注重数据安全、隐私与合规，也非常重要。

六、如何衡量数据驱动为企业带来的效益？

下面是一组LigaAI构建数据驱动型企业的效益数据。

01 研发协作提效

• 简化需求排期流程
• 更有效的研发工作衡量方法
• 超过 40% 的任务实现自动流转及通知
• 新模型上线，从 2 周变成了 2 天

02 价值交付

• 提高了产研对业务的参与度
• 快速反馈，提高业务的敏捷性
• 更高的客户评价与市场竞争力

整体而言，LigaAI帮助诸多企业成功实现了业务协同、降本增效的大目标。

# Liga总结

以「数据+AI」为核心的下一代研发协作，能够帮助企业完成更多的任务：让机器做繁琐重复的工作，将人回归到本职角色专注创造。

减少琐事和干扰事项的打扰，让开发者体验沉浸式工作，让专注激发、释放更多的创造力和生产力。

>> LigaAI 往期精彩阅读 <<

如何搭建可伸缩的研发流程管理方案？

影响研发效能的7个常见场景解读

分享一个优先级系数计算公式

迭代评审会的七宗罪，你知道吗？

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

• 语言工具三：期望成果 Desired Outcome
• 如何串连三个工具？

工具三

期望成果 Desired Outcome

如果很疑惑「任务故事」中的 Expected Outcome 要写什么，别想太多，直接来看 「ODI 创新流程 Outcome-Driven Innovation 」中的 Desired Outcome Statement。我觉得这是整个理论界的核心关键之一，有承先启后的作用，也给了用途理论（Jobs To Be Done，即 JTBD 理论）极大的差异性。

ODI 创始人 Tony Ulwick 可能比 Christenson 更早开始研究、应用用途理论，他口中的用途理论，跟 Christenson 有个重大差异：

任务「就是」用户在特定「场景」中，能获得「提升」。
A job is the progress that an individual seeks in a given situation.

在 Christenson 的版本中，他则说：任务「使得」（enables）用户获得提升。由此可见， Ulwick 特别注重提升，因此提出「期望成果」这个语言工具，并直接认定「提升」才能代表用户需求。

下面这张图，简洁说明了「期望成果」的结构：

Ulwick 说明 Desired Outcome Statement 是「用户定义的指标，让提升变成可被衡量、被掌握、被预测的过程」，必须透过访谈挖掘用户期待的提升，再转化成「期望成果」的语言结构。

换句话说，虽然我们难以衡量体验本身（毕竟设计与美感带有主观成分），但可以衡量「体验带来的结果」。除此之外，衡量「期望成果」和「目前成果」的差距，就成了 ODI 创新流程中的关键方法。

在 Christensen 在《创新者的用途理论》中也提出类似概念。他认为，用途理论不仅改善流程精进的方向，也会改变衡量成效的方式。它把关键的绩效标准从「内部的财务绩效指标」转变成「外部的顾客效益指标」。

我觉得上面两个说法太冗长、太绕口，改用以下方式称呼：

• 商业成功指标 Business Success Metrics：各类财务指标、生产与物流的效率指标、服务流程的漏斗转换率，通常以「优化绩效」为目标。关注这些指标的主角，大概九成以上是公司本身、或团队成员、或股东的金融分析师。
• 用户成功指标 Customer Success Metrics：以用户为主角的指标，以期望成果为代表，是用户衡量「特定场景下获得多少提升」的方法。虽然用户内心知道衡量的方式，但未必能精确表达出来，需要挖掘、萃取与转化。

这边举个例子，协助大家理解「访谈内容」转化成「期望成果」的前后对照。以「商品详细页」上的「商品评价」来说，我们在访谈中询问用户：

• 什么时候会用商品评价？
• 哪些情况，让你觉得商品评价很难用？
• 你希望商品评价如何帮助你？

我们获得了这个用户的这段话：

大概购买前都会略看评价，（用评价中的照片）看看和商品照有没有误差，特别找评分低或大串文字的评价，看看缺点。觉得评价会很大地影响购买行为，会推坑帮助下决心，也会补足商品规格的不足。觉得困扰的是常常看到不相干的商品评价，或看到评分太高等，反而让人特别担心，有时候是反指标。

当然，这只是其中一小段访谈记录。访谈过多位用户，发现了商品评价带给用户的提升，其实就是：减少顾客「发现产品不符合期待」的情况，特别在结账前一刻，或收到商品之后。

这句话是挖掘、浓缩、转化后的结果，访谈后我们必须从多位用户身上，自己辨识出这一个重复出现的期待。每位用户虽然用了不一样的描述方式，但其实都在讲相同的期望成果。

如果已经有办法浓缩出用户成功指标，「期望成果」适合用在以下情境：

• 当队友不理解产品、功能、专案对用户有什么价值时，用简短的一句话破题，开门见山地传达「用户成功指标」，然后再补充更多情境与实例；
• 放在任何需要描述「目标」的地方，例如：PRD 、产品/功能提案、专案简报、年度或季度的目标设定、OKR 中的 Key Results；
• 放在「任务故事」的 So I can (Expected Outcome) 段落。

思考

如何串连三个工具？

我们用了两篇文章，介绍「用途理论」中的三种「语言结构」（任务规格书、任务故事、期望成果），当我们下次面对三种状况时，希望能带来以下效果：

1. 减少「建立方法」时「花费的时间」或「遭遇的排斥」，融入现有方法，相辅相成。
2. 减少「叙述需求」时「花费的时间」，口头沟通时可浓缩成 3 句话，文字沟通时可浓缩成 1 页 A4 文件。
3. 减少「依场景重置沟通素材」所「花费的时间」，可以有弹性地重组、合并、拆分。

经过前面的介绍，举例来说，我们可以这样运用：

• 口头沟通时，先传达期望成果，再用任务故事补充，厘清目标和用户需求；
• 短文沟通时，以期望成果和任务故事开头，放在 PRD 或产品/功能提案中；
• 长文沟通时，把期望成果和任务规格书融入现有的研究报告中，搭配 UX 工具箱中「浓缩研究成果的图表」，图文并茂、相辅相成；
• 在期望成果、任务故事、任务规格书中替换相同内容，善用三者类似的结构，快速重组、合并、拆分。

经过这段探索与浓缩「用途理论」的过程，我发现这套语言结构，确实有串连各种工具的能力。当然，用途理论的观念不算是跨时代的进步，因为过去也有很多领域提出类似见解，例如：用户研究、设计理论、人类学、心理学、认知科学等等。如果接触过这些知识，读用途理论时很容易有「似曾相识」的感觉，甚至觉得只不过是「老调重弹」或「旧酒新瓶装」。

我觉得用途理论的漂亮之处，就在于它提出了够简单、够简洁的「思考框架」和「语言结构」。这带来两种效果：第一是帮助许多人在没有以上前置知识的状况下，也能在实务中直接应用；第二是帮助有前置知识的人「化繁为简」，在实务中串连各领域的知识和工具，并和没有相关知识的队友沟通协作。换句话说，这是一个「把理论带向实务」的桥接工具，因为已经精简到无法再简化的程度，所以才有办法贯穿各领域的知识之墙。

除此之外，我们千万不要小看「语言工具」的力量。产品经理的工作中，有太多时间要花在参与会议、口头协商、做简报、写文件，本质上「语言」就是我们吃饭的「工具」。如果有一套好用的语言工具，可以省去我们很多麻烦，建立有效的协商默契，并维持稳定的沟通品质，实在太重要了。

再进一步，还想跟大家分享一个私人的工作秘诀，那就是：产品经理要服务非常多的「用户」，包含了密切合作的伙伴——每个合作对象都是「使用产品经理的用户」。

在合作过程中，如果我们也用「期望成果」记录每个合作对象的期待，综合比对后，再说明我们必须面对的取舍，就能很有效地「厘清问题」并「沟通目标」。有句话说，每个伟大的产品，后面都有伟大的产品经理。伟大之处，也许就在于—— TA 用心观察、细心体会了每个用户的「用途」与「期望成果」。

本文作者: Jason HOU
文章来源: Medium

>> LigaAI 往期精彩阅读 <<

怎样简洁明了地说清楚产品需求？

为什么我们总是说不清「需求是什么」

技术分享 | Javaer 如何做单元测试？

敏捷实践 | 做优先级排序时使用最多的三个模型

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

• 任务规格书 Job Spec
• 任务故事 Job Story

工具一：任务规格书 Job Spec

「任务规格书」是比较完整又复杂的语言工具，实务中较少用到。呼应前面「产生需求的过程」，《创新者的窘境》一书的作者Clay Christensen 将任务界定为「用户在特定场景下想获得的提升」，任务一定和特定的情境脉络有关，他进一步说：

任务「使得」用户在特定「场景」中，能获得「提升」。

A job enables the progress that an individual seeks in a given situation.

如果要记录一个任务，他提出了「任务规格书」这个语言结构，其实也是个「文件结构」：

1. 用户处在什么「场景」中？
2. 想达成什么「提升」？想要的提升，有哪些功能面、社会面、情感面的任务？
3. 有哪些进步的「阻碍」？有哪些焦虑和阻碍？
4. 用户勉强接受哪些「不完美的方案」？我们必须赢过哪些方案？
5. 如何定义良好提升的「品质」？为了品质，用户愿意做哪些「取舍」？

如果我们做完需求探索、用户研究，可以按照以上五个问题，做成一份 1–3 页的 A4 文件。因为这个结构相对完整、复杂、不够简洁，所以更适合以下情境：

• 当作「介绍用途理论」的工具。
• 产品或研究团队「交接、浓缩研究结果」的工具，先让读者看完较短的文字摘要，再进入各种 UX 工具、图表、影音呈现的研究结果，加速读者的理解速度。
• 专案或产品启动时，先提供更浓缩、更简短的叙述，然后提供前项摘要的连结，给「想进一步了解用户需求」的队友参考。

工具二：任务故事 Job Story

「任务故事」是目前最被广泛使用的工具，但也遭受很多用途理论研究者的批评，因为它过度简化，容易被误用。同时，提出者 Alan Klement 是个充满争议的人物，因此得罪了很多用途理论的开创者。不过，Job Story 仍然是个实用的语言工具。

下面这张图，简洁地说明了 Job Story 任务故事的结构：

任务故事的格式，用任务故事代替用户故事。

这个方法进一步被 Intercom 发扬，他们进一步解释 Job Story 任务故事：

(1) When (Situation)：引发需求的场景

(2) I Want to (Motivation)：用户在场景中的选择动机

(3) So I can (Expected Outcome)：在场景中的期待提升

然后，他们会用 1–2 页 A4，提交一个名为 “Intermission” 的文件，当作一份产品/功能提案。在这份文件中，其中一段就是 Job Story，要能在几百字内讲完用户需求。推测 Intercom 之后就用这几百字的 Job Story 代表此产品/功能，在内部快速解释用户需求、沟通开发目的。

然而，实际上找出 Intercom 的 Job Story 案例，会发现几个问题：

• 某些 When 其实并没有说明 Situation，遗失了场景，只是把 As a user 改写成 When I am a user ，可以把 user 替换成各种画像、角色、职业等等； 例如，我们看过这种写法：When I am a Customer Support Manager… 和 When I manage a Customer Support Team…
• Motivation 和 Expected Outcome 的重复率很高，有时根本可以删去一个。

如果有以上问题，那 Job Story 就丧失了意义。若能避开上述问题，任务故事就适合用在以下场景：

• 即时口头沟通时，把用户需求浓缩成 3 句话，跟队友说明。
• 放在任务或需求池中的 Description「任务描述」中，简短解释用户需求。
• 模仿 Intercom，当成 PRD 或产品/功能提案的其中一段，解释用户需求，勾起读者兴趣，进而去看更详细的「任务规格书」或「用户研究报告」。

这篇文章，介绍了二个「结构化语言工具」：

• 任务规格书 Job Spec
• 任务故事 Job Story

但这两个工具都有明显的缺点，如何弥补这两个工具的缺点呢？有没有更简洁明了的语言工具？

下一篇文章，小编将继续跟大家介绍最后一个语言工具「期望成果 Desired Outcome」，并且还会跟大家说明该如何串连这三个工具，以及如何和原有的工具一起相辅相成。

本文作者: Jason HOU

文章来源: Medium

>> LigaAI 往期精彩阅读 <<

为什么我们总是说不清「需求是什么」

技术分享 | Javaer 如何做单元测试？

敏捷实践 | 做优先级排序时使用最多的三个模型

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

每天面对超多产品反馈、需求申请，花很多时间厘清、沟通？
参加无数的会议，冒出各种需求，发散的无边无际？
终于提出产品路线图，面对各方质疑，结果改到四不像？
…

这些收集、整理、协商需求的过程，是不是很令人头痛，又消耗我们宝贵的时间？不仅难取得共识，我们最怕的更是产出无法推动成效？

为什么需求描述这么难？

究竟卡在哪里？归纳出以下这几种状况：

状况一：描述需求时语意不清，没有厘清的过程，产生误会
状况二：针对相同的功能、接口、流程，因为每人代表不同用户，或遇到不同情境，提出互相独立的需求，产生冲突
状况三：针对相同需求，因为负责不同目标，或站在不同的解读角度，产生僵局

因为以上三种状况，导致我们必须反复沟通，消耗很多时间，也难以确立目标、推动成效。

举例 | 运营电商网站的团队讨论：如何优化商品详情页

状况一

市场 Abby：我们要提供更多商品照片，我看电商网站的时候最爱看照片了。

• 语意不清：「商品照片」是指主商品的照片，还是相关商品的照片？为什么需要照片，能达成什么效果？

状况二

工程师 Bob：放大图片的接口也很难用，点击图片还另开分页，又不能切换图片。
图片设计师 Cindy：但我觉得是排版有问题，很难找到信息，令人生气，我朋友因此干脆不买了。
图片客服 David：可是 ，顾客说「商品评价」最重要，又说我们的评价功能很难用，不能筛选评价。

• 情境差异：同样针对商品资讯页，在「什么情境」，觉得放大照片、或产品资讯、或商品评价，很难用？

状况三

市场 Eddie：我觉得最重要的是降低跳出率，因为这是站上流量最高的页面。
图片工程师 Fiona：我们不是有首购优惠吗？可以在商品页上强调，吸引顾客购买！
图片业务 Greg：对对对，卖家一直跟我说「优惠券功能」很重要，希望显示各种优惠，在商品旁边。
图片工程师 Henry：如果可以让顾客分享优惠给朋友，说不定还能带进更多流量！
图片市场 Iris：说到分享优惠，购物季要到了，可以完成「分享优惠」和「赠送购物金」的功能吗？

• 目标或角度差异：同样针对商业需求有关的「优惠」显示，但各自期待达成什么目标？这些目标分别遇到什么挑战、哪些限制？

如何改进？

知道这些问题后，我们该如何努力，朝什么方向改进呢？

• 面对状况一，我们希望：降低「描述需求」时「语意不清的情况」；
• 面对状况二，我们希望：降低「沟通需求」时「被自身立场、情境侷限的情况」；
• 面对状况三，我们希望：降低「提出需求」时「遗失或误会个别目标的情况」。

如果有一套语言结构，除了让我们朝以上方向改进，还能额外产生以下效果：

• 减少建立方法时花费的时间或遭遇的排斥，融入现有方法，相辅相成；
• 减少叙述需求时花费的时间，口头沟通时可浓缩成 3 句话，文字沟通时可浓缩成 1 页 A4 文件；
• 减少依情境重置沟通素材所花费的时间，可以有弹性的重组、合并、拆分。

那是不是很令人期待呢？

为了介绍这个语言结构，我们先回顾一下「需求」的本质。

需求与设计的本质

引用 《设计思考怎么改变世界? 》的这段话：

设计就是「现况」到「目标」的过程。在这里我为了好记，简单的说，设计就是 A→B

如果我们认同以上这段话，那么反过来说：

因为「使用者处于一个情境」，进而「希望达成某个目标」，所以产生了「需求」

先有「产生需求的过程」，我们才能「捕捉需求」，并依据需求来设计。符合「需求驱动设计」的「用途理论」，基于一个重要的假设：

人是「目标导向」的行为者，而「情境」会影响目标，但「手段」并不会

为了捕捉、描述需求，我们基于以上假设，产生了各式各样的工具，都为了达成以下子目标：

• (A) 降低团队「理解顾客情境」所「花费的时间」或「认知门槛」
• (B) 减少团队「描述目标」所「花费的时间」或「误解的情况」
• (C) 降低团队「沟通产品方案」所「花费的时间」或「误解的情况」
• (D) 降低团队「验证方案」所「花费的时间」或「经济成本」

举例来说：用户旅程地图、用户画像、故事板、同理心地图、价值主张画布等等，多少都希望能达成以上子目标 (A)、(B)。而辅助产品设计与开发的工具中，PRD、用户故事、用户流程图、线框图、流程图等等，都希望能达成子目标 (C)。

若我们野心更大，希望达成子目标 (D)，则需要众人通力合作，进一步导入原型图、可用性测试、A/B测试等方法。

然后我们就发现，这也是一个「工具氾滥」的时代。我们有「上千种工具」，协助我们厘清「上万种需求」，听起仍然让人无奈？在工具氾滥的时代，我们如何抓取「团队有限的注意力」，传达最重要的信息？如何给一个有效的摘要，快速复盘上次的阶段成果？有没有通用的框架，可以串连众多工具？

终于，我认识了「用途理论」，以及一套精简的「结构化语言」工具。

结构化语言工具

工具一：任务规格书 Job Spec
工具二：任务故事 Job Story
工具三：期望成果 Desired Outcome

简单的来说，我们可以这样运用三个工具：
口头沟通时，先传达期望成果，再用任务故事补充，厘清目标和顾客需求；
短文沟通时，以期望成果和任务故事开头，放在 PRD 或产品/功能提案中；
长文沟通时，把期望成果和任务规格书融入现有的研究报告中，搭配 UX 工具箱中「浓缩研究成果的图表」，图文并茂、相辅相成。
在期望成果、任务故事、任务规格书中替换相同内容，善用三者类似的结构，快速重组、合并、拆分。

下一期，小编将继续为大家详细介绍这三个工具，并进一步说明他们的神奇之处。

本文作者: Jason HOU
文章来源: Medium

>> LigaAI 往期精彩阅读 <<

技术分享 | Javaer 如何做单元测试？

敏捷实践 | 做优先级排序时使用最多的三个模型

故事点数vs工时，研发工作量到底怎么算？

译文 | 四张画布教你判断「产品开发优先级」

产品经理该如何确定优先级？

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

通过该案例，我们了解到 PhoneNumber 包含了初始化、校验、属性处理等多种逻辑，而传统的 POJO 类只包含其属性的getter setter方法。这是 DDD 和传统面向数据开发的重要差异点。

「PhoneNumber-充血模型」与「POJO 类-贫血模型」不难理解，笔者在「领域驱动设计入门与实践-上」中已对其做过介绍。难的是在实际项目中，若使用充血模型，如何把握好其强弱程度需要很丰富的经验。

DP（Domain Primtive）

我们将PhoneNumber这种类型称为 DP- Domain Primitive。类比 Integer、String 在 Java 编程语言中一样，DP 是 DDD 里一切模型、方法、架构的基础。

定义 DP：

在 DDD 里，DP 可以说是一切模型、方法、架构的基础，它是在特定领域，拥有精准定义、可自我验证、拥有行为的对象，可认为是领域的最小组成部分。

使用 DP 的三条原则：

• 将隐性概念显性化/Make Implicit Concepts Expecit

在Phone Number这个案例中，若使用 String 类型来定义电话号码，则「归属地编号」、「运营商编号」这些属于电话号码的隐性属性就难以体现出来，我们通过自定义类型PhoneNumber，通过赋予它行为来显性化了这两个概念，让代码的业务语义更加明确。

• 将隐性上下文显性化/Make Implicit Context Expecit

这里我们通过一个例子来说明：

假设现在要实现一个功能: 使 A 用户可以支付 x 元给用户 B，可能的实现如下：

public void pay(BigDecimal money, Long recipientId) {     
    bankService.transfer(money, "CNY", recipientId); 
}

如果这个是境内转账，并且境内的货币永远不变，该方法似乎没啥问题。一旦货币变更或做跨境转账，该方法留有明显的 bug，因为 Money 对应的不一定是 CNY。

在这个 case 里，当我们说“支付 x 元”时，除了 x 本身的数字外，还有一个隐含的概念「元」。

在原始的入参中，只用BigDecimal的原因是我们默认CNY货币是不变的，是一个隐含的上下文条件。但当我们写代码时，要把所有隐性的条件显性化，然后整体组成当前的上下文：做「支付」时，我们将「支付金额」&「货币种类」作为一个入参输入进来，两者整合成一个完整而独立的概念：Money。

原有的代码变为：

public class Money {     
    private final BigDecimal amount;     
    private final Currency currency;       
    public Money(BigDecimal amount, Currency currency) {         
        this.amount = amount;         
        this.currency = currency;     
        } 
    }  

    public void pay(Money money, Long recipientId) {     
        bankService.transfer(money, recipientId); 
    }
}

通过将默认货币这个隐性的上下文概念显性化，并且和金额合并为 Money，我们避免了很多当前看不出来未来可能会暴雷的 bug。

• 封装多对象行为/Encapsulate Multi-Object Behavior

将前面的案例升级一下：用户要做跨境转账，从 CNY 到 USD 且汇率随时在波动。

代码块：

public void pay(Money money, Currency targetCurrency, Long recipientId) {
    if (money.getCurrency().equals(targetCurrency)) {
        bankService.transfer(money, recipientId);
    } else {
        BigDecimal rate = exchangeService.getRate(money.getCurrency(), targetCurrency);
        BigDecimal targetAmount = money.getAmount().multiply(new BigDecimal(rate));
        Money targetMoney = new Money(targetAmount, targetCurrency);
        bankService.transfer(targetMoney, recipientId);
    }
}

这个 case 里

1、targetCurrency 不等于 money Curreny

2、调用一个服务去取汇率，然后做计算

3、用计算后的结果做转账

最大的问题在于金额的计算被包含在支付的服务中，涉及多个对象：2 个 Currency，2 个 Money，1 个 BigDecimal。这种涉及到多个对象的业务逻辑，我们要用 DP 包装。

应用 DP 的封装多对象行为，将转换汇率的功能封装到一个叫做 ExchangeRate 的 DP 里：

ExchangeRate 被定义为汇率对象，通过对金额计算逻辑 &各种校验逻辑封装，使原始代码变得简单：

public class ExchangeRate {
    private final BigDecimal rate;
    private final Currency from;
    private final Currency to;
    public ExchangeRate(BigDecimal rate, Currency from, Currency to) {
        this.rate = rate;
        this.from = from;
        this.to = to;
    }
    public Money exchange(Money fromMoney) {
        notNull(fromMoney);
        isTrue(this.from.equals(fromMoney.getCurrency()));
        BigDecimal targetAmount = fromMoney.getAmount().multiply(rate);
        return new Money(targetAmount, to);
    }
}
public void pay(Money money, Currency targetCurrency, Long recipientId) {
    ExchangeRate rate = exchangeService.getRate(money.getCurrency(), targetCurrency);
    Money targetMoney = rate.exchange(money);
    bankService.transfer(targetMoney, recipientId);

案例讲解

public class RegistrationServiceImpl implements RegistrationService {
    private final SalesRepMapper salesRepDAO;
    private final UserMapper userDAO;
    private final RewardMapper rewardDAO;
    private final TelecomRealnameService telecomService;
    private final RiskControlService riskControlService;

    public User register(String name, PhoneNumber phone) throws ValidationException {
        TelecomInfoDTO rnInfoDTO = telecomService.getRealnameInfo(phone.getNumber());
        if (!Objects.equals(name, rnInfoDTO.getName())) {
            throw new InvalidRelnameException();
        }
        // 计算用户标签
        String label = getLabel(rnInfoDTO);
        // 计算销售组
        String salesRepId = getSalesRepId(phone);
        // 构造User对象和Reward对象
        String idCard = rnInfoDTO.getIdCard();
        UserDO userDO = new UserDO(idCard, name, phone.getNumber(), label, salesRepId);
        RewardDO rewardDO = new RewardDO(idCard, label);

        // 风控逻辑
        if (!riskControlService.check(idCard, label)) {
            userDO.setNew(true);
            rewardDO.setAvailable(false);
        } else {
            userDO.setNew(false);
            rewardDO.setAvailable(true);
        }
        // 持久化数据
        rewardDAO.insert(rewardDO);
        return userDAO.insert(userDO);
    }

    private String getLabel(TelecomInfoDTO telecomInfoDTO) {
        // TODO
    }

    private String getSalesRepId(PhoneNumber phone) {
        SalesRepDO repDO = salesRepDAO.select(phone.getAreaCode(), phone.getOperatorCode());
        if (repDO != null) {
            return repDO.getRepId();
        }
        return null;
    }
}

常规逻辑和实现代码。我们先来给它挑挑刺，再利用领域驱动设计的思想来重构。发现

问题 1>> 对外部依赖的耦合非常严重

一切不属于当前域内的设施和服务，都可认为是外部依赖。比如：数据库，数据库 Schema，RPC 服务，ORM 框架，中间件…..并且都是可替换的。我们要做的是把由外部依赖变化导致的自己系统内发生的变动控制在最小范围。

“由外部依赖变化导致的内部系统的改造程度，我们可以理解为一个系统的可维护性。”

在检查这段代码的可维护性前，我们先来看看它有哪些外部依赖：

1-1、数据库 Schema

这里的业务代码强依赖数据库 schema，也就是 DO 类。一旦数据表的字段产生变动，DO 类就会随之变动。

但 DO 在这段代码里到处都是，并且将 UserDO 这个对象传递到了方法外部。一旦业务逻辑复杂起来、DO 发生变化，这段代码就会面目全非，甚至很可能会破坏掉原有正常的功能。

1-2、ORM 框架

此代码使用了大家熟悉的 MyBatis 框架：使用 Mapper 这种 DAO 对象来构建和执行 SQL。

如果框架本身没有向下兼容、API 产生了变化，系统要升级框架；或出于对安全问题的考虑，系统要替换整个 ORM 框架，业务代码要进行大量的变动。这是不合理且存在风险的。

1-3、RPC 服务

使用中国电信提供的手机号实名信息查询服务，强依赖在业务逻辑中。一旦中国电信提供的接口入参和返回都产生变动，或者变更服务商，那么业务逻辑代码也要进行相应的修改。说起来简单做起来难，建议抱有此想法的童鞋趁早放弃，不要给自己找锅背。

分析了以上三种依赖，大家已经了解了代码耦合度高的原因。如何改造？

思路：将其改造成面向抽象接口的编程。这样，DDD 将会作为一种指导思想辅助我们设计。

>> 针对数据访问抽象

有两个关键点：

1、DO 是具体实现，不应直接暴露给业务逻辑

2、DAO 作为访问数据库的具体实现

引入领域驱动设计中的 Entity 和 Repository。

上层的业务逻辑不需要关心下层的具体实现。

这里定义了一个 User 类—Entity，一种领域实体类。User 类中的属性用于描述这个系统内客户应该含有的信息，应尽量多的使用 DP 来将更多的自检和隐性属性内聚起来。

参照这句话「上层的业务逻辑不需要关心下层的具体实现」，在定义 User 类的时候，我们不关心下层数据库的具体实现、User 对象的存储在哪里，我们只需要关注如何去描述这个领域实体。

“有人可能会对 Entity 和 DP 的差别产生疑惑，它们最本质的差异就是主语义上能否拥有数据状态。”

Repository 就是数据访问的抽象层。在抽象层中，我们只定义动作。

比如这里的 UserRepository，只定义了 find 和 save 这两个动作，这样在实现类中，我们就可以依赖数据库访问相关的具体实现，然后，直接依赖 MyBatis 框架，比较 Redis Client 等各种数据库操作。

通过对数据访问层的改造，我们再来看业务代码，改造前：

// User Entity
public class User extends Entity {
    private UserId userId;
    private PhoneNumber phone;
    private Label label;
    private SalesRepId salesRepId;
    private SalesRepRepository salesRepRepository;

    public User(RealnameInfo info, String name, PhoneNumber phone) {
        // 参数一致性校验，若校验失败，则check内抛出异常（DP的优点）
        info.check(name);
        initId(info);
        labelledAs(info);
        this.salesRepId = salesRepRepository.ofPhone(phone).getRepId();
    }

    // 对this.userId赋值
    private void initId(RealnameInfo info) {

}

    // 对this.label赋值
    private void labelledAs(RealnameInfo info) {
        // 本地处理逻辑
    }
}

改造后：

public interface UserRepository {
    User ofId(UserId id);
    User ofPhone(PhoneNumber phone);
    User save(User user);
}
public class UserRepositoryImpl implements UserRepository {
    private final UserMapper userMapper;
    private final UserConverter userConverter;@Override public User ofId(UserId id) {
        UserDO userDO = userMapper.selectById(id.value());
        return userConverter.fromDO(userDO);
    }
    @Override 
    public User ofPhone(PhoneNumber phone) {
        UserDO userDO = userMapper.selectByPhone(phone.getNumber());
        return userConverter.fromDO(userDO);
    }
    @Override 
    public User save(User user) {
        UserDO userDO = userConverter.toDO(user);
        if (userDO.getId() == null) {
            userMapper.insert(userDO);
        } else {
            userMapper.update(userDO);
        }
        return userConverter.fromDO(userDO);
    }
}

>> RPC 调用抽象

这里主要有两块改动：

1、使用 RealnameService 接口类替代 TelecomRealnameService 具体实现类— 依赖倒置

2、DP 具体逻辑内聚：使用 RealnameInfo 这个 DP 来代替 TelecomInfoDTO 这个具体实现。这样无论外部服务是参数变化还是替换实现，我们都将变动范围控制在了具体实现类和配置文件内部，保证了核心业务逻辑的稳定。

这里还要引入一个概念：

“防腐层（Anticruption Layer）：防止外部系统的腐烂影响到我们自己的系统。这里的 RealnameService 就是我们的防腐层。”

代码如下：

public class RegistrationServiceImpl implements RegistrationService {
    private final SalesRepMapper salesRepDAO;
    private final UserMapper userDAO;
    private final RewardMapper rewardDAO;
    private final RealnameService realnameService;
    private final RiskControlService riskControlService;

    public User register(String name, PhoneNumber phone) throws ValidationException {
        RealnameInfo realnameInfo = realnameService.get(phone);
        realnameInfo.check(name);

        // 计算用户标签
        String label = getLabel(rnInfoDTO);
        // 计算销售组
        String salesRepId = getSalesRepId(phone);
        // 构造User对象和Reward对象
        String idCard = realnameInfo.getIdCard();
        UserDO userDO = new UserDO(idCard, name, phone.getNumber(), label, salesRepId);
        RewardDO rewardDO = new RewardDO(idCard, label);

        // 风控逻辑
        if (!riskControlService.check(idCard, label)) {
            userDO.setNew(true);
            rewardDO.setAvailable(false);
        } else {
            userDO.setNew(false);
            rewardDO.setAvailable(true);
        }
        // 持久化数据
        rewardDAO.insert(rewardDO);
        return userDAO.insert(userDO);
    }
}

问题 2 >> 逻辑混乱

public class RegistrationServiceImpl implements RegistrationService {
    private final UserRepository userRepository;
    private final RewardRepository rewardRepository;
    private final RealnameService realnameService;
    private final RiskControlService riskControlService;

    public User register(String name, PhoneNumber phone) {
        // 查询实名信息
        RealnameInfo realnameInfo = realnameService.get(phone);

        // 构建对象
        User user = new User(realnameInfo, phone);
        Reward reward = new Reward(user);

        // 检查风控
        if (!riskControlService.check(user)) {
            user.fresh();
            reward.inavailable();
        }
        // 持久化
        rewardRepository.save(reward);
        return userRepository.save(user);
    }
}

Register 方法的语义，只是注册。在最初的代码中， Register 方法中已经耦合了许多不属于「注册」这个业务域需要关心的逻辑，这为后边的业务修改无形中增添了不少工作量。

“由内部业务逻辑变化所导致的内部系统的改造程度，我们可以狭义的理解为系统的可扩展性”

回到这个例子，注册的外部逻辑已经进行了一定程度的解耦，但它依然不纯粹：「奖品对象」和「风控检查」为什么会耦合在注册逻辑中呢？如果，之后的发奖逻辑产生变动，注册方法还要修改吗？……

我们继续思考：

• 发奖是为了给予新用户一些福利，本质是判断当前用户是否为新用户
• 在注册这个业务域中，我们将它的行为抽象为「获取用户信息」，「检查并更新用户」，「存储用户信息」，这三个步骤不无不合理之处
• 在「检查并更新用户」这个逻辑中，存在发奖这种衍生行为与其他可能的行为

理清逻辑后，我们来看下最终代码：

public interface CheckUserService {
    void check(User user);
}

public class CheckUserServiceImpl implements CheckUserService {
    private final RiskControlService riskControlService;
    private final RewardRepository rewardRepository;

    @Override public void check(User user) {
        rewardCheck(user);
        // ...
        // 可能存在的其他逻辑
    }

    private void rewardCheck(User user) {
        Reward reward = new Reward(user);
        // 检查风控
        if (!riskControlService.check(user)) {
            user.fresh();
            reward.inavailable();
        }
        rewardRepository.save(reward);
    }
}

这里需要注意一点：CheckUserService 中进行检查时，可能会改变 User 对象和 Reward 对象的状态，涉及到了多个 Entity 状态改变的服务，被称为 Domain Service。Domain Service 主要用于封装多 Entity 或跨业务域的逻辑。

根据最终的代码块显示，核心逻辑已清晰，可维护性和可扩展性也大大增强 √

来说下单元测试

改造前的代码，多个业务逻辑耦合在一起；

改造后的代码，通过对业务逻辑的解耦，测试用例变得更容易维护。

随时间推移，迭代增多，单元测试会花费更少的精力，获得更高的单元测试覆盖率。这就是逻辑内聚 &解耦给单元测试所带来的好处。

代码改造前：

代码改造后：

归纳概念 

>> DP

：抽象并封装自检和一些隐性属性的计算逻辑，这些属性是无状态的

>> Entity

：抽象并封装单对象有状态的逻辑

>> Domain Service

：抽象并封装多对象的有状态逻辑

>> Repository

：抽象并封装外部数据访问逻辑

>> 领域驱动设计的指导思想：

• 首先对业务问题进行总览
• 然后对领域对象-Entity 进行划分，明确每个领域对象包含的信息和职

• 责边界，进行跨对象，多对象的逻辑组织-Domain Service
• 接着在上层应用中根据业务描述去编排-Entity & Domain Service
• 最后做一些基础设施工作：对下层的数据访问，RPC 调用去做一些具体实现

值得说明的一点是：在实践工作过程中，DDD 只是对我们进行一种指导，我们不必按部就班，全盘照抄上述这种设计规范，但要遵循「高内聚低耦合」的思想，对边界的划分与控制是领域驱动设计强调的核心思想。

架构

DDD 的一大好处是它不需要使用某些特定的架构。

由于核心域位于限界上下文中，我们可以在整个系统中使用多种风格的架构。有些架构包围着领域模型，能够全局性地影响系统;有些架构满足了某些特定的需求。我们的目标是选择适合自己的架构和架构模式。

这里我们简单的介绍两种在 DDD 落地过程中比较实用的架构风格：

>> Clean Architecture

目标：框架无关、可测试、UI 无关、数据库无关、外部代理无关

>> COLA Architecture

COLA 代表了简洁的业务思想：

1、COLA 是一种架构思想，是整合了洋葱圈架构、适配器架构、DDD、整洁架构、TMF 等架构思想的一种应用架构；2、 COLA 也是框架组件。

应用架构的本质，就是要从繁杂的业务系统中提炼出共性，找到解决业务问题的最佳模式，为开发人员提供统一的认知，治理混乱。“从混乱到有序”=定义良好的应用结构，提供最佳实践。

领域驱动设计入门与实践「上 &下」至此完结。全文作者：nerd4me ，一枚优秀的程序员小编~