为什么做了那么多，测了那么多，软件还是不好用？

[xnyu125]

因为不了解用户，不了解用户真正想要什么，用户想要的是有价值的体验，而不是堆砌软件功能。

随着各行各业信息化建设和数字化转型如火如荼地开展，互联网产品同质化愈演愈烈，垂直行业解决方案也进入红海竞争，产品驱动一切的时代进入尾声。我们看到软件由最初的线下过程线上化，到之后的“应把人的经验线上化而非死的流程”，到越来越多的 toB 产品逐渐 toC 化，到现在的追寻价值与意义、个性和体验，一款产品脱颖而出的难度逐层加码。这一切无不提示着后产品时代应是体验为王的时代。

在体验为王的时代，质量即体验，不管已经做了多少，我们都应该致力于为用户或客户提供良好的体验，站在用户或客户的视角看待业务和产品，帮助用户或客户实现真正的价值。

文章分享：《体验为王的时代，质量即体验》

[aabbcc112233]

看了文章浪费了我 5 分钟

[lishoujun]

质量!=体验
质量==体验是测试团队的一种常见误区

想象质量领域是一个圆，体验领域也是一个圆，这两个圆相交，它们有共同的部分，但是也有各自独立的部分。
质量的工作应该是将质量圆的部分做好，当人力溢出的时候，可以去做体验，但也可以去做开发、运维、运营。并没有显著的差别。

为什么有人说 质量==体验，但很少有人说质量==运维呢？
因为用户体验是看得见的，在用户体验上做工作，容易被看到结果，进而转化为产出和影响力。 说白了，质量人员去做用户体验，和近几年炒的很火的测试左移，测试右移，目的都差不多。

为什么研发和运维团队没有这样喊，而质量团队很喜欢这么喊呢？ 我觉得和质量团队“质量做好了是应该的，质量做坏了就会背锅”的特点有关，自身立场和定位不够 strong ，为了向上管理证明和体现团队价值，试图揽活，当质量做好了，可以说我们还做了什么什么，超出了本职工作，绩效 120%等等。 如果质量没做好，起码揽的活体现了用户导向，职业精神。

在我的认知里，一个团队 创意 关系 PM 研发 质量 UE 都过关，才侥幸能在大浪淘沙里面活下来，走向成功，尝试由某个职能 A 去代位补偿职能 B ，一是容易出现外行指导内行，二是容易导致被代位的团队产生依赖，从而加重 A 的工作压力。

[jones2000]

体验是基础核心技术开发， 不是随便找几个开源的代码堆起来的。软件和硬件结合才能真正提高体检。地基都不牢固，怎么建高楼呢， 不塌才怪。

[Hider5]

就国内这种疯狂堆业务，版本迭代，你能期望有啥用户体验

[freakxx]

为什么想了那么多，写了那么多，文章还是很不行？

因为不了解用户，不了解用户真正想要什么，用户想要的是有价值的内容，而不是堆砌空洞字眼。


你看，下一期我来写，能行吗

[Pichai]

@Hider5 不主动去找业务，拉增长，公司进入缓慢发展，基本就要被裁掉了。

[xnyu125]

@lishoujun @jones2000 @Hider5 @Pichai
感谢各位，可能是应对了一些情况才有的这个思考。比如我们接到需求后正常进入研发、测试，代码质量好，测的也全面，但上线还是接到投诉，或者干脆没人用。分析一下原因可能是：

1. 交付的是个伪需求，用户没有需求
2. 用户有需求，但交付的体验或质量不好，用户抱怨
3. 可能用户找错了，业务设计的有问题
……

假设现状就是这样，大家觉得质量团队要不要进一步挖掘这些问题呢？质量团队需要面对这些问题进行反思吗？

@aabbcc112233 那真是抱歉了，浪费时间≈图财害命，真是瑟瑟发抖 ing
@freakxx 文无第一嘛，欢迎并催更~

[wanguorui123]

体验是做减法，一般人学不会

[codefever]

做好用户体验需要一颗真正能与用户共情、无我的心态

[xuanbg]

软件不好用，100%是设计问题。

[jones2000]

@xnyu125 需求是很多用户都需要用的功能才是需求， 这种东西不是拍脑袋想的，需要有人在这行业里面工作了十多年总结的经验，不是画几个漂亮的 UI 图就可以的。否则你就砸钱改变用户习惯，　把你的需求变成大多数人的需求。

[fredli]

企业软件，买单的不用，体验？管老板什么事，能用就行，UX 照着互联网 app 去干，就不是这个价格了

[Tumblr]

让我想到了那个著名的段子：

