26 | 作为程序员，你也应该聆听用户声音

Mar 4, 2019

26 | 作为程序员，你也应该聆听用户声音-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

26 | 作为程序员，你也应该聆听用户声音

2019-03-04 郑晔来自北京

《10x程序员工作法》

课程介绍



讲述：郑晔

时长10:17大小9.42M



你好，我是郑晔。
在前面的专栏内容中，我们讨论过几次与产品经理的交流：你应该问问产品经理为什么要做这个产品特性，要用 MVP（最小可行产品）的角度，衡量当前做的产品特性是不是一个好的选择。
但还有一个问题可能困扰着我们：怎么判断产品经理说的产品特性是不是用户真的需要的呢？
很多时候，产品经理让你实现一个产品特性，你感觉这么做好像不太对，却又说不出哪不对，想提出自己的看法，却不知道从哪下手。之所以会遇到这样的问题，一个重要的原因就是，你少了一个维度：用户视角，你需要来自真实世界的反馈。
吃自家的狗粮产品经理无论要做什么，他都必须有一个立足的根基：为用户服务。所以，如果你了解了用户怎么想，你就有资本判断产品经理给出的需求，是否真的是用户需要的了。
而作为一个程序员，欠缺用户视角，在与产品经理的交流中，你是不可能有机会的，因为他很容易用一句话就把你打败：“这就是用户需求。”
很多程序员只希望安安静静地写好代码，但事实上，对于大多数人来说，安安静静是不太可能写好代码的，只有不断扩大自己的工作范围，才可能对准“靶子”。
今天我们讨论的角度，就是要你把工作范围扩大，由听产品经理的话，扩大成倾听用户的声音。
作为程序员，你应该听说过一个说法“Eat your own dog food”（吃自家的狗粮）。这个说法有几个不同的来源，都是说卖狗粮的公司真的用了自家的狗粮。
从 1988 年开始，这个说法开始在 IT 行业流行的，微软的保罗·马瑞兹（Paul Maritz）写了一封“Eating our dog food”的邮件，提到要“提高自家产品在内部使用的比例。”从此，这个说法在微软迅速传播开来。
如今，自己公司用自己的产品几乎成了全行业的共识。抛开一些大公司用这个说法做广告的因素，不断使用自家的产品，会让你多出一个用户的视角。
在挑毛病找问题这件事上，人是不需要训练的，哪里用着不舒服，你一下子就能感受到。所以，不断地使用自家产品，你自己就是产品的用户，这会促使你不断去思考怎么改进产品，再与产品经理讨论时，你就自然而然地拥有了更多的维度。
比如，前面在讨论 MVP 时，我曾经讲过一个我做 P2P 产品的经历。在这个项目中，我就作为用户在上面进行了一些操作。当自己作为用户使用时，就发现了一些令人不爽的地方。
比如，一开始设计的代金券只能一次性使用，如果代金券金额比较大，又没那么多本金，只能使用代金券的一部分，就会让人有种“代金券浪费了”的感觉。
于是，我就提出是不是可以把代金券多次使用。很快，产品就改进了设计。这种改进很细微，如果你不是用户，只从逻辑推演的角度是很难看到这种差异的。
当你吃不到狗粮时不过，不是每家公司的产品都那么“好吃”。“吃自家狗粮”的策略对于那些拥有“to C”产品的公司来说，相对是比较有效的。但有时候，你做的产品你根本没有机会用到。
我曾经与很多海外客户合作过，我做的很多产品，自己根本没有机会使用。比如，我做过五星级酒店的审计平台。除了能对界面上的内容稍微有点感觉之外，对于使用场景，我是完全不知道的。
如果没有机会用到自己的产品，我们该怎么办呢？我们能做的就是尽可能找机会，去到真实场景里，看看用户是如何使用我们软件的。
比如，做那个酒店审计平台时，我就和客户一起到了一家五星级酒店，看着他们怎样一条一条地按照审计项核查，然后把审计结果登记在我们的平台上。
那些曾经只在写程序时见到的名词，这回就活生生地呈现在我眼前了。后来再面对代码时，我看到就不再是一个死板的程序了，我和产品经理的讨论也就更加扎实了。
有的团队在这方面有比较好的意识，会主动创造一些机会，让开发团队成员有更多机会与用户接触。
比如，让开发团队到客服团队轮岗。接接电话，听听用户的抱怨，甚至是谩骂。你会觉得心情非常不好，但当你静下来的时候，你就会意识到自己的软件有哪些问题，如果软件做得不好，影响会有多大。
这时，你也就能理解，为什么有的时候，很多业务人员会对开发团队大发雷霆了，因为他们是直接面对用户“炮火”的人。
我们为什么要不断地了解用户的使用情况呢？因为用户的声音是来自真实世界的反馈。不去聆听用户声音，很容易让人自我感觉良好。还记得在 “为什么世界和你的理解不一样” 中，我们提到的那个只接收好消息的花剌子模国国王的例子吗？
我们要做一个有价值的产品，这个“价值”，不是对产品经理有价值，而是要对用户有价值。华为总裁任正非就曾经说过，“让听得见炮声的人来做决策。”
我们做什么产品，本质上不是由产品经理决定的，而是由用户决定的。只有听见“炮声”，站在一线，我们才更有资格判断产品经理给出的需求是否真的是用户所需。
当产品还没有用户时如果你的团队做的是一个新的产品，还没有真正的用户，那又该怎么办呢？你可以尝试一下“用户测试”的方法。
之前我做过一个海外客户的项目。因为项目处于启动阶段，我被派到了客户现场。刚到那边，客户就兴高采烈地告诉我，他们要做一个用户测试，让我一起参加。当时，我还有点不知所措，因为我们的项目还没有开始开发，一个什么都没有的项目就做用户测试了？是的，他们只做了几个页面，就开始测试了。
站在今天的角度，我前面已经给你讲过了精益创业和 MVP，你现在理解起来就会容易很多。是的，他们就是要通过最小的代价获取用户反馈。
他们是怎么做测试的呢？首先是一些准备工作，找几个普通用户，这些人各有特点，能够代表不同类型的人群。准备了一台摄像机，作为记录设备，拍摄用户测试的全过程。还准备了一些表格，把自己关注的问题罗列上去。
然后，就是具体的用户测试了。他们为用户介绍了这个测试的目的、流程等一些基本信息。然后，请用户执行几个任务。
在这个过程中，测试者会适时地让用户描述一下当时的感受，如果用户遇到任何问题，他们会适当介入，询问出现的问题，并提供适当的帮助。
最后，让用户为自己使用的这个产品进行打分，做一番评价。测试者的主要工作是观察和记录用户的反应，寻找对用户使用造成影响的部分。做用户测试的目的就是看用户会怎样用这个网站，这样的网站设计会对用户的使用有什么影响。
当天测试结束之后，大家一起整理了得到的用户反馈，重新讨论那些给用户体验造成一定影响的设计，然后调整一版，再来做一次用户测试。
对我来说，那是一个难忘的下午，我第一次这么近距离地感受用户。他们的关注点，他们的使用方式都和我曾经的假设有很多不同。后面再来设计这个系统时，我便有了更多的发言权，因为产品经理有的角度，我作为开发人员也有。
最后，我还想说一个程序员常见的问题：和产品经理没有“共同语言。”
因为他们说的通常是业务语言，而我们程序员的口中，基本上是计算机语言。这是两个领域的东西，很难互通。前面在讨论代码的时候，我提到要用业务的语言写代码，实际上，这种做法就是领域驱动设计中的通用语言（Ubiquitous Language）。
所谓通用语言，不只是我们写代码要用到，而是要让所有人说一套语言，而这个语言应该来自业务，来自大家一起构建出的领域模型。
这样大家在交流的时候，才可能消除歧义。所以，如果你想让项目顺利进行，先邀请产品经理一起坐下来，确定你们的通用语言。
总结时刻今天我们讨论了一个重要的话题：倾听用户声音。这是开发团队普遍欠缺的一种能力，更准确地说，是忽略的一种能力。所以，“吃自家的狗粮”这种听上去本来是理所当然的事情，才被反复强调，成为 IT 行业的经典。
在今天这一讲，我给你介绍了“了解用户需求”的不同做法，但其归根结底就是一句话，想办法接近用户。
无论是自己做用户，还是找机会接触已有用户，亦或是没有用户创造用户。只有多多听取来自真实用户的声音，我们才不致于盲目自信或是偏颇地相信产品经理。谁离用户近，谁就有发言权，无论你的角色是什么。
如果今天的内容你只能记住一件事，那请记住：多走近用户。
最后，我想请你思考一下，在你的实际工作中，有哪些因为走近客户而发现的问题，或者因为没有走近客户造成的困扰呢？欢迎在留言区写下你的想法。
感谢阅读，如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给你的朋友。

