¿Deberían los ingenieros de software actuar como soporte técnico? [cerrado]

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

Los desarrolladores participan en el soporte de producción

Pros

• Combate el síndrome de "Desarrollo en un vacío" . Es valioso estar al tanto de cómo los usuarios usan la aplicación. Hasta que finalmente vi esto como un joven desarrollador, no me di cuenta de lo mal que era un desarrollador de UI. Todo lo 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 son pueden ser humildes (aunque no hay garantía de que obtengas este beneficio; algunos desarrolladores son realmente ajenos, egoístas y tercos).
• Los desarrolladores obtendrán conocimiento del dominio . Esto es crítico si sus desarrolladores finalmente van a mejorar en la identificación y el llenado de los vacíos que faltan en la fase de análisis de negocios (suponiendo que haya alguna).
• 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 del dominio es capaz de hacerlo bien. Sin embargo, todavía 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).

Cons

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

En mi experiencia, a la mayoría de los desarrolladores no les gusta el soporte. Habiendo servido tanto en el lado del proyecto como en el de apoyo, puedo simpatizar. Al tener que hacer ambas cosas al mismo tiempo, el factor mitigador suele ser las horas extraordinarias, generalmente no remuneradas, para hacer frente a emergencias de asistencia y aún cumplir los plazos de los proyectos. A los gerentes de proyecto les encantan las horas extraordinarias no pagadas porque significa hacer citas sin costar más dinero, pero para los desarrolladores, es solo un gran tazón de mierda.

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

Creo que los desarrolladores ya usan dos sombreros. El soporte es más como un filtro usado para proteger el desarrollo de problemas triviales, como no tener la computadora conectada. Sin embargo, debe haber un acoplamiento estrecho 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. Así que, en cierto sentido, los desarrolladores ya son parte del equipo de soporte ... llámelo soporte de nivel 2.

Enfáticamente, no.
Todos sabemos lo difícil que puede ser tener que dejar de hacer lo que está haciendo para preguntar responder una pregunta. Respondo teléfonos para un servicio 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. Ningún trabajo se realiza tan bien como puede ser, porque estoy pensando constantemente en lo que puedo hacer para resolver un problema, y nunca estoy trabajando en la programación el tiempo suficiente para implementar por completo cualquier solución que pueda tener.

Una vez más, no puedo enfatizar lo suficiente lo importante que es poder concentrarse en un aspecto u otro.

Nunca pondría a un desarrollador como soporte de primera línea. La cantidad de interrupciones y la cantidad que tendrá que repetirse hará que la mayoría de los desarrolladores griten RTFM y cuelguen el siguiente persona que llama Esto no es algo que sus clientes necesiten, ni es algo que usted quiera que sus desarrolladores tengan que soportar.

Hay una cierta regla en cualquier posición de servicio al cliente. Para una persona que llama furiosa, la primera persona que contesta el teléfono está equivocada. No importa si tienen al presidente de la compañía, a la persona que desarrolló la aplicación o al gerente de soporte. Una vez que el cliente reciba la segunda persona, quien puede o no saber lo que está haciendo, podrá calmarse y explicar el problema con mayor claridad.

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

Depende de la empresa.

