1、理清了PMBOK对于项目管理的思路，明白了学习PMBOK不一定就能把项目管理好，但是，完整的项目管理理论配合实践经验，完全可以使项目管理水平得到大幅提升，在巨人的肩膀上，可以走的更快。（好像是看的更远？这句话是谁说的来者？）
       2、这次培训相当于PMP的培训，有过这次培训之后，就可以直接报考PMP了，不需要再参加培训了。（可以省5、6千块钱，太有诱惑力了，又赚了公司一笔！不过对于我也能考PMP，我没什么信心，和培训的老师比起来，我的差距太大了）。
       3、非常后悔上次培训没有认真学习基础知识，搞得一些基础知识全不知道，白天听完课，晚上还得看书。（这当然不能怪我，只能怪那个老师讲课的水平和《大唐双龙传》比起来差距太大，要怪只能怪那个老师和《大唐双龙传》！）
       这次培训结束后，我一直想，考PMP，不考PMP，这是个问题！最后还是决定考，毕竟通过考试，才能强迫自己系统的学习PMBOK，否则，对于我这种懒人来说，系统学习只能是空话。
       在提交了考试需要的资料，并交纳了3900元报名费之后，我开始准备考试了（这个钱，能不能想办法让公司交，嗯，这又是个问题！）。先上网，看看别人的经验，我google，项目管理联盟论坛，真是个好地方，我看看，好，果然有几条先人的经验，我照做就行了，这就是踩在巨人的肩膀上……，很抱歉，我又一次引用了不知出处的话（好像和牛顿有点关系，又好像没有？）
       我总结了几条，摘录下来，给后人参考（这样说好像我成了先人了，不过后人如果为了走的更快要站在我的肩膀上时，我郑重提醒，我的肩膀窄，踩得时候慢点，别掉下来：-）：
       1、老金的《如何准备pmp考试第二版》，这本书一定要有，别的书都可以不看，这本书必须看！当然，PMBOK04版出来之后，老金会不会写《如何准备pmp考试第三版》，不得而知，不过，这本书确实对考试相当有帮助。
       2、通读PMBOK，千万不要像我们上学的时候，画什么重点，全书都是重点，要通读！最少精读两遍，粗读n遍。一开始，可能觉得什么都知道，结合模拟题，再读，可能又觉得什么都不知道，这就对了！应该再结合模拟题，再读，就真的知道了。
       3、模拟题，这是必不可少的，去找一些题来做，可以更好的帮助你通过考试。
       4、保证复习时间，考前一周建议请假，专心复习，考前突击对于通过考试觉对大有帮助！
       5、考试的时候，不要着急，时间足够，很可能会觉得时间太漫长了。
       我想，只要认真复习，通过考试不是很难，难的是，通过学习，确实领悟到了PMBOK理论的实质，帮助自己提升了项目管理的水平，真正去做项目，而不是"熬"项目，这样，PMP认证才会有真正的价值。
       顺便提一下，我于今年6月份通过了PMP认证，160分，不算很高，可这不能怪我，都是《大唐双龙传》，复习期间，我又重新温习了一遍…………
      所以说，PMP考试通过的第六条，也是最重要的一条：
      一定要看《大唐双龙传》！

       我将基本按照这五部分，描述在这个项目中，是如何将项目结束的。
      1、启动
       该项目的客户属于我们公司长期合作的客户，客户与销售经理的关系非常密切，客户需要开发该软件时，直接找到了我们公司，我作为技术负责人和销售经理一起和客户交流了该软件的情况。在第一次接触中，我感到客户对于自己将要开发的软件的需要还不是十分清楚，但是客户方的项目经理，也就是该税务局的信息中心主任对于软件开发却有着比较丰富的经验，曾经参与过金税工程等大型软件的开发。这使我感到这样的客户比较容易交流。实际情况也确实如此，在与客户交流了几次之后，该项目基本确定，我被公司任命该该项目的项目经理，负责该项目的开发。
       在这个过程中，我想作为项目经理，有一个思想必须明确，那就是项目管理的目标就是实现项目的目标，结束项目。这个理念应该贯穿项目管理的始终，所以，在最初和用户交流时，我们就要考虑该项目如何才能结束，它需要达到什么样的目标用户才能够认可，该项目的大体成本是多少，公司对于项目开发周期有没有限制，该项目存在的风险作为项目团队能够承受等。
       具体到这个项目中，一开始，我就发现该项目最大的风险在与用户觉得这个项目很简单，同时对于需求却还是比较模糊，当然这也是大多数项目的通病，我承认这个项目与金税工程比起来确实非常简单（比金税工程复杂的项目也不多:），但是如果用户抱着这样的心态，必然会出现项目开发时狂赶工期，后期Bug满天飞，需求改来改去，用户诸多抱怨，公司一面奖励销售，一面拿研发人员开刀的情况。因此，我想怎样找个合适的机会将项目开发的难度以及项目管理的理念与用户沟通。
       正在我苦恼的时候，用户提出他们信息中心的技术人员希望进行一次培训，以掌握该项目中的Java等技术。我知道，机会来了，在十天的技术课程的安排上，我专门抽出了一天的时间讲解项目管理，课程安排发给用户后，用户发现了我的小秘密:，专门打来电话问我用一天时间讲解项目管理是否有必要，抓住这个机会，我先给信息中心主任讲了讲项目管理的重要性，以及这个软件的难度、风险、周期等，让用户同意了该要求。在项目开始的时候，获得客户方项目经理的认可是非常必要的，如果你的理念和做法在一开始让客户方的项目经理感到很难认可，我想，项目做起来的难度会非常大。
       接下来就是合同的签订和为期十天的培训，在培训中，我将PMBOK的项目管理理念贯穿到整个培训中，尤其是最后的项目管理的讲解，基本上达到了预期的效果，让客户认识到软件的开发绝对不是程序的编写，它涉及到方方面面，一个成功的项目没有客户的配合和参与是很难成功的。对于项目的结束，我也与信息中心主任作了多次沟通，双方基本互相了解了对方的需求和想法。这对于后来项目的顺利进行打下了良好的基础。
       通过该项目的启动，我发现，在启动时如果有条件，对客户进行一次培训非常有利于项目的顺利进行。在培训过程中，可以和客户成为朋友，同时把自己项目团队的开发方法和客户作认真的交流，让客户认可开发团队，而且经过培训时间的缓冲，一方面，可以组织其他技术人员对于项目中可能出现的技术难关进行突破，另一方面可以在私下里和客户交流项目需求，这种非正式的需求交流往往比正式的需求交流更容易知道客户发起项目的初衷和客户希望达到的目标。

       2、计划
       在计划阶段，一开始应该结合启动阶段对需求的大致了解做出大略的计划，明确项目的结束日期，该计划一方面要提交给用户，另一方面要知会全体项目组成员和公司项目管理部门或公司领导。当然，这里明确的项目结束日期一般情况下都和项目的真正结束日期相去甚远（到目前为止我还没遇到过特殊情况），这不要紧，因为在需求调研结束后，还会再细化项目计划，重新明确项目结束日期。但是不管如何明确，这时的项目结束如期往往受到来自客户、公司等方面的压力，做出的计划总是按照一种理想状况安排的，例如下面就是我在需求结束后作的项目计划：

       这个项目计划就是在客户方的领导及公司的双重压力下做出的，这个时候，项目经理必须保持清醒的头脑，不管计划上的项目结束时间是多少，心里必须清楚实际完成的大致时间和计划时间的差距，以及这种差距客户机公司是否能够承受。这样，在项目进行过程中，再根据情况对计划逐步调整，逐步向客户和公司汇报调整原因，容易达到客户和公司双方都基本满意的结局。如果差距过大，就要据理力争调整计划，当然，这是比较困难的，但比起最终被客户和公司双重责难，还是比较值得的。
