为什么很多公司测试和产品比开发更有话语权？

[god7d]

举个例子，最近有朋友跟我说，他们公司（创业小公司）测试部门上报老板说，产品 bug 多客户体验差是因为开发部门提测的版本 bug 非常多，导致他们有很多问题没测出来；开发反驳说人员太少，很多东西都是仓惶赶工完成的，bug 多是因为精力有限。老板一拍大腿，决定给测试加 2 个人！（ WTF ？？？）

我知道有的公司产品和测试是股东或者是核心管理层，所以有话语权，那么除掉这个原因外，还有什么其他原因呢？

[cue]

在我司测试比研发和产品有话语权多了，因为 bug 数决定着绩效……

[coderxy]

话语权是靠人去争取的， 如果你们的研发都是闷葫芦不知道去争取，那么必然会越来越无话语权

[god7d]

@cue 按这个逻辑，研发永远是负绩效😂

[cmdOptionKana]

测试与开发表达的核心意思你说了, 但表达方法可能会造成影响.

另外可能测试工资低, 人员要求低, 所以老板愿意给测试加人.

[inoreader]

站在用户角度，你开发再牛 B ，你并发支持再高、效率再高啥的，都基本无感，一个严重 bug 就能毁了所有。

[elevioux]

一个开发的工资顶两个测试？

[god7d]

@coderxy 你说的是一方面因素，很多公司产品和测试都敢于去争取，而开发部门很多却不敢争取，不知道是什么愿意呢

@cmdOptionKana 确实，从老板的思维角度来看，多招几个测试虽然不能解决根本问题，但是性价比高

[zqlcrow]

一直在中小公司，觉得产品有话语权，是应该的。

一是产品近天子（老板），二是产品近用户（上帝）。
有些 toB 端的东西，产品还要经常和客户打交道，这怎么能是码农可以比的呢？
退一步说，码农说白了，是实现产品的设计的。


至于测试，待的公司都很小。测试完全没地位。
因为难以根据 bug 数来考核码农，所以测试就完全没地位了。


其实我好奇，大公司如何通过 bug 数考核。
毕竟优秀的码农负责复杂的模块，bug 数就容易多一些。

[god7d]

@elevioux 很多企业招聘的黑盒测试人员工资非常低，而且公司只是让他们去测一些界面交互之类的小问题，大问题是不指望的，很多时候他们的工资可能会达到 1：3 ，这时候就出现一个哭笑不得的情况，就是测试在工作的时候是高度依赖开发的，甚至需要开发去讲解业务逻辑，很多小公司的人员架构就是 3 个专业开发+一个不专业测试

[devinww]

刚毕业在一个小公司的时候
老板说的 会哭的孩子有奶喝

[yaron1123]

产品为方向负责（一头），测试为质量负责（一尾），开发为实施负责（中间过程）；一头一尾是外部矛盾，中间过程是内部矛盾，对公司来说，外部矛盾都是大事，内部矛盾都好解决

[bjzhush]

第一层原因是老板不懂技术，但是老板不会觉得自己不懂产品和业务，所以老板跟产品沟通无障碍，跟技术沟通是有一定障碍的。
第二层原因是从工作流上来说，虽然产品和技术都是老板手下的部门，但是产品会和老板沟通业务，技术多是和产品沟通，这就造成了一定的远近亲疏关系

[god7d]

@zqlcrow 互联网公司确实是这样的，但是感觉现在除了互联网和传统软件，制造业和一些其他传统行业也有大量码农出没，能否讨论下这些行业的情况？比如一些做智能硬件的公司，产品应该相当有技术背景才能有能力进行设计，或者说这些行业根本不需要产品经理？只需要招聘一些美工 UI 就可以了？

[aogu555]

离执行端(实际干活)越近越惨，因为每个环境提出的问题都需要压到执行端来完成。
离资源端越近越吃香。
上面千根线，下面一根针。

[yaphets666]

这只是一个企业乱象的一部分，正是有这些乱象才给了后来人机会，才有老企业倒闭，新企业出来，时代的车轮滚滚向前。当然也可能向后。

[wetalk]

产品和测试，妹子比率高一点，叽叽喳喳特别引人注意，多数研发同学不爱表达或者不善于表达

[fredli]

技术不复杂好理解成熟了，就是测试话语权大

[god7d]

@god7d 就我目前所处的设备制造行业来说，我不太清楚产品这个岗位是在互联网之前就有，还是互联网兴盛起来才分离出的一个岗位。一般情况来说，没有产品的概念，一般会有一名技术人员承担项目经理的角色，由他来完成整个项目的设计和把控，产品测试都是开发兼任，倒也不是说没有招聘这些岗位的预算，主要还是觉得不懂技术无法胜任这部分工作，强行分出这些岗位反而造成外行指导内行的尴尬境地

