软件研发中的精细化人力资源管理模型及系统

李 引，刘东成，袁 峰，魏 革，阳 昕

1.广州中国科学院 软件应用技术研究所，广州 511458 2.广东金赋信息科技有限公司，广东 佛山 528200

◎工程与应用◎

软件研发中的精细化人力资源管理模型及系统

李 引1，刘东成1，袁 峰1，魏 革2，阳 昕1

1.广州中国科学院 软件应用技术研究所，广州 511458 2.广东金赋信息科技有限公司，广东 佛山 528200

软件项目研发的成功与否，人力资源的管理起着决定性作用。从实践项目中提出了精细化人力资源管理的模型，将人力资源、软件项目、任务等抽象成具有状态、属性和操作的实体，通过定义任务效率、效率奇点等指标，综合SPI、CPI指标进行项目成本进度偏差分析，为人力资源的计划、调度、冲突处理等提供支撑。基于该模型进行平台研发，并通过在该平台中跟踪和分析真实的精细化人力资源管理案例，验证了模型的有效性。

精细化；项目管理；人力资源管理

1 引言

针对软件过程、软件项目管理，国际上提出了PACE（Product And Cycle-time Excellence）[1]、ISO9000 质量管理体系[2]、CMM/CMMI[3-5]、项目管理知识体系（PMBOK）[6]、敏捷开发（Scrum[7-8]等）、RUP[9]等一系列的管理模型和体系，它们从不同的角度对项目管理的过程、产出、角色等要素进行了建模，具有各自的适用性。软件研发是复杂的智力活动，人力资源的安排、使用与管理将对项目的成败起着决定性的作用。在对上述模型体系分析研究的基础上，针对人力资源的管理，研究了如何对人力资源进行精细化管理的问题。精细化管理的核心在于通过对数据的分析，找出问题所在，并制定详细可行的控制措施。随着信息化技术的发展，人力资源管理软件逐渐被广泛采用，也为精细化管理提供了可能。精细化人力资源管理是一个全面化的管理模式，是一个与项目管理紧密相关的应用领域[10-12]。

基于以上分析，研究的问题主要包括：（1）对精细化人力资源管理领域建模。为了实现精细化人力资源管理，对人力资源也进行了建模。人力资源作为对象，拥有资源计划、工作时间等重要属性，与项目管理紧密相连，并通过报工日志形成项目管理与人力资源管理的闭环。（2）如何统计与分析模型产生的数据。对于精细化人力资源管理模型中产生的大量基础数据，如何进行收集和有效的数据分析，从而对项目管理起到评估和监控作用，对此进行了研究和分析。（3）如何将模型更好地服务于面向对象的需求分析过程。对于当前面向对象的需求分析结果难以复用的问题，对此进行了讨论，并提出了一种需求分析方法。

第2章对业务逻辑进行了分析，对人力管理领域进行建模，引入度量指标对模型中产生的基础数据进行分析。基于该模型，在第3章介绍了系统的实现。在第4章说明了真实项目如何运用模型进行管理和调整，并起到监控效果。最后进行总结。

2 精细化人力资源管理模型

2.1 业务逻辑分析

采用领域驱动设计的方式，对软件研发中的各个活动、过程、产出等进行分析建模[13]，以人力资源管理为中心的软件研发过程涉及的业务逻辑如图1所示。

立项时需指定项目负责人，设定项目目标、项目周期等关键要素，项目负责人对该项目具有最大权限，可查看所有项目成员的报工日志，查看项目进度，对项目进行资源分配，创建及变更计划等操作。立项完成后，该项目进入项目列表中，处于已启动状态。

处于已启动状态的项目，项目负责人可以对其进行项目计划。由于实际工程的需要，项目负责人可以为一个项目创建多个（草拟）项目计划。这些项目计划在正式发布前，均处于草稿状态，项目负责人可以据此与团队成员进行沟通。最终，项目负责人将发布一个正式的项目计划，即每个项目只能有一个生效的项目计划。

项目负责人可以对已生效的项目计划进行任务拆分。任务拆分遵循WBS规则，即以最小可交付成果为原则进行拆分。底层任务即工作包，并通过底层任务将项目管理与资源管理有效衔接。

底层任务由于是以可交付成果为单位，因此底层任务与资源并非一一对应。项目负责人需将底层任务再拆分到每一个资源，即拆分成与资源一一对应的简单任务，并指派到该资源。简单任务并不是项目管理宏观监控的关注点，却是项目进度、成本、资源使用情况等的基础数据来源。

项目进行时，项目成员通过查看自己每天的简单任务列表，对自己当天的工作进行安排，并需要填写报工（每个简单任务的投入时间、进度、完成情况等），从而形成项目“计划——执行——监控”的PDCA[14]闭环控制。报工日志中的数据将汇总到项目管理和资源管理中，对项目总体进度以及资源使用情况产生影响。

