项目成果论文范文
前言：我们精心挑选了数篇优质项目成果论文文章，供您阅读参考。期待这些文章能为您带来启发，助您在写作的道路上更上一层楼。
第1篇
1.作人的姿态
作人似乎跟商务谈判不太有关系，很多技术人员相信PM需要的是本事，是如何做好一个项目，而不是会搞好关系弄的四平八稳的人。随着PM在中国的悄悄兴起，越来越多的
的PM开始在老总的授意下参与商务谈判，和销售们一起打单子，这就比较实在的需要PM们去揣摩客户的心理。揣摩客户心理需要有多方面的知识，需要深度和广度，然而，最重要的仍然是作人。如何放下架子，降低作人的姿态，对从技术人员转型的PM们来说，是至关重要的。
降低作人的姿态需要从多个方面去实施，最主要应该记住：人不可貌相，更不可以地位衡量。很多公司为了保持公司形象，会统一叫员工打扮的好看一点，看起来象个白领的样子。然而，老板多半是没有约束的。中国改革开放才二十年，很多有钱的老板实业家文化层次都不高，往往是当大学生们只会把屁股坐在板凳上肆意挥霍父母辛苦积攒的财富时，他们已经在各地奔波，积累丰富的商业经验并对金钱，人生和社会的本质有了充分的认识，形成了自己稳定的思维框架。这些人，很多都是穿着旧旧的衣服，戴着破破的手表，说话的时候经常会带上三字经，钻进上海的人堆里，搞不好你会把他当成民工。因为到他们所处的社会地位，已经不需要任何华丽的外表来衬托自己的身份，他们有的是底气。对PM来说，这是个非常危险的挑战。虽然说项目在初期有意向时会对对方的人事和关键人物有一定的了解，然而大项目里能说的上话的人太多了。上海人最瞧不起的就是土气，很多人谈项目的时候看到民工或很俗气的表现不免会皱皱眉头，往往在皱眉头的时候就失去了项目，也就是失去了市场和金钱。PM必须作到能与每一个层次的人交谈，尤其是看起来比自己层次要低的群体，哪怕是公司里扫地的阿姨。只有作到谦虚谨慎，不摆架子，尊重别人，才会得到别人的尊重，才有机会赢得项目。鼻子比眼睛高的人只会把自己的鼻子撞扁。
2.丰富的知识面
光尊重别人还不足以赢得项目，准确的说是赢得对方关键人物的信赖。PM一般用不着陪客户喝酒吃饭，那是销售们的事情，但是PM和客户讨论问题可能是最多的。讨论问题的时候就是机会，如何投其所好，是一大关键。金钱与美女依然是常规的敲门砖，然而这种傻瓜也知道的办法人人都会去做。老板的关系也只是一个方面，如今的大老板，哪个没有关系？同等条件下PM凭什么去胜过别人一筹？
我一个朋友（PM）打一个单子时，发现对方对什么都不太感兴趣，费了很大力气也找不到突破口。对方这个人非常顺利，金钱地位美女样样不缺。他花了好多天和对方交谈，以自己的博学逐渐取得了对方的信任。后来他隐约发现对方对数学和天文学的发展史有所涉猎，如获至宝，回家花一个通宵的时间在网络上搜索相关资料。第二天他根本不谈项目的事情，只跟对方大谈特谈哥白尼，布鲁诺，伽利略这些人的生平，整整吹了一天。对方点头如捣蒜泥，态度和热情都来个一百八十度转弯，隔天他就拿到了单子。这是个经典的战例，谁能事先想到哥白尼会来帮助IT的人赚钱？这个PM靠的就是博学和由博学引申出的敏锐的感觉抓住了机会，让客户产生共鸣。客户感觉他层次也很高，而且和自己有共通之处，信任度大大增强，把项目交给他放心。如今这种例子在商务谈判中已经屡见不鲜了。对PM来说，并不要求在各个方面都很精通，那是不可能的事情，只要PM对一些流行的话题和天文地理历史各方面的知识有个大概的了解，在需要的时候能尽快的掌握，才有机会创造机遇和把握机遇。
3.强大的沟通能力
胸中有万千墨水却不知如何表达其实是比较少见的，但并非绝对没有。每个人的人生轨迹都有所不同，思维受环境的影响也各有差异。包括象我们目前这个班级里的一些未来的MSE们，一定有比较内向或者不太爱表达自己观点的人，这些人比较被动，往往很难承担起谈判的重任。从今天开始，这类人就必须重新学习如何说话，如何大声的争论。沟通，并不仅仅是大声说话，而是在表达自己观点的同时发现问题并综合整理加以解决。除此之外，沟通的能力与社会经验息息相关，与PM的见识联系紧密。在日常生活中，PM就要多留心，多思考，当别人想到某个层次的时候要争取比别人考虑的更深。当然，也有一些不够踏实的朋友把沟通和吹牛当成了完全的一回事情，在和客户交流的时候口若悬河的说一些不着边际的话。这种人，碰到不懂，不太认真或者好奇心强的客户是有一定市场的；而有水平，负责任的客户往往会觉得这种人不可靠，一般不会把单子交给他。PM需要把握好这个度，吹是肯定要吹的，只是吹牛的时候一定要有基础的去吹，对从来没涉及过的领域或者根本不懂的东西轻易不要发表意见，挑选自己熟悉的方向合理的进行发挥，适当的留上一两手，给对方高深莫测的感觉，效果最好。
4.优秀的售前团队
这个团队一般是由总经理发起并组建的，通常不指定PMP，对团队的成员如SALES，PM，SA，ENGINEER们的团队合作提出了比较高的要求。一般公司在接下一个单子进行到一定程度的时候，PM往往会尴尬的发现协议上销售代表们对客户的一些承诺是几乎做不到或者根本做不到的事情。这种情况非常多，销售的任务是拿下单子，我听到的销售们说的最多的就是"没问题"或者"NOPROBLEM"，但是当我听到客户的要求和销售的回答时我总是心惊肉跳，很不自然。销售是非常辛苦的，为了建立客户关系，尤其是空白的市场是很不容易的，往往为了一个单子会牺牲非常多。在这种情况下，和销售进行协调自然而然的又落到了PM的头上。在销售和客户做承诺之前，PM要主动的跟销售交流，提供粗略的总体设计框架和技术难关以及能考虑出的工作量，而不是等出了问题再被动和销售在老板面前互相推委责任。在组建团队的时候，PM要根据团队里每个人的素质和任务进行因人置宜的信息传递。优秀的售前团队合作是接单的重要保障。
在商务谈判的实际操作中，存在着各式各样的问题，PM的职责和要求绝非以上几点所能描述详尽。根据环境，政策，人文，关系等各方面的不同情况，PM的不同成长经历，每个PM最终都会建立自己对商务谈判的看法和经验。但是有一点的职责和要求绝非以上几点所能描述详尽。根据环境，政策，人文，关系等各方面的不同情况，PM的不同成长经历，每个PM最终都会建立自己对商务谈判的看法和经验。但是有一点可以肯定，这是PM成为PM的第一道关，也是最重要的一关。接不到单子，PM将失去去存在的意义。与销售有所不同，PM在该阶段的任务除了接单，还要尽可能的搜集客户关键人物的资料并与对方各个阶层的负责人建立良好的客户关系，以便在项目实施时充分调动资源。
二.启动阶段
1.项目的一些基本概念
项目三要素有多种版本，各不相同。实际操作中多分为范围，成本与进度，其中最重要的莫过于范围。我们把项目最终生成并提交给用户的产品和文档统称为递交件。谈判的时候一定要确立递交件的标准和要求，也就是范围。尽管商战的时候不可避免的客户会不断提高标准和要求，而承诺的款项却不会有一分钱的增加。但是这个标准对每个公司来说都有一个底线，一旦超过了这个底线，那项目就肯定是亏的。除非是为了二期有利可图或者是为了搞好关系，否则范围超过底线的时候情愿不做，再厉害的PM在这种情况下也是无能为力。建立范围需要的就是PM的多年的实战经验，在大大小小的项目中用血泪换来的一些体会。在这个时候，很能体现PM与技术人员的区别。成本就是客户答应付的款项，与我们的投入成本并不是一回事情。进度就不用多描述了。
项目如何成功？也有一些关键的因素。个人的理解也不尽相同，通常包括以下几个方面：界定工作目标及工作任务；老板或高层的支持；优秀的PM和开发团队；充足的资源；良好的沟通；对客户的积极反应以及适当的监控和反馈。这里要注意的就是资源和高层的支持。一个上规模的公司总是同时会有很多项目，可是再大规模的公司资源也不足以保证每个项目都能组建最合适的开发队伍或拥有最好的环境。这时候各个团队或者部门之间不可避免的会发生资源争夺战，摩擦再所难免。这时候对PM的作人再次提出挑战。除了高层对PM项目的重视程度，如果PM平时在公司与同事相处的好往往能使很多别人看起来很棘手的问题迎刃而解。相反，一个不会作人的PM由于人缘差，即使高层强压别的部门或团队配合，别人也会能拖就拖，延缓项目的进度和质量。有时候，这种内耗对项目和PM来说是毁灭性的。对客户的积极反应也比较关键。一般来说PM已经被项目里大大小小的事情搞的筋疲力尽，要PM去主动要求客户配合是很吃力的事情。然而，这个时候，越是困难，越是觉得累，越是要去主动。客户往往也不是特别的积极，主动与客户联系沟通和测试能及早发现问题。从风险控制的角度来说，问题发现的越早，风险越小，损失也就越小。积极的态度可以带动客户的积极性，在项目完工的时候，客户对你的感激往往是难以用语言描述的，这对以后接单或者做二期三期会打下良好的基础。因为在和别的新客户谈判的时候，新客户自然会找你的老客户了解情况，这时老客户随意的一句话顶的上你很费心的十句。
项目具有商业行为的几个重要特征，有消费源，有参与者，有成功关键因素，有财务目标，有风险。
2.启动阶段的主要任务
根据PMI的解释，接单之后项目自然转入启动阶段。启动阶段PM的主要任务是率领总体架构设计师和系统分析员收集尽可能详细的数据，确立尽可能详细的需求，进一步确立详细的项目范围，预估资源，确立其他方案并获得进入下一阶段的批准。在这个阶段，随着需求分析的深入，PM也开始在公司内部进行人员挑选和资源争夺，着手组建自己的项目团队。项目即将进入计划阶段。
在收集完数据之后，PM要和客户开始明确项目的大小，成本，规格，期限等重要特征并将其写入合同文本，同时准备内部的包括预算，衡量标准等文档，建立项目的评估标准。接下来就是需求分析。由于专业的原因，我们这里仅讨论软件工程项目的需求分析（以下简称需求分析）。
需求分析的主要参与人员有PM，总体架构设计师，系统分析员，熟悉业务流程的客户。PM统领的团队这时候还不是真正的开发团队，我们叫做前期团队。随着需求分析的逐步深入，新的团队成员不断加入，启动阶段结束的时候正式的团队将建立。对一个已经启动的项目来说，需求分析直接决定了项目的成功与失败。最初的需求体现在客户的工作说明书或招标文件及附件上。这种需求一般比较含糊，无法体现客户真正的需求。前期团队要根据自己的经验和客户沟通并引导客户进入正轨。有时候客户会很不讲道理或者思路僵化，就要求按照他的思维去定一些明显错误的需求。这个时候团队成员要耐心和客户举事实，谈经验，讲道理，用图形或模型等直观的方式将需求描述出来，比如常见的数据流图等。所以说，争论再所难免，客户有时候会吹胡子瞪眼睛拍桌子甚至会说"这个东西不要你们做了"之类的话。PM此时除了要亲身参与需求分析综合整理文档之外，还要处理好团队成员与客户的关系，确保关系不会恶化到无法收拾的地步。只要PM尽力约束团队中的成员，这个度还是很容易控制的。
对快速开发和叠代开发来说，需求和实现往往是同步进行，开发速度快是一大优势。对有相同或类似模式的小项目来说采用快速开发或叠代开发是很合算的做法，时下流行的极限编程就是针对这方面建立的思维模式。然而，大中型项目中有太多不一样的需求和模块。如果不是因为项目有差异，那么市场上就只有产品而没有项目了。所以，大中型项目的需求要认真仔细的去做。我们要讨论一个问题，究竟应该在需求分析和总体设计上花费多少时间？我们熟悉的瀑布开发模式基本上分需求分析，总体设计，软件开发，测试等几个阶段，然而究竟应该在前两个阶段上花多少时间却没有定论。实际项目操作的例子表明，分析设计的时间越长，需求设计做的越详细，测试的时间就越短，返工率越低，风险也越小，成本越容易得到控制。而需求分析和总体设计没有做好就急忙上马进行开发的项目在项目初期进展顺利的时候问题不大，到了项目后期和测试阶段一些潜伏期比较长但是破坏作用比较大的问题就会凸显出来，造成返工，延长测试时间。所以与其把问题堆积到紧张的项目后期，不如把时间多花点到需求分析和总体设计上。基础夯实了，金字塔就容易造了。
在日本公司打工的程序员们可能都知道，小日本的软件规范非常厉害，他们花在需求分析和总体设计上的时间通常在40%到50%左右，远远超过国内软件项目的实施，效果也要强的多。他们总体设计的规范甚至详尽到某个过程该如何判断，确立什么样的条件，换言之就是把什么时候该如何写(if...else)语句都帮程序员定好了。在这样的软件规范下，程序员更象是装配流水线上的工人，对一个模块或技术熟悉到一定程序就变成了完全的重复性劳动。所以在日本和欧美经常会有程序员是低级工作一说，很多人不明就里，对国内程序员也照搬，对国内的程序员来说是很不公平的。在国内，只会照抄别人代码，一点都不懂创新，凡事依靠别人，快下班就盯着表看的程序员是不少，这种人一般很难有什么前途。但是，优秀的不断进取的程序员也很多。由于国内没有象CMM这样的软件规范或者很少，所以这类优秀的程序员不少都是干着系统分析员甚至PM的活，拿着程序员的工资。这类程序员虽然在起步时会吃很多亏，而且是主动找亏吃，然而几年之后与前一种程序员的社会地位会出现明显的分化。当上进的程序员们作为PM进行商务谈判的时候，前者还在各个公司里频繁跳槽，跳来跳去都不满意。有些扯开了，回到我们的话题。日本的软件规范与CMM有惊人的相似，其中至少有35%以上都是几乎一模一样的。最近经济不景气，东京倒闭了160家软件公司，这个数字是今年6月份的，还在不断增加。这些公司纷纷抢滩上海，招收技术人员。如果去这样的公司应聘就要考虑清楚了，进去可以学到他们的规范和质量控制，可是要想从程序员成为系统分析员或PM，比登天还难。往往一个程序员进去干了好几年，对自己的那一块熟的不得了，而对隔壁同事所做的东西一窍不通。拒传华为正在尝试CMM4（华为印度研究所已经通过CMM4），对在华为工作的程序员们来说可谓福祸难料。当然，已经作到PM或QA或者热爱CODING的朋友例外。
需求分析本身也存在着时间分配的问题。第一遍需求分析花的时间会最长，分析员们在客户的各个部门之间几乎把腿都跑断，把口水说干，就是为了确立一个初期的需求模型。所有的文档将会提交给PM进行复审并签字，不合格的打回重做。反馈表随之将提交给客户，第二遍第三遍等等等等接踵而来，与客户反复讨论和磋商，反复提交文档和表格，目的只有一个，明确需求。当PM最终合并了所有文档并确立需求之后，最终生成的需求文档将提交给客户的各部门负责人签字。这些文档将作为合同的附件添加，以便在将来项目变更或者碰到重大问题时和客户扯皮的重要依据。需要说明的是，客户并非都是蛮不讲理，但是说实话，颇有无奈，国内目前的项目大多数客户为了不让自己的钱白花，经常变着法子提需求。在启动阶段明确需求并签字，无论最终情况如何，一份详尽的书面文档可以解决很多口头承诺或概念模糊的文档带来的许多问题。
详尽的需求分析有一个额外的好处就是对一些双方都很陌生或者从来无人尝试的领域将是一个决定是否进行项目的判断标准。有时候，这种大项目在签单时双方都没有绝对把握保证可以出成果，一旦在需求分析阶段发现难以逾越的技术难关，就会放弃项目。典型的例子就是NMD洲际导弹防御系统。上世纪八十年代初美国搞星球大战计划，拖跨了苏联。大家对那段历史有些含糊，很多人认为苏联人上了美国的当。其实并不完全如此，苏联人的情报机构无孔不入，并非那么容易上当受骗。实际上当时美国国防部已经开始着手NMD系统软件的需求分析，前后耗资数亿美圆，耗时两年，仅仅是做需求分析，终于发现存在着在当时技术上无法达到的高度，随后项目被放弃。
3.项目启动
项目启动要确定项目计划，与客户一起实施第一次项目审核，确认并对一些产品和服务向下包厂商下订单。这个时候的PM会忽然发现有开不完的会，一天开三到四个会议是很正常的事情。这些会议有与客户的会议，与下包厂商的，有团队的，有公司高层的。团队的会议主要是建立正式的团队，提供团队成员的角色和职责，提供绩效管理方法，向成员提供项目范围和目标。与客户的一个主要会议将是项目启动会议。在这个会议上PM会与客户确立正式的交流渠道，项目综合描述，让项目参与人员相互了解，建立以PM为核心的管理制度。还有一些零零碎碎的东西甚至包括办公场地的大小，电话多少部，所有人的联系方式等等都要在会议上确立，并做会议记录。这都是些非常琐碎的事情，听起来婆婆***，却是非常必要，缺一不可。大概就是所谓三军未动，粮草先行吧。
这时候，作为公司高层，应该向全公司发表申明，正式给PM项目经理任命书和项目授权书。这个动作虽然在别人看来有些形式主义，但是对提高PM本人的士气和责任感是有很大助力的。
三.计划阶段
1.定义结构分工结构图（WBS）
启动阶段结束后，项目进入计划阶段，也就正式进入实施。这里概念可能有些不太对头，其实是翻译的缘故，反正大家明白意思就行，不用拘泥于字面。WBS是一组要提交的项目元素，用来组织定义项目的总体范围，具体包括从工作内容，资源，成本角度考虑项目范围；建立一套系统所需要的分层工作结构；把项目分解成易于管理的几个细目，这概念有些模糊，其实跟资源管理器里分目录是一回事情。可以说，WBS是计划阶段的核心。WBS会详细的分到递交件，包括给自己人用的项目使用的过程文件，给客户用的模块和说明文档，完成每个细目的标准以及如何把这些细目的责任分配到具体的个人。WBS有缩进式和树状式，我这里也没办法画图，大家参考一些项目管理的书籍，里面有详细介绍。我整个文章只挑我觉得需要注意的地方，如非必要，对技术细节或者工具使用不做详细介绍。WBS的细目并不需要分解到同一水平，最下面的细目叫做工作包，分包的依据是个人的责任和可信度，也就是说到每个人头上的任务是否能落实，是否有把握完成；还有就是准备对项目进行控制的程度，程度越深，WBS树也就越深。由于WBS是实用性的东西，根据个人理解也不一样，所以一个项目可能会有几个正确的WBS，看PM的需要和最适合当前团队状态的进行选择。
WBS的定义还是很麻烦的。PM要召开团队进行讨论，向成员提供与项目相关的所有详细资料，并把WBS树分解到二层三层。然后要花上一段时间让成员进行头脑风暴式（BRAININGSTORM）思考，制订工作产出和相应人员的职责，记录每一个工作包的完成标准。在头脑风暴式思考时，会有很激烈的争论，PM要协调关系，调节气氛，从自己能考虑到的各个角度旁推侧敲，提示成员的思维角度和方向并加以总结。尽管很麻烦，制订WBS仍然是非常值得的。如同需求分析一样，WBS准备的越充分，编码的进度越快。
2.风险管理
既然是商业行为，那么项目的风险必然存在，相信阅读这个帖子的朋友不少人都经历过或大或小的风险。有些风险很容易解决，有些风险则大大损害利益。不论什么样的风险，能避免尽量避免，所以有必要对风险进行管理。由于风险的不可预知性，风险管理难度很大，概念也很难讲清楚，只能从一些可行的角度去分析，进行管理。
首先要识别风险。这是个难度很高的活。PM要先召开风险识别会议，这个会议面向公司，高层，跨部门的有经验的人都将参加。然后审核由项目小组生成的风险清单并与重要成员进行风险沟通，检查一些重要的风险源如WBS，成本（时间）预估，人员计划，采购管理等等。最后就要用到PM本身在以前类似项目中得到的经验教训。
识别之后要进行分析。我们可以进行粗略的量化分析（精确分析是不可能的事情）。有经验的人可以一起参加讨论，把提交出来的风险进行分类。首先按发生的可能性分，一般分成高，中，低三个级别，虽然很勉强，但是好歹也有个量化了；然后按耗去的成本分，也是高，中，低三级。我们可以把这两种类别的三个级别进行组合，碰到可能性也高，成本也高的风险就定位为不能接受。碰到这种风险只好让客户修改需求或者增加风险预留成本，否则一旦亏起来不是亏一点点，有可能赔的很厉害。高和中，中和中的搭配都是属于高风险，中和低，低和低搭配属于低，高和低搭配属于中。
针对出现的可能性，需要采取一些手段降低风险。到目前为止也没有一个定论说有绝对好的方式，只能尽其所能的避免。有几种方法可以考虑，第一种是将风险纳入项目管理计划并指定负责人，由外部人员定期检查项目风险，一旦风险发生，执行风险管理计划；第二种是保险，这种属于风险转嫁；第三种方式有点，不过最保险，就是把客户拖下水，让他们一起参与风险管理，呵呵，到时候就好说话了：）
风险管理作为项目计划之后，PM需要更新WBS，修改日程计划和更新风险管理计划。
2.启动阶段的主要任务
根据PMI的解释，接单之后项目自然转入启动阶段。启动阶段PM的主要任务是率领总体架构设计师和系统分析员收集尽可能详细的数据，确立尽可能详细的需求，进一步确立详细的项目范围，预估资源，确立其他方案并获得进入下一阶段的批准。在这个阶段，随着需求分析的深入，PM也开始在公司内部进行人员挑选和资源争夺，着手组建自己的项目团队。项目即将进入计划阶段。
在收集完数据之后，PM要和客户开始明确项目的大小，成本，规格，期限等重要特征并将其写入合同文本，同时准备内部的包括预算，衡量标准等文档，建立项目的评估标准。接下来就是需求分析。由于专业的原因，我们这里仅讨论软件工程项目的需求分析（以下简称需求分析）。
需求分析的主要参与人员有PM，总体架构设计师，系统分析员，熟悉业务流程的客户。PM统领的团队这时候还不是真正的开发团队，我们叫做前期团队。随着需求分析的逐步深入，新的团队成员不断加入，启动阶段结束的时候正式的团队将建立。对一个已经启动的项目来说，需求分析直接决定了项目的成功与失败。最初的需求体现在客户的工作说明书或招标文件及附件上。这种需求一般比较含糊，无法体现客户真正的需求。前期团队要根据自己的经验和客户沟通并引导客户进入正轨。有时候客户会很不讲道理或者思路僵化，就要求按照他的思维去定一些明显错误的需求。这个时候团队成员要耐心和客户举事实，谈经验，讲道理，用图形或模型等直观的方式将需求描述出来，比如常见的数据流图等。所以说，争论再所难免，客户有时候会吹胡子瞪眼睛拍桌子甚至会说"这个东西不要你们做了"之类的话。PM此时除了要亲身参与需求分析综合整理文档之外，还要处理好团队成员与客户的关系，确保关系不会恶化到无法收拾的地步。只要PM尽力约束团队中的成员，这个度还是很容易控制的。
对快速开发和叠代开发来说，需求和实现往往是同步进行，开发速度快是一大优势。对有相同或类似模式的小项目来说采用快速开发或叠代开发是很合算的做法，时下流行的极限编程就是针对这方面建立的思维模式。然而，大中型项目中有太多不一样的需求和模块。如果不是因为项目有差异，那么市场上就只有产品而没有项目了。所以，大中型项目的需求要认真仔细的去做。我们要讨论一个问题，究竟应该在需求分析和总体设计上花费多少时间？我们熟悉的瀑布开发模式基本上分需求分析，总体设计，软件开发，测试等几个阶段，然而究竟应该在前两个阶段上花多少时间却没有定论。实际项目操作的例子表明，分析设计的时间越长，需求设计做的越详细，测试的时间就越短，返工率越低，风险也越小，成本越容易得到控制。而需求分析和总体设计没有做好就急忙上马进行开发的项目在项目初期进展顺利的时候问题不大，到了项目后期和测试阶段一些潜伏期比较长但是破坏作用比较大的问题就会凸显出来，造成返工，延长测试时间。所以与其把问题堆积到紧张的项目后期，不如把时间多花点到需求分析和总体设计上。基础夯实了，金字塔就容易造了。
在日本公司打工的程序员们可能都知道，小日本的软件规范非常厉害，他们花在需求分析和总体设计上的时间通常在40%到50%左右，远远超过国内软件项目的实施，效果也要强的多。他们总体设计的规范甚至详尽到某个过程该如何判断，确立什么样的条件，换言之就是把什么时候该如何写(if...else)语句都帮程序员定好了。在这样的软件规范下，程序员更象是装配流水线上的工人，对一个模块或技术熟悉到一定程序就变成了完全的重复性劳动。所以在日本和欧美经常会有程序员是低级工作一说，很多人不明就里，对国内程序员也照搬，对国内的程序员来说是很不公平的。在国内，只会照抄别人代码，一点都不懂创新，凡事依靠别人，快下班就盯着表看的程序员是不少，这种人一般很难有什么前途。但是，优秀的不断进取的程序员也很多。由于国内没有象CMM这样的软件规范或者很少，所以这类优秀的程序员不少都是干着系统分析员甚至PM的活，拿着程序员的工资。这类程序员虽然在起步时会吃很多亏，而且是主动找亏吃，然而几年之后与前一种程序员的社会地位会出现明显的分化。当上进的程序员们作为PM进行商务谈判的时候，前者还在各个公司里频繁跳槽，跳来跳去都不满意。有些扯开了，回到我们的话题。日本的软件规范与CMM有惊人的相似，其中至少有35%以上都是几乎一模一样的。最近经济不景气，东京倒闭了160家软件公司，这个数字是今年6月份的，还在不断增加。这些公司纷纷抢滩上海，招收技术人员。如果去这样的公司应聘就要考虑清楚了，进去可以学到他们的规范和质量控制，可是要想从程序员成为系统分析员或PM，比登天还难。往往一个程序员进去干了好几年，对自己的那一块熟的不得了，而对隔壁同事所做的东西一窍不通。拒传华为正在尝试CMM4（华为印度研究所已经通过CMM4），对在华为工作的程序员们来说可谓福祸难料。当然，已经作到PM或QA或者热爱CODING的朋友例外。
需求分析本身也存在着时间分配的问题。第一遍需求分析花的时间会最长，分析员们在客户的各个部门之间几乎把腿都跑断，把口水说干，就是为了确立一个初期的需求模型。所有的文档将会提交给PM进行复审并签字，不合格的打回重做。反馈表随之将提交给客户，第二遍第三遍等等等等接踵而来，与客户反复讨论和磋商，反复提交文档和表格，目的只有一个，明确需求。当PM最终合并了所有文档并确立需求之后，最终生成的需求文档将提交给客户的各部门负责人签字。这些文档将作为合同的附件添加，以便在将来项目变更或者碰到重大问题时和客户扯皮的重要依据。需要说明的是，客户并非都是蛮不讲理，但是说实话，颇有无奈，国内目前的项目大多数客户为了不让自己的钱白花，经常变着法子提需求。在启动阶段明确需求并签字，无论最终情况如何，一份详尽的书面文档可以解决很多口头承诺或概念模糊的文档带来的许多问题。
详尽的需求分析有一个额外的好处就是对一些双方都很陌生或者从来无人尝试的领域将是一个决定是否进行项目的判断标准。有时候，这种大项目在签单时双方都没有绝对把握保证可以出成果，一旦在需求分析阶段发现难以逾越的技术难关，就会放弃项目。典型的例子就是NMD洲际导弹防御系统。上世纪八十年代初美国搞星球大战计划，拖跨了苏联。大家对那段历史有些含糊，很多人认为苏联人上了美国的当。其实并不完全如此，苏联人的情报机构无孔不入，并非那么容易上当受骗。实际上当时美国国防部已经开始着手NMD系统软件的需求分析，前后耗资数亿美圆，耗时两年，仅仅是做需求分析，终于发现存在着在当时技术上无法达到的高度，随后项目被放弃。
3.项目启动
项目启动要确定项目计划，与客户一起实施第一次项目审核，确认并对一些产品和服务向下包厂商下订单。这个时候的PM会忽然发现有开不完的会，一天开三到四个会议是很正常的事情。这些会议有与客户的会议，与下包厂商的，有团队的，有公司高层的。团队的会议主要是建立正式的团队，提供团队成员的角色和职责，提供绩效管理方法，向成员提供项目范围和目标。与客户的一个主要会议将是项目启动会议。在这个会议上PM会与客户确立正式的交流渠道，项目综合描述，让项目参与人员相互了解，建立以PM为核心的管理制度。还有一些零零碎碎的东西甚至包括办公场地的大小，电话多少部，所有人的联系方式等等都要在会议上确立，并做会议记录。这都是些非常琐碎的事情，听起来婆婆***，却是非常必要，缺一不可。大概就是所谓三军未动，粮草先行吧。
这时候，作为公司高层，应该向全公司发表申明，正式给PM项目经理任命书和项目授权书。这个动作虽然在别人看来有些形式主义，但是对提高PM本人的士气和责任感是有很大助力的。
三.计划阶段
1.定义结构分工结构图（WBS）
启动阶段结束后，项目进入计划阶段，也就正式进入实施。这里概念可能有些不太对头，其实是翻译的缘故，反正大家明白意思就行，不用拘泥于字面。WBS是一组要提交的项目元素，用来组织定义项目的总体范围，具体包括从工作内容，资源，成本角度考虑项目范围；建立一套系统所需要的分层工作结构；把项目分解成易于管理的几个细目，这概念有些模糊，其实跟资源管理器里分目录是一回事情。可以说，WBS是计划阶段的核心。WBS会详细的分到递交件，包括给自己人用的项目使用的过程文件，给客户用的模块和说明文档，完成每个细目的标准以及如何把这些细目的责任分配到具体的个人。WBS有缩进式和树状式，我这里也没办法画图，大家参考一些项目管理的书籍，里面有详细介绍。我整个文章只挑我觉得需要注意的地方，如非必要，对技术细节或者工具使用不做详细介绍。WBS的细目并不需要分解到同一水平，最下面的细目叫做工作包，分包的依据是个人的责任和可信度，也就是说到每个人头上的任务是否能落实，是否有把握完成；还有就是准备对项目进行控制的程度，程度越深，WBS树也就越深。由于WBS是实用性的东西，根据个人理解也不一样，所以一个项目可能会有几个正确的WBS，看PM的需要和最适合当前团队状态的进行选择。
WBS的定义还是很麻烦的。PM要召开团队进行讨论，向成员提供与项目相关的所有详细资料，并把WBS树分解到二层三层。然后要花上一段时间让成员进行头脑风暴式（BRAININGSTORM）思考，制订工作产出和相应人员的职责，记录每一个工作包的完成标准。在头脑风暴式思考时，会有很激烈的争论，PM要协调关系，调节气氛，从自己能考虑到的各个角度旁推侧敲，提示成员的思维角度和方向并加以总结。尽管很麻烦，制订WBS仍然是非常值得的。如同需求分析一样，WBS准备的越充分，编码的进度越快。
2.风险管理
既然是商业行为，那么项目的风险必然存在，相信阅读这个帖子的朋友不少人都经历过或大或小的风险。有些风险很容易解决，有些风险则大大损害利益。不论什么样的风险，能避免尽量避免，所以有必要对风险进行管理。由于风险的不可预知性，风险管理难度很大，概念也很难讲清楚，只能从一些可行的角度去分析，进行管理。
首先要识别风险。这是个难度很高的活。PM要先召开风险识别会议，这个会议面向公司，高层，跨部门的有经验的人都将参加。然后审核由项目小组生成的风险清单并与重要成员进行风险沟通，检查一些重要的风险源如WBS，成本（时间）预估，人员计划，采购管理等等。最后就要用到PM本身在以前类似项目中得到的经验教训。
识别之后要进行分析。我们可以进行粗略的量化分析（精确分析是不可能的事情）。有经验的人可以一起参加讨论，把提交出来的风险进行分类。首先按发生的可能性分，一般分成高，中，低三个级别，虽然很勉强，但是好歹也有个量化了；然后按耗去的成本分，也是高，中，低三级。我们可以把这两种类别的三个级别进行组合，碰到可能性也高，成本也高的风险就定位为不能接受。碰到这种风险只好让客户修改需求或者增加风险预留成本，否则一旦亏起来不是亏一点点，有可能赔的很厉害。高和中，中和中的搭配都是属于高风险，中和低，低和低搭配属于低，高和低搭配属于中。
第2篇
国际避税的前提是熟悉东道主国家相关税收制度或者《税收法》，因为税法是一个国家控制企业经济活动的主要法律手段。国际工程税收筹划的基本步骤是：
1.预先安排
工程项目中标之后就要开始进行商务谈判和合同签订，这是控制税收的关键步骤，作为承建方的东道主国家从主观上是重视国际工程项目的，预先安排工作是决定规避税收程度的前提，因此，在商务谈判中，往往会根据我国特殊情况或者不适应的税收制度进行例外规定，我国应该抓住这些优势，铺垫更多有利于后期规避税费的条件。比如争取每一个单项项目的税收减免，有时候东道主国家为了促成该工程项目会提出很多关税优惠政策，这也是我国企业要努力的重点，这些正好弥补了我国施工企业利润低下的弱点。预先安排可以说是规避税费的前提条件，也是关乎税费能够避免多少的关键步骤。
2.进程控制
国际工程项目比较大，工期比较长，实施过程中又会涉及到多个国家的材料采购、工作人员等等，设计、施工和预制都比较复杂，每一步都有可能影响到税负的缴纳，在这个过程中，需要对税收成本收益进行充分的分析，这是进行决策前必备的工序，这些都属于进展过程中的控制手段。比如，对于企业中的设备是自己采购还是进行租赁，这些都需要企业进行相关的关税、增值税费、利润税等多种费用进行综合分析，最后选取最优的结构。此外，还有人工费，一定要对该国的人工成本加以考量。既然是国际工程项目，就一定要充分的利用当地人工、材料、施工等优势来降低税费。
3.索赔工作中税收安排
在国际工程项目中还有一项税费不可忽视，就是索赔税费，因此对于该项内容也要给予足够的重视。当今，国际项目竞争激烈，工程造价又比较透明，导致了利润率也比较低，因此在工程进展过程当中，必须考虑到附加工程或者项目所带来的影响，对其及时采取优惠政策，比如，将临时进口关税采购的机器转换为永久进口型的，这样就可以减免一定的关税。
二、国内部分的税收筹划及管理
1.增值税方面筹划及管理
众所周知，增值税是每个国家税种中比较重要的一种，因此各国对于增值税的征税范围都比较明确———货物和提供的服务两个方面。比如，我国对外承包项目，其中那些对外工程所用的设备、机械或者生活物资，甚至是不再运回境内的工具按照现行税收法律政策是能够免税或者享有退税等优惠政策的。因为在货物购买后，出口之前，已经在采购价格当中包含了增值税，因此国家对于出口产品进行免税或者退税的做法是合理的。此外，对外承包工程的企业有时候会向国内某些公司进行业务的分包，分包施工企业为了项目的实施需要采购出口的物资，比如水泥、安装材料或者是一些消耗性的建材，这些材料在采购时是可以享受退税或者免税政策的，虽然这些分包公司没有对外出口的权力，也不会直接承担国外工程的施工，但是却可以借助对外承包工程企业的名义进行退税，或者申请对外工程承包企业为其进行退税，但是退税的工序比较复杂，要求的条件和需要协调的部门也很多，因此本文还是建议这些分包公司自己进行退税，该公司在进行退税的时候可以适当的减少分包合同中的标额，这样就可以减少一定的营业税和城建税，最终达到节省对外承包工程项目承包中的成本。
2.营业税方面筹划及管理
按照《营业税暂行条例》的规定，对外承包工程的企业因为承包工程项目的实施并不在国内，因此无需缴纳国内营业税，这是根据使用地来确定的，但是比较大型的国际工程项目在完成的过程中一般无法自身独立完成，会对某些工程进行分包，比如设计、土建、安装、调试、培训等方面都是可以进行分包的，因此，一旦这些业务分包给国内或者国外分包，由于国内企业不能直接承包对外承包过的工程项目，因此该企业仍然需要缴纳一定的营业税和城建税或者是教育附加费，但是分包公司毕竟承担的是对外承包工程中国内的一部分业务，因此没有责任承担合同全额应该缴纳的营业税，所以对外工程承包企业在与国内分包企业签订分包合同时，应详细划分分包合同中国内与国外部分的工作及其价格。分包企业应仅就国内工作的价款部分，开具营业性发票给对外承包企业用于账务处理，而国外工作的价款部分，开具结算单用于账务处理。这样做的结果是降低了分包合同的价格，从而节约了对外工程承包项目的成本。
三、国外部分的税收筹划和工程管理
1.关税的税收筹划与管理
我国的对外承包企业一般会将目标定位于发展中国家，因为这些发展中国家的关税政策有着很多相似的地方。想要做好关税的有关筹划与管理要做到以下几点：第一，考察我国与工程实施所在国是否存在相关的关税协定，如果我国工程设备或者货物是由第三方采购而来，那么就要考虑该国与工程实施所在国是否存在关税相关协定；第二，考虑工程实施所在国的海关是否能接纳关税保函，也就是利用保险公司给开出的保单来代替所得税的缴纳，这样的话就可以在实施工程的时候临时借用工程所在国的设备或者机械，等工程结束之后进行归还，这样就可以免缴部分关税。第三，考虑到不同的商品运用不同方式，不同语言进行报关税率不同的问题，比如国外工程运用外文进行描述就能获得较低的税率。本文建议，在谈判合同时，最好让业主承担关税，他们作为当地业主在关税规避方面有很多优势，往往在做清关和缴纳关税上会事半功倍。
2.企业所得税的税收筹划与管理
我国财政部和国家税务总局印发的《境外所得计征所得税暂行办法（修订）》（财税字[1997]116号）规定：对于纳税人由境外所得，不论是否要求汇回，只要处在纳税年度就必须按照条例和相应的实施细则进行计算并上缴所得税。但是对于海外项目有例外规定，比如一旦对外承包企业在海外实施项目时已经向项目实施所在国缴纳了企业所得税，并且两国之前还存有免征双重税的协定的，在我国缴纳所得税时是可以相互抵扣的，当然抵扣限额应该按照我国税费算法计算，对于超出限额的不得抵扣，低于限额的部分进行补缴。很多国家对于一些大型的对外承包项目有着特殊的规定，尤其是在企业所得税方面存在大量的优惠政策。据此，国内企业在承包国外工程的时候应该尽可能地运用各种手段争取在当地进行企业所得税的缴纳，充分利用好本国特殊优惠政策，比如在当地设立公司的分支，先按照工程所在国的税法或者政府的规定进行缴税，其中便会享受减免政策，等到税务机关批准之后，再按照本国相关减免政策进行抵免。本文以国际工程项目筹划与管理的概念分析作为基础，捋清对国际工程项目税收筹划时的步骤，通过合理有效的筹划方式来减少不必要的税费开支，从而获取一定金额的筹划收益。总之，国内企业在承担对外工程施工工作时不应该再遵循过去那种比较粗糙式的管理方式，应该向着细化、精确、技术性的方向加以研究，在激烈的市场竞争中，通过有效的管理方式来确保对外承包工程项目的顺利实施，利用好国家给予的优惠政策，最终增强企业在对外承包项目时的竞争力，促进我国对外承包项目的长期发展。
四、结语
第3篇
论文摘要:国际工程项目是指国际工程领域中的项目,也称国际领域中的工程项目。文章以工程项目组织结构模式为对象,探讨了各类工程项目组织结构模式的特点,提出了项目组织形式选择的基本要求。
国际工程项目是指国际工程领域中的项目,也可以说是国际领域中的工程项目。工程项目组织(ProjectOrganization)是指在工程项目管理人员中的职位结构设置及设置结果。工程项目组织的目的是按任务或职位制定好一套合适的职位结构,以使项目人员能为实现项目目标而有效的工作。工程项目组织的结构模式是指在项目上级组织的影响下,项目与上级组织以及项目内部的联系方式。由于项目组织是在上级组织内形成,而上级组织通常是一种常规组织,所以项目组织与常规组织既不同又有联系。按照这一思想,在项目管理组织中,形成了几种项目组织的结构模式:职能化项目组织、项目化项目组织、矩阵化项目组织和混合组织。
一、工程项目组织结构模式
(一)职能化项目组织
与常规组织联系最密切的就是职能化项目组织(FunctionalOrganization)。这种模式为了给项目安个“家”,把项目放到常规组织的一个职能部门去,使项目组织成为常规组织的一部分。在职能化项目组织中,人员利用上有最大的弹性及适应性。部门作为项目相关专业技术专家的基本管理基础,专家可被临时安排到项目中,完成所需要的工作后被立即安排回他们的常规工作;部门中的专家也可以被组织起来共享知识和经验,个别专家还可以被不同的项目利用。因此,职能部门在个别人离开项目甚至上级组织时,仍可保持技术上的延续性。
在这种模式下,客户、委托人不是活动和关心的焦点。职能部门有自己的常规工作要做,这些工作通常是优先于项目考虑的,因此客户常被忽视。有时在职能化项目组织中,没有一个人对项目负全面责任。这种不明确责任的失误通常意味着项目经理只对项目的一部分负责,而其他人却对项目的另一部分甚至更多的部分负责。不难想象,这必然会导致缺乏协调和扯皮,进而造成对客户的需要反映既慢又困难。这种模式不利于促进形成项目的系统管理方法。
(二)项目化项目组织
项目化项目组织(ProjectizedOrganization)也可称为纯项目组织,在项目上与上级组织联系方面,是另一个极端。在这种模式下,项目与上级组织的其他部分分离,成为一个自给自足的单位,它有自己的技术人员、自己的管理、由定期的成果进展报告和工作监督而保持着与上级组织的微弱关系。
在项目化项目组织模式下,项目经理在整个项目上有足够的管理权,项目经理是真正的项目领导,项目班子所有成员都只对项目经理负责,在做出技术决策前不用请示任何职能部门负责人。当项目与职能部门分开时,项目经理绕过了整个智能结构直接与公司高级组管沟通,沟通线路缩短了,使得沟通更迅速。同时,由于权力集中,做出快速决策的能力极大增强,整个项目组织也就可以对客户的需要和上级的要求做出快速反应。当存在若干个连续的类似项目时,项目化项目组织就可以稳定地拥有或多或少能开发出特定技术的一批骨干专家,从其成员当中开发出高水平的完成任务的能力。项目化项目组织结构简单而且灵活,理解和实现相对容易。这种形式易于形成对项目的系统管理方法。
然而,当上级组织同时进行几个项目时,要满足每个项目的人员配备需要。这会导致从行政部门人员到高级技术人员的重复配置。为确保技术知识和专门技术使用权的需要,导致了项目经理储存设备和技术以便当需要时就能得到,因而一些掌握关键技术的人是在可得时而不是在需要时就被项目占有了。把项目从职能部门的技术控制下解放出来,有利也有弊,尤其是项目带有“高技术”的特征时更是如此。虽然参加项目的技术人员对项目技术问题有一定的研究深度,但仍然还是落后于其专业中的其他一些人。在项目化项目组织中,项目采取自己的生活方式,常发生项目间的对抗及痛苦的争斗。
(三)矩阵化项目组织
为了能将项目化项目组织的优点与职能化项目组织有利的方面结合起来,同时也避免其各自的缺点,人们发现了矩阵组织(TheMatrixOrganization)。在效果上,职能化和项目化项目组织代表两个极端,矩阵组织则是二则的结合,它是覆盖于上级组织的职能部门之上的项目组织。由于是由项目化项目组织和职能化项目组织结合而成,根据两个极端中哪个的作用强,矩阵组织又分为强矩阵组织(Strong
Matrix)和弱矩阵组织(WeakMatrix)两种形式。
在矩阵化项目组织中,项目是强调的重点,项目经理个人负责管理项目,使项目按期、在规定费用以内达到预定要求。在这点上矩阵组织与项目化项目组织是相同的。由于项目组织是覆盖在职能部门之上的,从中临时抽调人力资源,项目对职能部门的技术专利库有了合理的使用权。当有多个项目时,所有项目都可能得到职能部门的专利,因而极大地减少了项目化项目组织的重复配置。矩阵组织对上级组织内部的各种要求反应也是既快又灵活。在矩阵管理中,项目有上级组织各行政管理单位的代表并有对他们的使用权。其结果是使项目保持了在政策、实践和程序上与上级组织的一致性。当同时进行几个项目时,矩阵组织可以实现较好的资源综合平衡,进而实现每个项目不同的时间、费用、性能目标。这种整体优化方法可使得所有项目人员配备得当,进度安排合理,从而优化整个系统而不是牺牲其他项目而实现一个项目的目标。在职能项目组织中,毫无疑问职能部门是决策的核心,在项目化项目组织中,显然项目经理是项目权利中心。到了矩阵组织,权利则要更多地在二者之间平衡,通常这种平衡相当细致。但若果对谁负责的问题出现疑问时,项目工作就会受阻。
在多个项目间优化项目目标的能力是矩阵组织的一个优点,但这种能力也有反面。多个项目必须当成一个整体慎重监控,而这是一项艰难的工作。为满足多个项目的进度而在项目之间调动资源可能引发项目经理间的明争暗斗,这些项目经理都总是考虑确保自己的项目的成功而不顾组织整体的优化。在使用矩阵组织的项目上,传统做法是项目经理负责管理决策,职能部门领导负责技术决策,但这种分工在实践中是很复杂的,没有谈判能力强的项目经理就不能保证项目成功。
矩阵管理破坏了命令统一的管理原则,项目人员至少有两个上级,他们是职能经理和项目经理。它使人员无法忠实于双向领导,也无法应付可能的混乱局面。任何在这种体制下工作的人都会体会到它的难处,没使用过这种方式是体会不到这一点的。
(四)混合组织系统
纯职能和纯项目组织在一个公司里可以同时存在,这就产生了混合形式(MixedOrganizationalSystems)。这种形式通常是将一些大的、长期良好运行的项目分离出一些附属项目或独立的活动。许多公司在已有的职能部门中先培育一些还未稳定的小项目,然后让它们“断奶”,形成有自己独立身份的纯项目,最终形成“攻关队”,大项目还可以成立“攻关实体”。混合型式的杂交带来了灵活性,它使公司能通过适当的组织结构设置,满足解决各类特定问题的需要。然而,由于利益和兴趣都不同,这种杂交中也有明显的危险,相同责任的不同组合会鼓励重叠、重复和虚构。
二、项目组织结构模式的选择
(一)影响选择项目结构模式的因素
选择组织形式不是一件易事,要依据项目的特点和公司的资源来选择。有的只是少量的设计原则,不会告诉你确切需要哪一种形式,也没有建立组织的详细指南。能做的就是考虑未来项目的性质、各种组织形式的特征、各自的优点和缺点,最后拿出折中的方案。在下表中列出了12项反映项目性质、特征的因素,它们基本上从各个方面描述了项目的情况,每种特性的评价分为三个等级或种类,各等级或种类对应着与其适应的三种项目组织形式之一。
(二)选择项目组织结构模式的基本要求
1.总的来说,职能化组织常用于需较深技术运用的项目,而不是以降低成本、满足特殊的进度、实现对变化的快速反应为主的项目。
2.如果公司要管理数量较多的类似项目(如建设项目),项目化项目组织更适合。同时还可用于一次性较强、较独特且需要慎重控制而且不适于单一职能部门完成的任务,例如新产品生产工艺的开发。
