项目管理技法_工程管理

1、项目管理技法软件开发项目管理智囊机构：项目管理室软件开发项目管理是软件开发领域的专业性项目管理活动，其成败关系到整个项目的成败，并影响到企业整体的商誉、市场和盈利力量。所以，软件企业需要关注项目管理力量的提升。而实现这一目的的重要途径之一就是设立项目管理智囊机构，通过积聚整个企业的项目管理专业学问、专业阅历和专业人才来确保项目管理的胜利。假如软件企业消失如下项目管理症状，就可以考虑采纳项目管理智囊机构。 项目管理中总是重复相同的失败大事，项目管理专业技能没有得到积累; 项目管理的绩效由于项目管理者个人的转变而消失很大的差异; 针对项目的质量、进度和成本等事项的估算没有适当的推断标准; 企业内各

2、个项目的管理方法各自不同，没有统一的标准和体系; 每个项目正式启动之前，都不得不进行进行相同的说明和培训; 项目管理者之间的项目管理相关学问没有得到有效沟通和共享项目管理智囊机构主要是指项目管理室(project management office)，这是企业项目管理的智囊机构，与项目组(project team)不同：项目管理室对企业内项目的一般管理手法负责，但是只对各项目供应管理支援;而项目组需要对项目的运营和损益负责。详细而言，项目管理室的主要职责在于：其一，项目管理标准统合，主要包括项目作业流程、项目作业进度、项目作业质量、项目作业成本、项目作业效率等事项的标准统一;其二，项目管理询问

3、支援，项目管理室成员通过其丰富的项目管理阅历和项目管理资料为项目管理供应问题解决方案、问题预防方法以及各种项目管理技能;其三，项目管理掌握支援，主要包括：作为项目之间的协调者，促进项目资源的合理安排;作为项目管理的监督者，猜测并监控各项目存在的各种风险并加以解决;其四，项目管理人才培训，通过有方案的持续的系统的项目管理培训体系为企业的进展供应项目管理培训服务，并从企业内外查找优秀的项目管理者，确保企业拥有足够的项目管理人力资源。NTT数据株式会社在PMO的实施方面就是一个典型。NTT数据为了确保企业项目管理者的质量和数量，在品质保证部内设立“项目管理推动室”作为项目管理的推动组织，重点从3个方

4、面来解决项目管理问题：其一，导入“PM企业内资格认证制度”，就是依据综合了PMBOK、IT技能标准(IT skill standard)以及NTT数据自身拥有的PM专业学问等内容的PM力量基准，以企业内资格的形式确认拥有项目管理技能的人才的价值，提高PM的存在感和价值感;其二，PM职位的明确化，PM职位不仅包括最高层次的项目经理，还包括小组长以及小队长，形成阶段性的职务进阶机制;其三，PM培训体制的完善，就是确立共享和继承NTT数据所拥有的PM专业学问的机制，以及完善促进讨论学习的培训措施。NTT数据为了进一步绽开“强化SI业务竞争力”这一重点经营方针，以及改善开发过程和提高项目管理力量，于2

5、022年11月设立“SI竞争力本部”，并在“SI竞争力本部”内设立项目管理室PMO，以期为项目管理者供应实务性支援，强化组织性的项目管理力量，以此开展整个企业的过程改善活动和项目管理活动。NTT数据还于2022年1月成立全资子公司NTT数据PMO株式会社(NTT DATA PMO CORPORATION)，这是集中了NTT数据项目管理专业学问的专家集团，由NTT数据中拥有丰富的系统开发阅历和很强的项目管理力量的专业人员组成，特地为项目管理学问不足的项目供应管理专业学问、调查、讨论、训练培训和询问服务。最初以NTT数据本身的开发项目为目标开展活动，此后将渐渐扩大到NTT数据集团的全部企业。软件开

6、发项目管理常用技术：效能推动器一般项目管理的常用技术在软件开发项目管理中同样具有价值，是项目管理的效能推动器。这些技术主要包括工作分解结构、里程碑、关键路径法、方案评审技术、S曲线、挣值管理、目标管理、责任矩阵、资源需求直方图、图表化、头脑风暴法、KJ法、蒙托卡罗模拟法、检查清单/模板、基础统计技术等。工作分解结构工作结构分解(WBS：work breakdown structure)是将项目完成之前的全部必要作业项目从上到下层次性排列出来。WBS是项目管理的起点，WBS的设计可以说是项目管理的最重要工具。项目管理的第一步是项目范围定义，明确项目的交付物，进而定义项目需要进行的活动、角色、责任