项目立项完成后，项目负责人可对该项目进行资源分配。资源分配依次需经过创建资源计划、资源冲突检测及确认三个步骤。创建资源计划是以项目为单位，申请将某资源在某段时间内。资源计划创建完成后，系统将自动进行资源冲突检测，将该资源在计划时间段内是否发生冲突以及工作饱和度返回给项目负责人，若发生冲突，则项目负责人必须对资源计划进行修改。确认后，则该资源将在计划时间段内属于该项目的资源池中，项目负责人进行任务拆分和指派时，可从项目的资源池中进行分配。

当项目的所有任务都已完成时，项目负责人可发起结项申请。项目联系人或客户根据立项时设定的项目目标，对项目成果进行验收。验收通过后，该项目完成结项，项目管理阶段到此结束，所有资源将被释放，项目信息不得再进行修改。

2.2 项目管理领域建模

项目是模型的管理单位，项目概念的建立从项目立项开始。项目应当包含项目计划、项目周期、项目成本等基本要素，此外还包含项目描述信息、项目状态及监控参数。

定义1 项目（Project）

Project=〈{projectStates}，{name，info，plan，planned-TimeCycle，cost，monitoringParameters}，{InitProject，New-Plan，DisHumanResource，CloseProject}＞。其中，项目状态projectStates，在定义2项目状态（ProjectStates）中进行说明。

name：项目名称，可唯一标识项目。

info：项目基本信息，包括项目描述、项目目标、项目总监、项目经理等必要的说明。

图 1 业务逻辑图

plan：定义 4中的项目计划，每个项目可包含多个计划，但只有一个生效计划。

plannedTimeCycle：计划项目周期，该时间不会随着项目计划的变更而改变。

cost：当前已花费的项目成本，包括人力成本及其他费用。

monitoringParameters：项目监控参数。挣值分析是测量工作绩效的常用分析方法，进度执行指数（SPI）和成本执行指数（CPI）是用来监控项目成本和进度的有效方法。除了用来反映项目状态，更是通过状态的分析来做出相应的应对措施来解决实际问题，从而使CPI和SPI的数据趋于正常。在本模型中，引入CPI及SPI作为项目监控的参数，具体内容在定义21项目监控参数中进行说明。

定义2项目状态（ProjectStates）

ProjectStates=（INITIALIZED，RUNNING，PAUSE，CLOSING，CLOSED）。

分别为已启动、进行中、暂停、结项中、已结项，转换关系如图2所示。

已启动：项目立项之后，项目状态变为已启动，本模型对项目的管理从已启动的项目开始。

进行中：当项目计划生效之后，项目变为进行状态，在进行状态的项目可以进行报工、资源申请与分配等操作。

暂停：当遇到某些情况，需要将项目暂停时，可将项目设置为暂停状态。暂停状态下，成本不再增加，但计划不顺延。即项目暂停不影响成本，但影响进度。

结项中：项目中所有任务均完成的时候，可以提交结项申请。

已结项：结项申请确认通过时，项目变为已结项状态，对该项目的管理到此结束。

项目管理从立项操作开始。下面对项目立项操作进行定义。

定义3项目立项（InitProject）

InitProject=〈{project}，{NULL}，{project.states=INITIALIZED}＞。立项之后，才建立项目的概念，才能对其进行后续操作。立项操作完成后，项目状态变为已启动，可以对项目制定项目计划、分配资源等。立项时需要确定项目的一些关键信息。下面对项目计划对象进行定义。

定义4项目计划（Plan）

一个项目有许多的项目计划活动，每个计划活动都有着计划名称、计划版本、计划时间周期，以及一系列的任务集合。任务集合是每个计划活动进一步细化的成果。每个任务都包含有任务名，任务时间周期，人力资源集合，计划工作量，实际工作量，已投入工作量。其中已投入工作量是指任务中每个人力资源的已投入工作量与任务已开始时间的乘积的和。

Plan=〈{isEffect}，{name，type，version，cycle，task-Set}，{NewPlan，ModPlan}＞。

状态isEffect=（TRUE，FALSE），计划生效时isEffect=TRUE，反之则为FALSE。

name：项目计划的名称。

type：项目计划表的类型，如 type=（Gant，Burn-DownChart），甘特图或燃尽图。

version：项目计划的版本号。

cycle：当前计划项目周期，调整计划时，该时间可能会发生改变。

对项目计划的主要操作有制定项目计划以及调整项目计划。制定项目计划一般在项目立项之后，而调整项目计划往往发生在正在进行的项目中。下面对这两个操作进行定义。

定义5制定项目计划（NewPlan）

NewPlan=〈{project，plan}，{project.states=INITIALIZED}，{plan.isEffect=TRUE，project.states=RUNNING}＞。只能对已初始化的项目制定项目计划，每个项目可包含多个项目计划，但只能有一个生效计划。计划生效之后，才能进行细化。此阶段不涉及资源的分配，与资源的关联将在对计划的细化中进行。项目进行中，可以对生效计划进行调整。

