江苏龙网

  1. 首页 > 生活 > >

程序新人因为不熟悉产品系统，最终修bug不完全，需要返工，谁需要背这个黑锅?

脱离标准谈责任都是耍流氓。对于软件开发来说，投入对于软件质量是边际效益递减的。所以软件开发从来都不是保证软件没有Bug的，而是检验软件是否符合最终要求。要求的直观体现就是测试用例(Test case)， 所以测试用例评审(Test case review)的意义是，建立整个团队认可的最终质量标准。所以大公司避免这个问题的方法是，把标准定得规范和量化。有了这个标准，才能讨论上面说的责任问题。如果测试没有按照用例执行，或者根本没有用例，导致这样的情况，那么是测试的责任。如果测试用例中没有涉及这类内容，但也没有进行过用例审核，那么是团队的流程问题。如果进行过用例审核并出现了这样的问题，那么开发和测试都有责任。或者说，不应该追究谁的责任，而是应该把用例和标准做进一步完善。如果测试用例里不应该包括这样的情况，那应该看作改善或者功能，谁都没有责任。所以大公司做软件一般都有非常详细的测试用例和文档，那就是软件质量底线的保证。只要跑完了这些用例，绝大部分时候能保证软件可以发行，即使存在Bug，一般也不会影响软件的主要功能。最后，对什么叫才叫好的规范，我作为一个游戏测试，觉得可以参考的SONY或者微软的TRC(Technical Requirements Checklist)，我觉得按照这样的标准来测试，游戏好不好玩不知道，但至少作为软件能保证质量。当然，像育碧这样规范完善的大公司，上次的刺客信条做成那个鬼样子，我就实在不知道怎么吐槽了。
■网友
Work as a team, pls.无论成败，都是整个团队的。如果黑锅可以一个人背，那么成功自然也可以被独占，这样的风格，是没办法建立起团队的。具体地说，整个流程上的人，没有谁可以摆脱责任。程序员没能覆盖全部逻辑分支自然是问题，测试人员没能覆盖全部业务场景也是问题。暂时不考虑是能力不够还是不认真的缘故，首先问题的存在是无法回避的。相关的人员，只要任何一个人，发现了“路径三”，都可以避免问题的出现————但是既然谁也没发现，那么就都不算无辜。个人不太喜欢“寻找责任者”的方式————并非要掩护哪些成员，而是不鼓励“丢黑锅”的行为。因为最终目标是“解决问题”（例如体高品质、提升技能等等），黑锅扣完了不见得问题就解决了，仅仅是“问题不在于我”了而已。说得严重一点，如果遇到非常严重的、影响巨大的BUG，就算找到责任人又能怎样？别说辞退了，甚至暴打一顿就能挽回损失么？根本不可能的。所以要点还是“未来怎样避免”类似的问题。从这个角度出发，整个流程上所有的人，都必须“主动的去做些什么”。程序员必须要多考虑代码逻辑，测试人员要多考虑操作场景，管理人员要针对这个事件给出对策并且扩散出去。责任一定要是整个团队的，如果仅仅定位到个人，那么其他人就会觉得和自己无关，那么以后也不会把精力放在提高上面，而是努力的推卸责任了。个人的责任要有，但是要从“解决问题”的角度来找，比如某些特殊情况下，只要更换一个成员就可以彻底解决所有问题，那么责任就是这位不幸的人的。从管理者的角度来看：1）类似问题是无法避免的。因为人的能力是有限的，总有盲点或者懈怠的时候。所以关键是把此类问题控制在一个范围内，力争Bug数量不要太多、程度不要太严重。2）人是有缺陷的，不完美的。所以对策永远有限要考虑其它方面，例如自动化工具、作业流程等等。这会带来额外成本，但是品质本身就是需要成本的，世界上没什么东西是真的free的。3）能力不够——培训、招聘。流程不备——完善它。不认真——谈心或者其它惩罚（包括辞退）。问题不可怕，可怕的是没对策。问题一定会出现，出现是必然，没出现是运气。所以建立一个流程和标准，比解决个别问题，要重要的多。大而化之的论述之外，针对问题的细节，可以有很多不同的思考。比如，Bug报告是否有责任覆盖所有场景？首先要问“这能不能做到”？然后是“该不该做到”？当然如果能达到这个程度再好不过。实际上提问的例子里面，程序员估计就是这样理解的————bug报告既然给出两个场景，那么我针对修改两个场景，任务完成！或者反过来，既然程序员分析出两个可能性，那么我就测试这两个就OK。但实际上这是不可能的，参考上文，人是有缺陷的不完善的，指望别人给出的东西彻底完美，不太现实。而且能够提供很完善的产出，这样的人薪资水平会怎样，可想而知，但是工作总归有成本限制。所以bug报告一定是“不完整”的。同理，代码的修改也一定是“不彻底”的。即使真的很完整很彻底，也要怀疑它不完善不彻底————掘地三尺得去找了，找不出来是能力问题，而掉以轻心盲目乐观就是态度问题了。从对策角度来看，可以考虑如下方向：A）连坐制。出了问题，整个流程上的人都要承担损失，避免推卸责任、各扫门前雪。B）Bug的密度和重大程度，必须和人员的收益挂钩。而且bug重大度的标准必须清晰————比如例子里面的bug应该算“严重”，因为是boss或者外部使用者反馈的，这意味着即使bug本身比较小，但是产生的影响却很大。C)另外考虑到一个关键词“新人”，这意味着还有其它改善方式，例如：加强培训，加强内部沟通（文档化或者讨论制），加强代码的可读性（推行强制标准和自动化检查工具）。总之，只期待新人都可以自动的快速成长，既不现实也不保险————新人捅娄子是意料之中，带来惊喜才是中奖了。如果对新人没有任何辅助措施，那么责任不在于新人，而在于管理者。PS，互联网开发一般不会采用太笨重的方式，多倾向快速迭代，所以往往也不会喜欢“文档化”（形式不限）。但是请考虑如下原因：1）人员流动不可避免。所以总会出现新手要面对旧系统的情况。每次都从零学习是个什么成本？2）犯过一次的错误，为什么要犯第二次？所以，哪怕自己建立跟踪系统也无所谓，请把业务场景啦、产生问题的例子啦，适当的文档化，作为check list。这是个笨办法，但是至少可以避免“栽倒在同一个坑里”。


推荐阅读


上一篇：迄今为止哪家互联网公司对人类生活社会贡献最大

下一篇：降到2480的锤子4g,相比同价位的国产机有哪些致命缺陷?