V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
xnyu125
V2EX  ›  程序员

为什么做了那么多,测了那么多,软件还是不好用?

  •  
  •   xnyu125 · 2022-05-18 23:22:11 +08:00 · 3991 次点击
    这是一个创建于 680 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

    25 条回复    2022-05-20 16:37:07 +08:00
    aabbcc112233
        1
    aabbcc112233  
       2022-05-18 23:52:46 +08:00   ❤️ 7
    看了文章浪费了我 5 分钟
    lishoujun
        2
    lishoujun  
       2022-05-19 00:15:23 +08:00   ❤️ 4
    质量!=体验
    质量==体验是测试团队的一种常见误区

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

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

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

    在我的认知里,一个团队 创意 关系 PM 研发 质量 UE 都过关,才侥幸能在大浪淘沙里面活下来,走向成功,尝试由某个职能 A 去代位补偿职能 B ,一是容易出现外行指导内行,二是容易导致被代位的团队产生依赖,从而加重 A 的工作压力。
    jones2000
        3
    jones2000  
       2022-05-19 00:41:54 +08:00
    体验是基础核心技术开发, 不是随便找几个开源的代码堆起来的。软件和硬件结合才能真正提高体检。地基都不牢固,怎么建高楼呢, 不塌才怪。
    Hider5
        4
    Hider5  
       2022-05-19 00:46:25 +08:00 via iPhone
    就国内这种疯狂堆业务,版本迭代,你能期望有啥用户体验
    freakxx
        5
    freakxx  
       2022-05-19 01:54:28 +08:00   ❤️ 9
    为什么想了那么多,写了那么多,文章还是很不行?

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


    你看,下一期我来写,能行吗
    Pichai
        6
    Pichai  
       2022-05-19 04:49:16 +08:00
    @Hider5 不主动去找业务,拉增长,公司进入缓慢发展,基本就要被裁掉了。
    xnyu125
        7
    xnyu125  
    OP
       2022-05-19 09:23:04 +08:00
    @lishoujun @jones2000 @Hider5 @Pichai
    感谢各位,可能是应对了一些情况才有的这个思考。比如我们接到需求后正常进入研发、测试,代码质量好,测的也全面,但上线还是接到投诉,或者干脆没人用。分析一下原因可能是:

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

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

    @aabbcc112233 那真是抱歉了,浪费时间≈图财害命,真是瑟瑟发抖 ing
    @freakxx 文无第一嘛,欢迎并催更~
    wanguorui123
        8
    wanguorui123  
       2022-05-19 09:30:37 +08:00
    体验是做减法,一般人学不会
    codefever
        9
    codefever  
       2022-05-19 09:33:29 +08:00
    做好用户体验需要一颗真正能与用户共情、无我的心态
    xuanbg
        10
    xuanbg  
       2022-05-19 09:39:15 +08:00
    软件不好用,100%是设计问题。
    jones2000
        11
    jones2000  
       2022-05-19 09:41:36 +08:00
    @xnyu125 需求是很多用户都需要用的功能才是需求, 这种东西不是拍脑袋想的,需要有人在这行业里面工作了十多年总结的经验,不是画几个漂亮的 UI 图就可以的。否则你就砸钱改变用户习惯, 把你的需求变成大多数人的需求。
    fredli
        12
    fredli  
       2022-05-19 09:52:49 +08:00
    企业软件,买单的不用,体验?管老板什么事,能用就行,UX 照着互联网 app 去干,就不是这个价格了
    Tumblr
        13
    Tumblr  
       2022-05-19 09:57:27 +08:00
    让我想到了那个著名的段子:

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

    然后一名顾客点了一份炒饭,酒吧炸了。
    9136347
        14
    9136347  
       2022-05-19 10:00:58 +08:00
    我一直觉得,什么体验啊什么的都是扯淡。我始终认为软件两大奥义,1:解决问题,2:带来价值。
    但是我觉得现在可能有点太卷了,解决问题变成了,创造问题然后解决。
    带来价值变成了,洗脑,让客户觉得你创造了价值。
    可能有失偏颇,但是这种极端的案例还是有的。
    Finnn
        15
    Finnn  
       2022-05-19 10:43:58 +08:00
    谁说产品就得按你用户的需求来,
    我的产品是为利润服务的,
    太理想化了
    cheng6563
        16
    cheng6563  
       2022-05-19 10:48:41 +08:00
    用户需求:啥不干白捡钱
    请问质量怎么办?
    bthulu
        17
    bthulu  
       2022-05-19 10:52:08 +08:00
    @9136347 深有同感, 小组领导为了维持小组的生存, 一直都在忙着创造问题然后解决
    xnyu125
        18
    xnyu125  
    OP
       2022-05-19 11:51:41 +08:00
    感谢大家回复。针对这些问题,也衍生出其他一些值得思考的问题:
    (我也不知道为什么做质量会想思考这些问题,只是觉得思考了可能有助于加强相互理解,减轻部分痛点)

    1. 我们一定要用软件的方式实现需求么,如果有其他方式不用研发也能交付价值,应该被鼓励吗?
    2. 怎么能避免创造需求然后解决呢?(怎么避免产研测整体自嗨)
    3. 假设我们验证了需求才研发,交付后怎么进行进一步的需求价值的回归验证呢?
    4. 用户需求是会变的,我们以什么频率观测需求的变化呢,它是一个线性过程还是一个不断迭代的过程?
    5. 当需求不合理的时候,我们是该据理力争,还是顺应时势?
    c8c
        19
    c8c  
       2022-05-19 14:13:42 +08:00
    你说的这个质量问题需要区分。
    1. 质量测试是否满足了 PM 的需求
    2. 质量需求是否满足了用户 的需求

    用户的需求一般来说不是 质量的问题,而是 PM 的问题
    xnyu125
        20
    xnyu125  
    OP
       2022-05-19 14:29:29 +08:00
    @c8c 澄清一下,这里的 PM 指产品经理而非项目经理,对吗?所以这个区分在于,测试可以只验证产品和软件需求,而不负责澄清和验证质量需求?

    实际情况可能是,不存在一个环节叫「质量需求」,或者大部分都是隐含的而非显性提出的质量需求。谁来决定「质量需求」呢?
    c8c
        21
    c8c  
       2022-05-19 15:43:26 +08:00
    @xnyu125 PM 指的是 产品经理,产品经理负责这个产品是什么样子的,用户需要什么,给用户提供什么。

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

    实际中,当然存在一个环节 质量需求, 譬如响应时间,用户说你要反应够快,那么就需要定义在 0.1 秒内返回给用户等等,这是具体化的需求。 当一个项目 /产品用户足够多的时候,这些都会提出要求的。
    xnyu125
        22
    xnyu125  
    OP
       2022-05-19 17:39:30 +08:00
    @c8c 理解了,这里的质量需求是指一些非功能的需求,如性能、安全、兼容性等要求,这些是可以在提需求的时候就被收集和澄清的。如果算是需求的一部分,看上去应是产品经理来驱动产出这部分质量需求。
    xnyu125
        23
    xnyu125  
    OP
       2022-05-19 20:03:29 +08:00
    @fredli 是,确实 toB 似乎没有 toC 更关注“用户”体验,用户在这里没有不用的权利。
    McreeWu
        24
    McreeWu  
       2022-05-20 15:00:51 +08:00
    我觉得现在的绝大多数软件更在乎流量能否快速变现,以及短暂的用户留存率。通过一些手段诱导用户留下,而不是完善软件自身的功能做好它本应完成的事。
    xnyu125
        25
    xnyu125  
    OP
       2022-05-20 16:37:07 +08:00
    @McreeWu 如果基于软件产品的生命周期来看会容易理解一些,在 0-1 阶段,需要快速验证产品构想,尽量快速获客争取留存,这是没问题的。但如果定义不清,或者过了这个阶段,可能该好好打磨产品功能了,却还在做这样急功近利的事情,就会流失用户了。这似乎是个悖论,为了快速变现而不会产出有价值的产品去长久的变现。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2769 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 12:13 · PVG 20:13 · LAX 05:13 · JFK 08:13
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.