一个项目经理的经验总结

                                                                 一个项目经理的经验总结

 

本人作项目经理工做多年，感到作这个工做最要紧的就是要明白什么是因地制宜、因势利导，只有最合适的，没有什么叫对的，什么叫错的，项目经理最忌讳的就是完美主义倾向，尤为是作技术人员出身的，喜欢寻找标准答案，耽误了工做进度，也迷茫了本身。如下是本人一些作项目的我的体会，写出来供你们指点，在讨论过程当中共同提升水平。
项目开始阶段是一个最重要的阶段。项目经理在接手一个新项目的时候，首先要尽量地多从各个方面了解项目的状况，如：
　　

1.这个项目是什么项目，具体大概作什么事情，是谁提出来的，目的是解决什么问题。在国内不少客户都很不成熟的状况下，千万不要根据项目的名称望文生义地去想象项目的目标。一个名为“办公自动化”的项目颇有可能在你进场之后一个月才发现客户其实须要的是一个计算机生产管理辅助信息系统系统。前期了解状况的工做越详细，后面的惊讶就越少，项目的风险就越小。


2.这个项目里牵涉哪些方面的人，如投资方、具体业务干系方、项目建成后的运营方、技术监督方等等，不少项目里除了业主单位的结构很复杂之外，还有一些其余单位也会牵涉进来，如项目监理公司、业主的行业主管机构等。项目经理须要了解每一个方面的人对这个项目的见解和指望是什么。事先了解各个方面的见解和指望，可让你在作项目碰到问题的时候，就每件事情分析哪些人会在什么方面支持你，哪些人会出于什么目的反对你，从而提早准备联合朋友去对抗敌人，让事情向你所但愿的方向发展。没有永远的朋友，也没有永远的敌人，只有一致的利益，这句话做为项目经理是必定要记住的；


3.基本了解了客户的状况后，下面的事情就是了解本身公司各方面对这个项目的见解。首先是高层领导是否重视，这个决定了你在须要资源的时候，公司是否会根据你的要求提供最有力的支持。领导口头确定是说支持的，你须要作的是了解公司对这个项目的实际指望，是想把项目越作越大仍是想赚钱？是想作样板工程仍是干脆想敷衍了事，公司领导对项目的态度决定了你作这个项目的战略，而这个战略方针将对你作项目计划产生直接的影响；
　　


4.在作总体项目计划前，还要大体计算一下你手上的资源。首先是时间，如今市场竞争激烈，每每不少项目要求在几乎不可能的时间范围里完成。对于这一点，你在作项目的风险控制计划的时候要充分考虑。其次是人员，根据项目预算和已往经验，大体计算一下将来的项目小组有多少种角色，每一个角色目前公司是否有人，是否能彻底归这个项目使用，是否须要另外招聘一些人员，招聘的准备工做要尽早启动。最后就是一些设备的准备，项目所需大件关键设备要尽早预约，之后无论发生设备等人仍是人等设备的状况，浪费的都是你的时间；


5.如今是作项目说明书的时候了。一份好的项目说明书不只将要作的事情描述得很清楚（主要是讲作什么，而不是说怎么作），并且把如何检查也说明得很透彻。也就是说它不只说明白了要作哪些事情，也让客户的业务人员（通常不懂技术）知道项目作成什么样就算完成了。简单地说，项目说明书描述项目作哪些事情和每件事情作到什么程度以及如何检查每个结果。
　　


6. 是到作整体计划的时间了吗？不，你如今已经知道了客户的目标和你手上的资源，那么作计划之前，你还须要和你的经理和客户充分沟通资源的问题。由于不少资源是还不明确的，你须要写一份报告，详细分析这个项目的风险以及对资源的需求状况。若是一些问题不能获得解决的话，将发生什么样的后果。若是资源不够，就要高层改变策略，增长对这个项目的投入。甚至在条件许可的状况下，有些公司会放弃这个项目。总之，没有人能完成一个不可能完成的任务，若是项目经理不能尽早发现风险，那么就只能去当烈士了。


