华为的成功,你也可以复制!

举报
IPD产品研发管理 发表于 2024/06/28 10:38:32 2024/06/28
【摘要】 让别人的经验成为自己的经验,就可以让别人的成功变成自己的成功。

记得很久之前,听朋友说过一次出差“奇”旅:他当时在北京出差,需要从地铁站中转一下再去机场。

在转站的过程中,就跑呀跑,一边跑一边想:北京的地铁,怎么台阶这么高、这么长。最重要的是,完全没有扶梯

他后来转念一想,这么大的地铁站,不装扶梯完全不合理,于是开始给12345打电话,反映这个情况。

惊喜的是,在1个小时内,12345那边就找到了北京地铁的相关方给出了回复。

地铁方的回复内容大意是:地铁内其实是有直梯的,可能路标引导稍弱,导致大家无法第一时间找到直梯,接下来,他们会在地铁站内的各个位置摆放一些比较显眼的引导,减少这类问题的发生huawei-issue-to-resolved-8.jpg

晚些时候,12345也对他进行了一次回访,主要目的是咨询这单反馈的处理流程,反馈人是否满意等等。

不管是朋友还是听了这个故事的我,都有一个很清晰的共识:地铁方可能不会因为某个人的几句反馈或抱怨就立马进行大幅改造,毕竟地铁会有自己的既定规划。但他们能及时给到反馈,且态度认真诚恳,这一点其实是最打动人的。

对朋友来说,虽然他不常在北京,但这种处理方式让他对北京这座城市又增添了一些好感度。

说到这了,就不得不提前段时间他身上发生的一件糟心事:趁着母亲节活动,朋友网购了一件东西,不幸的是,收到货后发现这件商品已经坏了。于是便开启了漫长而艰难的投诉之旅——快递方说是发货的问题,商家说是运输的问题。双方互相推诿,只苦了消费者这个皮球在中间被踢来踢去。最终的处理办法是,让平台客服介入,而的朋友态度则是不关注过程,只要一个处理结果。

两种情况、两种问题,得到的却是两种截然不同的处理态度。很明显,前者的问题解决机制更为有效,也更让人舒服。

事实上,不论是产品使用,还是一次出行,或是一次温馨的聚餐,当过程中出现各种无法预料的意外或失误时,高效的问题解决机制尤为重要。

在这篇文章中,我们要深入了解的是ITR(Issue to Resolution)流程,一个由华为提出的客户服务体系构建方法和管理流程。


一、问题发生到解决

ITR(Issue to Resolution)流程,也叫问题到解决流程,是华为三大业务流程(IPD-产品集成开发、LTC-线索到回款、ITR-问题到解决)体系之一。这一流程旨在以客户为中心,打通从问题发现、反馈到问题解决的完整服务过程,以端到端的方式打造服务闭环。

它涉及反馈的提交、评审、分发、跟踪和验证,直至最终关闭反馈等各个阶段。流程的目的是快速响应并解决客户或运维人员提出的问题,从而提高客户满意度和运维效率。


二、ITR流程的提出

在发展初期,华为面临着很多已经非常成熟强大的对手,如诺基亚、爱立信、摩托罗拉等。这些西方的巨头,他们的产品、技术等各方面都很完善。对初建的华为来说,要怎样才能从他们手里争下一份蛋糕呢?

事情的转机出现了。有一个客户以前和爱立信合作,现在开始寻求新的合作商。由于爱立信是一家瑞典公司,周六周天不上班,因此当产品出现一些问题时,客户这边无法得到及时的服务响应。在这个背景下,华为凭借24小时的问题响应服务,成功地让该客户由爱立信转向华为。

对客户来说,一个高效、及时的问题响应与解决流程,也许就是影响决策的关键因素。


三、ITR流程的挑战与解决

搭建公司自己的ITR流程时,一般会有以下几个步骤:

  1. 用户、运维、市场等人员提出问题后,及时创建反馈;
  2. 专人进行评审反馈是否合理、有效;
  3. 评审通过的反馈进行分发,需要有指定人员进行解决、处理;
  4. 及时跟进反馈状态与阶段;
  5. 验证反馈是否得到解决、解决方案是否满意;
  6. 关闭反馈。

虽然看似简单,但在实际应用中,ITR流程往往也面临着很多挑战,比如:反馈跟踪困难、处理流程长、等待时间长和反馈分发等问题。

接下来,想跟大家分享一下禅道团队的ITR流程是怎样的。

