如果准雇主告诉您“由于开发人员讨厌修复错误,他们将错误修复外包了”,您会怎么想?您可能会担心什么?
如果准雇主告诉您“由于开发人员讨厌修复错误,他们将错误修复外包了”,您会怎么想?您可能会担心什么?
Answers:
解决我们自己的错误实际上使我们成为更好的开发人员。对我来说,这是一个非常愉快的时刻。特别是当它们被很好地报道时。
如果他们不喜欢修复错误,那么问题就出在其他地方。
我怀疑问题出在管理人员如何看待错误,或更糟糕的是,错误的设计决策和/或没有(单元)测试会导致错误修复。
外包错误修复可能会使情况更糟。
开发人员可能会想降低质量。谁在乎?一些海上家伙在那里清理他们的混乱。
直到离岸人员替换在岸人员为止。
离开,逃跑 ...快速,永不回头...
我曾在这样一家公司工作,他们认为他们很聪明,
嘿,我们都有他们所有的错误,但是我们的前辈抱怨他们花费太多时间修复错误。
让我们开设一个离岸办公室,让其他人来处理这个问题。
对于一个听起来听起来像是一个非常好的计划的经理,开发人员最终被释放来解决创建次佳事物的更有趣的任务!
......等等...
两年后,他们从总公司的5个开发人员团队转到了2个创建新东西的团队和30个发现并修复错误的团队。
您知道吗...错误修复团队正在苦苦挣扎,他们跟不上。
这使得“前辈”完全无法为自己的错误负责。更糟糕的是,由于一切都发生得太遥远,因此管理人员也没有意识到,并且代码质量从已经很糟糕的质量水平急剧下降了。
当我离开时,他们已经为臭虫修复者开设了两个办事处,他们仍然不能跟上现在唯一创建它们的开发人员。他们实际上认为这是因为新手不够聪明...
所以是的,从现在开始,如果一家公司说他们将其漏洞修复工作外包给了一家海外办事处,请相信我....我运行起来...很快。
这是纸袋管理方法。
站在铁路上,等待火车来临时,一看到火车,就将纸袋放在头上,然后……POOF ..火车不见了!魔法 !
如果准雇主告诉您“由于开发人员讨厌修复错误,他们将错误修复外包了”,您会怎么想?您可能会担心什么?
我会跑得很远很远。开发人员总是,总是,总是有责任修复自己的错误。吃狗粮是良好工程的基本原则。
此外,错误修复同样重要,也许比开发更重要。我的意思是,开发是代码编写,测试和调试/修复。
我从这家公司得到的是,他们将错误修复视为第二类任务。这本身就很令人不安,我会高度质疑他们的工作质量(以及因此而来的工作环境)。更令人不安的是,他们将对他们而言是二等工作委托给离岸工人。那更令人不安。显然,他们的工程过程中包含着社会分层。
缺陷总是导致变更的根本原因,通常,错误是由引入变更的人负责的。谁比鼻祖更好地了解错误的性质及其解决方案?
如果它是在全球范围内委派的,那么如何确保原始作者可供离岸工程师使用?
他甚至有空吗,留下离岸工程师,除了积压的错误和截止日期之外,别无他物,但没有Metropole的支持?一个人可能希望执行哪种类型的错误修复?谁修复他的错误?是什么阻止Metropole的开发人员通过修正验尸来学习?
所有领域都有混蛋。在软件中尤其如此。由于这是不可避免的,因此您唯一的选择是与比您了解更多或做正确的混蛋一起工作。该公司似乎不符合该描述。
总之,逃跑。
这听起来有点像我以前的雇主,除了“准雇主”位。他们一直在让开发人员流失,失去太多支持现有产品,而又增加了法律法规变更所需的新功能(办公室收入的60%来自基于VB6的产品,而MS表示VB6运行时不会在将来的任何操作系统中分发,因此就像Vista出现时一样-疯狂地解决问题)。想要使公司很快上市的力量,所以他们正在让所有人都在渴望资源,以使资产负债表看起来比实际更好。因此,在海外聘用是接近市场的唯一途径。
根据我的经验,引述所说的是您的准雇主便宜。
这取决于它们“修复错误”的含义。如果这是在开发/测试周期内修复错误,那么这很奇怪,这是原始开发人员的工作。另一方面,如果它们表示已将发布产品的维护外包,那么这并不罕见,这不是我担心的事情。
实际上,某些公司在潜意识中存在着这一政策。我为外包商工作;我自己和我的同事比现场的人更熟练的程序员,他们要求我们教给他们如何使用工具等,但是另一方面,我们比他们更快地发现他们的代码中的问题。
通常,客户的程序员与至少一些用户物理上位于同一建筑物内,因此他们更有可能获得无法跨半球的上下文。我们发现它运作良好,对我而言,缺失的部分是他们没有在审查我们的代码,因此当合同完成时,他们可能会有一些意外或疑问,这不是由于我们方面的任何伪劣做法,而是由于您遇到的常见问题接管别人的项目。
无论如何,我很高兴在我们的情况下这不是官方政策,因此我认为这会侵蚀现场程序员,使他们只不过是BA。