¿Deben los ingenieros de software también actuar como soporte técnico? [cerrado]

48

¿Debería un ingeniero de software actuar también como soporte técnico? Es decir, si una empresa permite que sus ingenieros usen tanto el ingeniero de software como los sombreros de soporte técnico. Parece que eliminaría la capacidad de escribir software si el soporte técnico dedica gran parte del tiempo de un ingeniero.

staticx
fuente
2
Por soporte técnico, ¿te refieres a apoyar las aplicaciones específicas que están desarrollando o el tipo general de "administrador del sistema"? Puedo decirte que es molesto trabajar en una pequeña empresa y que la gente te moleste para instalar Excel.
Carlos
12
¿Deberíamos? No. nosotros? Si. Lo odio.
Rachel
77
Un ingeniero siempre debe esforzarse por cometer errores aparentemente inocentes que causen más trabajo para la persona que pensó que sería una gran idea usarlos para soporte técnico.
Erik Reppen

Respuestas:

74

Este es un problema clásico en las empresas que tienen un componente de desarrollo de software en su trabajo, sean o no empresas de software. Lucho con esto todo el tiempo.

Tener desarrolladores involucrados en el soporte de producción

Pros

  • Lucha contra el síndrome de "Desarrollo en el vacío" . Es valioso conocer cómo los usuarios usan la aplicación. Hasta que finalmente vi esto como un desarrollador joven, no me di cuenta de lo malo que era un desarrollador de UI. Lo único que me importaba era la codificación y no el diseño, el análisis o la perspectiva del usuario.
  • Los desarrolladores que no son tan buenos como creen que pueden ser humillados (aunque no hay garantía de que obtendrás este beneficio; algunos desarrolladores son realmente ajenos, egoístas y tercos).
  • Los desarrolladores obtendrán conocimiento de dominio . Esto es crítico si sus desarrolladores eventualmente serán mejores para identificar y llenar los vacíos que la fase de análisis de negocios (suponiendo que haya) se pierda.
  • Un buen soporte es un punto de comercialización. Si lo haces bien, los clientes lo apreciarán. Y un desarrollador completo con habilidades de comunicación y conocimiento de dominio es capaz de hacerlo bien. Sin embargo, aún preferiría que las aplicaciones sean de una calidad lo suficientemente alta como para que no necesiten soporte. La calidad superior es su propia forma de atención al cliente (y también un punto de comercialización).

Contras

  • Factor de interrupción . Esta es la falla número uno de mezclar el trabajo del proyecto y el trabajo de soporte, sin excepción. Los proyectos interfieren con el soporte, y el soporte interfiere con los proyectos. Los proyectos dependen de estimaciones y avances importantes, el apoyo es impredecible y puede implicar una urgencia improvisada. Los proyectos se basan en el cronograma, el soporte se basa en la interrupción. No es una combinación feliz y muy frustrante para los desarrolladores.
  • No todos son buenos en el apoyo . Alguien que tenga menos experiencia con la aplicación o el negocio, o alguien cuya personalidad o habilidades de comunicación sean tales que estén mejor protegidos del acceso del usuario, podría no funcionar bien en el soporte.
  • Uso ineficiente de los recursos . Frank Shearar señaló en los comentarios que un desarrollador que ofrece soporte trivial puede ser más costoso que un técnico de soporte de nivel uno.

En mi experiencia, a la mayoría de los desarrolladores no les gusta el soporte. Habiendo servido tanto en el proyecto como en el lado de apoyo, puedo simpatizar. Al tener que hacer ambas cosas al mismo tiempo, el factor atenuante suele ser el tiempo extra, generalmente no remunerado, para lidiar con emergencias de apoyo y aún así cumplir con los plazos del proyecto. A los gerentes de proyecto les encantan las horas extras no pagadas porque significa hacer citas sin costar más dinero, pero para los desarrolladores, es solo un gran plato de chupar.

Sin embargo, también creo que si los desarrolladores hicieran un mejor trabajo creando sistemas confiables e intuitivos, tendrían menos soporte. Entonces esto crea un argumento circular extraño para mezclar los dos. Lo que creo que debes hacer si tienes que hacer ambas cosas es encontrar formas de evitar que sea simultáneo.

