华为的成功,你也可以复制
2024/7/16 6:02:59
本文主要是介绍华为的成功,你也可以复制,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
记得很久之前,听朋友说过一次出差“奇”旅:他当时在北京出差,需要从地铁站中转一下再去机场。
在转站的过程中,就跑呀跑,一边跑一边想:北京的地铁,怎么台阶这么高、这么长。最重要的是,完全没有扶梯!
他后来转念一想,这么大的地铁站,不装扶梯完全不合理,于是开始给12345打电话,反映这个情况。
惊喜的是,在1个小时内,12345那边就找到了北京地铁的相关方给出了回复。
地铁方的回复内容大意是:地铁内其实是有直梯的,可能路标引导稍弱,导致大家无法第一时间找到直梯,接下来,他们会在地铁站内的各个位置摆放一些比较显眼的引导,减少这类问题的发生。
晚些时候,12345也对他进行了一次回访,主要目的是咨询这单反馈的处理流程,反馈人是否满意等等。
不管是朋友还是听了这个故事的我,都有一个很清晰的共识:地铁方可能不会因为某个人的几句反馈或抱怨就立马进行大幅改造,毕竟地铁会有自己的既定规划。但他们能及时给到反馈,且态度认真诚恳,这一点其实是最打动人的。
对朋友来说,虽然他不常在北京,但这种处理方式让他对北京这座城市又增添了一些好感度。
说到这了,就不得不提前段时间他身上发生的一件糟心事:趁着母亲节活动,朋友网购了一件东西,不幸的是,收到货后发现这件商品已经坏了。于是便开启了漫长而艰难的投诉之旅——快递方说是发货的问题,商家说是运输的问题。双方互相推诿,只苦了消费者这个皮球在中间被踢来踢去。最终的处理办法是,让平台客服介入,而的朋友态度则是不关注过程,只要一个处理结果。
两种情况、两种问题,得到的却是两种截然不同的处理态度。很明显,前者的问题解决机制更为有效,也更让人舒服。
事实上,不论是产品使用,还是一次出行,或是一次温馨的聚餐,当过程中出现各种无法预料的意外或失误时,高效的问题解决机制尤为重要。
在这篇文章中,我们要深入了解的是ITR(Issue to Resolution)流程,一个由华为提出的客户服务体系构建方法和管理流程。
一、问题发生到解决
ITR(Issue to Resolution)流程,也叫问题到解决流程,是华为三大业务流程(IPD-产品集成开发、LTC-线索到回款、ITR-问题到解决)体系之一。这一流程旨在以客户为中心,打通从问题发现、反馈到问题解决的完整服务过程,以端到端的方式打造服务闭环。
它涉及反馈的提交、评审、分发、跟踪和验证,直至最终关闭反馈等各个阶段。流程的目的是快速响应并解决客户或运维人员提出的问题,从而提高客户满意度和运维效率。
二、ITR流程的提出
在发展初期,华为面临着很多已经非常成熟强大的对手,如诺基亚、爱立信、摩托罗拉等。这些西方的巨头,他们的产品、技术等各方面都很完善。对初建的华为来说,要怎样才能从他们手里争下一份蛋糕呢?
事情的转机出现了。有一个客户以前和爱立信合作,现在开始寻求新的合作商。由于爱立信是一家瑞典公司,周六周天不上班,因此当产品出现一些问题时,客户这边无法得到及时的服务响应。在这个背景下,华为凭借24小时的问题响应服务,成功地让该客户由爱立信转向华为。
对客户来说,一个高效、及时的问题响应与解决流程,也许就是影响决策的关键因素。
三、ITR流程的挑战与解决
搭建公司自己的ITR流程时,一般会有以下几个步骤:
用户、运维、市场等人员提出问题后,及时创建反馈;
专人进行评审反馈是否合理、有效;
评审通过的反馈进行分发,需要有指定人员进行解决、处理;
及时跟进反馈状态与阶段;
验证反馈是否得到解决、解决方案是否满意;
关闭反馈。
虽然看似简单,但在实际应用中,ITR流程往往也面临着很多挑战,比如:反馈跟踪困难、处理流程长、等待时间长和反馈分发等问题。
接下来,想跟大家分享一下禅道团队的ITR流程是怎样的。
首先,无论是客户还是运维人员发现问题后,客户侧同事会判断问题是否之前出现过。若是已知问题,会直接回复客户答案或解决方案。若问题是新发生的,则会在禅道中记录,由产品经理评审反馈的合理性与描述的清晰度。合理且清晰的反馈,会进入处理流程,产品经理接下来会考虑该反馈的考虑解决方案,并可能将反馈转换为工单、Bug、用户需求或研发任务。
具体处理方式取决于反馈的类型和紧急程度:
若反馈为紧急需求或紧急Bug,但影响的是某一个或某几个特定客户,通常会转换为工单,以便快速解决影响客户流程的问题;若反馈的是较为通用的紧急需求或Bug,一般转换为任务或Bug。
在考虑需求紧急程度的维度中,一般紧急的需求会转为工单,普通需求转化为研发需求或用户需求。
同样,需求的清晰度也会影响处理方式,因为客户提出的可能仅是初步想法,需产品经理细化、拆分后才能进入研发阶段。
在做完反馈的流转后,接下来,又将由哪些人员负责跟进处理呢?在禅道团队中,具体划分为以下四个小组:
第一个是通用产品研发小组,主要负责通用产品的需求实现以及Bug解决。通用产品研发小组采用敏捷开发的方式,且周期也较为固定,一般按照两周一个迭代的节奏交付,最终交付物是通用产品的版本。
除通用产品需求外,还会有一些比较小众的研发需求。这里会有一个小众需求开发小组,同样采用敏捷开发的方式。由于小众需求量较少,处理周期也较短,迭代节奏是一周一迭代,最终交付物为插件或功能包。
对不同的客户来说,通用版本可能无法满足各种特定需求。因此,禅道成立了定制开发小组,主要负责定制需求的实现和Bug解决。定制开发小组的开发模式一般是融合瀑布模型,最终交付物是定制版本。
最后,禅道也成立了应急响应小组,主要负责处理非常紧急,需要立刻响应客户、给出解决方案的问题。应急响应小组的处理方案一般为工单,采用看板的开发方式。在应急响应小组中,没有固定的周期开发,通常是以小时为单位做估算,最终交付物为补丁或插件等。
这便是禅道的反馈跟踪矩阵。
四、具体的ITR流程在禅道中应如何落地?
在禅道中,有一个反馈模块,客户可以通过反馈模块来条目化地管理问题和反馈,还可以通过工作流功能自定义公司实际的反馈流程。
在跟踪、监控反馈的过程中,也可以通过禅道的BI模块,了解现阶段的反馈响应速度等情况。
五、应急响应小组的工程实践
在之前的反馈处理流程中,获取到一个反馈后,产品经理会依据反馈的紧急程度和适用群体,转为工单,并指派给应急响应小组。此时,应急响应小组会根据工单的基本信息,进行相应的环境搭建,进行问题修复,再以补丁或插件的形式交付给客户。
整个修复过程会耗时1~2小时,这种时长对紧急程度高的工单而言,效率较低。因此,应急响应小组编写了两个脚本来自动化流程:
一是环境配置,只需输入版本号,脚本便能自动完成版本信息的提供、下载、替换加密文件、获取授权文件以及环境搭建,整个过程仅需约15秒;
二是自动打包,研发人员在编码完成后只需提供版本信息和反馈ID,脚本便能自动完成打包、编写描述文件、压缩和加密,整个过程约需40秒。
这些脚本的应用显著提高了应急响应小组的工单处理速度,原本需耗时一小时的流程现在不到一分钟就能完成。处理完毕后,程序还会自动将打包文件推送到通讯工具中,供相关人员下载。这一自动化工程实践不仅提高了问题解决的效率,还减少了重复性工作,极大地缩短了问题响应解决时间。
由此出发,客户满意度的提高也不是什么稀罕事了。
对每一个公司来说,在如今的经济下行期,也许ITR(从问题到解决)流程会变得至关重要。华为打造的ITR流程,或许就是复制华为成功经验的绝佳路径。
这篇关于华为的成功,你也可以复制的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2024-08-24DDD精粹速读(二)
- 2024-08-23Web渗透学习:入门指南与实用技巧
- 2024-08-23跨域漏洞入门:理解与基本防御策略
- 2024-08-23安全测试入门:从零开始的网络安全探索
- 2024-08-23安全攻防入门:初学者指南
- 2024-08-23安全渗透入门:从零开始的网络安全探索
- 2024-08-23渗透测试入门:从零开始的网络安全探索之旅
- 2024-08-23渗透攻防入门:从零开始的网络安全探索
- 2024-08-23数据库服务漏洞入门:初学者指南
- 2024-08-23网络安全入门:轻松开始你的网络防护之旅