中人网

标题: 案例讨论：研发部绩效考核案例分析 [打印本页]

作者: 小个儿 时间: 2010-5-31 17:16
标题: 案例讨论：研发部绩效考核案例分析

L公司研发部，人数30人，分为A/B/C三个专业，其中A专业9人（2个负责人），B专业6人（1个负责人），C专业15人（3个负责人），项目组的成立采取自由组合的方式，对项目组的考核主要采用核对项目周期等，暂无疑义。
主要问题，L公司研发部除了负担新项目研发外，对老项目的维护，也占日常工作的大部分时间，因此，对研发部日常工作的考核也是重点，考核内容为：
普通工程师：任务的完成情况，包括完成的时间控制、完成质量等；
专业负责人：文件审核的时限、质量，工作指导，疑难问题解决等；
共同：个人能力、专业知识、协同协作能力等。
如何确立合适的绩效考核方案，以满足L公司研发部对日常工作考核的需求？

要求：方案可执行度高、简单易行，公平合理。

作者: 小个儿 时间: 2010-6-1 12:29
标题: 回复：案例讨论：研发部绩效考核案例分析
难题未解

作者: 湖南人在他乡 时间: 2010-6-1 14:02
标题: 回复：案例讨论：研发部绩效考核案例分析
从案例来看，L公司的研发部的主要职责有两大块即新项目开发和原有研发项目的维护。而绩效考核欲达到的目的是对研发部每个成员的工作过程能够有效管理与改进提高。因此在绩效方案设计过程中由于研发部各岗位的职责不同，如果想对不同岗位的工作过程采取绩效管理的办法有效监督与提高，实属不易。愚见认为不妨试用以下方案：方案1：基于项目的目标管理（MBO)考核法，具体操作是每季度各项目组成员在项目负责人（考核人）带领下制定下一季度本项目组的项目任务计划，并制定出详细的MBO行动计划来（包括项目、进度节点、项目验收标准（以满足客户要求为最低标准）、行动措施（包括如何开展项目、需要怎么的协作）。考核人只需按其MBO行动计划进行检验即可。方案2：基于项目的kpi考核法，具体操作是考核人首先得要结合各研发岗位的职责及其在各项目中的主要任务找到相应的KPA再依据设计提取相应的KPI指标（KPA1:新项目开发中的KPI指标：开发进度、开发质量、开发成本控制，具体依据企业而言；KPA2:原有项目改进与维护中的KPI指标：老产品的客户满意度、老产品的再创新（创新进度、质量）、老产品的制造成本下降率（旨在考查研发人员对项目批量生产后其在研发前期的非标准零部件的标准化选用的改进）等）同时，建议无论采取哪种方案均可增加一个研发人员个人学习与成长方面的考核。可根据企业需要设计一个研发人员能力提升计划案。以上仅是凭案例所列情况提出个人浅见，旨在“抛砖引玉”。

作者: 等待之外 时间: 2010-6-1 17:27
标题: 回复：案例讨论：研发部绩效考核案例分析
湖南人的答复很精彩，真是行家一出手，就知有没有，不过软件工程师的考核确实很难做，我们公司先前做过，但是很失败，期待分享小个儿的胜利成果

作者: 小个儿 时间: 2010-6-2 10:00
标题: 回复 3F 湖南人在他乡的帖子
十分感谢湖南人在他乡的回答，我们公司的情况实属特殊，首先我们的考核目标就目前来说，仅仅是为了提升研发效率，另外，一般常用的KPI的指标，并不适用我们现在的情况，对于老产品问题的解决，多数是设计缺陷甚至是影响使用的设计bug，并不是良性改进。因此，研发部门除了正常的设计工作外，多数处于“救火”的状态，现在要考核的就是“救火”的效率、质量等。

