it项目量化指标

1. 如何量化考核软件开发人员绩效

你好，
“目标管理”更适合软件开发人员。
但些方法最好从上至下全员使用
1、目标项（即当月或是阶段性的工作项目、或是要点）
2、目标项的达成准标（以量化标准作为结点，避免方向性的准标如“进一步提高等”）
3、目标在执行过程中所遇到的问题点
4、针对第3项问题点所采取的应对措施（目的进行检验，和纠偏）
5、提交成果主要的衡量标准
6、衡向配合部门

以上6项楼主可以进行一个列表，进行横排~进行目标设定，阶段性进行总结。
根据目标完成成度进行考核。
因为软件开发人员的工作性质比较特殊，考核方案要与所担当的项目结合起来才能很好的推动，如果太过形式化，执行力和效果都不会很好。
希望回答对您有帮助.

2. 如何有效量化考核指标

绩效考核的目的是为了激励员工，能达到“激励”这个目的就可以了，没必要对所有的岗位都定量到底，给一些定性指标也是不影响“激励”这个最终目的的，而且可以给员工一个更加宽松的环境，有助于处理好企业文化和员工关系。
而且，确实有一些工作是不适合定量的，比如产品开发，这种工作周期又长，风险又大，可能研究了几年，还是有很大的失败可能——通常一个项目能有60％的成功率就顶顶不错了，如果是定量考核的话，那对开发人员无疑是非常不公平的，他付出了长期的工作，却得不到丝毫承认，而且他的工作也并非完全没有成果，也许这个项目是失败了，但由此积累下来的技术却可能用在别的地方。像这些岗位，定量指标虽然更简单方便易见成果。
定量考核要慎用，最好是和定性考核掺杂着来，根据不同的岗位、时期、公司所处阶段等，可以以不同的考核方法为主，比如，同样对于生产员工来说，在公司处于扩张期、追求规模时，可以量化考核其生产效率为主；在公司处于稳定期、追求产品质量与创新时，则以定性考核期工作能力等为主。
最后我想说自己很认同镖哥的说法，所以基本借用了他的话，嘿嘿，不好意思了，膘哥。

3. IT部门的KPI应该怎么制定

kpi指标设计的重点一是要体现信息化部门的价值，二是要保障系统安全有效运行。kpi要确定可以量化的关键值。也可采用监控系统，定期输出报表。
考查指标，例：
it项目完成率、it服务满意度、it网络故障时长、it信息安全事故次数 等。

4. IT项目绩效考核方法

靠考核解决这个问题不太可能. 要改变的是公司的薪酬制度, 提高基本工资(岗位工资), 降低项目提成的比例. 当然薪酬总额要测算好, 不能比改之前低.

5. 关键绩效指标法的IT服务的关键绩效指标法