huawei-issue-to-resolved-1.jpg

首先,无论是客户还是运维人员发现问题后,客户侧同事会判断问题是否之前出现过。若是已知问题,会直接回复客户答案或解决方案。若问题是新发生的,则会在禅道中记录,由产品经理评审反馈的合理性与描述的清晰度。合理且清晰的反馈,会进入处理流程,产品经理接下来会考虑该反馈的考虑解决方案,并可能将反馈转换为工单、Bug、用户需求或研发任务。

huawei-issue-to-resolved-2.jpg

具体处理方式取决于反馈的类型和紧急程度

  • 若反馈为紧急需求或紧急Bug,但影响的是某一个或某几个特定客户,通常会转换为工单,以便快速解决影响客户流程的问题;若反馈的是较为通用的紧急需求或Bug,一般转换为任务或Bug。
  • 在考虑需求紧急程度的维度中,一般紧急的需求会转为工单,普通需求转化为研发需求或用户需求。

同样,需求的清晰度也会影响处理方式,因为客户提出的可能仅是初步想法,需产品经理细化、拆分后才能进入研发阶段。

在做完反馈的流转后,接下来,又将由哪些人员负责跟进处理呢?在禅道团队中,具体划分为以下四个小组:

huawei-issue-to-resolved-3.jpg

  • 第一个是通用产品研发小组,主要负责通用产品的需求实现以及Bug解决。通用产品研发小组采用敏捷开发的方式,且周期也较为固定,一般按照两周一个迭代的节奏交付,最终交付物是通用产品的版本。
  • 除通用产品需求外,还会有一些比较小众的研发需求。这里会有一个小众需求开发小组,同样采用敏捷开发的方式。由于小众需求量较少,处理周期也较短,迭代节奏是一周一迭代,最终交付物为插件或功能包。
  • 对不同的客户来说,通用版本可能无法满足各种特定需求。因此,禅道成立了定制开发小组,主要负责定制需求的实现和Bug解决。定制开发小组的开发模式一般是融合瀑布模型,最终交付物是定制版本。
  • 最后,禅道也成立了应急响应小组,主要负责处理非常紧急,需要立刻响应客户、给出解决方案的问题。应急响应小组的处理方案一般为工单,采用看板的开发方式。在应急响应小组中,没有固定的周期开发,通常是以小时为单位做估算,最终交付物为补丁或插件等。

这便是禅道的反馈跟踪矩阵。

huawei-issue-to-resolved-4.jpg

四、具体的ITR流程在禅道中应如何落地?

在禅道中,有一个反馈模块,客户可以通过反馈模块来条目化地管理问题和反馈,还可以通过工作流功能自定义公司实际的反馈流程。

huawei-issue-to-resolved-5.jpg

在跟踪、监控反馈的过程中,也可以通过禅道的BI模块,了解现阶段的反馈响应速度等情况

huawei-issue-to-resolved-6.jpg

五、应急响应小组的工程实践

huawei-issue-to-resolved-7.jpg

在之前的反馈处理流程中,获取到一个反馈后,产品经理会依据反馈的紧急程度和适用群体,转为工单,并指派给应急响应小组。此时,应急响应小组会根据工单的基本信息,进行相应的环境搭建,进行问题修复,再以补丁或插件的形式交付给客户。

整个修复过程会耗时1~2小时,这种时长对紧急程度高的工单而言,效率较低。因此,应急响应小组编写了两个脚本来自动化流程:一是环境配置,只需输入版本号,脚本便能自动完成版本信息的提供、下载、替换加密文件、获取授权文件以及环境搭建,整个过程仅需约15秒;二是自动打包,研发人员在编码完成后只需提供版本信息和反馈ID,脚本便能自动完成打包、编写描述文件、压缩和加密,整个过程约需40秒。

这些脚本的应用显著提高了应急响应小组的工单处理速度,原本需耗时一小时的流程现在不到一分钟就能完成。处理完毕后,程序还会自动将打包文件推送到通讯工具中,供相关人员下载。这一自动化工程实践不仅提高了问题解决的效率,还减少了重复性工作,极大地缩短了问题响应解决时间。

由此出发,客户满意度的提高也不是什么稀罕事了。

对每一个公司来说,在如今的经济下行期,也许ITR(从问题到解决)流程会变得至关重要。华为打造的ITR流程,或许就是复制华为成功经验的绝佳路径。

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。