资源预览内容
第1页 / 共11页
第2页 / 共11页
第3页 / 共11页
第4页 / 共11页
第5页 / 共11页
第6页 / 共11页
第7页 / 共11页
第8页 / 共11页
第9页 / 共11页
第10页 / 共11页
亲,该文档总共11页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述
以任务为核心的 IT 研发项目管理体制浅释_研发管理_企业管理0 0 引言引言经过近半个世纪的发展,信息技术(IT)已经渗透到社会各个领域和人们的 日常生活,信息化建设已经成为我国社会主义现代化建设的一个重要组成部分。 因此,与之相关的项目管理(以下简称 IT 项目管理)也越来越受到业界的重视, 人们从理论和实践荫个方面不断探索着 IT 项目管理的有效方法。然而,由于 IT 项目尤其是以软件研发为主的大中型项目的高度复杂性和不确定性,项目管 理中普遍存在的诸多问题至今尚未从根本上得到解决。这些问题可以概括为以 下两大方面:一是对于一个项目,预先的估算和项目计划同实际过程总是存在 着较大偏差,以至于不得不在实施过程中反复调整计划,不但造成了超出预期 的资源、成本消耗,而且不能保证达到预期的进度和质量要求,甚至造成项目 半途而废;二是对于一个组织,每当一个 IT 项目尤其是较大规模的项目立项, 总是存在着人手不足、亟待聘人的现象,当项目完成之后,就会人浮于事,而 一旦再做新的项目还是人手不足。伴随着两大普遍性问题,同时出现了管理上 的误区:要么仅从具体项目和具体管理技术入手寻求解决问题的方法,要么盲 目套用别人的管理模式。这样做,非但没能解决问题,反而增加了额外的资源 消耗。通过总结已有的经验教训和对问题产生原因的分析,笔者认为要从根本上 解决上述问题,须根据 IT 项目自身的客观规律在组织层面建立起一整套合理的 管理体制及运作机制。对于一个组织而言,所谓的管理体制,就是由组织结构 及责权利分配形式、工作流程及具体操作规范构成的一套管理体系,其中的责 权利分配形式则构成一种运作机制。组织的性质不同、经营目标不同、管理理 念不同,所创建的管理体制就会千差万别。那么,对于一个以 IT 项目研发为主 的企业,怎样的管理体制才算是合理的?又如何才能建立起合理的体制及机制? 这其实涉及到社会、文化,心理、思想意识和管理理念等诸多方面,如果从这 种角度入手进行理论推导,其复杂度极高,甚至得不到结果。因此,本文避开 这个复杂过程,而是从实践经验出发,提出了“以任务为核心”的总体思路或 管理理念,然后围绕“任务”这个核心来建立研发项目管理体制。于是,下文 的内容包括:首先诠释“任务核心论”,然后描述以任务为核心而建立起来的 管理体制及运作机制,最后以示例形式简要说明在所建立的体制下 IT 项目的实 施过程,并指出如何避免上述两大问题的发生。1 1 任务核心论诠释任务核心论诠释这里所说的任务是指一个组织为了实现其经营目标而开展的所有业务工作 的总和。对于一个以 IT 项目研发为主的组织来说,任务就是所有研发工作的总 和。所谓“以任务为核心”就是把任务作为考虑问题的出发点,就是使管理面 向任务而不是面向人,就是根据任务的需要来决定组织的结构和行为。当然, 这并非与当今企业所倡导的人本文化相矛盾,而仅仅是作为建立管理体制的一种思路。相反,用这种思路所建立起来的管理体制恰恰体现了人的责权利需求 和发展需要。为了建立起一整套以任务为核心的管理体制,需要对任务进行分解。从层 次上将其分为高、中、低三个层面,然后在不同层面进行任务规划,逐层进行 任务管理。1.11.1 高层面研发任务规划高层面研发任务规划高层面研发任务规划的工作包括:首先根据组织的经营性质在战略上确定 技术研发方向;然后根据组织的年度研发产出指标、利润指标以及中长期发展 目标来确定产品研发范围并制定出短、中、长期产品研发目标;最后根据所制 定的年度研发目标来限定年度研发成本投入额和研发队伍的总体规模及技术人 才构成。高层面任务规划虽然表面看上去同一个具体项目过程关系不大,但其实却 从根本上决定着项目的管理方向。它首先从研发范围和资源构成方面做出了框 架性限定,使项目的实施必须考虑这种限制,从而必须对项目进行细致合理的 规划,以求利用有限的资源实现预定的目标。也就是说,高层面任务规划结果 使得中层面任务规划既有切实依据又有明确目的,避免了管理的盲目性。1.21.2 中层面研发任务规划中层面研发任务规划中层面研发任务规划,则是根据高层面规划所确定的技术方向、产品范围 和所限定的资源条件,首先在调研的基础上进行产品策划,然后通过对产品研 发任务内在联系的分析,将产品研制任务分成若干个可以付诸实施的具体项目, 并规定每个项目的研发目标、完成期限、验收准则和成本投入额;再通过需求 调研,分析确定项目的需求,为下一步的设计和开发定义范围和目标。由于中 层面任务规划建立在高层面任务规划所确立的方向、目标和所限定的条件的基 础上,因此其规划结果,即所确立的具体研发项目,应既能保证高层面任务目 标的完成,又能使资源成本消耗不超出所限定的范围。1.31.3 低层面研发任务规划低层面研发任务规划低层面研发任务规划,则是对中层面任务规划所确定的每一个具体项目进 行细致的任务划分分解为可以落实到个人进行开发的模块,并规定每个模 块的质量要求、完成期限、验收方式及准则;然后把模块开发任务落实到人, 直到该项目的研发目标实现为止。综上所述,有了高层面任务规划的限定、中层面任务规划的合理、低层面 任务规划的精细,项目的成功就有了保证。接下来就是要建立一套面向各层面 任务的管理体制。2 2 以任务为核心的以任务为核心的 ITIT 项目管理体制项目管理体制2.12.1 研发组织结构研发组织结构一个企业的 IT 项目研发过程,其组织结构如图 1 所示。图 1. 以任务为核心的研发组织结构如有任何看法或投稿请联系 MSN:liangxi1122hotmail.com;QQ:85557991对图 1 的几点说明:(1)这种组织结构是根据上文介绍的任务层次及任务规划职责而构建的。其 中,技术副总负责高层面任务规划,项目策划部门负责中层面任务规划,项目 开发部门负责低层面任务规划与产品实现。另外,质量检测部门则负责各个阶 段产品和集成产品的质量检测与把关。根据所承担任务层次的不同,不同的部 门、不同的岗位,其级别也不同。(2)这种组织结构与目前常见的研发组织结构的主要区别在于:1)部门的划分是依据任务的层次,也就是根据不同层面的任务规划职责而 划分出级别不同的部门,自上而下逐层进行任务管理,而不是按业务种类划分 为并列部门。2)取消了“项目组”的概念,而是由不同部门分担不同层面的项目研发任 务。3)除了部门经理外,不再设置其他专职管理岗位,而是靠一种机制来自动 控制项目的质量与进度。(3)该研发组织结构的优点:1)首先可以从根本上解决上述 IT 项目管理中的第二个普遍性问题。因为该 组织结构打破了原来的并列部门、并列项目组之间的界限,使所有资源可以统 一调配,从而避免不同项目之间资源冲突的出现;又由于中层面任务规划考虑 了资源限制,从而确保所规划的项目可以通过现有资源来完成。2)避免了资源重复性消耗。常见的并列式研发组织结构,难免会出现不同 部门或不同项目组中有相同工种的人员在重复做着相同或相近的开发工作。因 IT 领域人力成本很高、工作周期又长,这种人员和工作的重复对于一个组织来 说是一种不容忽视的资源浪费。而图 1 所示的组织结构不会出现资源重复消耗 的现象。3)削弱了内部竞争,加强了内部协同。在并列式研发组织结构中,不同部 门、不同项目组之间以资源和利益冲突为主,缺乏协同机制。而图 1 所示的组 织结构使得不同部门之间形成一种相互依存关系,即对于某个部门而言,没有 其他部门的输出,也就没有本部门的成果或利益。例如,对于项目开发部,没 有策划部规划出来的研发项目,便无事可做,也就无利可得;没有质量检测部 的检测结果,便得不到对研发工作的认可,也就无法获得应有报酬。这种关系 可以使各部门之间互相督促、相互支持,而不是冲突和抵触。当然,这种组织 结构中也存在着竞争关系,但仅限干同一岗位的不同人员之间的工作能力竞争, 这是一种小范围内的有益竞争,既利于工作的开展又利于个人能力的提高。4)有利于组织结构的稳定和个人发展。相对稳定的组织结构是组织发展的 基础,图 1 所示的组织结构不会因业务内容的改变或业务量的增减而变化,即 具有一定的稳定性。虽然结构是静态的,但人员可以动态调整(升迁),从而满 足个人发展需要。2.22.2 研发工作流程研发工作流程这里的研发工作是指高层面任务规划完成之后,即基本技术方向及产品范 围、研发目标已经确定,研发组织规模及结构已经形成之后,组织所开展的连 续性的项目研发活动,也就是本文前面所述的中层面任务规划、低层面任务规 划及实施过程。根据这两个层面任务规划的内容,在研发流程中分别将其映射 为项目定义阶段和项目开发阶段,如图 2 所示。图 2. 以任务为核心的研发工作流程对图 2 的几点说明:(1)这里的“产品”是广义的,“产品研发建议”是指提出新产品概念或建 议参加某个应用项目的投标,“产品策划”则是针对所提出的建议而进行的高 层面的、全方位的需求论证和可行性论证。这里的“项目”并非以产品为单位, 而是根据一种或多种产品研制任务的内在联系,将研发任务重新排列组合而构 建出来的一个或多个具有明确目标的任务集合,而且以“流水线”形式进行研 发。(2)项目计划不再是项目立项后、开发前进行的一项独立活动,而是渗透在 整个研发流程中,且表现为层层深入、逐步细化。这便顺应了 IT 项目自身不确 定性的客观规律,避免出现最初制订一个完整计划却与实际情况偏差较大的现 象。(3)项目定义阶段的各项工作由图 1 所示的项目策划部负责实施,项目开发 阶段的工作则由项目开发部负责实施。另外,对于每项活动和每个阶段产品, 都由质量检测部进行规范性监查和质量检验与评价。(4)把需求开发过程同系统设计实现过程分离,且由不同部门承担。这样做, 一是可以使不同的项目交叉并行,即保持第 n+1 个项目的需求分析活动与第 n 个项目的设计开发活动同时进行,从而使研发工作以流水线形式连续不断,避 免资源闲置现象。二是可以保证需求分析的充分、细致,从而减少需求变化对 开发过程的影响。对需求的充分把握和掌控是保证项目按计划完成的一个关键 环节,而原有研发流程都是把项目的需求分析甚至产品预研过程同开发实现过 程混在一起,且完全由一个孤立的项目组来承担。由于模块开发的周期是难以 缩短的(除非大量增加开发人员使所有模块并行开发),故在有限的时间里,不得不缩短需求开发的时间,甚至需求尚未明确便过早地进入设计开发阶段,以 至于当需求发生变化时,便前功尽弃,甚至导致项目失败。以任务为核心的研 发项目管理体制则从组织层面提供了这个问题的一般性解决方法。如有任何看法或投稿请联系 MSN:liangxi1122hotmail.com;QQ:855579912.32.3 责权利分配原则责权利分配原则如果把组织结构及工作流程比喻为管理体制的骨架和肉体,那么责权利分 配形式便是管理体制的灵魂,它决定着体制如何运行,即构成一种运作机制。在以任务为核心的管理体制中,责权利的分配形式是由任务决定的,是具 体而明确的。“责”即指任务承担者对任务所负职责和所承担的风险,“权” 即指任务承担者对任务的处理权和对相关人员的处置权,“利”则指任务承担 者在完成任务后应得的绩效薪酬和职位升级。其基本分配原则如下:(1)任务层次的高低决定着职责与风险的大小。即任务的层次越高,任务承 担者的责任就越大,所承担的风险也就越高。(2)权、利与责成正比。(3)对于同一层次的任务,利与所完成的任务量成正比,即多劳多得。(4)在上述原则基础上,对于所有任务,其利的分配都必须用任务完成的质 量和效率进行修正。即对于每一项具体任务,利 oc 任务量 X 质量系数效率系 数。(5)对于管理者(各部门经理),其利的分配首先取决于本部门完成的总任务 量和质量、效率,然后用部门人力资源超出定额的比例加以修正部门人数 超定额越多,部门经理所得绩效薪酬越少。(6)对于不同部门、不同岗位,责权利的分配应形成部门之间、岗位之间既 相互依存、相互促进,又相互监督、相互制约的关系。2.
网站客服QQ:2055934822
金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号