该帖子同步发自：(riverstone的博客  访问该博客)

　　五彩石之后，我参与收费线，一度进入了修整期，主要工作是日常。前一阵子有个比较大的项目成立，但是由于人员不够，便决定安排日常与项目兼顾。当时我凭以往经验认为，在项目前期阶段，我们是可以做到将两者兼顾的。但事实是，那段期间并没有按我的计划进行，由于种种原因，也可能是我的时间管理出了差错，我们把多数时间投入到了日常，剧减了前期去理解项目需求的时间。而这一决定直接导致了在UC评审时没能很好的明确把控住，致使现阶段我们的测试成员还在为确认项目中某些功能需求而犯愁。

　　当这个风险暴露出来后，我曾反思：日常与项目兼顾，以前我可以，为什么现在做不到?是业务复杂度的问题!是时间管理的问题!是团队合作的问题……原因可能还有很多，而我作为项目的测试负责人，前期没将这些风险完全评估出来。即使有一万个理由，也还是一个不称职的测试负责人。

　　总结：在项目启动时，最好能将资源完整投入，特别是业务比较复杂的项目。若确实出现资源不足，应该及时且坚决地反馈出来。

　　二、对UC评审的把控。

　　对UC质量的把控，本该是开发人员的事。但UC写出来，看得最多的则是测试人员。所以测试人员对UC的质量是最关心的。那么从测试的角度，什么样的UC才是可以通过评审的呢?我们现在的流程中还没有完全的标准，这就需要测试人员靠前期对需求的理解来把控。要是前期投入时间不够，自己的工作没做足，在评审时找不出有效的问题。或是由于项目进度，虽然评审出问题，但之后马上进入下个阶段，那么将会导致后期过程中问题多、反复问，此时开发修复完善的积极性又不高。最终致使测试理解需求准备阶段进展较累。这也是前一个问题带来的直接后果。

　　总结：虽然我们的流程，对特殊的项目可以适当灵活运用，但无论是什么项目，UC对测试人员的指导参考价值是第一位的。这回的教训再次告诉我，在UC评审阶段一定要把握好这个度，那么前期一定要有足够的时间去做准备。

　　三、项目中的沟通、协调。

　　一个项目比较大，投入的开发、测试资源肯定也就增多。这期间，成员中出现了沟通上的问题，也曾为之愤愤过，也曾努力协调过……

　　总结：在测试团队中收集上来的问题，理应站在测试者的角度考虑，但对这类问题也要学会过滤整理。我们每个人的性格不一样，看待问题的态度也不同，作为测试负责人，要综合平时对队友的了解，具体对待。项目组是一个整体，我们的目标是一致的。而且从产品线的角度，大家将是长期合作的伙伴。虽然我们对事不对人，但可以寻找更好的沟通方式，不该因小问题上大和气。

　　我们的项目业务比较复杂，繁多，所以周期比较长，现在发现了，还可以从某些方面做些弥补措施。但对多数项目来说还是短期的，可能问题发现了要到下个项目中才有机会去弥补。

　　本来想项目结束后再来好好总结的，不过现在这些教训等到项目结束后，感觉可能就不太一样了，所以想先写出来，以督促自己，也供大家借鉴。