关于项目关键人物的一点思考

关键人物人员流动是项目的一个重要风险之一，有人就提出很多的解决方案，比如结对编程、代码评审、文档规范化、内部轮岗之类的。大意是任务分派均等，有backup人员，尽量避免某一个或者两个人处理所有的核心模块，好似不应该有关键人物存在。我个人的观点却相反，项目里面没有关键人物才是风险。

关键人物的重要性

先说明一下，关键人物是技术和性格的完美结合。对技术精益求精，对项目尽心尽力，对代码质量有较高的要求，能够站在整个项目的发展的角度来看待问题，积极与资深业务人员沟通，追求'Better Sulution'。那些接受分配的工作，码代码，以代码能够wok并完成任务的成员不在此行列。

关键人物才能设计出满足业务需求的良好架构

架构设计远没有SSH那么简单。首先要深入的了解业务需求，并发现架构设计必须满足的特点，比如准确性，数据的完备性，可扩展性，性能，用户体验，实时性，配置灵活性等等。其次要找一些开源的或者公司自己开发的组件搭建初始架构，这个过程也是很难的，能够工作与良好工作之间还是有一段距离的，不敢说每一个组件都需要深入了解过，至少它的特点(优点缺点)至少得心中有数，组件与组件之间的融合能力也需要考虑，这些都要求平时的知识储备，对开源软件的关注程度。架构的过程就是抽象的过程，之后需要抽象业务，搭建项目内部模块化的代码，思考开闭原则，提供通用(Uniform Interface)，使得之后普通成员可以容易的实现或扩展从而开发新的功能。值得说明的是，简单即美，越简单越不易错，越容易理解和修改。

关键人物才能写出健壮的核心代码

核心代码不一定很多，但是是系统的命脉所在。如果核心代码改来改去，整个项目的进度会大受影响。所以核心代码要健壮、稳定、准确、易用、高效率。

关键人物才能持续优化代码和功能

关键人物之所以能成为关键人物，是因为他们才有精益求精的精神。代码的优化，功能的优化，新技术的引进和推广，通常都只有关键人物才想得到，并大胆的进行改进。普通的成员，如果对自己项目的架构没有那么深入的理解，即使想改进估计也不敢或者无从下手。

关键人物才能保证代码的质量

通常关键人物是代码规范的践行者，如果项目组内部没有规范，关键人物通常会制定代码规范。关键人物还承担代码评审的重任，从设计方案到代码规范，从准确性到效率都需要考虑。

关键人物才能保证架构风格的统一性

整个项目不大可能全部由一个人开发，如果项目组成员每一个人都按照自己的理解向项目贡献代码，人员的能力参差不齐，设计想法也不相同，一段时间之后整个项目乱糟糟的，初始的设计架构遍体鳞伤。项目的推进和维护都非常的困难。我觉得这个风险与关键人物的流动相比，实在是大得太多了。

关键人物的维护

关键人物之所以离开，基本上分为三种, 因钱离开、因关系不好而离开、因更好的发展而离开(更好的平台或者创业)。因钱离开，如果关键人物的薪水还不及普通的成员，那就是公司自己的问题，但确实有些公司因为能力问题无法满足要求。因关系不好，没有对错，只能尽量避免。因发展而离开，更是没什么好说的。但是关键人物离开之后，总是需要新的核心人物站出来，勉强读得懂代码的不能算核心人物，我说的是能够理解的当前的架构，能够维系当前架构的人。我不觉得2个星期的代码交接就能够培养一个新的关键人物出来。一个可行的方案是，师徒制，找一个爱好技术的成员作为关键人物的徒弟，平时可以给关键人物打下手，关键时刻可以把他推上去。当关键人物离开的时候，我们需要的不仅仅是文档，最重要的还是一个新的关键人物！

小结

以上仅是个人的一点看法，某些是受《人月神话》思想的影响，大多数是自己观察项目之后的一些思考和理解，如有错误之处，还请见谅。如果您是项目经理，希望您能珍惜您团队的关键人物; 如果您是关键人物，还请多多赐教；如果您是团队的普通一员，希望能与您共勉。不可能每一个人都成为项目的关键人物，就算做一颗螺丝钉，我们也要高质量完成自己的任务。