[xiaowei7777]

开发写完代码，简单调一下，不自测就提测。这不是基本操作吗？做不完，为了自己绩效，到了提测日直接提测，然后压缩测试时间，一遍调一遍写。这不也是基本操作吗

[eason1874]

别总觉得老板不知道哪个重要，老板不舍得多花钱罢了，按闹分配

本来 100 块的事，给你 90 ，你硬啃下来，老板不会因为感谢你分给你 5 的，除非你主动提

[xz410236056]

“产品 bug 多客户体验差是因为开发部门提测的版本 bug 非常多，…………bug 多是因为精力有限。”
讲道理，小公司就喜欢玩这些虚的，讲证据啊。。。开发提交测试的时候附带单元测试（移动端基本没集成测试这一说，有的话一起附带）覆盖率和用例。测试也出统计数据报告，靠量化决策啊。这言论也太主观了吧

[dbskcnc]

这个开发的锅不冤啊， 自己的选择而已，要我就是 bug 少而没按时完成

[amon]

这种一般看 leader ，哪个部门 leader 强势， 哪个部门的人就相对有话语权。

[RealJacob]

@zqlcrow 有没有可能，大公司不通过 bug 数考核。。。

[grissom]

应该和话语权无关，因为开发部给老板的感觉是如果增加开发人员会增加 bug 数量，所以增加测试人员相对更合理一些。但老板并没有发现根本问题出在哪，或者没人让他知道。

[jink2018us]

公司大了产品复杂了开发迭代了几代代码成了屎山，每个开发只知道自己一小块，码代码靠猜，加个功能捅堆 bug 。这时候测试有话语权了。

[otakustay]

PM 为产品在市场的成功负责，QA 为产品交付的质量负责，从你的描述来看，研发为什么负责了呢？

[dreasky]

产品和测试是负责人 技术只是工具人

[iyaozhen]

多年测试，我觉得测试有话语权是对的，我们一直是对上线有一票否决权，有质量问题就不能上。这个角度看确实有话语权，但其实还是岗位性质决定的。

大部分情况下测试也不能干预研发的架构设计，也只能提点意见。不过之前我个人老喜欢干这个，因为决定研发按我的设计来我好测一点，有把握，bug 少。

多年斗争经验来看，“开发反驳说人员太少，很多东西都是仓惶赶工完成的，bug 多是因为精力有限。” 你们这个反驳的不对，应该是 PM 需求不合理、老改，排期短，测试提测标准不明确，整体要让产品的时间往前压缩，测试的时间提前介入。哈哈哈

[god7d]

@iyaozhen 您这个牛了，还可以干预研发的架构设计，看来也是技术大牛转的测试

[amirobotics]

我这里是 bug 决定一切。

[dddd1919]

开发太菜

[mosakashaka]

老板不懂技术，怕开发忽悠他
所以拿测试制衡开发

[LuckyPocketWatch]

你见过产品是开发的上级么？

开发部门由产品领导，开发部门分成若干个小组，每天向产品的指定人员汇报工作进度，研发的考核也是由产品来定的

[nc4697]

弱肉强食。平时多表现的强势一些，总是能拿到话语权的

[iClarence]

朋友部门的前端 BUG 率 = 测试提交的总（前端+后端） Bug List ，前后端的占比，例如 200 个 bug ，后端 2 个人，前端 2 个人，你有 50 个，就是 25%，占比高绩效就低分，然后说你质量差，跟着进行一轮 PUA ，说你产出不符合期望。
测试一言不合就说，那我给你打 bug ，你说这样测试地位能不高么？
前后端对接联调期间后端处理掉的 bug ，不计算在 buglist 中，然后前后端用来算占比。

[yufeng0681]

1 、做一个 /一批 量化清晰的需求，不需要话语权
2 、做 模棱两可，没细节的需求，需要话语权来决定最后时刻，需求是 A 还是 B
3 、测试加人还是研发加人？老板不会因为你朋友说的这么一点信息做决策，你朋友是底层研发，看不到老板视野里面的其他信息，人总是喜欢主观判断，而且当自己是失利一方时，更加容易推导出：自己是受害者
4 、bug 一般是业务代码出错， 软件可靠性，性能，可测试性等质量属性没有设计没有代码，我们一般称之为没有实现，待完善。 如果业务代码一堆 bug ，那是没想清楚，不是没时间； 没时间的表现是某个功能没开发；
5 、出了 bug ，还要花时间修复，调测，再进入测试，这些时间成本可比你编码阶段想清楚，消耗的时间 /成本更大。

