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% 的人回答都是千篇一律一样的。所以这个问题就是看你和面试官之间的眼缘。

感觉面试官心情不好，急匆匆的被叫过来给我面试，他的态度让我感觉好像研测理解不一致全是我的责任一样，要我必须根治这种问题，我们测试确实需要去跟进和确认，这肯定得有一方做出牺牲去确认的，但不是测试单方面的问题吧，只要是人参与的工作那就一定会有误解，研测产三方都不希望如此，可是无法避免的啊，当时也面很久了比较累，后面发挥得也不太好，确实一直被他带着节奏追问了很久，他也一副非常不满意的样子，很后悔没有反问一句贵公司又是如何处理这类问题的

当研测双方对需求理解不一致时，永远是你对，就再也不会出现不一致的情况了。
你——就是可以说话的需求！是产品的代言人！

你不要被他的问题绕进行了，以终为始，需求就应该是明确的，澄清的，如果不清楚就应该理清，BUG 修复的成本在后期可是玩远大于前期，如果遗漏到产品验收时再发现，修改代码，那需求的交付质量将更加难以评估，面试管可能是看你对于有些原则是不是应该坚持，不妥协，这也是测试人员应有的素质

反问面试官，为啥会出现理解不一致，需求没评审？用例没有评审？设计没有评审？阁下又该如何应对

研测双方对需求理解不一致，是个人都会先找产品确认吧，一锤定音。
我们都是开发、测试、产品拉个群，抛出自己的疑惑，请产品确认，产品自己拿不准的，再进行讨论，最后总能达成一致。这个时间是怎么也节约不出来的。

找产品确认浪费时间，也比做错误需求，白白做无用功好得多

竟然有相同际遇的

我在你那个年龄还在点点点

我在的公司 3 个月没发工资了，想换一家连面试都约不到

不是你的问题，是大环境的问题，也许换个赛道会有惊喜，年轻人加油吧~

这已经不是经济下行的问题了，即使经济不下行，走到这个关口也必然是如此。
前几年互联网大火，我们进来，实际上是赶上了风口，老大们提的互联网 +，把所有实体都插上互联网的翅膀。各个行业都有互联网部门 或者买菜 外卖 打车之类行业的互联网化。

但是这个互联网化是有尽头的，所有行业都互联网一遍，不会再有多少互联网的余地了。没有扩张也就没有新增岗位。

加上原来扩张期巨头们同一行业会投很多企业，比如打车，到一定阶段它就会整合 成剩下仅有的几家，形成垄断，这也意味着岗位的缩减。

所以啊，想再回到那个急速扩张的时代，干一年跳翻倍的时代，绝不可能了，除非有新的突破带来巨大的岗位 i 需求，但是大家也看到了，这一波大模型很多企业巨资投入，但是轮到我们了吗，并没有惠及普通从业者。提供岗位也很少