害得我英文从头看到尾，居然后面有中文翻译？

贵司贵小组的规则是什么我就怎么做 比如我司产品说了算，研发测试对需求的理解基本躺平，然后就是领导说了算……产品研发测试一起躺平……
挂就挂吧，纠结个啥，真正做事情就做了，扯这些乱七八糟的

现在找工作找不到，招人招不到，本质还是供需两侧的人才不匹配。

非科班，深圳的

我不知道是哪个大厂，就谈谈我自己的理解吧，我出发点是正向的思考问题，即这个问题是有意义的，也真的真实存在的，不是找茬的，面试官也不是心情不好。
首先要掌握基本情况：
需求：需求文档是不是写的足够清楚，我们是不是足够理解需求内容。
技术：研发侧要实现需求，应该有多种方案，可能不是故意的曲解方案，而是某个方案可能成本最低，风险最小，这时候要从技术角度去理解研发同学的想法，从自己对技术的掌握来判断研发同学说的是不是真的，即使要去和产品对，也能侧面提出论据。
人：研发侧是否有人力来支持方案的实施，人员是否在变动，是否存在请假风险，都很关键，把人的因素考虑进去，综合考虑。
到这里，大概能得出了一些结论，分三种情况：

1. QA 侧问题：QA 执行者理解需求有误。
2. RD 侧问题：理解有误，或者方案考虑的不全面。
3. 需求问题：prd 写的烂，比如一句话需求。 注意问题沟通时候的方式方法，不要只会怼怼怼。 然后要升华到流程，看看是否依靠流程改进，可以根本解决问题（这部分不详细写了，大概意思，要写太也多了）： QA 侧：关注 Case 评审的互动、效果、质量 RD 侧：技术评审、技术复盘。 PM 侧：需求质量、粗评、细评。 问题发现环节：哪个阶段发现问题，成本是不同的，要第一时间发现问题。 流程落地 + 监测：调查讨论、文档、实验、宣讲、效果量化、抽检、评估、改进、案例分享学习、推广。

那以你的看法，该如何回答第一个问题？

理性讨论也没啥吧，问题在我们日常工作中也常见，答案也确实主观 但面试官就非要这样提问，出于压力面也好 真的想考察你也好，就当大家在给职场菜鸟提供了一些其它解题思路咯

工作量是谁定义的呢， 如果我们就 1 天的活估 2 天， 大家都保持这种默契又如何呢

面试官的问题只是问如果研发跟测试出现了需求不一致，该如何解决；但是他并未说明是什么阶段出现这个问题，个人看来其实是考察测试 Owner 在不同项目阶段，遇到类似的问题，如何站在不同的角度（当然也得看下这个面试官他是什么角色，他是站在测试的角度去提问还是站在项目的角度上去提问）去做好产品和开发的协调关系。建议回答的时候，可以列举项目在不同项目阶段出现此问题时，你的沟通思路；因为项目处在不同的阶段，处理的缓急程度是有区别的，沟通的代价也是不一样的，对于项目的本身成本也是不一样的

同意，这个面试官，不好糊弄，而且不管你回答的怎么样，一定会给你挑刺，会不断施压，不过，考察点，应该是侧重于你的反应能力，思考能力，沟通能力，情绪掌握。

即使我不说后期可以在需求评审和用例评审阶段多注意该问题，那面试官一样会问第二个问题，甚至还会说总不能每次都这样吧？那我不还是得顺着话题找优化方案
我觉得我的回答和面试官的追问，没有必然的联系，而且给出一个优化方案我认为是很有必要的，面试是双方的博弈，不是全交给面试官，挤牙膏似的问一点答一点，给出合理的答案和优化方案，我不觉得自己回答的模式有太大问题
其它楼层提供的思路也很好，或许面试官想要的不是我们测试去承担这个事，而是希望坚定测试的立场，需求模糊需求有歧义，应该要求产品改进，在需求阶段就占用时间，不应该只由测试承担

996，真的能提高工作效率吗？问题是 996，工资涨了吗?

如果是我，我会这样回答：

楼上回答 +1，个人认为，测试的职责，只是：“发现问题”，但不需要具备：“解决问题”
所以，当你提的 bug，研发觉得不是 bug，尝试跟研发沟通，拿出需求文档，如果沟通无果，丢给产品，让产品去解释，一定不要占用太多时间来跟研发讲需求，你不是：“产品经理”，是：“测试人员”，把自己定位好

