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