Bernard Dy
fuente
1
Creo que respaldar un proyecto en desarrollo no está mal. Hablar con el cliente es bueno. Pero si trabajas en 7 proyectos con 7 plazos diferentes y urgencia ... Después de un tiempo, realmente no es realmente bueno. es un poco malo.
Loïc Faure-Lacroix
44
También he visto tiendas donde los desarrolladores que pierden sus plazos simplemente se encogen de hombros y dicen "Tuve mucho tiempo de soporte esta semana. Sin errores, los usuarios solo necesitaban ayuda". Por lo general, no había forma de saber si eso estaba sucediendo o si el desarrollador estaba lento esa semana. Siempre y cuando controle eso, estoy a favor de que los desarrolladores admitan su código, pero no como soporte de respuesta telefónica de primera línea.
Kate Gregory el
10
Debe haber una capa de soporte de primera línea para capturar las preguntas RTFM, dejando solo las preguntas con contenido técnico útil / comentarios para que los desarrolladores respondan.
Robert Harvey
44
@Christopher: Los sistemas de autodescripción son un buen ideal para luchar, pero difíciles de lograr en la práctica. Hay muchos factores de personas y presiones de las partes interesadas que conspiran en contra de hacerlo bien, y siempre habrá usuarios que "no lo entiendan".
Robert Harvey
1
Una excelente respuesta. Mi compañía encuentra un buen término medio: cada desarrollador pasa un día en soporte técnico de tercera línea, rotando a través del equipo. Si estás en tecnología puedes ser interrumpido dentro de lo razonable, pero todos los demás son inmunes a menos que surja algo importante. Durante nuestros días en tecnología, tendemos a hacer correcciones de errores más ligeras, cosas de administración, etc. para evitar estar en algo complejo cuando se interrumpe ... Así que básicamente todos tenemos un día para hacer lo que los desarrolladores odian hacer pero tienen que hacer, pero sepan que Recibimos llamadas de soporte ocasionales para romperlo. Más importante aún, ¡es genial saber que eres inmune el resto del tiempo!
Jon Story
18

Creo que los desarrolladores ya usan dos sombreros. El soporte es más como un filtro utilizado para proteger el desarrollo de problemas triviales como no tener la computadora conectada. Sin embargo, debe haber un fuerte acoplamiento entre el desarrollo y el soporte. Algunos clientes tienen problemas legítimos que pueden ser el resultado de un error. Debería ser responsabilidad del desarrollo ayudar a resolver estos problemas lo antes posible. Entonces, en cierto sentido, los desarrolladores ya forman parte del equipo de soporte ... llámelo soporte de nivel 2.

revs Pemdas
fuente
18

Enfáticamente, no.
Todos sabemos lo difícil que puede ser tener que parar lo que está haciendo para pedir a responder a una pregunta. Contesto teléfonos para una mesa de ayuda y escribo algunas aplicaciones de utilidad.

No puedo concentrarme en resolver un problema porque cada 5 minutos tengo que levantar el teléfono. Ninguno de los trabajos se realiza tan bien como puede ser porque estoy constantemente pensando en lo que puedo hacer para resolver un problema, y ​​nunca estoy trabajando en la programación el tiempo suficiente para implementar completamente cualquier solución que pueda tener.

Nuevamente, no podría enfatizar lo suficiente lo importante que es poder enfocarse en un aspecto u otro.

IAbstract
fuente
+1 Me identifico con todo lo que dijiste. Estaba en una posición similar hace unas semanas. Ahora no tenemos teléfono pero tocan la puerta de todos modos, incluso para cosas como: "Hola chicos, ¿han visto a X por ahí?" caramba!
jasonco
1
Puede reservar "horas de oficina" para evitar las interrupciones. La asistencia telefónica no es una buena idea.
JeffO
2
De acuerdo, también, los programadores semi-disfuncionales no son muy buenos para apoyar a las personas :)
Homde
66
Esta es una mala respuesta en mi opinión. Un desarrollador que NUNCA apoya nunca puede aprender cómo sus decisiones afectan al usuario, bueno o malo. Solo ver a alguien intentar usar el software puede ser una gran llamada de atención, incluso si cree que coincide con las especificaciones. Hay formas de mitigar las partes negativas de la misma, rotando horarios entre desarrolladores, mesa de ayuda para manejar las llamadas de eliminación para que solo esté apoyando su aplicación, etc. Si tiene un desarrollador que "no funciona", tenga que preguntarse qué tan útiles realmente lo son si ni siquiera pueden hablar con el usuario. Supervise si es necesario, para que puedan aprender.
Jay
1
@BryanOakley: tenga un plan que obtenga soporte técnico. Si bien sigo apoyando mi respuesta, no es realista esperar que una nueva empresa tenga todo el personal necesario para una adecuada atención al cliente y desarrollo. Todavía recomendaría que la tarea principal de un desarrollador sea el desarrollo, no el soporte al cliente. El problema es que cuando un desarrollador tiene vínculos estrechos con un cliente, el desarrollador: (a) siempre será contactado directamente por el cliente en lugar de los canales tecnológicos adecuados, o (b) terminará desarrollándose específicamente para las necesidades de ese cliente en lugar de Amplio alcance del desarrollo necesario.
IAbstract
10

