外企项目管理个人经验总结.docx
《外企项目管理个人经验总结.docx》由会员分享，可在线阅读，更多相关《外企项目管理个人经验总结.docx（23页珍藏版）》请在冰豆网上搜索。
外企项目管理个人经验总结
1、进度管理1~12
2、外订货管理13~16
3、质量管理17~21
4、人员管理22~23
5、事件管理24~25
6、报价26~30
7、对用户31~35
8、置换其他厂家的终端系统时36~36
9、项目混乱时37~40
10、事故处理41~43
11、其它44~50
进度管理
题目
以实物检验进度
解说：
仅凭数字检查进度很难发现问题的本质，因此还要结合实物检查。
无论是新手还是有经验者，对于初次参加其项目及以前没有一块工作过的人都必须检查他们实际完成的文档，确认其内容，以此方式检验进度。
仅凭完成的文档页数检查进度往往会只流于表面形式而忽视了实质内容，从而造成下一阶段的返工。
事例：
对中间阶段文档的评议也要检验，为确保记述内容等的中间质量，须由第三者认真检查。
进度管理
题目
设定客观数量基准值去检查进度
解说：
进度管理要尽量消除主观看法的表现形式和暧昧的数字。
要用客观能够把握的数量化表现是很重要的。
因此，要使各工程的作业数字化，明确各工程的进度基准。
要周期地用各工程的产物予定数与实际完成数检查进度。
（1）根据各工程中的产物（文档页数和PCL件数）的予定完成数及所须日数和现在的实际完成数，以数量方式检查进度。
（2）想了解进度时，也要指示下级用数量化报告。
（○工程?
%（实际完成数/予定数）
△延迟日期）
事例：
在分散开发等相互开发交流不充分的环境中，如果在项目的进度基准不明确的情况下检查进度，有时会出现外订货厂家的领导根据过去作过的项目的经验自己随便判断而进行报告的情况，而且，听取报告方的管理者也往往会由于繁忙而不加调查，随便作出“可以”的判断。
在上述这样想法各异的情况下，有时会发生直到限期之前，才发现把文档完成期误认为是研讨完成期，而造成给用户增添很多麻烦的大失败结果。
进度管理
题目
要明确地指示作业成果物
解说：
要用书面（检测表）化具体地定义各工程的成果物。
越是大规模的项目，越需要更多的有不同经验和想法的人员参与。
为使这些参与者统一于同一方向目标，需使各作业紧密衔接，使各作业工程的成果具体地书面（检测表）化，始终以此方式进行管理。
特别是对于开始的成果物，要全体成员都参加评议研讨，这样更有利于统一方向和目标。
事例：
虽然负责人向各承担者指示了各文档的制作基准，但因未规定详细内容，描述程度等细节，因此作出来的文档会因承担者的水平差别而各不相同。
由于是手写文档，如果要提高到统一水平，必定要花费大量的人力和时间而大大的延误工期，因此就那样原封不动地用于下期工程，最终造成程序接口不良频繁发生的结果。
进度管理
题目
设立定期收集情报机构
解说：
设立项目负责人提供进度和存在问题等情报的机构，每个工程段落常有误期的情况。
因此，每月的工程会上要提供正确数据，特别是即使在上级不检查的时候，承担者也必须提供正确的数据。
因此要重点在解决使用可定量地表示进度报告中的报告数值的格式化报告用纸，灵活充分的利用自动收集数据的支援系统等方面下功夫。
另外，在体制上亦需尽早地指派一个总体管理者，有利地推进情报收集工作。
事例：
如果只是要求工程的每个段落提出进度情报，那么，越是进度慢的组，即使检查，也越是难以提供出数据，结果是当明白了实情时已为时已晚，为挽救此局面需要花费大量人力和时间。
进度管理
题目
力求自主管理
解说：
不是把管理强加于作业者，而是要激发作业者的工作热情，使其积极主动地参与管理。
因此，进度管理不是以来自上面的检查形式，而是以来自于作业者的报告形式为主的。
事例：
为贯彻进度管理，项目负责人虽时常向各作业承担者发出指示，进行检查，而各承担者在多次的反复过程中，形成了老调重弹的思想，从而使报告流于形式，而难于发现真正的问题。
进度管理
题目
中途不得全面改动已决定了的日程表
解说：
日程表一经决定，则不得中途轻易地全面改动，而只能是通过修改补充使其使用到最后。
（如全面改动，就看不见全过程，抓不住本质问题）
事例：
在进度会上，副组长说：
“规格制定晚了三周，所以要更改日程计划，小日程计划表不变”，与会者没有追究延误的原因。
在下个月的进度会上，副组长又和前个月一样作了[规格作成晚了]的报告，此时才开始研究延误原因及措施，但为时已晚，延误了该功能的正式使用。
因为每次进度会上都全面更改日程计划。
所以看不见全过程，抓不住本质问题。
进度管理
题目
作业日程中别忘了安排评议时间
解说：
评议讨论时间要安排在日程表上。
无论哪个工程都需要评审讨论，但日程表上常会遗漏此项，从而易于导致作业分配，必要要因数上的差错。
例如：
文档制作日程表上的实日数是10天，而实际上制作是7天，审议讨论是2天，评审后的修改是1天，因此实际作业天数比日程表上的要少的多。
事例：
回答向用户提供资料的期限时，往往只考虑资料制作日数而忘了将与内部有关部门的评审日数估算进去。
因迫于期限，未与公司的有关部门商讨就将资料提供给了用户。
事后，有关部门对资料内容提出了不同的意见，只好重新讨论，给用户增加了麻烦。
进度管理
题目
追究延误的根本原因
解说：
在进度会上听取解决进度慢的对策时，常常会作出解决了的表面原因，即可赶上进度的宽厚判断。
此时，管理者应进一步追问为什么采取了这样的对策就能解决问题？
这比以前的做法有哪些改进？
等根本原因。
事例：
以进度慢是因为人手不够为理由而大量增员（新手），相反会因为作业差错返工量增加而使项目混乱不堪。
进度管理
题目
明确对策重于工程延误的理由申诉
解说：
不要听工期延误理由的申诉。
重要的是要使其明确打算采取什么措施挽回延误？
无论听取多少延误的理由也不能使工程赶上去，反而会造成相互推卸责任，士气不振，破坏为达到目标的统一意志。
通常，应让其明确“挽回工期的方针措施”。
即使在延误的理由中含有本质的问题，也要让其拿出克服那个问题的方案。
事例：
由于顾客的规格定不下来，程序设计工程无法前进而大大地延误了工期的情况也不少。
此情况下，系统的运转开始时间又不能变，于是不得不大幅度地压缩中间工程，给后期工程造成了不良后果。
进度管理
题目
全部工作都要日程化
解说：
如果只把程序开发工作日程化，据此分配人员的话，那么当发生了一些未想到的工作（生成，测试文件制作，工具制作等）时，人手就不够了。
要把系统开发中所需项目的所有工作都列出来排在日程中。
事例：
因环境生成未安排人员和日程，因此在进入组合测试2周前，急急忙忙地从各组拼凑人员生成了环境。
但是，由于插进了计划外的作业，推迟了各组的进度，结果使组和测试比原定的日程晚了三周。
进度管理
题目
全面洞察作业整体，明确其形象
解说：
掌握作业整体，弄清其形象可使自己心中有数，亦可提高效率。
就像一个400m地赛跑运动员，首先要使自己的跑道在头脑中形成映像，计算从始点到终点的时间，根据熟练程度可得出接近实际跑步时间的值。
即只有牢牢地把握自己的步速，把自己的力量合理地分配给整个的400m，才能够跑得更快。
系统建设的SE作业也是如此。
事例：
随着系统开发作业的进展，每当发生了未预料的作业时，就要分配作业人员。
可是，当发生了紧急作业时，已无人员可分配，只好由组长自己承担而使组长不能全面地掌握项目整体的情况。
进度管理
题目
信口开河和根据主观愿望的推测是技术人员的大敌
解说：
因过于艰苦，便把根据主观愿望的推测作为预测和前提而造成了欺骗的结果。
对于技术人员来说，真实第一。
要时常作出客观的判断。
事例：
对顾客提出的规格变更要求总是给以暧昧的回答，顾客便以为技术问题已解决，理解了他们的更改要求。
在某一次与顾客共同商讨的进度会议上谈到了有关作业的进展时说明了在技术上无法实现，顾客认为这是欺骗行为，怒不可遏。
外订货管理
题目
要进行作业中途管理
解说：
对于外订货的进展情况不能放任不管，中途要经常检查，把握生产情况是很重要的。
只在订货时提出一些要求，然后就放任不管是不行的，重要的环节是适时地检查生产的进展方式，成果物等，一旦发现错误就及时向正确方向引导。
事例：
请外厂编制程序时，订货方说“全拜托你们了”，中途，接受订货方说“工程正在按计划进行，请放心”。
于是就放松了检查，结果，作好的产品不能按原来的要求进行，这种情况是常有的。
外订货管理
题目
要培养接受订货负责人
解说：
在接受订货者中培养一个负责人，让他制定方针政策，在防止或挽回工期延误方面下功夫。
事例：
只解释工程延误的理由，没有及时拿出如何挽回的方案，因此进度越来越慢。
〈防止再次发生的对策〉
（1）不要盲目依赖对方…仔细观察接受订货人及其公司，如认准可信赖，则完全交托给他们，如无把握，就培养一个负责人。
有了负责人下期工程就可放心的委托他了。
（2）防止工程延期…不要听对方一说“不行”就放弃了。
先从最基本做起，然后再寻找合适的时机实现附带要求。
外订货管理
题目
要书面明确接受订货方的责任范围（作业范围）
解说：
如不用书面明确接受订货方的责任范围（作业范围），以后会发生扯皮纠纷。
（特别是在质量，交货期方面要格外注意）
事例：
如不将作业范围向对方明文化，往往会在接近交货期时发现产品质量问题很多，达不到品质标准。
于是便要求对方提高质量，达到交货标准，而对方却说他们尽到了自己的责任，于是两方意见分歧，各不相让。
结果是虽然请对方采取了措施，但此后双方的关系却非常紧张。
外订货管理
题目
对于初次接受订货厂的生产情况要及早检查
解说：
初次接受订货的厂家即使在书面上完全同意订货方的条件，但因是初次交往，心中无数，因此一开始就要检查其生产情况，如发现问题，及时给予改进的指导。
事例：
对于初次打交道的接活厂方在书面上提出了要求后由于繁忙等原因而没有检查生产情况，结果在交货后的测试中问题很多，为解决这些问题而投入了大量的人力。
质量管理
题目
根据重要度，影响性，作业量决定提高质量的优先顺序
解说：
当有好几个质量问题较多的程序时，全部同时着手修改是较困难的，要先从重要度高的，影响大的项目开始做起。
当有好几个质量问题较多的程序时，要想同时全部提高质量在体制上是很难做到的，同时效果也不会太好。
为什么这么说呢？
如果在体制上能够做到的话，就会防患于未然了，一般的人员是不会如此富裕的。
在人手不富裕的情况下要同时修改几个程序，提高其质量，其结果只能是让其程序作者本人重新检查。
要提高程序质量，至少必须由期程序编制者意外的人用不同的眼光，思路去审查修改才行，否则达不到预期效果。
因此，需投入有一定经验的人进行重点的检查修改。
事例：
如想全部修改质量差的程序，往往会影响计划，大大推迟整个系统工程，程序修改半途而废，造成使所有程序都不能运行的严重后果。
质量管理
题目
对程序挪用时的不良管理要作明确的规程化
解说：
挪用程序时，对于在原处和挪用处发生的不良，双方都需要采取对策。
采取对策时，不要漏掉考虑B票（备选记录）体系。
程序挪用时，要用以下体系管理不良，共同对有问题的事项采取有效的对策。
有在原处发生的原处固有通常的错误
（1）
性能衰减/修改不彻底
（2）
问挪用处也有关通常的错误（3）*
性能衰减/修改不彻底（4）*
题在挪用处发生的在挪用处发生的通常的错误（5）
性能衰减/修改不彻底（6）
固体潜在不良在原处已发生（7）*
在挪用侧未发生（8）*
*适合对方，要取得修改内容的同步
图1问题的分离体系
事例：
在程序挪用处发生了不良时，轻率的判断为时挪用处的特有不良而不通知原处，使原处也发生了同样的故障。
反之，也是如此。
质量管理
题目
对必要的工程进行必要的检查，采取必要的体制
解说：
进入综合测试，检验阶段后，每天早晚都要追踪对不良的调查和对策状况。
如不进行上述工作，就不能把握系统的质量，最终成为项目混乱的原因。
定期检查，决定调查人和调查的优先顺序，防止发生混乱十分重要。
事例：
在体制够的情况下，由于工作集中于某个人而使工作效率低下，另外，一个人兼顾多项工作而造成项目混乱。
质量管理
题目
质量不好的程序要下决心返工
解说：
质量不好的程序要下决心返工。
质量不好的程序即使多次修改也不能完全排除不良（成为公司外的故障根源）。
此时，应下决心撤换程序制作者，重新编制程序，消除后患（以达到高枕无忧之目的）。
事例：
从工作量，维护等方面考虑，对质量极差的程序进行修改倒不如从头重编更合适。
质量管理
题目
杂乱无章的质量提高是无意义的，要抓住重点。
解说：
只笼统地说“要提高质量”是不会有什么效果的。
编程序的人总是认为自己的产品没有错误，应该在对不良进行了分析的基础上决定重点，然后再开始提高质量的作业。
此时，设定的观点未必都很准确，但一点点地检查，通过的部分不断地积累，质量好的程序逐渐扩大。
另外，例如，即使设定的观点不准确，也可能会在此过程中发现很多观点以外的不良。
事例：
在无周密计划的情况下去提高程序质量，其结果往往是花费的劳力多但质量不稳定。
这是因为对相同的检查没有作记录而多次重复实施同一想法所造成的。
人员管理
题目
有计划地统一项目的方向，目标
解说：
有计划地相互交流，统一方向目标。
1、定期例会
○组长会都作为定期例会每周开一次。
副组长会另外，应每月1次把大家召集
○○○○小组长会在一起沟通思想。
○○○○
○
○○○○
2、其他
除上述定期例会外，还应定期召开各种专题（工程，质量，作业等）会。
事例：
由于组长和组员的意见，步调不统一而导致返工作业多，挫伤了组员的工作积极性。
人员管理
题目
缺乏有经验人员的项目要充分利用原型开发
解说：
在几乎都是由无经验者组成的软件开发项目中应先行开发原型系统以求强化技术力量。
在都是由无经验者组成的软件开发项目中，如果一开始就开发正式软件，不但进度慢，而且不能保证质量。
因此，在有了一定的规格时，可将其基本部分抽出来作为原型系统先行开发。
这样可事先强化项目人员的技术力量，以便在开发正式软件时可以原型系统为基础，有效地利用其经验。
事例：
对于全都是无经验者的项目人员来说，一切都是新的工作，会陷于试验性错误状态，不能按计划开发出符合要求的软件产品，造成大混乱。
（结果，到期不能交出确保质量的软件产品，给用户添麻烦。
）
事件管理
题目
事件管理要由总管者日程化
解说：
对于系统开发中的问题和要研究的事项等，如果个别处理，则无法取得它们之间的同步联系而发生故障。
规格总管部门要按期将所有事件汇总在一览表中，分析判断它们的关联，排成日程表。
事例：
收到规格变更的指示后，便把采取对策的事交给了现场。
在A业务上采取了对策后便完事了，而与此相关连的主程序尚未对策，结果无法测试，只好推迟预定的运行测试。
事件管理
题目
必须用书面文件进行确认
解说：
对于和用户及公司内其他部门间的咨询、委托事项、规格变更等有关事项，如果只用口头互相传递，会由于遗忘或解释错误等而出问题。
事例：
得到用户规格变更的口头要求后，在没有相互确认有关程序的处理、测试数据的作成、文件过渡作业的分工等的情况下就擅自答应了对方。
当快到交货期检查工作时，经详细调查才发现工作量很大，已来不及变更。
报价
题目
每当报价条件变化，就要重新提交报价单
解说：
随着反复的交涉，新系统的条件在不断地改变。
如条件变了却不重新报价或虽重新报价了，但却只停留在口头上或笔记本上，那么新的报价可能会被忽视，对方只承认最初的低报价。
再次报价的结果应以正式文件提出。
事例：
某项目经程序设计、生产阶段顺利地进入了测试阶段。
当初未明确化部分的规格也确定了，由于承担人员的努力，可按时交货，在工程会上向用户提出当初的报价要增加XXKS。
因营业部门为重新报价，协作公司提出要加钱，便急忙向用户提出，结果遭到了用户的严厉拒绝。
报价
题目
明确分工
解说：
有时会有这种情况：
认为无需一开始就明确用户和公司之间、公司内部的营业、SE、设计部门之间的分工。
双方都想当然地认为对系统测试、为测试用的生成等体制及费用有重大影响的作业应由对方承担。
实际上，在交涉谈判时，因列出作业一览表，事先明确各自的分工。
事例：
批量订货时，没有讨论和决定测试环境生成作业的细节和分工。
接受APP定制作业的B公司在实施单机测试和子系统内组合测试时才发现需要用超过了他们所承担的程序变更作业范围的测试数据主文件。
于是便请求用户支援，但用户也无有经验者，因而使工程晚了三个月。
报价
题目
报价条件需得到用户认可
解说：
报价条件是报价的前提条件。
前提条件如果错了，报价的内容也就变了。
通过与用户深入地讨论报价条件，才能使最初的方案生效。
标价条件不应过多，办不到的事情应明确地告诉对方。
事例：
某项目，计划利用现用的挪用程序，预计是在几乎无改造的前提下高效率地推进作业。
但实际上几乎没有文档，而且即使有，也不能与程序对上，因此只能根据源程序作规格，实际上作的是改造规格的工作，因此作业时间由原来的3个月变成了8个月，工作也增加了十倍。
报价
题目
必须整理报价
解说：
随着规格讨论的深入，当功能规格书完成时，报价内容与最初呈示的会有很大的变化。
在用户认可功能规格书之后，或是在公司呈示后经过一定的时间规格书确认后，必须重新整理报价再次呈示。
事例：
接收系统订货时，用户和营业部门约定的内容是软件开发费XX亿日元，一套系统是XXX亿的大概数字。
但用户要求的新系统比原来的大得多，结果花费了4年的时间和超过了1万人月的工时，公司亏损了10亿日元。
报价
题目
用户的预算额
解说：
超过了用户预算额的报价肯定有麻烦，因此应弄清用户的预算。
报价时应请用户确保留有余地的预算。
只考虑竞争而低于他公司的报价往往会造成悲剧。
事例：
A项目，以单价×日元/步签约，以○○亿日元的总额承包了系统开发，但计划时和设计完了时增加了50%的规模，对方不肯付钱，吵吵闹闹，以缩减规模相争，结果决定增加的部分由用户、公司、其它软件公司三家平分。
公司失去了特有的优势，一部分子系统地承担者士气低落。
对用户
题目
对用户不要说过谦的客套话
解说：
接受订货后，用户为我们举办了[业务说明会]，此时，在道谢的客套话里禁用[收获很大]之类的过谦语。
事例：
对用户举办的业务说明会说了[学到了很多东西]的客套话。
事后，用户的负责人不满地说[那不是为公司举办的学习会。
他们能作好我们要求的系统吗？
]
作为专业集团，不要使用户感到不安。
对用户
题目
过分的热情会带来大麻烦
解说：
有时会以“尽量听取用户的要求，满足其愿望”的心情而应允了用户，但结果是实现不了，给用户造成了很大的麻烦。
必须经组织研究，认为能实现之后才能答应用户。
当出现了规格问题，需采取程序对策时，即使是一些小修小改，但件数多了作业量也很大，最后才发现应付不了。
要使项目的全体成员都清楚必须在负责人认可的情况下才能应允用户，而且要请用户不要听信个别人的承诺。
事例：
承担者以热情的心情出发轻率地应允了用户的规格变更要求，后来才明白是很大的规格变更，作业量也很大，应付不了，只好答应用户在下期的版本中支持，给产品最终用户添了大乱。
对用户
题目
要抓住关键人物
解说：
如对方不是真正的关键人物，说多少话也无用，最终结果可能完全相反，要尽早抓住有决定权的关键人物对话是至关重要的。
总是只和特定的人对话也不可取，扩大对话对象范围也能了解到用户整体的意向。
不能和无决定权，说长论短的人作最后的决定。
事例：
在与用户的规格讨论会上，以发言最多的A氏的意向为中心决定了规格，但在产品最终用户也参加了的联合会议上才得知A氏是信口开河，因而所定的规格步全面，作业需大量返工，花了三个月才弥补过来。
对用户
题目
做不到的事情要及早明确说明
解说：
轻率地答应用户的要求当时很容易，但事后做起来却非常复杂艰难，以致给用户带来麻烦。
要仔细整理用户的要求，做不到的就应明确地告诉对方，并说明理由请对方理解，虽然准备说明资料很麻烦，但比起不负责任地应允而又做不到时所发生的麻烦要轻松得多。
事例：
在讨论功能的实现方式时轻率地采用了用户的提案，结果返工作业多，推迟了工期，只好缩短用户的验收测试时间，从而导致了运行开始后小问题频繁发生，给用户天麻烦。
对用户
题目
作业内容不要超过报价范围
解说：
抱着“使使劲大概没问题”的想法轻易地答应了用户的要求，于是用户便以为“无论提什么他们都能接受”，因而不断地扩大要求，当到难以承受而拒绝时，用户便会产生不相信和不满的情绪。
要使用户充分认识到系统开发是需要时间和金钱的。
事例：
每次和用户讨论规格，都轻易地答应了一些小的规格追加和变更，当觉察到时，已大大地超过了最初的报价，于是向用户提出调整日程和削减功能，被用户拒绝，不得不增加大量人员而造成了大亏本。
置换其他厂家的终端系统时
题目
要及早确定模拟范围
解说：
置换其他厂家的终端系统时，用户往往希望在不改变原来的主机连接通信协议的情况下扩充功能。
此时如不及早明确模拟中能够达到的功能和不能达到的功能，用户的要求就会逐渐升级而使规格在所定的时间内确定不下来。
因此要能够及早地弄清通信协议上的限制。
事例：
置换A公司的终端系统时，在与用户开发的主机业务程序进行组合测试前的预备商讨会上提出了无法支持的功能。
而用户认为这是理所当然能够支持的功能（置换前是可实现的功能），因此非常生气，而且产生了不信任感。
项目混乱时
题目
要有计划地向支援者分派工作
解说：
为挽回延误的工程进度，在向支援人员分派工作时，要在考虑项目作业及其状态，支援者的业务水平，支援体制，支援时间等情况下分派任务。
事例：
项目的进度慢了很多，从其他部门调来了支援人员以图赶上工期，但因计划混乱，不但没有充分地发挥支援者的力量，反而因应付支援人员而削减了总战斗力。
项目混乱时
题目
组长不要随便插手部下的工作
解说：
为了赶进度，不得已需组长临时分担部下的一部分工作时，应在彻底弄清工作量的基础上进行。
及时估计得不准确，也应避免组长不在时而发生混乱。
事例：
工期大大延长，为挽回工期，组长亲自分担了部下的作业。
但因对作业量估计不足，结果组长成了主要的承担者而投入了主要精力，因而不能全面地掌握指导整个组的工作，从而使项目混乱。
项目混乱时
题目
问题太多时，要排好解决问题的先后顺序
解说：
当问题太多，修改的作业量大大地超过了能力时，要根据轻重缓急安排好修改的先后顺序，从最重要的开始一件件地进行确实的修改和测试，确认工作。
要防止由于对优先级别低的问题进行运用处理等措施而引发更多更大的问题。
事例：
程序的不良太多来不及采取对策，每个不良的修改都不完全，不彻底，从而引发了更多的不良结果使整个项目一直陷于[不良多发][品质恶劣]的状态中。
项目混乱时
题目
弄清事实，采取根本的对策
解说：
只根据表面现象判断时，即使采取了对策其结果也只能时加
升级会员 