任正非：产品竞争力如何真正做到以用户体验为中心

转发《给我一个降落伞》及评论

——产品竞争力如何真正做到以用户体验为中心

史耀宏

二战中期，美国空军降落伞的合格率只能达到99%（这已是供应商认为当时质量的极限），这就意味着每一百位跳伞的士兵中会有一个伞兵因为降落伞无法打开而牺牲。军方要求，厂家必须让合格率达到100%才行。厂家负责人说，我们竭尽全力了，99%已是极限，除非出现奇迹。为此军方提出改变降落伞品质验收的方法：每次交货前从降落伞中随机挑出几个，让厂家负责人亲自跳伞检测。从此，奇迹出现了，降落伞的合格率达到了百分之百。一条看似不显眼的规则，缔造了一个产品竞争力奇迹……

为什么突然提起这段往事？加入产品线以来，我和同事们精力花的最大、讨论最多的一个词就是”产品竞争力”。以我负责的BSS为例，从最终用户ROADS体验到数字化生产，从运营商市场部的TTM到IT部门TCO等讨论的不亦乐乎，但产品上市后最终客户的体验，是否真正关注：

最终用户到营业厅办理3G升4G套餐，需要排队一个小时，填多张表，再办理近半个小时业务才能开通，我们听后只是认为运营商流程太复杂；

我们自己开发的客户端App，自己都不愿在上面办理业务；

运营商市场部人员为了配置一个30天的促销属性，在进行N步配置后，最后常常因为不知所以的校验不通过而失败……

一个产品从设计到实现，设计SE根据需求文档和自己的理解进行设计，开发人员只管编码实现，测试人员只根据需求文档测试，相当一部分销售人员甚至不知道产品长什么样，整个产品线成为机械的产品制造者。其核心原因就是从我这个子产品线总裁到关键团队没有真正作为最终用户使用过自己做的产品，没有把用户体验作为产品竞争力的核心要素。作为产品线负责人，作为产品管理、设计、开发、行销、服务等关键角色，是时候大声喊出来”给我一个降落伞”，像降落伞供应商高层一样作为使用者用自己做的降落伞跳伞，亲身感受最终用户的不满与问题了。我与我的管理团队，初步制定了这几个要持续跳的降落伞：

例行通过我们开发系统的网上营业厅与APP办理业务；

每季度做半天营业员直接服务最终用户；

每月相关人员和战略运营商MKT人员共同工作一天；

每季度牵头实施一次升级、季度出账或故障定位……

给我们一个降落伞，公司领导说可以先从西藏跳起，那里海拔高，万一降落伞没有打开也不会丧命，掉到喜马拉雅山上可以爬起来，改进后再跳。相信每一个产品线只要真正去使用自己开发的产品，找到一个以用户体验为中心”跳降落伞”的长效机制，就一定能够将用户体验为中心融入到整个产品线组织的血液，突入产品竞争力的无人区。

天天打松鼠：

记得10多年前，电软为解决产品安装难问题，要求PDT Leader、开发代表、SE Leader亲自到实验室把产品端到端安装一遍。整改后，可安装能力大幅提升。

只有领导亲入一线，才能知道具体问题在哪儿，只听汇报，是不会知道问题在哪儿的。

边走边瞧：

1、既然要求了管理团队做这件事，他们的体验心得要在心声上发表。

2、可以设置一个角色（可以来自SE)，从前端需求、框架设计、代码开发、测试、销售、交付、维护，把产品整体从头到尾跟踪起来。他的工作就是和各个团队一起作战，一个新的产品或者一个大的版本，就需要一个这样的人即可。

Sonicgo回复@边走边瞧：

这个角色就是交付PM，除了框架设计这一步可能难涉及外，交付PM天然就要从头跟到尾。或许我们更需要设立真正意义上的产品经理角色，除了寄希望于一个角色外，BSS项目的每个人都会用自己的系统去理解业务流程/业务规则估计会更快见效。

QQ群明片：

每个角色都懂全局固然很好，但整个解决方案没有一个角色懂全局就是不可饶恕的了。可当前，我们的产品就是这样。

杯茶：

缺产品经理啊。角色场景都不分，怎么可能做好?“我都能做”，和“您的问题应该这样解决”差别很大。

向数学大师致敬：

现在不仅仅是营业系统的操作使用人员体验差，最终用户的体验也很差。去营业厅办个业务，动辄排上一个小时的队，好不容易轮到自己办理，又要坐在那里等业务专员操作半天。

雏鹰爱吃鱼：

跳伞失败关乎到负责人的生命危险，我们的“降落伞”即使没有打开又怎样，真的会拼尽全力的改进吗？

被坑的不只是爹：

不是说现在各个模块解耦么？

为什么现在还是很多模块不能独立销售？

客户很多时候就是要一个小模块，比如Campaign，比如TT，结果我们都说不单卖，要买就买一个整体的解决方案。

猴年猴赛雷@被坑的不只是爹：

