考虑成员资源情况和各个任务间的关系

       到年关了各项目都更为紧张了。这一两个月北京团队没有大规模的开发任务，只有些完善性或补充性的功能在北京团队进行着。开发强度降低了，但团队成员的时间需要更为合理。因为年关了，很多项目必须要结，而人手有限，所以更应合理安排各项目完善、测试和部分项目的再调研。整个团队磨合过程中也有不少收获简述如下。

      提早指定新成员的学习，适时督查。这次项目组进入年终最后一批功能的完善和测试，但发现一些新成员人就对项目模块不了解，甚至在讲述了两三遍后仍旧是疑惑颇多。虽然比不是多数人，但可见项目知识资料和学习内容部署了，但是没有足够督查，致使有些成员在关键时候掉链子。

     设置排团队文档的形成机制。团队的大部分时间是运维团队，只有部分成员或小部分时间处在开发状态中，而这种状况是会对原项目的文档形成一些冲击的，例如客户的需求是随时会变化的，再如之前有些文档不够完善等等。团队在运维过程中要在了解之前文档的基础上，经过运维来不断的升级文档，不断的使刚接手的人员能够顺利了解项目上手功能模块。在文档的形成过程中一定要严办审核，不怕反复更改，就怕放置在桌面上接灰尘。此外要对文档有严格的版本管理。

     要缓和过度到独立工作的状态上。虽然到目前为止还有些成员不能独立工作，但从这段时间的经验来看从项目知识和应用角度入手，逐步进入独立工作状态的尝试是适合现在的团队的。这批成员本着如下过程已经有所成效：项目知识和开发方式的简单介绍、需求理解、应用的灵活运用、小功能辅助指导以及一定难度任务的提高，进而使成员达到独立工作的状态。

    要给成员和自己一些压力。如果一些事情从源头就开始放松，那这件事情会被延误一大截甚至是无法想象的。很简单的一个经历，原本工作量及小，而其优先级也极低，选择一个能力合适的人分配了下午，由于压力过小，致使小功能敬一再推迟完成时间。虽然没有超出当前批次的任务交付，但这么多工时的耗费也不应该。当然期间不能排除执行人能力问题。

    仔细考量任务完成计划的合理性。最近两个批次的任务重合在了一起，但本应该最先完成的任务批次，却需要直接依赖第二批次中的部分任务（影响到了本批次的其他任务），这样应该先完成交付的反而需要等待后交付的任务。这种不合理虽然是后续需求或远程团队设计有变更的情况导致的，但这足以让我们警觉要考量任务的关系。

     

     要尽可能的多的留下测试和部署时间。在开发上会根据个人能力其开发时间有所不同，但也要考虑这种不同也会影响到测试上，即一些成员开发的内容测试修改时间相对是会长些。