项目管理项目管理要素指南问.docx
《项目管理项目管理要素指南问.docx》由会员分享，可在线阅读，更多相关《项目管理项目管理要素指南问.docx（20页珍藏版）》请在冰豆网上搜索。
项目管理项目管理要素指南问
（项目管理）项目管理要素指南问
5策划阶段输出标准文件有哪些？
总体工作计划、人力资源计划、质量保证计划、风险分析与对策、项目预算表、项目阶段中所需要的标准文档模版、项目启动报告
6各输出文件如何处理？
首先，所有输出文件均需要得到相关人员批准确认，提交配置管理员归档；质量保证计划提交SQA监督执行、项目预算表提交财务跟踪执行
7如何编制项目预算表？
项目预算表由五大部分组成：
人工费用（包括咨询服务费用）、采购费用（项目中用到的软硬件）、全过程差旅费用、办公费用、项目活动费用；
预算编制以计划为依据，分为预算总表和明细表；总表结果以明细表汇总所得；
项目经理每月需要检查预算执行情况，如果出现变化，需及时提交项目管理委员会，经审核同意后，方可允许预算变更；
项目关闭时，项目经理需提交预算执行报告。
8如何进行工期评估？
项目工期评估是项目管理中很重要的一个环节；整个项目后续的计划与人员安排都依赖于该工期的评估；项目经理在做工期评估时按照以下步骤：
1）根据售前技术支持方案，与产品功能进行比较，分系统列出差异表
2）分系统，按照增、删、改、查、打印、导入导出原则，对差异功能点进行统计，统计出待开发功能点，根据历史开发经验，评估出差异功能点开发工作量；该工作量+标准产品部分开发工作量为该子系统合计开发工作量
3）按照实施过程时间分配比率（需求：
设计开发：
测试：
实施=0.6：
1：
0.7：
0.6）,计算出各子系统总体工作量和周期
4）如果客户有明确周期要求，则根据上述得到的总工作量合理安排资源；如果没有周期要求，则项目经理按照产品实施人员标准要求规划出合理的周期
5）在最后得出的总体工作量和周期基础上根据项目经验分别乘1.1~1.3的风险系数
9如何做好项目风险管理？
首先在项目启动时，做好风险分析；风险分析步骤：
1）识别风险点、风险发生概率以及影响程度
2）确定重点关注风险点，并给出风险解决措施
3）给出风险措施的跟踪监控措施
在管理风险问题点时，项目经理要遵循闭环管理原则，对于重点关注风险，而且影响程度大的风险，一定要跟踪落实到底，直到该风险消失或解除；
其次，在项目启动的同时，项目经理要编制质量保证书，保证书主要针对策划书中项目各阶段的输出的保证，并将该质量保证书提交SQA审核，对于重大项目，交由专职SQA跟踪与监控。
10项目经理应知应会的计划有哪些？
项目策划——包括策划整个项目的进度、资源（人力、软硬件资源等）、财务、过程模式、风险分析等主要内容；项目策划完成，项目经理必须对项目的整体运作过程做到心中有数。
变更计划——变更无处不在，项目经理必须根据公司制度严格按照变更流程制定变更计划（按优先级及必要性对变更进行筛选）。
开发计划——更细节的工作计划，具体分配到开发小组或开发人员的计划，必须明确到1-2天内的工作内容，这样的开发计划才有价值。
测试计划——需协助测试部门根据项目策划的进度安排，制定具体的测试计划。
实施计划——视项目组的工作要求来定，如果项目组是实施产品或者包括做简单的二次开发，实施计划基本上可与项目策划同等作用（或用项目策划来涵盖），否则便是项目后期的试运行、验收等工作的计划编排。
其余的还要明确：
配置管理计划、质量保证计划、技术评审计划、月度/周工作总结计划等等。
综上，凡事预则立，项目经理应排除“计划不如变化快”的消极心理，要知“如果没有计划，变都不知如何变！
”
11制定计划应注意哪几个方面？
a）不能只关注时间，而要看人日工作量，往往一个项目的实施周期是合同定好的，这样项目经理编制计划时已经约束好了大的时间节点，编制计划多数是编制人日安排；同时注重人日工作量还有助于项目经理更加关注成本和组织协同。
b）安排工作计划应明确到1-2天的工作量和内容，天数粒度大会导致无法准确控制；
c）不要忽视周计划的重要性和作用，周计划是最为明确也最易有效控制的计划；
d）不要忽视阶段总结，计划和总结往往是同时的，只有通过好的总结，识别出遗留问题，才能更好的编制下一阶段计划；
12如何使项目组人员充分明确并重视计划？
首先要使项目组人员明确计划，要明确计划就需要项目组每个人都明确的知道自己应该做什么，可以通过计划分解来实现。
大计划分解为小计划、组内计划分解为个人计划，要充分调动团队每个成员的主动性，自行分解汇总。
其次，明确了计划还要使组内人员认识到计划内容的重要性，让每个人知道为什么做，同时对计划引起足够的重视，这需要项目组以透明的方式进行管理和沟通，如可通过例会方式将每个人的工作成果展示给大家等等。
需求调研阶段
13如何开展需求调研？
1）实施人员在接到调研任务后，首先应从项目经理、售前技术支持以及销售三方获取到客户相关需求信息（包括技术方案、客户原始需求）
2）告知客户方我们调研工作方法：
首先提供产品调研模版于客户，针对该模版进行解释，对客户进行培训，如何按照该模版描述自己的需求
3）给客户布置任务，按照我们提供的模版把企业实际业务流程写出
4）分析客户提供的业务流程文档，与客户一起分析改善点
5）根据讨论确定的思路修改业务流程文档，收集或设计相关表单报表；让用户管理层签字确认业务流程文档。
6）将业务流程文档按照公司标准的需求规格说明书格式转化
14需求调研人员应避免在哪些方面陷入“钻牛角”？
调研人员往往会在调研过程中陷入以下困境：
1）与客户过分强调技术实现细节
2）调研过程忽视技术实现而承诺过多业务功能之外的软件需求
3）过分追求完美，在业务实现上，客户没有提出的需求，主动提出和承诺
15如何处理客户不合理需求及软件期望？
1）不要当场否定或承诺客户提出的需求
2）寻求对方项目经理帮助，分析客户需求提出的不合理性或者过高期望可能带来的风险
3）如果客户最后坚持要实现，而需求又不在前期范围中，最后统一汇总，让对方项目经理，甚至更高层领导签字，明确描述该部分需求对后期的可能影响
16如何处理调研中客户消极不配合的情况？
对该类客户，首先向对方表示感谢，希望得到工作上的支持；其次，多从对方角度考虑问题，分析客户不配合原因，从中找出客户的真正关注问题和希望解决的问题；如果是属于对方因为自身工作任务重，寻求项目经理帮助，找到客户的领导，在此期间能够分担部分客户的本职工作，并表示感谢；如果是其他原因，请对方项目经理帮助，做好客户思想工作；
不管是什么情况，绝对不能出现向客户方任何人抱怨客户不配合；
17如何同时展开多个业务模块的需求调研？
调研人员在调研时，一定避免所有的事情都由自己主导完成，要充分发挥客户的参与性和积极性；首先在我们调研方法上，将需要调研的业务流程交给客户，即给客户布置作业；让用户在一段时间内按照我们的要求提交相应的资料或文档；调研人员找出时间差，在时间差的范围内分别与不同用户讨论业务流程。
18需求调研中有咨询服务时，如何做好与咨询顾问的配合？
1）与咨询顾问沟通确认我们的工作方法和工作模版，在任务上进行分工；尽量做到用文档进行输出交接。
2）时刻提醒咨询顾问围绕软件界定需求范围与客户讨论，不要超出需求范围
设计与开发阶段
19如何制定设计开发计划?
设计开发计划的制定主要有以下几个步骤：
20设计开发计划中各项任务应该细化到何种颗粒度？
具体的设计开发计划中的各项任务应尽可能细化到0.5~2个工作日。
21开发模型的选择？
建议采用迭代化的开发方法
一个项目的好坏，开发模型优良是项目成功重要保障，有了好的开发模型我们可以很好的控制项目进度、降低风险。
所以我们在项目开始前首先需要确定项目的开发模型。
这里我们建议采用迭代式的开发模型。
我们知道原有早期传统的开发模型是一个文档驱动的流程，它将整个软件开发过程划分为顺序相接的几个阶段，每个阶段都必需完成全部规定的任务后才能够进入下一个阶段。
项目开始首先完成系统需求规格说明书，之后才能够进入概要设计阶段，编码则在系统设计完成之后进行。
这就意味着只有当所有的系统模块全部开发完成之后，我们才进行系统集成，对于一个由很多个模块组的复杂系统来说，这是一个非常艰巨而漫长的工作，且存在着潜在的风险。
如：
需求或者设计中的错误无法在项目早期发现，只有在系统交付客户之后才能发现原先对于需求的理解是错误的，系统设计的错误也只有在测试阶段才能被发现。
对于项目风险的控制能力较弱，往往项目风险只能随着项目结束才能逐步降低，同时也只有经过系统测试之后，才能确定设计是否能够真正满足系统需求。
为了解决传统软件开发流程中的问题，我们建议采用迭代化的开发方法来取代瀑布模型。
在瀑布模型中，我们要完成的是整个软件系统开发这个大目标。
在迭代化的方法中，我们将整个项目的开发目标划分成为一些更易于完成和达到的阶段性小目标，这些小目标都有一个明确的阶段性评估标准。
迭代就是为了完成一定的阶段性目标而所从事的一系列开发活动，在每个迭代开始前都要根据项目当前的状态和所要达到的阶段性目标制定迭代计划，整个迭代过程包含了需求调研、软件设计、软件实现、版本集成、软件测试、软件发布和产品交付等各种类型的开发活动，迭代完成之后需要对迭代完成的结果进行评估，并以此为依据来制定下一次迭代的目标。
22何时开始进行程序集成？
从开始有代码的第1天起就要进行集成，而且是持续集成，直到通过测试，交付客户正式使用。
这个第1天通常情况下，还没有开始进入编码阶段，而只是设计的初级阶段或中间阶段。
23在编写代码时是先写代码还是先写注释？
我们采用的是单元测试驱动的方式进行开发，先写测试代码，再写程序代码；但在代码编写之前最好先写注释，对于复杂逻辑要写出详细的伪代码。
24编写注释有哪些主要事项？
（1）必须是有意义；
（2）必须正确的描述了程序；（3）必须是最新的。
注释必不可少，但也不应过多，以下是四种必要的注释：
a.标题、附加说明；
b.函数说明：
对几乎每个函数都应有适当的说明，通常加在函数实现之前，在没有函数实现部分的情况下则加在函数原型前，其内容主要是函数的功能、目的、算法等说明，参数说明、返回值说明等，必要时还要有一些如特别的软硬件要求等说明；
c.在代码不明晰或不可移植处应有少量说明；
d.及少量的其它注释。
25在设计开发中遇到问题怎么办？
1）如果是各模块公用接口等共性的问题需要及时召集相关人员，一起协商优先解决；协商后，明确具体负责人，由该人负责，其他人协助解决；
2）如果是个人初次遇到的问题，建议个人先独立进行解决，根据影响程度，如果超过0.5~2个小时仍未解决，请咨询其他同事。
3）作为小组组长或项目负责人，应经常性的与组员进行沟通，及时发现影响进度的问题或瓶颈，并及时解决，做到日清周清；对于大家经常性遇到的问题，及时进行总结，形成指导手册并不断补充完善。
26在编码中有哪些注意事项？
遵循公司制定的统一的编码规范。
下面列举其中的几点共参考：
◆清晰易读的源程序文件结构：
每个程序文件应由标题、内容和附加说明三部分组成。
（1）标题：
文件最前面的注释说明，其内容主要包括：
程序名，作者，版权信息，简要说明等，必要时应有更详尽的说明（将以此部分以空行隔开单独注释）。
（2）内容控件注册等函数应放在内容部分的最后，类的定义按private、protected、pubilic的顺序，各部分中按数据、函数、属性、事件的顺序。
（3）附加说明：
文件末尾的补充说明，如参考资料等，若内容不多也可放在标题部分的最后。
◆一致的界面设计风格
◆统一的编辑风格：
（1）缩进：
缩进以Tab为单位，一个Tab为四个空格大小。
全局数据、函数原型、标题、附加说明、函数说明、标号等均顶格书写。
（2）空格：
数据和函数在其类型，修饰名称之间适当空格并据情况对齐。
关键字原则上空一格，不论是否有括号，对语句行后加的注释应用适当空格与语句隔开并尽可能对齐。
（3）对齐：
原则上关系密切的行应对齐，对齐包括类型、修饰、名称、参数等各部分对齐。
另每一行的长度不应超过屏幕太多，必要时适当换行。
（4）空行：
程序文件结构各部分之间空两行，若不必要也可只空一行，各函数实现之间一般空两行。
（5）按照6所述编写注释
◆严格按照命名规范进行命名
27开发人员为什么要进行自测？
开发人员的测试是保证代码能正常运行，在开发时候发现的错误往往比较容易修正。
（另外一个好处就是没有人来骂你。
因为只有你自己知道）。
但是一旦软件到了测试小组那里出了问题，那么就多了很多时间来修正BUG，如果到了客户哪里才发现的BUG，那么时间就更长了，开发人员本身受到的压力也是到了最大化了。
另外开发人员的测试除了保证代码能正常运行以外，还有一个很重要的方面就是要保证上次能正常运行的代码，这次还是能正常运行。
如果做不到这点，那么BUG就不断的会出现，很多BUG也会反复出现。
于是软件看上去就有修补不完的BUG了。
28如何进行组内成员配置？
项目启动之前除项目管理者着手计划制定外，同时也需要对其项目组成员配置进行规划，界定其职责。
通常我们需要几种角色：
技术组长：
负责技术难题攻关，组间沟通协调。
需求人员：
负责将用户需求转换成项目内的功能需求和非功能需求，编制项目需求规格说明书，针对每个迭代集成版本与用户交流获取需求的细化。
设计人员：
负责对需求规格说明书，进行系统设计。
开发人员：
实现设计，完成用户功能。
集成人员：
负责整套系统的编译集成，督促小组系统功能提交，及时发现各模块集成问题，起到各小组之间的沟通的纽带。
测试人员：
对于集成人员集成的版本进行测试，尽可能的发现程序缺陷，以及未满足需求的设计。
文档整理人员：
负责对小组内产生文档的整合，统一。
系统环境人员：
负责系统编译环境、运行环境规划。
编制系统环境说明书。
维护人员：
系统验收后，维护人员，建议维护人员早期进入项目参与项目测试以便顺利承担起项目维护职责。
在设计开发阶段，对以上各个角色都需要，往往一个小组成员只有2~4人，我们可以根据实际需要1人承担多个角色。
29如何进行组内沟通？
通常口头沟通是最为常见的，这种沟通快捷、方便。
一般的小问题或者是简单问题的理解非常有效，但问题复杂或是此次沟通需要后续使用，那么该种沟通则存在问题，则需要以书面方式加口头相结合最为有效。
即可在本次沟通中方便、快捷的领会，也可以为后续工作提供依据。
项目组内部沟通不是越多越好，你会发现当内部的沟通时间没有规律或是沟通时间过长，这样其实也会严重影响项目成员的开发进度，但沟通又是必不可少，何种间隔最为适宜了？
这是不好定的，通常以评审作为沟通的基础，平日的沟通建议项目组成员在每天工作过程遇到问题，将其记录下来，然后在以邮件方式发送给需要沟通或者询问者。
大家可以每天下班之前收取邮件，对于可以直接回答的问题则直接以邮件方式回复，对于无法直接答复而只需与提出问题者讨论的问题，则可以在第二天上班前进行商议确定。
而需要众人一起讨论的问题，则放到每周会议上讨论。
非常紧急的话则可以马上约齐人员讨论，通常有良好的沟通方式话，这种非常紧急的问题是不常见的。
现场实施阶段
30项目实施阶段的主要工作有哪些？
在项目实施阶段，主要有以下工作（按先后顺序列举）：
（1）基础数据准备
（2）软件安装调试
（3）用户培训（一般分管理员培训和业务操作培训两个部分）
（4）试运行（必要时需进行应用辅导）
（5）项目总结
（6）验收
在上述工作开展之前，要制定详细的实施计划，计划需和客户充分沟通并获得认可。
31基础数据的准备重不重要？
基础数据的准备和录入，是系统运行的基础，故控制好这个环节也至关重要。
大长江检验模块，在系统试运行前，配备了4名专职录入员4个月才完成了基础数据“检验卡片”的录入工作（总共5000张检验卡片），可见，提前进行基础数据的收集并做好相应的录入准备是非常重要的。
32软件安装调试时有哪些注意事项？
（1）在到客户现场前，需提前与客户确认硬件、软件及网络环境已配备到位；
（2）如需与第三方软件系统做接口，需确认对方配合人员能按时到位；
（3）给客户方安装的任何商业软件，如Windows操作系统、Oralce/SqlServer数据库等，都应由客户方提供（在合同中明确提出由我方提供的除外）。
33问开展软件培训时会遇到什么困难？
遇到困难后我们该怎么办？
培训时可能会遇到各种的困难，如硬件不到位，人员不到位等，这个时候需要我们和客户方领导确认一个培训负责人，所有培训事项直接由他来负责，如培训人员组织，培训场地，培训所需电脑及其他硬件，这样，通过客户方自上而下施加压力的方式可以顺利的完成客户培训，避免项目在等待中延期和超支。
另外需要注意的是，在培训阶段，必须要求客户有一个负责软件维护的人员全程参与整个培训。
这个对客户和我们都有好处，以后客户对软件后期一些维护接手快，我们后期工作也轻松。
34项目总结汇报时有哪些注意事项？
项目总结汇报一般是项目验收的前奏，这个环节也至关重要，如果能把握好项目总结汇报，得到客户的验收签字就容易多了。
在做项目总结汇报时，有以下注意事项：
（1）汇报的内容需要提前预审，预审人员不仅是本公司相关人员，更重要的是需要客户方项目组、特别是项目经理及主要负责人参与，一来获得他们的认同和支持，二来他们的总结对客户高层来说更有分量和说服力！
（2）总结汇报一定要邀请对方相关主要领导参加，如果他们不能参加，总结汇报的价值就降低了不少。
总结汇报是一个承前启后的过程，在汇报结束时，需要展示后续的验收日程表，以推进验收工作的展开。
35异地实施时的计划与客户计划如何衔接？
首先明确一般客户方负责项目的人员是兼职的（可能负责多个项目或其他本职工作，即使客户方专门指派了项目的负责人），而我们作为实施方是专职的；其次明确所有项目计划都是我方项目经理应该专职编制和总结的，包括参考客户方有关项目的计划和要求，明确总的推动一般是以我方为主，排除被动工作的心理；
最后，我们的项目实施计划均需要客户相关人员配合完成，下一步计划需要提前告知相关人员，有冲突时及时调整，以免执行计划工作时，客户出现无法配合的情况；
36异地实施时，如何有效组织项目小组的具体工作（计划和会议相关）？
项目组总结计划必须和客户方项目相关人员一同协商通过；避免单方面提出计划安排；
项目组异地工作的效果，往往取决于客户的参与度和支持度，项目经理要靠计划及相关会议做好各个层面的充分沟通；
试运行阶段
37在试运行阶段如何与不同角色的客户进行沟通？
试运行阶段应确定双方的沟通接口人员，我方主要与客户方的接口人员进行直接沟通。
该接口人员可以是业务部门的具体试运行负责人，也可以是信息部门的具体试运行负责人。
对于业务问题，主要来自于对方的基层使用人员，而大面积基层用户都习惯和自己人交流解决问题，所以我们应委托业务部门的具体试运行负责人来收集基层使用人员提出的各类问题，由其汇总后定期与我方沟通。
业务部门的负责人员往往对基层业务非常了解，此类沟通方式可以清晰的处理各类业务问题，但对于技术类问题应考虑业务人员的实际情况，必要时可以借助于对方信息部门的相关人员协调解决。
如果接口人员是信息部门的具体试运行负责人，此类沟通往往不能彻底有效的弄清业务问题，此时可以通过接口人员联系基层的使用人员，进行直接沟通。
沟通时切记要因材施教和对症下药，不要与技术人员过于深究业务细节，也不要对业务人员使用不恰当的技术术语。
38系统试运行期间有哪些注意事项？
（1）客户提出的任何问题或要求，需及时响应并记录；如果是需要我方来处理的问题，则需给出处理措施和计划完成日期；
（2）在试运行阶段，项目组应积极推动用户来使用系统，如果使用方不积极而我们又没有推动的话，试运行就达不到应有的效果，最终很可能影响项目的按时验收；
（3）在试运行阶段，项目组的工作重心应该不单是保障系统的稳定运行，还应观察和总结试运行的效果并提取运行数据，这样做的目的是：
1）对系统的作用进行评估；
在紧接下来的验收和项目总结阶段有据可依、有话可说。
39如何处理用户试运行期间发现的BUG？
软件存在问题是客观的，即使是在规范的质量保证体系下经过了严格的单元测试和系统测试，也没有不存在BUG的软件。
而用户往往有意识无意识假定软件就应该是没有问题的，这是我们可以预见的项目风险。
因而对于试运行期间由用户发现的BUG，我们应该虚心听取，诚恳致歉，及时解决，并且自发的进行举一反三的复查工作，争取先于客户发现潜在的BUG，保护来之不易的用户满意度。
同时，应该形成详细的BUG记录定时提交给质量保证部门，以形成逐渐完善的知识经验库，助以提高未来项目的测试针对性和覆盖率。
40如何处理用户试运行期间提出的修改要求？
任何项目都有明确的合同约束边界，而基层用户在试运行期间提出的问题往往是不会考虑这一约束边界的。
对于用户提出的任何问题，都不应即时承诺，一旦轻易承诺，将导致项目的边界无休止的变更，严重模糊项目目标，项目的修改将不断扩散，而距验收目标愈行愈远。
我们要做的是如实的做好记录，进而进行边界分析，分清哪些是合同范围内的修改要求，哪些是超出合同范围的修改要求，对于这些要求分类进行处理。
41如何处理超出合同范围的修改要求？
用户在需求调研阶段所提出的需求是存在局限性的，在实际应用后难免产生一些新的业务思想，希望也通过系统加以解决，这些业务需求可能包含很有价值的需求，也可能是未经过深思熟虑就提出的，还可能是希望我们的系统兼备其它系统的功能。
对于有价值的需求，应充分肯定用户的修改意见，在进行必要的分析后，与公司内部相关部门沟通，采取相应的产品升级或其它相应措施，并通过销售人员尽力做好后期的铺垫，引导用户以长期合作的视点考虑这类需求，在后期的系统中满足其要求。
对于未经过深思熟虑的修改要求，应引导客户理智分析这类需求是不是必要的、非改不可的，力争以现有功能满足其要求。
而对于用户希望兼备其它系统功能的需求，应站在系统规划的高度上引导客户，建议其采购我方对应的专业解决方案，或寻求其它厂商的对口解决方案。
42如何处理合同范围内的修改要求？
在试运行期间客户反馈的问题，确认是合同范围内的，需登记到《项目试运行问题记录》，如果属于产品部分的问题，则需同时登记到《产品实施问题记录》并反馈给产品实施总监，产品实施总监对问题进行分析，如果属于产品自身原因导致的问题，则提交产品部修改，产品部修改完成后，提交给产品实施总监，实施总监再提交给实施部进行更新；如果是其它原因，则将相应情况反馈给实施部。
43对于试运行阶段由实施部进行修改的内容，处理流程是怎样的？
按照实施部项目管理制度，项目试运行阶段流程如下
44如何处理试运行时发现的系统性能与效率类问题？
企业用户的数据量巨大，这在我们的系统测试过程中是很难完全模拟的，对于此类问题我们应该做好充分的思想准备。
对于此类问题，一般可通过改进程序算法、改进数据库存取逻辑、统计结果预处理等手段加以解决。
由于在需求调研阶段一般已经向用户明确定义好系统运行的硬件要求，因而在处理性能与效率类问题时，不到万不得已，绝不可建议用户升级硬件配置。
45如何交付修改内容？
试运行期间修改的内容一般需制作成补丁包，补丁包内含有修改或新增的程序文件、自动应用补丁的dos批处理或unix/linux脚本文件以及补丁的使用说明。
补丁应经过系统测试后方能交付。
视补丁包的体积大小，可采用邮件交付或刻录光盘交付的方式。
46公司制度中关于试运行阶段的程序和文件有哪些？
试运行阶段需参照的制度包括：
《项目实施与维护规程》、《产品实施配合规范》
试运行阶段应记录的文件包括：
《项目试运行问题记录》、《产品实施问题记录》、《项目需求变更记录》
47试运行阶段在为人处
升级会员 