我认为模块解耦的目的更多的是为了降低产品开发的复杂度，但从销售的角度来说，重点还是卖解决方案，不是每个模块都能解耦卖，一是利润问题，二是不能保证和运营商现有的系统兼容。

未来的生活：

BSS软件的定制性比较强，不同运营商的差异比较大，华为这种大兵团作战的公司是否适合直接做BSS软件值得考虑。公司总是强调做一系列套件，让客户去组合，但是仅仅是组合应该是不够的，还需要针对套件的部件进行定制。

是否应该像惠普的模式，自己提供一个大平台，然后让第三方针对具体局点去定制？

nicknm：

BSS的特殊和复杂，在于首先它是软件，其实这个软件他既2B，又2C。

但凡硬件，无论2B（如基站），还是2C（如手机），通常功能都很容易说清楚，然后只需将核心功能通用化后注入盒子完事。

但凡软件，无论是2B（ERP），还是2C（支付宝），通常功能复杂而且很难说清楚，2B软件承载管理理念，2C软件打造极致体验，理念和体验这二者都很难一句话说清楚。

而BSS作为软件，他除了承载运营商管理理念外，同时要替运营商想清楚运营商的最终用户应该如何借助BSS获得最佳体验。

做好BSS这种光盘，给我一把合作的BSS降落伞，核心在于1）把自己当做运营商，想清楚什么才是运营商最佳管理理念和流程；2）把自己当做最终用户，想清楚什么才是最佳的用户接触办理和业务交互体验。

鸭梨山大2012：

说到底，公司一直是做硬件的公司，在软件方面差距不小，也不仅仅是电软，其他产品线也是的，只重视功能实现，却不关注用户体验设计。

范德比尔特：

小米公司就有一个要求：所有产品管理人员，每周都要花2个小时上小米论坛，回答用户不少于10个投诉。

雷布斯是缺少客服人员吗？？这就是ALI所说的降落伞之一。

神采飞扬：

一直坚持深入一线体验自己系统是否好用，能够发现很多在办公室很难想到的设计优化。

举个真实例子，客户需要归档回执件到系统，操作界面是用户录入纸件上的编号，但是每天数以千计、万计的录入，效率很低，优化方案是在打印回执件的时候附加上二维码，通过扫描枪扫码录入，效率倍增。

小馄饨摊摊主：

真正做产品的基本上都是DSV。希望真正能做到领导层去跳降落伞，而不是又一层一层传递下去，最终又是DSV去跳降落伞。

另外，我强烈推荐让中国区服务的领导先跳！！！

小海星：

作为刚进公司的一个产品经理，被告知不用很懂产品，不用很懂技术，不用很懂balabala……感觉产品经理只要知道客户需求大致匹配哪个解决方案就够了，剩下的就是流程流程流程……用户体验是要研究人在特定场景下的思维模式和行为模式，然后顺势利用它，我们现在倡导的用户体验借鉴太多互联网的东西，不匹配运营商的业务场景，产品经理应该需要在一定程度上成为一名用户体验设计师，而不是流程里的齿轮，永远原地打转。

一杯沙漏：

从测试角度看，有时候流程太复杂、界面不友好、日志不清晰、数据结构太复杂，类似问题都被拒绝了。而且随着版本增加，这些不好用的，大家都已经习惯。客户抱怨、服务报怨可能就被引导为需要技能导入或者加强培训。

心碎乌托邦：

“跳伞”这个事情按照季度、月度这个频率是远远不够的，收集到的场景信息片面的情况居多，正儿八经的把”造伞”的人去军营当一个月、一个季度正规伞兵，相信不仅仅能够保障降落伞质量高，可能各种灵感、竞争力都能在实战中创造出来。

再一个办法，设计、开发、测试组成联合小组，当一下客户系统的”医护兵”，直接处理申告（我们拿到的客户申告，一大部分都是客户自行过滤后的），这个的冲击力和震撼程度相信不亚于原子弹。

孔夫子：

1、所有软件新员工，应该送到运营商的营业厅/MKTING部/IT部门/呼叫中心实习3-6个月，至少干1个月营业厅1个月呼叫中心。

2、重装旅培训应该有一周时间到运营商的营业厅/MKTG部/IT部门/呼叫中心做简单上岗实习。什么解决方案亮点架构自学就行了。

说点逆耳的：

关键是看能不能做到，结果能否公布，能不能成为一种机制，而不是一个运动。

现在不仅是高层领导，研发内部真正“会用”自己系统的人也是少数。对我们自己做的产品都缺少荣誉感。

gmoon：

也许我们的研发，产品经理不够专业，但是至少客户是懂的。但是我们却对客户关上了门。每次做客户满意度调查时，都是左挑右挑客户，有时候恨不得直接帮客户把调查表填了，还很开心的说这就是体验客户关系的时候到了。

我们首先要承认自己有问题，然后我们才会改进。但是现在我们对错误的容忍度太低了。导致大家从上到下都是瞒着，一片和谐。

Fishing：

