项目中后期管理

        中后期差不多就对应的是规范期、执行期和休整期了。这三个时期中前两个时期对于中小型的项目可以合并为一个时期，执行监控期。其实规范和执行本来也就没用明确的概念，规范就是在执行中一点一点的监督纠正出来的。所以这段时间就是项目经理监督，团队成员各司其职的执行计划，保证质量的的完成自己的任务。休整期就是收尾准备上线的时期了，这个时期除了休整以外也有一些事情需要着手做一下。

        在项目的执行监控期大致可以参考风险驱动的模式来进行，风险这个词作为项目经历应该每天早上到公司就得想一遍，我现在有那些风险，那些优先级高，要怎么应对它。对软件项目来说虽说风险很多，但仔细划分一下大致可以分为下面这些分类。

        1、质量风险：这个是首位的，也是最重要的。很多东西都能决定质量，前期的设计、开发、测试人员的素质、选择的技术架构都可能造成质量的风险，尤其是产品前期的设计以及开发、测试人员的素质最为关键。它的应对也最困难，整篇系列文章最核心的一点就是围绕保证最低质量展开的。具体怎么做可以参考其他的文章，后续也会有帖子专门讨论它的应对。

        2、进度风险：进度风险，比较模糊但相对来说也比较容易控制。只要计划做好，按照计划执行就可以监控有没有进度风险。但这里有一条就是千万不要为了进度而掩盖本来该做但没时间做的功能点，尤其是隐蔽性比较强的功能点。

        3、沟通风险：沟通这里主要是和外部的沟通，这个风险我感觉最好的应对办法就是不要让团队成员私自对外沟通，所有的沟通都要由项目经理来做或者在项目经理的主导监督下来做。

        4、团队成员协作、个人能力素质、流动风险：团队成员是核心，他们的素质决定了输出的成果。项目经理应该要了解团队每个人的基础能力，要做到心里有谱，比如一个任务分给谁，他能做成什么样，需要多久，让他做可能会产生什么问题，这些都要了解。协作沟通也需要关注，但要允许他们对项目，技术由私底下的个人沟通。对于执行监控期的项目来说任何的人员流动都是一个很大的风险，无论这个人能力再不行，越是项目中后期风险越大，一个人在决定离职之前肯定会有纠结一段时间，或者是自己做的东西感觉要暴雷了才会想走。在提离职后要有各种谈话，流程也要一个月左右，这个时间段对他做的东西就不要报多大希望了，能利用这段时间把他之前挖的坑发现并填完就万幸了。所以如果有人提离职，就要在适当的时间停止他未完成的工作，并且组织测试对之前的工作进行测试，代码进行review。尽可能的利用最后的一个月把已经把做完的东西给巩固了，不要让他负责的模块成项目的一个大坑，谁都不敢接的坑。

        5、技术、性能、集成风险：技术风险相对可控，但要关注的是一些技术难点，比如一些程序莫名的卡，无法跟踪日志的崩溃，不能重现但时时会出现的异常。这些都要关注，没有无缘无故的异常，只有你没发现的问题。这些都有可能成为项目的新病。而集成风险往往会严重影响项目的进度，项目经理在项目开始时期要尽早的识别出来需要对接那些东西，对外提供那些接口。需要对接的东西要今早的找到对接方要到对接文档等技术资料，对外提供的接口要尽早的提供对外接口的标准的文档。对于项目需要对接的已经运行的系统，可能会造成额外费用的要尽早的让商务、领导参与进来。

        6、工作环境、领导支持的风险：领导支持就不说了，一个项目没有领导的支持是做不好的。工作环境包含硬件环境工位、空调这些，也有软件环境比如公司的制度，加班有什么制度，能不能打车，bug多怎么处理，怎么奖励优秀的成员等等，这些要熟知。尤其是惩罚和奖励制度。

        7、需求变更的风险：这个老生常谈了，没什么好的办法。但如果项目经理对产品比较熟的情况下，对于需求的变更从产品方面考虑，给领导或客户提出做和不做的建议。并且给出估计的时间。不要感情用事，也不要嫌麻烦，项目里面什么都可以用时间来衡量的，时间也就是成本。至于老板有意见，客户觉的胡闹。把要做的东西实事求是的列出来就好了。

        能把上面的这些风险管理好，整个项目差不多也就成功一多半了，另外在项目的执行监督期还要解决一个懈怠的问题，项目经理自己不能懈怠，要每天review代码，复测功能，跟踪进度，识别风险，应对风险。这些要靠自律，也要靠监督。还有团队成员的懈怠。对付懈怠我认为一个不错的办法就是外部监督，首先把自己的要做的事情都公开透明，做好的输出品哪怕是半成品也要发布出去，定时发布，谁都可以看。另外就是引入产品经理确认制度，一个项目以模块甚至页面为单位，让产品经理确认，确认做的怎么样，有没有跑偏。确认完再提测。提测也要尽可能的提前，以模块为单位，产品经理确认完就提测。测出来ticket就改，开发和改ticket并行。如果团队素质能达到，最好要求是每天剩余的ticket量不要超过5个或者几个。

        项目后期差不多差不读整个项目已经开发完，进入二轮测试，主要是改ticket的阶段。这个阶段大部分的成员已经离场或者准备离场，之前不同成员负责的模块难免要让一个人或者有限的几个人来进行处理。这个时候就要注意如何防止填完一个坑又挖出来其他的好几个坑了。首先严重的或者面比较大的ticket尽量要求谁做的谁改，这个最好了。如果不能这样做就加强代码的review。单元测试或者自动化测试也可能是个好的解决办法，但由于成本太高没试过。

        后期还要做的一个事情就是为项目上线做准备，基础的要准备运行环境文档，部署文档，使用说明文档，数据库初始化脚本，内置数据脚本，对外接口文档，前置环境文档（跟那些项目对接那些东西），这些比较基础就不一一列举了。还有一件事情要做的就是最好组织一次会议，主题是项目中的那些坑，把团队成员组织起来，大家畅所欲言，把自己认为项目的坑或者潜在的问题说出来，不是为了追究责任也不是为了分配任务，而是为了了解。了解项目中有那些你不知道的问题，知道了问题才能想办法去应对。

        另外如果是个产品的话，在后期最好能做到任何代码都和tiket挂钩，比如禅道有ticket编号，代码上传的时候无论是SVN还是GIT都可以规定注释格式。可以规定所有的代码都必须关联ticket编号。这样可以保证所有的需求，想法，定制都汇集到一个地方。以后产品升级的时候就可以从那个地方去找升级的方向了。