是什么使一个程序员成为高级程序员？当你问起这个问题，你会得到各种各样的答案。有些人认为是能写出绝佳的代码。有些人认为这牵涉领导能力。其它也有些人为需要能指导其它人或者有产品的思想。正如我们稍后在文章中讨论的，每个人可能都是正确的。但是如果每个人都是正确的，成为高级程序员的路就变得混沌模糊，更不要说其实真的很难。我怎样成为一个很牛的程序员，一个很牛的领导，很牛的导师，以及更多？一个人真的能同时处理好这么多领域的发展么？这给投入很多精力深造的人造出了很多挫折。而且使得搞清楚怎么发展自己的领域以及自己的影响变得非常困难。
几年前，我们在Riot的工程师中注意到一个主题。人们需要对如何提升到下一个等级有更明确的定义。作为一个游戏玩家，以及高度驱动的个人，我们很自然的想要知道怎么“升级”。但是我们有个问题：在Riot，我们不喜欢扼杀想法、创造权威地位的分阶层。
让我来通过一个例子阐述下。假设一个团队正在开发一个游戏中的新功能，来处理游戏的竞争性与排名。这个假设的团队由两名高级工程师以及一个助理工程师组成。这个助理工程师是个死忠粉、比赛型专业级玩家。团队其余的人，也是热情的玩家，只是没有进入联赛竞技的水平而已。当团队开始设计这个功能，他们就一个可能影响玩家经验的技术选择进行辩论。其中一个高级工程师强烈建议一种方式，但是那个助理不同意，因为他知道这个对高度竞技型玩家是什么感觉。在Riot，我们期望那个助理有说出自己想法的勇气。即使在很多通常的意义的术语定义下，她是个“初级”的，但是对竞技性游戏她有更多的背景、更加专业。我们也期待高级工程师可以重视从更多“初级”工程师得来的输入。
好的点子可以来自任何地方，我们希望最好的点子浮出水面，不需要考虑人们认知中的“权威。一个并没有什么经验的人也可能是一个高度匹配的问题解决着或者批判性的思考者。他们也可能带来一个独特的视角，增加了思想上的 团队多样性。不考虑他们的技能或观点，只是基于他们的经验使团队以前没有考虑他们的解决方案。那这与成为一名高级工程师有什么关系呢？我们需要一种思考职业成长的方法，强调价值传递和玩家对权威和头衔的影响。它还需要有一条清晰连贯的路线从好到非常好。头衔并不是能正确捕获所有细节以及我们思维复杂性的系统。
头衔出了什么问题？
概括来讲，头衔过于单一维度了。这里我想用另一个游戏的类比。我们假设你正在准备一只突击队，然后你决定征询一下你的朋友来选择突袭的完美英雄。其中一个朋友告诉你：“我是个40级的突击队员，因此我显然应该在你的队伍中。”那你希望这个人在你的突击队中么？大部分人会同意这信息不够充足。他们能打出多少伤害？他们有多少生命值？是什么类型的突击队员？他在哪？小队需要何种力量来面对潜在的威胁？最后你也不知道剩下的团队组成是什么。如果我已经有了其它4个冠军级的突击队员了呢。这种单一维度的头衔——“高级突击队员”没有能的描述出一个有效队伍所需要的所有组成部分。
同样的情况可以类推到英雄联盟的团队竞争。如果你想要一个周全的团队，你需要酌情分配团队控制，前排坦克，爆发伤害，突袭能力等。我们需要一个系统来捕获这些类似的东西。我们想要确定我们定义一个好的Riot工程师需要选择哪些具体的属性来放在每个人单独的角色页上。如果我们能够有效的做到这点，我们就有办法构建平衡的团队并给予他们各自需要关注发展的领域，所有这些都与头衔无关。十八个月前，我们决定开发这套系统。
伟大的滋味
首先，我们要决定具体选择哪些属性。虽然伤害、生命、敏捷、智力对你最喜欢的RPG角色非常重要，但并不能很好的应用到一个Riot优秀的工程师身上（好吧，也许智力可以）。我不准备深入解释为什么我们最终决定选择这几个属性，因为这主要是无数小时的与工程师、经理、产品负责人的交流与讨论，每个人基本花了10分钟来聆听我们疯狂的想法。先不管我们了，我们知道我们希望这些属性够全面，这意味着它们可以有效地描述出工程中的各种角色。我们最初从以下几项开始:
1. Craft (研发能力)
2. People Leadership (人员领导力)
3. Craft Leadership (技术领导力)
4. Product Focus (产品关注度)
5. Development Process (开发流程)
Craft 是最容易理解的，至少我们这么认为，因为它代表你的工程核心技术水平。关于这条我们稍后继续讨论。People Leadership 是管理人的能力，建立和领导团队及组织，并指导和培养周围的人。 Craft Leadership是指能在研发能力上指导其它人并能在技术角度推动组织规范的能力。Product Focus 表现了你对整个产品的设计和视觉贡献了多少。Development Process 涵盖了整个开发流程的各个基本面，包括持续交付、敏捷开发等等。
然后我们决定使用这5个属性，并使用我们的RFC流程将他们在所有的工程师中公开。我们很快发现Craft这项太模糊，并不能真正定义工程师的价值。在Riot我们有一些不同种类的工程师，表现在专注于不同的焦点或领域，所有的这些都是必要的——例如软件、底层架构、安全等。当我们对带有这些专长的人使用这些属性衡量的时候，Craft并不能很好捕获每个人的特征。经过一番争论，我们一致认为将Craft分为 Programming (编程)和 Subject Matter Expertise(学科知识专长)。也许在未来的某篇文章中，我可以将这个划分的更细致，但是我们觉得Programming 可以作为Riot工程师的定义了——我们希望所有的工程师精通编程，而无需考虑他们的其它的关注点。我们也修改了一些在产品和流程方面的措辞，来更精准的表达他们的含义，最后我们确定如下几点：
1. Programming（编程）
2. Subject Matter Expertise（学科知识专长）
3. People Leadership（人员领导力）
4. Craft Leadership（技术领导力）
5. Product Sense（产品观）
6. Delivery Methods（发布方法）
使用这六个属性，我们可以有效的在平面上描述在Riot什么样的工程师扮演者各种的角色。这里有一些可能的原型的例子：
专家
产品负责人
敏捷教练
下面是最有意思的部分: 所有的这些好的定义都没有使用头衔。我们可以拥有（事实上我们在很多地方也使用）高级工程师，助理工程师以及以及一张各种不同头衔的列表可以轻松的满足这些原型。我们现在有个方法来思考怎么组件团队，定义角色，以及展示我们工程师在每个分类中的值是什么。 其它的原型肯定同样存在。
只是个开始
定义了这些属性对我们开始思考工程师的职业生涯发展提供一条有巨大意义的途径。但是，我们还是需要来定义“路径”。本来嘛，1级的技术领导力和5级人员领导力应该是什么样的？我们发现，即使是“level（等级）”这个词也会有严重的影响。我们将在下一篇文章中解决我们是如何处理这个问题的。