定义6调整项目计划（ModPlan）

图2 项目状态转换图

ModPlan=〈{oldPlan，newPlan}，{oldPlan.isEffect=TRUE}，{oldPlan.isEffect=FALSE，newPlan.isEffect=TRUE}＞。此操作指的是在在项目进行中对已生效的计划进行调整，因此前置条件为oldPlan.isEffect=TRUE。操作完成后，旧计划失效，新计划生效。

本模型采用工作分解结构（Work Breakdown Structure，WBS），以可交付成果为导向对项目要素进行分组。WBS最低层次的项目可交付成果称为工作包，对应模型中的任务。每个任务可以有多个项目成员参与执行。因此需要对任务对象进行建模，定义如下。

定义7任务（Task）

Task=〈{isFinished}，{name，fatherTask，belongToPlan，plannedTimeCycle，actualTimeCycle，humanResourceSet，plannedWorkload，acturalWorkload，simpleTaskSet}，{NULL}＞。

其中，状态isFinished={TRUE，FALSE}任务是否完成，完成时isFinished=TRUE，此时该任务下的所有简单任务均已完成，且不得再进行报工，未完成时isFinished=FALSE。

name：任务名，可以对任务进行唯一标识。

fatherTask：父任务。

belongToPlan：所属项目计划。

plannedTimeCycle：任务计划周期。

actualTimeCycle：任务实际执行周期。

humanResourceSet：表示一切参与到该任务的人力资源的集合，也就是定义6中的人力资源。

plannedWorkload：任务计划工作量。

actualWorkload：任务实际工作量。

simpleTaskSet：简单任务（定义8）集合，simpleTask-，其中n表示该项目任务中简单任务的数量。

由于任务是以可交付成果为导向，一个任务可对应多个资源，无法收集单个资源在单个任务中的执行情况，于是引入简单任务概念。表示为：

定义8简单任务（SimpleTask）

SimpleTask=〈{NULL}，{belongToTask，plannedWorkload，acturalWorkload，humanResource}，{DisHumanResource，Report}＞。

belongToTask：所属任务，一个简单任务只能所属一个任务。

plannedWorkload：简单任务的计划工作量。

actualWorkload：简单任务的实际工作量。

humanResource：简单任务对应的资源，定义16中定义的资源。

简单任务不可再分，不可独立于所属任务存在，每个简单任务对应一个资源。任务、简单任务、资源的关系如图3所示。与简单任务相关的操作有报工（定义11）及资源分配（定义18）。

图3 简单任务示意图

项目运行情况的收集是通过资源填写报工日志完成。资源根据简单任务列表提交当日的报工日志，将各简单任务的完成情况汇总成任务完成情况，从而对项目的整体进度产生影响。项目负责人可以查看项目进度与计划，并对项目计划作出调整。下面对报工日志以及报工操作进行定义：

定义9报工日志（WorkLog）

WorkLog=〈{EFFECT，DRAFT}，{humanResource，simpleTask，workload，accomplishRate}，{NewWorkLog，Report}＞。

humanResource：定义16中的人力资源。

simpleTask：定义8中的简单任务。

workLoad：当天工作量。

accomplishRate：任务完成度。

定义10 报工（Report）

Report=〈{workLog，simpleTask}，{simpleTask.human-Resource=worklog.humanResource}，{worklog.states=EFFECT}＞。

其中，前置条件为报工日志中的资源与简单任务中的资源对应。报工日志提交后，对应的简单任务的实际工作量将更新为加上本次日志中工作量的总和。报工是模型中的重要操作，将计划与实际有效联系起来。资源根据计划（定义4）中的简单任务（定义8），填写实际工作量以及任务完成情况，收集该数据可进行任务完成情况、项目运行情况、资源效率等分析。完成报工操作后，该报工日志生效，即状态变为EFFECT。

项目计划中所有任务均完成后，可提交结项报告（对象），进行项目结项操作。每个项目只允许提交一份结项报告。

定义11结项报告（ProjectCloseReport）

ProjectCloseReport=〈{PENDING，EFFECT，FAIL}，{projectName，plannedTimeCycle，actualTimeCycle，acceptanceList，qualityEvalution}，{CloseProject}＞。

提交结项报告后，该报告正在处理中，Project-CloseReport.states=PENDING；报告生效后，Project-CloseReport.states=EFFECT；结项不通过，则Project-CloseReport.states=FAIL。当且仅当一个项目的结项报告处于FAIL状态时，可重新提交一份结项报告。

projectName：项目名称。

plannedTimeCycle：计划项目周期，对应定义 1项目中的值。

actualTimeCycle：项目实际运行周期。

acceptanceList：验收清单。

qualityEvaluaion：质量评价。

定义12项目结项（CloseProject）

