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

¿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.

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.

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.

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.

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.

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.

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.

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.

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.

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!

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.

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.

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.

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.

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.

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.

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.

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.