分享给需要的人，Ta购买本课程，你将得20元

生成海报并分享

赞 23

提建议

25 | 开发中的问题一再出现，应该怎么办？

27 | 尽早暴露问题：为什么被指责的总是你？

 写留言

精选留言(15)

陈斯佳
2019-06-01
这篇文章对我来说非常有启发，虽然我不是纯程序员，我的本职工作是做运维的，但是我一直认为，运维这个岗位所面对的用户是两类，一类是程序员，还有一类就是QA测试。以今天这章讲解的内容为指导，之后我会调整我自己的工作方式和内容，去多接近我的程序员和测试，多去尝试他们的工作场景，比如说，使用他们正在使用的IDE来编写代码，提交代码，走整个发布流程。通过这种方式来看看其中有哪些是可以提高的。感谢老师！
17
西西弗与卡夫卡
2019-03-04
最近在做内部信息系统，昨天正好提到贴近用户这个话题，原话有些低俗。内部产品在设计和开发过程常常不如C端产品受大家重视，反正不管怎样都要用。看似团队不用像C端产品那样操心，需要别人捏着鼻子才能使用产品的结果就是成绩不容易被别人看到，问题容易被人挑刺，最后造成团队成就感低，以此恶性循环。痛定思痛，团队准备转换思路，用互联网C端用户理念重新审视内部系统，同样要明确目标，制定指标，更重要的是不光只是问需求，还需要到相关位置上轮岗，亲身体会用户的痛苦
展开
作者回复: 坐在办公室里，很难做好软件。走出去，才会听到真实声音。
11
丁丁历险记
2019-11-16
让听见炮火声的人去做决定。
10
kevin
2019-04-10
跳出程序的思维框架，多走出去看看，扩大自己的上下文
5
wuhulala
2020-03-19
现在产品就没有客户，需要找几个小白鼠实验试验了
作者回复: 没有用户太危险，不知道投入是不是浪费。
4
David Mao
2019-03-05
我做了好多年的软件测试，前几年和销售一起去谈客户，才深深地体会到客户声音的重要性。客户关注的才是真需求，产品经理和开发想出来的很多是伪需求，很多不是客户想要的功能。
作者回复: 经验越丰富，越能体会到走近用户的重要性。
3
Luke
2021-06-22
360 公司的老板周鸿祎也曾经说过「要像小白一样思考、像专家一样行动」这样的口感。总感觉作为研发人员，我们也可以并有权拓展自己的边界。聆听用户的声音，让开发人员培养起站在用户角度思考的习惯，了解了用户所面临的痛点。试着自己当一把产品经理，也不至于每天困扰，自己的才干被埋没在产品文档的鸡零狗碎中了。😄
展开
作者回复: 往前一步，有更多的上下文
2
行与修
2019-03-05
走近用户好处多多，前期能得到第一手资料，中间多接触能及时校正方向，后面可以深化业务认知（有些领域不是一两个项目就能撑起自己的知识体系）同时兼顾关系维护。反之则大概率陷入被动，不得不妥协随波逐流。暂且不说和产品团队之间，开发内部自己就先掐起来了，前东家里就很容易碰到屈从内部压力而最后客户又不买账的情况，结果辛辛苦苦做出来的又推倒重来，贼郁闷～现在为防止此类问题出现，会及时引入用户做裁判，大家都别争了，客户关切已经出来了，愿赌服输吧😂
展开
作者回复: 专业的产品不好找，走近用户，防止被坑。
3
ifelse
2022-04-21
开发要适当接触用户，了解用户真实需求，不要只顾埋头写代码。
1
陈斯佳
2019-08-16
佩服马化腾一秒钟变小白的能力。如果我们都能一秒钟变成自己的客户，这个世界将变成美好的人间
作者回复: 共情能力，需要有意识地锻炼。
1
Mi Manchi
2022-06-22
华为总裁任正非就曾经说过，“让听得见炮声的人来做决策。” 最近正好看了相关的三本书，“让听得见炮声的人来做决策。”是华为借鉴美军的改革方案所提出来的，这三本书如下： 1、《赋能：打造应对不确定性的敏捷团队》斯坦利·麦克里斯特尔 2、《华为数字化转型：企业持续有效增长的新引擎》周良军、邓斌 3、《华为灰度管理法》冉涛
展开
研发
2022-02-15
我们为了真实的模拟用户的操作环境，特地做了一套跟用户环境几乎相同的系统，在这个系统上我们能重现用户遇到的所有问题。这套系统帮我们发现了很多问题
John Bull
2020-10-23
让自己多角度，特别是用户的角度来想问题，往往是最有说服力的。
作者回复: 有共情能力是一项珍贵的品质。
Matthew Chen
2020-05-30
尽可能地了解产品，从用户使用和商业运作等多个角度了解情况，帮助开发人员找到和前两者保持一致的执行路径。用户测试是国外很常见的一种实践方式，甚至在一些庭审模拟过程中也在使用。
作者回复: 很好的分享。
UnivTime
2019-03-04
1. 这是篇好文章，提醒了日常工作中重要却不被怎么提起的事项； 2. 开发自己使用不到的产品时最大的阻碍是，有些概念不理解，逻辑不太清楚，没有全局观，没法转换成编码语言；
作者回复: 鸡同鸭讲，是很多团队的硬伤。