CloseProject=〈{project，ProjectCloseReport}，{∀i∈（1，n），taski.isFished=TRUE，n为项目中任务总数}，{NewCloseReport，ConfirmClose}，{ProjectCloseReport.states=EFFECTamp;project.states=CLOSED or ProjectCloseReport.states=FAILamp;project.states=CLOSING}＞。项目结项为复杂操作，包括新建结项报告和确认结项两个基本操作，具体定义如下：

定义13新建结项报告（NewCloseReport）

NewCloseReport=〈{project，ProjectCloseReport}，{∀i∈（1，n），taski.isFished=TRUE，n为项目中任务总数}，{ProjectCloseReport.states=PENDING，project.states=CLOSING}＞。仅当项目中所有任务的状态均为已完成（taski.isFished=TURE），项目才能提交结项报告。

定义14确认结项（ConfirmClose）

ConfirmClose=〈{project，ProjectCloseReport}，{Project-CloseReport.states=PENDING，project.states=CLOSING}，{ProjectCloseReport.states=EFFECTamp;project.states=CLOSED or ProjectCloseReport.states=FAILamp;project.states=CLOSING}＞。

提交结项报告后，报告的状态变为PENDING，项目状态变为CLOSING。此时由决策者根据报告中的内容进行评价，最终对是否结项进行确认。确认结项后，结项报告生效，ProjectCloseReport.states=EFFECT，且项目状态变为CLOSED。若决策者认为该结项报告不符合要求，不予结项，则将报告状态置为FAIL，项目处于CLOSING状态，此时可为该项目重新创建一份结项报告。处于已结项状态的项目，不能再进行计划变更或报工等操作。项目结项后，对该项目的管理工作全部完成。

2.3 人力资源管理领域建模

人力资源是复杂的，它包含有一系列的专业知识和技能属性，以及与它有所关联的其他资源属性。它包含有一系列的属性，实际上，在项目管理过程中，项目是多变的，人力资源本身也是多变的。人的专业知识和行为能力与他所具备的项目管理经验，参与项目实践时间，学习能力都是相关的。一个参与过类似项目，参与此次项目时间长久，学习效率高的人会更为高效地完成项目规定计划。这种行为活动是一种自学习，自适应的项目计划活动。人力资源是一种瞬时资源，在项目计划阶段做好的资源计划赶不上资源变化，人力资源在项目活动中实际执行的行为时间是不确定的。因为随时可能由于计划变更，需求变更或者有优先级别更高的项目进入影响到当前项目计划，此时资源可采取满负荷加班方式完成额外的项目需求，也可以通过采取与企业管理层协商决定先投入哪个项目达成共识的方式来完成自身的计划进度安排。

针对人力资源的复杂性、多变性、不确定性，把人作为项目过程管理中的基本元素进行资源定义。

定义15人力资源（HumanResource）

HumanResource=〈{NULL}，{name，planSet，availible-Time，scheduledTime，skillSet，workingTime，fullTime，efficiency}，{DisHumanResource，Report}＞

name：人力资源的名称，可唯一标识人力资源。

planSet：定义16中的资源计划的集合，一个资源可包含多个资源计划。

availibleTime：人力资源的可用时间。

scheduledTime：人力资源的已安排时间。

skillSet：人力资源的技能集合，其中每个技能Skill被定义为一个三元组〈SkillName，SkillType，SkillLevel＞，每个人力资源所拥有的技能是所有他所拥有的技能名称、技能类型以及掌握程度的集合。

workingTime：人力资源的已工作时间。

fullTime：资源每天的满荷工作时间，可按不同需要进行设定，一般fullTime=8.0 h。

efficiency：资源效率，资源投入的所有任务的任务完成效率平均值，计算公式：

定义16资源计划（HumanResourcePlan）

资源计划是一个资源在某段时间内的工作安排情况，表示该资源在某时间段内对某项目的参与度。一个资源可包含多个资源计划。

HumanResourcePlan=〈{PENDING，EFFECT，FAIL}，{timeSpam，projectName，participation}，{DisHumanResource}＞。

提交资源申请后，相应的资源计划的状态变为PENDING；成功分配后，状态变为EFFECT；申请失败，则状态为FAIL。

timeSpam：该资源计划的时间段。

projectName：所参与的项目。

participation：参与度，含义为资源投入该项目的工作量，占自身所有工作量的比例，用百分比表示。

例如，资源小王2015年1月1日至2月1日参与项目A，参与度为70%，此为资源计划1。同时，小王2015年1月5日至2月15日参与项目B，参与度为40%，此为资源计划2。

定义17资源分配（DisHumanResource）

资源分配操作指的是为某项目创建一系列资源计划，并确认是否生效的过程。操作序列为复杂操作，包括创建资源计划（定义18）、资源冲突检测（定义19）以及确认操作（定义20）。定义如下：