一个侧试工程师走进一家酒吧，要了一杯啤酒；
一个测试工程师走进一家酒吧，要了一杯咖啡；
一个侧试工程师走进一家酒吧，要了 0 . 7 杯啤酒；
一个侧试工程师走进一家酒吧，要了-1 杯啤酒；
一个测试工程师走进一家酒吧，要了 232 杯啤酒；
一个测试工程师走进一家酒吧，要了一杯洗脚水；
一个测试工程师走进一家酒吧，要了一杯晰蝎；
一个测试工程师走进一家酒吧，要了一份 asdfQWer @ 24dg ! & * ( @ ;
一个测试工程师走进一家酒吧，什么也没要；
一个测试工程师走进一家酒吧，又走出去又从窗户进来又从后门出去从下水道钻进来；
一个测试工程师泪井一家酒吧，又走出去又进来又出去又进来又出去，最后在外面把老板打了一顿；
一个测试工程师走进一家酒吧，要了一杯烫烫烫的馄斤拷；
一个测试工程师走进一家酒吧，要了 NaN 杯 Null ；
一个测试工程，面中进一家酒吧，要了 500T 啤酒咖啡洗脚水野渊良牙棒奶茶；
一个测试工程师把酒吧拆了；
一个测试工程师俗涟成老板走讲一家酒吧，要了 5 00 杯啤酒并且不付钱；
一万个测试工程师在酒吧门外呼啸而过；
一个测试工程师走进一家酒吧，要了一杯啤酒牡 0ROp TABLE 酒吧；
测试工程师们满意地离开了酒吧。

然后一名顾客点了一份炒饭，酒吧炸了。

[9136347]

我一直觉得，什么体验啊什么的都是扯淡。我始终认为软件两大奥义，1：解决问题，2：带来价值。
但是我觉得现在可能有点太卷了，解决问题变成了，创造问题然后解决。
带来价值变成了，洗脑，让客户觉得你创造了价值。
可能有失偏颇，但是这种极端的案例还是有的。

[Finnn]

谁说产品就得按你用户的需求来,
我的产品是为利润服务的,
太理想化了

[cheng6563]

用户需求：啥不干白捡钱
请问质量怎么办？

[bthulu]

@9136347 深有同感, 小组领导为了维持小组的生存, 一直都在忙着创造问题然后解决

[xnyu125]

感谢大家回复。针对这些问题，也衍生出其他一些值得思考的问题：
（我也不知道为什么做质量会想思考这些问题，只是觉得思考了可能有助于加强相互理解，减轻部分痛点）

1. 我们一定要用软件的方式实现需求么，如果有其他方式不用研发也能交付价值，应该被鼓励吗？
2. 怎么能避免创造需求然后解决呢？（怎么避免产研测整体自嗨）
3. 假设我们验证了需求才研发，交付后怎么进行进一步的需求价值的回归验证呢？
4. 用户需求是会变的，我们以什么频率观测需求的变化呢，它是一个线性过程还是一个不断迭代的过程？
5. 当需求不合理的时候，我们是该据理力争，还是顺应时势？

[c8c]

你说的这个质量问题需要区分。
1. 质量测试是否满足了 PM 的需求
2. 质量需求是否满足了用户 的需求

用户的需求一般来说不是 质量的问题，而是 PM 的问题

[xnyu125]

@c8c 澄清一下，这里的 PM 指产品经理而非项目经理，对吗？所以这个区分在于，测试可以只验证产品和软件需求，而不负责澄清和验证质量需求？

实际情况可能是，不存在一个环节叫「质量需求」，或者大部分都是隐含的而非显性提出的质量需求。谁来决定「质量需求」呢？

[c8c]

@xnyu125 PM 指的是 产品经理，产品经理负责这个产品是什么样子的，用户需要什么，给用户提供什么。

项目经理是管理整个项目进度的。

实际中，当然存在一个环节 质量需求， 譬如响应时间，用户说你要反应够快，那么就需要定义在 0.1 秒内返回给用户等等，这是具体化的需求。 当一个项目 /产品用户足够多的时候，这些都会提出要求的。

[xnyu125]

@c8c 理解了，这里的质量需求是指一些非功能的需求，如性能、安全、兼容性等要求，这些是可以在提需求的时候就被收集和澄清的。如果算是需求的一部分，看上去应是产品经理来驱动产出这部分质量需求。

[xnyu125]

@fredli 是，确实 toB 似乎没有 toC 更关注“用户”体验，用户在这里没有不用的权利。

[McreeWu]

我觉得现在的绝大多数软件更在乎流量能否快速变现，以及短暂的用户留存率。通过一些手段诱导用户留下，而不是完善软件自身的功能做好它本应完成的事。

[xnyu125]

@McreeWu 如果基于软件产品的生命周期来看会容易理解一些，在 0-1 阶段，需要快速验证产品构想，尽量快速获客争取留存，这是没问题的。但如果定义不清，或者过了这个阶段，可能该好好打磨产品功能了，却还在做这样急功近利的事情，就会流失用户了。这似乎是个悖论，为了快速变现而不会产出有价值的产品去长久的变现。