关键绩效指标法将成为考核IT服务绩效的一个重要因素。关键绩效指标法包括与业务需求结合的度量，数据中心的监测和能力规划等等指标。
IT服务的关键绩效指标法指标与常见的监测指标之间的差异是企业领导的参与。任何一个企业都可以部署一些监控工具来跟踪分配给虚拟机的资源或服务器的带宽利用率等。这些分散的技术因素对IT技术人员有帮助，但对企业的实际应用价值并不大。企业应该了解关键绩效指标法，利用关键绩效指标法来管理和解决问题。
虽然ITIL有一套通用的性能建议关键绩效指标法设置，但它没有一套可以通用于所有项目的需求关键绩效指标。IT的关键绩效指标法关键绩效指标通常分为三大类：服务交付力关键绩效指标法、服务关键绩效指标法或性能的效率关键绩效指标法和灵活性关键绩效指标法（应对服务的变化）。企业的IT服务提供商也应该使用服务可用性的关键绩效指标法指标。 服务吞吐量关键绩效指标法体现在用户对应用程序或系统的使用或需求。通常是指事务的数量或计算工作的措施。·响应时间关键绩效指标法
响应时间的关键绩效指标法指标包括需要完成事务的时间长短。响应时间关键绩效指标法包括多种基础设施元素，如服务器、网络和存储。它与服务级别协议有紧密的关系（SLA）。· 资源利用率关键绩效指标法
举个例子，物理或虚拟机的资源与被分配资源总量的比值就是一种利用率关键绩效指标法。如果一个虚拟机分配了10G的内存关键绩效指标法，而它使用了10G的内存关键绩效指标法，利用率便是100%关键绩效指标法。·正常运行时间关键绩效指标法
正常运行时间关键绩效指标法是衡量应用或系统正常运行时间的百分比指标关键绩效指标法。群集技术关键绩效指标法，自动恢复服务器关键绩效指标法和网络故障转移关键绩效指标法都有助于正常运行时间的指标关键绩效指标法。企业可以利用这些指标来计算其定制服务关键绩效指标法。例如，如果设备的吞吐量关键绩效指标法和正常运行时间关键绩效指标法的指标高而响应时间的指标低关键绩效指标法，无论资源利用率的高低，服务分数都不会受到很大影响。但如果资源利用率和响应时间增加而吞吐量或者运行时间下降，则会严重影响服务关键绩效指标法分数。 ·工作效率还是性能关键绩效指标法？这个派生关键绩效指标法的指标将工作量的分配资源关键绩效指标法和利用资源关键绩效指标法拿来做比较。这个指标可以看出工作量对资源需求的大小，是浪费资源、资源不足还是刚刚好。·系统效率和性能关键绩效指标法
系统效率关键绩效指标法是以服务器的分配资源与可用资源对比的一个指标关键绩效指标法，让服务器能达到最佳的性能负载。从这个指标可以看出服务器是存在资源浪费还是资源超载关键绩效指标法。工作负载关键绩效指标法和系统的指标关键绩效指标法通常是通过数据中心汇总数据后计算出来的平均值。IT团队通过快速测量工作期间的状态，再比较它以前的状态来为新技术项目的投资提供必要的数据关键绩效指标法。例如得到一个较低的关键绩效指标法数据，就表明可能需要升级负载均衡或其他技术项目关键绩效指标法。 ·服务请求回应的关键绩效指标法
服务请求回应关键绩效指标法是指在可接受的时间内回应通过呼叫或者其他方式的服务关键绩效指标法请求，并成功解决的事件数量关键绩效指标法。·服务处理时间TTR关键绩效指标法
TTR关键绩效指标法是衡量需要解决关键绩效指标法服务请求的时间。例如当收到一个新虚拟机的请求时，评估的时间，方案的确定，批准到提供一个新的虚拟机这一整套流程的时间关键绩效指标法；或者收到要进行资源关键绩效指标法分配更改的请求，所需要的性能检测时间关键绩效指标法。伴随着IT服务请求的数量增加，TTR关键绩效指标法会相应的下降。可以看出TTR关键绩效指标法是灵活的，能够应对变化的工作量和用户需求。如果服务请求和TTR关键绩效指标法的数量同时增加，则表明IT服务存在明显的服务敏捷性短板关键绩效指标法。 IT服务提供商或其他提供受SLA（Service-Level Agreement 服务等级协议）约束的IT服务组织，都可以采用SLA 关键绩效指标法，这是一个涉及范围广泛的指标。·服务请求处理率KPI
这个关键绩效指标法指标是度量在一个可接受的时间对服务请求提供可用服务或者帮助的百分比关键绩效指标法。·正常运行时间关键绩效指标法
正常运行时间关键绩效指标法指标体现在一个计费周期内关键绩效指标法服务的可用性上。在周期内，也许不可避免有一定量的关键绩效指标法服务中断，但这个中断时间可以衡量SLA的履约能力和关键绩效指标法经营业绩。·平均故障间隔时间（MTBF）/平均修复时间（MTTR）关键绩效指标法
MTBF和MTTR是指故障频率关键绩效指标法和修复故障关键绩效指标法所需要时间的两个指标。
·服务请求数量的关键绩效指标法
这个关键绩效指标法指标是投诉或服务请求的数量。它的增加表明某些系统或平台存在问题。收集所有的关键绩效指标法数据，整合并制定关键绩效指标法结果提供给业务主管，它是SLA问题的一个重要早期关键绩效指标法预警。根据这个关键绩效指标法提供的关键绩效指标法基础数据可以为业务目标改善服务。 一个也许最重要但被忽视的方面——关键绩效指标法是与业务紧密相关的。无论会计、市场营销、销售等等行业，IT服务都可以管理关键绩效指标法和提供符合行业所需的关键绩效指标法应用系统和工具的关键绩效指标法统计报告。但并不是每一个关键绩效指标法指标都必不可少或可以作为测量目标。从公司到公司，甚至从项目到项目，这些关键绩效指标法指标的作用并不相同。选择IT的关键绩效指标法指标首先要了解这些指标的作用。专注于关键绩效指标法服务的业务将关注在不同负载条件下的事务或吞吐量相关的测量和活动关键绩效指标法指标。相反，企业关注控制成本的关键绩效指标法指标，包括计算资源的可用性指标、利用率和系统功耗。因此，随着时间推移，根据不同区域选择可测量并建立阈值的机制，实现与监控管理工具测量和选择不同关键绩效指标法指标是一个成熟IT服务的关键。

6. 核心IT能力评价指标甄选基本原则有哪些

