Photo by Venveo on Unsplash.本文来自微信公众号：caoz的梦呓（ID：caozsay），作者：曹政。
经常遇到问题，学什么有用，或者从事这个岗位比那个岗位是否对未来有帮助，说实话，我觉得很多年轻人钻了不必要的牛角尖，他们对职场经验的理解，非常的狭隘，似乎你的工作经验就是在某个极为具体而明确的技术工种上的从业资历，这让我想起一个古典的笑话，某个大酒楼高薪请来一个御厨，结果发现，他只会切葱。
关于所谓工作经验，说个极端案例，我以前做过站长统计，我就注意过，那些个人站长，个人开发者，用起不同的第三方统计工具，无师自通啊，根本不需要讲解啊，拿来就会用，什么数据干什么的一看就明白。但很多企业里做运营的，做数据分析的，你要从头给他讲，讲什么数据是什么意思，为什么要看这个数据，很多这样的课程，学几个月，学什么呢，如何理解最基础运营数据，并理解其与业务的因果关系。
这事有意思不，有的人一眼就看出来的东西，有的人要学几个月，甚至有的人干了几年的运营还是糊里糊涂，各种拎不清。如果你几个月几年的经验，比不过人家看一眼，这所谓工作经验的价值，是不是，尴尬了一点。
什么是工作经验，用一句老话说吧，“授人以鱼不如授人以渔”，学习的能力，比知识，更重要。
那什么是学习的能力呢？
其实说白了都很简单，发现问题，分析问题，解决问题。就是这种能力，好像很简单是么。
很多人会忽略第一点，发现问题。
为什么会忽略第一点，发现问题难道不是很简单的事情么？
发现问题也会有不同层级的问题，浅层级的问题很容易发现，代码报错、功能不可用、业务出现问题导致用户投诉、系统负载崩溃等等，是的，这些问题都很常见，但是我们想想，如果一个系统的业务漏洞被羊毛党薅出大问题了，才想起来补救；一个安全事故被黑客拖库并且公开了，才知道问题的存在，这问题造成的损失那是触目惊心的；又或者一个负载问题，到系统彻底崩溃长久恢复不起来的时候才知道去解决，是不是对业务的影响极大。
那如果能在问题暴露之前，自己未雨绸缪地发现问题呢？
那作为一个程序员，比如说，你会完成某个功能，你会某种开发语言或开发工具，你觉得这是你的工作经验，但你写这个功能的时候，你能考虑到安全的风险，能考虑负载的风险，是不是境界就不一样了，但如果你还能考虑到业务拓展性的诉求，知道低耦合高复用的原则，那就更上一层楼了。 那么这时候你想想，所谓安全，所谓负载，所谓耦合，和你使用的开发语言，开发环境，功能诉求，关系密切么？有一些关系，但其实更多的是通用性的思维对么。
作为产品，运营也是同理，你去处理某个诉求的时候，你按部就班的完成诉求是一种经验，你能想到这个设计中可能存在的运营风险，或者可能面临的一些挑战，比如羊毛党，比如恶意刷单，这是不是上一个境界了，当你运营一个产品，面临大量的用户评论，反馈，意见和建议时，能敏锐地感受到，这里存在的业务优化点和改进点，能通过日志分析找出沉默用户纠结和挣扎，以及流失的问题。这就是又上了一个境界。
回到最初提到的案例，为什么有些草根站长拿起第三方统计一看就懂，一用就会，他们对自己业务数据的熟稔程度太强了，对业务增长的执念太深了，所以任何第三方数据拿来后，只要搞清楚每个数据定义，立即就能清楚这个数据的意义和价值。这种执念和流量目标思维的根深蒂固，才能驾驭不同的工具，而很多打工的人是没有执念的，没有流量目标思维，所以只能根据工作需要，按部就班地对待数据，甚至要坐等领导的安排，才知道该看什么，不该看什么。
如果你对你所从事的领域没有执念，没有强大的目标思维引导，仅仅是按部就班，听从指挥的去工作，去学习，我告诉你，你的成长效率，就有可能是那种花了好几个月，好几年，比不上人家几天时间的那种。
一些不错的应届生，可能是算法高手，各种技术课程优秀的那种，但习惯于老师提出问题，自己去解决，而在职场还习惯于等别人提出问题，自己不擅长发现问题，那么很好的技术基础可能也会前进缓慢。职场的目标感，对所处业务领域和技术领域的执念，是带动你发现问题的动力。漫无目的地学习，试图通过提个问题让大V告诉你该学什么不该学什么，一上来就说明你自己不擅长发现问题。
我们知道，无论是技术，还是业务，你想上一个台阶，往往要面对一个词，优化。从技术方案的优化来说，系统性能的优化，架构逻辑的优化，可靠性、稳定性的优化，系统扩展性的优化。从产品和运营来说，用户体验的优化，业务支持效率的优化，转化率的优化，业务扩展性的优化等等。那一个系统，一个产品，正在线上运营，看上去也没出什么大问题，现在，有的人看看系统，看看产品，会觉得一切都ok啊，没啥问题；有的人就会觉得，到处都是问题，到处都是优化点，冯大辉老师就经常吐槽，某某知名产品，一堆操作逻辑问题，这就是发现问题的能力啊。很多时候，所谓经验，就是菜鸟看上去一切正常的地方，高手一看到处都是问题。
举个以前提过的例子，搜索引擎竞价排名系统，你说这很简单啊，谁价格高谁靠前啊，如果想更好的提升收入，仔细想想，这样够么，远远不够。百度凤巢的算法极为复杂和庞大，为什么？类似这样的案例很多，如果你设计facebook广告系统，如何利用已有的社交数据提升收入，如果你设计一个游戏产品，如何基于玩家数据和反馈提升产品收入，如果你设计淘宝系统，如何改进推荐和搜索系统以提升有效成交，这是一个又一个永无止境的需要发现新问题的场景。这些，都是工作经验。技术层面，产品层面，都需要不断去发现新问题。
下面说分析问题，菜鸟很多不知道怎么分析问题，甚至懒得分析问题。
你说数据库链接过多了，好啊，增加一下最大链接参数。你说内存缓存不够用了，好啊，加大缓存设置。你说服务器负载过高，好啊，申请新服务器。
这不问题都很容易解决么。
为什么数据库链接过多？为什么内存不够用，为什么负载过高，要知道具体的原因，具体的负载构成，然后要知道这个构成是否合理，是否有优化空间，不分析，简单粗暴解决，如果遇到的是所谓雪崩效应，这种解决方案可能没用啊，加一倍两倍的资源也都不够啊。
分析问题需要逻辑严谨，而不是停留表面现象。就好比，你看到一个地方房价贵，不能简单说，炒房团，或者开发商太坏，要想想是不是垄断供给导致的供给不足。你看到一个地方乱停车，不能直接说车主素质太差，要看看是不是停车位规划不够。你看到一个地方行人乱穿马路，你除了谴责行人无素质之外，是不是也注意一下最近的斑马线有多远。对问题的分析，不能停留在表面，要尽可能更深入地去理解。
有些程序员，遇到问题束手无策，连搜索引擎都不会用，然后抱怨没人教，学不到东西，就算真的能力有限，你自己至少能问出有质量的问题，能把问题描述清楚了也好啊，这也算是你认真分析过了。连描述都粗枝大叶，贴到社区或群里里，然后说为什么高手都不回答。
把问题能描述清楚，本身就是一种分析过程，证明你在你的经验技术范围内，已经对问题所涉及的各个环节都做了排查和数据的展示。你说这东西怎么教，就要靠自己的。
业务也是，用户流失了，怎么分析；收入下降了，怎么分析；获客成本又增高了，怎么分析，这些都需要找到真正的原因，而不是流于表面。所以什么数据代表什么，什么指标意味着什么，从日志里能不能看出用户流失的原因，类似这样的我旧文提过无数次。
能敏锐的发现问题，是职场最有价值，也是最资深的体现；分析问题需要严谨的因果逻辑和对数据，日志，业务熟稔的认知，以及一定的技术底蕴；而当这两点都完美时，你会发现，解决问题就变成轻而易举的工作了。很多从业者都有这样的经验，分析问题几小时，解决问题两分钟，很常见吧。
是的，这才是职场经验的真相。
那么，你再来反思一下，你会用什么编程语言，会使用什么开发工具，会用什么工具做设计图，真的很重要么？
我以前也讲过这个概念，用思想驾驭工具，你在什么场合，为了什么问题，基于对问题的认知和对工具的认知，选择合适的工具解决问题。这叫思想驾驭工具。
但很多菜鸟呢，工具奴役思想，我举个例子，会java了，言必称面向对象，似乎不面向对象的程序员都是该回收的古董。会C语言了，觉得不操作内存指针的也敢叫技术？这就是工具奴役思想，今天跑过来说mongodb牛逼，明天鼓吹redis无敌，看上去好像会的很新很高大上，其实都是知道基本操作而已，看过几篇新技术的评测报道觉得好像用这个很厉害，但实际上对不同工具的适用场景，优缺点根本稀里糊涂。
今天啰嗦了很多，我希望年轻人明白，所谓经验，不是具体的工具，具体的岗位，具体的某个操作能力，而是你能否敏锐的发现问题，能否细致认真的分析问题，当你对技术，产品，或者业务模式的认知达到一定境界的时候，那些工具，都是为你所用的，为你所驾驭的。甚至可以说，一样全新的工具出现了，基于你的认知和业务理解，看一眼手册文档，用不了几天就明白如何使用了。从一种数据库到另一种数据库，从一种语言到另一种语言，从一种数据分析工具到另一种数据分析工具，甚至从运维到数据分析，从研发到测试，从性能调优到深度学习，只要明确目标和方法，一通百通，举重若轻，并没有什么大不了的障碍和门槛。
以上，是针对很多关于职场方向，技术方向问题的综合回答，你要提高的是对技术的认知，对产品和业务的认知，对数据的认知，而不要纠结于所谓具体技术岗位的差异，开发工具的差异，技术选型的差异，从长远看，这点差异根本不构成职场经验的优劣。至于其他方面该如何选择，前文有提，不再赘述。
最后，简单复盘总结：
1. 在看上去很正常的系统、业务中发现问题，是非常能体现出经验差距的，这需要对技术，业务有足够的敏锐度和强大的目标感。进入职场的第一件事，就是要立即建立清晰的目标感，并基于目标感不断打磨敏锐度。
2. 分析问题需要正确的逻辑，能够找到真正的原因而不是流于表面。清晰的描述问题本身也是分析的过程，要想找到高手的帮助，自己也要做好足够的问题分析和描述，这样别人才能有效甄别和协助分析。
请问，数据库挂了，什么原因？ 有超过1000种可能原因，我该怎么回答你。
3. 让思想驾驭工具，而不是工具奴役思想。
请问，redis和mongodb哪个更好？先描述业务场景和技术诉求，才能针对性选择。
说句打击一大片的，所有脱离业务诉求前提谈技术方案优劣的，有一个算一个，都是垃圾。
4. 有足够强大的技术认知或业务认知，同一个领域内的不同岗位，不同开发工具，不同技术选型，很多都可以一通百通，无需纠结。
本文来自微信公众号：caoz的梦呓（ID：caozsay），作者：曹政。