共计 5451 个字符，预计需要花费 14 分钟才能阅读完成。
麻利开发说要「拥抱变动」，在充斥不确定的环境中，惟一不变的正是变动。面对源源不断的市场反馈和需要变更，麻利团队应该如何均衡「高效迭代」与「响应用户」的关系，既快又好地实现研发工作，交付业务价值？
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 般的麻利践行者也将继续以更优良的产品与服务，助力每一位踏上麻利转型之路的敌人，成就麻利。
理解更多麻利开发、项目管理、行业动态等音讯，关注咱们的 sf 账号 -LigaAI~ 或者点击 LigaAI- 新一代智能研发合作平台，在线申请体验咱们的产品。