Nunca pondría a un desarrollador como soporte de primera línea. El número de interrupciones y la cantidad que tendrá que repetir usted impulsará a la mayoría de los desarrolladores a gritar RTFM y colgar a la siguiente persona que llame. Esto no es algo que sus clientes necesiten, ni es algo que quieran que sus desarrolladores tengan que soportar.

Hay una cierta regla en cualquier puesto de servicio al cliente. Para una persona iracunda, la primera persona que contesta el teléfono está equivocada. Ya sea que tengan el presidente de la compañía, la persona que desarrolló la aplicación o el gerente de soporte, no importa. Una vez que el cliente obtiene a la segunda persona, que puede o no saber lo que está haciendo, el cliente podrá calmarse y explicar el problema con mayor claridad.

Este no es un entorno que desea retener buenos desarrolladores. ¿Tiene algún valor que un desarrollador interactúe con un cliente en un problema particularmente difícil que va más allá de "por qué mi portavasos ya no funciona"? Absolutamente. Pero eso es después de que la solicitud de soporte haya sido examinada a través de las líneas de soporte de primer y segundo nivel.

Berin Loritsch
fuente
Zappos ha construido un imperio que va en contra de la regla de la primera persona.
JeffO
No sé acerca de Zappos, pero parece lo suficientemente cierto para la mayoría de las empresas. Todo lo que sé es que si estoy lo suficientemente frustrado como para llamar al soporte técnico, me siento mal por la persona que está al otro lado de la línea.
Berin Loritsch
¿Nunca? Como en nunca, nunca? ¿Incluso si fuera una pequeña empresa compuesta por vendedores y uno o dos desarrolladores? ¿Ni siquiera si sus desarrolladores fueran comunicadores muy fuertes y les gustara hablar con los clientes?
Bryan Oakley
Desea que sus desarrolladores sean percibidos como expertos: conviértalos en la segunda persona con la que el cliente habla. Para entonces, el cliente se calmará un poco y se comportará de manera más razonable. Ahora, si es un cliente con el que tiene una buena relación y no es la primera presentación que el desarrollador tiene al cliente, entonces estaría perfectamente bien. Sin embargo, el primer contacto debe ser examinado primero por otra persona.
Berin Loritsch
Como alguien que ha sido un soporte de primera línea, creo que la regla para la "persona que llama furiosa pensando que la primera persona que contesta el teléfono está equivocada" no es correcta. Sin embargo, solo puedo hablar desde mi propia experiencia . La persona que llama furiosa de vez en cuando que cree que esto se da cuenta de su error ( siempre y cuando la primera línea esté bien informada ) o simplemente no está buscando una solución, sino alguien a quien culpar, lo que significa que nadie puede ayudarlos. Todavía estoy de acuerdo en general: los desarrolladores deben ser el último contacto, una vez que se determina que hay un error en alguna parte (o una alta posibilidad de uno)
DoubleDouble
9

Depende de la empresa.

Mi trabajo es exactamente así . Soy un desarrollador de software, pero como somos una empresa bastante pequeña, cada desarrollador asume un rol de soporte "no oficial" generalmente basado en su propio software. Algunos desarrolladores tienen que brindar más soporte que otros, dependiendo de una serie de factores, como cuántos productos han desarrollado / enviado, cuán defectuosos son sus productos y cuán efectivos son en el soporte . Si puede proporcionarle al cliente exactamente lo que necesita para resolver el problema, lo contactarán para resolver los problemas lo antes posible. ¿Espada de doble filo? Si. Sufre de una productividad reducida, pero el cliente está contento y es más probable que siga siendo cliente. Esto es importante para las empresas más pequeñas.

