这“阅世”两个字，刚开始我也是听得一头雾水。
我刚入行那会儿，大家都在聊技术栈、聊框架性能，突然有人冒出来一句：“这项目得找个阅世深的人来带。” 我当时就懵了，心想这是什么新鲜词汇？难道是哪个新的技术名词？还是行业黑话？
后来混久了，在各种场合听多了，才慢慢摸索明白，原来这玩意儿压根儿就不是技术活，而是纯粹的“经验谈”。
我记得有一次，我们团队接了个大需求，要做一个用户行为分析平台。产品经理画了一堆图，讲了一堆概念，我们一帮技术人员就开始埋头研究用什么技术栈，怎么搭架构。架构搭完了，项目启动会，领导突然点名让我一个刚毕业没多久的小伙子去牵头。
我当时就懵了，感觉完全HOLD不住。架构设计我能啃下来，数据模型我也能跑通，但涉及到真正的业务流程和用户习惯的把握，我心里是虚的。我赶紧找我们组里一个快要退休的老前辈求助。
那位老前辈听完我的描述，笑呵呵地拍了拍我的肩膀说：“小伙子，你这不是技术问题，是‘阅世’不够。”
他接着说，技术架构是死的，按部就班能搭起来。但一个产品要跑起来，靠的是对用户心理、市场走向、乃至公司未来战略的理解。这就是“阅世”。
阅世，说白了就是看世界的经验积累。
我开始琢磨，啥叫经验积累？
我当时回想了一下，自己就是埋头写代码，项目上线了，数据指标不好看，老板骂一顿，下次优化一下。基本就是按部就班，缺乏对全局的把控。
我开始改变策略，不再只盯着代码和文档。我强迫自己去参加各种跨部门的讨论会，哪怕听不懂他们在聊什么商业模式、市场占有率，我也坐着听。
我跑去问运营，用户为什么不用我们这个新功能？他们回答了一堆数据和运营策略，我记录下来，反过来思考，这些运营动作对我的技术实现有什么启发？
我还特意去研究了我们公司历史上失败的项目，分析为什么失败。是技术不行？还是市场没看准？慢慢地，我发现很多技术上看起来完美的方案，在真实世界里就是走不通。
比如我们早期做过一个推送系统，技术上完美实现毫秒级响应。但用户画像没搞清楚，推送的内容全是他们不感兴趣的，结果就是用户把推送关了，或者直接卸载APP。这个教训对我触动很大，这就是典型的“阅世不足”，光会修车，不知道路该怎么开。
后来每当团队遇到争议，比如对某个需求的优先级卡住了，或者对未来技术方向拿不定主意时，大家就开始问：“有没有阅世的人给参谋参谋？”
这时候，那些经历过几次产品大起大落、见识过不同商业周期的老人们，就能一针见血地指出问题的关键。他们不是说哪个函数写得好不而是直接告诉你：“这个方向会死，因为三年前我们试过，用户根本不认。”
这就是“阅世”的力量。
当你听到别人说“这个人阅世很深”，千万别以为他在夸你代码写得多牛逼，他是在说你对这个世界的复杂性理解得够透彻，能从经验里提炼出规律，少走弯路。
我现在努力的方向，就是多看，多想，多经历不同行业的坑。只有真的踩过坑，才能真正理解“阅世”到底意味着什么。
