网络安全科技企业，最宝贵的就是人才。一般来说，企业70%左右的成本都是人力成本，没有合适的人，一切远大的科技理想都是镜中花水中月，沦为空谈。雷军曾说过：“找人是天底下最难的事情。”在创业初期，雷军恨不得花费150%的精力找人，他曾经在一周内有5天、每天超10小时说服一位跨国公司高管加入小米，这些都充分说明了人才的重要性，以及高端人才的稀缺性。一个研发管理者，一年中我认为最少需要拿出20%以上的精力来招募和培养人才。

人是复杂的，千人千面；人也是有共性的，趋利避害，合力向善，这些不会随着时间改变。安全研发人才，既有人的共性，也有群体的特点，同时也有个人的个性。下面就具体谈谈如何做好研发人才的招聘工作。

一、研发团队模型的建立

研发招聘是个体系性的工作，招人之前先别急，首先要知道自己的团队模型该怎么设计。什么是“合适”的研发团队模型？——就是最有效率的模型；什么是最有效率的模型？——研发效率就是质量、进度、成本最优，即：能够快速研发出高质量的产品，同时也有合理的整体成本的模型。

科技企业之间的竞争，在方向上没有出大问题的情况下，剩下的主要因素其实就是看谁的效率和成本最优。

为什么把这个事情放在最前面？因为这是招聘研发工作的最初始的起点，也是招聘策略建立的起点，同时也是后续人才管理模式的起点：没有研发模型，就不知道你组建的团队是否能支撑研发工作的成功；没有研发模型，就不知道给你的预算够不够用；没有研发模型，就无法知道需要什么样不同层次技能的人才；没有研发模型，就没有贯穿指导后续人才育用留的核心思路。上述，几乎是贯穿关于研发人才所有环节的核心起点（指导思想）。

A、我们需要什么样的研发团队模型

建立一个合适的研发模型，主要需要考虑2个因素：团队人力预算，以及具体产品的阶段。

1、团队人力预算

首先看预算，因为研发管理工作本质上就是一个投资的行为，需要计算产出比。如果是Google，就基本可以不考虑这个问题了，找全世界最优秀的人就好。但是实际情况，不同的行业，不同的公司阶段，薪资行情都是不一样的（这是企业现状决定的），而人才却几乎是通用的，自由流动的；另外，钱也并不是成功的唯一因素（这里我认为薪资需要跨越中等线，否则其它因素难以发挥作用）。所以，这里设计模型的时候一定要务实，不要走极端，多构思想办法。历史上华为等民族企业，比起外企，最初的时候薪资也不是最高的。但是这么多年下来，很多高大上的外企倒下了，华为走到了前面了，这个就和打扑克一样，最初的牌不一定是最好的，但是通过合理组合，最后也能赢下来，这是管理者最闪光之处。

讲预算，并不是要做血汗工厂。企业和人才，合理的关系，我认为是正向博弈、双赢多赢。人力成本居高不下，企业会失去竞争力跨掉，人才也树倒猢狲散了；成本过低，找不来优秀的人才，也是对知识的不尊重，企业也一样会垮掉；只有匹配企业中短长期目标的、匹配行业盈利水平的预算，才能支撑企业发展起来，从而人才的回报也会持续上升，达到正向博弈的多赢结果。这个道理，管理者要懂，人才也需要懂。

豪华的预算，可以招聘最顶尖的人才来组成。优秀的人总是喜欢和优秀的人为伍，优秀的人遇见强者会激发起强烈的斗志，从而整体素质上一个大台阶，产生超越预算的创造力，且可选择最有难度的研发领域进发，比如AI、新能源、IC，等；

低于中线的薪资预算，那就选择一些中等以下难度的产品，降低人的自由发挥度，固化流程，建立梯次，降低毛利预期，通过扩大规模复制实现盈利，如富士康。

重点说一下中等偏上的预算，这是大多数管理者现实遇到最多的情况。往往中等偏上的预算，研发目标却是比较高的。这一块没有什么固定模式，我讲一下我处的行业这块的个人经验。我所在的网络安全行业，和十几年前不相比有了很大的变化，其中开源的成熟，为中等预算的团队带来了一个契机——可以通过构建一个具备丰富设计经验的精英小团队作为火车头，借鉴业界成熟的开源技术，设计好最有难度的框架部分，制订好科学的技术路线，做好研发精细管理，降低其余人员的能力要求和自由发挥度，相应的也降低了成本要求，从而产出高质量的产品。另外，我认为目前研发行业，特别是软件研发行业，拼人力的模式不优雅，内卷严重，阻碍了行业的发展，基本快走到头了。未来我认为绝大部分中级和初级程序员会失业，人工智能结合新的编程模式，会取代这部分工作，留下的是那些少量具备架构思想和创造力的资深专家，这里扯远了。

当然，具体模型的细化，需要结合下面一节：具体产品的阶段来设计。

2、具体产品的阶段

不同产品的阶段，需要的研发团队模型是不同的。

总的来说，0-1产品，目标是快速创新，挑战高难度，这个阶段不要太考虑成本，需要大部分是精英型的员工的团队模型；管理中，这种模型的员工关注产品成功和之后的回报率。

