这是一个创建于 734 天前的主题，其中的信息可能已经有所发展或是发生改变。
举个例子，最近有朋友跟我说，他们公司（创业小公司）测试部门上报老板说，产品 bug 多客户体验差是因为开发部门提测的版本 bug 非常多，导致他们有很多问题没测出来；开发反驳说人员太少，很多东西都是仓惶赶工完成的，bug 多是因为精力有限。老板一拍大腿，决定给测试加 2 个人！（ WTF ？？？）
我知道有的公司产品和测试是股东或者是核心管理层，所以有话语权，那么除掉这个原因外，还有什么其他原因呢？
 |
1
cue 2022-11-18 09:19:07 +08:00
在我司测试比研发和产品有话语权多了，因为 bug 数决定着绩效……
|
 |
2
coderxy 2022-11-18 09:22:14 +08:00
话语权是靠人去争取的， 如果你们的研发都是闷葫芦不知道去争取，那么必然会越来越无话语权
|
 |
4
cmdOptionKana 2022-11-18 09:25:20 +08:00
测试与开发表达的核心意思你说了, 但表达方法可能会造成影响.
另外可能测试工资低, 人员要求低, 所以老板愿意给测试加人. |
 |
5
inoreader 2022-11-18 09:28:21 +08:00
站在用户角度，你开发再牛 B ，你并发支持再高、效率再高啥的，都基本无感，一个严重 bug 就能毁了所有。
|
 |
6
elevioux 2022-11-18 09:28:24 +08:00
一个开发的工资顶两个测试？
|
 |
7
god7d OP @coderxy 你说的是一方面因素，很多公司产品和测试都敢于去争取，而开发部门很多却不敢争取，不知道是什么愿意呢
@cmdOptionKana 确实，从老板的思维角度来看，多招几个测试虽然不能解决根本问题，但是性价比高 |
 |
8
zqlcrow 2022-11-18 09:32:38 +08:00  2
一直在中小公司，觉得产品有话语权，是应该的。
一是产品近天子（老板），二是产品近用户（上帝）。 有些 toB 端的东西，产品还要经常和客户打交道，这怎么能是码农可以比的呢？ 退一步说，码农说白了，是实现产品的设计的。 至于测试，待的公司都很小。测试完全没地位。 因为难以根据 bug 数来考核码农，所以测试就完全没地位了。 其实我好奇，大公司如何通过 bug 数考核。 毕竟优秀的码农负责复杂的模块，bug 数就容易多一些。 |
|
9
god7d OP @elevioux 很多企业招聘的黑盒测试人员工资非常低，而且公司只是让他们去测一些界面交互之类的小问题，大问题是不指望的，很多时候他们的工资可能会达到 1：3 ，这时候就出现一个哭笑不得的情况，就是测试在工作的时候是高度依赖开发的，甚至需要开发去讲解业务逻辑，很多小公司的人员架构就是 3 个专业开发+一个不专业测试
|
 |
10
devinww 2022-11-18 09:34:13 +08:00
刚毕业在一个小公司的时候
老板说的 会哭的孩子有奶喝 |
 |
11
yaron1123 2022-11-18 09:36:52 +08:00 12
产品为方向负责（一头），测试为质量负责（一尾），开发为实施负责（中间过程）；一头一尾是外部矛盾，中间过程是内部矛盾，对公司来说，外部矛盾都是大事，内部矛盾都好解决
|
 |
12
bjzhush 2022-11-18 09:37:46 +08:00
第一层原因是老板不懂技术，但是老板不会觉得自己不懂产品和业务，所以老板跟产品沟通无障碍，跟技术沟通是有一定障碍的。
第二层原因是从工作流上来说，虽然产品和技术都是老板手下的部门，但是产品会和老板沟通业务，技术多是和产品沟通，这就造成了一定的远近亲疏关系 |
|
13
god7d OP @zqlcrow 互联网公司确实是这样的，但是感觉现在除了互联网和传统软件，制造业和一些其他传统行业也有大量码农出没，能否讨论下这些行业的情况？比如一些做智能硬件的公司，产品应该相当有技术背景才能有能力进行设计，或者说这些行业根本不需要产品经理？只需要招聘一些美工 UI 就可以了？
|
 |