你回答的：“如果还是出现这种情况，为了减少占用研发时间，我会整理好自己的疑问和解决方案，单方面找产品确认需求，确认之后要求产品将需求描述清楚再告知研发”，，我觉得是犯了很大一个原则错误，，就是没有认清楚自己是：“测试人员”，为什么需要通过你这个中间人，去给研发传达需求解决方案？就算你讲的很清楚了，研发继续做错，责任还得是你担责，因为是你给研发讲怎么解决，讲什么什么需求，研发就会把锅推给你，你不但还要担责，还浪费自己时间。

形式主义加班可不少见

“Scrum 是一种癌症，” 互联网对此进行了思考。

在 3400 次回复后，我学到了一些东西：

首先，在告诉我我错了的人中，最常见的工作是 “敏捷教练” 和 “Scrum Master”。他们强烈支持 Scrum，但我不知道为什么。

第二，Scrum 不能失败，因为 Scrum 是您希望 Scrum 成为的任何东西。没有正确的方法去做 Scrum，所以如果它对你不起作用，你就不会像你想象的那样聪明。

第三，Scrum 不是敏捷的，除非它是敏捷的。但它总比瀑布好得多，除非它不是，而且它总比什么都没有和一切同时发生都好。

第四，我把 Scrum 和共产主义的比较引发了很多人。他们说共产主义是伟大的，但认识到他们从来没有生活在共产主义社会。他们不断提到他们读过的这本书，以及每一个在共产主义下流血的人是如何 “做错了共产主义的”。

最后，到目前为止，大多数人都以激情憎恨 Scrum。

不管你怎么看，Scrum 都是个失败。

你们这个 996 不大对啊，还有时间摸鱼。

一般 996 的同时，会同时增加工作量，让你真的要加班才搞得定。否则这种 996 真的屁用没有。

额，你怎么知道我们最近也开始强制加班了

解决不了就要向上反馈找 PM 去推动，尤其是在一些跨部门跨团队的需求面前，需求各个部门的开发理解不一致是非常正常的。还有在这种情况下，PO 可能也只是熟悉自己的产品，其他部门的产品可能也不熟悉，需要 PM 去推动更高级别的开发出架构图，方便 PO 理解，再去推动解决这种需求理解问题。比如后续可以组织进行需求反讲

get√ 我道行太浅了还得再练练，一直以来公司管理都是很扁平化的，氛围轻松没啥权力对等才能沟通的说法，但你的回答确实是个有经验的管理者该做出的正确行事风格，能有这样的上司真的很靠谱（呜呜呜，谢谢大佬提醒

凡事都有个度，这种沟通上的冲突，独立解决问题在绝大多数团队都不适用，还是要权力对等才能沟通
技术问题肯定是独立解决为上，但是也得有个时限，我以前的要求是半小时没进展必须来找我……要么我来指出方向，要么就是我要跟着你一起研究，不然我哪里知道你最终的结果是不是 “错错得对” 的运气呢~

解决任何问题，如果刚开始的方向不对，后面很可能会花费很多时间才能得到最终方案，高效率团队需要技术性管理，在指引方向和提点思路上必须投入足够的时间，不然就是个路人甲团队，leader 自己晋升吹牛逼都不好吹

有这个意思，可能是我在小作坊待惯了吧，提倡独立解决问题，以我狭隘的眼光，我一直以为上司是讨厌你给他制造麻烦的，所以回答的重点一直都在想自己去解决，一时没 get 到他的意思，后面他也有引导我问有没有想过问上级

没那么多活又要 996，要么想逼人走，要么有部门领导想做样子给上面看

你是个懂 996 的~

站在面试官的角度，我觉得面试官的这个问题意义不是很大，他想看应聘者处理合作/流程上的 操作和主观能动性，但是这种问题根本区分不出来候选人这方面的能力，所以他会不停的挑刺，看看你的抗压能力和随机应变的能力。这个问题的答案并不重要，因为他的这个问题很 low，99% 的人回答都是千篇一律一样的。所以这个问题就是看你和面试官之间的眼缘。