0 引言

    经过近半个世纪的发展，信息技术(IT)已经渗透到社会各个领域和人们的日常生活，信息化建设已经成为我国社会主义现代化建设的一个重要组成部分。因此，与之相关的项目管理(以下简称IT项目管理)也越来越受到业界的重视，人们从理论和实践荫个方面不断探索着IT项目管理的有效方法。然而，由于IT项目尤其是以软件研发为主的大中型项目的高度复杂性和不确定性，项目管理中普遍存在的诸多问题至今尚未从根本上得到解决。这些问题可以概括为以下两大方面：一是对于一个项目，预先的估算和项目计划同实际过程总是存在着较大偏差，以至于不得不在实施过程中反复调整计划，不但造成了超出预期的资源、成本消耗，而且不能保证达到预期的进度和质量要求，甚至造成项目半途而废；二是对于一个组织，每当一个IT项目尤其是较大规模的项目立项，总是存在着人手不足、亟待聘人的现象，当项目完成之后，就会人浮于事，而一旦再做新的项目还是人手不足。伴随着两大普遍性问题，同时出现了管理上的误区：要么仅从具体项目和具体管理技术入手寻求解决问题的方法，要么盲目套用别人的管理模式。这样做，非但没能解决问题，反而增加了额外的资源消耗。

    通过总结已有的经验教训和对问题产生原因的分析，笔者认为要从根本上解决上述问题，须根据IT项目自身的客观规律在组织层面建立起一整套合理的管理体制及运作机制。对于一个组织而言，所谓的管理体制，就是由组织结构及责权利分配形式、工作流程及具体操作规范构成的一套管理体系，其中的责权利分配形式则构成一种运作机制。组织的性质不同、经营目标不同、管理理念不同，所创建的管理体制就会千差万别。那么，对于一个以IT项目研发为主的企业，怎样的管理体制才算是合理的?又如何才能建立起合理的体制及机制?这其实涉及到社会、文化，心理、思想意识和管理理念等诸多方面，如果从这种角度入手进行理论推导，其复杂度极高，甚至得不到结果。因此，本文避开这个复杂过程，而是从实践经验出发，提出了“以任务为核心”的总体思路或管理理念，然后围绕“任务”这个核心来建立研发项目管理体制。于是，下文的内容包括：首先诠释“任务核心论”，然后描述以任务为核心而建立起来的管理体制及运作机制，最后以示例形式简要说明在所建立的体制下IT项目的实施过程，并指出如何避免上述两大问题的发生。

1 任务核心论诠释

    这里所说的任务是指一个组织为了实现其经营目标而开展的所有业务工作的总和。对于一个以IT项目研发为主的组织来说，任务就是所有研发工作的总和。所谓“以任务为核心”就是把任务作为考虑问题的出发点，就是使管理面向任务而不是面向人，就是根据任务的需要来决定组织的结构和行为。当然，这并非与当今企业所倡导的人本文化相矛盾，而仅仅是作为建立管理体制的一种思路。相反，用这种思路所建立起来的管理体制恰恰体现了人的责权利需求和发展需要。

    为了建立起一整套以任务为核心的管理体制，需要对任务进行分解。从层次上将其分为高、中、低三个层面，然后在不同层面进行任务规划，逐层进行任务管理。

1.1 高层面研发任务规划

    高层面研发任务规划的工作包括：首先根据组织的经营性质在战略上确定技术研发方向；然后根据组织的年度研发产出指标、利润指标以及中长期发展目标来确定产品研发范围并制定出短、中、长期产品研发目标；最后根据所制定的年度研发目标来限定年度研发成本投入额和研发队伍的总体规模及技术人才构成。

    高层面任务规划虽然表面看上去同一个具体项目过程关系不大，但其实却从根本上决定着项目的管理方向。它首先从研发范围和资源构成方面做出了框架性限定，使项目的实施必须考虑这种限制，从而必须对项目进行细致合理的规划，以求利用有限的资源实现预定的目标。也就是说，高层面任务规划结果使得中层面任务规划既有切实依据又有明确目的，避免了管理的盲目性。