14
aogu555 2022-11-18 09:42:25 +08:00
离执行端(实际干活)越近越惨，因为每个环境提出的问题都需要压到执行端来完成。
离资源端越近越吃香。 上面千根线，下面一根针。 |
 |
15
yaphets666 2022-11-18 09:42:44 +08:00
这只是一个企业乱象的一部分，正是有这些乱象才给了后来人机会，才有老企业倒闭，新企业出来，时代的车轮滚滚向前。当然也可能向后。
|
 |
16
wetalk 2022-11-18 09:45:37 +08:00 1
产品和测试，妹子比率高一点，叽叽喳喳特别引人注意，多数研发同学不爱表达或者不善于表达
|
 |
17
fredli 2022-11-18 09:46:47 +08:00
技术不复杂好理解成熟了，就是测试话语权大
|
|
18
god7d OP @god7d 就我目前所处的设备制造行业来说，我不太清楚产品这个岗位是在互联网之前就有，还是互联网兴盛起来才分离出的一个岗位。一般情况来说，没有产品的概念，一般会有一名技术人员承担项目经理的角色，由他来完成整个项目的设计和把控，产品测试都是开发兼任，倒也不是说没有招聘这些岗位的预算，主要还是觉得不懂技术无法胜任这部分工作，强行分出这些岗位反而造成外行指导内行的尴尬境地
|
 |
19
xiaowei7777 2022-11-18 09:49:25 +08:00
开发写完代码，简单调一下，不自测就提测。这不是基本操作吗？做不完，为了自己绩效，到了提测日直接提测，然后压缩测试时间，一遍调一遍写。这不也是基本操作吗
|
 |
20
eason1874 2022-11-18 09:50:38 +08:00
别总觉得老板不知道哪个重要，老板不舍得多花钱罢了，按闹分配
本来 100 块的事，给你 90 ，你硬啃下来，老板不会因为感谢你分给你 5 的，除非你主动提 |
 |
21
xz410236056 2022-11-18 09:52:50 +08:00
“产品 bug 多客户体验差是因为开发部门提测的版本 bug 非常多，…………bug 多是因为精力有限。”
讲道理，小公司就喜欢玩这些虚的，讲证据啊。。。开发提交测试的时候附带单元测试（移动端基本没集成测试这一说，有的话一起附带）覆盖率和用例。测试也出统计数据报告，靠量化决策啊。这言论也太主观了吧 |
 |
22
dbskcnc 2022-11-18 10:01:41 +08:00
这个开发的锅不冤啊， 自己的选择而已，要我就是 bug 少而没按时完成
|
 |
23
amon 2022-11-18 10:05:18 +08:00
这种一般看 leader ，哪个部门 leader 强势， 哪个部门的人就相对有话语权。
|
 |
25
grissom 2022-11-18 10:11:06 +08:00
应该和话语权无关，因为开发部给老板的感觉是如果增加开发人员会增加 bug 数量，所以增加测试人员相对更合理一些。但老板并没有发现根本问题出在哪，或者没人让他知道。
|
 |
26
jink2018us 2022-11-18 10:24:39 +08:00
公司大了产品复杂了开发迭代了几代代码成了屎山，每个开发只知道自己一小块，码代码靠猜，加个功能捅堆 bug 。这时候测试有话语权了。
|
 |
27
otakustay 2022-11-18 10:28:29 +08:00
PM 为产品在市场的成功负责，QA 为产品交付的质量负责，从你的描述来看，研发为什么负责了呢？
|
 |
28
dreasky 2022-11-18 10:31:44 +08:00
产品和测试是负责人 技术只是工具人
|
 |
