it-swarm.cn

软件工程师也应该充当技术支持吗?

软件工程师也应该充当技术支持吗?也就是说,公司应允许工程师戴上软件工程师帽和技术支持帽。如果工程师的大部分时间都被技术支持占用,那么似乎将丧失编写软件的能力。

49
Brian

对于工作中具有软件开发组件的公司,无论是否为软件公司,这都是一个经典问题。我一直为此感到挣扎。

让开发人员参与生产支持

优点

  • 战斗“在真空中发展”综合症。了解用户如何使用该应用程序很有价值。直到我最终把它看作一个年轻的开发人员,我才意识到自己是一个多么糟糕的UI开发人员。我只关心编码而不是设计,分析或用户角度。
  • 不如他们想像的那样出色的开发人员可以谦虚(尽管不能保证您将获得这种好处;某些开发人员确实是遗忘,自私和固执的)。
  • 开发人员将获得领域知识。如果您的开发人员要最终变得更好地识别和填补业务分析阶段(假设有)遗漏的空白,那么这至关重要。
  • 好的支持是一个营销点。如果做得好,客户会喜欢上它。具有沟通能力和领域知识的全面开发人员能够做到这一点。但是,我仍然希望应用程序具有足够高的质量,因此不需要支持。卓越的质量是其自身的客户支持形式(也是营销点)。

缺点

  • 中断因子。这是混合项目工作和支持工作的第一大错误,没有障碍。项目会干扰支持,而支持会干扰项目。项目取决于估计和里程碑进度,支持是不可预测的,可能涉及即刻的紧迫性。项目基于进度表,支持基于中断。这不是一个愉快的组合,并且使开发人员很难处理。
  • 并非每个人都擅长支持。对应用程序或业务缺乏经验的人,或者个性或沟通技巧使他们更好地不受用户访问影响的人,在支持方面可能效果不佳。
  • 资源使用效率低下。弗兰克·希亚尔(Frank Shearar)在评论中指出,进行琐碎支持的开发人员可能比一级支持技术贵。

以我的经验,大多数开发人员都不喜欢支持。我在项目和支持方面都曾担任过,我对此表示同情。当必须同时执行这两项任务时,缓解因素通常是加班费,通常是无偿的,以应对紧急情况并仍使项目截止日期。项目经理喜欢无偿加班,因为这意味着无需花费更多金钱即可约会,但对于开发人员而言,这只是一大笔钱。

但是,我也相信,如果开发人员在创建可靠,直观的系统方面做得更好,您的支持就会减少。因此,这为混合两者创建了一个怪异的循环参数。我认为如果必须同时执行这两项操作,则应该找到避免同时进行的方法。

74
Bernard Dy

我认为开发人员已经戴了两顶帽子。支持更像是一个过滤器,用于保护开发免受诸如未插入计算机之类的琐碎问题的影响。但是,开发与支持之间应该紧密耦合。一些客户有合法的问题,可能是错误的结果。开发的责任应该是帮助尽快解决这些问题。因此,从某种意义上说,开发人员已经属于支持团队的一部分……称之为第2层支持。

18
Pemdas

很重要,没有
我们都知道必须停止您正在做的事情有多困难  回答问题。我会为服务台接电话,并编写一些实用程序。

我不能专注于解决问题,因为每隔5分钟我必须拿起电话。两项工作都做得不好,因为我一直在思考如何解决问题,而且我从事编程工作的时间也不足以完全实现我可能拥有的任何解决方案。

再说一次,我不能过分强调能够专注于一个方面或另一个方面有多么重要。

18
IAbstract

我永远不会把开发人员作为第一线支持。中断的次数和您将不得不重复的次数将使大多数开发人员大喊 [〜#〜] rtfm [〜#〜] 并挂断下一个打电话的人。这不是客户需要的东西,也不是您希望开发人员必须忍受的东西。

任何客户服务职位都有一定的规定。对于愤怒的呼叫者,接听电话的第一个人是错误的。无论他们是公司总裁,开发应用程序的人还是支持经理,都没有关系。一旦客户得到第二个人,该人可能知道也可能不知道他们在做什么,则客户将能够冷静下来并更清楚地解释问题。

这不是您想要保留优秀开发人员的环境。让开发人员与客户互动解决一个特别棘手的问题,是否有价值,而不仅仅是“为什么我的杯架不再工作了”?绝对。但这是在通过第一层和第二层支持热线审查了支持请求之后。

10
Berin Loritsch

这取决于公司。

我的工作是完全像这样。我是软件开发人员,但是由于我们是一家相对较小的公司,因此每个开发人员通常都基于自己的软件担当“非正式”支持角色。有些开发人员必须比其他开发人员提供更多的支持,具体取决于许多因素,例如他们开发/销售了多少产品,产品的故障程度以及他们的效果如何)得到支持如果您可以向客户提供他们解决问题的确切信息,他们将继续与您联系,以尽快解决问题。双刃剑?是。您遭受生产力下降的困扰,但客户满意,并且更有可能继续成为客户。这对于较小的公司很重要。

我们确实有一个系统支持团队,但是由于我们的工作性质,他们大部分不得不处理与硬件相关的问题。就个人而言,在一家较小的公司中,此问题没有人们想象的那么严重。当然,您在尝试制定一些重要功能时会接到电话,但与此同时,客户服务有了很大的改进;他们可以拥有权威的声音,而不是那些拥有二手信息和支持脚本的人,他们可以(在许多情况下)知道如何解决他们的问题。如果您不能在那里解决问题,则可以亲自向他们保证,将为他们的错误实施修复,或者考虑他们的功能要求以供将来发布。您可以直接从软件用户那里得到真实的反馈,因此您的下一个版本可能比您已经想象的要好。

