很多朋友反映，IT岗位越来越卷，
涨工资也越来越难，
很多到了20K+，基本就涨不动了。
诚然，从外部环境来看，
互联网的风口红利早已淡去，
加上政策导向，对头部大厂已经极度不利。
整个行业，没有了“火车头效应”。
势必对技术基层的生存空间，产生挤压。
是不是意味着走技术路线，就将油尽灯枯呢？
也不尽然。或者说，实际情况恰恰相反。
君不见，扎堆的猎头们，
都在为各种企业搜索“高级”技术人才而疲于奔命，
所谓无利不起早，
高端技术岗位的佣金，
足以实现“半年不开张，开张吃半年”的光景。
也有些朋友反映说，
自己在技术面试的时候，感觉发挥得还行，
但在后面几轮面试中，
对方领导往往问一些“非技术的话题”，
感觉往往抓不到对方想要的核心，
再然后就没有然后了。
郁闷的是，很多人都不知道是怎么挂掉的。
高级技术岗位与普通技术的鸿沟，到底在哪呢？
面试的时候，
应该如何回应这些“非技术”的问题呢？
琦哥以多年撸码的经历，来作一点总结。
一般来说，一个牛逼的技术大佬，
会在两个层面区别于一般水平：
一个是技术层面，
一个是管理层面，
以及作为一个的管理者，
所需具备的一些“软实力”。
这个软实力，往往是最关键的，
也是最不容易被重视的，跟情商EQ相关的。
I、技术层面
先来说说技术层面，又细分为4个小方面：
一、T型知识储备
“T”字的横线，代表你的知识广度。
“T”字的竖线，代表你的知识深度。
1) 知识广度
所谓广度，
并不要求一个技术人对所有领域面面俱到，
而是具备把一本看似很厚的书，快速读薄的能力，
即，提取“框架”+”核心”的能力。
我相信并没有多少人能把
操作系统、数据结构、网络协议、编译原理、
各种中间件、编程语言 样样精通的，
除非他根本不是个正常人。
但并不妨碍我们把这个领域，
归集到某个稳定的认识框架中去。
就像一个图书管理员，
知道一本书，应该摆在书架中上某个位置。
以及有没有其它类似的书籍条目，
以及有它们之间的相关性。
知识广度，就是为你绘制一张“知识地图”，
在你需要的时候能快速找到它。
与图书馆员不同的是，
你还需要知道这本书，讲了一个什么故事。
即它的“中心思想”，或者说它的本质是什么。
这个很重要。
操作系统的本质是软硬件的协调，
数据结构的本质是时间与空间的平衡，
网络协议的本质是分层管理，
编译原理的本质是有限状态机，
C语言的本质是指针，
Java语言的本质是OOP，
Python的本质是粘合剂，
Scala的本质是MapReduce，
Go的本质是轻便，
云原生的本质是架构与逻辑的解耦，
虚拟化的本质是无缝迁移，
分布式的本质是高可用与弹性伸缩
……
计算机技术的本质无非就是横向并行、纵向分层，
以及它们之间缓存与缓冲技术。
从CPU内部多核架构，到主板的GPU与CPU并行，
到如今各种微服务架构，
这些都是“横向并行”在不同层次的表现；
从汇编、OS、虚拟机分层，到网络协议分层，
到前后端分离，再到各种业务中台、数仓分层，
再到现在的K8S/Istio/CloudNative架构，
这些是“纵向分层”治理的模式；
CPU中间各种的L1/L2缓存，到磁盘Buffer，
到DNS，路由表，再到浏览器localStorage，
到Redis、RabbitMQ等等，都是缓存和缓冲技术，
是为了解决信息在横向、纵向的传输过程中，
速率不匹配的问题。
所谓融会贯通，就是利用这些东西的设计思想，
不管对与错，总结出自己的一套理解。
当遇到新的知识时，
只是把新书放进老的书架中去，就容易得多。
有了“框架”+“核心”，
你对趋势的把握就轻松得多，
你就是IT领域的“老中医”，
你就是趋势，
你就是核心，
或是被别人抢相追捧的一坛“陈年老酒”，
也就不会再有“搞IT就是吃青春饭”
这种无谓的低级苦恼。
2) 知识深度
或者说技能深度。
这个其实没什么好讲的，
人总要有个吃饭的家伙。
你应该是某个领域的“看起来”非常擅长的，
你自己n不nb不重要，
让别人认为你在这个领域里最nb（可以是之一），才重要
至少你要给自己打上这个标签。
这就是“个人品牌的差异化”战略。
这对于超过30岁的程序员尤为重要。
比如在“金融科技”领域深耕5年，
“C端消费互联网”资深开发工程师，
“企业级信息系统”架构专家。
名字自己想，但必须得有。
这样，你才能区别于普通的底层码农，
从HR的简历堆里脱颖而出。
二、架构设计能力
架构这个词近年来都被吹烂了，
随便写个设计文档，改个依赖包，
搞定性能问题，甚至改个烂bug，
似乎都是架构师天经地义该干的事。
关于架构，权威的定义是
为了实现系统目标，而定义的组件、以及它们之间的关系，
以及围绕它们的一些规则。
TOGAF 规范里面分为
业务架构、应用架构、技术架构、数据架构 四种。
但是，这些都说得说太文绉绉了。
其实，架构就是一种结构、模式、模板，
在具体场景下的变通实现，
大到业务集群，中到网络规划，小到编程套路，
都可以算做架构。
为了代码的可维护性而且添加的设计模式，
为了实现可扩展性而抽象出来的通用接口，
为了给团队分派任务而切分的开发边界，
为了给领导汇报邀功而画的架构图，
都可以算作架构。
说到底，所有的架构，无一例外就是要解决5个问题：
-
扩展性，在变化面前争取最小的改动
-
高性能，能扛住各种流量各种搞
-
可用性，系统稳定性好，不会分分钟BBQ
-
可拆解，分而治之，复杂的问题拆解成若干小问题，并且适合多人同时开工
-
可吹牛装B
关键是自己平时撸码时候要多总结，
对一切套路的总结，就是架构。
当然，思而不学则殆，可以结合几本经典书籍，
你可以将你的野路子，
与行业高手们神交、对齐、吸取。
什么 DDD 里的战略和战术建模，
什么有界上下文，贫血模型，
什么实体、聚合根、值对象，
业务对象，领域对象、防腐层、
六边形模型、事件源模型
你可以不求甚解，
但你要知道这些名词，大概是在解决什么问题。
这样你的思维才越来越清晰，结构化。
千万不要把架构理解成只是架构师的事情，
每个技术人员都或多或少要有架构思维，
而架构师只是个title而已，
业内也有很多伪架构师水得不行。
所以，不用觉得很玄乎。
架构可以是装B吹水的代名词，
也可以是帮你梳理思维的工具。
三、Trouble Shooting Skill
说直白一点，就是你的填坑技术要好，
遇事不慌，可以先发张朋友圈，淡定自如的那种。
这当然需要你一定年限的经验积累，以及总结归纳的能力。
日志分析法，回滚法，白盒法，排除法，替换法，二分法，
再加上祖传的重启大法。
对于难搞的问题，你的工具箱和方法论，至少能给3个以上的可选方案。
当某个问题把所有同事搞到殚精力竭的时候，
你具有扛着炸药包继续顶上的能力。
四、擅于总结与分享，输出影响力
关于分享，
很多技术人会不重视，觉得跟KPI没有直接关系，
且技术人普通羞于表达，准备一次分享，耗时耗力。
但是，通过跟他人分享，
会给个人带来巨大的“软性价值”。
首先，根据“费曼学习法”，通过向他人讲授的方式，
你能高效的将知识体系有机的组织起来，并在大脑中强化印象。
一直输出，双方受益。
其次，通过向他人讲授，你其实正在输出自己的影响力，
以及更容易获得他们的信任。
这将在今后的沟通中，形成价值交换的“隐形价值”。
会更有利地推动跨部门事宜。
再次，在互联网时代，你对某个领域的总结整理，
以技术博客或B站视频的方式 输出，
有利于建立自己的长期口碑，和技术权威，
成为你跳槽面试装B的加分项。
II、管理层面
再来说说管理层面，很多人工资长期卡在20K，
就是对工作中的管理技能重视程度不够，
或者说缺乏训练，
琦哥曾经也沉醉于“我技术牛逼，仗剑走天涯”
这种一根筋式的自我麻痹。
直到路越走越窄，甚至“众叛亲离”，
才方知须对自己的认知进行全盘升级。
所谓管理，就是从“非技术”角度去看待问题，
这里面包括“自我的管理”。
我这里讲的不是“番茄工作法”这种自我管理，
而是认知的切换，视角的切换，
才能脱离“技术缰绳”，认知拔高一个纬度。
客户视角，销售视角，运营视角，运维视角，
个体视角，部门视角，财务视角，老板视角，
员工关系视角，等等。
从技术角度只能看到一个一个的技术“点”，
需要在不同的视角下，连成一根有脉络的“线”，
甚至感知到是一个“面”的范畴。
视角越多，看到的问题就越立体，
思路就越灵活，
解决的方法就越多，
与他人沟通就越有同理心。
然后才是回到“管理”二字。
首先得“管”，然后才是“理”。
“管”的是目标、进度、风险、
“理”的是流程、工具、文化。
对于 IT 技术的管理，我个人拆分成6个维度：
一、团队管理
从招聘、再到培养，以及绩效与激励，
并辅之以适当的培训步骤，
再到储备干部的识别与选拔，
整个周期都属于对人的管理范畴。
怎么识别潜力员，怎么根据不同个性的成员，
施以特定的引导，在团队中发生化学反应。
怎么对不良行为和态度以予纠正，
需要像良师益友一样温和的辅导。
在这个过程，建立自己的leadership。
关于leadership，
以后如果有时间，以后再深入谈谈。
二、流程管理
包括流程与规范。根据业界标准研发规范，
比如瀑布模式，或者SCRUM模式
结合公司实际情况进行裁剪。
以及相应的标准化输出项检查标准，和报告模板。
其次是规范，这里面又包含
编码规范、接口规范、数据库规范
SQL语句规范、异常处理规范
日志规范、安全规范、运维规范等等。
以及相应的模板，比如
需求PRD文档模板
架构设计文档模板
详细设计文档模板
验证测试报告等等。
流程其实就是一套固定的工作流+模板。
三、项目管理
项目管理能力应该是任何带管理性质岗位所必须的，
这里不再赘述，
最关键的就是识别关键路径与风险，
以及变通与协调资源的能力，
具体可以参考PMP的方法论。
四、风险管理
IT公司的核心资产就是信息本身，
所以信息安全的防范，需要一套规章制度，
当然这个是CTO这一级别需要关注的。
其次是运维安全，尤其是SAAS产品的公司，
系统运维的稳定性，是这家公司的生命线。
再具体一点就是可观测性、可用性、灾备系统，
以及配套的应急响应流程。
五、工具管理
关于工具，对于IT公司的最重要的，
就是维护好的一好用的自动化构建与部署（Devops）工具链。
然后是自动化测试工具的使用，与覆盖度的持续铺开。
再次就是需要有一套成熟的APM监控平台，
以及相应的预警、告警、通知。
有了成熟的监控系统，才不会闭着眼睛开车。
六、文化建设
这个相对较虚，
但是成熟的管理者，需要具备一定的务虚的能力。
兵熊熊一个，将熊熊一窝。
一个团队的文化氛围，与leader个人的行事风格有很大关系。
好的技术leader，应该是倡导开放思维、
鼓励创新、包容试错的价值观。
这并不是口号，而是在现实工作情况中，
相对于稳定性、效率、纪律等价值观的
相对排序，和相对倾向。
当价值观存在冲突的时候，
在特定条件下需要进行取舍。
III、软实力
一个nb的技术人，一半要方法论，一半要天赋。
与其说天赋，倒不如说它是一种“软实力”。
与他的性格、气质、品行，甚至个人魅力有关。
一、专注力
首先，他需要有专注力，
它的外在表现就是人们常说的“责任心”。
更具体来说，
-
对TA所在领域，有持续深入的思考。
-
TA绝不被动做事，对现实中的各种事项有价值判断，对实现路径有反复的斟酌。
-
一旦敲定实现步骤，落地速度极快。
二、不情绪化
一个技术牛人，或者一个好领导，
是很难被情绪化的。
不骄不馁，犹如大厦中的阻尼，稳如老狗。
是团队中的心理支柱。
三、人品
人品好，被人尊重。
吃得了小亏，扛得起锅。
能帮小弟们排疑解惑，
也能为下面的手下的利益，据理力争。
对下属不苛求，“因才施策”。
四、说服力
也就是口才好，但也不一定是口若悬河。
而是语言的逻辑性严谨，洞察沟通对象的隐形需求，
能找到切入点，达到目的。
这样才能在跨部门协调中游刃有余，
向上管理，向下宣导都需要这项能力。
五、共情力
有同理心，是很多技术人是严重缺少的。
外在表现就是沟通过程中一根筋，缺少换位思考。
能晓之以理，但做不到动之以情。
如果能补齐这块短板，
将极大提升他的职场生存效率。
六、度量大，能容人
在识人用人上，做到不拘一格。
有曾经一些与我有过冲突的团队成员，
最终成为了我最好的合作助手，
以及生活中的好朋友。
哪怕遇到昔日的对手，只要时机尚可，
能做到摒弃前嫌，互相勾兑，互相提携。
毕业前3年，可以单打独斗。
但再往之后，
你需要越来越多的战友和伙伴，才能成事。
但越nb的人，往往越有一些小个性和怪脾气。
唯有包容，路才会越走越宽，
朋友也会越来越多。
七、雷霆手段
前面说的都是怎么做一个“老好人”，
但有的时候，需要具备一定的铁腕，
该下手时，能下手。
好的管理者，
其实就是90%的和蔼可亲，加10%的心狠手辣。
好了，讲了这么多。
总结一下，牛人=技术+管理+软实力。
其中每一项又细分多个维度。
可能有很多方面，我自己也没有做到。
把它们列出来，希望能在工作和生活中做得更好。
也希望能给正在职业迷茫期的朋友们，
一点浅薄的建议。
谢谢。
文章出处登录后可见！