DisHumanResource=〈{project，humanResource，humanResourcePlan}，{project.states=Initiated or project.states=RUNNING}，{NewHumanResourcePlan，Detect-Conflict，ConfirmDis}，{humanResourcePlan.states=EFFECT or humanResourcePlan.states=FAIL}＞。

定义18创建资源计划（NewHumanResourcePlan）

NewHumanResourcePlan=〈{project，humanResource，humanResourcePlan}，{project.states=Initiated or project.states=RUNNING}，{humanResourcePlan.states=PENDING}＞

定义19资源冲突检测（DetectConflict）

先定义几个术语：

资源饱和率（saturationRate）：资源分配时在某时间段内其资源占用率的大小。它描述了资源的冲突强度。正常使用资源的饱和率上限，成为饱和率阀值（saturationThreshold），可根据需要设定。

资源冲突（confliction）：资源在某个时间段内，其资源饱和率超过阀值，则称该资源在该时间段内发生了资源冲突。

DetectConflict=〈{humanResource，humanResourcePlan}，{humanResource Plan.states=PENDING}，{isConflict=TRUE or isConflict=FALSE，saturationRate=rate}＞。资源冲突检测的前置条件是提交了资源计划申请，即humanResourcePlan.states=PENDING。计算饱和率的方法为将资源计划中的资源使用时间，加上资源当前的已安排时间，即计算假设该资源按照此资源计划进行工作的饱和率。资源冲突检测的结果为是否发生冲突，及该资源的饱和率。该结果将影响操作者的决策。

定义20确认分配（ConfirmDis）

ConfirmDis=〈{project，humanResource，humanResourcePlan}，{isConflict=TRUE or isConflict=FALSE，saturationRate=rate}，{humanResourcePlan.states=EFFECT or humanResourcePlan.states=FAIL}＞

资源冲突检测的结果为是否发生冲突，及该资源的饱和率。模型本身并不进行决策，需要操作者进行结果确认，即Confirm。操作的结果可以是该资源计划生效（humanResourcePlan.states=EFFECT）或放弃该资源计划（humanResourcePlan.states=FAIL）。

2.4 度量指标建模

针对项目执行进度和成本，一般采用经典的CPI和SPI进行，如下定义。

定义21项目监控参数

用二元组〈parameter，value＞表示，MonitoringParameters={〈paragrameter1，value1＞，〈paragrameter2，value2＞}。

parameter：参数类型，在本模型中采用SPI和CPI。

value：参数范围，value={H，N，L}，H为运行良好下限，N为运行正常下限，L为轻微偏差下限。监控参数值value≥H时，运行良好；H＞value≥N时，运行正常；N＞value≥L时，轻微偏差；value＜L时，严重偏差。

计算公式：

其中，PV为在规定的时间内在工作上将要花费的获得批准的成本估算部分，AC为在规定时间内完成工作所花费的实际成本，EV为实际完成工作的价值。项目中所有任务的指数平均值为项目指数。

由任务（定义7任务（Task））及简单任务（定义8简单任务（SimpleTask）的定义可知，项目管理模型中一份项目计划包含有多个任务，每个任务又可以分配多个人力资源，任务与人力资源是一对多的关系，而简单任务是不可再分的任务，每个简单任务对应一个人力资源。人力资源与项目之间的衔接可以通过报工日志，项目变更，资源申请，资源分配等方式。其中在报工日志中，人力资源通过简单任务与项目计划进行交互。简单任务执行效率只表示该资源在该任务中的执行情况，但是统计某个资源的所有简单任务的完成效率，可反映该资源的执行效率。因此，在这里引入两个统计量：

定义22简单任务完成效率（TaskEfficiency）

其中p为任务完成度，用百分比表示。以每人每任务为计算单位，表示该资源在该任务上的完成效率。PVt为简单任务的计划完成时间，ACt为简单任务的实际工作时间。当实际完成效率与计划预期一致时，TaskEfficiency=1；当实际完成效率低于预期时，TaskEfficiency＜1；反之，TaskEfficiency＞1。

例如，某简单任务的计划完成时间是10 h（PVt=10 h），当前已工作5 h（ ACt=5 h），当前该简单任务的完成度为40%，则

说明该简单任务的完成效率低于预期。

该值与进度成本指数SPI、CPI的计算方法类似，与之不同的是，没有将资源成本计入公式，仅计算任务完成度与预期的关系，直观地反映了该资源在该简单任务上的完成效率，或者该任务工时预估的准确度。

定义23效率奇点（SingularPoint）

当TaskEfficiency＞H或TaskEfficiency＜L时，该简单任务称为效率奇点简单任务（SingularPoint）。L、H为正常值的上下限，根据经验数据计算得出。一般的，L=0.9，H=1.2。

