¡Cómo salir de la rutina de soporte y comenzar a pagar la deuda técnica!

La organización de su amigo necesita desesperadamente que alguien haga la gestión del cambio. Esta persona o grupo tomaría las solicitudes de cambio y las correcciones de errores y les daría prioridad de acuerdo con el impacto en el negocio y la cantidad de esfuerzo requerido. De esa manera, las tareas que son más importantes para la organización en su conjunto se realizarán primero, en lugar de las tareas que son más importantes para quien esté molestando a su amigo en este momento.

EDITAR: como ejemplo de cómo funcionaría esto, la mayoría de las organizaciones tienen una escala de gravedad. El nivel de gravedad más alto es una aplicación o función crítica para el negocio que no funciona. Si hay algo que el negocio puede hacer para solucionar el problema, eso reduce la gravedad al siguiente nivel. Si la aplicación no es crítica para el negocio, la severidad es aún más baja. Las solicitudes de nuevas mejoras normalmente se priorizan por separado.

Haga que alguien más atienda las llamadas, y haga que la línea cambie de

  

Llegaremos a eso de inmediato.

a

  

Muy buena sugerencia. Crearé una solicitud de función para comenzar a trabajar en ella lo antes posible. Si desea seguir el progreso de su solicitud, puede rastrearlo aquí: [enlace al ticket del rastreador de casos]. En el futuro, también puede enviar solicitudes de futuros de la misma manera que estoy aquí: [enlace al rastreador de casos]

Esa es probablemente la forma más sencilla y efectiva de hacerlo, en mi opinión. El último bit intenta reducir el estrés de esta persona que responde las llamadas con el tiempo.

El problema que está viendo con el sistema de 'prioridad' actual es que cuando todo es una prioridad, nada es una prioridad . Para eso, su amigo necesita desesperadamente prestar atención al consejo de @Larry Coleman, personas separadas del desarrollo que gestionan las solicitudes de cambio. Lo ideal sería que su amigo ni siquiera supiera acerca de una solicitud de características, hasta que ese grupo independiente acordara que debería ser priorizada para el trabajo. Incluso podría ser esta nueva persona que está respondiendo las llamadas ahora que las prioriza, siempre que comprendan el negocio y comprendan el desarrollo.

Yo también he pasado por una situación similar. El producto fue construido sobre cuerdas de zapatos y fue el primero en su mercado en el lanzamiento. Inicialmente fue exitoso (para un negocio de personas solteras), pero supongo que todo funcionó entre 2003 y 2007. Busqué personal, pero aprendí de la manera más difícil que contratar un buen personal es costoso y de ninguna manera fácil. Supongo que tu amigo está en una situación similar.

En mi caso, quedó claro desde el principio que las cosas irían cuesta abajo en algún momento. El negocio seguía creciendo, pero la competencia estaba alzando la cabeza, el mercado parecía que iba a disminuir, hubo señales tempranas (mediados de 2006) de que se estaba produciendo una desaceleración económica, etc. Básicamente, una serie de factores motivaron Que yo decida que el producto morirá eventualmente; cuanto más tarde, mejor (para los clientes y para mí).

En retrospectiva, probablemente tomé tantas buenas decisiones como tomé malas, pero aquí hay una breve reseña:

1. Personalice correctamente y temprano. Obtenga financiamiento si lo necesita. (No buscar ninguno fue mi mayor error). Si tiene ventas, encontrará dinero.

2. Use control de versiones / pruebas de unidad / todas las recomendaciones relacionadas con las mejores prácticas. Todos se ven tontos / ridículos / poco interesantes cuando se enseñan en la universidad, pero generalmente son las mejores prácticas por buenas razones.

3. Contrate al menos un vendedor / vendedor, especialmente si está orientado a la tecnología. (Porque si es así, tendrá una tendencia natural a dedicar más tiempo a asuntos de tecnología que a marketing, incluso si tiene una red de afiliados).

4. fuente de multitud su apoyo. Configura un foro para que los usuarios puedan ayudarse a sí mismos. Configure un sistema de emisión de boletos e invite a sus usuarios expertos (normalmente usuarios frecuentes del foro) a sumergirse en una sección especial como asistentes virtuales. Deje que se ocupen de las multitudes de clientes que necesitan esta / esa pequeña tarea realizada por unos pocos dólares, para que pueda concentrarse en el panorama general.

5. Maximice sus esfuerzos para reducir la cantidad de asistencia que está brindando. Cuanto menos apoyo tengas, más tiempo tendrás para hacer cosas más interesantes. En el momento en que el producto sea una prueba ficticia, los clientes se lo agradecerán, al igual que sus ventas y su personal de soporte.

6. Haga que los desarrolladores reales realicen parte del apoyo (una o dos horas por día, para que no pierdan el contacto con la realidad) y les den una mano libre para sugerir cualquier cambio o cambio de producto ( UI, funcionalidad) si identifican algo que les haga perder menos tiempo en soporte. La idea es que, si los usuarios los molestan una y otra vez por las mismas razones, querrán arreglar las cosas lo antes posible para poder deshacerse de las llamadas de soporte. Y los más inteligentes realmente lo hacen, y eso es exactamente lo que quieres.

7. Si sientes que el producto va a morir, decide matarlo aquí y allá y continúa con el siguiente paso. Dejalo morir, de verdad. Una vaca de dinero es una vaca de dinero; Cuando haya cumplido su propósito, envíelo al carnicero. Hágalo con suavidad (para los clientes), pero no permita que su supervivencia prolongada le consuma demasiado tiempo si la sobrecarga de mantenimiento es tal que su competencia, con el beneficio de ser recientes y de haber acumulado algo de deuda técnica , implementará nuevas funciones más rápido de lo que puedes de todos modos.

Una línea a la vez. Tómese un poco más de tiempo para cada corrección, limpie hacks y agregue pruebas automáticas a medida que avanza. A menudo, hacer algo bien termina siendo mucho más rápido que agregar otro hotfix. Si la administración empuja a tu amigo a trabajar más rápido, como a la administración a menudo le gusta hacer, debería crecer una piel más gruesa y entrar en el modo "cuando haya terminado".

La clave es qué tipo de metodología de desarrollo tiene a su alrededor para protegerlo hasta cierto punto. Por ejemplo, en Scrum existe la idea de que el trabajo que se realizará no cambia durante el sprint por lo general. Por lo tanto, hay algunas reglas sobre lo que se va a hacer y lo que no se puede hacer de inmediato. La otra pregunta es ¿hasta qué punto la administración respalda su deseo de no estar en una rutina de soporte? Esto también podría ser importante, ya que un manejo apático puede ser un poco mortal para el proyecto de un amigo.

Lo mejor que puedes hacer es detener el autobús y mirar hacia atrás. Tu amigo debería

• Haga un informe de cada problema en el sistema y el razonamiento detrás de por qué son malos. Los problemas de diseño deben resaltarse, y la cantidad de refactorización necesaria.
• Deben darse líneas de tiempo aproximadas para solucionar los problemas
• El informe debe entregarse a sus gerentes, y luego a las partes interesadas en el sistema
• Todos los desarrollos de funciones deben detenerse durante el período de fijación.

Muchos proyectos hacen esto. Si la administración no puede convencerse, es un caso perdido, pero si están de acuerdo, el sistema podría volver a ponerse en forma a largo plazo.