1.是否要接需求的问题
我们的测试阶段分为测试环境线上环境ugbash三个
原则上来讲在测试环境的测试阶段可以在评估工作量之后适当修改需求,后两个阶段不能修改需求.
a 视觉因为很难在第一阶段介入,比较特殊.可以允许在第二三阶段提出修改.如果要进行视觉微调,视觉需要单独和开发商量,开发修改也必须以不影响进度为准(不因为需求变更而减少正常开发任务).
b 逻辑的问题请策划在设计时想清楚,或在第一阶段时和开发沟通,提出修改.
c 非策划和视觉直接提出的需求全部拒绝,需通过前两者来提出
2.需求确认的问题
a 负责人制度
每个版本设立一个策划负责人(属于策划组成员),任何在开发测试阶段对需求的不了解都向他询问.在讨论过程中拥有对策划案的最终决定权.
b 需求确认
如果交互确认阶段没涉及的细节,开发人员不明确的,请在实际开发前主动找负责人询问.
如果开发阶段看错交互稿,或者没有主动找负责人继续明确(需求确认),导致到测试阶段时发现所做的内容和策划想法不一致,开发人员承担全部责任.如果经常发生此情况则对相应开发提出批评.
开发在需求确认过程中,一些复杂逻辑讨论需要叫上测试同学.
简单逻辑可以和策划讨论完后通知测试同学.
讨论完毕后最好在qq上和策划再次发一遍讨论结果.这是开发保护自己权益的最好办法,防止策划赖账:)
c 砍需求的意识
这是更高级的开发自我修养.
当认为某个需求很难实现的时候,不闷头实现,首先想到去和策划再次确认.因为策划可能并不了解该逻辑的实现成本,导致提需求的时候没有考虑最高的性价比.开发可以提出一个性价比更高的方案.这要求开发看待需求不仅仅是一个任务,而是策划在需求背后的思考,背后为了解决的问题.