项目的SPI、CPI出现偏差时，可参照对项目奇点率的统计进行分析，若奇点率高，则说明很多任务都出现了进度偏差，考虑是计划问题；若奇点率低，说明出现偏差的任务少，但偏差严重，则考虑是资源执行力的问题。人力资源的变动有可能造成项目计划的变动，同时，项目计划的改动也会造成人力资源的变更。通过采用这种模型机制，能够将项目过程中的每个阶段精确到每个人力资源的控制中去，生成可信可用的调度计划，及时反应人力资源的最新状态，项目的最新执行进度等。

该精细化人力资源管理模型适用于传统开发模式以及迭代开发模式。资源在每个项目任务中的报工都会及时反馈到资源的基础数据以及项目进度中，项目计划与进度的展现方式可根据不同的开发模式选择为甘特图或燃尽图。对于传统开发模式，项目立项后进行项目计划、分配资源，在项目进行中，通过成本分析、进度分析以及资源效率分析，对项目计划进行调整。对于迭代开发模式，项目启动后，每个迭代周期进行项目计划、分配资源、项目监控过程，通过模型对参数的统计与分析，指导下一迭代周期的计划与资源分配。

对项目进行监控时，需要结合项目监控参数CPI和SPI，以及任务奇点率进行分析。由于大于或小于正常效率范围的点均为效率奇点任务，所以任务奇点率高有两种情况，即简单任务完成效率偏低或偏高。

下面分别对这四种情况进行分析：

（1）若项目监控参数（CPI、SPI）指数较高，任务奇点率较高，说明项目计划安排不合理。若项目中的简单任务完成效率普遍高出正常值，则说明任务的工作量估计不准确，导致资源普遍过于超前完成任务；若项目中的简单任务完成效率普遍偏低，则说明资源的分配不合理，即挣得值大的任务完成情况良好，而挣得值小的任务进度延后。

（2）若项目监控参数（CPI、SPI）指数较低，任务奇点率较高，说明项目计划安排不合理。若项目中的简单任务完成效率普遍高出正常值，则说明任务拆分不合理，导致挣得值大的任务进度延后，或资源出现问题（工作效率低于正常值）；若项目中的简单任务完成效率普遍偏低，则说明任务拆分不合理，对任务的工作量估计不准确，资源普遍无法按计划完成任务。

（3）若项目监控参数（CPI、SPI）指数较高，任务奇点率较低，说明项目运行状态正常。

（4）若项目监控参数（CPI、SPI）指数较低，任务奇点率较低，说明资源普遍按计划完成任务进度，但项目的挣得值和成本投入均过小，说明计划安排不合理。

3 系统实现

本文提出的模型在广州中国科学院软件应用技术研究所的在线研发管理平台iSERP（intelligent Service of ERP）[15]中进行了开发和实现。iSERP是一款面向智力服务行业的企业的项目精细化管理系统。它能够为软件、广告、律师、金融等以人力资源智力活动为主要生产力的企业提供精细化的管理服务，能够对项目每天的进展和人力资源分布进行监控，为高层提供清晰明了的资源和项目视图。

3.1 总体功能架构

由于系统功能众多，采用功能结构图的方式将系统的功能进行分解，体现各个模块间的层次关系和逻辑结构。系统包括我的工作台、资源管理、项目管理、报工管理和系统管理五大模块，如图4所示。

图4 总体功能架构图

其中，项目资源成本分析、项目阶段成本统计、项目资源使用情况分析等数据分析，均是由项目计划及报工产生的基础数据，根据不同企业的需求进行的统计与分析。

3.2 资源管理业务流程

资源管理模块是项目管理平台中的基础模块之一，该模块为其他管理提供资源基础数据的来源。该模块的主要参与者有普通员工、项目负责人及部门负责人。在系统中主要实现了资源基础数据、资源申请、资源分配功能，如图5所示。

图5 资源管理流程

（1）资源基础属性。对资源的基础数据进行维护（请参见第3章中定义15），包括自然基础数据（如名称、技能等），以及扩展基础数据（如资源计划、可用时间、已工作时间等）。

（2）资源申请。由项目负责人发起资源申请（即创建资源计划），申请表单中需指定项目、资源、时段、参与度，表示为某个资源在某时间段内以一定参与度投入到某项目中。由部门负责人对资源申请进行审批。

（3）资源分配。由部门负责人对部门内项目的资源申请进行审批。项目负责人发起资源申请后，系统将进行资源冲突检测。当发生了资源冲突，或资源冲突程度大于系统设定值时，将提醒部门负责人，部门负责人可以视情况驳回申请，再由项目负责人重新申请。当资源申请审批通过时，系统将自动更新资源的信息。

（4）资源变更。在项目进行中，项目负责人可以随时为项目创建新的项目计划，或修改已生效的资源计划（即资源变更）。发起资源变更时，与资源申请类似，同样需要部门负责人的审批。

3.3 实体关系