Mi trabajo es exactamente como este . Soy un desarrollador de software, pero como somos una empresa bastante pequeña, cada desarrollador asume un rol de soporte "no oficial" basado generalmente en su propio software. Algunos desarrolladores tienen que ofrecer más asistencia que otros, dependiendo de una serie de factores, como cuántos productos han desarrollado / enviado, qué tan defectuosos son sus productos y qué tan efectivos son en el soporte . Si puede proporcionarle al cliente exactamente lo que necesita para resolver el problema, seguirán acudiendo a usted para resolver los problemas lo más rápido posible. ¿Espada de doble filo? Sí. Sufre de una productividad reducida, pero el cliente está contento y es más probable que siga siendo un 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, principalmente tienen que lidiar con problemas relacionados con el hardware. Personalmente, en una empresa más pequeña, este problema no es tan disruptivo como uno podría imaginar. Claro, recibes llamadas mientras intentas resolver alguna característica importante, pero al mismo tiempo, el servicio al cliente ha mejorado mucho; pueden tener una voz autorizada que sabe (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 allí y luego, puede asegurarles personalmente que implementará una solución para su error, o considerar su solicitud de características para una futura versión. 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 cree.

Me gusta pensar que los clientes felices crean una imagen más positiva de su empresa, lo que generalmente lleva a 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 por computadora que no está dispuesto a conectar con alguien que realmente entienda lo que está pasando. Espero que cualquier empresa de aplicaciones grande tenga algunos programadores que trabajen con soporte técnico.

Los desarrolladores deben 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 de seguimiento de errores priorizado.

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. Hacer que sea una cosa permanente no es una buena idea.

Mi último trabajo fue exactamente este. Apoyamos los sistemas existentes y también escribimos nuevos según fue necesario. Fue un desastre absoluto. Yo estaría constantemente interrumpido. Mi moral era tan baja porque los proyectos iniciados tardarían una eternidad en terminarse. Además, tuvimos que llevar a cabo un buscapersonas para horas de asistencia sin pago extra (esto fue en el campo de la atención médica). Creo que la solución (que sugerí a mi gerente en ese momento), habría sido tener una línea de soporte técnico de primera línea, y si se trata de un error de software, reenví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í. Hacer frente 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 en realidad piensa que a menudo está muy lejos de lo que el constructor (el ingeniero) cree que hace.

Debería 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 tiene que contratar desarrolladores basados en parte en su capacidad para brindar asistencia telefónica, o permite que sus clientes hablen directamente con personas que no son buenas para tratar a los clientes y no quieren hacerlo en la primer lugar. Esto puede o no ser mejor que hacer que hablen con un chico con un acento indio grueso que lee un guión cortés.

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. Estos son generalmente los que pueden obtener otros trabajos más fácilmente: es decir, los buenos. A medida que avanza este proceso, terminas en una tienda llena de gente con menos talento, lo que hace que sea menos agradable para los competentes pasar por alto la primera oferta de trabajo de otra persona.

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

Creo que mucho de eso depende de la compañía. Su firma típica de BigCo generalmente puede permitirse tener personas de apoyo para aislar a los desarrolladores. Por otro lado, una startup con tres personas en total simplemente puede no tener los recursos para proporcionar personas de apoyo separadas.

Creo que la mejor estrategia general (sin tener en cuenta el tamaño de la empresa o los recursos) es utilizar equipos de apoyo para solucionar los problemas de la fruta y los problemas más comunes ("¿Ha intentado encenderlo y apagarlo?"). Los ingenieros deben trabajar con los clientes en los problemas más complicados que requieren el conocimiento de 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.

Aunque no creo que sea apropiado usar desarrolladores como soporte todo la hora, creo que hay algo que decir para que un desarrollador realice el soporte inicial de una aplicación. Esto debe incluir específicamente el soporte después de hora. También creo que puede ser útil tenerlos programados en el soporte después de horas regulares para sus aplicaciones de forma regular.

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

Lo ideal sería no por las razones mencionadas anteriormente, pero sí, mientras que el proyecto es incipiente, porque los desarrolladores pueden proporcionar resoluciones rápidas, a menudo esperadas por las empresas, que brindan soporte para la mejora continua del software. Valoro a los desarrolladores que brindan soporte de manera inteligente: aquellos que prestan sus habilidades analíticas mediante el ejemplo a un equipo de apoyo más formal a tiempo completo, y aquellos que responden al negocio de tal manera que muestren un espíritu de servicio y cooperación. Las claves de este éxito incluyen la gestión que reconoce y formaliza el soporte de primer y segundo nivel para descargar rápidamente a los desarrolladores de lo que debería ser su rol a corto plazo. Los desarrolladores que muestran una habilidad especial tanto para el desarrollo como para el soporte deben ser cultivados como soporte de tercer nivel o como apoyo para la gente de soporte. Por lo tanto, debería depende del tiempo, depende del talento y del deseo y se administra 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 principal.

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 apoyo y acepté la oferta. Puede ser la empresa o el entorno en el que estoy trabajando actualmente. Pero en realidad es un 90% de apoyo y un 10% de desarrollo. Hace ya un par de años que perdí las garras del desarrollo. Lamento haber aceptado esta oferta.

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

Lamentablemente, estoy en un punto muerto.

Por favor, no aceptes roles si no te gustan o no te interesan.

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

1) Mimar a sus clientes

Si es el soporte de primera / segunda / tercera línea (realmente me refiero al soporte de línea borrosa) donde los desarrolladores tratan directamente con los clientes, entonces es una gran estafa. Los desarrolladores tienen el conjunto de habilidades requerido 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 da como resultado clientes arruinados, exigentes y privilegiados que no pagan más que cualquier otro cliente.

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

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

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

3) Su currículum vitae sufre.

A menos que esté cambiando 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 soporte pagado que rota entre el equipo es una historia diferente.

Pros

1) Deja de lloriquear

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

Sí, porque lo hacen. Lol'd cuando leo esta pregunta? Era como si fuera una pregunta (no es que esté cuestionando su derecho a hacer la pregunta OP), pero es bastante retórica porque casi todos los desarrolladores que he conocido han tenido algún tipo de trabajo de soporte técnico implícito en su o su función de trabajo Simplemente no puedes evitarlo. En la mayoría de los casos, usted es la persona más compitante técnicamente, no solo en su dominio funcional, sino en términos de TI en general. Es muy difícil evitarlo por completo.