36丨技术落地之道：你真的知道自己要解决的问题是什么吗？

Feb 17, 2020

36丨技术落地之道：你真的知道自己要解决的问题是什么吗？-极客时间



下载APP





关闭

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

渠道合作

推荐作者

36丨技术落地之道：你真的知道自己要解决的问题是什么吗？

2020-02-17 李智慧来自北京

《后端技术面试 38 讲》

课程介绍



讲述：李智慧

时长09:56大小7.95M



做软件开发，其实就是用软件的手段完成业务需求，而业务需求一定是用来解决某些问题的，用户的问题、老板的问题、运营的问题等等。软件工程师常常疲于奔命，开发各种需求，但是这些需求到底想要解决什么问题，开发完成以后是否真的解决了问题，实现了功能的自身价值。对于这些问题，很多开发者常常既不了解，也不关心。
我们讲一个小故事吧。北欧有一个度假胜地，是欧洲人民夏天避暑度假的好去处，去度假胜地需要经过一个长长的隧道，隧道的工程师为了保证隧道的安全使用，在隧道入口处立了一块牌子，写着：请打开车灯。
游客们开着汽车，打开车灯，穿过隧道，到达度假胜地，愉快地去玩耍了。而等他们要回去的时候，有些人却发现车子无法启动——他们忘记关闭车灯，汽车电池耗尽了。小镇的警察们只好开着自己的警车四处为游客们充电，疲惫不堪。而沮丧的游客们则在回去以后四处抱怨，分享他们糟糕的旅游经验，导致小镇旅游业大受影响，镇长压力山大。
于是人们找到隧道的工程师，要求他在隧道的尽头再立一块牌子，写上：请关闭车灯。工程师照做了以后，却发现麻烦来了：夜晚穿过隧道的游客看到牌子，虽然非常疑惑，但还是按照指示关闭了车灯，结果却发生了车祸，麻烦更大了。于是工程师不得不写上：如果是白天，请关闭车灯。结果有的游客没看到隧道入口的牌子，却看到了隧道出口的牌子，同样疑惑。为了解决新问题，工程师不得不在牌子上继续写下去⋯⋯
这个场景和软件工程师们日常的工作场景是不是很相似？总有客户、老板、产品经理过来跟你说，这里需要这样一个按钮，那里需要这样一个功能。你照做了以后，发现带来了更多的麻烦，为此，你不得不在代码里不断地写 if/else。你不是在解决问题，而是在制造问题。
回到这个故事，我们重新思考一下：这是谁的问题？谁能够解决这个问题？如果这是镇长的问题，那么能不能让镇长在停车场修建充电桩让游客们充电？如果这是警察的问题，那么能不能多招一个警察，专门帮游客充电。如果这是游客的问题，能不能在隧道出口立一块牌子，写上：你的灯亮着吗？提醒他们问题的存在，让他们自己去解决问题。
所以，你在每次解决问题的时候，是否想清楚了问题的本质究竟是什么？这是谁的问题？谁能解决这个问题？你在为谁解决问题？这些问题决定了你是否能真正解决问题，为公司创造价值，也决定了你是否能选择最合适的技术去解决问题，进而提升自己的技术能力以及自己的技术影响力。
作为一个软件工程师，如果只是听从别人的指令开发代码，却不了解这些代码究竟想要解决什么问题，那么很多时候你是在制造问题，而不是解决问题，你加班加点辛苦工作只是在为公司制造麻烦。而对于你自己而言，日复一日重复执行解决方案，距离你成为一个技术专家也越来越远。
关于如何发现真正的问题，这里有几个小的建议，供你参考。
不要把解决方案当作问题的定义，而忽略了真正要解决的问题是什么我工作这么多年来，经历过很多公司，参加过很多次技术会议，就我所见，几乎所有的技术会议都没有有意识地讨论过一个主题：这个会要解决的问题是什么？
很多时候，会议一开始就讨论解决方案。有的会议上，产品经理上来就说我们需要一个什么样的功能，请技术部门给一个技术方案和工作量评估，至于这个功能用来解决什么问题，给用户或者公司带来什么价值，几乎很少说明。有的会议上，架构师上来就说我们打算推广一个什么样的技术，请相关技术团队配合，至于这个技术用来解决什么问题，给用户或者公司带来什么价值，也几乎很少说明。
所以，这样的会议，讨论的重点就是解决方案本身：这个功能怎么做，这个技术怎么应用落地。而不是讨论真正的问题是什么：为了解决真正的问题，这个功能是不是必须要做，有没有更好的解决办法；这个技术是不是必须要上，能不能带来足够的价值。
这样的会议，即使有争论，争论的也是解决方案本身，而不是问题。关于解决方案的争论又往往陷入各种细节之中，经过一番讨论，更加不知道要解决的问题是什么了。
所以，以后参加技术会议的时候，也许不需要急于参与到讨论之中，而是要多思考：这次会议把要解决的问题说清楚了吗？需求背后真正要解决的问题是什么？当前讨论的内容真的能解决问题吗？
想清楚了这些，你会对当前的局面有更加清晰的认识，你会发现其他与会者的激烈争论，都是在盲人摸象，自说自话，彼此的关注点根本不在同一个问题上。
这个时候，你出手把大家拉回到问题本身，主导会议的讨论方向，你就会成为最有技术影响力的那个人。
你不需要去解决别人的问题，你只需要提醒他问题的存在在有关育儿教育的经典书籍中，对于如何面对婴幼儿的哭闹，比如小孩子摔倒了，开始哭闹的时候，给出的解决方案是，不要立即鼓励小孩子，要让他们勇敢一点，自己爬起来。更不要斥责他没出息，走路不小心什么的，而是把他抱在怀里，轻轻在他耳边说，（爸爸）妈妈知道你摔疼了。重复这句话，直到小孩子不哭了，然后再跟他说，你是个勇敢的孩子，你可以自己面对的，下次你可以自己爬起来。
在这个例子中，小孩子摔倒了哭，是谁的问题？当然是小孩子自己的问题，但是他太小，又处在巨大的挫折之中，无法独自解决问题。所以，父母这时候要做的是，安抚好孩子的情绪，告诉孩子，爸爸妈妈和你在一起，理解你的痛苦。等他从挫折中恢复过来，不哭了，然后鼓励他，让他自己解决问题。
我们开篇那个隧道车灯的故事也是如此，忘了关闭车灯导致汽车无法启动是谁的问题？是游客自己的问题。谁最适合解决问题？是游客自己，他只需要关闭车灯就可以了。所以镇长设立充电桩，多招一个警察帮游客充电，都使问题更加复杂。但是游客又没有意识到问题的存在，所以不去解决问题。那么要做的事情就不是去帮游客解决问题，而是提醒他问题的存在：你的灯亮着吗？游客意识到问题的存在，他就会自己解决问题。
软件需求开发中，也有很多帮用户解决问题的场景。日常开发中，产品、运营、开发、测试、运维，也有很多交互合作，需要互相帮助；哪些问题对方可以轻易解决，哪些问题应该通过修改软件功能来解决，应该思考清楚。
鱼是最后一个看到水的，身处问题之中的人往往并不觉得有问题身处问题之中的人常常并不能感知到问题的存在，正如身在水中的鱼儿看不到水一样。太多的问题被人们的适应能力忽略掉了，直到有人解决了这些问题，身处其中的人才恍然，原来过去的方式都是有问题的。
所以，如果你到一个新环境中，发现存在着一些问题，而身处其中的人却熟视无睹，往往不是他们有问题，也不是你有问题，可能只是他们已经适应了问题的存在，而你还没有适应。
关于问题的定义有个公式：问题 = 期望 - 体验。
到一个新环境中，大家体验差不多，但是你的期望和其他人不同，你就会感受到问题。而这种感受则可能是你出人头地的机会：如果你解决了这些问题，其他人也会明白过去的方式是有问题的，而你就是那个解决问题的人。
小结一个技术，是不是真的能解决问题，是衡量一个技术是否有效的主要标准。而业务究竟遇到了什么问题，用什么样的技术才能真正有效地解决问题，是工程师在进行技术落地之前必须要考虑清楚的事情。
不去思考，真正地面对问题，总是试图用自己擅长的技术，或者业界热门的技术解决工作中看似一样，其实大不相同的业务问题，既不能够真正解决问题，为公司创造价值，也不能够提升自己的技术水平，获得真正的进步。
如果自己用技术总是能有效解决问题，在这个过程中，也会不断增强自己的技术自信，知道自己用技术可以创造真正的价值，自己可通过技术参与到改造世界的过程中，也会树立起技术的信仰。不会总是犹豫，自己是不是要转管理，是不是要转行。
思考题隧道车灯的小故事对你有什么启发？
如果你是一个管理者，你团队某个员工工作不认真，工作效率低，是谁的问题？是公司的问题吗？是你的问题吗？是员工自己的问题吗？如果是员工自己的问题，你该如何提醒他问题的存在，并进而帮助他提高工作效率？
欢迎你在评论区写下你的思考，也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

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