29
iyaozhen 2022-11-18 10:39:32 +08:00
多年测试，我觉得测试有话语权是对的，我们一直是对上线有一票否决权，有质量问题就不能上。这个角度看确实有话语权，但其实还是岗位性质决定的。
大部分情况下测试也不能干预研发的架构设计，也只能提点意见。不过之前我个人老喜欢干这个，因为决定研发按我的设计来我好测一点，有把握，bug 少。 多年斗争经验来看，“开发反驳说人员太少，很多东西都是仓惶赶工完成的，bug 多是因为精力有限。” 你们这个反驳的不对，应该是 PM 需求不合理、老改，排期短，测试提测标准不明确，整体要让产品的时间往前压缩，测试的时间提前介入。哈哈哈 |
 |
31
amirobotics 2022-11-18 11:02:08 +08:00
我这里是 bug 决定一切。
|
 |
32
dddd1919 2022-11-18 11:24:52 +08:00
开发太菜
|
 |
33
mosakashaka 2022-11-18 12:02:07 +08:00 1
老板不懂技术，怕开发忽悠他
所以拿测试制衡开发 |
 |
34
LuckyPocketWatch 2022-11-18 12:08:26 +08:00
你见过产品是开发的上级么？
开发部门由产品领导，开发部门分成若干个小组，每天向产品的指定人员汇报工作进度，研发的考核也是由产品来定的 |
 |
35
nc4697 2022-11-18 12:23:28 +08:00
弱肉强食。平时多表现的强势一些，总是能拿到话语权的
|
 |
36
iClarence 2022-11-18 14:32:39 +08:00
朋友部门的前端 BUG 率 = 测试提交的总（前端+后端） Bug List ，前后端的占比，例如 200 个 bug ，后端 2 个人，前端 2 个人，你有 50 个，就是 25%，占比高绩效就低分，然后说你质量差，跟着进行一轮 PUA ，说你产出不符合期望。
测试一言不合就说，那我给你打 bug ，你说这样测试地位能不高么？ 前后端对接联调期间后端处理掉的 bug ，不计算在 buglist 中，然后前后端用来算占比。 |
 |
37
yufeng0681 2022-11-18 14:39:41 +08:00
1 、做一个 /一批 量化清晰的需求，不需要话语权
2 、做 模棱两可，没细节的需求，需要话语权来决定最后时刻，需求是 A 还是 B 3 、测试加人还是研发加人？老板不会因为你朋友说的这么一点信息做决策，你朋友是底层研发，看不到老板视野里面的其他信息，人总是喜欢主观判断，而且当自己是失利一方时，更加容易推导出：自己是受害者 4 、bug 一般是业务代码出错， 软件可靠性，性能，可测试性等质量属性没有设计没有代码，我们一般称之为没有实现，待完善。 如果业务代码一堆 bug ，那是没想清楚，不是没时间； 没时间的表现是某个功能没开发； 5 、出了 bug ，还要花时间修复，调测，再进入测试，这些时间成本可比你编码阶段想清楚，消耗的时间 /成本更大。 |
 |
38
wangxiaoaer 2022-11-18 14:45:16 +08:00
技术人员总以为自己是中流砥柱，可是换到建筑行业，程序员就是工地搬砖砌墙抹灰的，要什么话语权？
|
 |
39
fengzeyan 2022-11-18 14:51:54 +08:00
@wangxiaoaer 有没有可能你看到的工作内容只是搬砖呢?
|
 |
40
Pichai 2022-11-18 14:54:24 +08:00
测试和研发都是为产品服务的呀！
|
 |
41
fairless 2022-11-18 15:03:47 +08:00
正常，毕竟是码农，而不是技术专家
|
 |
42
mejee 2022-11-18 15:04:42 +08:00
> 开发反驳说人员太少，很多东西都是仓惶赶工完成的，bug 多是因为精力有限
这么说，不就坐实了研发的 bug 多嘛。既然测试说研发不行，那研发的正确回答应该是：测试能力不行，测试完成的东西 bug 多 |
 |
43
Hanson16043287 2022-11-18 15:11:22 +08:00
排期以内问题，是自己的问题
排期以外问题，非自己的问题 不合理的排期，会有一点点惨 如果没有排期，那会死的很惨 专业性排第一，不专业会挨批 无论测试，还是产品，UI |
 |