我喜欢认为满意的客户会为您的公司树立更正面的形象,这通常会带来更多的客户。因此,作为软件工程师,我喜欢技术支持。

9
badgerr

开发人员应该是最后的支持。

只有当服务台和我们的质量保证部门无法为客户提供帮助时,我们才会感到困扰。即使这样,它也必须通过我们优先的错误跟踪系统。

如果这是一个非常大的问题,我们会听到的。

3
Carra

没有什么比不愿意让您与真正了解正在发生的事情的人联系的计算机技术支持更令人沮丧的了。我希望任何大型应用程序公司都会有一些可以提供技术支持的程序员。

3
user1842

开发软件需要一些人才和技能,而在一线支持方面需要有效的人才和技能。我不知道这些人才有什么关联。

这意味着您要么必须部分地基于开发人员提供电话支持的能力来雇用开发人员,要么让您的客户直接与不擅长处理客户并且不想在一开始就这样做的人进行交谈。这可能比让他们和一个有印度口音的家伙说话要好得多,而这个家伙会讲礼貌的话。

另外,当您使工作变得不愉快时(我不知道任何实际享受一线支持的开发人员),您的一些开发人员将离开。通常,这些人可以更轻松地获得其他工作:即好工作。随着这一过程的进行,您最终会发现一家人才稀少的商店,这使主管人员无法获得别人提供的第一份工作机会。

至于完成认真的开发,如果经常出现中断,请不要理会。我的妻子抱怨期望同时进行开发和支持用户。

2
David Thornley

我最后的工作就是这个。我们支持现有系统,并根据需要编写新系统。那是一场彻底的灾难。我会经常被打扰。我的士气实在太低了,因为项目开始要花很长时间才能完成。另外,我们不得不随身携带传呼机来获得非工作时间的支持,而无需支付额外的费用(这是在医疗保健领域)。我认为解决方案(当时我曾向我的经理建议)将获得第一线的技术支持,如果是软件错误,则将其转发给开发人员。不用说,我只呆了一年半,直到我最终离开去从事更好的所有开发工作!

2
Bmw

有时候,肯定是的。面对客户通常会给出大多数人(尤其是程序员)缺乏的观点。用户实际使用产品或实际想法的方式通常与建造者(工程师)的想法相去甚远。

应该是短暂的短期工作,以免打断实际的开发任务。

2
talonx

仅当它是新开发人员或对域和客户群不熟悉的开发人员时,我才这样做。使它成为永久性的东西不是一个好主意。

2
JeffO

虽然我认为使用开发人员作为支持是不适当的all时间,但我认为让开发人员对应用程序提供初始支持尚需说明。具体应包括下班后的支持。我还认为,定期安排他们的应用程序在非工作时间支持中会很有帮助。

没有什么比让多个3AM调用使您意识到某些设计决策和/或捷径对人们支持和维护您的代码的能力有什么影响了。

1
dietbuddha

我认为这很大程度上取决于公司。您典型的BigCo公司通常可以负担得起支持人员隔离开发人员的费用。另一方面,只有三个人的创业公司总数可能根本没有资源来提供独立的支持人员。

我认为最好的总体策略(不考虑公司规模或资源规模)是使用支持团队来解决业绩低下和最常见的问题(“您是否尝试过关闭并打开?”)。工程师应与客户一起解决棘手的问题,这些问题需要了解系统的工作方式以及更多面向开发人员的支持(API,开发人员工具等)。您可以让支持人员扮演“联络员”的角色,但是我发现这通常比其价值更大。

1
Jason Baker

理想情况下,出于上述原因,最好是“否”,但在项目尚处于初始阶段时,是的,因为开发人员可以提供通常是企业期望的快速解决方案,从而为软件的持续改进提供了支持。我重视那些精明地提供支持的开发人员:那些通过示例向更正式的全职支持团队提供分析技能的开发人员,以及那些以表现服务与合作精神的方式来回答业务问题的开发人员。但是,取得成功的关键包括管理层认识到并正式确定了第一级和第二级支持,以使开发人员从他们的短期角色中迅速卸任。对开发和支持都非常了解的开发人员应被培养为第三级支持或对支持人员的支持。所以应该是时间相关的,才华和欲望相关的,并且得到有效管理。

我自己的兴趣是回答艰难的支持问题,并从经验中学到的东西可以减少对总体支持的需求,这对最终用户和主要支持都有利。

0
Kit

我加入高薪公司时就陷入了陷阱。在采访中,我被告知将有70%的开发和30%的支持,我接受了这个提议。可能是我目前正在工作的公司或环境。但实际上它有90%的支持和10%的开发。现在已经两年了,我失去了发展的动力。很遗憾我接受了这个提议。

但是我觉得我失去了更多的新技术和新框架的编码能力。现在,我不知道从哪里开始。我一直在准备,但是这些helloworld示例不足以拥有一些良好的实践经验,并且很难更新我的知识和经验。由于家庭原因,我什至不能离开我的工作。

不幸的是我陷入了僵局。

如果您不喜欢或不感兴趣,请不要接受角色。

0
Stranger