研发项目管理的机制保障.docVIP

研发项目管理的机制保障 　　上世纪70年代中期，美国国防部曾立题专门研究软件项目做不好的原因，发现70%的项目是因为管理不善引起的，而并不是因为技术实力不够，进而得出一个结论，即管理是影响软件研发项目全局的因素，而技术只影响局部。可见在研发项目中管理的重要性。 　　而笔者在本土软件公司协助建立项目管理制度时发现，以项目工作形态为主的企业，其项目管理之失败在于缺乏一套有效的运作机制，而不是部门主管缺乏执行力。 　　以研发项目为例，由于项目管理方法及软件已经相当普遍，大部分的项目经理都知道如何展开工作计划及分配工作项目，比较常遇到的，反而是下列问题： 　　研发人员未主动向项目经理汇报工作情形与遭遇到的困难，导致项目经理无法及时掌握进度，并将问题排除。 　　项目经理未在适当的时间请其它部门提供必要的支持，或是这些支持事项到后来石沉大海，没有下文，影响到项目的进度。 　　大部分的研发人员不愿意制作项目管理所需之文件，例如：填写会议记录、工作计划、产出成果文件等，导致后来执行类似项目的人员，没有资料可以参考。 　　决议事项未被遵守，没有人执行后续工作，导致事情延宕。 　　项目相关文件资料未适当整理及保管，甚至遗失。 　　当项目规模不大，或只是一两个项目时，这些可能只是小问题，项目经理只要提高意志力或执行力即可解决。一旦项目规模扩增，变成有数十个单位共同参与 ，而且同时有数十个项目一起进行时，这些小问题的影响就会累积成大问题。所以对于拥有较大规模研发团队的制造业，必须建立一套项目管理机制，让项目管理成为每个人的责任，便利各项产品开发工作的推动。 　　资源管理机制 　　X企业是一家ERP系统开发公司，接到订单后，必须依据客户要求列出待开发的功能项目，交由研发部门执行程序开发，并整合成为系统功能的一部分，再由客服部门提供导入的服务，工程师协助客户安装系统，以及提供使用者教育训练。 　　这天，负责A客户系统导入的项目负责人李勇拿着手上的单子，怒气冲冲地朝着研发部门走去，原来他已向客户承诺明天前往安装新系统功能，但是刚刚手下的工程师通知他研发部门还没将功能开发完成，情急之下就想找研发主管理论。 　　李勇见到研发主管齐威时，强压下心中怒火，以还算委婉的语气询问两周前即已提出的功能开发需求，为何到今天尚未完成。由于李勇面色不善，一向不喜与人争执的齐经理耐着性子向李勇解释：“由于这两周的开发项目比较多，其中有大型客户预定的开发项目，必须到下周一才能将A客户的功能需求完成。”齐经理解释后，李勇怒气未消，质疑着说依过去的经验，A客户所需的功能只要60个工作小时即可完成，研发部门有那么多人，为何已花了两个礼拜的时间还无法完成。齐经理说：A客户所需功能的开发时数不只60小时，此外由于研发人员擅长的项目不尽相同，而且还有新人要训练，所以研发部门会将预计开发的项目与人员的专长作调配，再来排时程，不太可能直接将工作时数换算成天数来交件。另一方面李勇当时只是传来一张联络单要求开发的功能项目及日期，并未与研发部门进一步确认这些功能开发的难易度及时程。齐威进一步质疑A客户的需求早在上个月中即已收集完毕，李勇为何不早点提出，造成研发部门上个月有2名人员闲置，而这个月所有人员都得加班的不平衡现象，增加其管理上的困扰…… 　　企业在资源管理方面常遇到下列问题： 　　规划项目应完成的工作时，无法合理估计需要多少资源，包含：人力、设备、共同资源及其它辅助单位的支持;项目执行时，原本预定的资源遭挪用，由于人力断层导致项目进度中断或延后;或是提供支持的部门迟迟无法将工作完成，影响到研发部门后续工作的进行;部门人力资源分配不均，有些人员业务繁重，有些人员则游手好闲;对部门资源的需求未作适当安排，造成某些月份工作量大，某些月份人员闲置;缺乏客观的数据来评估部门或人员执行工作的效率，也没有预计与实际工作时数的比较数据。 　　为了解决这些问题，在资源管理方面则应建立以下制度： 　　标准工时制度。将参与研发流程的相关部门区分为主体部门、共享资源部门、支持部门。再由各个部门依据详细工作清单，估计每个项目的标准工时，或工时范围。 　　部门资源分配制度。评估人员的素质，初步计算部门对于每个工作项目所能提供的最大产能;设计资源分配表，显示资源分配及耗用情形;应重视人员的能力、成长性，使实际执行情形与标准工时相符;运用作业研究等资源分配工具;律定资源挪用的权限、判断标准与机制。 　　部门/人员工作时程规划。规定时程变更的机制;设计各部门及人员的工作程序和方式;将此信息以及时的方式提供给其它部门。 　　资源耗用统计。设计工时报告并要求人员填写;累计资源耗用时数。 　　进度管理机制 　　企业在进度管理方面经常遇到以下问题： 　　第一， 对于整个项目包含了哪些工作、如何完成、执行的顺序等，缺乏通盘的规划。