信息系统项目管理师考试知识点汇总.docx

信息系统项目管理师考试知识点汇总.docx

《信息系统项目管理师考试知识点汇总.docx》由会员分享，可在线阅读，更多相关《信息系统项目管理师考试知识点汇总.docx（56页珍藏版）》请在冰豆网上搜索。

信息系统项目管理师考试知识点汇总

信息系统工程项目中的硬件设备监理

我们知道三类信息系统工程项目--信息网络系统、信息资源系统与信息应用系统都需要硬件来支撑。

硬件监理在系统集成项目中占有很大比重。

简单谈谈我对几个项目中和硬件有关的几点监理体会，想到哪点就写写哪点吧，总不能让人看了直接来抢了我饭碗。

　　1、到货计划的审查要点。

重点最晚供货的设备到货时间和设备供货的时间优先级别，深入了解各设备是否需要从国外进口。

通常从国外进口货物在供货时间上更难把握，应预留足够的时间提前量。

必要时需要提供相关订单号和查询电话（或者网址）进行跟踪。

2、到货验收的审查要点。

检查货物存放场地的空间和安全保卫措施;检查货物外观包装情况，并用DV或者相机逐一取证。

重点检查装箱单与实物的一致性、设备的序列号。

3、设备的验证，关注出厂日期和保修条款，如果发现出厂日期与到货日期相关太远（每家产品会有差异），有可能是存货甚至是返修产品，应责成集成商提供足够理由和佐证材料。

大部分厂商的设备目前都可以在官方网站是查询，通过查询可以确认原厂部件。

特别要验证原厂服务是否与合同要求吻合。

　　4、设备的安装监理，着重安装人员及设备的安全措施，电源插座检查、电压检查。

安装过程是否规范，理线规范性和标签标识情况。

5、设备的配置与联调，要求先确定调试配置参数及相应的图纸，配置策略等。

先确认的呢单一设备的工作状态，再系统联调。

6、设备的测试与预验收。

先确定测试方案包括技术方案和测试计划，再按此方案中的步骤检查，确保一个同等知识要求的运维人员可以按此方案完成测试操作。

验证测试结果与预期的一致性。

　　7、设备的试运行跟踪，使用跟踪情况表，特别是问题产生原因和解决途径,要求这些内容写入运维手册的QA项.

8、使用与管理培训，先出培训教材和培训计划，最后要有培训效果检查表确认每个受训对象合格通过，培训演员对教师和环境等培训过程的反馈表。

　　9、正式验收。

。

。

。

重要是移交材料的完备性，明确售后服务详细流程。

。

。

。

。

项目经理如何学会管理自己的领导

　　好像所有的人都会赞同沟通能力最重要，可是什么是沟通能力的内涵呢?

我觉得是：

清楚地表达、传递，并引导人们的表现朝你的期望发展。

这里的“人们”包括你的领导。

在一个项目开始前和进行中，跟你的领导始终沟通无碍，是项目成功的最大保障。

怎么才能和领导沟通好呢?

　　管理你的领导

有朋友说PM有权利调配资源，不够就去要。

现实中，基本上我们的项目最大的限制除了钱就是资源，资源很多情况都被领导掌握，PM哪有随便调资源的权利?

但是领导们都常常觉得，够了啊，总之你给我搞定。

PM要学会说“不”，制定计划的时候就要否定老大们不切实际的想法，但绝对不是上去就狂喊，而是说法上要有技巧，说“目标——步骤——难点——计划——资源”，领导们会容易接受一些。

就是说：

我们的目标，是要达到什么效果，还有范围是什么;步骤是1、2、3、4，先做什么再做什么;难点是什么，哪个地方容易出错，不管是技术难点还是管理难点，PM都要考虑在内。

比如技术上大家都没有做过，就是难点，比如管理上没有某个规则等等。

因为有了这些难点和目标，我们觉得时间计划是什么（保留适当的储备）——因为要实现这个计划，我们需要什么资源。

领导们听到最后，嗯，很有道理，他就要权衡了，给你资源么，不给?

不给重新讨价还价，目标要不要改?

时间要不要延长?

范围要不要缩小?

给，给当然好了，PM要到自己的东西了。

无论是制定目标还是过程中，你需要资源的时候都可以尝试用这种方法。

虽然很多时候资源是被领导掌握，但是身为PM要记着，领导也是我们的资源，你用他的思维方式，引导他去思考。

你要学会管理你的领导。

　　向领导暴露问题

