Cómo "vender" el soporte como una opción profesional [cerrado]

Nos resulta relativamente fácil contratar desarrolladores para trabajar en varios proyectos.

El problema surge cuando el proyecto está terminado pero aún necesita ser apoyado.

Realmente luchamos para que las personas se unan al equipo de soporte. Se ve como un callejón sin salida, que limita la carrera, es aburrido, de segunda clase, etc.

Actualmente, lo solucionamos haciendo que el equipo del proyecto asigne parte de su equipo al equipo de soporte durante un tiempo. Parte de la tarea es hacer un "volcado del cerebro" del proyecto para que el equipo de soporte lo entienda. Esto funciona siempre que la asignación sea solo por un período fijo.

Intentar contratar personas para trabajar a tiempo completo es un problema. Hay pocas aplicaciones y el calibre no es particularmente alto.

(Sin embargo, la realidad financiera es que el soporte puede ser muy lucrativo para una empresa y una vez que se obtiene una reputación, otras compañías se acercan a usted para que lo apoyen aunque no haya participado en el desarrollo original)

No

Para mí, la mejor opción aquí es no separar a los desarrolladores en soporte y no soporte en primer lugar. En mi humilde opinión, hay tres razones principales:

• las personas que escriben cosas que son difíciles de apoyar no aprenden hasta que tienen que apoyarlas.
• las personas que solo brindan apoyo generalmente tomarán el camino de menor resistencia para corregir un error, incluso si obstaculiza el trabajo futuro.
• el ahorro de tiempo teórico en cumplir el cronograma en el nuevo desarrollo al contar con los desarrolladores de soporte separados siempre es más que consumido al tener que proporcionar instrucciones o repetir el trabajo.

Dentro del equipo de desarrollo, puede tener personas que tengan tareas de mantenimiento o adopten un enfoque de permitir que las tareas de mantenimiento sean los campos de entrenamiento para los miembros más nuevos del equipo, pero si intenta venderlo como el objetivo a largo plazo del puesto, solo atraerá personas que le causarán acidez estomacal o personas que pronto se irán.

Siempre debe haber un camino claro para salir de un rol de desarrollo de soporte al 100% y / o un cierto porcentaje de trabajo de desarrollo nuevo para mantener a las buenas personas interesadas.

No desea atraer a la clase de personas que están felices en ese rol indefinidamente y nunca convencerá a los buenos desarrolladores para que asuman ese rol y lo mantengan a largo plazo a menos que ofrezca el tipo de pago que nunca los consideraría. Un cambio de carrera.

Haga que el trabajo de soporte sea divertido y valioso para sus desarrolladores.

Me encanta hacer soporte por las siguientes razones:

• Hablo con personas de todo el mundo. Hice muchos amigos así. ¡Hace unos años, uno de mis clientes me invitó a su boda! Solía ​​tener un mapa del mundo en mi oficina con alfileres que los ubicaban.
• El apoyo es casi el mejor para obtener gratificaciones por su trabajo. Cuando haces felices a los usuarios, también te hace más feliz.
• Las quejas son una forma útil de mejorarte a ti mismo. Tomo cualquier queja en serio, y en la mayoría de los casos, puedo convertir a alguien enojado en un cliente / usuario feliz que eventualmente correrá la voz.
• Me ayuda a entender lo que los clientes / usuarios necesitan. Entonces puedo construir un mejor software.

Eso son solo algunas razones.

Con respecto al soporte en sí, sugiero implementar un proceso fácil de administrar.

Cuando recibimos un caso de soporte, hacemos lo siguiente:

• Si es un error reproducible, lo agregamos a la cartera de pedidos y le damos su ID al cliente / usuario. También tomamos la identificación del cliente / usuario para notificarle de las resoluciones y liberar a la persona. Esto es fácil si recopila su correo electrónico directamente.
• Si es un problema usar el software, aprovechamos esto como una oportunidad para mejorar la documentación. Cualquier respuesta se escribe como un artículo de base de conocimiento que agregamos en nuestra base de datos después. Tarda el triple de tiempo en escribir, pero no lo repetimos más tarde (la mayoría de los usuarios prefieren navegar en KB).
• Si se trata de una solicitud de función, conectamos al usuario con el propietario del producto directamente. Esto es muy valioso Por supuesto, utilizamos sistemas como uservoice.com, pero hablar con el usuario directamente es mucho mejor.
• Si se trata de una queja, tratamos de gestionarla fuera del proceso. A las personas que se quejan les gusta que las consideren importantes (incluso si la queja es trivial).

¿Por qué no solo pagar a los desarrolladores de soporte 5 o 10k más que la construcción y olvidar a los desarrolladores?

Al adjuntar una prima adicional para soportar roles; en reconocimiento de los desafíos adicionales de "enlace con el cliente" y "mantenimiento del código de producción"; no solo proporcionará una motivación adicional, sino que lo más importante será que los roles tendrán más prestigio. Después de todo, un salario más alto debe significar un papel más importante e incluso si ese no es el caso, se percibirá de esa manera.

Si cree que el soporte es un trabajo de segunda categoría, es probable que tenga problemas para contratar personas. Si lo trata como un trabajo que limita la carrera y el callejón sin salida, no obtendrá buenos candidatos.