上面的计划提交后，我估计最终的结束时间大约要比计划晚5周左右，主要是对于系统修缺，也就是试运行开始后，用户必然会提出许多意见，2周的时间应该完成不了，但是，如果直接在计划上提出7周的时间，用户绝对无法接受，公司也无法接受，项目可能就会陷入停滞，在压力下，我做了2周的修缺，那么，到时候怎么办呢？我通常的做法是，在尽量争取长的修缺时间后，首先保证试运行的基本按时进行，这一点，相信大多数项目团队都能够保证，然后，在开发时采取多版本上线的方式，尽量让用户尽早提出修改意见，争取尽早开始修改，第三，在试运行开始后，用户提出意见时，及时调整项目计划并及时通知用户，让用户明白当他的意见被采纳后，项目结束时间将被推迟到什么时候，给用户一定的压力，可以减少意见量，尽早结束项目。还有，就是在可能的情况下，尽量将实际的估计时间和自己的主管领导进行沟通，获得他的支持，保证无后顾之忧（这一点很重要，不过就看你和领导的关系了:）。
       事后证明，我当初的估计基本是对的，项目结束的时间大约比计划时间晚了4周左右，这是由于用户对于软件开发的熟悉和配合，如果碰上比较麻烦的客户，时间大约会再晚一些，但只要事先有充分的估计，就不会手忙脚乱。

       3、执行
       执行过程相对比较顺利，由于和客户保持了良好的关系，得到了客户的大力支持，基本上没有提出刁钻的问题。在这个过程中，一开始的部分，我们是在公司开发，这个过程中，我们开发了部分模块，作为0.1版，到现场给用户进行了安装。