就算这些资源都要到手了，我们就是承诺项目没问题吗?

当然不是啦。

领导们还是聪明而有经验的，他们都知道项目一定会有问题，他们不期望不出问题（他们基本都认为，不出问题的项目一定是有虚假信息，项目不可能不出问题），他们只是希望可控（问题可以被解决，知道对现有质量、进度、资源、预算的影响）。

　　所以PM千万不要心虚说，因为前面我要了这个那个，后面我就不可以出问题了，有问题就隐瞒。

恰恰相反，PM就是要在过程中暴露问题。

你说出来了，领导就是再不开心也知道解决问题最重要，所以他就会帮你解决问题，你就多了一个强有力的资源了。

暴露问题是要说：

问题是什么——为什么会出——如果不解决，对目标、范围、进度、质量、客户满意度、预算影响是什么——你觉得解决方案是什么?

——各自对上面6个维度的影响是什么，各自都有什么局限和好处?

——领导决策。

　　如果你也没解决方案（这样不算好的PM，但是没辙的时候也是会有的），你就做前面两步好了。

问老板，怎么办啊?

但无论是谁给的解决方案，也无论这个方案是什么，你最后都要向你的领导（当然包括你的所有利益相关者）说清楚，这样一个变更对目标、范围、进度、质量、客户满意度、预算的影响是什么。

让你的领导感觉，虽然会出问题，但是你至少让问题的影响可控了。

他在下一个问题出来前可以睡觉了。

　　什么时候汇报?

　　虽然我认为很少有PM会犯这个错误，但觉得还是说一说比较好。

周报是干嘛的?

其实很多时候虽然是一份常规的记录资料或文档，但最大的作用，我认为是保持所有人对项目的关注度。

让一些更大的老板、边缘的团队成员、边缘的利益相关者保持对项目的关注度;让核心团队成员有成就感：

我们做了那么多，还报告领导了。

我认为，周报或者叫周期性报告不是解决问题的，只是陈述性、总结性的。

　　一旦有了问题要马上汇报!

当然还要考虑上级领导的风格（他是事无巨细关注型还是抓大放小型）和PM的权利（什么样的问题有决策权）。

但一旦有了PM搞不定的问题，要马上汇报。

　　出了问题要随时解决、即时解决。

你想周期性报告一周一次?

一月一次?

那时候黄花菜都凉了。

所以马上汇报。

不要怕你的领导，因为耽误了时间更可怕。

项目经理如何处理好与不同类型客户之间的关系

　　作为项目经理，如何处理好与客户之间的关系非常重要。

但是究竟如何处理客户关系呢?

客户的人员都有哪些类型?

不同类型的客户的应对是否都一样呢?

下面我们来看看在日常工作中经常遇到的客户类型，应该如何处理跟他的关系。

权威决策型：

这类客户往往具有权威的技术、业务和管理能力，对于事情本身具有决策权。

　　应对策略：

正面应对，以技术服人。

　　典型决策者：

具有商务上的决策权，但是不是业务和技术的专家。

应对策略：

用通俗的语言表达技术和业务，尽量减缓正式的冲突，下面处理协调，效果会更好。

技术专家型：

只关心技术实现、细节和技术可行性。

　　应对策略：

直接正面应对，解释技术上的可行性和解决方案。

　　糊涂管理型：

是甲方的管理者，具有一定的决策权和影响力，但是对项目管理不懂装懂，不时干预项目的事情，有时是麻烦的制造者。

应对策略：

客气地拒绝，一定掌握主动权，一旦他掌握主动权，他会引导你项目的失败。

　　和稀泥型：

不承担责任，但也不得罪任何一方，不解决问题，但也不制造麻烦，属于老好人型。

　　应对策略：

别指望解决你的问题，可以利用大事化小，保持和气。

虚伪专家型：

技术和业务有一定了解但是都不是很深；多为新提拨的业务和技术骨干或多年被“埋没”的人才，喜欢卖弄点技术能力，缺少大局观。

应对策略：

或者成为利用的对象，或者让其远离你的项目，敬而远之。

从大局考虑，使其空，从技术的纵深考虑，使其服。

　　小人型：

阴奉阳维，表面一套背后一套，报复。

得志小人更是难缠。

　　应对策略：

不让其染指项目是最好的办法。

项目经理人与项目成员的实战指南

　　在一个团队中，作为一名团队领导，将：

　　1）避免团队目标向政治问题妥协

　　2）向团队目标显示个人承诺

　　3）不用太多优先级的事物冲淡团队的工作

