外企项目管理个人经验总结.docx

外企项目管理个人经验总结.docx

《外企项目管理个人经验总结.docx》由会员分享，可在线阅读，更多相关《外企项目管理个人经验总结.docx（24页珍藏版）》请在冰豆网上搜索。

外企项目管理个人经验总结

1、进度管理

2、外订货管理

3、质量管理

4、人员管理

5、事件管理

6、报价

7、对用户

8、置换其他厂家的终端系统时

9、项目混乱时

10、事故处理

11、其它

1~12

13~16

17~21

22~23

24~25

26~30

31~35

37~40

41~43

44~50

36~36

题目

以实物检验进度

解说：

仅凭数字检查进度很难发现问题的本质，因此还要结合实物检查。

无论是新手还是有经验者，对于初次参加其项目及以前没有一块工作过的人都必须检查他们实际完成的文档，确认其内容，以此方式检验进度。

仅凭完成的文档页数检查进度往往会只流于表面形式而忽视了实质内容，从而造成下一阶段的返工。

事例：

对中间阶段文档的评议也要检验，为确保记述内容等的中间质量，须由第三者认真检查。

题目

设定客观数量基准值去检查进度

解说：

进度管理要尽量消除主观看法的表现形式和暧昧的数字。

要用客观能够把握的数量化表现是很重要的。

因此，要使各工程的作业数字化，明确各工程的进度基准。

要周期地用各工程的产物予定数与实际完成数检查进度。

（1）根据各工程中的产物（文档页数和PCL件数）的予定完成数及所须日数和现在的实际完成数，以数量方式检查进度。

（2）想了解进度时，也要指示下级用数量化报告。

（O工程？

％（实际完成数/予定数）

△延迟日期）

事例：

在分散开发等相互开发交流不充分的环境中，如果在项目的进度基准不明确的情况下检查进度，有时会出现外订货厂家的领导根据过去作过的项目的经验自己随便判断而进行报告的情况，而且，听取报告方的管理者也往往会由于繁忙而不加调查，随便作出“可以”的判断。

在上述这样想法各异的情况下，有时会发生直到限期之前，才发现把文档完成期误认为是研讨完成期，而造成给用户增添很多麻烦的大失败结果。

题目

要明确地指示作业成果物

解说：

要用书面（检测表）化具体地定义各工程的成果物。

越是大规模的项目，越需要更多的有不同经验和想法的人员参与。

为使这些参与者统一于同一方向目标，需使各作业紧密衔接，使各作业工程的成果具体地书面（检测表）化，始终以此方式进行管理。

特别是对于开始的成果物，要全体成员都参加评议研讨，这样更有利于统一方向和目标。

事例：

虽然负责人向各承担者指示了各文档的制作基准，但因未规定详细内容，描述程度等细节，因此作出来的文档会因承担者的水平差别而各不相同。

由于是手写文档，如果要提咼到统一水平，必定要花费大量的人力和时间而大大的延误工期，因此就那样原封不动地用于下期工程，最终造成程序接口不良频繁发生的结果。

题目

设立定期收集情报机构

解说：

设立项目负责人提供进度和存在问题等情报的机构，每个工程段落常有误期的情况。

因此，每月的工程会上要提供正确数据，特别是即使在上级不检查的时候，承担者也必须提供正确的数据。

因此要重点在解决使用可定量地表示进度报告中的报告数值的格式化报告用纸，灵活充分的利用自动收集数据的支援系统等方面下功夫。

另外，在体制上亦需尽早地指派一个总体管理者，有利地推进情报收集工作。

事例：

如果只是要求工程的每个段落提出进度情报，那么，越是进度慢的组，即使检查，也越是难以提供出数据，结果是当明白了实情时已为时已晚，为挽救此局面需要花费大量人力和时间。

题目

力求自主管理

解说：

不是把管理强加于作业者，而是要激发作业者的工作热情，使其积极主动地参与管理。

因此，进度管理不是以来自上面的检查形式，而是以来自于作业者的报告形式为主的。

事例：