系统实体关系如图6所示。项目可拆分成多个任务，每个任务可再划分为多个简单任务，简单任务不能独立于任务存在。简单任务与人力资源一一对应，且每天对应一条报工日志。项目与人力资源为多对多关系，一个项目包含多个人力资源，人力资源可同时属于多个项目。

图6 实体关系图

3.4 资源管理模块详细设计

由前文分析可知，资源属性本身是由自然属性和扩展属性复合而成，其扩展属性如工作属性、技能水平等可作为一个单独的类。资源属性与工作属性、技能水平之间为1..n关系，其类图如图7。

图7 资源基础数据类图

资源分配操作包括创建资源计划、资源冲突检测以及确认操作，图8为资源冲突检测时序图。该操作的输入信息为资源计划，即在某个时间段将某资源加入某项目中，提交资源计划时将处罚资源冲突检测。最终返回该资源在计划时段内是否发生冲突以及饱和率。

图8 资源冲突检测时序图

4 实例分析

下面以真实项目“桌面即时通讯工具”项目为例，对其业务场景和数据进行分析。

4.1 项目立项

桌面即时通讯工具项目的项目周期为2015年5月1日至2016年1月31日，工作量387人天，项目计划时分配的初始团队成员如表1。

表1 团队成员表

图9 资源申请

图10 资源冲突检测

4.2 分配资源与资源变更

项目启动后，可在创建项目计划时由项目负责人申请资源（为某项目在某段时间内申请某资源），也可先进行资源申请，即资源申请与创建项目计划没有依赖关系。在桌面即时通讯工具项目中，项目负责人采用的是先制定顶层项目计划，同时确定顶层任务的负责人，并为顶层任务申请资源。对于底层任务，则由所属顶层任务的负责人，在任务开始前进行资源申请。资源申请的界面如图9。

项目负责人发起资源申请后，系统当即会进行资源冲突分析，根据系统预先设置的阈值（日工作量标准为8 h，饱和度上限为110%），当此资源申请将使资源的工作量超出阈值时，即发生资源冲突，系统将给出提示。

2015年8月10日，由于发生需求变更，需要增加开发人员，于是项目经理发起了资源变更，希望将资源王一龙加入本项目。由于王一龙同时参与了其他项目，且工作量已经饱和，于是系统进行了如图10提示。

系统提示在2015年8月10日至2015年12月31日之间，王一龙发生了资源冲突，冲突率为55.4%（冲突时间/申请时间）。于是项目经理对资源申请进行了调整，将其他可用资源添加到了项目中，保证了项目正常进行。

系统将资源冲突设置为必要条件，即所有资源申请必须通过资源冲突的检测，才能通过，从而进入审批流程。否则，项目负责人必须对申请进行修改。发生冲突时，项目负责人可在所有资源列表中查看各资源的技能、可使用时间等。这种设定，保证了资源使用的合理性，实现资源使用情况的可视化。

4.3 报工与项目监控

在项目计划完成拆解，并将资源分配到简单任务之后，对应的资源就可以在自己的报工日志的任务列表中查看自己的任务列表，并安排当天的工作，任务列表如图11所示。

图11 任务列表

任务列表中列出了当天该资源参与的所有简单任务（可能分属于不同项目中），是从资源角度对简单任务的汇总。每一项简单任务，列出了其名称、所属项目/部门、任务类型、工时（总工作量）、剩余工作量（根据此前个人填写的报工计算得出）、计划完成时间、任务执行情况（百分比）等，资源需根据今天工作的实际情况填写各项任务的投入时间和完成情况。

提交后，项目负责人可查看所有成员的报工日志，且成员填写的报工日志将及时反映在整个项目的进度中，为项目负责人细致了解项目情况提供了基础数据。

项目进行过程中，出现CPI=0.78，SPI=0.71，依据系统中设置的值，该项目处于严重偏差状态。此时，项目中所有简单任务的完成情况如表2（未列出暂时未到计划开始时间的任务）。

其中根据公式（4）以及前文中对效率奇点（定义26）的定义，任务效率正常值为[0.9，1.2]，因此1、6、7、9四个简单任务效率低于正常值下限0.9，为效率奇点任务。对这四个效率奇点任务进行分析，见表3。其中，资源效率为该资源所负责的所有简单任务完成效率的平均值，与项目无关，反映的是该资源的工作效率。用公式（1）计算，并参见第3章中定义15。

表2 简单任务效率表

表3 奇点任务表

可见资源本身的效率属于正常范围。通过与奇点任务的负责人沟通，由于开发过程中出现了计划时未考虑到的技术难点，导致该简单任务的完成效率较低，并重新给出了该简单任务完成所需工时的预算。为了保证后续计划的准确性，项目经理及时对整体计划进行了调整。

4.4 项目结项

当项目计划中的所有任务都完成时（即完成度为100%），项目负责人填写结项报告，提交后进入结项过程。

在本项目中，由于当前项目计划的完成度为92.21%，所以无法提交项目结项报告。

