QA人员一定要有实际项目经验

最近一段时间正处于项目策划阶段，这个阶段势必要和部门QA打交道，咨询问题并获取支持。按照我们公司的软件开发流程，策划阶段要输出一系列文档的。这些文档都是有公司模板或者是经部门裁剪后模板作为基础的，所以现在项目前期策划基本上就是按照自己的思路填写文档，估计很多公司也都是这么做的。

好不容易花了一个星期的时间把这些文档'填全'了。提交给QA，让之帮忙审审。QA的一封邮件回来，问题多多。

当我看到这些QA提出的问题时，我的第一个念头就是"QA人员一定要有实际项目经验"或者说这些体系文档QA自己按照流程一个一个的实践一下，自己填一遍。这样就能体谅这些问题是为什么发生的了。比如说：QA建议每个项目阶段前都要有一个任务叫"策划xx阶段"，用过MS Project的人都会了解，如果分配给一个人的任务散布在整个Project甘特图的各个部分，十分不利于人员的任务分配，你要考虑到任务间的依赖关系，还要考虑到'资源工作表'中每个资源不能'变红(过载了)'。这些阶段性策划在实际项目过程中都是在一个集中的时间段完成的，大可集中放到一处。还有，对于多人参与的任务也是很难分配的，也是要考虑依赖关系和资源过载的。

部门的QA没有实际项目经验，隶属学院派的，工作很认真，并且有坚定的过程改善的信念，唯一缺乏的就是实际的项目经验。如果能到一线锻炼一下，相信她会发现更多待改善的问题，也就不用我们不断的提意见、沟通、反驳、再沟通、再达成一致了。谈到QA，我的理解是：QA一定要有坚定的信念，很好的执行力，丰富的项目经验，相信通过良好的不断改进的过程一定能让项目管理更加精确、准时。否则如果没有这份坚定，做起工作来那简直就毫无乐趣而言了。很多大公司的QA都是由一线开发人员、测试人员或者是项目管理人员转型后来做的，他们在项目里待过，知道改善的地方在哪里，同理心更强，知道开发人员为了达到某个项目管理的目标需要付出的代价。有项目经验的QA能大大减少纸上谈兵的概率，提高自己的说服力。

还有很多问题原因不在QA，而是模板的问题。填写模板时我们也希望要填写自己能控制、能想到的东西，如果在自己控制力之外的一些东西非要填，那就很头疼了。其实这也和部门角色定位有关系。部门的项目负责人与传统意义上的项目经理不甚相同，部门的项目负责人在一定意义上是偏技术类的。如果让偏技术类的负责人去填写什么"信息资产管理"、"共利益者管理"、"客户资产管理"、"项目采购计划"这类的表格显然是"门不当户不对"。

做项目也是做事，应该本着一个原则'简单'。把一些与项目目标不相关的事情也牵扯进来似乎费力费神，毫无意义。记得在上一个项目总结会上提到过一个成本目标的问题，项目初期策划时需要填写一个成本估计，然后结项时收集实际成本数据做比对，看目标是否达成。可是项目总结时根本无处获取这样一个成本数据，财务那面根本就不会给我们技术负责人出这种报表的，类似这样的'估计'估之作甚呢。

意见和建议已经提交给QA了，估计明天又会有一次激烈讨论。^_^