Tenemos un equipo de soporte de sistemas, pero debido a la naturaleza de lo que hacemos, en su mayoría tienen que lidiar con problemas relacionados con el hardware. Personalmente, en una empresa más pequeña, este problema no es tan perjudicial como uno podría imaginar. Claro, recibe llamadas mientras intenta resolver alguna característica importante, pero al mismo tiempo, el servicio al clienteha mejorado mucho pueden tener una voz autorizada que sepa (en muchos casos) cómo resolver su problema en lugar de alguien con información de segunda mano y un script de soporte. Si no puede resolver el problema en ese momento, puede asegurarles personalmente que implementará una solución para su error, o considerar su solicitud de características para una versión futura. Puede obtener comentarios reales directamente de los usuarios de su software, por lo que su próxima versión puede ser incluso mejor de lo que ya cree.

Me gusta pensar que los clientes satisfechos crean una imagen más positiva de su empresa, lo que generalmente genera más clientes . Y es por eso que, como ingeniero de software, me gusta el soporte técnico.

tejón
fuente
Estoy en el mismo bote que tú y estoy totalmente de acuerdo contigo. Sin embargo, debería ser posible y con mayor frecuencia que una recepcionista atienda la llamada y escriba una nota para que le devuelva la llamada a ese cliente. De esa manera, puede continuar sin ser interrumpido en su trabajo y volver a llamar cuando le convenga. Sin embargo, vuelva a llamar el mismo día, preferiblemente dentro de las 2 horas posteriores a la
recepción de
3

No hay nada más frustrante que el soporte técnico informático que no está dispuesto a conectarte con alguien que realmente entiende lo que está sucediendo. Espero que cualquier gran empresa de aplicaciones tenga algunos programadores que trabajen con soporte técnico.

usuario1842
fuente
44
Hay una cierta ley con el soporte técnico: el primer tipo que obtienes siempre está equivocado. Puede ser la persona más astuta técnica en el equipo, y debido a que levantó el teléfono primero, el cliente no podrá confiar en ellos. Básicamente, el primer hombre existe para dejar que el cliente se desahogue y eche humo para que el siguiente pueda ser el "salvador". Este es el caso en cualquier profesión de servicio al cliente, no solo en el soporte técnico.
Berin Loritsch
@BerinLoritsch Esa es una ley que se aprende de la experiencia, no un prejuicio injustificado como parece implicar. No sé qué se necesitaría para convencer al centro de soporte de que, sí, he probado las soluciones habituales. Obviamente no puede basarse en lo que pido, pero he notado que en 20 palabras o menos puedo saber si la persona ha solucionado los problemas básicos.
Milind R
3

Los desarrolladores deberían ser la última línea de soporte.

Solo cuando el servicio de asistencia y nuestro departamento de control de calidad no puedan ayudar a un cliente seremos molestados. E incluso entonces tiene que pasar por nuestro sistema prioritario de seguimiento de errores.

Si es un problema realmente grande, lo escucharemos.

Carra
fuente
2

Solo haría esto si es un desarrollador nuevo o uno que no está familiarizado con el dominio y la base de clientes. Convertirlo en algo permanente no es una buena idea.

JeffO
fuente
2

Mi último trabajo fue exactamente esto. Apoyamos los sistemas existentes y también escribimos nuevos según sea necesario. Fue un desastre absoluto. Me interrumpirían constantemente. Mi moral era muy baja porque los proyectos iniciados tardarían una eternidad en terminar. Además, teníamos que llevar un buscapersonas para recibir asistencia fuera del horario laboral sin pago adicional (esto era en el campo de la atención médica). Creo que la solución (que le sugerí a mi gerente en ese momento) habría sido tener una primera línea de soporte técnico, y si se trata de un error de software, envíelo a los desarrolladores. ¡No hace falta decir que solo duré un año y medio hasta que finalmente me fui para un mejor trabajo de desarrollo!

BMW
fuente
2

