项目管理技法
作者: 来源: 文字大小:[大][中][小]
软件开发项目管理智囊机构：项目管理室
软件开发项目管理是软件开发领域的专业性项目管理活动，其成败关系到整个项目的成败，并影响到企业整体的商誉、市场和盈利能力。所以，软件企业需要关注项目管理能力的提升。而实现这一目的的重要途径之一就是设立项目管理智囊机构，通过积聚整个企业的项目管理专业知识、专业经验和专业人才来确保项目管理的成功。如果软件企业出现如下项目管理症状，就可以考虑采用项目管理智囊机构。
目管理中总是重复相同的失败事件，项目管理专业技能没有得到积累；
项目管理的绩效因为项目管理者个人的改变而出现很大的差异；
针对项目的质量、进度和成本等事项的估算没有适当的判断标准；
企业内各个项目的管理方法各自不同，没有统一的标准和体系；
每个项目正式启动之前，都不得不进行进行相同的说明和培训；
项目管理者之间的项目管理相关知识没有得到有效沟通和共享……
项目管理智囊机构主要是指项目管理室(project management office)，这是企业项目管理的智囊机构，与项目组(project team)不同：项目管理室对企业内项目的一般管理手法负责，但是只对各项目提供管理支援；而项目组需要对项目的运营和损益负责。具体而言，项目管理室的主要职责在于：其一，项目管理标准统合，主要包括项目作业流程、项目作业进度、项目作业质量、项目作业成本、项目作业效率等事项的标准统一；其二，项目管理咨询支援，项目管理室成员通过其丰富的项目管理经验和项目管理资料为项目管理提供问题解决方案、问题预防方法以及各种项目管理技能；其三，项目管理控制支援，主要包括：作为项目之间的协调者，促进项目资源的合理分配；作为项目管理的监督者，预测并监控各项目存在的各种风险并加以解决；其四，项目管理人才培训，通过有计划的持续的系统的项目管理培训体系为企业的发展提供项目管理培训服务，并从企业内外寻找优秀的项目管理者，确保企业拥有足够的项目管理人力资源。
NTT数据株式会社在PMO的实施方面就是一个典型。NTT数据为了确保企业项目管理者的质量和数量，在品质保证部内设立“项目管理推进室”作为项目管理的推进组织，重点从3个方面来解决项目管理问题：其一，导入“PM企业内资格认证制度”，就是根据综合了PMBOK、IT技能标准(IT skill standard)以及NTT数据自身拥有的PM专业知识等内容的《PM能力基准》，以企业内资格的形式确认拥有项目管理技能的人才的价值，提高PM的存在感和价值感；其二，PM职位的明确化，PM职位不仅包括最高层次的项目经理，还包括小组长以及小队长，形成阶段性的职务进阶机制；其三，PM培训体制的完善，就是确立共享和继承NTT数据所拥有的PM专业知识的机制，以及完善促进研究学习的培训措施。NTT数据为了进一步展开“强化SI业务竞争力”这一重点经营方针，以及改善开发过程和提高项目管理能力，于2003年11月设立“SI竞争力本部”，并在“SI竞争力本部”内设立项目管理室PMO，以期为项目管理者提供实务性支援，强化组织性的项目管理能力，以此开展整个企业的过程改善活动和项目管理活动。NTT数据还于2004年1月成立全资子公司NTT数据PMO株式会社(NTT DATA PMO CORPORATION)，这是集中了NTT数据项目管理专业知识的专家集团，由NTT数据中拥有丰富的系统开发经验和很强的项目管理能力的专业人员组成，专门为项目管理知识不足的项目提供管理专业知识、调查、研究、教育培训和咨询服务。最初以NTT数据本身的开发项目为目标开展活动，此后将逐渐扩大到NTT数据集团的所有企业。软件开发项目管理常用技术：效能推动器
一般项目管理的常用技术在软件开发项目管理中同样具有价值，是项目管理的效能推动器。这些技术主要包括工作分解结构、里程碑、关键路径法、计划评审技术、S曲线、挣值管理、目标管理、责任矩阵、资源需求直方图、图表化、头脑风暴法、KJ法、蒙托卡罗模拟法、检查清单/模板、基础统计技术等。
工作分解结构
工作结构分解(WBS：work breakdown structure)是将项目完成之前的所有必要作业项目从上到下层次性罗列出来。WBS是项目管理的起点，WBS的设计可以说是项目管理的最重要工具。项目管理的第一步是项目范围定义，明确项目的交付物，进而定义项目需要进行的活动、角色、责任以及项目组的结构。项目范围定义可以使用WBS，将项目的“交付物”自上而下逐层分解成易于管理的若干元素，组成一个树状图。WBS每细分一层都是对项目元素更细致的描述，细分的元素称为工作细目，其中最低层的工作细目即树状图的叶节点叫作工作包，工作包定义了需要达成的性能、质量、日程和成本。为了便于分层统计和识别，WBS中的每个元素都被指定一个惟一的标识符，并分层表示。制作WBS的注意点是：不是以现存组织为基准进行作业分解，而是以“做什么”为基础，从零开始进行作业分解；不是项目管理者一个人单独制作，而是项目组成员共同制作；WBS的任意层次的要素都需要具有(1)工作范围明确、(2)日程确定、(3)具有成本计划(预算)、(4)资源已经分配、(5)具有业绩测评尺度、(6)组织责任明确等特征。
计划评审技术
计划评审技术(PERT：program evaluation review technique)是用网络图来表达项目中各项活动的进度和他们之间的相互关系，并在此基础上进行网络分析，确定关键活动与丶?/span>路线，利用时差不断地调整与优化网络，以求得最短周期。然后，还可将成本与资源问题考虑进去，以求得综合优化的项目计划方案。PERT可以表现出工作包或者活动、担当者、交期、日程以及各活动之间的依存关系等等。PERT与WBS相互关联和支援，使用PERT有赖于WBS的完成，但是PERT的制作又可以发现WBS的遗漏。PERT着眼于项目管理者应该考量的“质量、成本、交期(QCD)”，是质量最佳化、成本最小化、交期最短化的分析工具。PERT不拘泥于细枝末节，而是着眼于发现将来要直面的重要课题和问题点，从能否实现项目目标而不是各工作包的角度进行分析。首先从微观角度制作PERT，在考量各工作包的重要性以及相关性的基础上着眼于QCD相关内容：里程碑的设定；项目风险的挖掘；项目瓶颈的抽出；人、财、物、信息、时间等项目资源的最佳分配；项目成员的最佳配置；工作包与活动的统合；工作包与活动的分解；现有资源的灵活运用；工作包之间、团队成员之间的整体效果的分析；最短路线、重要路线等关键路线的确定；活动顺序的妥当性。
挣值管理
挣值管理(EVM：earned value management)是综合项目范围、进度计划和项目资源，测量项目绩效的一种方法。挣值管理通过比较计划工作量、实际挣得多少与实际花费成本，决定成本和绩效是否符合原定计划。挣值管理将计划与挣值换算为成本，并通过与达成实绩所用实际成本的比较来对项目的实绩进行度量和分析，可以说是成本与进度的统合控制管理工具。挣值管理也离不开偏差管理。
在项目过程中，通过监视成本差异和进度差异以及成本效率指数、进度效率指数的变动，预测超过成本和进度滞后的情况后采取对策。在分析计划与实绩差异的原因及对策时，可以使用图表化、头脑风暴法+KJ法。如果计划与实绩差异过大，就应该考虑缩小项目范围等对策。
头脑风暴＋KJ法
头脑风暴(brain storming)和KJ法都是发现问题和解决问题行动中实施创造性开发的方式。
头脑风暴法又叫作集思广益法，它通过创造一个无批评的自由的会议环境，使与会者畅所欲言、充分交流、互相启迪，产生大量创造性的意见，其目的是利用组合脑力刺激创造性，想出更多更好的主意。其作用在于：打破思维定势，鼓励开放性的思考；发挥集体智慧，在他人的看法上建立自己的意见；打破沟通障碍，形成团队精神；防止少数人控制会议。其实施步骤如下：(1)将头脑风暴的中心议题写在白板、胶片或挂图上，确保每个人都充分理解中心议题的含义。(2)项目组成员轮流发言，任何意见都会得到肯定。轮流的过程鼓励大家参与，但任何人如果没想好则发言可以随时跳过。(3)将每一条意见用大号字写在胶片或挂图上。用原话记录每条意见，不作任何解释。(4)继续轮流发言，直到每个人都没有意见为止。(5)复查意见记录，去除完全重复的条目。小心识别并保留在用词上有极细微差别的意见。头脑风暴法对于认识现状、整理问题、讨论问题过程中挖掘参与人员的意见非常有效。在PMBOK所谓范围、成本、质量、沟通、风险等知识领域的管理中比较有效。
在问题并不明朗的情况下通过KJ法可以使问题逐渐清晰起来。所以，在软件开发过程中，多用于需求分析、业务分析等。在项目计划阶段，对于PMBOK所谓风险管理知识领域中的风险识别、对策立案等方面比较有效。但是，如果理解KJ法的成员比较少，其使用会比较困难。特地集中起来的创意和意见如果仅仅简单加以分类，就难以引出问题点和创意点。
检查清单/模板
在项目执行期间，可以由项目管理团队作成检查清单或者模板(checklist/template)，也可以由项目管理室那样的支持项目管理的组织在项目审查和监督的成功案例和失败案例的基础上作成。检查清单或者模板是组织的最佳实践，通过这些经验的积累可以提高项目管理的效率，有助于防止失败。检查清单用于确认作业或工程是否存在遗漏。模板作为产出物的雏形式样，具有WBS、网络图、需求变更书、进展报告书、合同标准文件等形式。通过雏形的灵活运用，经验较浅的项目管理者可以明白必须做些什么，并能在其他项目中重复利用。
软件开发项目管理检查清单：天气晴雨表
检查清单用于确认作业或工程是否存在遗漏，是反映项目管理是否存在问题的“天气晴雨表”。下面是软件开发项目管理的一个检查清单，比本章中所言“软件开发项目管理过程中的祸根及其后果”更加详细。通过这个清单，可以发现项目管理存在的问题，并采取措施加以改善。
需求式样晴雨表
是否存在稳定的、完整的、书面的需求式样？
是否已经就需求事项煞费苦心地与顾客进行了沟通和确认？
是否存在需求式样尚未确定就以“暂定式样”开始作业而事后返工的情况？
是否为了确认顾客的需求而对“需求式样书”进行了审查？
是否根据顾客提供的产品式样书而直接进入了设计作业？
是否在作业途中不断变更或追加需求式样？
是否按照项目编号规则对每项需求赋予了惟一的编号？
是否已经明确顾客方的项目推进体制以及最终决策者？
是否摄于顾客的特权优位性而不经讨论地接受顾客的需求变更？
是否在远远超越自身能力而根本无法完成的情况下不能清楚地说“不”？
是否在作业已经进入测试阶段后还发现需求式样理解有误？
是否以单一窗口接收顾客的需求，确保一窗口输入？
项目组成员的作业是否基于最新需求信息，而不是已经失效的历史信息？
项目计划晴雨表
是否将估算视为一种特殊的技能，并将估算当作一个小项目？
是否定期对项目计划实施重新估算并根据实际情况加以调整？
是否对作业文档等成果物的“量”进行了估计？
是否以适当的单位进行了作业量的估计？
项目作业是否具有详细的日程表？
日程表确定之后，如果和实际情况出入较大，是否进行了调整？
是否接受了不切实际的开发日程，而其结果是，日程表仅仅成为一种形式？
“工作量”和“难易度”是否会因为担当者的不同而出现巨大变动？
是否因为实际进展超前于计划而没有思考项目计划本身存在的精度问题？
团队管理晴雨表
是否存在明确的软件开发行动单位：团队？
是否虽然叫作团队，但是并没有认识到协作而是专注于工作任务的分担？
管理者是否仍然承担以前作为技术者所承担的具体开发作业任务？
项目管理者是否仅仅根据自己的经验而将需求式样直接分派给“个人”？
项目管理者是否总是认为项目没有什么值得注意的问题？
团队成员是否知道项目作业内容的相互关系及其优先级？
是否在项目启动之后仍然还有项目组成员感到无所事事？
是否经常有特定的项目组成员总是加班到深夜？
团队成员是否知道并遵守统一的作业规范？
是否从作业流程上、从团队协作上追究过程序缺陷的真正原因？
团队成员是否在相互察看成果物后产生提高自己的作业水平的意识？
当问题难点解决之后，是否向项目组成员介绍解决该问题的思维和方法？
项目组成员的出勤时间是否经常相差很大而不寻找原因？
项目组成员在遇到技术难题时是否与项目组其他成员沟通并寻求支援？
项目组成员在讨论问题时是否出现无条理的、非建设性的讨论？
作业流程晴雨表
是否存在专注于组织整体的开发作业和项目流程的人或者小组？
是否存在项目开发作业的标准作业流程？
是否存在记述顾客需求式样的文档标准？
是否存在设计书的文档标准？
是否不经过设计阶段而直接进入编码阶段？
设计阶段是否实施了以设计为对象的审查？
编码阶段是否实施了以代码为对象的审查？
中途式样变更后，是否未经其影响范围的分析就直接分配给担当者？
是否未经单体测试就直接开始综合测试？
是否时至最后才发现此前隐藏的诸多问题？
是否无视已经发现的问题而继续推进作业？
是否多次重复出现以前相同的错误而没有吸取教训？
是否没有专门的测试人员而在交付之前还是由开发者自己实施测试？
对式样需求是否确立了适当的测试项目？
测试是否几乎没有自动化手段？
过程改善方面是否存在可以商量和咨询的人员？
是否鼓励各开发小组写作事后分析报告，至少能就项目进程开会讨论？
是否组织正式的活动，就软件开发与质量控制流程的相关问题相互切磋？
项目配置晴雨表
是否在发现潜在的缺陷时难以确定其对现有模型的影响范围？
是否只有担当者知道而没有向所有成员公布缺陷的修正范围和修正方法？
是否因为修改一个程序缺陷而引发多个新的缺陷？
担当者是否能在任何时间对源程序做自由的变更？
开发期间是否定期对制作过程中的文件和程序进行备份？
是否确立了资源备份在非常时期的因应方式？
需求式样书和设计书等正式文件是否存在“确认”手续？
项目文档是否一直保持最初的状态，即使在式样变更后仍然没有变化？
是否在项目后期难以想起中途式样变更的“理由”？
对于程序缺陷和式样变更，是否能追踪其修改点？
对于开发环境目录中的旧代码是否难以判断其能否删除？
开发文档是否会出现链接到旧版本的情况？
教育培训晴雨表
是否描绘出现在的开发组织多年后的“风姿”？
在组织上，是否对现在的人员实施技术性教育和培训？
是否确立了员工教育培训的计划和目标？
是否将技术学习视为个人任务而没有组织上的“方向”？
项目开发人员所持有的软件开发文献的平均数量是否在1册以下？
项目作业休息时间是否毫不涉及崭新技术方面的话题？
项目组成员是否不知道软件工程的意思？
是否不了解“凝聚度”、“结合度”等词汇的意思？
是否难以说出5个以上的软件质量特性及其副特性？
项目审查晴雨表
参与者是否了解审查的整体流程？
是否带着目的而非盲目地实施审查作业？
是否仅仅局限于代码审查而不顾及其他？
审查者是否只关注形式而非实质？
是否明确审查对象物，针对“物”而非“人”？
是否记录审查结果并追踪缺陷修正结果？
是否将审查的反馈结果导入下一项目中？
审查会议是否演化成为问题解决会议？
其他
是否采取了数据备份以及病毒防范等措施？
对电子邮件的应对是否总是滞后？
是否感到电子邮件的应对很繁琐？