初出茅庐如何管理一期开发项目

初出茅庐如何管理一期开发项目

       我们公司是一个外包公司，与华为合作，给中国移动做项目。说是与华为合作，其实就是关键位置上是华为的人，其他的都是我们公司的人，而我所在的组就是测试组。

不知道，别的人碰到这种情况会怎么想，反正我是一开始兴奋，然后颓废，现在坚持。为什么这么说呐？开始的时候，我觉得自己不行，能和华为的人一起工作，肯定能学到很多东西，然而，当我真正在公司待上了一段时间后，我觉得非常压抑，感觉自己就是一个廉价的马蹴。因为，你再怎么优秀，你在这个团队也没有发言权，关键点上的人也不会听你意见。于是，我就渐渐的颓废了。但是人啊，在不得志的时候，不能妄自菲薄，如果自己都不能端正自己，那一定不会有人瞧得上自己的。颓废过后，我觉得自己应该要坚持，而且必须坚持，这是人生的一个历练，是人生成长的必经之路。于是，在根本不被华为人认同的情况下，我默默的负责了我们组，月项目的测试管理工作。

我们是，每个月月初华为的人员决定开发任务，月末指定日期升级。这种，应该来说是一种相对传统的模式，这也注定他的管理模式会相对传统。月初确定需求，就开始评估工作量，分发需求，然后写测试方案，测试用例，再一轮两轮三轮的测试，最后验收通过上线。虽然传统，但是，任何一个项目都是有风险的，都不是那么简简单单的几句话就能描述这一个月的工作的。

首先，在拿到需求后，对测试工作量的评估，以及组员对业务了解程度，以往工作效率，抗压能力，技能等都得有一个综合的评估，还要预留一定的冗余。看起来，也许是一件小事，但是没有一定的经验和实践往往是做不好的。之前就有一次，华为外派一个人员来我们组，而他根本没有测试经验，也没管理过团队，拿到需求，也不知道从哪听来的说，多少行代码就要写多少个用例，也不轮组员们业务水平，劈头盖脸的分下来，结果，一个刚进公司，还处于试用期，且还没有一年工作经验的女员工就被分配去测试接口。对于接口，我们这些工作了一段时间的老员工都不敢接，他却强压个一个新手，当时，我们就极力反对，可是人家是华为外派来的，我们又对他根本不了解，他也根本听不进我们的。结果，可想而知。所以，吸取了这个沉痛的教训，我在给大家分配任务的时候，对新手，我预估的工作量为正常的50%，富余的时间，就给他尽可能多的时间去熟悉业务，而对于老员工，我则能者多劳，但尽可能的不饱和分配，如果综合评估工作已达当前人员测试饱和度的90%时，一定配备后备人员。

其次，需求分配后，组织需求分析师、对应开发工程师、系统分析师、测试工程师参与需求讲解。讲解会议后，开始编写测试方案，测试方案要结合需求分析文档、系统分析师的设计方案、开发工程师的story设计文档、同时在编写时，尽可能的设计流程图，同时还要求评审开发工程师的story设计。然后组织测试方案评审，评审时，要求完全脱稿演说，即要求在不看任何需求文档的前提下，在所有组员面前描述自己的需求核心功能，同时要求开发工程师、需求分析师旁听。尽可能在设计之初，就把需求的覆盖率提高。

再次，测试方案评议通过后，开始编写测试用例，在编辑测试用例时，要求每天跟进开发进度并前期测试。同时，每天上报可能出现的风险。尽可能的让自己的测试用例更接近实际开发效果，可执行性更高。如果在编写用例过程中，发现描述不清晰，需求边界不明确，思路不明朗等问题时，必须用邮件明确提出，请需求分析师及相关人员给予明确答复，用例编写完成后，组织全员互评，并给出评议报告。对于，已经开发完成，但还未转测试的功能，可以先前进入开发环境验证。

第四，第一轮转测试前，输出ST用例，要求开发工程师必须在全部通过后，才能交付测试，如果未能通过，必须杜绝阻塞性问题才能转测。

第五，转测时，发现bug，必须提交到缺陷库，提交缺陷库的bug，必须写明重现步骤，附带截图或错误日志，同时通知对应开发工程师，每天工作结束时，上报测试进度，同时必须上报测试风险，描述典型问题。如未上报，第二天晨会，必须在全员面前汇报测试情况。每一轮测试完成，组员都必须书面汇报测试过程中的经验及教训，以及希望提升的地方。

第六，在实际测试过程中，如出现需求变更，需要需求提出方给出明确文件，需求分析师，出具详细需求文档，修改测试用例。如出现需求不做时，当前测试人员马上停止测试相关工作，同时邮件通知相关人员，但不再给该组员分配别人的需求，该组员可以利用自己的时间帮助其他组员，但是组长不给予明确通知。同时，严禁私下更换需求测试工作。当功能已经基本验证通过，无明显问题时，可提前申请验收方参与需求功能检查。

第七，测试工作结束时，务必保证每一个缺陷都处于关闭状态。同时，总结经验教训，分析缺陷类型，组织开发工程师以及组员培训。