认清它，承认它，然后改变它。
1. 前言
在上一篇 传统软件行业中技术团队的发展(现状篇) 中，我们介绍了传统软件行业公司中技术团队的形成渊源，以及特点。
本篇在上一篇的基础上，尝试探索传统软件行业公司中，技术团队如何破局，遏止住团队下滑趋势。
2. 先说结论
本篇我们反转叙述顺序，先说结论，再解释其中的细节。
至于原因嘛？主要考虑到现在很少有人会从头到尾地将一篇文章看完，但我又特别希望这篇文章的关键信息能够被潜在受众看到。
对于传统软件行业中的技术团队发展，我们需要立足于公司实际情况，建立完善的快速人才培养体系，以及科学高效的工作流程，以不断降低的培训成本和不断完善的协作流程，化被动为主动，助推公司的业务发展，实现技术与业务的相互驱动。
以上，就是我们个人思考总结出来的，传统软件行业中技术团队实现良好发展的一条破局之路。
思路其实不难，稍微观察过一段时间，说出其中的一两点其实很简单，所以重点还是方法论 —— 如何实施？
接下来就让我们逐一解释，尤其是其中被显式标注的三句话。
3. 完善的快速人才培养体系
“一切问题，最终看来都是人的问题”。在软件开发这种人类脑力劳动占据主要比例的人类活动中，尤其显得明显。
前文已经提到的，传统软件行业公司对于技术的要求不高，相较于技术创新对于业务的支撑，如何实现对常见问题解决方案的快速复用，快速组合来进一步解决各类新的业务需求问题，才是公司所看重的。
而要实现技术解决方案的低成本快速复用：
- 首先当然是要有这样的解决方案的归纳，收集和整理的执行者；
- 然后就是更重要的，如何让这些解决方案能够以不断降低的成本，更快的速度传递给团队内的技术人员知晓，避免他们的重复创造。
关于第一点，不是本小节的重心，这一点是每个技术人员的追求，只要引导得当，很容易找到能够承担这项职责的技术人员。（毕竟稍微有点技术追求的研发人员都会有一个自己的工具集，里面放着过往遇到问题的快速解决方案）
第二点则是本小节所要讨论 —— 通过建立完善的快速人才培养体系，实现技术解决方案的低成本复用。
3.1 初中高级人才的定义
以上面这一条为中心点，我们需要重新明确对于初中高级人才的定义。
| 层级 | 主要职责 | 工作内容 |
|---|---|---|
| 初级 | 完成单一业务功能开发 | 1. 学习公司的技术栈体系，知晓公司针对不同的业务场景下沉淀的各类技术解决方案。 2. 将理解的业务需求，使用前面学习的技术解决方案，以类似搭积木的方式转换为代码。 |
| 中级 | 项目技术负责人 | 独立承担一个产品或项目的技术负责人，带领初级研发人员，与产品/项目经理协作，保质保量完成研发工作。 |
| 高级 | 技术解决方案收集沉淀和普及，流程完善 | 本文所设想体系下的关键。他们是经过考验，有专业性，主动性，行动力的一批人。他们的主要工作是对团队技术栈进行迭代，实现开发效率的稳步提升；做好技术栈的培训方案并实施；收集各类业务场景下的解决方案，沉淀之后并推广下去；观察找出现有研发协作流程的效率桎梏点，提出改进方案并落地实施。 |
3.2 人才定义再细化
以上三个级别又可以细分为初中高。这样就可以进一步覆盖实际环境。
- 对于招聘来的人员，因为其对于公司技术栈和现有业务场景解决方案不熟悉，所以一律以当前级别的初级起步；待试用期结束时再根据其对于公司技术栈的熟悉程度来确定对应的级别。
- 进一步细分也可以让我们更灵活应对熬年限所带来的评级困境——你做再多的项目，如果你无法培养出能够接替你工作的人，如果你每次都必须通过手把手，口传心授的方式，以极高的成本才能培养出一个能够接替你当前职责的人，那你就永远在中级待着吧。
3.3 中高级的分水岭
诚如上面已经提及的，在传统软件公司，中高级的重要分水岭，不会是技术深度这类的硬实力，而是能够将自身的技术能力以低成本复制出去的能力。
作为一个在传统软件多年，一直吃技术这碗饭的职员，多年的观察下来，让我一直有一个疑问："为什么我们会有这么多’技术类问题‘？"
这么多年走过来，虽然笔者限于自身原因，一直在迭代自身的技术体系，但就实际工作中使用到的技术，八成却都是笔者在进入这行头一两年所知晓的那些内容。
这么多年项目下来，绝大部分时候的技术问题往往不是因为深度不够导致无法解决造成的业务延期；而恰恰是因为一线研发人员的精力被投入到了重复性的问题解决上 。
这里我们先不谈那些流程上的问题导致的重复工作，我们先单单讨论常见问题的解决方案，总是A团队某个人率先遇到，可能因为当事人技术能力强一些，然后不声不响地自己解决了，交差了事。过了几天，团队里的另外一个人也遇到了类似的问题，他自己换了种方式又解决了一次，并且因为能力上的差距，其所消耗的时长更多，而且因为原本业务压力就大，加上前面在技术预演上消耗了较多时间，那接下来就别扯什么长远的设计，代码可读性了，赶紧把需求赶完的吧。
之后团队经历了数次人员迭代，类似的情况不断上演，所以对于一些时间稍长的项目，你会发现其中简直是技术大杂烩，开源组件集中营，同一类问题，有多种不同的开源组件被集成进来。
同一个小组团队尚且会出现上述问题，当范围扩大到整个部门，以上情况只会愈演愈烈，超出任何个人的控制范围。
能够意识到上面这个问题，并且愿意为之付出行动谋求改变，这就是传统软件公司中，中级晋升为高级的关键所在。
不需要先达到终点，只需要你走在了路上，你就已经是事实上的高级人才。
3.4 既要TA待遇要求低，又要TA十项全能，想啥呢？
虽然嘴上承认“既想马跑得快，又想马儿吃得少”不现实，但不少传统软件公司的领导层身体倒是诚实得很，恨不得招聘来的每个人都是十项全能，而给出的待遇却始终在低位徘徊，美其名曰“物美价廉”。
哪那么多的物美价廉，你这企业是有着美名在外，让业内新人趋之若鹜吗？ 正是因为数量少，所以才有“漏网之鱼”的说法。
人员数量，人员质量，人员成本的不可能三角，这一客观规律，不论你口号喊得多响亮，打进去多少鸡血，它只会在那冷冷地看着你，看着你摔倒一次又一次，最终或者知道疼了被迫正视它，或者你带着不甘走向墓地。
想要破除不断增长的人力成本困境，除了完善的人才培养体系外，流程则是最大的依凭。
4. 科学高效的工作流程
正式开始前，先让我引用一下我在去年阅读过的一篇获益匪浅的极客时间专栏- 《10x程序员工作法》 里的一段话：
程序员解决的问题，大多不是程序问题。
软件行业里有一本名著叫《人月神话》，其中提到两个非常重要的概念：本质复杂度（Essential Complexity）和偶然复杂度（Accident Complexity）。
简单来说：
- 本质复杂度就是解决一个问题时，无论怎么做都必须要做的事，
- 而偶然复杂度是因为选用的做事方法不当，而导致要多做的事。
比如你要做一个网站，网站的内容是你无论如何都要写的，这就是“本质复杂度”。而如果今天你还在用汇编写一个网站，效率是不可能高起来的，因为你选错了工具。这类选错方法或工具而引发的问题就是“偶然复杂度”。
再比如类似打包，发布，配置管理这种事情本来应该用自动化和不断优化的流程来完成，但现在却因为大量依赖于人工操作来执行，导致各种"抄近路"横行，最终造成沟通成本居高不下，大量的精力被浪费在无尽的扯皮上，留给真正需要关心的业务实现上的精力捉襟见肘；那么项目延期，加班等等情况的发生也就不足为奇了。
上一篇文章中已经总结了，天然形成的工作协作方式中势必存在大量的抄近路人工操作，导致所谓的流程对人的倚赖非常重，尤其是在部分关键节点上，甚至可以直接瘫痪整个流程。
我们需要重构当下这过分依赖人治的工作流程，改变当下人推着流程走的模式，最终实现流程推着人走的新工作流程。
而且，正如上文已经论述的，传统软件公司涉及到的大部分技术问题特点也决定了自身更需要在流程上下功夫，找出突破口。
4.1 流程可以降低对人的依赖
科学高效的工作流程，最大的特点就是最大限度地降低对人的依赖，保住产品的下限。
“人决定产品的上限，而流程决定产品的下限"。过往我们将最终交付物的质量基本完全寄托在当事人的责任心和职业技能成熟度上，这种无奈的根源恰恰是因为我们的整个流程都是倚靠人治建立起来的。
科学高效的工作流程，将过往被关键节点所掌握的流程信息和操作固化到流程中，将原本飘忽不定的审核标准公开明确，借助机器铁面无私的规范执行特点，以及一丝不苟，不打折扣的工作态度，显著降低流程执行过程的沟通交流成本，减少关键节点数量，降低对于流程节点人员的要求。
4.2 流程可以不断进化
相较于流程而言，人的能力提升之后，一来你要担心他是否有二心，二来你这也得打鼓"老虎也有打盹的时候"。总之，人是最大的变数来源。
而对于流程你完全没有这些担心，忠诚不二，一丝不苟地执行指令外，我们对于流程的优化会进入 —— 发现问题，优化流程，再发现新问题，再优化流程的正向循环里面。
最终的效果是流程越来越智能，最终的目标：“人解决问题，流程负责执行解决方案”。
4.3 流程可以让人员精力集中
关于这一点，直接举个例子就清楚了。
当下的项目团队里，为什么很多时候技术负责人忙成狗，却又不让新人上手，还不是因为当下流程里完全没有度量系统，没有门禁，没有检查。客户就是我们的测试人员，测试周期长，反馈慢，可不得事事都自己上放心吗？ 万一中间出点啥问题来回沟通更费劲。
通过设置层层检查关卡，将问题尽量消除在引入阶段，除了大幅降低错误修复成本外，也使得中高研发人员可以放心地将一些低级任务交给初级人员练手，一来可以减轻中高级人员的压力，集中精力到更有价值的事情上，二来也是对于初级人员的锻炼，让他们快速成长起来，从而让团队进行良性发展迭代之下。
5. 立足于公司实际情况
这一点可以算是前两者的基础了，再精炼一下其实就是教员的那句"实事求是"。
那么实际是什么？
- 人员技术能力差， 主观意愿也不高，"just a work" 是常态。
- 公司业务特点决定了，相较于技术深度，公司更看中技术的可复制性，技术方案的快速性。
所有的一切改变，都必须以上面这些"实际"作为前提。
面对现实是解决问题的开始。
“能力太差”，“责任心太弱”；寄希望于这种短期内不见效的变化来改变自己的境遇，甚至就是以此来解释这件事情，很多事情都没做好的原因。
这些理由错了吗？ 没有。
但是你要的是什么？是解决问题？还是证明问题不是“我”导致的，与我无关？
6. 最后
本系列文章所描述的问题，属于一个非常大的课题，一个只能无限接近，却始终无法真正解决的问题，业界一直在为此努力。
这个问题的解决方案，是需要个人和公司共同努力才能实现的。
在这个过程中，成为参与者甚至是主导者，让这个小世界按照你的意愿去发生你所希望的改变；还是作为冷眼旁观的看客，最终只会是取决于你自己。
合作是共同选择的结果，我们一直期望有更多的人走过来。
7. 作者其人
跌跌撞撞直到而立之年，才开悟如何才能追寻到心中的目标。
曾经也是愤世嫉俗：”我私下研究了这么久的技术，为什么生活得还是这么惨，待遇还是这么差“，"为什么没有伯乐慧眼识英才？”。最终被迫认清：机会很难得，别人没有义务和意愿给你。 信任是一件很稀缺的东西。
也不曾有过这样的热情：
在阿朱的会上，我问了他一个问题：为什么明明知道企业应用软件行业的利润率不高，还是会选择做这个行业？
他说：“的确如此，金山的雷军也这么说，这个行业会有发展的瓶颈。但是，他仍然相信，传统的产业机会巨大，信息技术的创新只要应用进去，哪怕只有一点点，带来的改变和机遇都是巨大的。所以，他愿意做这样的努力来看到这件事情的发生”。
我佩服这样有理想的人。
笔者本人呢，只是一个报复心比较强，对于沉沦时期的种种遭遇耿耿于怀的俗人。
只是因为不甘心过于平庸，被迫面对现实，在一个不高的起点，思考如何切实有效地解决眼前的困境，以让自己已经足够糟糕的生活能够出现转机。
