管理成果论文
前言：想要写出一篇令人眼前一亮的文章吗？我们特意为您整理了5篇管理成果论文范文，相信会为您的写作带来帮助，发现更多的写作思路和灵感。
管理成果论文范文第1篇
南宋教育家朱熹说：“静者，养动之根也。”也就是说，“静”能为“动”服务。教学过程中的“静”同样能为“动”服务。如果在教学过程中巧妙运用“静堂”，将对教学效果产生一定的积极影响。
一、开场静坐，移神醒脑
教师进入课堂，不急于打开教案，只是用亲切的目光环视全班学生。此时的“静堂”能排除外界干扰，使学生兴奋的细胞逐渐安定下来。“老师的第一句话会讲什么呢？”学生的注意力集中到课堂上来了。此时此刻，如果教师能抓住这静后的黄金时分，抓住这“静”化了的心灵，来一段精美的开场白，那么，知识和信息就会像一泓清溪流进学生的心田。
二、过渡静思，衔接自然
鲁迅先生《从百草园到三味书屋》一文采用了百草园和三味书屋两相比照的结构形式，文章中的过渡段充满了对百草园的依恋之情。文中写了这样一段话：“我不知道为什么家里的人要将我送进书塾里去了，而且还是全城中称为最严厉的书塾，也许是因为拔何首乌毁了泥墙罢，也许是……”这段话生动地写出了“我”对百草园的难舍难分之情。
如果让学生带着“这一过渡段有什么作用”的问题结合课文“静堂”思考，就不难得出“过渡段写出了‘我’留恋百草园的欢乐与自由，厌恶三味书屋的禁锢与无味”的结论。
三、静思，升华情感
如《荔枝蜜》一文是以“我”对蜜蜂的感情变化为线索组织材料的。“我”对蜜蜂由讨厌到喜欢，又由喜欢到赞叹，再由赞叹到“梦见自己变成一只小蜜蜂”，思想感情就进入。学生为那可爱的小生灵对人无所求的高尚品德而赞叹不已，学生为一只工蜂最多活六个月却不停地为人类酿造最甜的生活而震颤。如果此时教师要求学生为“我”对蜜蜂的感情变化设计一个变化图，并且让学生静想一会儿再动手。那么，学生的激情虽然仍在升华，但是却内化了，他们能通过“静堂”进一步感受体会生活，会透过酿造最甜生活的蜜蜂想到自己也将要为人类酿造生活的蜜。
四、结尾静悟，余味无穷
管理成果论文范文第2篇
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本身在以前类似项目中得到的经验教训。
识别之后要进行分析。我们可以进行粗略的量化分析（精确分析是不可能的事情）。有经验的人可以一起参加讨论，把提交出来的风险进行分类。首先按发生的可能性分，一般分成高，中，低三个级别，虽然很勉强，但是好歹也有个量化了；然后按耗去的成本分，也是高，中，低三级。我们可以把这两种类别的三个级别进行组合，碰到可能性也高，成本也高的风险就定位为不能接受。碰到这种风险只好让客户修改需求或者增加风险预留成本，否则一旦亏起来不是亏一点点，有可能赔的很厉害。高和中，中和中的搭配都是属于高风险，中和低，低和低搭配属于低，高和低搭配属于中。
管理成果论文范文第3篇
（1）不够规范的建筑市场
对于国家现行的管理要求和行政规范，一些个别地方的政府和建设行政主管部门没有落实到位，严重的甚至并不落实，导致有法不依、执法不严、违法不究的现象出现；而在业主方面，由于缺乏专业的知识，无论工程层次的高低、结构的难易、工程的范围，都要求一级资质的企业去参加竞标，这样很难形成差异化的竞争，给市场公平竞争带来不小的压力，市场的秩序容易混乱。而对于建造师资格证书造假和出借等这样普遍存在的违规违法的行为，实则加剧了建筑市场不规范的运行。众所周知，建筑行业是劳动密集型的行业，进入市场的门槛比较低，导致市场上有很多缺乏资金的小企业的存在。
（2）贯彻不完全的建筑施工项目管理体系
建筑施工项目管理体系在多数建筑施工项目管理程序文件中都没有得到真正的贯彻与实施。这样的现象具体有：专项施工方案的编制和针对性强的施工组织设计都比较缺乏，施工作业指导书是不完善的；材料的实验不到位，这样就会导致使用的材料不合格；很多项目有着搬旧方案的现象；工程技术和管理人员主要追求工程的进度忽略质量问题，导致形式化的工程技术交接，不规范的过程检验，这些都说明了项目质检的工作人员没有很好的履行自己的责任，建筑工程项目的管理都不够规范化，严重的话会出现建筑工程的关键部位质量失控的现象。
2提高我国建筑工程管理的有效举措
（1）建立我国建筑工程管理思路新体系
就目前我国建筑工程管理理论建设还存在不足，影响了建筑工程管理工作水平的提高。所以，现阶段建立一套适合我国建筑工程管理的理论体系已经迫在眉睫。现阶段，我国建筑工程管理体系是在借鉴国外建筑行业基础上的，而国外建筑行业的发展领先于国内建筑行业的发展，因此，在很多方面都不能更好的适应我国国内建筑行业的发展，对此，必须在立足国内建筑行业发展的实际情况而建立一套适合我国建筑行业发展的工程管理体系，包括管理理念、管理方法、管理模式，这样才能促进管理工作有条有序的开展，使其更好的服务于建筑行业的可持续发展。
（2）加强建筑工程项目施工质量的管理工作
我们知道，建筑工程建筑主要围绕具体的施工来开展，所以要想提高建筑工程管理工作的水平，就必须不断提高建筑工程施工的管理水平。这就要求我们做到将各方面因素有效结合起来，如建筑施工材料，施工工艺、施工人员、施工设备等因素，将管理工作有条有序的开展，保证每一环节的效率与质量。
（3）提高锻炼部门的执行能力以及不断加强管理法的建设
应该提高监督队伍的整体素质以保证政府监督工作的权威性和有效性。所以，要加强建筑工程质量监督机构对质量管理的学习，让监督队伍的素质不断的提高。与此同时，监督手段也要不断的提高完善，增加监督队伍的科学含量，增加先进的检测设备，来实现监督工作的科学化、现代化。而从建筑市场的整体趋势来看，市场中存在着不少的执法不严、违法不究的现象。
3结语
管理成果论文范文第4篇
工程设计是工程建设和工程造价控制的关键步骤，在初步设计阶段要根据电力工程的建设规模、建设标准、结构形式、使用功能等确定投资的最高限额，完成施工图纸后，要准确的计算工程造价。在进行工程设计时，要根据施工技术、当地地质条件、经济发展水平等，对各种设计方案进行比较，选择可行性高、经济性强、安全性高的设计方案，良好的设计方案能有效的降低施工工期，节省施工成本，据统计设计阶段的费用占整个工程费用的1％，但设计阶段的工程造价对整个电力工程造价控制有75％的影响作用，因此，科学、合理的工程设计是做好工程经济管理工作的基础。
二、施工阶段的工程经济管理
1.全面进行电力工程预算管理
预算管理是有效促进企业管理的方法，也是企业管理的一个重要手段，所以在电力工程建设中实行预算管理。在进行预算管理时，需要保证预算管理的全面性，保证预算管理的高度，只有这样才可以全面的对电力工程进行管理[3]。还需要根据电力企业的特点，对电力工程预算进行合理有效的编制，提高电力工程预算编制的有效吐和适应性，然后认真、严格的执行预算管理。
2.加强设计变更审查
工程变更是施工阶段工程造价控制控制一个重点，工程变更包括设计变更、施工条件变更、新增工程、施工工期变更等，其中设计变更是对工程造价控制影响最大的，因此，加强设计变更管理对工程经济管理有十分重要的作用。在电力工程建设过程中，尤其是在大型的电力工程中，设计变更是不可避免的，在进行设计变更时，要尽量提前，因为设计变更发生的越早，电力企业的经济损失就越少。如果在设计阶段发生设计变更，只需要更改施工图纸，经济损失不会很重；如果在采购阶段发生设计变更，不仅需要修改设计图纸，还需要重新选购施工材料及施工设备；如果在施工阶段发生设计变更，很有很能需要将完成的工程拆除，这就会造成很大的经济损失，因此加强设计变更管理有十分重要的意义。在进行设计变更时，要将工程造价控制在总概算范围内，如果变更后工程造价超过总概算，要及时汇报给相关部门，经相关负责人同意后，才能进行变更，在设计变更过程中，必须将变更的原因标明，从而为工程结算做依据。
3.加强现场签证审查
要加强现场签证审查，签证监理人员要掌握必要的工程经济管理知识和工程预结算知识，严禁对不应该签证的项目签证；监理人员要认真审核施工单位填写的签证，确认无误后才能盖章确认。监理人员要重点审查施工单位偷工减料、以少报多、弄虚作假、结算阶段搞突击等现象，严格审查非包干工程现场签证。加强合同管理。施工阶段是整个工程所需费用最多的阶段，因此，施工阶段的工程经济管理对电力工程的全过程工程经济管理有十分重要的作用。在投标招标阶段，投标单位要严格的按照相关规定进行投标报价，投标单位在投标过程中，要积极的利用工程量清单计价，从而有效的提高承包单位的技术设备和管理水平，降低工程造价。承包商签订合同后，在施工阶段要加强合同管理，严格的按照合同规定进行施工。
三、结算阶段的工程经济管理
1.工程量的审查
对于采用工程量清单计价的工程，在进行工程结算时，要对工程量进行重点审查，结算的工程量要以签订合同文件中的工程量清单为依据，审查人员要掌握必要的工程量计算、图纸审查知识，要充分了解整个电力工程的设计方案和施工过程。
2.定额、取费审查定额
单价是定额子目消耗的费用，一般情况下，定额单价可以直接套用在项目核算中，在套用定额单价时，要确保定额单价的准确性，不能出现高套、错套的现象；有的项目需要定额换算，在进行定额换算时，要确保换算方法的准确。在进行取费审查时，要保证没有太高取费基数现象，取费的类型要和招标文件、合同文件的相关要求相同。
四、结语
管理成果论文范文第5篇
【关键词】建筑工程；项目安全；施工安全；安全管理
一、建筑工程项目勘察设计阶段安全管理
在建筑工程项目勘察设计阶段建设单位务必要以书面形式与具备相应资质的勘察设计单位所提供施工现场及毗邻区域水、电、气、热、邮电通讯等地下管线及地质资料等相关事项签定合同，这样起到在建设工程项目过程中的制约作用。具体要求勘察设计单位在建设工程项目进度中应当提供建筑工程全面、准确的地质测量和水文资料，并按照建筑安全标准进行设计，以保证建筑结构的安全和作业人员的安全。
二、建筑工程项目准备阶段安全管理
建筑工程项目单位在编制招标文件时，由具有一定资历理论基础和丰富工程项目经验的专业建设工程安全工程师和技术人员同共参与，其中在承揽项目的技术和安全要求上具体载明；在建设工程项目施工过程中的相关作业环境和建设工程项目相关安全措施所需费用以专项费用来计提，不要列入建设工程项竞价来算；建设工程项目招标规范中，承包单位建设全程安全业绩要纳入评标标准；由相关建设工程项目安全专家来参与安全方面的评标工作。制定合理工期，建设单位要与具备相应资质等级的施工单位、监督单位签定合同。建设单位在申请施工许可证之前，应当向当地建筑工程安全监督机构提交工地安全方案，工其中包括建设单位与施工单位各自的安全责任、该项目的安全风险评估报告、安全生产保证体系及安全生产专项施工措施。
建筑工程项目单位在备一切相关建设工程项目材料中，不得购买或者强行要求建设施工单位购买、提供、使用不符合安全卫生标准的建筑材料、防护用品及机械设备；不得为施工单位指定上述产品的生产厂、供应商。生产经营单位为建筑工程提供的安全防护用品、零配件、建筑材料等应当符合安全卫生标准和噪声控制标准，并按照生产和安装标准对其产品配齐有效的保险、限位等安全设施和装置，同时提供检测合格证明及下列资料：产品的生产许可证；产品的有关技术标准、规范；产品的有关图纸及技术资料；产品的技术性能、安全防护装置的说明。在建设工程项目施工中要加大力度抓好材料管理。这项工作对建设工程项目的性能，保质，安全上起重要作用。要做到把材料全方位、全过程的安全检测，评测，验收管理。在建设工程项目的现场勘察、设计到竣工验收等一系列安全工作上有意识科学地进行策划、组织、指挥、协调、监督控制和改进来发展安全管理工作。公司和项目部组织施工技术人员编制施工安全方案。审批后的施工安全方案即是作为建设工程全程项目安全施工的依据。施工安全单位，由材料部门根据项目部编制方案产品来采购和领用，如施工过程中发现超出安全的用料，材料管理人员必须立即查核，必须保证建设工程项目安全用料方案标准来对材料使用，强化材料安全的严格性。公司材料采购实施招投标，建设工程项目的施工材料由公司安编制审核通过的的方案清单来对材料采购，来例于安全范围的其它材料由项目部自行采购，采购时采用“安全评测，总量订货，分批采购”出现安全和积压、浪费。材料的采购量和单价要有专门机构监控。项目部应使用委托书约定所委托的采购材料的质量、价格、服务、验收办法、交货时间，保证工程的进度而出现安全问题。
三、建筑工程项目实施阶段安全管理
建筑工程项目监理单位要将建筑工程施工方案的安全审查相关内容纳入建设工程项目监理范围，具体要做到建设工程项目实施安全、质量、工期和投资四项同步控制。建设工程项目单位不得要求施工单位违反建筑工程安全生产法律、法规和强制性标准进行施工。建筑工程项目施工单位应当建立以本单位安全生产第一责任人为核心的分级负责的安全生产责任制，设立安全生产管理部门，配备与工程规模相适应的安全工程师，并向工程项目派驻项目安全工程师。项目安全工程师负责有关安全生产保证体系有效运行和实现安全管理目标的人员、物资、经费等资源计划，对项目安全生产保证体系实施过程进行监督、检查，组织参与安全技术交底和安全防护设施验收，纠正和制止违章指挥、违章作业，验证预防措施和应急预案。建设工程项目施工单位应当接受建筑工程安全监督机构的监督管理，分阶段向当地建筑工程安全监督机构申请安全审核。建设工程项目施工单位应当针对下列工程编制专项安全施工方案：土方开挖工程；模板工程；起重吊装工程；脚手架工程；施工临时用电工程；垂直运输机械安装拆卸工程；拆除、爆破工程；其他危险性较大的工程。同时，进入施工现场的垂直运输和吊装、提升机械设备应当经检测机构检测合格后方可投入使用。建设工程项目施工单位应当根据不同施工阶段和周围环境及天气条件的变化，采取相应的安全防护措施。建设工程项目施工单位的项目经理、安全管理人员应当经过上级安全培训、考核合格后，持证上岗。
四、建筑工程项目竣工验收阶段安全管理
在建筑工程项目竣工后，施工单位要要自行检测工程质量和整理相关资料，做好建设工程项目竣工施工安全评价，向建筑工程安全监督机构提交《单位工程竣工施工安全管理资料》。建设工程项竣工安全管理资料是证明施工现场能否达到建设工程项目安全要求的程度。所提供建设工程项目的客观检测资料文件记录，是建设工程项目在施工现场能否达到实行全过程安全管理的主要依据，同进也是建筑工程监督机构（下转第137页）（上接第198页）对工程项目考核的重要内容。在建设工程项目在全程实施过程中作的安全资料的记录正确与否，体现了建设工程项相关单位对工程项目的安全管理能力和力度。在建设工程项目施工安全管理过程中应将建设工程项目全程安全记录。其中应包括以下相关内容：台账、报表、原始记录等，并按有关规定去建立、收集和整理，确定种类、格式；确定安全部门或相关人员，收集、整理包括分包单位在内的各类安全管理资料，进行标识、编目和立卷，并装订成册；安全记录的贮存和保管，要有专人负责，贮存的环境应利于保存和检索。
五、总结
建筑程项目安全管理，要确保建筑工程的质量安全性能，保障建筑工程项目在施工过程中施工人员的人身和财产安全。要从建设工程项目勘察设计安全管理、全程施工安全管理、建设工程项目监理单位与建筑工程有关的生产经营单位，建筑工程项目竣工验收等安全管理等相关工作做重点抓。只有做好建筑工程项目全程中各环节的安全管理工作，这正是建筑工程项安全管理意义所在。
【参考文献】
[1]任宏，兰定筠.建设工程安全技术与管理丛书.中国建筑工业出版社．