[wangxiaoaer]

技术人员总以为自己是中流砥柱，可是换到建筑行业，程序员就是工地搬砖砌墙抹灰的，要什么话语权？

[fengzeyan]

@wangxiaoaer 有没有可能你看到的工作内容只是搬砖呢?

[Pichai]

测试和研发都是为产品服务的呀！

[fairless]

正常，毕竟是码农，而不是技术专家

[mejee]

> 开发反驳说人员太少，很多东西都是仓惶赶工完成的，bug 多是因为精力有限

这么说，不就坐实了研发的 bug 多嘛。既然测试说研发不行，那研发的正确回答应该是：测试能力不行，测试完成的东西 bug 多

[Hanson16043287]

排期以内问题，是自己的问题
排期以外问题，非自己的问题
不合理的排期，会有一点点惨
如果没有排期，那会死的很惨

专业性排第一，不专业会挨批
无论测试，还是产品，UI

[ymcj001]

开发需要换个思路，不要赶着实现全部功能，先实现一小部分，但是把这部分的内容给完善了，实在不行自己多测几次

[cedoo22]

好多公司 对 BUG 没有明确的定义， 开发时没有很完整的规范去遵守， 让测试提个测试标准 多半拿不出。
等到测试的时候， 好多 bug 都是完全靠 测试去定义。 有些问题， 测试按自己 的 逻辑， 说是 bug 就是 bug 。。。就开始扯皮。。。


你要相信， 找问题的人永远占着先手。。。。 我一个月 3000 工资，丝毫不影响我评论 马云 、 吐槽马化腾

[silencil]

在我司，开发更有话语权。重构系统，我独立设计，包括厘清业务，确定页面原型等。原因：除了开发，其他人不熟悉业务。产品是外包，测试大部分时间在做交付。

[jones2000]

2 组测试人员。 开发写业务模块，1 组测试对应开发的业务模块写单元测试，另外一组对应整理业务流程写测试。 这样需求变动了以后， 能快速的做回归测试。 光靠开发有什么用，开发只是产品开发流程中的 1 小部分，基本就干体力活的。

[ersic]

不背锅就行，话语权谁爱要谁要。

[dudubaba]

我知道的某知名互联网公司，产品 > 测试 > 开发，产品负责抄竞品的东西，然后开发，测试最后一把关，产品核验后发布。测试这一环节决定质量问题，如果 bug 率过高（前后端单独统计）会不建议发布，次数多了肯定会影响开发绩效考核。所以开发其实很卑微的。唯一硬起来的时候是跟不懂技术的产品怼的时候。。。

[tibifide]

@elevioux 高级开发工资确实能抵两个中级测试

[jklove123bai]

一般产品离老板近，给老板汇报工作。而且产品说的话老板能听懂，研发就不一定了

[STtree]

我觉得测试和产品只要不犯低级错误，一般很难去挑毛病。但是再牛的开发也不敢拍胸脯保证自己 100%没 bug ，所以挑开发的毛病是比较容易的。如果测试和产品再能说会道一点，那么老板肯定会觉得产品不好是因为开发不行。

[rocksolid]

因为开发老是觉得技术能解决一切，现实就是谁会说话，谁会赚钱，老板就听谁的

[milkmlik]

看责任归属吧，产品上线，出了问题，测试没测试出来，产品验收也没发现，产品、测试担责任，如果产品、测试甩锅，那产品、测试应该也没啥话语权吧。

[lindas]

谁干的活重要谁就有话语权，有些人只会写 curd ，只懂自己写的那一块，自己的产品能干什么都不清楚，老板怎么会听他的

[ultimate]

@cue 华为？

[yoa1q7y]

我们这产品离职率可比开发高多了
因为产品是一个项目的策划人，方案的好坏直接决定了项目的未来
项目收益不及预期一般是不会找开发的麻烦的，但产品是直接责任人
别看产品只是写写文档动动嘴，挨骂背锅的时候开发一般也见不到啊

[yulin1103]

公司是 toB 的金融软件，甲方爸爸用着不爽的地方说是缺陷就是缺陷。产品直接与客户对接，话语权最大，其次是业务测试，业务开发可以说是最没话语权的了

[gyinbj]

我觉得可能是因为业务流程 和 用户体验需要要更好一些吧
毕竟开发人员基本不怎么使用自己开发出来的东西。。
使用者各式各样~ 需求也各式各样