在之前没接触项目管理之前，一直有个误区，那就是项目管理可能不需要太多的专业技术能力，懂点行政管理，有点领导力就可以轻轻松松，把一个团队管理地有模有样，把团队里的每个人管得服服帖帖。
后面转向项目管理这块，做个几个项目之后，越发觉得之前的想法设想就是天真得不行，以至于在很多时候项目管理实践上踩过很多“坑”，有过许多地无可奈何，均由于在当时缺乏项目管理者所需的能力，以至于项目管理得连自己都觉得狼狈。
这么说来，要做好一名IT项目管理者究竟需要拥有什么能力呢？在经历过我踩过一些项目管理上的“坑”以及吃过不少的苦头的反思总结下，我觉得需要具备以下的几种能力。
其实不管是哪一行业也好，特别是在IT领域，比如像我是从事IT领域的信息安全方向，在我看来，信息安全技术的能力就是自身能力框架的基石，就像你要盖成摩天大楼，就必须蚂孝根基牢固，这样的话任何风雨飘摇都无法轻易撼动你，因为会由于基础的夯实而坚挺。
所以基础的能力是取决后面发展的长远，否则“跨越式”的跃进可能会忽略基础成长的机会，造成日后基础松垮，限制了向上堆积的能力。
还有如果你想你的项目团队成员都能心甘情愿听从你的领导和安排的话，你就得有一个让他们“服”你的前提，团队成员他们擅长的是实施的业务能力和专业技术，如果你的专业技术或者业务能力无法优异与他们，那他们又有什么理由一定要服你呢？
这一点其实在项目管理中体现地尤为常见。一位基层员工，由于某些管理的能力特质，被领导赏识，进而提拔为IT项目主管。但是当时被提拔为项目主管时，他的技术能力相对一般，但却面临着要去领导一群大部分技术能力比他好的技术工程师。
一开始他觉得很正常，也没什么压力挑战，因为他自己误以为做好一名管理者，不需要很强的技术能力，因为只需要有好的领导力就可以做好管理了。
后面等到项目实施时，他才发现其实如果本身技闷搭稿专业技术能力不过硬的话，比团队内的人还弱的话，就会面临一种管理的“痛苦”在里面，那他们会有一种心理想法那就是：我根本不会管你管理有多厉害，你的技术都没我厉害牛逼，我凭什么要听你的。
也许，你可能会很无奈：为什么我是作为一个管理者的角色，为什么非用跟你比技术能力呢？但是你也怪不了人家，因为在IT领域里搞技术实施的，人家认的就是第一基础能力，你要我听你的话，可以，只要你技术比我厉害我就承认你。
所以在IT项目管理中，管理能力的基础就是技术能力，技术的晋升拓展就是管理，这种主次之间的逻辑认定，你如果逆反执行，你就会遭遇举步维艰的困境。
其实这种能力在古代军营中的元帅与军将士兵之间的能力差别中体现到很到位。比如大唐薛仁贵，起初作为一个不起眼的火头军，如果没有身怀十八般武艺的能力和过人的胆识，怎么可能屡建丰功伟绩，最后晋升为元帅；在晋升为元帅这种“军营一哥”的角色之后，他同样是一个大的管理者角色，手底下均是武艺高强的武将下属（罗通、秦汉等），从他的武艺在历史电视剧里面的表现来看，更是超越了众人，所以同事及下属没有几个不钦佩赏识以及服从他的。
这也皆因有很大部分是因为极为出色的专业实力在推动了自身的管理，为管理顺水推舟，使得管理的可执行性有了一定的保障性。
估计很多的人都因缺乏良好的沟通表达能力而吃过亏。在论文答辩时，你做出来的论文水平比你的竞争者要高，但人家却因为沟通表达比你好，而得了高分；在求职面试时， 你的专业技术水平比你的竞争者强，但人家却因为回答表现比你好，而被录用了；在项目实施中， 你的其他综合能力都很全面，但如果没有良好的沟通协商能力，那么你的需求永远得不到满足。
所以说，要想成为管理的主导者，你必须学会如何去更好地沟通表达。一个人想做一件事情，这就是他内心的一个真实的需求，但是需求需要实现或者说被满足，它就必须被表达出来，那么如何更好将需求通过语言形式传递表现出来，这就是沟通表达。合适恰当的传递表现形式，就好比优秀良好的沟通表达，更直抵对方的内心，更容易让人听懂接收，以至于让对方去接受并响应你的需求。
在IT项目的实施管理更为重要，对于团队内部，有一件事情需要大家一起来协作共同完成的，这个时候，如果你没有把需求很好地表达出来的话，会有几种情况：第一，你根本表达不清楚，比如没说清这部分的功能要谁去实现，输出报告要谁去整理；人家就不会理解你的需求是什么；第二种是你既说明了事件是什么（事项）、为什么要去做（缘由背景）、谁去做（实施人员）、什么时间点要结果（Deadline）；到这里的话你的需求表达算比较明确了，但还不是最优。
沟通表达的效果差异，在于表达之后，需求如愿实现的差异。什么是好的表达？我觉得就是你把要表达的需求和东西说出来之后，人家不仅仅听懂了，而且按照你的需求反馈了最为积极正确的回应。接着上面的例子，为什么还不算是最优的表达，因为其实还缺少表达一个比较重要的点，那就是目标预期，因为有些时候你把目标预期定出来，对方就会更接近你的真实需求导向输出结果。
但如果没有说出目标预期的话，就有会像是大领导总有天马行空的空洞设想，底下的人听不到目标预期的界限，也许只能无奈地自由发挥，跟着天马行空，实施落地就是痴人说梦。
在将领导的目标预期落地执行方面的话，Google现任CEO皮查伊做得简直太好，这也是他的大boss——拉里·佩奇（Google创始人之一）为什么那么赏识他，最后愿意当一个“甩手掌柜”的原因之一。
因为拉里·佩奇是个不善言辞又喜欢脑洞大开的主，在开高管会议时，总是喜欢说些天马行空的概念，可能由于太过于宏观， 导致高管们一头雾水，不知所云。
但是皮查伊却懂得去主动与老板交谈，简短几分钟便能抓住老板的目标预期是什么，并准确无误地传达给团队成员，以至于可实现落地。
这就是高效沟通表达的艺术，巧妙的沟通不在于冗长而在于精准简洁。
然后对于项目团队外，也就是面对客户或者其他跨部门的沟通的话，除了会沟通，还要懂得协商。不懂得协商的话，自己就会身处被动，客户的配合主动性就会很低，项目开展实施，就难免会陷入“对方都是大爷，我一切都听大爷的安排”的低段位服务姿态。
一般客户方（甲方），服务方（乙方）项目开展合作形式就是：客户方配合服务方开展工作，很多时候会遵循一条原则：“你们主动做事，你们就应该主导，我们只是配合方”，所以谁做事，谁就要去占据做事主导权，因为配合方往往是不着急的。所以在这个时候，当我们是服务方时，我们去把握主动是正确合理的，因为你想把良好的结果导向自己这边的话，主动跟他们说需要怎么配合要比自己不知所措，等着问他们怎么配合；要是后者这种情况的话，会产生两种结果。
第一种，客户方会不满。“事情主要是你们来做，我们是配合的，你们自己都不知道怎么做，那我们怎么知道配合你们呢？” 也许你心里会说自己其实是知道怎么做的，只是咨询下你们的意见而已。但其实，只有当对方把自己代入配合角色， 就会自然而然喜欢别人来引导，而不是来反问他们。
第二种，客户方逆转局势，你陷入被动。当你同样不计划主动告诉对方怎么去做，而去问客户怎么开展工作的时候，而刚好遇到的是不厌其烦且很有想法的客户，那你可能就就要无奈地开启“苦逼模式”。
踏入“不能做主”的泥沼，什么事情，怎么去做，都要听人家的想法来做，自己就失去把握的主动权，这样的话，可能会把自己拉入一个一个隐形的“大坑”，到时候要么你就只能“入坑”或者放弃脱离。
所以，面对近乎苛刻的要求和选择时，必须懂得从自身立场出发，通过与对方的协商，将结果主动导向自身有力的一面，而不是任由使唤，被动去接受本不应该接受的诸般要求。
《驱动力》里面讲到：“企业管理最让人头疼的问题是什么？员工的主动性和创造性。” 其实大到企业管理层面，这是个问题，小到基层项目实施， 驱动力简直关系到每个项目成员能否发挥最大的积极性来推动整个项目的实施，这是个根本性的关键问题；同时，这也决定了项目管理者是否是一名激励人心的驱动者。
也许普遍项目管理者会认为：调动成员积极去帮项目做事情，不外乎就是在多点付出而获得成效后，通过多分几张钞票或者说几番激励赞美的话，这两种方式就可以解决了吗？ 这只是通常的驱动力激励手段，应该是属于“治标不治本”的方法，即使这两种在一定的程度驱动了他们的积极，而无法深层通过在项目过程中，激励出他们应该有的“成就感” ，那只是一种短暂的驱动，时间一久就会疲乏，驱动就会变得迟缓。
所以管理者在通过物质需求和言语激励的方式之外，还应该懂得将员工的“成就感”当成创造力和执行力的源泉，并费些心思，将驱动力的力量从自身散发出来，感染到每个人，使得获得成就感，而成为自愿自觉去创造的“个体”。
在我看来有几个成长点是管理者具备后才能修成驱动力的，第一是自身的人格魅力，第二是本身的强大执行力，最后是拥有思考驱动力的思想。
管理者每时每刻都在产生决策，如果在决策时，无法赶跑“犹豫不决”这只怪物，那么你只能被吞噬。
对于决策迟疑，缺乏决断力，我深深吃过它的亏。有一次，一个比较重要的项目实施开展到重要里程碑阶段，只要完成这个里程碑阶段的工作，就可以进入项目验收阶段了。但是在完成里程碑阶段工作之前， 存在一个比较头疼棘手的问题。
那就是有个项目组核心成员，在那个时间点刚好赶上他自己另外负责的项目有项紧急的事情需要他去处理。但因为当时部门项目的现状是几乎大部分数人手里自己都带有项目，也就是自己既是项目经理，又要做项目实施人员，可谓是光杆司令；不但如此，在自己项目空窗期，还要“接济”帮忙下其他同事的项目。
刚好，那个核心项目成员他自己身上也是刚好有几个项目在跟的，只是当时我手上这个项目刚好在做，需要人手。在那个时候，我刚好是关键节点比较赶，而他那边又着急需要安排处理他自己的事情，我面临要去做出选择决策：究竟是让他去处理自己的项目，还是让领导去另外安排协调同事去处理呢？
如果他去，我这边项目搁置，不好交代；但是他那边不处理，我绑着人家好像又有点不合理，安排其他的同事又可能搞不定。不过领导是有提到一点：那就是我这个项目的重要程度会比较高，其他的项目可以灵活安排。
领导虽然没有说得很明白，但是也很明显传递给了我一个信息，那就是目前你负责的项目的优先级是比较高的，在遇到与其他优先级低的项目事项冲突时，必须做出合适的判断，优先执行优先级高的事项，其他事项通过外部资源协调解决处理。
但我当时还是缺乏全局观的意识，在遇到这样一个急需立马做出决策判断的时刻，陷入的却是迟疑和犹豫不决，前面的领悟总结只是事后“马后炮”才正确意识到的。
我还是在“浪费性的思考”后，做出了错误的决策，“老好人”般地放了那位同事去处理自己的棘手事去了。之后我被领导狠狠地批了一顿，因为我失了轻重， 项目里程碑阶段工作拖了进度“后腿”，结果耽误了项目的正常验收。
这是典型缺乏决策力的表现，作为一名项目管理者，在遇到关键决策时，综合评判出各个选择的优先级和重要程度后，就应该强有力地去执行重要程度高及优先级大的事项，摒弃“完美周全”的理想想法，因为现实总是难以做到百分百的兼顾所有；因为有些其他选择可以选择移交转移，让别人来帮你实现。
自己都想揽在身上，自己解决，那只会让自己陷入困顿、犹豫，最后所有的事情都成了“耽误综合体”，决策成为痛点；而当拥有睿智的决断力时，事情可能就会因为精准理智的快速处理而变得高效，进而推到整体事态的进展，映射到项目上的话，那就相当于项目进展会因为管理者的强有力坚定的决策，而衍生影响全局的强大执行力，促进了项目完成里程碑式的跨越。
所以，当一名IT项目管理者拥有了非常扎实的专业技术能力、出色的沟通表达能力、优秀的协商能力、振奋人心的驱动力以及睿智强大的决策力，这些必需的一项项能力后，在项目管理领域，那便意味有了开辟属于自己疆场领域的绝对资本以及自信。
从普遍角度上说，一个有效的项目管理要从几方面入手。1. 项目范围
明确定义好项目管理范围，才能有效配置相应资源。
2. 项目计划
根据项目要求，制定切实可行的项目计划。国内大部分项目经理都是根据上级指示做事，没有仔细做过项目评估，这就导致在项目执行过程中，经常出现不可控因素，影响了项目的执行结果。
3. 项目资源
包括设备，材料，资金，人力资源等。关键是资金和人力资源，一个是保持适当的现金流，一个是保证有足够的人去做该做的事。
4. 风险预估
包括对用户及对自身评估两部分。对用户主要涉及其信用度，财务闷哗局状况，技术能力/经验等方面；对自身主要包括足够的项目管理人员，技术人员配置是否足够，经验是否丰富，有否做过同类项目，用户的付款条件对项目管理造成的风险是否可控？
以上是针对工程类项目，针对芦团软件开发项目，在项目范围/风险中，还需要特别关注用户对项目的具体及特殊要求。
内容来源于ITSS符合性评蚂让估落地工具-云雀运维！！！
什么是项目管理？经过人们长期探索总结，项目管理在发达国家中已经逐步发展成为独立的学科体系，成为现代管理学的重要分支，并广泛应用于IT、金融、服务、航空航天以及工程等诸多行业。由于其诱人的梁核高额年薪以及广泛的就业前景，项目管理目前已经成为超越MBA的最炙手可热的“黄金职业”。 项目管理无疑将会是未来二十年中最热门的行业。那么到底什么是项目管理？
项目管理的定义有很多，按照教科书的理解是：项目管理是在运作方式和管理思维模式上最大限度地利用了内外，去完成项目目标。项目管理包含很多层面：团队管理、风险管理、采购管理、流程管理、时间管理、成本管理和质量管理资源等。
笔者的理解是：项目管理，就是通过合理地组织，利用的一切可以利用的资源，按照计划的成本和计划的进度，完成一个计划的目标。在项目实施过程中，目标很可能会发生变更，那么成本和进度都需要做相应的调整。
项目主管如何解决问题？
按照白猫黑猫理论，评价项目管理是否成功的唯一标准就是项目是否保质保量按时完成。现在的项目实施一般都是主管负责制，项目主管重任在肩，要达到项目成功这一目标谈何容易。
在项目管理过程中，笔者就要经常思索以下问题：
如何在选择余地不多的情况下，组建一支得力的项目组？
项目组成员的挑选非常重要，假如在一个关键的岗位安排了一个不合适的人选，这个项目很可能会出师不利。当然在现有的人力资源中，不一定能顺利选到优秀的人才并组建成一只能战斗的队伍。笔者就碰到这种最恶劣的情况：项目组只有主管有经验，别的成员都是刚刚毕业的大学生，那么主管的任务就不仅仅是管理，而且需要花费大量时间精力来培养这些新手，让他们能尽快进入预定的角色。
如何界定项目成员工作的范围和定义他们之间的工作接口？
这个问题就是俗语说的"派活"。要把活分出去可不是一件简单的事情。项目主管首先需要对项目组成员非常了解和熟悉，知道他们的知识结构和能力水平；其次要对项目情况非常清楚，并能对项目实施过程进行划分和功能模块的细化，并结合每个人员的特点指派具体的任务；最后要重点注意的是，尽量让组员之间的工作接口简单和接口定义详尽，避免将来产生互相推诿和扯皮。
如何准确衡量项目成员的工作量？
做过主管的人都碰到过这种问题：分配给甲的工作，要求一周完成，但是一个月过去了，他还没干完；分给乙的工作，要求一周干完，但是他一天就干好了。实际上现在的项目管理中，工作量的衡量往往靠主管的经验来加以主观判断，而且这种判断也不是因人而异的。主观判断会造成较大的误差，这些误差的积累最终导致不可控制的因素增加和项目风险扩大。
如何在不打扰项目组成员工作的情况下，及时进行沟通？
现在很少有单q匹马就能把项目全部搞定，往往需要团队来完成，那么团队的合作精神就显得尤为重要。在一般人的眼里，技术人员都普遍比较孤傲，不好管理。主管不仅仅要掌握良好的沟通技巧，还要擅于感情交流，帮助解决项目渗伏组成员工作上和生活上的实际困难，使他们集中精力干好本职工作。良好的上下级和同级关系创造了融洽的工作气氛，项目成功的可能性大大增加。
如何评估项目执行状况，随时掌握项目进展？
在项目运作过程中，如果靠员工的报告来掌握项目进展是不够的。事实上，员工都愿意报喜不报忧，在项目初期就出现的问题苗头，如果不能传递上来橡喊掘，将在后续阶段造成大的纰漏。笔者认为除了要定期听取项目组成员的报告，还要专门有一个品保组来监督项目的执行情况。品保组就像廉政公署一样，不参与项目的具体实施，专门给别人"挑刺"，或者写一些测试程序来发现问题。
如何与客户单位沟通与协作？
有时候，项目都已经执行到最后阶段，客户单位突然提出了新的要求，这会让主管非常为难。一方面要尽量满足客户的需求，另一方面又不能对系统做太大的改动，影响进度计划。这种情况往往是与客户的沟通出现了问题，说明在需求阶段做的不够好，同时在实施过程中没有与客户有密切的联系。
如何在诸多不确定因素和限制条件下，按时完成项目任务？
项目成功与否受太多的风险因素影响。所谓“风险”，是损失的不确定性；是给定情况下，一定时期内可能发生的各种结果间的差异。它的两个基本特征是不确定性和损失。项目开发是一项可能损失的活动，不管开发过程如何进行，都有可能超出预算或时间延迟。很少有人能保证开发工作一定成功，都要冒一定的风险，也就需要进行项目风险分析。在进行项目风险分析时，重要的是要量化不确定的程度和每个风险的损失程度。潜在的问题都可能会对项目的计划、成本、技术、产品的质量及团队的士气产生负面的影响。风险管理就是在这些潜在的问题对项目造成破坏之前识别、处理和排除。
如何在完成项目任务同时，保证甚至提高交付结果的质量？
笔者的同事曾经做过一个项目，按计划按预算完成了，但是系统不稳定，某些关键技术指标不能满足国标。造成这种情况的原因有：没有划分清晰功能模块和接口关系，成员相互指责，最终难以定位不稳定的根源，；没有成立质保组，没能很好地实施项目过程控制；过分注重项目的时间进度，忽略或隐瞒了前期的小问题。
如何成为优秀的项目主管？
笔者认为：一个优秀的项目主管首先是一个乐观而自信的人。他凡事都从正面考虑，不把失败当失败，反而将其看作成功之母，吸取经验教训，在那里跌倒又在哪里爬起。优秀的项目主管不一定要很有经验，但是要有强烈的进取心和明确的目标，并能够与他人良好沟通，鼓舞他人为共同的目标一起努力。
IT项目管理的特征探讨
IT项目具有非常明显的特点：紧迫性、独特性和不确定性。下面分别讨论一下这些特点含义和项目管理的相应对策。
紧迫性
IT项目的紧迫性决定了项目的历时有限，具有明确的起点或终点，当实现了目标或被迫终止时，项目即结束。随着信息技术的飞速发展，IT项目的生命周期越来越短。有的项目时间甚至是决定性因素，因为市场时机稍纵即逝，如果项目的实施阶段耗时过长，市场份额将被竞争对手抢走。
在开始一个项目前，主管就必须明白项目的时间约束。具体到每个人、执行项目中的每一个任务都必须明确时间要求。一旦没有按照进度完成，必须要有充分的客观理由，否则就要追究相关人员的责任。
独特性
IT项目的独特性在IT服务领域表现得非常突出，厂商不仅向客户提供产品，更重要是根据其要求提供不同的解决方案。即使有现成的解决方案，也需要根据客户的特殊要求进行一定的客户化工作，因此可以说每个项目都有区别。
项目的这种独特性对实际项目管理有非常重要的指导意义。项目主管必须在项目开始前通过合同（或等同文件）明确地描述或定义最终的产品是什么。如果刚开始要提供什么没能定义清楚，或未达成一致，则最终交付产品或服务时将很容易发生纠纷，造成不必要的商务和名誉损失。即便是定义清楚了项目的目标，但是客户单位仍然会经常调整实现指标，这种变更很难控制，这就需要项目组与客户单位有良好的沟通渠道，否则改来改去，永远改不完。
不确定性
IT项目的不确定性是指项目不可能完全在规定的时间内、按规定的预算由规定的人员完成。这是因为项目计划和预算本质上是一种预测，在执行过程中与实际情况可定会有差异。另外，在执行过程中还会遇到各种始料未及的“风险”，使得项目不能按原有的预测来运行。
针对不确定性，在项目管理中就要注意制定切实可行的计划。笔者在工作中就发现科研工作，特别是国家级的项目，往往有一个“后墙不倒”原则。也就是说，设定一个项目的最终完成时间，具体的实施过程中，时间进度的安排就没有计划。在具体实施中，这种方法的最终结果是要么后墙倒了，要么后墙勉强没倒，做出来的产品满足不了质量要求。
还有一种不好的做法是过度计划，即将项目中非常微小的事情都考虑清楚才动手，但如此“详细的计划”其实是在试图精确地预测未来，也是不切实际的，在执行中会发现难以与实际一致，而不得不频繁地进行调整。具体问题具体分析。尽管有项目计划，执行过程中仍会碰到各种各样意想不到的问题，且往往没有现成的处理方法，这就要求项目经理必须掌握必要的工具方法，掌握整体过程和关键要素，灵活面对，妥善解决。
几个迫切需要重视的问题
项目管理有一些规律，但是还要具体问题具体分析，如果照搬硬套肯定会事倍功半。下面三个案例就是笔者在管理中遇到过的，现在拿出来一起探讨。
管理新手的重要性
一个项目组除了主管，全是新手！其实能有几个项目主管会如此幸运，项目组成员全都身经百战经验丰富。很多人认为，新手加入在短时间内对项目毫无益处，不仅帮不上忙，还需要别人来传帮带。笔者认为恰好相反：新人的加入是将会给整个项目组带来一些新鲜的想法，挖掘和引导这种的想法对新人的培训和很快的上手工作是非常关键的。公司花了钱招来的新人往往经过了人事部门的过滤，都具备了一些基本知识，主管可以先给他们分配一些具体的工作，调动他们的积极性非常关键。
在培训新人时就应该注意：
项目内容培训，让他尽快了解项目组的工作内容，项目的方向、目的，用到的知识、技能；
给他在项目组中的角色做个定位，明确他的职责，并提供必要的支持；
告诉他项目组管理方面须注意的问题，让他尽快融入到项目组里来；
尽量与目前项目组的工作结合起来培训，如让他尽快熟悉项目已经完成的工作，告诉他以后的计划，以及他马上要做的工作等等；
保持良好的沟通，了解他的进展，根据实际情况调整培训计划。
管理文档的重要性
让项目主管最痛苦的事情莫过于：当一个重要成员半途离开项目组时，才发现他根本就没有留下任何可用的文档。天下没有不散的宴席，项目组的成员也是在动态调整中，文档就是成员之间交接的重要工具。很多主管很容易陷?quot重技术实现，轻文档"的误区。他们总是认为项目实施时间紧迫，为了节省时间，可以在项目收尾阶段突击写文档。要是项目周期稍长，到了最后，成员还会记得清清楚楚每个实现细节吗？没有文档的项目铁定是一个失败的项目。
从过程控制的角度看，项目的实施质量控制，最重要的就是文档的管理控制。通过文档来显示表明每个基线，每个成员的工作量和完成质量，达到项目的风险最小化。
管理平台的重要性
笔者最初的几个项目都没有管理平台，所以没有量化的概念，管理手段非常落后。去年笔者在公司率先引入了微软PROJECT2000作为核心的项目管理软件，并根据项目的需求，以现有的计算机网络系统（Network）为基础，建立了内部的INTRANET项目管理平台。经过一年多的使用达到了以下效果：
使用PROJECT2000建立项目计划信息共享门户，使技术人员、主管随时看到与自己相关的任务信息，并通过建立状态报告，达到了解技术人员各自工作完成情况；
利用研发内部网站、电子公告板等共享信息系统，提供有效的信息沟通途径；
根据项目计划，建立动态提醒机制；
建立项目数据管理系统(Data)：对与项目有关的数据和与数据有关的过程，进行有效地管理；
电子文档管理系统(Document)，对图纸、文件、资料等文档，采用集中管理的方式，进行有序地组织，实现充分的共享和重复使用，实现了通过IE浏览器访问项目文档功能；
建立数据记录体现变更控制记录，项目文档记录。
结束语
就中国现状而言，项目管理还是一个全新的尚待开发的领域，很多项目管理人员和笔者一样都是在实践中不断摸索和思考。
从现实来看，只有那些跨国公司和国内的大型企业才对项目管理提出要求；从教育来看，项目管理的系统教育基本上就是空白，甚至目前中国还没有项目管理这一学科设置。同时，在中国，你所能够获得的有关项目管理的出版物以及资料都极其有限。
好在国内的教育部门已经发现了这个问题，各种PMP的培训班广告也开始出现在各类媒体中。那么我们是否都需要这个一个证书呢？
曾记得庄子在《庄子·养生主》中谈到的解牛的庖丁，在外人看来，技艺高超的庖丁解牛时，一招一式，轻松自如，姿势优美，其节奏如美妙音乐的旋律。而庖丁自己在历经多年的实践后，解释他的高超技艺的境界是："以神遇而不以目视，官欲止而神欲行，依乎天理，批大隙，导大，因其固然?quot
项目管理还是有"天理"可循，假如有机会还是应该带着实践中的问题多看书多学习，最终会达到所谓的管理艺术。(IT工程技术网)
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）