1-10 的产品，目标是持续保持功能领先、产品的稳定性、客户响应的及时性，我按照经验大致拍一个比例：需要15%的高经验级别的工程师负责系统设计和解决核心疑难问题，30%中级员工作为开发主力负责大模块特性的开发和维护以及客户响应，同时指导55%的初级员工进行小特性的开发和例行维护，形成“合适”的团队模型结构；管理中，不同级别的员工主要诉求也是不一样的：高经验员工关注产品远景、薪资竞争力以及技术难度挑战，中级别员工关注技术沉淀和个人成长空间，初级员工关注有人指导和基本能力的形成。

进入维护期的产品，可以采用10%～20%的中级员工作为核心，负责产品的开发和维护，同时指导和培养剩余的初级员工开展工作。之前高经验的员工可以撤出，进行其他新产品的研发迎接新的挑战，中级员工可以开始挑大梁，后续可培养成为管理者或架构师，初级员工后续可以成长为中级人才，这样所有级别的员工都能够有新的挑战和成长空间，同时成本最优。

每个模型员工的数量，需要通过科学拆分研发目标工作量，拆分设计、研发、测试、预研等环节，设计出不同阶段员工的数量规模，指导招聘和预算支出的节奏。

模型和员工数量有了，还需要规划科学的组织架构，比如采取扁平化，还是层级化的结构，跨部门如何协同，各岗位和职位角色的设计，以及每一件业务如何从进入到闭环，都需要反复推演，直至完美。

很多年前，我在团队内部各团队之间做了一个“给你150w”的活动——假设给你150w预算来组队，根据你的产品特点，如何去设计一个合适的团队结构模型，在完成产品研发任务的同时达到效率最优，本质上就是演练培训上述两个问题。类似的演练，在团队leader之间可以长期开展，结合实际定期复盘，非常的有帮助。

总结：

• 合适的研发模型，主要需要考虑2个因素：团队人力预算，以及具体产品的阶段；
• 不同模型都可能成功，就像下围棋，不同风格只要适合（你的团队），都是“合适”的可成功的；
• 不要盲目学习所谓的优秀企业，研发成功的因素很多，学会因地制宜，多在实践中反思。

B. 我们需要什么样技能的人才（能力大厦）

前面因为太重要，铺垫的太多了。关于我们需要什么样的技能的人才，我讲一下我实践过的经验，不一定很优，抛砖引玉。

首先，设计一个人才能力全景图：能力大厦——就是包含你团队需要的所有人才的技能的结合。这里的设计不要太远，也不要太近。企业研发，我觉得能够近看3年远看5年就好，太远了，企业自己其实也说不清楚。技术潮流5年一更新这个是比较普遍、合理的。

我举个例子，比如下一代防火墙的研发，需要的技能5年内大致如下：

如图，
通用基础：这是研发的能力的基础（地基）。俗话说，万丈高楼平地起，没有一个稳固、坚实的基础，是无法承载领域知识的成长；招聘中，应届生和跨行业的候选人，主要看重和考察的就是这部分。

业务支柱：这是你从事的细分领域的业务知识（柱子），IT技术分的比较细，比如游戏、互联网、数通、安全、物联网，都有各自不同的业务领域知识。这部分内容，够不够高、扎实，是走向领域专家的重要支撑。对社招员工，这部分是主要考察因素。

业界前沿：这部分主要是指技术前瞻性（屋顶），也是成长为架构师以后，能继续走向资深、首席架构师的核心能力要素。

上述模型，是以构建知识体系大厦为目标的技术人能力模型，从感性的角度也比较容易理解：基础够不够宽厚，支柱数量和高度够不够，天花板够不够高，这三个方面构成了技术人职业生涯的全面客观的技术支撑，也是企业对工程师职位级别评估的标准。
上述模型，在不同的阶段横纵矩阵的侧重略有不同；从整体看，每个阶段在每个层面都需要持续演进。比如：对校招和初级员工，应明确告知他，你现在最主要的目标需要打好地基；中级员工，应明确告知他，你现在最主要的目标是需要把业务领域支柱架好；对高级员工，应明确告知他，你现在最主要的目标需要拓展视野，积极创新，成为领域专家。

然后，可以顺理成章的推出科学的职位级别模型。按不走弯路的理想情况，职级可参考的时间轴和素质画像可如下：

当然，最后如果你的产品在全行业中的位置讲清楚，那就更好啦：

你可以告诉他，计算机行业分的很细，也很大，我们所处的领域，就是蓝色这一块。学海无涯，选择了这个行业，这就是我们职业生涯致力一生的技术方向，希望你最终能成为领域专家。

这样，就把能力和职位级别两件事情，给员工和老板讲清楚了！

上述工作做完了之后，相应的对人才的评估之科学的依据也就建立起来了，比如，某个候选人，面试后，面试官标注了能力大厦的匹配（红圈）部分：

面试的时候，可不妨坦诚的告诉他你的评价依据的——这些依据不以人的年龄、性别、出身为依据，而是根据企业的能力大厦为依据，对个人，长远看，坦率的说清楚这一点对候选人都是有好处的，也是容易达成共识的。这些共识，从人才的定薪、后续发展、培养、上台阶，都是一个科学的指引。

总价一下：能力模型很重要！

1、企业需要有自己的能力模型，才能科学找人、育人、用人；

2、员工需要有自己的能力模型，才能科学知道自己职业塑造方向和如何发挥价值；

3、管理者和员工双方，只有共识了“领域”的能力模型，才能为绩效沟通打下最初的共识。