7、以及项目组的结构。项目范围定义可以使用WBS，将项目的“交付物”自上而下逐层分解成易于管理的若干元素，组 成一个树状图。WBS每细分一层都是对项目元素更细致的描述，细分的元素称为工作细目，其中最低层的工作细目即树状图的叶节点叫作工作包，工作包定义了需要达成的性能、质量、日程和成本。为了便于分层统计和识别，WBS中的每个元素都被指定一个惟一的标识符，并分层表示。制作WBS的留意点是：不是以现存组织为基准进行作业分解，而是以“做什么”为基础，从零开头进行作业分解;不是项目管理者一个人单独制作，而是项目组成员共同制作;WBS的任意层次的要素都需要具有(1)工作范围明确、(2)日程确定、(3)具有成本

8、方案(预算)、(4)资源已经安排、(5)具有业绩测评尺度、(6)组织责任明确等特征。方案评审技术方案评审技术(PERT：program evaluation review technique)是用网络图来表达项目中各项活动的进度和他们之间的相互关系，并在此基础上进行网络分析，确定关键活动与丶?/span路线，利用时差不断地调整与优化网络，以求得最短周期。然后，还可将成本与资源问题考虑进去，以求得综合优化的项目方案方案。PERT可以表现出工作包或者活动、担当者、交期、日程以及各活动之间的依存关系等等。PERT与WBS相互关联和支援，使用PERT有赖于WBS的完成，但是PERT的制作又可以发觉WB

9、S的遗漏。PERT着眼于项目管理者应当考量的“质量、成本、交期(QCD)”，是质量最佳化、成本最小化、交期最短化的分析工具。PERT不拘泥于细枝末节，而是着眼于发觉将来要直面的重要课题和问题点，从能否实现项目目标而不是各工作包的角度进行分析。首先从微观角度制作PERT，在考量各工作包的重要性以及相关性的基础上着眼于QCD相关内容：里程碑的设定;项目风险的挖掘;项目瓶颈的抽出;人、财、物、信息、时间等项目资源的最佳安排;项目成员的最佳配置;工作包与活动的统合;工作包与活动的分解;现有资源的敏捷运用;工作包之间、团队成员之间的整体效果的分析;最短路线、重要路线等关键路线的确定;活动挨次的妥当性。挣

10、值管理挣值管理(EVM：earned value management)是综合项目范围、进度方案和项目资源，测量项目绩效的一种方法。挣值管理通过比较方案工作量、实际挣得多少与实际花费成本，打算成本和绩效是否符合原定方案。挣值管理将方案与挣值换算为成本，并通过与达成实绩所用实际成本的比较来对项目的实绩进行度量和分析，可以说是成本与进度的统合掌握管理工具。挣值管理也离不开偏差管理。在项目过程中，通过监视成本差异和进度差异以及成本效率指数、进度效率指数的变动，猜测超过成本和进度滞后的状况后实行对策。在分析方案与实绩差异的缘由及对策时，可以使用图表化、头脑风暴法+KJ法。假如方案与实绩差异过大，就应当

11、考虑缩小项目范围等对策。头脑风暴+KJ法头脑风暴(brain storming)和KJ法都是发觉问题和解决问题行动中实施制造性开发的方式。头脑风暴法又叫作集思广益法，它通过制造一个无批判的自由的会议环境，使与会者畅所欲言、充分沟通、相互启迪，产生大量制造性的看法，其目的是利用组合脑力刺激制造性，想出更多更好的办法。其作用在于：打破思维定势，鼓舞开放性的思索;发挥集体才智，在他人的看法上建立自己的看法;打破沟通障碍，形成团队精神;防止少数人掌握会议。其实施步骤如下：(1)将头脑风暴的中心议题写在白板、胶片或挂图上，确保每个人都充分理解中心议题的含义。(2)项目组成员轮番发言，任何看法都会得到确定

12、。轮番的过程鼓舞大家参加，但任何人假如没想好则发言可以随时跳过。(3)将每一条看法用大号字写在胶片或挂图上。用原话记录每条看法，不作任何解释。(4)连续轮番发言，直到每个人都没有看法为止。(5)复查看法记录，去除完全重复的条目。当心识别并保留在用词上有极微小差别的看法。头脑风暴法对于熟悉现状、整理问题、争论问题过程中挖掘参加人员的看法特别有效。在PMBOK所谓范围、成本、质量、沟通、风险等学问领域的管理中比较有效。在问题并不明朗的状况下通过KJ法可以使问题渐渐清楚起来。所以，在软件开发过程中，多用于需求分析、业务分析等。在项目方案阶段，对于PMBOK所谓风险管理学问领域中的风险识别、对策立案等

13、方面比较有效。但是，假如理解KJ法的成员比较少，其使用会比较困难。特地集中起来的创意和看法假如仅仅简洁加以分类，就难以引出问题点和创意点。检查清单/模板在项目执行期间，可以由项目管理团队作成检查清单或者模板(checklist/template)，也可以由 项目管理室那样的支持项目管理的组织在项目审查和监督的胜利案例和失败案例的基础上作成。检查清单或者模板是组织的最佳实践，通过这些阅历的积累可以提高项目管理的效率，有助于防止失败。检查清单用于确认作业或工程是否存在遗漏。模板作为产出物的雏形式样，具有WBS、网络图、需求变更书、进展报告书、合同标准文件等形式。通过雏形的敏捷运用，阅历较浅的项目管