7.明白了要作哪些事情和你手上的筹码以及你作这个项目的整体策略，如今是成立项目小组的时候了。不少项目经理都没有本身选择组员的权利，那么，就尽可能发挥你的影响力去寻找那些你想要的人吧。成员的组成根据项目不一样，相差较大，很难有什么具体要求，可是，必定要有精通客户业务的人，不少小项目里，这我的就是项目经理本人，大项目里会配备行业专家（Industry expert），这样和客户沟通起来才不会鸡同鸭讲，双方才能够相互理解。我常常看到的状况是 咱们的技术人员和客户交谈时满口的专业术语，结果搞得客户一头雾水，反过来，他还指责客户不懂技术。其实，明白本身想作什么的客户已是很好的客户了，不知道本身要作什么，更不懂怎么作还要指手画脚的客户处处存在，可是要明白，是客户选择了你，而不是你选择了客户，有了客户你才有工资拿，心平气和一点吧。 对于这种需求每天变的客户，你就必定要事先作好规矩： 1、统一联系人，客户指定一我的和项目组进行沟通，不能张领导、王领导都来讲几句，若是他们意见不一致，那你只有得罪领导的选择了，因此，项目的最初就要定好规矩，我项目组只认一个的意见，有什么要求大家内部先统一再和我谈，我不想卷入大家内部业务部门之间的矛盾之中； 2、全部需求变动所有要有书面文字，这点切记！这样作好处多多： *有书面证据，之后他还想改，你有了他之前要求的证据，告诉他：你之前但是这么说的； *便于需求变动管理，需求如何慢慢演变的历史能够看清楚，从而更深切地体会客户的目的； *对于客户来讲，嘴巴一动最方便，反正是大家作，不花他的资源，因此要求是否合理，是否和项目的目的一致，他是不负责任的。可是若是要他写书面要求，还要签字盖章，他就要谨慎多了，并且一写东西，思想就会更加深刻，不少无理要求也就这样胎死腹中了； 8.如今你要面对三群人：你的领导、你的组员和你的客户，和这些人沟通，让他们知道你打算怎么作，何时要他们作什么准备这些事情将是你的主要工做。既然沟通这么重要，那些事先定义一下沟通的原则也是一件很要紧的事情。不少沟通原则都是潜规则，若是你在一个部门时间作长了，对这些规则的运用以为是一件理所应当的事情，可是，你如今面对的是多个部门甚至多个单位，不把沟通规则说清楚，你之后就会吃亏。下面的东西看起来无聊，其实仍是很管用的： 第一个是规定信息的流动方式和介质，是推仍是拉。推的意思就是项目经理将主动发布信息，无论经过电话、邮件仍是书面方式，保证将信息传达到每一个人。这种状况适合小项目，人少；拉的意思就是项目经理就是一个相似web服务器，你本身须要什么信息就去问他。固然，没有项目经理把本身搞得那么累，他会用发布信息到公共介质的方式公布信息，简单的是白板，复杂一点的是项目的公共信息交互区，潜规则就是我发了你没去看就不要说我没告诉你。说这些看似很无聊，其实里面牵涉信息传达不彻底的责任问题。固然，这些都是指通常的方式，并且不要绝对化，通常状况下，主动沟通和被动访问是同时存在的，尤为是对领导，项目经理更加应该主动去和领导沟通。 第二个问题就是文档问题，不少人怕写文档，可是项目经理必定要牢记“好记性不如烂笔头”的道理。有理有时候为何会说不清呢？就是由于没有证据。因此项目经理开始就要和客户说清楚有些文档是必须签字的，好比项目经理的项目日志，每一个星期至少让客户签字，另外全部达成共识的东西，好比会议纪要，甚至领导的讲话记录，都要写成文档，双方签字，这样之后扯皮的时候，就能作到有据可查。记住：说了的就和没说同样，只有写下来你们签字后才算真正发生了的。还有一些问题，好比你提交的报告，给领导（包括本方领导和客户领导）作一个选择题，结果领导压住不批，让你无所适从，结果拖延了进度。这时候，你能够等，可是注意要留记录，标明是谁的责任；另外，若是你在开始阶段就和领导商定：若是批示提交三天后没有获得领导答复就算对方赞成，这样你就会主动不少。再好比不一样事件的审批流程问题：什么等级的事情记录在项目日志里、什么等级的事情要双方项目经理专门签署备忘录、什么等级的事情要双方领导出面签署合同附件等等。事先想得越周到，之后的工做就越主动。 9.好了，作了不少前期工做，定义了一些游戏规则，如今是坐下来作计划的时候了。这一节，任意找一本项目管理的书都会说得比我好，因此我就少写一点，说一些本身的体会就是了。首先是找几个关键组员，好比客户业务专家、系统分析员等等，作一下项目模块划分工做。项目分红几块去作，每一块完成什么，模块之间的信息如何交换等等。需求定义的是作什么的问题，而这里说的是怎么作的问题。这里要强调一点： 完成一个目标有不少种方式，你要选一种你最熟悉的，而不是看上去最完美的，这个思路会让你的项目减小不少风险。有时候客户会被某种新技术打动，坚持要你采用那种新技术，你就应该告诉他：你选我作这个项目，就应该允许我采用本身最喜欢的方式作事情，新技术之因此有诱惑力，就是由于吃亏的人还很少，我不但愿你成为第一批受害者。采用一个计划会让你的工做更加明确，好比用微软的Project软件，你填写完表格之后，就能够知道这个项目有多少件事情要作，每件事情须要什么资源，他们之间的先后关系如何，消耗的时间有多长，完成后有什么标志等。全部的结果最后用一个叫作干特图的形式表现出来。你作完这个表之后会惊奇地发现，干特图上项目的结束时间会远远落后于你的计划结束时间（签合同的人永远不会先征求你的意见的）。 固然，学过项目管理的人会大谈什么WBS、优化路径之类的东西，可是个人经验是你再优化也不可能把这些东西安排到计划的时间结束。若是你没碰到这个问题，在我恭喜你挑了一个轻松活以前，请你再去确认你是否罗列了全部要作的事情和正确评估了他们所须要的时间。这时候，你就要考虑牺牲一些任务的时间（也意味着质量）了。按照什么标准牺牲？这个项目的战略！咱们在第三节提到过的战略。个人经验是若是你什么都赶进度，其结果可能就是十件事情你一件也没作好，想一想多么失败啊。因此，把资源投到你熟悉和有把握的事情上，最后的结果是十件事情，你有三件作成了精品，三件完成，还有四件由于某些缘由延误，成绩单是否靓丽了不少呢？战略决定优先级，而正确排列事情的优先级是一个项目经理能力的主要体现。 好，如今项目已经完成了前期工做，了解了项目的目标、搞清楚了手上的资源，制定了项目的策略，而后编制了项目的总体计划，项目进入实施阶段。进入这个阶段反而是项目经理比较空闲的时候，不像前期的时候项目经理要象记者同样处处和不一样的人接触，搞清楚他们在说什么，努力猜想他们在想什么和他们的真正目的，那才是最累人的事情。固然，小项目的项目经理每每本身也是一个资源，要作不少事情，这时候反而比谁都苦。项目经理这段时间的主要工做是保持和客户领导以及本身领导的沟通。 和客户领导沟通时特别要注意，除非你须要对方给你支持，那么你才须要讲得具体一点，不然，告诉他一切正常就能够了，并且态度要积极一些，千万不要说一些领导不懂的细节，好比：“王局长，最近项目进度还算正常，就是JVM常常发生一些内存泄漏的状况…”王局长：“(*&$@@”。和本身的领导汇报也要注意这个问题，除非他是一个技术高手，你须要他的技术经验，不然通常就汇报进度是否正常以及有问题时你的对策和打算就能够了，有些须要他支持的地方，好比资源调用须要说详细一点。和组员开会，除了一些项目进度跟踪会议之外，还有不少讨论会，须要你们用头脑风暴方法给出解决问题。与会人员不少都是技术人员，他们的特色是注重细节、缺少大局观、有点消极悲观、自尊心强（若是总结得不对，欢迎你们拍砖）. 因此，你做为会议的主持人，只要负责提出问题和记录下他们的观点，千万不要作评判者的角色。一个问题，有不少方面，从不一样的角度看，现象是彻底不一样的，想一想盲人摸象的故事吧。这些技术人员，他们每每精通一个方面，就本身的角度发表看法，除非一些很特别的状况，你都应该认为，他们提出的方案，从他们的角度来看是最合理的。你的长处是掌握事情的优先级，评估各个方面的轻重缓急，从而根据他们的意见得出一个合适的（而不是正确的）方案。因此，在会议上，你要充分尊重每个人和他的意见，夸奖那些意见提得比较好的人，千万不要把会议带入无休止的争论（你要让你们知道事情不是非黑即白的，而是多元的，唉，咱们的教育惹的祸…）。会后，你本身写文档，作决定。会议上你们的面子都被照顾了，本身实施起来的阻力就小，若是还有意见的，你就私下找他聊，若是还不能说服他，你就要让他明白，由于你负责这个项目、你担当风险，因此，这个优先级应该你来判断。组织中的高层，并不见得水平会比通常的成员高，可是，他要承担组织的风险，加之信息的不对称性，因此，对事情的优先级的判断确定比下属强。 在开发过程当中，内部管理还要注意的一点是时刻强调以验收为目的的思想，每一个任务的最终可交付成果必定要是能够被检查的，好比，【界面要求：美观大方、简洁明快】，这个要求我就不知道如何检查。因此，给开发小组布置任务的时候就要考虑如何检查结果，好比我见过一个计划，里面有一个任务【开发人员熟悉EJB编程】，这个任务，除了让这些人去参加一些专业认证考试，不然，结果很难被检查。因此，时刻考虑如何检查结果、如何向客户交付是项目经理一直要注意的事情，我据说有些老项目经理拿到项目是倒排计划的，即首先看如何验收和验收标准，而后决定工做计划。不少项目开始了好久，还不知道如何验收，那么这个项目出问题的可能性就很大了。作项目就是为了验收，咱们的角色不是研究机构，咱们的目的就是在付出那么多劳动后获得结果。 　　 　　 另外我插一句：我是极其不主张到客户现场开发的。尤为是一大群技术人员直接和客户交流，很容易引发冲突和矛盾（技术人员的本性决定的）。个人作法是项目经理和项目实施人员到现场，软件开发人员仍是在公司作项目。项目实施人员就是初级项目经理，他们了解本身的产品，懂得一些客户的业务，关键是在于他们具备良好的沟通能力，俗称“皮厚”。他们是客户和研发人员的桥梁，其职业方向也是很机动灵活，之后能够有不少方向能够转，比开发人员的路要宽得多。 接着，咱们再谈谈最让人头痛的需求变动问题。变动一般分为两种：一种是部分更改了原先的目标，即需求变动；另外一种是没改变目标，可是客户不满意目前的实现方式，大到流程的实现，小到界面的布局，都是属于这类。碰到这种状况是难以免的，主要是事先沟通的不够充分和客户随着项目的进展，慢慢想清楚了问题，改变了之前的思路。这时候，若是须要改而且你的战略是允许这种状况的，那么注意下面几点： 　　 1. 确保之前的文档，就是记载着之前的结论的东西，客户是否签过字，若是没有，赶忙把你的工做停下来，赶快再和客户本身确认一下你的方案，而后让他签字，避免之后说话没有凭据； 　　 2. 和客户坐下来，探讨他修改的根本目的是什么，是否是有一样能达到相同目的，可是对你来讲有代价更小的选择？ 　　 3. 明确更改流程，通常是客户指定一人签字（不然客户每一个领导都有权力来插一杠子，你就废了），以正式项目文件的方式提交给你，而后，你作评估分析，分析对成本、进度的影响，在你的领导赞成后，出相应意见书，主要是要说明更改设计的缘由和指出由此带来的不肯定后果（这个东西先写出来，后面若是真的发生了，至少不是你的错）。而后再让客户在上面签字。见过医院给病人作手术之前让家人签的免责条款吗？对，就学习那个，让你们都意识到任何的更改都有成本和代价。 系统开发告一段落后，就进入客户培训、系统验收阶段，这个阶段，我通常会注意如下几个问题： 　　 1、给客户作培训前，多注意一些表面功夫。不少程序员认为，系统的逻辑核心是否正确是关键，至于界面如何，界面上的用词是否准确，那是可有可无的问题，并且培训的时候也是信手拈来，想到哪里说到哪里，下面听讲的人不知所云，云山雾罩，培训效果天然能够想象。个人体会是，给客户作培训的版本，若是你在作屡次测试之后仍然不能肯定逻辑是否合乎要求，那么，你至少要在界面上多花一点功夫。注意每一个界面的布局、用词、连接的正确性等等，总之不要让客户看到一些他不应看到的东西。文档方面，准备至少两个文档：用户手册和培训手册。这两个文档的内容不少都是一致的，可是角度彻底不一样。用户手册每每是站在系统设计者的角度，按照本身的思路，分模块讲解系统的操做和功能；而培训手册，必定要站在客户业务人员的角度，根据每一个角色面对不一样业务的办理，如何经过使用本系统的一系列功能来实现目标。因此，第一次培训之前，系统界面是否完整正确、培训文档是否完备都是很关键的因素，第一炮打不响，之后就麻烦不少。 做为项目经理，其实脑子里就是几样东西：作哪些事情、作到什么程度、怎么交货、手上的资源以及各个事情的优先级。所谓多快好省那是人类的梦想，这四个方面都是相互矛盾的，属于典型的又要马儿跑，又要马儿不吃草的类型。考虑问题的轻重缓急方面，每每是把快放在第一位，各方领导都会给你最后期限，因此保进度是第一位的；省是第二位的，企业的根本目的是盈利，若是收入不能增长的话，至少费用要控制住；好是第三位的，没办法，谁都想精益求精，可是，没有强大的资源保障，质量只好先牺牲了；最后是多，客户的要求源源不断，如何下降客户的指望值，让他们从理想回到现实也是项目经理的份内工做。 　　 验收前，除了作好文档工做，便可交付成果之外，多花时间搞清楚客户的作事情流程是很重要的事情，这些在前面已经有所说起，这里就再也不多说。 　　 我对验收最大的体会就是举证问题。即千万不要让客户这么想：你必须有证据证实你的系统是没问题的。这样你就没戏了，微软那么多天才，作了XP还每天打补丁，要你的程序没问题，既不可能，你也没办法拿出证据。你要让客户明白，所谓验收，就是我按照测试文档的测试用例跑一遍，结果和预期结果一致就应该算经过了，并且还允许有一些小错误留在验收后改正，他能够对测试用例提意见。因此，验收前双方要确认测试计划和测试用例。若是他认为系统不符合要求，那么他应该举证，证实这个系统和最初设计相背离的。因此，参考法律概念，千万不要举证倒置。另外，认为系统完美了才能验收的想法也是错误的，软件开发合同里必定要注明验收之后维护期的费用问题，不然，客户担忧一旦验收就得不到大家的支持，天然不配合验收，那么，你这个项目经理就很难交功课了。