从4月份开始，由于备考《系统集成项目管理工程师》的原因，博客没有持续更新，在上半年考试结束之后，又对项目进行了一些收尾的工作。下面就这段时间的学习作一个记录和总结吧。
在学习的过程中，提炼了一些自己认为比较重点的内容进行整理，在项目管理的五大过程和十大知识领域中，其中所囊括的内容可应用到所有的行业中，项目管理的知识具有通用性和适用性，比如土建工程的项目可行性研究报告和信息系统的项目可行性研究报告其输出基本一致。
在一般的系统集成项目中，当一个项目启动后，要进行需求分析、评审、管理等过程，在政府性的采购项目中，这些集成工作都会按照正常流程在进行，一步一步的把项目进行持续交付，直到收尾，这是一个相对规范的过程。
由于目前我国互联网行业的迅猛发展，大量的系统集成项目人员大量进入了私营企业内部进行工作。并且，由于国家喊出“大力创新、万众创业”的口号下，千千万万的项目就此落地开花。
互联网项目只争朝夕，时间就是生命，一个创意从灵感突现到写下第一行代码，可能就是在一天之内；市场，并没有留给创业者太多的思考时间，继而进一步挤压了项目管理的空间；从而导致仓促立项、野蛮开发、后期维护BUG不断，甚至导致项目流产。当初的团购网站，从一夜之间百花齐放、蓝天碧海，到最后万象俱灭、一地鸡毛，留下美团一家独大，这为我们从项目管理的角度进行研究提供了很好的素材和经验。
快速开发迭代的能力背后是庞大资源的支持，人力资源管理、成本管理、质量管理、干系人管理，在独角兽的背后，是贪婪的资本运作。
但是无论如何，成功的项目的背后都是借助于庞大的资源，获得大量的工具支持，然后提供强劲的输出结果。在五大过程和十大知识领域中，包含了一个很重要的工具和技术，就是“专家”支持，比如政府采购项目中，技术专家的评审必须占评标委员会成员席位的2/3以上，这是硬性指标。借助专家在系统集成项目管理领域的专业知识，确保项目高效、稳定、规范的进行运转。
快速迭代是把双刃剑，在庞大的资源面前，快速迭代就像装上了涡轮的汽车，其迭代能力得到进一步的提升，运转效率也更高，项目文档、报告、配置都得到了很好的提升和保障，但是对于上面提到了仓促立项、野蛮开发；这种类型的项目通常也打着快速迭代的口号、由于缺乏资源的支持，大量的削减了项目执行过程，比如不作项目可行性研究详细报告，甚至不作可行性研究初步报告，仅凭脑子里面的灵光一现，就马上投入资金、项目强行上马，这可能就是系统集成项目行业中自嘲的：我有一个很好的想法，就差一个程序员了！
很多时候，上面的自嘲并非玩笑，比玩笑更可怕的是，这个玩笑是真实的存在。在这种背景下，系统集成项目管理具有非常迫切的现实需求意义。
在很多私营企业中，很多时候都是老板一言堂，说干就干，而且要大干快上；项目管理的过程在这些企业中就像笑话一般的存在，并且由于“全栈工程师”的原因，系统集成的开发人员通常身兼多职，既是裁判员也是运动员，少部分系统开发人员本身也并不具有项目管理的思想，他们一心只想着完成老板的要求（并非需求），然后拿到工资，至于是否规范、以后怎么样，天知道，大不了辞职一走了之。
他们不知道什么叫CCB，换句话说，老板就是CCB，在这样的企业中工作，老板就是狂风暴雨的大海上漂泊的一叶小舟，风雨飘摇，顾不了太多，该扔的不该扔的都得先扔掉了。而有经验的，具备良好的系统集成项目管理经验的开发人员，他们会把这一叶小舟上的物品收拾得井井有条、在船头漏水的时候，知道在舱底存放着修补工具，按图索骥、临危不乱。
沟通是一门艺术。在图书馆里面堆砌了大量的关于人际沟通方面的书籍，用以帮助人们进行有效的沟通。
在系统集成项目中，沟通管理作为一项重要的内容被单独列出，一个运转良好的项目，必然是一个有效甚至是高效沟通的过程，这种对项目干系人的沟通管理，持续贯穿到整个项目的生命周期中，项目经理作为其中的纽带，负责将整个沟通过程进行无缝的连接；对干系人的沟通，又分为水平沟通和垂直沟通，其中最为有效的方式，就是面对面的沟通，在系统集成项目中，距离不会产生美，只会带来冲突和矛盾。
沟通的方式很多，比如常见的文档、邮件、即时通讯工具、会议、讨论、通知、访谈、专家指导，沟通的线路数量随着干系人的持续加入会成指数级上升，比如当前项目组中有5名成员，此时，沟通线路为25条，如果后续新加入4名成员，该项目组的沟通线路将会上升到61条，在如此复杂的沟通线路中，想要进行有效的沟通，就必须充分利用各种各样的沟通管理工具，以达到沟通管理的高效输出。
有效的沟通是解决冲突的重要途径，冲突的形成就是有障碍的沟通，在干系人信息不对称的时候，就会造成信息孤岛，冲突就无法避免；另外，有效的沟通一定是妥协的结果，妥协的力量来自方方面面，有可能是项目基线的调整，也有可能是资源的投入，无论是何种结果，都需要完整的记录到项目文档中，就像领导开会通常都是用脑子和嘴巴直接传递信息，但是作为领导的助理，则必须将信息文档化、流程化。
有一项非常重要的工作，在项目管理的过程中常常被弱化甚至被忽略，那就是项目收尾。
有些项目的收尾工作非常复杂，有些则非常简单，但是无论如何，我们都可以围绕项目自身，去做一些必要的工作，千万不能就地解散，各回各家各找各妈；部分收尾工作内容具有普适性，根据项目干系人的不同，他们关注项目收尾的工作内容的重心也不尽相同。
比如建设方关注的是项目的建设质量，是否如期按照项目基线和详细设计完成，承建方关注项目交付后资金交付，项目组内部需要进行项目总结、资料归档；有些项目还需要组产品交付后启动新的工作，比如项目后续维护管理，或者是一些长期的项目，需要持续交付，直到项目的终止。
零零散散的写了一大堆心得体会，大家将就看看。