14、理者可以明白必需做些什么，并能在其他项目中重复利用。软件开发项目管理检查清单：天气晴雨表检查清单用于确认作业或工程是否存在遗漏，是反映项目管理是否存在问题的“天气晴雨表”。下面是软件开发项目管理的一个检查清单，比本章中所言“软件开发项目管理过程中的祸根及其后果”更加具体。通过这个清单，可以发觉项目管理存在的问题，并实行措施加以改善。需求式样晴雨表 是否存在稳定的、完整的、书面的需求式样? 是否已经就需求事项煞费苦心地与顾客进行了沟通和确认? 是否存在需求式样尚未确定就以“暂定式样”开头作业而事后返工的状况? 是否为了确认顾客的需求而对“需求式样书”进行了审查? 是否依据顾客供应的产品式样书而直

15、接进入了设计作业? 是否在作业途中不断变更或追加需求式样? 是否根据项目编号规章对每项需求给予了惟一的编号? 是否已经明确顾客方的项目推动体制以及最终决策者? 是否摄于顾客的特权优位性而不经争论地接受顾客的需求变更? 是否在远远超越自身力量而根本无法完成的状况下不能清晰地说“不”? 是否在作业已经进入测试阶段后还发觉需求式样理解有误? 是否以单一窗口接收顾客的需求，确保一窗口输入? 项目组成员的作业是否基于最新需求信息，而不是已经失效的历史信息?项目方案晴雨表 是否将估算视为一种特别的技能，并将估算当作一个小项目? 是否定期对项目方案实施重新估算并依据实际状况加以调整? 是否对作业文档等成果物

16、的“量”进行了估量? 是否以适当的单位进行了作业量的估量? 项目作业是否具有具体的日程表? 日程表确定之后，假如和实际状况出入较大，是否进行了调整? 是否接受了不切实际的开发日程，而其结果是，日程表仅仅成为一种形式? “工作量”和“难易度”是否会由于担当者的不同而消失巨大变动? 是否由于实际进展超前于方案而没有思索项目方案本身存在的精度问题?团队管理晴雨表 是否存在明确的软件开发行动单位：团队? 是否虽然叫作团队，但是并没有熟悉到协作而是专注于工作任务的分担? 管理者是否仍旧担当以前作为技术者所担当的详细开发作业任务? 项目管理者是否仅仅依据自己的阅历而将需求式样直接分派给“个人”? 项目管理

17、者是否总是认为项目没有什么值得留意的问题? 团队成员是否知道项目作业内容的相互关系及其优先级? 是否在项目启动之后仍旧还有项目组成员感到无所事事? 是否常常有特定的项目组成员总是加班到深夜? 团队成员是否知道并遵守统一的作业规范? 是否从作业流程上、从团队协作上追究过程序缺陷的真正缘由? 团队成员是否在相互察看成果物后产生提高自己的作业水平的意识? 当问题难点解决之后，是否向项目组成员介绍解决该问题的思维和方法? 项目组成员的出勤时间是否常常相差很大而不查找缘由? 项目组成员在遇到技术难题时是否与项目组其他成员沟通并寻求支援? 项目组成员在争论问题时是否消失无条理的、非建设性的争论?作业流程晴

18、雨表 是否存在专注于组织整体的开发作业和项目流程的人或者小组? 是否存在项目开发作业的标准作业流程? 是否存在记述顾客需求式样的文档标准? 是否存在设计书的文档标准? 是否不经过设计阶段而直接进入编码阶段? 设计阶段是否实施了以设计为对象的审查? 编码阶段是否实施了以代码为对象的审查? 中途式样变更后，是否未经其影响范围的分析就直接安排给担当者? 是否未经单体测试就直接开头综合测试? 是否时至最终才发觉此前隐蔽的诸多问题? 是否无视已经发觉的问题而连续推动作业? 是否多次重复消失以前相同的错误而没有吸取教训? 是否没有特地的测试人员而在交付之前还是由开发者自己实施测试? 对式样需求是否确立了适当的测试项目? 测试是否几乎没有自动化手段? 过程改善方面是否存在可以商议和询问的人员? 是否鼓舞各开发小组写作事后分析报告，至少能就项目进程开会争论? 是否组织正式的活动，就软件开发与质量掌握流程的相关问题相互切磋?项目配置晴雨表 是否在发觉潜在的缺陷时难以确定其对现有模型的影响范围? 是否只有担当者知道而没有向全部成员公布缺陷的修正范围和修正方法? 是否由于修改一个程序缺陷而引发多个新的缺陷? 担当者是否能在任何时间对源程序做自由的变更? 开发期间是否定期对制作过程中的文