（1）科学性原则
评价指标体系是理论与实际结合的产物，它必须是对客观实际的抽象描述，企业核心IT能力涉及的因素很多，如何对其进行高度的抽象、概括，如何在抽象、概括中抓住最重要、最本质、最有代表性的东西，是设计评价体系的关键和难点。对客观实际抽象描述越清楚、越简练、越符合实际，其科学性也就越强。另外，评价的内容也要有科学的规定，每个指标的概念要科学、确切，要有精确的内涵和外延，从而满足科学性要求。
（2）系统性原则
企业核心IT能力评价是涉及到战略、业务流程、组织结构和文化、信息系统等要素的复杂结构系统，是所有要素组合效应的综合反映，具有很强的系统整体性，因此在评价指标体系设置过程中，这种系统特殊性应该得到充分的反映，采取系统设计、系统评估的原则，考虑各种因素的相关性、整体性和目标性，才能全面、客观地做出合理地评价。
（3）动态和静态相结合的原则
企业核心IT能力具有明显的动态性，只从静态角度来考虑是不全面的，不能反映企业核心IT能力的发展规律。因此，评价企业核心IT能力还必须从发展变化的角度来考察，在内部因素与外部因素相互作用的运动中，揭示企业核心IT能力的运动规律，这要求在设置评价指标体系时，要有反映当前企业核心IT能力状态的静态指标，也要包括反映企业核心IT能力变化趋势的动态指标。
（4）独立性原则
企业核心IT能力评价指标要能反映出企业核心IT能力所具有的系统性，这就要求评价要素功能齐全，但是评价要素多了，指标独立性差，相互兼容、重叠，突出不了主要矛盾，同时也给实际评价操作带来困难，因此各个评价指标之间应该尽量避免显见的包容关系，对隐含的相关关系在处理方法上应尽量将之弱化、消除。
（5）定性与定量相结合的原则
企业核心IT能力是一个多维的复合系统，不仅包括容易量化的因素，也涉及到许多难以量化的要素，但是其又是衡量企业核心IT能力的重要指标，必不可少，因此在指标体系的选择和运用中，即要包括定性评价要素，也要包括定量评价要素。在评价分析时，将定性指标进行量化处理并以近似值加以反映。
（6）可操作性原则
各评价指标应该概念确切，含义清楚，信息集中，数据资料易于采集，计算范围明确，计算方法简便、明确、易于操作。
（7）可比性原则
运用评价指标体系进行比较分析时，常要作横向、纵向的排序分析，为了使评价结果可比，选取的指标具有普遍的适用性，指标所包含的空间范围、时间范围、计算口径、计算方法等尽量一致。

7. 如何准确估算IT项目管理的工作量

IT项目开发过程中，在面对一个业务功能时首先做的是从需求中设计表结构，然后为表结构定义各种各样的关联，定义完关联后基本上在大脑内形成界面的大致样子，然后就开始写代码。
从上面的过程中，可以知道IT项目管理工作量估算大致分成下面的两个步骤：
1. 数据结构设计阶段
2. 根据数据结构编写代码阶段

接下来分析下每个估算步骤所用到的知识。
1. 在数据结构设计阶段所使用的知识分为以下几个部分
1) 数据库设计知识
2) 业务知识
2. 在根据数据结构编写代码阶段所使用的知识分为以下几个部分
1) 数据库操作知识
2) 后台编程语言知识
3) 前台编程语言知识
4) 业务知识

通过以上的分析可以看到，在第一个阶段所需知识单一，更多的源自于经验。由于所使用知识比少，当需求产生变化时，为变化所花费的时间也比较少。因此可以得出一个简单的结论，当某一个步骤所需知识比较单一时，对该步骤的变更和编码所需时间都比较少。

8. IT员工的考核标准

IT员工的考核

绩效考核是企业绩效管理体系的重要组成部分，目的是为了改进部门或员工的工作绩效，考核与计划密切相关，既可针对个人，也可针对部门或项目团队，故有“个考”与“团考”之分。在企业的管理实务中，绩效考核是公认的人力资源管理难点之一，做得好有正向作用，否则会有副作用。 中国金融大典

企业一般都根据战略规划，拟定每年的工作计划，再将年度计划分解成各部门的年度计划。大多数情况下，业务部门的计划定量居多，而职能管理部门的计划以定性为主，所以较难定量地衡量工作绩效。因此，成本中心性质的职能管理部门的绩效考核较难做，IT部门尤其难。

众所周知，企业长期目标需要通过每年的计划逐年实现，信息化工作也一样——年初定计划、年底再考核，如果发现结果有偏差，只能来年再改善，所以考核不能光在年底做，在年度计划执行中也要做，以便及时发现问题与偏差，进行调整或改进，以保障年度目标的实现。我认为，CIO重视结果固然没错，但也要重视控制过程式的考核，不管这种考核是月度考、季度考还是半年考。针对IT部门的考核体系如何建立，应权衡各方因素综合考虑，因为考核与其他管理行为一样，是有管理成本的。