作为一个业软老兵，需要告诉机关的那些长期坐在办公室里面闭门造车的人，他们需要尝试的东西还有很多很多，远远不止上面说的那几条。

1、OOTB交付，让那些吹NB可以OOTB的人，自己去交付一下OOTB的交付试试，看看我们在OOTB的基础上还需要几千人天的定制？

2、那些号称能缩短TTM的人去亲自配置一下套餐和赠送，优惠。一线人员可以提供全方位技术支持。

3、号称可以一键出账的人，每个月1号的时候，随便给扔到一线的任意一个局点去，让他给我们展示一键出账。

4、让那些和一线争论是问题还是需求，逼着一线去问客户要PO的研发CDPM/SE去一线和客户亲自谈谈看。不是我们不想要PO，有时候的确是我们的产品给我们的底气不足。

5、很多时候，一线客户怎么使用我们的产品，在机关办公室里的SE是无法想象到的。

其他的不多说了，很多需要改进的，可服务性的，优化类的问题太多了……

我们总希望TOP-Down的去解决问题，但是大部分时候还是需要打铁还要自身硬。若是自身不够硬，总期望top-down的去解决问题的话，结果问题也许会被临时解决，但是长远来看，我们还是输了。

y00160930：

我理解体验是分角色的，不同角色关注是差别很大的，从几个角色的维度看体验：

1、最终用户体验，就是交互界面，包括操作的简便、流畅、信息简约有效等等，这部分一定是很专业的，甚至是需要突破性、创造性思维的，UCD专家保障前台，SE/MDE专家保障后台；

2、开发者/DSV体验，sales force是生态圈的标杆，盯着他去做，再及时和DSV闭环问题；

3、运营人员体验，从idea到产品落地，如何更快的速度，90%的日常营销都能配置出来，10%的才需要进行开发，这是要我们产品管理、高级SE和客户联动产生优秀实践，例如：Promotion就是和基地客户持续互动形成的抽象，具备了一定的通用性、快速配置的能力；

4、运维人员体验，从1人能运维1000台设备的指标看，如何通过大屏实时运维，一目了然，工具化的手段定位，DIC目前的运维体验就是朝着这个方向，体验还是很不错的；

5、客户主管的体验，从综合性的视角看的，商业结果要好，各个细节方面都要考虑到，你要想的比他多，超出一点期望；

6、产品Owner的体验，就是史总提到的自己体验，从上述的各个环节，自己就是这个角色，深入到项目现场、操作现场、客户现场，来看我们的系统是不是做到极致。

围绕不同角色的体验改进，我觉得专业性是不一样的，我们也许需要围绕这样的角度去配置、培养人才，持续的研究，我们终究能形成一些突破。

168542：

之前客户/一线反馈的问题少了么？听到炮火的人天天被客户的炮把菊都爆成菜花了家里还在扯是需求还是问题单，有人真正重视客户体验么？建议史总就把体验的参与者范围圈定一下，就各个层级部门的一把手去体验，尤其是研发，体验后亲自输出体验报告，上AT汇报心得。只有大领导重视了，未来才可期。

大胖头鱼：

一线重视交付和后续的维护，但对真正懂业务、在前端与客户谈需求的专家不够重视，长期以往，产品的设计质量可想而知。软件生命周期中，一个错误发现的越晚，修复错误的费用越高，对前端入口不够重视，就会导致后面无停止的修复，客户满意度一降在降，最后出局被淘汰。

一直都在加油：

最靠谱的做事方法就是”三现”（现场、现实、现物）。

人生梦想：

最好的办法是研发管理团队的奖金直接和用户体验强挂钩。这才是降落伞。

y00160690：

华为要做人类情感和数据之间的桥梁，必须要深刻的体会人类情感的诉求，不能停留在冰冷的盒子和软件层面，用户体验（包含运营商客户和最终消费者）是提升产品竞争力的关键。

吃啥：

一边是研发一心聚焦做光盘做套件，一边是要深入客户体验，怎么结合？至少现在没有处理好。

外出公干中：

其实在我们纠结产品本身的时候（产品本身固然重要），国外已经开始注意产品带来的整个服务了，这个就是国外比较火的“服务化设计”。

会飞的前夜：

“光盘”方向是否正确？跳过几次伞后，冷暖自知！

我想我是海29：

为什么苹果的产品总能满足客户需求，即使客户需求不清楚，客户自己都不知道自己应该要什么，但是苹果告诉你，你应该用什么，你的生活方式应该是怎样的，这就是苹果的牛逼之处。

反观我司，各个部门独立运营，你要是想拉通个其它部门，比登天都难，即使拉通了，过来支持的人员也是被动响应，动不动就一句话：说吧，你要我咋干我就咋干，看似忠厚老实，其实是在偷懒。

解决方案：让前端贴近客户需求的一线人员与研发、开发、测试人员互换（硬性），相信有个1-2年会有起色。

花粉老祖祖：

请大佬们一起降落到江苏移动现场系统运维室，亲自体验下我大BES。

二○一六年八月八日