敏捷开发说要「拥抱变化」，在充满不确定的环境中，唯一不变的正是变化。面对源源不断的市场反馈和需求变更，敏捷团队应该如何平衡「高效迭代」与「响应用户」的关系，既快又好地完成研发任务，交付业务价值？
12 月 21 日，LigaAI 特别策划了「敏捷三人行」直播活动，与优普丰首席敏捷教练申健、乐豆信息 (Beansmile) 创始人杜立刚 (Leon) 一起探讨、分享并总结了快速识别高价值反馈、高效响应用户需求的经验之道。直播全程高能，金句频出，下面就随 LigaAI 一起回顾精彩内容吧！
01 找准「话语权」，让事情更顺利
主持人：任何形态的软件产品一旦面世，就会面对各种各样的用户反馈。B 端产品和 C 端产品在反馈关注点和处理流程上，都有哪些差异？
????LigaAI - 张思： 产品发布上线后，用户反馈是了解客户的重要渠道。B 端产品和 C 端产品在反馈的处理流程上没有表现出明显的差异性，大致环节是「收集 - 整理分类 - 优先级筛选 - 转化 - 计划上线和发布」。
但从业务特性来看，C 端产品注重打造产品「爽点」，让用户获得极致的用户体验。因此，C 端产品的用户反馈整体呈现更多的个性化和天马行空，也更符合个人用户的使用习惯；
而 B 端产品的最大目标通常是赋能客户更加成功，因此用户反馈更加关注产品对目标企业/客户的整体价值。它们围绕业务目标展开，目的性和业务属性会更强。
????Beansmile - Leon： 我也赞同思哥的说法。整体看来，B 端产品的规则更明确，处理反馈时闪转腾挪的空间相对较小；而 C 端产品通常极富创新性，其业务发展和法规监管有更强的探索性 。
我们之前服务过一个金融行业客户，同期需要交付 To B 和 To C 两个产品。B 端产品面向各大金融机构，受到证券、基金投资等行业法律法规的约束，几乎不太能在规则上探索，研发过程最大要求就是保证功能稳定、数据安全、逻辑正确；
而面向个人理财的 C 端产品有许多内容可以一边做，一边调整、逐步完善。相比成熟的 B 端产品，更具创新的 C 端产品可以逐步参考行业头部企业的做法，总结分析后再制定，这是一个比较明显的差异。
????优普丰 - 申导 ： 我也想从决策角度补充一点。C 端产品的购买决策是短决策链的个体决策，通过打击用户「痛点」和「爽点」，激发用户为产品和体验付费的冲动与欲望。
而 B 端产品的决策复杂度则更高：决策路径通常很长，而且不同环节的决策负责人通常不一样，他们的决策影响力也不尽相同。因此只有找到决策链上的「关键强节点」，识别他们的真正需求，才能让事情更顺利。
主持人：谈到决策复杂度，就少不了要提「决策权」。在敏捷团队中，面对海量的用户反馈，谁具有对用户反馈拍板定案的决策权？
????LigaAI - 张思： 在 LigaAI，用户反馈的处理通常由产品负责人 (PO) 或者产品经理 (PM) 主导。他们会与客户成功 (CSM) 伙伴一起，共同评估和分析用户反馈的具体内容、价值排序，以及同当前目标的整体匹配度，综合多个因素完成判断和处理。
????Beansmile - Leon： 对于纯交付类的客户项目，我们最重要的任务就是找准有决策权和最终影响力的产品负责人 (PO) 。他们通常是企业老板或者高级负责人，能对产品的投入产出比负责，具有接纳或拒绝需求的能力和魄力。
如果是技术入股的项目，我们更注重于维护技术自主权。在挑选合作伙伴时，我们更倾向于选择 理解技术、愿意为技术放权、不干涉技术或研发过程的伙伴，以此避免过程中不合理的时间线或者产品路径加重研发负担。
????优普丰 - 申导 ： 在敏捷开发里，产品负责人之所以称为 Product Owner，是因为他们天然要承担决策拍板权 (Ownership)。
好几年前，我与朋友一起参加一个 O2O 创业项目。第一次开会面议时，我发现朋友和甲方领导都不太懂技术，于是我花了一些时间跟甲方领导介绍互联网的玩法和 O2O 产品。领导听了觉得很不错，我便乘胜追击地说：“要不这个产品您就听我的？”结果对方答应了。这样，我将原本属于甲方的决策责任，经过授权，揽到了乙方身上，让研发过程顺利很多。
理论上，B 端产品的反馈决策权一般只在（最）高级负责人身上。许多与我们直接联系的产品负责人或者项目经理，他们不一定拥有最终拍板权，而找不到项目中真正的「话事人」也会导致项目最终推倒重来。
02 提出反馈的人，往往不清楚自己想要什么
主持人：刚刚三位都提到用户反馈过程中产品负责人 (PO) 的重要性。在应对海量的用户反馈时，PO 该如何透过反馈，洞察真正的用户需求？
????LigaAI - 张思 ： 用户的反馈总是很主观。想要找到用户的真实需求，便要求产品负责人对客户群体、行业模式、具体的消费场景和使用场景有较深的理解 ，才能对充满随机性的用户反馈做出相对准确的判断。
用户反馈总会指向一个「问题」，传递的信息是「用户需要什么」和「希望产品如何解决问题」。产品负责人需要根据已知的信息，提供一个良好的解决方案。在理解和分析反馈时，一定要深挖问题背后的原因，区分「Want」和「Need」的区别，找到用户完成目标的路径中真正「Need」的部分，才能洞悉有效的用户需求。
具体的做法是，基于对客户和业务的整体理解，多问自己「为什么」。产品负责人经过反问和反推，逐步整理出用户反馈背后更深层的原因；当出现明确的可验证想法，再进一步与用户对话，探索更多方案的可行性。
????Beansmile - Leon ： 一个很有意思的现象是，很多提出反馈的用户往往不清楚自己想要什么，而初级的产品经理则很容易被这些信息误导。就像几乎所有主流的视频会议软件都默认带有视频美颜功能。尽管没有用户会明确指出自己需要美颜，但他们都不会拒绝美颜带来的更好的视觉效果。
而同样的功能发生在另一个场景，则完全不一样。一个受伤的用户想将伤口拍下，上传供互联网医生诊断，而手机自带的不可关闭的相机磨皮功能，却将疤痕完全磨平了。这个场景中，用户就无法达成自己的目的。
不难看出，想要透过用户反馈，了解背后真正的需求，关键在于理解业务、理解场景、理解人性。需求分析人员需要具备相当的同理心和换位思考能力，才能以更真实的用户视角考虑使用场景，设计出优秀的产品和功能。
????优普丰 - 申导： 用户洞察是相对复杂的事情。有的用户嘴上说的是 A，脑子里想的是 B，潜意识里想要 C。中国有句老话，听话听音。我自己也一直在研究，如何更好地洞悉人的诉求和意图。总结下来主要有三点。
第一，学会观察和倾听，只有静下来才能听进去别人在说什么。产品负责人不能沉浸在自己的想法世界里，而是应该在拿出可验证的产品测试之前，安静且专注地做好用户调研，观察用户行为，了解真实状态下的用户表现。
第二，正如 Leon 提到的，关注人性。人性就是最基本的需要，七宗罪、贪嗔痴、酒色财气这些都是人性。有的用户反馈和需求为业务服务，也有的仅为了面子工程存在。产品负责人需要在历练中积攒和沉淀，你必须见识过很多的场景，才能洞察反馈背后反映出来的「真需求」。
第三，借用乔布斯的一句名言：不要听用户的，因为他们不知道自己想要什么。
主持人：敏捷团队如何通过分工协作，将源源不断的用户反馈转换为迭代中的用户故事？
????优普丰 - 申导 ： 「用户故事」顾名思义是从用户角度讲故事：通过对场景、人物和事件的描述，试图找出用户诉求背后真正的、感性的、情绪性的需求意图。使用简单的「Who - What - Why」三段式结构，讲清楚待完成的特性或功能、背后的价值，以及为什么要实现这个功能。
国内有一些团队会僵化地使用用户故事，认为过去写 PRD 文档，现在就写用户故事文档。这是错误的。用户故事的作用是让大家交流和思考需求所提的场景里面有谁，要做什么以及意图是什么。 所以，技术团队不要着急跳进解决方案里，要先研究清楚需求意图，这个特别重要。
用户故事通过更频密的对话达成团队内部的一致，消除不同角色的理解差异。从用户反馈到用户故事，一般会使用三个思考框架。
首先是业务问题域的影响力地图 (Impact Mapping)，它可以帮助团队挖掘原始的需求。具体的做法是，从业务目标开始找到目标用户，找准用户痛点和产品价值点，最后为此提供解决方案。
第二，利用解决方案域的用户故事地图 (User Story Mapping) ，将交谈中产生的用户故事拆分、归类、简单排期，帮助团队找到真实需求全貌，并查漏补缺。
第三是技术实现域的产品待办列表 (Product Backlog) 和迭代待办列表 (Sprint Backlog) 。 落到具体的实现层面，就必须有先后顺序，所以我们需要待办列表将排队过程落地，将地图式的二维信息，转变为列表式的一维信息。
????Beansmile - Leon ： 与合作方一起挖掘用户故事时，我们喜欢使用「电影制作」做场景类比。软件定制研发就像是双方合作制作一部电影，讨论阶段就是在研讨剧本：故事需要涉及哪些角色、他们分别有哪些故事、需要做什么、每个角色在具体场景中的使命是什么……
通过将用户故事总结、罗列出来后，我们就能将很多细节信息研究清楚，比如不同角色的管理权限、不同故事场景的具体操作和限制条件等等。在聊天中，一步步引导合作方「聊」出更多的细节，识别更多的关键路径，后续的研发工作才会顺利。
还有一点比较重要，也是敏捷开发里强调的 「Deploy Early, Deploy Often」——早点部署，频繁交付。我们发现相比 Staging 环境，部署到 Prod 环境的交付成果，客户关注得更多。因此，可以早一点将功能放到 Prod 环境里跑，尽早地让客户看到、体验到实际的产品。
????LigaAI - 张思 ： 我们在处理小型需求和反馈时，经常使用待办列表工具进行排期和排序。除了申导提到的三种框架外，LigaAI 团队还会使用 JTBD 理论 (Job To Be Done) 分析用户故事。
JTBD 理论指出，用户使用一款产品，本质上是为了达成一个工作目标。因此，在 LigaAI 团队中，我们会逐级拆解用户要实现的「大目标」，及若干个指向最终目标的小工作 (Job) 。这个我们有个标准的协作流程：
并且在这个流程中，我们和很多 LigaAI 的客户都用上了 LigaAI 的智能助理、跨项目流转等自动化工具。比方说：从提交反馈 - 分析设计 - 迭代排期 - 开发上线 - 用户通知，全流程通过机器人自动推送、实现无缝衔接；避免了沟通中的信息差和时间差，让整个团队能够基于对用户反馈的共识，快速推进迭代开发。
另外，我也非常赞同 Leon 提到的应该「尽早部署，频繁交付」。LigaAI 团队在研发过程会使用 MVP (Minimum Viable Product) ，尝试先将一些 MVP 功能实现交付，让客户提前体验；再根据客户的反馈意见，做进一步的完善和优化，逐步交付更大的价值。
03 只有变化，是唯一不变的
主持人：今天的三位嘉宾都（曾）是技术团队的负责人。那么在管理角度，敏捷团队应该如何打造积极拥抱变化、快速响应变化的团队文化？
????LigaAI - 张思 ： 对任何团队而言，人都是最重要的。想 让研发团队适应敏捷，就一定需要打造信息流通、自主交流的团队氛围。 让团队内部自然地形成协作的默契，一起拥抱变化，这是团队建设的大前提。常规的团建活动、内部分享或者非正式会谈，都是比较好的低负担的文化建设手段。
第二，敏捷团队的管理者需要为团队提供更多赋能的后勤保障和支援。 在适当的时候，提供敏捷方法论的指导，保障物理层面的需求。
????Beansmile - Leon ： 打造拥抱变化和快速响应变化的团队文化，可以从思维方式和技术操作两个层面入手。
首先，大家一定要意识到，变化是永远不变的。尤其是交付型团队，几乎没有任何一个客户的需求是一成不变的。所以，敏捷团队要从观念上接受变化，才能真的拥抱变化。
其次， 产品负责人要做好预期管理，包括调节需求、把控进度等想法。不要试图向客户传递要创造鸿光伟业的想法，尽量将产品预期压低，务实一些，将研发过程持续维护在可控的范围内。
比如，通过每日站会将风险粒度最小化、使用量化手段监控成员的工时或者点数、将子任务拆细更清晰地完成过程管理。 只有当可量化的研发工作经受得起每日的定期同步，过程管理才不容易出错。
风险始终存在，我们不能消灭风险，但是可以控制风险的粒度。在技术操作层面，建立严格的 Code Review 标准，应用 CI/CD 等自动化部署工具，介入人工测试等等，也可以在一定程度保障团队拥抱变化的能力和信心。
????优普丰 - 申导： 在软件开发领域，敏捷开发为变化而生。在充满创造性和探索性的工作中，我们要不断地验证，不断地拿产品说话。拥抱变化也不是一蹴而就的事情，也要在不断地磨合和迭代优化中，逐步验证更好的方式。
第二，技术管理者要充分发挥「培养人」的职责，把团队发展起来。 培养成员的心智、认知领导力和拥抱变化的勇气，不断地磨炼、打造一个更加敏捷的团队。
中层管理*打造自组织团队的关键在于不断地磨炼成员，手把手带领成员成长；而中层管理者的成长则要亲自接受市场和客户的打击与挑战，亲临实地地了解市场和客户需求。管理者必须自己经历风暴，才能快速成长。
随着组织走向成熟，团队规模不断扩大，外部与内部变化也将生生不息，没有休止。敏捷团队只有拥抱变化、快速响应变化，才能在变化中找到组织稳步发展的生存之路，否则就会被市场和竞争淘汰。
而在一次次拥抱变化与响应变化的敏捷实践中，如同优普丰和 LigaAI 般的敏捷践行者也将持续以更优秀的产品与服务，助力每一位踏上敏捷转型之路的朋友，成就敏捷。
了解更多敏捷开发、项目管理、行业动态等消息，关注我们 LigaAI@oschina 或点击LigaAI - 新一代智能研发协作平台，在线申请体验我们的产品。