团队管理的思考[摘]

就我的经验和思考，对于一个发展中的技术团队（往往处于一个发展中的公司），尤其是还处于起步阶段，此时并不是什么“先进”的经验和管理方法都能够“拿来”就用上的。一个恰当的，能够配合其发展的循序渐进的具备真正的、更强的可操作性的动态方法才是最重要的。

轻量化，敏捷，同样是过程改进的重点。

从另外一个角度而言，项目管理从大的角度来说有两种方法：

1、依靠一些成熟的过程控制和项目管理方法，配合完善的制度和文档表单等；

2、以人为本，PM不需要过分关心每个人将在什么时候能完成多少量的工作，重点是如何恰当地用好每一个人，让他们不闲着的同时又能不过于累，最好能持久地保持高效的作战能力——甚至是高昂的情绪。

前者，显然需要一个相对成熟的环境、团队。后者显然不能适用于较大的团队，往往常见于一些小团队、小企业。

显然，我们所有的人都会认为1的方法是最好的，这样的项目和团队才是真正“可管理的”。

可现实问题是，1是目标，2是现状的时候，我们该怎么做？

培训所有员工尤其PM学习ISO/CMM N/PMP？制定规章制度强制要求所有成员执行？

呵呵，别说学习的东西未必能配合上，制度未必能马上适合，就说“执行力”本身就存在相当大的问题——成本。于是，很多公司在这条路上最终走向了不归路：

1、自上而下，本来的目的未必就是要真正的“规范化”，也许市场意义更大些。技术部门不过是牺牲品，技术部门的经理和员工们往往是在积极投入一段时间之后陷入孤立无援的境地，而不得不在项目接踵而至的繁重任务和一个一个难以实现的最后期限重压之下“放弃”那些制定中的规章制度和计划；

2、不太聪明的管理层也许低估了这类事情的可行性，或者高估了自己以及自己团队的能力，尤其公司的实力。当管理层，尤其是老总遇到来自项目或市场的压力之后，无论是清醒地意识到了自己当时的冲动或是仍然抱着希望“忙过这个项目之后再说”，其采取的行动往往都是把后果转嫁给无辜的技术部门和开发工程师们

何况，那些“拿来”的东西中毕竟有许多许多的值得我们学习的，甚至是深深吸引着我们的东东——哪怕仅仅是个美好的梦想，但实现梦想的过程，本身就是一个持续的改进的过程。

那些美好的东西，是我们的目标，不是两元钱一张的双色球彩票。

改进的过程中，需要目标的指引，更需要清醒地了解自身的状况，并恰当地制定阶段目标——如同任务分解，以及改变阶段目标。在改进的过程中，更需要具体的实现方法、实现技巧。

就说一个例子：绩效考核。随便找一个技术部经理来问问他对于开发人员的绩效如何考核时，都会有各自不同的思考和答案，很难找到一个完美的解甚至是解空间。原因很简单，很难量化一个任务的工作量有多大（及技术难度）；更难量化一个开发人员完成该任务的工作量又有多大——也许在你看来很简单。当然，一个比较有经验的项目/部门经理，可能相对而言比较容易判断前者。而对于后者的把握，更在于对具体成员的能力和性格的了解——这样的要求对于经理而言显然更加困难。

坦言说，我一直采用那样的笨办法——为团队成员提供种种便利，甚至是生活上的。让他们在工作、生活中都很方便，很舒适，很开心。为他们的工作提供各种便利，不必到处去找一个软件一个新的开发包一个能够快速修复丢失的数据的工具一本喜欢的电子书和相关资料和资源。战斗在第一线，带头攻关解决各种难题并在恰当的时候适当地放缓节奏让成员做一点自己喜欢的事情，给他一个有挑战性的任务，而又在恰当的时候给他一些鼓励甚至是不明显的帮助让他获得成就感，让他从学习和收获中获得满足感，甚至给他犯错误的机会。等等等等。

但并不代表我放弃了更加规范的方式，因为在我看来，我更希望他们具备了基本的实现能力（如编码、单元测试、代码规范、错误处理等）之后，再一点点加上新的要求和新的能力要求。

否则，在你心中时时刻刻都有那么一个长长的 TOList 的滋味，会比那磨盘上的驴好受么？

当然，你可以要求员工具备“很强的承受压力能力”，否则解聘，呵呵

具体不说了，说回绩效考核。

很多变因导致很难拎起一点而又能按住其它方面。不过，如果在让开发人员首先学会控制自己的编码质量之后，从编码质量角度入手，暂时放松从其它方面的量化考核，会不会相对容易一些呢？

例如，编码规范的要求，外加一些内部习惯的开发模式配合，开发人员必须对自己的代码质量负责（比如单元测试），以定期代码评审弥补单元测试及编码规范的不足，然后通过缺陷的跟踪、缺陷率统计分析角度入手，制定相关规定，以此为动力/压力让开发人员能够重视编码规范、单元测试和评审内容和结果，降低自己的缺陷率。从而，可以在诸多变因中先揪住一点，逐渐把过程控制从缺陷跟踪和管理角度入手慢慢扩大到整个开发周期。

So，我很高兴 Vault 提供了与两个缺陷跟踪软件的集成，哪怕未必很强大。也许这并不能满足其它公司或者团队的需要，但对于我们现在这样一个刚刚起步的团队而言，恰恰很适合。

也许，坐在招聘桌前的我们忽然发现随便一个来面试软件开发工程师的，都不再是“程序员”，而都是职业化（职业素质）、专业化（专业技能）的开发人员时，那么要求他们能够很快适应我们所要求的种种规范时，都很容易了吧。

当然，别忘了最重要的一点：如同实现规范的过程所需要付出的种种成本一样，规范化也有规范化的成本的！

2005年3月22日 0:06 作者: play