生成海报并分享

赞 16

提建议

35 | 技术进阶之道：你和这个星球最顶级的程序员差几个等级？

37丨技术沟通之道：如何解决问题？

 写留言

精选留言(21)

任鑫
2020-02-23
总觉得，智慧老师这个专栏，越到最后干货越多，层次较高的问题都不是哪个行业独有的，几乎干啥都会遇到，教育小孩和做团队leader有相通之处。青青翠竹尽是法身,郁郁黄花无非般若。
28
任鑫
2020-02-23
我觉得隧道装灯比较好，向用户提一个新要求会带来一大波解释成本和培训成本。
共 2 条评论
23
learn more
2020-04-14
员工工作不认真，效率低下，到底是谁的问题。有可能是公司文化的问题，新员工不赞同公司文化等，老员工已经适应；有可能是团队leader作风问题，leader的形式作风很容易就影响到个人，办公室政治就是来自于此；有可能是个人，个人心态已经崩溃，不再相信公司文化，不再坚信所做的事情有意义，那么工作就会不认真，效率自然也就低下。
展开
共 2 条评论
10
Song╮承諾
2021-01-21
我主动帮他一起开发了，但并不能改变他的工作态度，而我自己的工作内容增加了。想知道正确的解决办法。
作者回复: 1 你不是救世主，你能帮助别人，但是不能拯救别人。 2 在工作中如果帮助别人不能让你得到回报，包括不限于：打造威望，锻炼技术，提升下属等，那么你就该考虑是不是还要继续帮助下去了。
6
meta-algorithmX
2020-02-17
正所谓，正确定义了问题就解决了一大半问题。在真正定义问题之前往往需要在心理表征上先做好这样的两个事情： 1. 首先明确，目标是奔着解决问题去的。 2. 识别对方是不是真正想解决问题，正所谓“你无法叫醒一个装睡的人”。之后推动事情向前走的动力就不完全靠 “分析问题” -> "定义问题" -> "解决问题"的套路来进行，期间可能需要一定的行政手段、政治手腕和说服的艺术来推动事情向正确的方向发展。当然，如果你身处的环境是一个已解决问题为统一目标的环境，以上的这些问题都不是问题，关注问题本身就好。
展开
5
escray
2020-10-20
开篇的故事来自于温伯格的《你的灯亮着么：发现问题的真正所在》中的第 13 章，隧道尽头的灯光。故事很短，也很有趣，推荐阅读。专栏中的追命连环问很有价值，“问题的本质是什么？这是谁的问题？谁能解决这个问题？你在为谁解决问题？”，“这次会议把要解决的问题说清楚了么？需求背后真正要解决的问题是什么？当前讨论的内容真的能解决问题么？”，估计大部分时候，都经不起这样的连环夺命 Call。隧道车灯的故事，可以提醒我，认真去考虑究竟是谁的问题。但是如果领导把问题扔过来，我是没有办法抵挡的——最终解决问题的其实还是那个工程师，他挂牌提醒了司机，“你的灯亮着么？” 团队成员工作不认真，当然是他自己的问题，管理者只要尽到提醒的责任即可；如果是工作效率低，那么就要认真去看一下，是哪方面的原因。如果效率低下的原因来自于团队或者环境，那么管理者就有责任去改进。管理者可以提醒、可以提供帮助，如果确定是员工本人的原因，并且改进效果不好的话，尽快让该员工离职，也许才是最好的选择。
展开
4
苗
2020-08-24
工作不认真，很大概率是员工个人态度问题；一个解决方案是洗脑；工作效率低，有可能是公司问题，没有高效率的开发过程管理，高效率的交流渠道，解决方案是关注软件开发过程的敏捷；也有可能是员工自己的问题，如基础差，理解设计能力差，可以组织员工有针对性的学习相关知识或者结对编程以及引入代码评审。
4
E
2020-09-17
隧道车灯的小故事对你有什么启发？可以研发自动适应环境的车灯，事实上，现实世界也都这样了。
共 1 条评论
2
不要挑战自己的智商
2020-08-04
启发就是：不要企图自己能控制所有问题，解决所有问题。不要低估别人的主观能动性。一个同事工作不认真，有可能谁的问题都不是，而是匹配问题。或者彼此目标不一致。解决方法是是沟通，但也别指望沟通能解决所有问题。不能解决的算了。
2
LIKE
2020-07-07
项目决策权在高层，高层和基层之间的信息又很少互通的，所以在隧道口频繁竖牌子的现象就比较常见。如果规避？1.基层领导做好双向信息传递 2.基层员工做好信息反馈。关于第二个问题，没有太好的解决方案，大体就是谈话，通过找当事人、合作比较多的同事（开发、测试、前端、产品）去谈话，了解实际情况，定位可能问题所在，如何鼓励就不知道 ... 希望老师能给个参考解决方案
展开
2
G7-华仔
2020-05-29
全是干货，思维方式的转变。问题定义不清楚后面所有的工作都是零。把问题根源是否清楚作为一个思考习惯，通过问问题能激发思考和创新力。
2
山猫
2020-02-17
不想回答思考题，想说说自己遇到的几个问题： 1. 当某个分类/操作下没有商品/不可用时，该分类/操作是否需要展示/显示； 2. 用户订单跨月完成或退款时，该如何统计和清算； 3. 产品说这个需求很简单时，我该几点下班？
1
辉度
2023-01-15 来自浙江
“身处问题之中的人往往并不觉得有问题”，这句话又一次让我想到了大学期间数字电路这门课程的一个实验： > 实验的内容很简单，用某一个型号的芯片，加上一堆电线，在一个有脉冲、数字显示的机器上，实现一个时钟。从写代码的角度来说，很简单，维护小时、分钟这两个变量就可以了，一个对24进行取余，一个对60进行取余，再输出就行。说实话，动手前，我和队友老陈都觉得两个课时的时间太充裕了。就是分成一个24进制和一个60进制的显示即可。我们从两个人分工两个模块和共同完成的决策中选择了共同完成，毕竟想着时间也充裕。实际上，我们面临的问题是代码编程遇不到的，因为有些芯片是坏的，有些电线也是坏的，相当于我们代码写了`a=1+1`，结果a返回不是2,还是0。我想这个问题，平时写代码时我们肯定不会去考虑，默认了它就必定返回2吧？**计算机到底是怎么保证这个计算结果是可靠的呢**？所以我们很多时间在“debug”，通过计算，实验，确定刚接起来的几根电线和芯片到底是哪个出了问题。随着时间的过去，仪器上的电线已经乱成一堆大麻花了，对我们的眼力和记忆都开始造成了考验，这时候，是两个人共同来工作的重要性也就体现了，两个人来确认，失误的概率就很低。最终，我们在下课后2分钟完成了这个实验，感叹啊，激动啊。过了多年，再来反思： 1. 如果我们事先校验每一个芯片、电线是否正常，是否会降低后续的排查痛苦呢？ 2. 如果不是双人合作，分成两个模块，在会“冲突”的仪器上，我们会不会乱作一团？ 3. 如果不是双人合作，面对问题的分析计算、重新接线的过程中会不会出现更多失误？ 4. 以及，老师是不是应该事先告诉我们，这个实验可能会面临各种各样的仪器上的问题？对应我们现在工作中，是不是印证了一些事情的必要性： 1. 做好单元测试，再进行集成测试是十分有必要的 2. 在合适的情况下，进行划分模块，没有过多冲突才是合理的 3. 结对编程在应对困难的问题时，两个脑子共同运转是`1+1>2`的。 4. 信息很重要，没有事先准备好信息，了解清楚问题，过程就会十分混乱，如陷泥潭。
展开
1
java小霸王
2022-07-10
启发：一个问题如果想知道本质可以通过连环追问的方法，直到问题本质
炫炫
2021-05-16
这本书真有意思，你的灯亮着吗
whoami
2021-04-30
学而不思则罔，思而不学则殆。焦虑使人贪婪地、囫囵吞枣地去学习，却忘了学习是为了解决自己的焦虑。老师的文章总使我想起了酒剑仙……
北极的大企鹅
2021-03-25
有些问题测试和产品一说产品一定就那样了但是技术方面其实这个点是有不同意见的为了改善一个没必要的用户提醒而不去提示问题真正所在后来我觉得那也适应一下问题吧但是这个问题我可不会记得的
展开
北极的大企鹅
2021-03-25
有点相似的问题
米亮
2020-04-05
有时候期望值也是虚高的或者不切实际的
梁中华
2020-03-22
确实，每次和产品开会我总会提醒他们，这个项目的背景是什么？