1.2 中层面研发任务规划

    中层面研发任务规划，则是根据高层面规划所确定的技术方向、产品范围和所限定的资源条件，首先在调研的基础上进行产品策划，然后通过对产品研发任务内在联系的分析，将产品研制任务分成若干个可以付诸实施的具体项目，并规定每个项目的研发目标、完成期限、验收准则和成本投入额；再通过需求调研，分析确定项目的需求，为下一步的设计和开发定义范围和目标。由于中层面任务规划建立在高层面任务规划所确立的方向、目标和所限定的条件的基础上，因此其规划结果，即所确立的具体研发项目，应既能保证高层面任务目标的完成，又能使资源成本消耗不超出所限定的范围。

1.3 低层面研发任务规划

    低层面研发任务规划，则是对中层面任务规划所确定的每一个具体项目进行细致的任务划分——分解为可以落实到个人进行开发的模块，并规定每个模块的质量要求、完成期限、验收方式及准则；然后把模块开发任务落实到人，直到该项目的研发目标实现为止。

    综上所述，有了高层面任务规划的限定、中层面任务规划的合理、低层面任务规划的精细，项目的成功就有了保证。接下来就是要建立一套面向各层面任务的管理体制。

2 以任务为核心的IT项目管理体制

2.1 研发组织结构

    一个企业的IT项目研发过程，其组织结构如图1所示。

    (1)这种组织结构是根据上文介绍的任务层次及任务规划职责而构建的。其中，技术副总负责高层面任务规划，项目策划部门负责中层面任务规划，项目开发部门负责低层面任务规划与产品实现。另外，质量检测部门则负责各个阶段产品和集成产品的质量检测与把关。根据所承担任务层次的不同，不同的部门、不同的岗位，其级别也不同。

    (2)这种组织结构与目前常见的研发组织结构的主要区别在于：

    1)部门的划分是依据任务的层次，也就是根据不同层面的任务规划职责而划分出级别不同的部门，自上而下逐层进行任务管理，而不是按业务种类划分为并列部门。

    2)取消了“项目组”的概念，而是由不同部门分担不同层面的项目研发任务。

    3)除了部门经理外，不再设置其他专职管理岗位，而是靠一种机制来自动控制项目的质量与进度。

    (3)该研发组织结构的优点：

    1)首先可以从根本上解决上述IT项目管理中的第二个普遍性问题。因为该组织结构打破了原来的并列部门、并列项目组之间的界限，使所有资源可以统一调配，从而避免不同项目之间资源冲突的出现；又由于中层面任务规划考虑了资源限制，从而确保所规划的项目可以通过现有资源来完成。

    2)避免了资源重复性消耗。常见的并列式研发组织结构，难免会出现不同部门或不同项目组中有相同工种的人员在重复做着相同或相近的开发工作。因IT领域人力成本很高、工作周期又长，这种人员和工作的重复对于一个组织来说是一种不容忽视的资源浪费。而图1所示的组织结构不会出现资源重复消耗的现象。

    3)削弱了内部竞争，加强了内部协同。在并列式研发组织结构中，不同部门、不同项目组之间以资源和利益冲突为主，缺乏协同机制。而图1所示的组织结构使得不同部门之间形成一种相互依存关系，即对于某个部门而言，没有其他部门的输出，也就没有本部门的成果或利益。例如，对于项目开发部，没有策划部规划出来的研发项目，便无事可做，也就无利可得；没有质量检测部的检测结果，便得不到对研发工作的认可，也就无法获得应有报酬。这种关系可以使各部门之间互相督促、相互支持，而不是冲突和抵触。当然，这种组织结构中也存在着竞争关系，但仅限干同一岗位的不同人员之间的工作能力竞争，这是一种小范围内的有益竞争，既利于工作的开展又利于个人能力的提高。

    4)有利于组织结构的稳定和个人发展。相对稳定的组织结构是组织发展的基础，图1所示的组织结构不会因业务内容的改变或业务量的增减而变化，即具有一定的稳定性。虽然结构是静态的，但人员可以动态调整(升迁)，从而满足个人发展需要。

2.2 研发工作流程

    这里的研发工作是指高层面任务规划完成之后，即基本技术方向及产品范围、研发目标已经确定，研发组织规模及结构已经形成之后，组织所开展的连续性的项目研发活动，也就是本文前面所述的中层面任务规划、低层面任务规划及实施过程。根据这两个层面任务规划的内容，在研发流程中分别将其映射为项目定义阶段和项目开发阶段，如图2所示。