为贯彻进度管理，项目负责人虽时常向各作业承担者发出指示，进行检查，而各承担者在多次的反复过程中，形成了老调重弹的思想，从而使报告流于形式，而难于发现真正的冋题。

题目

中途不得全面改动已决定了的日程表

解说：

日程表一经决定，则不得中途轻易地全面改动，而只能是通过修改补充使其使用到最后。

（如全面改动，就看不见全过程，抓不住本质问题）

事例：

在进度会上，副组长说：

“规格制定晚了三周，所以要更改日程计划，小日程计划表不变”，与会者没有追究延误的原因。

在下个月的进度会上，副组长又和前个月一样作了［规格作成晚了］的报告，此时才开始研究延误原因及措施，但为时已晚，延误了该功能的正式使用。

因为每次进度会上都全面更改日程计划。

所以看不见全过程，抓不住本质问题。

题目

作业日程中别忘了安排评议时间

解说：

评议讨论时间要安排在日程表上。

无论哪个工程都需要评审讨论，但日程表上常会遗漏此项，从而易于导致作业分配，必要要因数上的差错。

例如：

文档制作日程表上的实日数是10天，而实际上制作是7天，审议讨论是2天，评审后的修改是1天，因此实际作业天数比日程表上的要少的多。

事例：

回答向用户提供资料的期限时，往往只考虑资料制作日数而忘了将与内部有关部门的评审日数估算进去。

因迫于期限，未与公司的有关部门商讨就将资料提供给了用户。

事后，有关部门对资料内容提出了不同的意见，只好重新讨论，给用户增加了麻烦。

题目

追究延误的根本原因

解说：

在进度会上听取解决进度慢的对策时，常常会作出解决了的表面原因，即可赶上进度的宽厚判断。

此时，管理者应进一步追问为什么采取了这样的对策就能解决问题？

这比以前的做法有哪些改进？

等根本原因。

事例：

以进度慢是因为人手不够为理由而大量增员（新手），相反会因为作业差错返工量增加而使项目混乱不堪。

题目

明确对策重于工程延误的理由申诉

解说：

不要听工期延误理由的申诉。

重要的是要使其明确打算采取什么措施挽回延误？

无论听取多少延误的理由也不能使工程赶上去，反而会造成相互推卸责任，士气不振，破坏为达到目标的统一意志。

通常，应让其明确“挽回工期的方针措施”。

即使在延误的理由中含有本质的问题，也要让其拿出克服那个问题的方案。

事例：

由于顾客的规格定不下来，程序设计工程无法前进而大大地延误了工期的情况也不少。

此情况下，系统的运转开始时间又不能变，于是不得不大幅度地压缩中间工程，给后期工程造成了不良后果。

题目

全部工作都要日程化

解说：

如果只把程序开发工作日程化，据此分配人员的话，那么当发生了一些未想到的工作（生成，测试文件制作，工具制作等）时，人手就不够了。

要把系统开发中所需项目的所有工作都列出来排在日程中。

事例：

因环境生成未安排人员和日程，因此在进入组合测试2周前，急急忙忙地从

各组拼凑人员生成了环境。

但是，由于插进了计划外的作业，推迟了各组的进度，结果使组和测试比原定的日程晚了三周。

题目

全面洞察作业整体，明确其形象

解说：

掌握作业整体，弄清其形象可使自己心中有数，亦可提高效率。

就像一个400m地赛跑运动员，首先要使自己的跑道在头脑中形成映像，计算从始点到终点的时间，根据熟练程度可得出接近实际跑步时间的值。

即只有牢牢地把握自己的步速，把自己的力量合理地分配给整个的400m才能够跑得更快。

系统建设的SE作业也是如此。

事例：

随着系统开发作业的进展，每当发生了未预料的作业时，就要分配作业人员。

可是，当发生了紧急作业时，已无人员可分配，只好由组长自己承担而使组长不能全面地掌握项目整体的情况。

题目

信口开河和根据主观愿望的推测是技术人员的大敌

解说：

因过于艰苦，便把根据主观愿望的推测作为预测和前提而造成了欺骗的结果。

对于技术人员来说，真实第一。

要时常作出客观的判断。

事例：

