这是一个创建于 919 天前的主题，其中的信息可能已经有所发展或是发生改变。
因为不了解用户，不了解用户真正想要什么，用户想要的是有价值的体验，而不是堆砌软件功能。
随着各行各业信息化建设和数字化转型如火如荼地开展，互联网产品同质化愈演愈烈，垂直行业解决方案也进入红海竞争，产品驱动一切的时代进入尾声。我们看到软件由最初的线下过程线上化，到之后的“应把人的经验线上化而非死的流程”，到越来越多的 toB 产品逐渐 toC 化，到现在的追寻价值与意义、个性和体验，一款产品脱颖而出的难度逐层加码。这一切无不提示着后产品时代应是体验为王的时代。
在体验为王的时代，质量即体验，不管已经做了多少，我们都应该致力于为用户或客户提供良好的体验，站在用户或客户的视角看待业务和产品，帮助用户或客户实现真正的价值。
文章分享：《体验为王的时代，质量即体验》
 |
1
aabbcc112233 2022-05-18 23:52:46 +08:00  7
看了文章浪费了我 5 分钟
|
 |
2
lishoujun 2022-05-19 00:15:23 +08:00 4
质量!=体验
质量==体验是测试团队的一种常见误区 想象质量领域是一个圆，体验领域也是一个圆，这两个圆相交，它们有共同的部分，但是也有各自独立的部分。 质量的工作应该是将质量圆的部分做好，当人力溢出的时候，可以去做体验，但也可以去做开发、运维、运营。并没有显著的差别。 为什么有人说 质量==体验，但很少有人说质量==运维呢？ 因为用户体验是看得见的，在用户体验上做工作，容易被看到结果，进而转化为产出和影响力。 说白了，质量人员去做用户体验，和近几年炒的很火的测试左移，测试右移，目的都差不多。 为什么研发和运维团队没有这样喊，而质量团队很喜欢这么喊呢？ 我觉得和质量团队“质量做好了是应该的，质量做坏了就会背锅”的特点有关，自身立场和定位不够 strong ，为了向上管理证明和体现团队价值，试图揽活，当质量做好了，可以说我们还做了什么什么，超出了本职工作，绩效 120%等等。 如果质量没做好，起码揽的活体现了用户导向，职业精神。 在我的认知里，一个团队 创意 关系 PM 研发 质量 UE 都过关，才侥幸能在大浪淘沙里面活下来，走向成功，尝试由某个职能 A 去代位补偿职能 B ，一是容易出现外行指导内行，二是容易导致被代位的团队产生依赖，从而加重 A 的工作压力。 |
 |
3
jones2000 2022-05-19 00:41:54 +08:00
体验是基础核心技术开发， 不是随便找几个开源的代码堆起来的。软件和硬件结合才能真正提高体检。地基都不牢固，怎么建高楼呢， 不塌才怪。
|
 |
4
Hider5 2022-05-19 00:46:25 +08:00 via iPhone
就国内这种疯狂堆业务，版本迭代，你能期望有啥用户体验
|
 |
5
freakxx 2022-05-19 01:54:28 +08:00 9
为什么想了那么多，写了那么多，文章还是很不行？
因为不了解用户，不了解用户真正想要什么，用户想要的是有价值的内容，而不是堆砌空洞字眼。 你看，下一期我来写，能行吗 |
 |
7
xnyu125 OP |
 |
8
wanguorui123 2022-05-19 09:30:37 +08:00
体验是做减法，一般人学不会
|
 |
9
codefever 2022-05-19 09:33:29 +08:00
做好用户体验需要一颗真正能与用户共情、无我的心态
|
 |
10
xuanbg 2022-05-19 09:39:15 +08:00
软件不好用，100%是设计问题。
|
|
11
jones2000 2022-05-19 09:41:36 +08:00
@xnyu125 需求是很多用户都需要用的功能才是需求， 这种东西不是拍脑袋想的，需要有人在这行业里面工作了十多年总结的经验，不是画几个漂亮的 UI 图就可以的。否则你就砸钱改变用户习惯， 把你的需求变成大多数人的需求。
|
 |
12
fredli 2022-05-19 09:52:49 +08:00
企业软件，买单的不用，体验？管老板什么事，能用就行，UX 照着互联网 app 去干，就不是这个价格了
|
 |