这样做，我认为有几个好处，首先，可以让用户感到项目一直在进行，而不至于破坏和用户的信任关系，其次，可以尽早了解现场的实际情况，如果发现问题，及时调整开发方向或者让用户调整现场环境。再次，可以让用户对部分模块尽早提出修改意见，在开发其余模块时，就可以对这部分进行修改，同时把意见贯穿到其他模块中去，减少后面修改的时间。
       开发大致结束后，我们进入现场给用户进行安装调试，然后再进行系统修改，这是最艰苦的时期，在这时，用户、公司、项目团队都很容易疲惫、厌烦、愤怒、绝望，并把这一切的罪过都堆到项目经理的头上。所以这时作为项目经理，要保持高度的警惕，必须有完整的项目日志，记录每天的进度；必须保持和用户方项目经理良好的沟通，随时将问题及进度报告客户及公司，让他们明白每天项目团队在做什么，为什么结束时间会一推再推；必须观察项目组成员的情况，防止由于疲惫而出现人员流失的现象；必须随时提醒自己，项目的目标就是结束项目，所作的一切都要围绕结束项目而进行。
       在这个过程中，我们项目组基本熬了过来，在我的预想时间内结束了项目，虽然还有很多不令人满意的地方，但毕竟随着项目的结束，大家的压力减轻，可以更好的总结经验。

       4、控制
       在项目进行的过程中，会出现各种各样想象不到的问题，遇到这种突发情况，需要项目经理及时解决。
       在这个项目进行的过程中，在开发进入最关键的时刻，项目组的技术骨干突然提出要离职，这是我事先没有思想准备的，如果他真的离职，将会对项目造成极大的麻烦。这个时候，我和他进行了长时间的沟通，了解他离职的原因，如果能够挽留，尽量挽留。
       经过交流，发现他提出离职是基于三个原因，一是对公司长期的不满，在一个公司待长了就会对公司产生种种不满，这是人之常情，虽然我提出增加薪水及提升职位，但很难让他对于公司的不满得到根本解决，二是具体生活的压力，在我们这个二级城市的薪水待遇很难解决结婚买房等具体压力，因此他希望能够到北京这样薪水待遇比较好的地方，这也是我们公司目前面临的人员流失的重大挑战，但这个问题短期内恐怕没有更好的方法，三是对于外面世界的向往，在一个二级城市呆的时间长了，对于北京这样紧挨的全国信息中心必然产生向往，希望技术、思想等各方面能够在北京得到提升。
       这些问题也是普遍问题，我无法通通为他解决，但为项目考虑，经过劝说，由于平时大家关系非常好，他答应留下来一个月左右的时间，解决好他负责部分的技术问题，同时做好交接工作。这对于项目来说，危机就解除了，因为有一个月的时间，完全可以安排好一切。
       针对这样的危机，我想，作为项目经理，一是平时就要注意和团队成员的关系，当发生各种情况时，即便是用人情，也可以帮助自己度过危机；二是对于许多问题，要在平时就了解到团队成员的需要，能帮大家解决的，尽力解决，不要等到发生问题的时候，实在解决不了的，要让大家知道公司的难处和具体环境的限制，不要让大家记恨公司；三是要牢记团队建设的核心是团队成员的个人发展，要给每个成员成长的空间，包括技术、薪水、职位等，否则，一旦团队成员达到发展的顶峰，就会感到没有前途，离职恐怕是必然的选择。
      

       5、收尾
       收尾阶段最大的困难是什么？进度！这个时候，面临项目结束，所有人对会对进度非常关注。如何设法说服用户，结束没完没了地更改，顺利地结束项目，是每个项目经理都必须面对的问题。
       在这个项目中，由于前期作了大量的工作，在临近收尾时，我们准备了完备的文档，解决了当前存在的Bug，并承诺了以后的服务，双方都比较满意，顺利地签署了初验报告，用户也支付了项目款项，结束了该项目。
       所以，我觉得，顺利地收尾并不取决于收尾阶段的工作，而是要把收尾工作贯穿到项目始终，如果前期准备充分，收尾时最大的冲突，进度，就不会成为项目经理最大的问题，相反，如果收尾阶段才开始考虑如何结束项目，那恐怕项目的结束就会遥遥无期。

       这个项目目前除了日常维护和简单的修改外，已经没有大量的工作了，虽然项目的顺利结束，有很多偶然的因素，例如用户的积极配合（这在其他项目中是少见的，一般是用户的百般刁难），但我想，他仍然具备一些中小项目共同的特点，作为项目经理，我提出来和大家分享的目的是希望我们总结经验，能跳出项目的焦油坑，顺利地结束每一个项目。