如何成为一名项目经理
1.这个项目是什么，将做什么，是谁提出的，旨在解决什么问题。在国内很多客户都很不成熟的情况下，不要根据项目的名字去想象项目的目标。一个叫“办公自动化”的项目，很可能在你进入市场一个月后，发现客户实际需要的是一个计算机生产管理辅助信息系统。前期了解情况的工作越细致，惊喜就越少，项目的风险就越小。
2.这个项目涉及到哪些人，比如投资人，具体的业务利益相关者，项目完成后的运营者，技术主管等。在很多项目中，除了业主单位结构复杂之外，还会涉及到其他单位，比如工程监理公司、业主行业主管部门等。项目经理需要知道每个人对这个项目的想法和期望。提前了解各方面的看法和期望，可以帮助你在做项目遇到问题时，分析谁会以什么方式支持你，谁会出于什么目的反对你，从而提前做好准备，团结朋友共同对敌，让事情朝着你想要的方向发展。没有永远的朋友，也没有永远的敌人，只有一致的利益，这是作为项目经理必须牢记的；
3.在基本了解了客户的情况之后，接下来的事情就是了解我们公司各方对这个项目的看法。首先是高层领导是否重视，这决定了在你需要资源的时候，公司是否会按照你的要求提供最有力的支持。你需要做的是了解公司对这个项目的实际预期，是想把项目越做越大还是赚钱？无论你是想做一个样板项目还是只是敷衍了事，公司领导对项目的态度决定了你做这个项目的策略，这个策略方针会对你的项目规划产生直接影响；
在制定整体项目计划之前，你也要粗略的算一下自己手里的资源。首先是时间。现在市场竞争激烈，很多项目往往被要求在几乎不可能的时间范围内完成。对于这一点，你在制定项目的风险控制方案时要充分考虑。其次是人员，根据项目预算和以往经验，粗略计算未来项目团队会有多少个角色，每个角色目前是否被公司占用，是否能被这个项目充分利用，是否需要招聘一些其他人员，招聘的准备工作要尽早开始。最后是一些设备的准备，项目需要的关键设备要尽早预定，无论设备和其他发生什么都是在浪费你的时间。
是时候做一个项目描述了。一个好的项目说明书不仅要清楚地描述要做什么(主要是关于做什么，而不是怎么做)，还要说明如何彻底检查。换句话说，它不仅解释了要做什么，还让客户的业务人员(他们一般不懂技术)知道项目是做什么的。简而言之，项目描述描述了项目做什么，每件事做到了什么程度，以及如何检查每个结果。
6.是时候做一个总体规划了吗？不，现在你已经知道了客户的目标和你所拥有的资源，在制定计划之前，你需要和你的经理和客户就资源进行充分的沟通。因为很多资源还不清楚，你需要写一份报告，详细分析这个项目的风险和对资源的需求。有些问题解决不了会怎么样。如果资源不足，高层应该改变策略，增加对这个项目的投入。即使条件允许，有些公司也会放弃这个项目。总之，没有人能完成不可能的任务。如果项目经理不能尽早发现风险，那么他只能是烈士。
7.知道了要做什么，你的筹码，你对这个项目的整体策略，是时候成立项目组了。很多项目经理没有权利选择自己的团队成员，那就努力发挥你的影响力去寻找那些你想要的。成员的构成根据项目不同差别很大，很难有什么具体要求。但是，必须有精通客户业务的人。很多小项目，这个人就是项目经理本人，大项目会配备行业专家，这样和客户的沟通就不会鸡同鸭讲，双方都能相互理解。我经常看到的是，我们的技术人员在和客户交谈的时候，满口专业术语，结果客户一头雾水。反过来，他指责客户不懂技术。其实知道自己想做什么的客户已经是很好的客户了，不知道自己想做什么，更不用说怎么做的客户，比比皆是，但是要明白，是客户选择了你，而不是你选择了客户。只有和客户在一起，才能得到报酬，才能心平气和。
对于需求每天都在变化的客户，你必须提前制定规则:
第一，统一联系人。客户指定一个人与项目团队沟通。张和王两位领导你都不能说几句。如果他们不同意，你就得得罪领导的选择。因此，必须在项目开始时制定规则。我的项目组只认可一种意见。有什么要求先统一再找我。我不想卷入你们内部业务部门之间的矛盾。
第二，所有的需求变化都要写，记住这一点！这样做有很多好处:
*有书面证据，他想以后改。当你有了他之前要求的证据，就告诉他:你之前就这么说了；
*便于需求变更管理，需求如何慢慢演变的历史可以看得一清二楚，从而更深入地了解客户的目的；
*对顾客来说，动动嘴最方便。反正你是没花他的资源就做了，所以要求是否合理，是否符合项目目的，他是不负责任的。但如果让他写书面请求并签字盖章，他会谨慎很多，而且一旦写了，思想会更深刻，很多不合理的请求都会胎死腹中；
8.现在你要面对三组人:你的领导，你的团队成员，你的客户。你的主要工作将是与这些人沟通，让他们知道你打算做什么，以及你希望他们什么时候做准备。既然沟通这么重要，那么提前明确沟通的原则也很重要。很多沟通原则都是潜规则。如果你在一个部门待久了，应用这些规则是理所当然的。但是，你现在面对的是多个部门，甚至多个单位。不把沟通规则讲清楚，以后会吃亏的。以下这些东西看起来很无聊，但其实很有用:
首先是规定信息流动的方式和媒介，是推还是拉。推送是指项目经理会主动发布信息，无论是通过电话、邮件还是书面形式，确保信息传递到每个人。这种情况适合人少的小项目；拉意味着项目经理就像一个web服务器。如果你需要任何信息，问他。当然，没有一个项目经理把自己搞得这么累，他会通过向公共媒体发布信息来发布信息，这是一个简单的白板，稍微复杂一点的是项目的公共信息交互区。潜规则是，如果我发给你，不要说我没告诉你。这样说看起来很无聊，但实际上涉及到信息传递不完全的责任问题。当然，这些都是一般的方式，不要绝对化。一般情况下，主动沟通和被动获取并存，尤其是对于领导，项目经理要主动与他们沟通。
第二个问题是文档。很多人害怕写文档，但是项目经理一定要牢记一个道理“好记性不如写的差”。为什么有时候说不清楚？因为没有证据。所以项目经理一开始就要跟客户说清楚，有些文件是必须要签字的，比如项目经理的项目日志，至少每周都要客户签字。另外，凡是达成* * *谅解的事情，比如会议纪要，甚至领导的讲话记录，都要写成文件，由双方签字，以便日后争议结束时，有据可查。记住:你说的和你没说的一样。只有在你写下并签字后才会发生。还有一些问题，比如你提交的报告，给了领导(包括自己的领导和客户领导)一道选择题。结果领导不肯批，让你无所适从，耽误了进度。这时候你可以等，但要注意留下记录，注明责任人；另外，如果你一开始就和领导达成一致:如果你在指令提交后三天没有得到领导的回复，对方也会同意，这样你就掌握了很多主动权。再比如不同事件的审批流程:项目日志中记录了什么级别的事情，什么级别的事情需要双方项目经理签字，什么级别的事情需要双方领导签字。事先想的越周到，在以后的工作中就会越主动。
9.嗯，我们已经做了大量的前期工作，定义了一些游戏规则。现在是时候坐下来制定计划了。这一节，任何一本关于项目管理的书都会讲得比我好，我就少写点，说点自己的经验。首先是找到几个关键的团队成员，比如客户业务专家、系统分析师等。，做项目模块划分工作。项目分成几个块，每个块完成什么，模块之间如何交换信息等等。需求定义了做什么的问题，但是这里我们说的是怎么做。这里我想强调一点:
实现一个目标有很多方法。你应该选择你最熟悉的那个，而不是看起来很完美的那个。这个想法会降低你项目中的很多风险。有时，客户会被一项新技术所打动，坚持要你采用这项新技术。你应该告诉他，如果你选择我做这个项目，你应该允许我用我喜欢的方式做事。新技术之所以吸引人，是因为吃亏的人不多，我不希望你成为第一个受害者。使用计划会让你的工作更加清晰。比如使用微软的项目软件，你填表后就可以知道这个项目需要做多少事情，每件事情需要哪些资源，它们之间的关系如何，需要多长时间，完成后有什么标志。所有的结果最终都以甘特图的形式显示出来。当你完成这个表格后，你会惊讶地发现甘特图上的项目结束时间会远远落后于你的计划结束时间(签合同的人绝不会先征求你的意见)。
当然，学过项目管理的人会讲很多WBS和优化路径，但我的经验是，这些东西你要等到计划时间结束才能安排。如果你没有遇到这个问题，在我祝贺你选择了一份轻松的工作之前，请确保你已经列出了所有要做的事情，并正确评估了它们需要的时间。这个时候你就要考虑牺牲一些任务的时间(这也意味着质量)。根据什么标准？这个项目的策略！我们在第三节提到的策略。我的经验是，如果什么都赶，结果可能是十件事都没做好。想想多么失败。所以，如果你把你的资源投入到你熟悉的、有把握的事情上，最后的结果会是十件事情，其中三件已经做成优秀的产品，三件已经完成，四件因为某种原因推迟。成绩单是不是好看多了？战略决定优先级，正确安排优先级是一个项目经理能力的主要体现。
好了，现在项目已经完成了前期工作，了解了项目目标，明确了手头的资源，制定了项目战略，然后编制了项目的总体方案，项目进入实施阶段。进入这个阶段是项目经理相对自由的时候。不像前期，项目经理要像记者一样到处接触不同的人，了解他们在说什么，努力猜测他们在想什么，他们的真实目的是什么。那是最累的事情。当然，小项目的项目经理本身往往也是一个资源，要做很多事情。这个时候，他比谁都苦。这期间项目经理的主要工作就是和客户领导以及自己的领导保持沟通。
与客户领导沟通时要特别注意。除非需要对方支持，否则需要具体。否则就告诉他一切都好，态度积极。千万不要说领导不了解的细节，比如:“王主任，最近项目进展正常，就是JVM经常漏点内存……”王主任:“(* &；$@@"。向自己的领导汇报也要注意这个问题。除非他是技术专家，你需要他的技术经验，一般可以汇报进度是否正常，以及出现问题时你的对策和计划。有些需要他支持的地方，比如资源调用，需要详细说明。和团队成员开会，除了一些项目进度跟踪会，还有很多研讨会，需要集思广益解决问题。很多参与者都是技术人员，特点是注重细节，缺乏大局观，有点消极悲观，自尊心强(如果总结错了，欢迎拍砖)。
所以，作为会议主持人，只要你负责提问，记录他们的意见，就千万不要当评委。一个问题有许多方面。从不同的角度看，现象完全不同。想想一个盲人摸大象的故事。这些往往精通某一方面的技术人员，从自己的角度发表意见。除非有一些非常特殊的情况，你应该认为他们提出的方案从他们的角度来看是最合理的。你的强项是把握事情的轻重缓急，评估各方面的轻重缓急，从而根据他们的意见拿出一个合适(不正确)的方案。所以在会上，你要充分尊重每个人和他的意见，表扬那些提出更好意见的人，千万不要把会议带入无休止的争论中(你要让大家知道，事情不是非黑即白的，而是多样的，唉，我们的教育造成了麻烦……)。会后，你自己写文件，做决定。会上大家的面子都照顾到了，所以自我实现的阻力很小。如果你还有意见，可以私下找他谈。如果你还是说服不了他，就要让他知道，因为这个项目是你负责的，你承担风险，所以这个轻重缓急要由你来判断。一个组织的高层不一定比普通成员高，但是他要承担组织的风险和信息的不对称，所以他对事情轻重缓急的判断肯定比下属好。
在开发过程中，内部管理应注意始终强调验收目的的思想。必须检查每项任务的最终交付成果。比如界面要求优雅、简洁、活泼，不知道怎么检查这个要求。所以在给开发团队分配任务的时候，要考虑如何检查结果。例如，我看到一个计划，其中一个任务开发人员熟悉EJB编程。在这个任务中，除了让这些人参加一些专业的认证考试，成绩会很难查。因此，对于项目经理来说，考虑如何检查结果以及如何将结果交付给客户总是很重要的。听说有的老项目经理拿到的是倒排计划，就是先看如何验收，验收标准，再决定工作计划。很多项目已经开工很久了，不知道怎么验收，所以这个项目出现问题的可能性很大。做项目是为了验收。我们的角色不是一个研究机构。我们的目的是付出这么多劳动后得到结果。
另外，我插一句:我强烈不赞成去客户的现场开发。尤其是一大群技术人员直接和客户沟通，容易造成冲突和矛盾(技术人员的性质决定的)。我的做法是项目经理和项目实施人员去现场，软件开发人员还在公司做项目。项目实施者是初级项目经理。他们了解自己的产品和一些客户的业务。关键是他们有很好的沟通能力，俗称“脸皮厚”。他们是客户和R&D人员之间的桥梁，他们的职业方向也非常灵活。他们未来可以转向很多方向，比开发商的范围要广得多。
那么，我们来说说需求变化这个最让人头疼的问题。变更通常分为两种:一种是部分变更原目标，即需求变更；另一种是目标没有改变，但是客户对目前的实现方式不满意，从流程的实现到界面的布局。遇到这种情况是不可避免的，主要是因为事先沟通不够，客户随着项目的进展，逐渐想清楚问题，改变之前的想法。这时，如果你需要改变，并且你的策略允许这样做，那么注意以下几点:
1.确保之前的文件是记录之前结论的文件，以及客户是否已经签字。如果没有，赶紧停下手上的工作，赶紧和客户确认你的方案，然后让他签字，避免以后说话没有证据；
2.与客户坐下来，亲自讨论他修改的根本目的是什么。有没有一个替代方案可以达到同样的目标，但对你来说更便宜？
3.项目初期工作)定义变更流程，一般由客户指定的一个人签字(否则客户的每个领导都有权插一杠子，你就报废了)，然后以正式项目文件的形式提交给你。然后你做一个评估和分析，分析对成本和进度的影响，你的领导同意后出具相应的意见，主要是说明更改设计的原因和指出不确定的后果(这个东西先写好)然后让客户签字。医院给病人做手术前，你见过家属签的免责条款吗？是的，只要学会这一点，让每个人都意识到任何改变都是有成本和代价的。
系统开发告一段落后，我将进入客户培训和系统验收阶段。在这个阶段，我一般会注意以下几个问题:
第一，在给客户培训之前，多关注一些表面功夫。很多程序员认为，系统的逻辑核心是否正确是关键。至于界面和界面上文字的准确性，就无关紧要了。而且训练的时候也很容易想出来，下面听的人不知所措，训练效果自然可想而知。我的经验是，如果你在多次测试后仍然不确定逻辑是否符合要求，你至少应该在界面上多花一点功夫。注意每个界面的布局，文字和链接的正确性等。总之，不要让客户看到他不该看到的东西。文件方面，至少准备两份文件:用户手册和培训手册。这两份文件很多内容是一样的，但是角度完全不同。用户手册往往是站在系统设计者的角度，按照自己的思路，以模块的形式解释系统的操作和功能；至于培训手册，一定要站在客户的业务人员的角度，根据每个角色对不同业务的处理，如何利用这个系统的一系列功能来达到目的。所以在第一次培训前，系统界面是否完整正确，培训文档是否齐全都是关键因素。如果第一枪失败，以后会有很多麻烦。
作为项目经理，脑子里其实就那么几件事:做什么，做到什么程度，怎么交付，手头的资源，每件事的优先级。尽可能快地储蓄是人类的梦想。这四个方面是矛盾的，属于典型的要马跑不吃草的类型。在考虑问题的轻重缓急时，我们往往把速度放在第一位，各方领导都会给你一个期限，所以保证进度是第一位的；省是其次，企业的根本目的是盈利。如果不能增加收入，至少要控制开支；好是第三，没办法，大家都想精益求精，但是没有强大的资源保障，质量只好先牺牲；最后，还有很多客户的诉求。如何降低客户的期望值，让客户从理想回归现实，也是项目经理的工作。
验收前，除了做好文档工作，多花点时间搞清楚客户的工作流程也很重要，这里就不多说了。
我最大的接受体验就是证明的问题。就是永远不要让客户认为你必须有证据证明你的系统是可以的。这样，你就没救了。微软那么多天才，XP天天打补丁。这是不可能的，你也无法证明。你要让客户知道，所谓的验收就是我按照测试文档运行测试用例，结果与预期结果一致，就应该认为是通过了。而且一些小错误在验收后是允许改正的，他可以对测试用例进行评论。因此，双方应在验收前确认测试计划和测试用例。如果他认为系统不符合要求，那么他应该提供证据证明系统偏离了最初的设计。所以，参照法律概念，千万不要把证据倒置。另外，认为制度完善了才能被接受也是错误的。软件开发合同必须注明验收后维护期的费用。否则客户担心一旦接受了，得不到你的支持，自然你这个项目经理也很难交作业。
但是，当初你说想考二级建造师...但个人认为二级建造师可有可无...因为现在2年级无处不在...想要的话就努力考1级。...
当然，你有时间也可以考..毕竟有多个证也不是坏事。