对顾客提出的规格变更要求总是给以暧昧的回答，顾客便以为技术问题已解决，理解了他们的更改要求。

在某一次与顾客共同商讨的进度会议上谈到了有关作业的进展时说明了在技术上无法实现，顾客认为这是欺骗行为，怒不可遏。

题目

要进行作业中途管理

解说：

对于外订货的进展情况不能放任不管，中途要经常检查，把握生产情况是很重要的。

只在订货时提出一些要求，然后就放任不管是不行的，重要的环节是适时地检查生产的进展方式，成果物等，一旦发现错误就及时向正确方向引导。

事例：

请外厂编制程序时，订货方说“全拜托你们了”，中途，接受订货方说“工程正在按计划进行，请放心”。

于是就放松了检查，结果，作好的产品不能按原来的要求进行，这种情况是常有的。

题目

要培养接受订货负责人

解说：

在接受订货者中培养一个负责人，让他制定方针政策，在防止或挽回工期延误方面卜功夫。

事例：

只解释工程延误的理由，没有及时拿出如何挽回的方案，因此进度越来越慢。

〈防止再次发生的对策〉

（1）不要盲目依赖对方…仔细观祭接受订货人及其公司，如认准可信赖，则完全交托给他们，如无把握，就培养一个负责人。

有了负责人下期工程就可放心的委托他了。

（2）防止工程延期…不要听对方一说“不行”就放弃了。

先从最基本做起，然后再寻找合适的时机实现附带要求。

题目

要书面明确接受订货方的责任范围（作业范围）

解说：

如不用书面明确接受订货方的责任范围（作业范围），以后会发生扯皮纠纷。

（特别是在质量，交货期方面要格外注意）

事例：

如不将作业范围向对方明文化，往往会在接近交货期时发现产品质量问题很多，达不到品质标准。

于是便要求对方提高质量，达到交货标准，而对方却说他们尽到了自己的责任，于是两方意见分歧，各不相让。

结果是虽然请对方采取了措施，但此后双方的关系却非常紧张。

题目

对于初次接受订货厂的生产情况要及早检查

解说：

初次接受订货的厂家即使在书面上完全同意订货方的条件，但因是初次交往，

心中无数，因此一开始就要检查其生产情况，如发现问题，及时给予改进的指导。

事例：

对于初次打交道的接活厂方在书面上提出了要求后由于繁忙等原因而没有检查生产情况，结果在交货后的测试中问题很多，为解决这些问题而投入了大量的人力。

题目

根据重要度，影响性，作业量决定提高质量的优先顺序

解说：

当有好几个质量问题较多的程序时，全部同时着手修改是较困难的，要先从重要度咼的，影响大的项目开始做起。

当有好几个质量问题较多的程序时，要想同时全部提高质量在体制上是很难做到的，同时效果也不会太好。

为什么这么说呢？

如果在体制上能够做到的话，就会防患于未然了，一般的人员是不会如此富裕的。

在人手不富裕的情况下要同时修改几个程序，提高其质量，其结果只能是让其程序作者本人重新检查。

要提高程序质量，至少必须由期程序编制者意外的人用不同的眼光，思路去审查修改才行，否则达不到预期效果。

因此，需投入有一定经验的人进行重点的检查修改。

事例：

如想全部修改质量差的程序，往往会影响计划，大大推迟整个系统工程，程序修改半途而废，造成使所有程序都不能运行的严重后果。

题目

对程序挪用时的不良管理要作明确的规程化

解说：

挪用程序时，对于在原处和挪用处发生的不良，双方都需要采取对策。

采取对策时，不要漏掉考虑B票（备选记录）体系。

程序挪用时，要用以下体系管理不良，共同对有问题的事项采取有效的对策。

有在原处发生的一原处固有、^通常的错误

（1）

/\性能衰减/修改不彻底

（2）

问〈'挪用处也有关匸「通常的错误（3）*

\、■性能衰减/修改不彻底（4）*

题在挪用处发生的、在挪用处发生的£通常的错误（5）

\'性能衰减/修改不彻底（6）

固体潜在不良在原处已发生（7）*

'在挪用侧未发生（8）*