El soporte generalmente no se considera tan divertido como el nuevo desarrollo, y si tiene equipos de desarrollo y soporte separados, los equipos de soporte deben tomar lo que el desarrollo les brinda, lo que a menudo no es divertido. (Una vez trabajé en un lugar donde R&D nos entregaba un software que hacía algo genial, pero que por lo general necesitaba un rediseño para ser de calidad de producción, y no tuvimos suficiente tiempo para hacerlo, por razones políticas. Eso no fue divertido.)

Si el soporte es realmente crítico para el negocio, debe tratarlo como tal. Si insiste en tener equipos de soporte separados, y es importante tener buenos equipos, debe abordar estos problemas. Asegúrate de que haya una carrera hacia arriba. Publique el dinero que está ganando con el apoyo, en parte por su autoestima, en parte para hacer que otras personas se den cuenta de su valor, en parte para que puedan poner cifras de dólares para sus actividades en sus hojas de vida. Establezca estándares y permita que los equipos de soporte aporten información sobre si un proyecto está listo para pasar del desarrollo al soporte. Como el trabajo es menos divertido y posiblemente más importante, pague mejor. (Tendría más simpatía con los gerentes que se quejan de "no podemos obtener los solicitantes que necesitamos" si no se traduce generalmente como "no podemos encontrar a los solicitantes que necesitamos baratos").

Si bien estoy de acuerdo en que el apoyo generalmente es un asco, muchos desarrolladores podrían disfrutar el prestigio que acompaña a la "propiedad" del proyecto, incluso si no escribieron el software ellos mismos. Ese programador se convierte en el goto de ese proyecto, y realmente se convierten en un experto invaluable en el sistema. Si bien estoy principalmente involucrado en nuevos desarrollos en la compañía para la que trabajo, muchos de mis colegas que son más que competentes en realidad son muy respetados por el mantenimiento de nuestro software más crítico. Después de todo, el software que se admite actualmente es probablemente el que actualmente está haciendo dinero (un pájaro en mano vale dos en el monte).
Solo diría que no todos ven el apoyo como un terrible trabajo de mazmorra para programadores de baja calidad, y jugaría con ese sentimiento para atraer a más personas.

Algunas reflexiones:

1) Dices que se ve como un callejón sin salida y una limitación profesional. Si esto no es cierto y la gente ha pasado a otras cosas (desarrollo, gestión de proyectos, gestión del equipo), entonces estoy seguro de que tiene ejemplos que puede usar. Si no tiene ejemplos, entonces puede que tenga que aceptar que es un callejón sin salida y una limitación de carrera y que necesita abordar estos problemas.

2a) Si el soporte incluye la corrección de errores, ¿por qué están separados? Si alguien lo codificó mal para empezar, entonces, ¿qué le estás enseñando al darle su desorden a otra persona para que lo resuelva? Además, si los desarrolladores de soporte no se consideran tan buenos como los desarrolladores, ¿cómo puede esperar que arreglen lo que los desarrolladores no pudieron hacer? En serio, la regla debería ser que lo escribiste, lo arreglaste.

2b) Si el soporte no incluye la corrección de errores, entonces son trabajos muy diferentes y enfatizan diferentes habilidades. No debería preocuparse por cruzar aquí más de lo que se preocupa por cruzar entre el desarrollo y la limpieza.

3) Usted dice que es lucrativo para la empresa, luego lo hace lucrativo para las personas involucradas. Esto podría ser a través de un mejor dinero, una mejor capacitación, un mejor equipo y dándoles todo lo que necesitan para hacer esto realmente bien. Si hay dinero disponible, que sea un gran trabajo.

El problema al leer su publicación es que no parece creer que sea un buen trabajo. Si eso es cierto, entonces no es de extrañar que no pueda venderlo como uno.

El apoyo es un trabajo difícil, a ningún cuerpo le gusta escuchar a las personas quejarse todo el día. Encontrar gente buena puede llevar tiempo, pero una vez que lo tienes, debes mantenerlo cerca

1. Pague buen dinero, incluso muy por encima de las tasas de la industria para mantener a las buenas personas
2. Proporcione un buen ambiente de trabajo, pequeñas cosas como trabajo, almuerzo y bebidas.
3. No meta a todo su personal de apoyo en una habitación pequeña y ruidosa.

Creo que zappos.com ha demostrado que un trabajo no tiene que ser malo cuando trabajas para una buena compañía. La peor parte de estar en apoyo es no poder ayudar a alguien. Si fastidió a los usuarios con una letra pequeña del contrato de servicio o si envió un software defectuoso que no se solucionará pronto, el soporte será una mierda. Deben ser alentados a encontrar soluciones a los problemas; algo así como la programación.

Apoyé durante un par de años a mi primera empresa fuera de la universidad. Lo que me hizo registrarme durante un par de años fue:

1. La carrera requerida para convertirse en ingeniero de software.
2. Necesitaba tiempo para repasar el idioma principal de la compañía (Fortran, Circa 1989)
3. No estaba casado, así que podría renunciar si descubría que no me gustaba la compañía o el trabajo.

¿Qué tal una mezcla de desarrollo y soporte (roles divididos)? Creo que aún tendrá dificultades para obtener la aceptación por eso debido a razones ya mencionadas (¡desarrolladores! = Personas de soporte de productos). Pero si su producto se basa en una amplia comprensión de la tecnología interna, tal vez un 80% de desarrollo, un 20% de soporte sería una compensación justa. O algún tipo de tutoría / observación para los nuevos empleados para garantizar que obtengan información correcta sobre el producto.