以往，我在IT部门基本实行的是以项目管理为主线、专业IT管理为辅线的内部管理体系。年初，我将公司下达的全年信息化工作计划分解到各项目，实行项目经理负责制;其他事务则以日常管理为主，年终考核以“团考”为主、“个考”为辅。平时自然会论月或论季定期检查、半年做个小结，根据运作情况，对相关部门或人员“敲敲边鼓”，必要时再适当调整计划，但并没有做严格意义上的年中考核。

今年，IT部门根据公司新规划的需要设立了专业二级部门后，每个二级部门的定位、每个专业岗位的职责更清晰了。IT部门的工作任务就直接分解下达到各二级部门了，而公司级与跨二级部门的项目仍然实行项目制，所以试行年中考核的机会比较成熟。

其实，我之所以说IT部门的考核难做，主要是有不少难题需要解决，还要考虑如何方便操作、不至于耗费太多管理成本。比如：

考核对象

“团考”针对的是整个IT部门，还是仅仅针对二级部门;项目考不考;跨年度运作的大项目如何考：“个考”考哪些人。

考核组织与分工

由谁来考?总裁还是分管副总裁，抑或是人力资源总监牵头的考核班子，或是IT部门管理层自己考核下属员工。

考核内容和项目

除了计划、任务完成情况外，是否还要对内部管理、团队协作、员工成长及内部客户满意度等进行测量：“团考”与“个考”内容能一样吗;不同专业性质的二级部门或员工的考核内容能一样吗?

考核指标及评价标准

制定哪些KPI;要区分不同岗位吗;每个KPI的评价标准如何定;如何将定性指标量化;各个指标的权重如何分配：“团考”和“个考”如何关联。

考核方式和周期

是用表格测评，还是访谈;测评表、调查表的内容、分值如何制定;访谈提纲要统一吗;选哪些访谈对象;被考核对象是否要先小结与自评;测评要几个纬度;年中考核与年终考核如何区分与关联。

考核结果及应用

考核结果如何反馈、谁来反馈;考核结果不理想，是否要调整任务或岗位;要不要和奖励直接挂钩;年中考核的改进建议，年终考核如何检查。

我相信这一系列难题，专业的HR管理咨询公司都可以提供一整套所谓解决方案，来帮助CIO解决。问题是，你“玩”得起吗?企业愿意投入咨询费用吗?咨询项目做完后，能保证有效的知识转移吗?企业的HR部门今后能够就此操作实施吗?咨询方案年年都可以照搬吗?

今年，公司决定在我们的IT部门试行年中考核后，人力部与我们共同商讨提出了比较切实可行的方案，最后由领导牵头、两个职能管理部门共同组成的考核组，用了并不太长的时间就完成了本次考核。这个考核方案得到了大多数员工的理解与赞同，认真参与，内部客户也很认真对待。通过测评、内部调查、沟通和访谈等过程，人力部增进了对IT部门总体情况的了解。我也打算根据发现的一些问题，适当调整管理策略，比如授权、汇报关系、任务分工与目标界定等。此次年中考核也为年终考核打下了基础，能够确保IT部门全年工作计划的全面完成。

我认为，在整个考核过程中，CIO应与人力资源部门一起根据企业的发展需要、管理水平和条件，持续地改进绩效考核工作，完善IT部门的绩效管理体系，以激励员工取得更好的绩效。

9. kpi如何跟it项目结合

研发岗位，首先是程序员，参考了一些文档，暂且定义如下：岗位职责：1完成项目经理安排的开发任务；2按照详细设计文档编码；3对所负责的开发模块进行单元测试并通过；4修改测试部门反馈的缺陷；5对使用公司或部门产品/框架提出反馈意见；6定期完成工作周报，向项目经理汇报。序号 指标名称 定义 计算公式及考核方法1 完成代码数量 完成的代码行数 工具统计所得的代码行数×难度系数（难1.2，中1，易0.8）2 工作态度 是否迟到早退、工作是否认真积极 定性指标3 整体bug数量 所负责的模块所产生的bug数量 Bug数量×严重程度系数4 修复缺陷引起其他缺陷的数量 修复bug后再次产生的bug数量 Bug数量×严重程度系数5 计划时间与实际完成时间的偏差 项目经理计划的完成时间与实际完成时间之间的偏差 （实际完成天数－计划完成天数）/计划完成天数6 提出建议和意见 对项目组或部门的实际情况在管理、技术上提出有益的建议和意见的条数