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