Liga妙谈 | 如何快速甄别、高效响应用户反馈?

敏捷开发说要「拥抱变化」,在充满不确定的环境中,唯一不变的正是变化。面对源源不断的市场反馈和需求变更,敏捷团队应该如何平衡「高效迭代」与「响应用户」的关系,既快又好地完成研发任务,交付业务价值?

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-新一代智能研发协作平台,在线申请体验我们的产品。

你可能感兴趣的:(Liga妙谈 | 如何快速甄别、高效响应用户反馈?)