13
Tumblr 2022-05-19 09:57:27 +08:00
让我想到了那个著名的段子：
一个侧试工程师走进一家酒吧，要了一杯啤酒； 一个测试工程师走进一家酒吧，要了一杯咖啡； 一个侧试工程师走进一家酒吧，要了 0 . 7 杯啤酒； 一个侧试工程师走进一家酒吧，要了-1 杯啤酒； 一个测试工程师走进一家酒吧，要了 232 杯啤酒； 一个测试工程师走进一家酒吧，要了一杯洗脚水； 一个测试工程师走进一家酒吧，要了一杯晰蝎； 一个测试工程师走进一家酒吧，要了一份 asdfQWer @ 24dg ! & * ( @ ; 一个测试工程师走进一家酒吧，什么也没要； 一个测试工程师走进一家酒吧，又走出去又从窗户进来又从后门出去从下水道钻进来； 一个测试工程师泪井一家酒吧，又走出去又进来又出去又进来又出去，最后在外面把老板打了一顿； 一个测试工程师走进一家酒吧，要了一杯烫烫烫的馄斤拷； 一个测试工程师走进一家酒吧，要了 NaN 杯 Null ； 一个测试工程，面中进一家酒吧，要了 500T 啤酒咖啡洗脚水野渊良牙棒奶茶； 一个测试工程师把酒吧拆了； 一个测试工程师俗涟成老板走讲一家酒吧，要了 5 00 杯啤酒并且不付钱； 一万个测试工程师在酒吧门外呼啸而过； 一个测试工程师走进一家酒吧，要了一杯啤酒牡 0ROp TABLE 酒吧； 测试工程师们满意地离开了酒吧。 然后一名顾客点了一份炒饭，酒吧炸了。 |
 |
14
9136347 2022-05-19 10:00:58 +08:00
我一直觉得，什么体验啊什么的都是扯淡。我始终认为软件两大奥义，1：解决问题，2：带来价值。
但是我觉得现在可能有点太卷了，解决问题变成了，创造问题然后解决。 带来价值变成了，洗脑，让客户觉得你创造了价值。 可能有失偏颇，但是这种极端的案例还是有的。 |
 |
15
Finnn 2022-05-19 10:43:58 +08:00
谁说产品就得按你用户的需求来,
我的产品是为利润服务的, 太理想化了 |
 |
16
cheng6563 2022-05-19 10:48:41 +08:00
用户需求：啥不干白捡钱
请问质量怎么办？ |
|
18
xnyu125 OP 感谢大家回复。针对这些问题，也衍生出其他一些值得思考的问题：
（我也不知道为什么做质量会想思考这些问题，只是觉得思考了可能有助于加强相互理解，减轻部分痛点） 1. 我们一定要用软件的方式实现需求么，如果有其他方式不用研发也能交付价值，应该被鼓励吗？ 2. 怎么能避免创造需求然后解决呢？（怎么避免产研测整体自嗨） 3. 假设我们验证了需求才研发，交付后怎么进行进一步的需求价值的回归验证呢？ 4. 用户需求是会变的，我们以什么频率观测需求的变化呢，它是一个线性过程还是一个不断迭代的过程？ 5. 当需求不合理的时候，我们是该据理力争，还是顺应时势？ |
 |
19
c8c 2022-05-19 14:13:42 +08:00
你说的这个质量问题需要区分。
1. 质量测试是否满足了 PM 的需求 2. 质量需求是否满足了用户 的需求 用户的需求一般来说不是 质量的问题，而是 PM 的问题 |
|
20
xnyu125 OP @c8c 澄清一下，这里的 PM 指产品经理而非项目经理，对吗？所以这个区分在于，测试可以只验证产品和软件需求，而不负责澄清和验证质量需求？
实际情况可能是，不存在一个环节叫「质量需求」，或者大部分都是隐含的而非显性提出的质量需求。谁来决定「质量需求」呢？ |
|
21
c8c 2022-05-19 15:43:26 +08:00
@xnyu125 PM 指的是 产品经理，产品经理负责这个产品是什么样子的，用户需要什么，给用户提供什么。
项目经理是管理整个项目进度的。 实际中，当然存在一个环节 质量需求， 譬如响应时间，用户说你要反应够快，那么就需要定义在 0.1 秒内返回给用户等等，这是具体化的需求。 当一个项目 /产品用户足够多的时候，这些都会提出要求的。 |
|
22
xnyu125 OP @c8c 理解了，这里的质量需求是指一些非功能的需求，如性能、安全、兼容性等要求，这些是可以在提需求的时候就被收集和澄清的。如果算是需求的一部分，看上去应是产品经理来驱动产出这部分质量需求。
|
 |
24
McreeWu 2022-05-20 15:00:51 +08:00
我觉得现在的绝大多数软件更在乎流量能否快速变现，以及短暂的用户留存率。通过一些手段诱导用户留下，而不是完善软件自身的功能做好它本应完成的事。
|
Select Language