　　4）公正、公平的对待团队成员

　　5）愿意面对和解决与团队成员不良表现有关的问题

6）对来自员工的新思维和新信息采取开放的态度

　　作为团队成员，要将：

　　1）展示对个人角色和责任的真正理解

　　2）展示目标和以事实为基础的判断

　　3）和其他团队成员有效地合作

4）使团队目标优先个人目标

　　5）展示投身于任何项目成功所需的努力的愿望

　　6）愿意分享信息、感受和产生适当的反馈

　　7）当其他成员需要时给予适当的帮助

8）展示对自己的高标准要求

　　9）支持团队决策

　　10）以为团队的成功而奋斗的方式体现带头作用

　　11）对别人的反馈做出积极的反应

项目接近尾声时不能忽视的10件事

对于你的组织规模，你可以把项目管理视为一项偶尔的实践或者可以拥有一个复杂的PMO。

不论那种情况，你可能通过典型的项目初始、精化和构建过程。

但是到了项目终结的时候，很多项目经理只讨论短期的终点线。

最后的步骤处理不好会给行动增加混乱并且可能导致客户不满、员工不悦，并把项目拖得比所需时间更长。

　　这里是一些你需要在达到你下一个项目的终点时要考虑的事情。

其中有些项目是纯管理的，但其中很多能帮助你进一步保证你的项目能够成功。

　　一、最终测试

　　测试会耗费人员，而我们很多人都不愿意去做——特别是做过几轮之后。

我见过大量的四到六个月的项目有一两天的计划去测试。

没有安排适当数量测试的项目通常在实施的最初几周内因问题而结束。

这里不要走捷径和将测试的重要性减至最小；否则，你会为痛苦的进展过程而承担额外的风险。

　　二、最终培训

　　用户？

谁关心用户？

好了，很多项目都为了他们的利益而做，所以确信把你所有的测试资料完成并移交。

这个不做好最有可能体现在发怒的客户半夜三更打来的愤怒的电话上。

　　三、确认交付物

　　你检查了所有的箱子并清理了收件箱，而且你想真地结束了。

但你的客户怎么想？

安排时间和你的客户检查所有的交付物并且确认他们已经得到满足了。

有些情况下，可能有一些特殊问题到你计划终止日期时尚未解决。

在你项目的早些时候，应该有一份协议来决定如果发生这样的情况会如何影响你的结束日期。

　　四、获得项目签字

　　当你获得所有交付物都已满足的认可以后，请求在项目文档上做一个正式的签字。

这样做帮助确保所有人都认可项目状态。

因为这个签字通常标志着项目的正式结束，注意不要让你的客户感觉签字的压力。

如果他们在不明所以的情况下做了，你可能会在日后出现问题的时候最终得到一个不满意的客户。

　　五、解散团队

　　现在项目完成了，你的团队何去何从？

基于你的组织，他们可能被送回一个开发池或者去做业务。

或者他们需要在企业内部为自己发起一些工作。

不管是什么，你要保证花点时间和他们在一起，并且设置一个明确的不再需要他们的服务的最后日期。

同时不要忘了你可能需要完成一些需要加入他们档案的业绩审核文档。

　　六、分析实际与计划的对比

　　资源——你是否真正摆脱了10周只有一个开发者/测试员，或者你需要去争夺并得到更多的人员？

你为你的商业伙伴安排的时间量怎么样？

明白你有多接近这些目标能帮助你为下一个项目更好地分配资源，并且在下一个项目来临时为它设定更切实的预期。

　　预算——项目要花费多少？

你是达到预算、未达到预算、超出预算？

坐下来弄明白这些基本问题的答案会给你一些对任何项目临界区域的洞察力。

　　七、存档文档

　　任何项目期间，好像我们都创建大量的文档。

其范围可能从范围文档和项目计划到合同和会议纪要。

不管是什么，在你结束时根据企业的保留策略应该有地方保存它们。

当两年后你的电话铃响起来并且有人要你解释项目期间你所做的一个决定的背后原理时，你将会很高兴。

　　八、确保合同终止

　　一个项目不常有自己的预算。

你可能还有硬件、软件或专业服务的合同。

在你完成以后，确认检查合同的所有项目都满足了，向供应商索要发票并把它们提交给AP，并且关闭任何相关的财务帐目，如果需要的话。

　　九、举行一个验尸会议

　　什么类型的风险你识别并减轻了？

你想用以确保下次再做的什么真的变好了？

和所有的项目