最近与同事聊天，从软件质量保证的方法论谈论到了技术管理，那技术管理的内涵到底是什么？在此通过这篇文章做一个小小的总结和适当的外延。
技术管理给人的感觉更多是工作量评估、项目计划、项目进度跟踪等，但这只是技术管理的一部分。大体上，可以将技术管理分为两个纬度，如图1所示。
图1
纬度之一就是项目管理，其中包括项目计划、风险管理、预算管理等。对于基层技术管理者，更多涉及的内容是工作量评估、项目计划、项目进度管理等等。这一纬度的可见性很强，一项做不好就很容易让上级“紧张”，因此每一项内容都有专门的培训课程。
另一个纬度则是团队管理，在现在很多技术性企业中，采用的都是人力资源管理进直线的方式，即技术管理者还要承担一定的人力资源方面的管理工作，比如绩效管理、职业发展规划等，当然这些内容给人的感觉更多的是“很虚”。由于这种特性，造成真正意义上关注团队管理的情形相对要少得多，与之相对应的培训课程也更少。
相信在不少企业，将技术管理更多地理解为项目管理，在管理活动中似乎只有风险、计划和时间表，而忽视了培养团队。在图2中存在两个点和一条射线，其中点A代表团队A对于技术管理在两个纬度所采取的权重，同理，B点则代表B团队。从图中可以直观地看出，A团队更加侧重于团队管理，而B团队则更加侧重于项目管理。另外，图中的射线代表如果团队权重是分布在这条线上或附近，则说明这个团队在技术管理中很好地掌控了团队管理与项目管理的平衡。
图2
一个团队的技术管理，其两个纬度的权重在图2中的分布或许不是一成不变的，应当根据不同的时期调整其侧重点，但是，无论如何团队管理应当是技术管理的核心内容，或者更进一步地说，提高团队技能是技术管理的核心课程。
团队管理不能只是出去吃吃饭做一做team building什么的，更为重要的是要提高团队的技能，且是实实在在地提高团队的技能。项目管理中的很多问题，都可以通过提高团队的技能从而缓解，乃至根治。举一个例子，为什么我们对于风险管理（项目管理中的内容）那么的执着？那是因为团队的能力不足以应对所面临的挑战！当然，作者并不是要说团队的技能上去了就不需要风险管理，而是指当技能增强了以后，对于风险的掌握自然就强了，而对于风险管理的要求就会有所弱化。团队技能上不去，项目管理工作只会是越做越累，且只是工作在问题的表面。
提高团队的技能是一个很不轻松的话题，因为它在理但却很难操作。但无论如何，技术管理者首先应当具备这种意识，因为只有意识先行才会有所行动。现实中，存在不少现象，技术管理者说“我的老板才不管团队技能的培养呢，他只关心他自己，因为团队能力的提高并不是他的首要职责，他只要求我将产品按计划做出就行了。老板不管，那我也就更管不了，也没有给我时间去做啊。”对于这种借口存在以下几个问题：
1）产品按计划完成意味着项目成功了，但它并不意味着产品成功。一个技能不行的团队是能进行产品开发，也能做到项目成功，但一定做不到产品成功。可能一发布产品，就“全员求火”了。
2）如果每一级管理者都采用这样的借口，那最终的结果就是没有人真正关心团队技能的培养。一个企业为什么需要那么多的（技术）管理者？只是为了让更多的人去找借口？显然不是。在所有从上到下的管理者中，一定需要有一层去关注团队技能的培养，那只能是基层技术管理者，即通常我们所说的组长或team lead。因为团队技能不足，第一个受害者就是团队自身，而基层管理者身在其中。有的基层管理者，他的工作主要就是schedule以及来自上级的指令，对于团队技能的提高似乎与已无关，更谈不上对团队的激励了。这种对团队技能忽视的现象其实是对自身利益将被损害所表现出来的一种麻木。技术管理者能否将团队技能逐渐地提高，或许是评价其管理能力出色与平庸的关键指标。
3）培养团队不是有时间就能解决问题，而首先需要有意识。时间总会是有的，因为项目总是要做的。有了意识以后，同样是做一件工作，所采用的策略将完全不同，而团队所学得的知识也很有可能更多。
技术管理者除了需要有提高团队技能的意识，更要注意方法论的运用，打造适合团队自身的方法论也显得尤为必要。另外，承担一定的责任和适当的风险有助于为工程师们提高技能创造空间。
本文出自 “李云” 博客，请务必保留此出处 http://blog.csdn.net/hzliyun/article/details/7078920。
