关于对项目量化一些疑问

这几天看了有关功能点的文章，对项目的量化有了一些认识但还是很模糊。不知道这种功能点的量化能否作为以后开发的一个考核内容。

还有就是对开发团队的考核，如何进行比较合理，感觉主观的成分很大，而客观的量化指标不好确定。大家能否给些建议。多谢了

功能点最不应该应用在所谓的绩效考核上，而且更加不能利用在对于个别人的考核上。这一点是功能点应用的常识。大概的原因是，功能点并不会涉及系统的核心功能和周边功能的划分，也不会涉及有技术难度问题。
实际上主观的成分大是优势而不是劣势，但是这个主观因素不应该是个别人的主观因素，而应该是各个参与者的主观因素的集合。

多谢指点。我觉得很难有一个量化标准去考核上，因为公司要上考核，所以想找一个比较合理方案去做。现在想法是考核由同级，上级，下级，对一个进行综合的平价，然后在根据不同权指比重来计算。

多谢提醒。

考核一个开发团队不是一个简单的工作，特别是希望有一个量化的指标的时候。这主要是因为软件本身就难于量化，即便有量化的指标，也难于使用个别的指标去反映整体的情况。当然其实还是有某些方式解决考察团队工作的。而对于个人的考核我看不是很必要，因为一般的非核心的程序员，只要大家对其没有反感，那么其工作就不会是不好的。即便某些人经常性的出问题，而其他人对其工作也为表现出不满，则也说明其工作即便别人去做也未必就能没有问题。
考察一个团队应该主要考察其进步的情况，或者说必须将其情况放在一个有前后文的过程中进行考察，并且需要让被考察的人明白你使用的考察方法。同时这个考察必须要同HR的考察相结合才有效果，也就是说对团队的考察必须要同HR对于团队中所有成员的考察结合。软件公司的核心资产是程序员，程序员自身能力的增长就是企业核心能力的增长。建立一个体系，考察程序员在团队中对于劳动纪律的遵守情况（不是说考勤等等，而是指对于SCM纪律的遵守，对于大家共同约定的尊重，对于情况的如实反映）。如果一个团队这些情况在不断的变好，那么其团队的建设就是成功的。而建立一个比较量化的系统，是可能的，关键就在于比较。也就是说以某个场景下的情况为单位，将工作进行于这个场景的比较，这样是可能的。
当然我遇到的普遍情况是，当一个公司希望对开发团队进行考核的时候，往往就是遇到问题的时候。普遍的情况是管理团队对于开发团队有所不信任。而大多数情况下，问题出在管理团队而非开发团队。可惜在国内敢于承担责任的管理者少之又少，所谓的对于开发团队的考核往往就是管理者推行推卸其能力不合格一个行动。因此往往看到的情况是，推行的考核带给组织的只有政治争吵和钩心斗角。避免这样的情况是最应该注意的。

非常感谢，解答了我很多困惑。

 

现在公司对开发团队工作总有延期现象，比较不满，其实作为一个研发人员我心里知道很多情况不是团队错误，上头定的时间很多时候几乎都是不可能完成的任务，延期我想是在情理之中，但上头总觉得这些项目很简单很好作，做过一些沟通但成效不大。而且有时候需求还没做好就要紧张开始coding。慢慢来吧，领导可能也需要潜移默化的引导吧。多沟通是好，但希望能知道一些好的沟通方式。

绩效考核目标一个是鼓励工作好的人员，同时对混日子的做一个督促和警世，主要还是以奖为主，正向鼓励。能把部分人的能动性调动起来。

还有就是你说的避免内部的政治损耗非常重要，我就怕这样情况发生。本来是个创业公司，就怕内耗。