作者: 萧然1983 时间: 2010-6-2 10:22
标题: 回复：案例讨论：研发部绩效考核案例分析
呵呵，一直在软件行业工作，给楼主提供一些思路，具体的就要自己解决了；软件公司主要分为软件开发，项目实施和硬件管理三大部分，所以考核也得分为三类；根据工作重心不一样进行考核；基本是KPI配合360，考核基础是工作数据：软件开发：开发程序个数，耗时，质量；合作开发程序个数，耗时，质量；系统问题/客户问题解决个数，耗时，质量；项目实施：项目计划书的时间进度管理为主要；团队管理，沟通实施等；

作者: 小个儿 时间: 2010-6-2 12:44
标题: 回复 6F 萧然1983 的帖子
谢谢回答，我们不是软件行业，算是制造业吧，项目包括软硬件、结构设计等，我现在的困惑就是对技术类的工作如何量化。十分感谢楼上各位的回答，可能是我刚刚接触绩效管理，了解的太少，对各位的回答我还得细细消化。

作者: chenxb 时间: 2010-6-3 09:08
标题: 回复：案例讨论：研发部绩效考核案例分析
针对性要强层次性要清楚

作者: hongzhou 时间: 2010-6-7 02:33
标题: 回复：案例讨论：研发部绩效考核案例分析
“"救火"的效率" 说的很到位啊，呵呵~ 刚来就找到个能借鉴的帖，占位！救火这块是不是可以从：接警反应，灭火速度，挽回损失，失火原因，隐患排查，消防能力硬件建设，消防能力软件建设等方面进行考核。外行人插两句外行话，权当我凑热闹了，楼下各位继续哈~

作者: viviangemini 时间: 2010-6-7 13:37
标题: 回复：案例讨论：研发部绩效考核案例分析
技术人员的工作为什么要量化？是从数量上考虑还是完成时间上考虑？技术类的工作是很难量化的，比如写代码，如果一天规定写10行代码，或许技术人员写了10行，但只有1行是有用的。再比如说BUG，运行检查BUG应该是由测试人员完成的，考虑如何减少BUG比较重要。

作者: 温柔刀客 时间: 2010-6-7 14:39
标题: 回复：案例讨论：研发部绩效考核案例分析
假如员工经常处于救火状态的话那考核就难了，主要是因为岗位职责不确定，及主要的工作流程也不确定。

作者: 小个儿 时间: 2010-6-7 16:51
标题: 回复 10F viviangemini 的帖子
正是因为研发人员的工作不好量化，所以绩效做起来很难。程序员至少还有代码的行数可以参考，先不说参考的准确率，但是对于硬件设计及结构设计的工程师就更难量化了，结构设计，图纸的复杂程度根本就无从量化。所以这个问题我还在纠结中。。。

作者: pengyuanpin 时间: 2010-6-12 11:17
标题: 回复 10F viviangemini 的帖子
我所在的公司也遇到同样的难题。研发部既要完成预研项目，还要完成目前客户的定制项目。而且每次都不能及时交货，虽然客户没有要索赔，但是效率低下，收益也低。而且部门管理混乱，每个项目没有落实到责任人，哪位员工有空，部门领导就让他做，多次与其部门领导交流，可是还是得不到改善。这样也没法追究责任，奖励也没有依据。怎样改善该部门的效率，规范管理呢，请各位高手支招。