44
ymcj001 2022-11-18 15:23:01 +08:00
开发需要换个思路，不要赶着实现全部功能，先实现一小部分，但是把这部分的内容给完善了，实在不行自己多测几次
|
 |
45
cedoo22 2022-11-18 15:24:05 +08:00
好多公司 对 BUG 没有明确的定义， 开发时没有很完整的规范去遵守， 让测试提个测试标准 多半拿不出。
等到测试的时候， 好多 bug 都是完全靠 测试去定义。 有些问题， 测试按自己 的 逻辑， 说是 bug 就是 bug 。。。就开始扯皮。。。 你要相信， 找问题的人永远占着先手。。。。 我一个月 3000 工资，丝毫不影响我评论 马云 、 吐槽马化腾 |
 |
46
silencil 2022-11-18 15:25:10 +08:00
在我司，开发更有话语权。重构系统，我独立设计，包括厘清业务，确定页面原型等。原因：除了开发，其他人不熟悉业务。产品是外包，测试大部分时间在做交付。
|
 |
47
jones2000 2022-11-18 15:28:22 +08:00
2 组测试人员。 开发写业务模块，1 组测试对应开发的业务模块写单元测试，另外一组对应整理业务流程写测试。 这样需求变动了以后， 能快速的做回归测试。 光靠开发有什么用，开发只是产品开发流程中的 1 小部分，基本就干体力活的。
|
 |
48
ersic 2022-11-18 15:29:34 +08:00
不背锅就行，话语权谁爱要谁要。
|
 |
49
dudubaba 2022-11-18 15:33:00 +08:00 1
我知道的某知名互联网公司，产品 > 测试 > 开发，产品负责抄竞品的东西，然后开发，测试最后一把关，产品核验后发布。测试这一环节决定质量问题，如果 bug 率过高（前后端单独统计）会不建议发布，次数多了肯定会影响开发绩效考核。所以开发其实很卑微的。唯一硬起来的时候是跟不懂技术的产品怼的时候。。。
|
 |
51
jklove123bai 2022-11-18 16:11:00 +08:00
一般产品离老板近，给老板汇报工作。而且产品说的话老板能听懂，研发就不一定了
|
 |
52
STtree 2022-11-18 16:16:12 +08:00
我觉得测试和产品只要不犯低级错误，一般很难去挑毛病。但是再牛的开发也不敢拍胸脯保证自己 100%没 bug ，所以挑开发的毛病是比较容易的。如果测试和产品再能说会道一点，那么老板肯定会觉得产品不好是因为开发不行。
|
 |
53
rocksolid 2022-11-18 16:32:00 +08:00
因为开发老是觉得技术能解决一切，现实就是谁会说话，谁会赚钱，老板就听谁的
|
 |
54
milkmlik 2022-11-18 16:38:30 +08:00
看责任归属吧，产品上线，出了问题，测试没测试出来，产品验收也没发现，产品、测试担责任，如果产品、测试甩锅，那产品、测试应该也没啥话语权吧。
|
 |
55
lindas 2022-11-18 17:10:39 +08:00
谁干的活重要谁就有话语权，有些人只会写 curd ，只懂自己写的那一块，自己的产品能干什么都不清楚，老板怎么会听他的
|
 |
57
yoa1q7y 2022-11-18 19:49:28 +08:00
我们这产品离职率可比开发高多了
因为产品是一个项目的策划人，方案的好坏直接决定了项目的未来 项目收益不及预期一般是不会找开发的麻烦的，但产品是直接责任人 别看产品只是写写文档动动嘴，挨骂背锅的时候开发一般也见不到啊 |
 |
58
yulin1103 2022-11-18 20:10:55 +08:00 via Android
公司是 toB 的金融软件，甲方爸爸用着不爽的地方说是缺陷就是缺陷。产品直接与客户对接，话语权最大，其次是业务测试，业务开发可以说是最没话语权的了
|
 |
59
gyinbj 2022-11-19 00:34:18 +08:00
我觉得可能是因为业务流程 和 用户体验需要要更好一些吧
毕竟开发人员基本不怎么使用自己开发出来的东西。。 使用者各式各样~ 需求也各式各样 |
Select Language