|
生活百科全书，解答生活难题 http://www.okwang.cn
摘要:
可是当新的软件技术,人为因素对绩效工资的影响可以变得越来越小,管理的功能将正式进入主流应用
这是12月4日李维讲座的主题，觉得对最近的软件发展的根本有一个概括性理解，同时这是一个影响每一个IT从业人员的大事，特整理一下他讲座的主题：
首先看几个场景：
场景一：
你们公司是如何绩效考核一个程序员的：
1、他写过多少项目；
2、他写过代码行数；
3、他写过项目产生Bug数；
4、由高级程序员主观对他的代码进行质量评价；
以上数据都不能很量化的评价一个程序员。如果看过《水煮三国》的，还会记得"猎人的狗力资源管理"那一节，这样的机制会出问题的。
场景二：
如果测试人员发现bug，谁会被拎出来罚站？
1、程序员
2、架构设计师
3、项目经理；
4、总经理
注意：某些bug，是因为架构、技术的问题而造成的，不能把所有责任都推给程序员。
场景三：
为何我们估算的软件成本、软件开发工期经常不准？
1、我们采用的技术是一个新技术，执行中可能会碰到很多技术难题；
2、我们很难对一个程序员
hao(办公室里太热！) 说：
我们可以带着上面的几个场景来看下面的分析：
最近这几年，不知你有没有留意到，一些对代码质量进行量化的工具，出来了不少。
比如:
Borland的Together中的Code metrics/Audits可以对代码进行评估和管理，
CMMI是对软件开发做管理，
J**A 的JMX/ BCI也是对代码做管理，
VS.net TS 中也有对代码进行静态分析和东西分析的工具。
那么SA/SD/OOA/OOD又由什么管理呢？当分析人员画了分析图Class Diagram时有什么方法可以确定他们画出来的架构是正确的？
IT的管理人員常常以程序员写的程序或是代码数量来衡量程序员的绩效，
可是当新的软件技术，如Generic Programmuing出现时又如何管理/评估程序员的绩效呢？
其实，这些问题的背后都是管理和数字。
以上质量量化分析工具的出现对软件开发来说，会带来哪些变革呢？
变革就是，可预计的未来几年，以后程序员的绩效、架构师的绩效，将会变得可计量。人为因素对绩效**的影响可以变得越来越小。
也许你在某个单位，并没有采用上面代码质量对应绩效**。但是这会是一个趋势，我们必须从现在开始就准备应对这个变革。
以上是对人来说，对整个软件行业来说，由于软件质量
|
职业指南