Algunas veces, definitivamente sí. Enfrentar al cliente a menudo da una perspectiva que la mayoría de las personas, especialmente los programadores, carecen. La forma en que el usuario realmente usa el producto, o realmente piensa, a menudo está muy lejos de cómo el constructor (el ingeniero) piensa que él / ella lo hace.

Debe ser por períodos cortos y periódicos, para no interrumpir la tarea real de desarrollo.

talonx
fuente
2

Hay talentos y habilidades que necesita para desarrollar software, y talentos y habilidades que necesita para ser efectivo en el soporte de primera línea. No sé si estos talentos tienen alguna correlación.

Esto significa que, o bien debe contratar desarrolladores basados ​​en parte en su capacidad de brindar asistencia telefónica, o dejar que sus clientes hablen directamente con personas que no son buenas para atender a los clientes y que no quieren hacerlo en primer lugar. Esto puede o no ser mejor que hacer que hablen con un chico con un fuerte acento indio que lee un guión educado.

Además, cuando hace que el trabajo sea desagradable (y no conozco a ningún desarrollador que realmente disfrute del soporte de primera línea), algunos de sus desarrolladores se irán. En general, estos son los que pueden obtener otros trabajos más fácilmente: es decir, los buenos. A medida que avanza este proceso, terminas con una tienda llena de gente menos talentosa, lo que hace que sea aún menos agradable para los competentes pasar la primera oferta de trabajo de otra persona.

En cuanto a lograr un desarrollo serio, olvídalo si hay interrupciones frecuentes. Mi esposa se ha quejado mucho de que se espera que desarrolle y apoye a los usuarios simultáneamente.

David Thornley
fuente
1

Creo que mucho depende de la compañía. Por lo general, su firma BigCo típica puede permitirse contar con personal de apoyo para aislar a los desarrolladores. Por otro lado, una startup con un total de tres personas simplemente puede no tener los recursos para proporcionar personas de soporte separadas.

Creo que la mejor estrategia general (sin tener en cuenta el tamaño de la empresa o los recursos) es utilizar equipos de soporte para solucionar los problemas más bajos y los problemas más comunes ("¿Has intentado apagarlo y encenderlo?"). Los ingenieros deben trabajar con los clientes en los problemas más difíciles que requieren conocer cómo funciona el sistema junto con un soporte más orientado al desarrollador (API, herramientas de desarrollador, etc.). Podría hacer que la persona de apoyo actúe como un "enlace", pero creo que eso suele ser más problemático de lo que vale.

Jason Baker
fuente
1

Si bien no creo que sea apropiado usar desarrolladores como soporte todo el tiempo, creo que hay algo que decir para que un desarrollador haga el soporte inicial de una aplicación. Esto debería incluir específicamente el soporte fuera de horario. También creo que puede ser útil que se programen en el soporte fuera de horario para sus aplicaciones de forma regular.

No hay nada como las múltiples llamadas de 3AM para que se dé cuenta del efecto que ciertas decisiones de diseño y / o accesos directos tienen en la capacidad de las personas de respaldar y mantener su código.

dietbuddha
fuente
2
Corrección: No hay nada como múltiples llamadas de 3AM para que se dé cuenta del efecto que ciertas decisiones de diseño y / o accesos directos que su gerente le impuso tienen sobre la capacidad de las personas de respaldar y mantener su código. El mal diseño y el código a menudo son el resultado de una mala gestión que los malos programadores.
David Thornley
0

Idealmente, no por los motivos mencionados anteriormente, pero sí, mientras el proyecto es incipiente, porque los desarrolladores pueden proporcionar resoluciones rápidas, a menudo esperadas por las empresas, que respaldan la mejora continua del software. Valoro a los desarrolladores que brindan soporte de manera inteligente: aquellos que prestan sus habilidades analíticas por ejemplo a un equipo de soporte de tiempo completo más formal, y aquellos que responden al negocio de tal manera que muestran un espíritu de servicio y cooperación. Sin embargo, las claves de este éxito incluyen la administración que reconoce y formaliza el soporte de primer y segundo nivel para descargar rápidamente a los desarrolladores de lo que solo debería ser su función a corto plazo. Los desarrolladores que muestran una habilidad tanto para el desarrollo como para el soporte deben cultivarse como soporte de tercer nivel o soporte para la gente de soporte. Entonces debería depende del tiempo, depende del talento y del deseo, y se gestiona de manera efectiva.