作者: shicaiyuan 时间: 2010-6-13 16:42
标题: 回复：案例讨论：研发部绩效考核案例分析
发现HR的思维还是比较局限于微观的东西，系统思维不够，我想原因很多，我们可怜的HR经常被纠缠在细节的事务当中去了，日子久了自然也就缺乏大局观了。任何一个公司推行绩效必须都是从公司到部门，再到个人。这个案例失败的地方，或许说他误导了广大HR的地方在于：直接把HR的思路引导到具体岗位、具体成员的考核上去了，从而忽视对部门绩效、公司绩效的分析、判断，从而造成绩效考核输入端为垃圾，输出也为垃圾。研发部绩效考核方案：首先肯定是要把研发部今年的绩效考核的内容描述出来（如果你不能描述，你就不能评价，如果你不能评价，你就不能管理），如果要描述，肯定是要收集一大堆资料：收集公司年度经营目标——收集研发部年度工作规划——收集研发部部门职责+岗位职责——收集研发部过去1-2年的绩效考核资料其次，仔细分析研发部绩效考核的资料，建议的工具：行业分析、竞争对手分析、swot、价值链分析、最后用OGSM工具列出部门考核内容再次将OGSM内容分解到研发部岗位成员上去。这个过程，其中人力资源部可以做的事情是：1、培训并设计工作计划，组织开展设计绩效方案的计划，2、提供过去的考核资料包括记录和数据；3、组织开展年度工作规划；4、用OGSM分解出各研发部岗位成员的考核指标；5、分析、评估其他部门绩效方案的smart的情况我希望给论坛新人一个建议：永远不要越俎代庖地给业务部门定指标，您可以影响，可以培训，但就是不可以给人家定指标，原因很简单绩效管理是业务部门管理者的核心内容，如果您都帮人家做了，等于你耕了人家的地，睡了人家的老婆，这个问题就很严重了。也许我说的有些理论，会让一些HR失望，但毕竟这才是正确决绝绩效管理的思路，一个连自己定位都不清楚的人，能做好工作吗？跑龙套的就是跑龙套的，要做主角，就回到自己的一亩三分地上去干

作者: yxx_ni 时间: 2011-1-3 16:23
研发期限较长，成果转化较慢，考核应按计划实施。

作者: cinderellagf 时间: 2011-1-19 16:51

我也觉得应该HR培训业务部门怎么做指标，而不是代为做指标。但是老总交待下来要做指标，也没办法了。。

作者: huanghe425 时间: 2011-1-20 13:50
bug根据技术难度、项目难度来衡量的，如果这样就要考虑到人员胜任力不同、项目整体难度不同、技术难度不同，乘上这样的系数。我原来就这样考虑的，但是这样系数的确定以及说明不是人力资源考核的人就能定的出来，需要逻辑思维很强的开发人员，来和你扯皮
楼主要解决的的效率和质量，目的是推动研发进程，内部奖惩公平
我们扮演的只是推动、协助和局外观察。
如果我们要引入质量管理体系去管，那就需要成立专门的考核专项组，不知道楼主有没有这么多人
基本情况就得靠我们自己，我的对研发部门的口号是“帮助管理者更好的管理、帮助研发人员更好的成长”，把这个过程记录下来。也就是把这个项目的过程切碎，目标变小，半月考核为最小单位，使用目标管理，问题就在这半个月中发现和解决，都体现在目标管理的表中。月度或季度，部门考核员汇总，部门经理确认。
老项目的维护，认同楼上的说法，就是顾客满意度，现在是新项目开发为主要目标，老项目维护自扫门前雪的事情，如果前期做的不好，后果也得项目组或开发人员自己承受

作者: 杨锡 时间: 2013-3-12 10:19

shicaiyuan 发表于 2010-6-13 16:42 ( P$ @5 L" R% f+ @6 M Y
发现HR的思维还是比较局限于微观的东西，系统思维不够，我想原因很多，我们可怜的HR经常被纠缠在细节的事务 ...

很有道理，可能是HR已经把这些化在大脑里了，变成了基础条件。不管这些有没有，这些全局的思路必须有，但是不一定要表现出来。把理论、体系都化作看似凌乱的方案中，别人都看出什么模式，那这样的HR看成高手。
最忌讳生搬硬套理论和体系的模式，其实整天把这些专业术语摆出来HR是不专业的，因为不自信，所以需要一些工具来遮挡。

真正HR高手是把强大的理论体系化作凌乱的方案，其实：解决问题就好！

欢迎光临中人网 (http://bbs.chinahrd.net/)