图2. 以任务为核心的研发工作流程

    对图2的几点说明：

    (1)这里的“产品”是广义的，“产品研发建议”是指提出新产品概念或建议参加某个应用项目的投标，“产品策划”则是针对所提出的建议而进行的高层面的、全方位的需求论证和可行性论证。这里的“项目”并非以产品为单位，而是根据一种或多种产品研制任务的内在联系，将研发任务重新排列组合而构建出来的一个或多个具有明确目标的任务集合，而且以“流水线”形式进行研发。

    (2)项目计划不再是项目立项后、开发前进行的一项独立活动，而是渗透在整个研发流程中，且表现为层层深入、逐步细化。这便顺应了IT项目自身不确定性的客观规律，避免出现最初制订一个完整计划却与实际情况偏差较大的现象。

    (3)项目定义阶段的各项工作由图1所示的项目策划部负责实施，项目开发阶段的工作则由项目开发部负责实施。另外，对于每项活动和每个阶段产品，都由质量检测部进行规范性监查和质量检验与评价。

    (4)把需求开发过程同系统设计实现过程分离，且由不同部门承担。这样做，一是可以使不同的项目交叉并行，即保持第n+1个项目的需求分析活动与第n个项目的设计开发活动同时进行，从而使研发工作以流水线形式连续不断，避免资源闲置现象。二是可以保证需求分析的充分、细致，从而减少需求变化对开发过程的影响。对需求的充分把握和掌控是保证项目按计划完成的一个关键环节，而原有研发流程都是把项目的需求分析甚至产品预研过程同开发实现过程混在一起，且完全由一个孤立的项目组来承担。由于模块开发的周期是难以缩短的(除非大量增加开发人员使所有模块并行开发)，故在有限的时间里，不得不缩短需求开发的时间，甚至需求尚未明确便过早地进入设计开发阶段，以至于当需求发生变化时，便前功尽弃，甚至导致项目失败。以任务为核心的研发项目管理体制则从组织层面提供了这个问题的一般性解决方法。

2.3 责权利分配原则

    如果把组织结构及工作流程比喻为管理体制的骨架和肉体，那么责权利分配形式便是管理体制的灵魂，它决定着体制如何运行，即构成一种运作机制。

    在以任务为核心的管理体制中，责权利的分配形式是由任务决定的，是具体而明确的。“责”即指任务承担者对任务所负职责和所承担的风险，“权”即指任务承担者对任务的处理权和对相关人员的处置权，“利”则指任务承担者在完成任务后应得的绩效薪酬和职位升级。其基本分配原则如下：

    (1)任务层次的高低决定着职责与风险的大小。即任务的层次越高，任务承担者的责任就越大，所承担的风险也就越高。

    (2)权、利与责成正比。

    (3)对于同一层次的任务，利与所完成的任务量成正比，即多劳多得。

    (4)在上述原则基础上，对于所有任务，其利的分配都必须用任务完成的质量和效率进行修正。即对于每一项具体任务，利oc任务量X质量系数×效率系数。

    (5)对于管理者(各部门经理)，其利的分配首先取决于本部门完成的总任务量和质量、效率，然后用部门人力资源超出定额的比例加以修正——部门人数超定额越多，部门经理所得绩效薪酬越少。

    (6)对于不同部门、不同岗位，责权利的分配应形成部门之间、岗位之间既相互依存、相互促进，又相互监督、相互制约的关系。

2.4 激励与制约机制

    按照上述原则进行的责权利分配结果，一方面对于每一个部门和每一个岗位体现出来的是一种激励——对于管理者而言，受到的激励是尽力实现或超额完成本部门的任务目标，同时尽量降低人力资源成本，因为他们的收益就是由任务完成情况和资源耗费情况共同决定的，对于其他各岗位人员，受到的激励是尽量多承担任务，同时又必须保证质量和进度，因为，他们的收益就是由实际完成的任务数量和质量、效率共同决定的。另一方面，对于不同部门，不同岗位之间体现出来的是既相互依存又相互制约的关系。

    总而言之，以任务为核心的责权利分配形式，可以开创出“以激励机制来促使管理体系自觉运行，以制约机制来控制体系合理运行”的良性运作局面，既节省资源又能顺利实现组织的预期目标。当然，这种管理体制在具体实施的细节上涉及到相关技术问题和各岗位人员的能力问题，如对开发任务量的合理估算、对产品质量的定量评价技术，等等。这些问题不在本文探讨范围之内，故予以省略。