Mi propio interés ha sido responder las difíciles preguntas de soporte y aprovechar lo que he aprendido de la experiencia para reducir la necesidad de soporte en general, lo que beneficia tanto a los usuarios finales como al soporte primario.

Equipo
fuente
0

Me metí en esta trampa cuando me uní a una empresa con buena paga. Durante la entrevista me dijeron que habrá un 70% de desarrollo y un 30% de soporte y acepté la oferta. Puede ser la empresa o el entorno en el que estoy trabajando actualmente. Pero en realidad es 90% de soporte y 10% de desarrollo. Han pasado un par de años que perdí el control del desarrollo. Lamento haber aceptado esta oferta.

Pero siento que he perdido el control de la codificación de muchas nuevas tecnologías y marcos. Ahora no sé por dónde empezar de nuevo. Sigo preparándome, pero estos ejemplos de helloworld no son suficientes para tener una buena experiencia práctica y realmente me resulta difícil actualizar mis conocimientos y experiencia. Ni siquiera puedo dejar mi trabajo para comenzar de nuevo debido a los compromisos familiares.

Lamentablemente estoy en un punto muerto.

No acepte roles si no le gustan o no le interesan.

Desconocido
fuente
-1

Contras: suponiendo que tiene que tratar directamente con los clientes.

1) Malcriar a tus clientes

Si es el soporte de primera / segunda / tercera línea (realmente quiero decir soporte de línea borrosa) donde los desarrolladores tratan directamente con los clientes, entonces es una gran desventaja. Los desarrolladores tienen el conjunto de habilidades necesarias para depurar problemas o desarrollar soluciones para resolver problemas. Si los clientes tienen acceso completo a los desarrolladores (línea borrosa), no hay forma de evitar que los clientes "abusen" de este privilegio, lo que resulta en clientes mimados, exigentes y privilegiados que no pagan más que cualquier otro cliente.

2) Acondicionando a tus desarrolladores para que mientan y inventen historias.

Cualquiera que haya tratado con clientes sabe que es un requisito previo poder mentirles. Hay un error con una corrección de 1 línea que se puede hacer en 5 minutos. Una persona de atención al cliente habría sido capacitada para gestionar las expectativas del cliente, que tardaría hasta 3 días en resolverse.

Como desarrollador, si tiene que tratar directamente con los clientes, debe pensar en formas creativas para apaciguar o engañar a los clientes cuando su trabajo principal debe ser resolver problemas técnicos y asegurarse de que el sistema funcione sin problemas.

3) Su currículum vitae sufre.

A menos que cambie de ingeniero de software a analista de negocios / consultor de TI / gestión de proyectos, su CV sufrirá un aspecto técnico.

El trabajo de apoyo remunerado que rota entre el equipo es una historia diferente.

Pros

1) Deje de quejarse de quejarse

Los desarrolladores que hacen lo que odian les harán apreciar mucho más la codificación. ¿Tiene un programador que está constantemente quejándose? Póngalos en la línea directa por un mes.

Leesa
fuente
3
Póngalos en la línea directa por un mes. Luego busque un desarrollador de reemplazo, porque ese tipo no va a estar por mucho tiempo. Además, busque a alguien bueno en las relaciones con los clientes para calmar a quienes hablaron con una persona que estaba de mal humor antes de que se le asignara hacer algo que odia y que no muestra respeto por parte de la compañía.
David Thornley
De acuerdo con David, si tiene que dirigir su equipo como un salón de clases, es posible que desee reconsiderar sus prácticas de contratación y / o su entorno de trabajo.
Matthieu
-1

Sí, porque lo hacen. ¿Lol'd cuando leí esta pregunta? Pensé cómo es esto incluso una pregunta (no es que cuestione tu derecho a hacer la pregunta OP), pero es bastante retórico porque casi todos los desarrolladores que he conocido han tenido algún tipo de trabajo de soporte técnico implícito en su Su función de trabajo. Simplemente no puedes evitarlo. En la mayoría de los casos, usted es la persona más competente técnicamente, no solo en su dominio funcional, sino en términos de TI en general. Es muy difícil de evitar por completo.

Tipo anónimo
fuente