成功提交结项报告，进入结项过程后，则需要由客户对项目成果进行验收，系统自动核算实际工作量，为项目验收提供参考数据。项目验收通过后，即完成项目结项过程，该项目的管理活动告一段落，系统将自动释放所有资源。

5 结束语

本文提出了精细化人力资源管理模型。该模型将人力资源单独作为对象，纳入到项目管理的领域范围内，而不是从属于项目中的一部分。作为对象的人力资源，拥有资源计划、可用工作时间、工作量等一系列属性，在实际应用中，可根据具体的管理需求灵活地对这些基础数据进行加工利用。项目计划与资源之间，通过资源计划联系起来。首先制定整体项目计划，再将计划拆分为与资源一一对应的简单任务，由此，计划被拆分并指派到了单个资源。而资源则通过每天的报工，对指派给其的任务完成情况进行反馈，从而形成了项目计划、报工、项目进度反馈等PDCA闭环控制。

[1]PRTM.PACE[EB/OL].[2016].http：//acronyms.thefreedictionary.com/Product+and+Cycle-Time+Excellence.

[2]质量管理体系技术委员会TC176.ISO9000[EB/OL].（1994）[2016].http：//www.iso.org/iso/home/standards/managementstandards/iso_9000.htm.

[3]Software Engineering Institute.CMM/CMMI[EB/OL].（2010）[2016]http：//www.sei.cmu.edu/cmmi/.

[4]高琰，李建华，费耀平，等.基于CMM的软件项目管理系统的设计与实现[J].计算机工程，2002（9）：249-252.

[5]Curtis B，Hefley W E，Miller S.Overview of the people capability maturity model[J].Overview of the People Capability Maturity Model，1995.

[6] 国 际 标 准 化 组 织 ISO.PMBOK[EB/OL].（1996）[2016].http：//www.pmi.org/.

[7]Jeff S，Ken S.Scrum[EB/OL].（1991）[2016].https：//www.scrum.org/.

[8]Bougroun Z，Zeaaraoui A，Bouchentouf T.The projection of the specific practicesofthe third levelofCMMI model in agile methods：Scrum，XP and Kanban[C]//2014 Third IEEE International Colloquium in Information Science and Technology（CIST）.IEEE，2014：174-179.

[9]IBM.RUP[EB/OL].（2007）[2016].https：//en.wikipedia.org/wiki/Rational_Unified_Process.

[10]Liu S T.Project management：A systems approach to planning，scheduling and controlling（book）[J].Quality Progress，2004，37：95-96.

[11]王有伟.IT行业项目管理现状及发展趋势[J].科技创新导报，2012（17）：209-210.

[12]孙小平，方万芽.浅谈IT行业项目管理的有效方法与策略[J].硅谷，2013（1）：111-112.

[13]李引，袁峰.基于领域驱动设计的应用系统模型[J].计算机工程与应用，2013，49（16）：1-8.

[14]戴明.PDCA[EB/OL].（1950）[2016].https：//zh.wikipedia.org/zh/PDCA.

[15]李引，袁峰，吴鸿.基于软件构件技术的多租户个性化框架[J].计算机工程与应用，2015，51（9）：22-29.

LI Yin1,LIU Dongcheng1,YUAN Feng1,WEI Ge2,YANG Xin1

1.Institute of Software Application Technology,Guangzhouamp;Chinese Academy of Sciences,Guangzhou 511458,China 2.Guangdong KAMFU Informationamp;Technology Co.,Ltd.,Foshan,Guangdong 528200,China

Fine-grained human resource management model and system in software development.Computer Engineering and Applications,2017,53（21）：203-213.

Human resource management plays a critical part in the success of a software project development.Based on the practical project,a fine-grained human resource management model is introduced,which defines the human resource,software project,task and so on,as an entity which has states,attributes and operations.In addition,the data generated from the model provide support for the human resource plan,scheduling,conflict resolution,evaluation etc.A platform is developed based on this model,and a real case is studied through the platform to verify the validity of the model.

fine-grained;project management;human resource management

A

TP311

10.3778/j.issn.1002-8331.1604-0396

佛山市院市合作项目（No.2014HT100022）；广州市珠江新星项目（No.201610010092）；广东省科技计划项目（No.2017A040405012）；南沙区科技项目（No.2016SF001）。

李引（1981—），男，博士，副研究员，研究领域为软件构件，云计算；刘东成（1987—），男，硕士，研究领域为软件工程，食品溯源；袁峰（1977—），男，博士，硕士生导师，副研究员，研究领域为模型驱动，云计算，智慧城市；魏革（1972—），男，高级工程师，研究领域为信息安全，大数据；阳昕（1989—），女，硕士。

2016-04-28

2016-06-29

1002-8331（2017）21-0203-11

CNKI网络优先出版：2017-03-23,http://kns.cnki.net/kcms/detail/11.2127.TP.20170323.0832.018.html