3 IT项目实施基本过程示例

    本章以一个假设的示例，简要说明在上述IT研发项目管理体制下一个具体项目的实施过程，并说明如何避免IT项目管理中两大普遍性问题的发生。

    假设情景：A公司以某行业的信息系统开发为主业，已经建立了上文所描述的IT研发项目管理体制，且处于正常运行状态。目前，第n个项目的需求开发即将结束，同时又参加了一个大型软件工程项目的投标并得中(即图2所示的产品策划活动已完成)，用户在合同中提出了简要的业务需求和整体进度要求。

    下面就这个中标项目，从图2所示的“项目规划”活动开始、到模块开发任务得到落实为止，简要说明项目实施过程中各项活动的基本操作方法，以及为避免上述两大问题的发生而采取的策略和措施。

    (1)项目规划活动：根据该工程项目的研发任务量、产品的质量／进度要求和目前正在开发的第n个项目的进展情况，对新的研发任务进行分解和重新组合——把需求相对明确和稳定的内容作为先行项目(第n+1个项目)，而把需求尚未明确或易发生变化的内容作为后行项目(第n+2个项目)。即一边开发着需求明确的内容，一边等待另一部分内容变得需求明确、稳定。这是项目管理过程中最早采取的避免需求变化影响的策略。另外，所划分的每个项目的规模及起止时间，要根据当前项目的进展情况和资源条件而定，确保开发资源在任何阶段既无冲突发生又无闲置现象。

    (2)项目立项活动：对上一步规划出来的两个项目分别进行深入策划，即对每一个项目从需求分析到模块开发过程的各项活动提出时间限制、质量要求及验收准则，最终形成指导实施的项目任务书。对于第n+1个项目，因其需求较明确，故规定其需求开发时间较短；而第n+2个项目的需求需要随着时间的推移、与用户的不断沟通而逐渐明确，因此规定其需求开发时间较长，且在需求基本确定后，还要求进一步跟踪其可能的变化。这是项目管理过程中所采取的避免需求变化影响的又一策略。

    (3)项目需求开发：通过调查、讨论、用户沟通和深入分析等过程来确定本项目的需求，并制订需求变化应对方案。对开发部，需求文档必须明示每一项需求的明确程度和稳定性，以便他们在设计上和模块任务规划上采取应对需求变化的具体措施；对用户方，一方面必须充分沟通达成一致，另一方面必须跟踪需求的变化并加以控制，使这种变化限定在尽可能小的范围之内。

    (4)项目系统设计：根据需求构建系统整体结构、划分功能模块并规定每个模块的功能／性能指标，同时说明在灵活性(需求变化的应对，可扩充、易升级等)方面的解决方案。系统设计须充分考虑需求及各种条件限制，使系统在充分满足业务需求、能够应对主要需求变化的同时，达到“最小化”，以减少开发工作量、降低开发成本。

    (5)模块任务规划：根据项目需求和系统设计的内容及要求，同时根据当前项目的进展及资源占用情况，将开发任务进一步细化为有明确质量和开发进度要求的模块，并将这些模块在项目进度所限定的时间轴上排列——根据各模块需求的稳定性，对其他模块的影响以及开发人员的时间安排进行综合权衡之后，来决定模块任务的时间分布。将需求不稳定的模块尽量排在后面，待其需求稳定后再开发，使需求变化的影响降到最低。

    (6)模块任务分配：对上一步规划出来的每一个模块进行详细策划——将需求和设计要求体现到每个模块中，提出明确的时间限制、质量要求及验收准则，最终形成可以落实到人的开发任务。另外，在任务分配时进行“双向选择”，有能力的开发人员可以同时承担多个模块的开发任务。

    上述各个环节所采取的策略与措施，可以把项目研发过程控制在一个理想状态，即利用现有资源便能实现预期目标，项目研发活动逐层逐步按计划实施。这就是以任务为核心的IT研发项目管理体制所能产生的实际效果。

4 结语

    综上所述，IT项目管理中普遍存在着两大问题，归根结底是组织层面的管理体制及运作机制问题。按照“以任务为核心”的原则、遵循IT项目的客观规律而构建起来的IT研发项目管理体制，便可以从根本上解决达两大问题，使一个组织能够以较少的资源成本消耗来实现其预定的研发目标，这正是项目管理的宗旨。