看到一个开发工程师发文抱怨遇到了一个喜欢给开发提需求的测试。很不忿为什么有的测试这么喜欢给开发提一些需求类的问题，然后产品又觉得改下也挺好，开发就只能忙死累活？
能理解开发人员的郁闷，但其实发泄错了对象，因为导致这个情况是几个岗位责权未清导致的：
看下几个岗位职责：
PO：负责产出符合INVEST原则的需求描述，并要在一定时间窗内保持需求的稳定性，不可想一出是一出，每一条需求的实现其实都可以算到成本上。改变、废弃的需求属于沉没成本，要算PO头上。PO有需求的最终解释权和决定权。包括争议bug，基本上PO有裁决权
开发：完成已认领需求的实现，实现前任何模棱两可的点都尽可能应该跟PO确认清楚。这也是需求澄清的重要性，包括澄清时就应该和测试在内三方达成共识。按共识进行实现
测试：验证需求并从使用和质量角度提出产品缺陷和产品优化建议。这里测试提出的问题，有三个主要争议类型，缺陷、优化跟需求。
判定是缺陷的，是开发责任；
是优化的，通常是一些不符合常规使用逻辑或界面调整等，优先级不高但三方均觉得最好改掉，正常按计划排开发工作量实现，但不能算作开发实现上的遗漏；
需求，重要功能调整或需求本身就需要变更，要重提需求，PO应承担变更成本。
所以从产品最优角度，测试提出的优化或需求，PO能采纳就代表有其实现价值。只是当引入修改成本的评估后，才能避免题主说的改来改去的恶性循环。开发进行功能改动也可以理解为进度、成本的变化，PO要有义务权衡并承担优化、需求实现带来的成本变更
对于测试而言，其实应鼓励多提各种优化建议，只是要注意和缺陷的界定是否清晰。但优化建议的分析总归也是有一定成本，所以也可以引入优化采纳率这个指标进行平衡。
测试全栈系统提升课程正在上新优惠中:
随时随地看视频
