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

Tengo un amigo". Sí, buen comienzo, lo sé, pero sinceramente, este no soy yo.

Básicamente, ha estado trabajando en un proyecto exitoso durante aproximadamente 4 años, la dificultad es que la deuda técnica se ha recuperado y le resulta casi imposible dejar de respaldar el producto (ajustar esto y aquello) y seguir adelante con un desarrollo real .

He hecho varias sugerencias, registrar todo su tiempo, crear tickets, no responder correos electrónicos, etc. El problema con esto es que parece servir solo como un recordatorio de que no está haciendo nada "útil".

La deuda técnica se ha producido en gran medida porque, en primera instancia, fue un gran beneficio para el producto recibir solicitudes y llamadas telefónicas de los usuarios e implementarlas rápidamente.

Lo que me gustaría saber es si alguien tiene alguna sugerencia sobre cómo podría salir de esta rutina, una gran parte de la cual estaría cambiando las percepciones de los usuarios para que no piensen que pueden llamar y esperar algo hacerse entonces y allí.

Está muy bien decir planear mejor, aunque entiendo que es muy difícil planificar el desarrollo real dado el requisito de soporte y las presiones relativas de los usuarios (ver arriba).

La organización de su amigo necesita desesperadamente a alguien que haga la gestión del cambio. Esta persona o grupo tomaría solicitudes de cambio y correcciones de errores y las priorizaría de acuerdo con el impacto comercial 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ían 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 la empresa puede hacer para solucionar el problema, eso reduce la gravedad al siguiente nivel. Si la aplicación no es crítica para el negocio, eso hace que la gravedad sea aún menor. Las solicitudes de nuevas mejoras normalmente se priorizan por separado.

Haga que otra persona atienda las llamadas y cambie la línea 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 seguirlo 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 simple y efectiva de hacerlo en mi opinión. La última parte trata de reducir el estrés de esta persona que responde las llamadas con el tiempo.

El problema que está viendo con el sistema actual de 'prioridad' 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. Idealmente, su amigo ni siquiera debería saber acerca de una solicitud de función, hasta que ese grupo separado acordó que debería priorizarse para el trabajo. Incluso podría ser esta nueva persona que está respondiendo las llamadas ahora que les da prioridad, siempre y cuando comprendan el negocio y comprendan el desarrollo.

He pasado por una situación similar yo mismo. El producto fue construido sobre cuerdas de zapatos y fue el primero en su mercado en el lanzamiento. Inicialmente fue exitoso (para un negocio en solitario), pero supongo que todo funcionó entre 2003 y 2007. Intenté contratarlo, pero aprendí por las malas que contratar a un buen personal es costoso y de ninguna manera fácil. Supongo que tu amigo está en una situación similar.

En mi caso, se hizo evidente desde el principio que las cosas irían cuesta abajo en algún momento. El negocio todavía estaba creciendo, pero la competencia estaba alzando la cabeza, el mercado parecía que iba a reducirse, hubo indicios tempranos (mediados de 2006) de que se estaba desacelerando la economía, etc. Básicamente, una serie de factores llevaron decidí que el producto moriría eventualmente; cuanto más tarde, mejor (para los clientes y para mí).

En retrospectiva, probablemente tomé tantas decisiones buenas como malas, pero aquí hay un breve resumen:

1. Personal de forma adecuada y temprano. Obtenga financiación si la necesita. (No buscar ninguno fue mi mayor error). Si tiene ventas, encontrará dinero.

2. Utilice el control de versiones / pruebas unitarias / todos los hoopla relacionados con las mejores prácticas. Todos se ven tontos / ridículos / poco interesantes cuando se les enseña en la universidad, pero generalmente son las mejores prácticas por buenas razones.

3. Contrata al menos un agente de ventas / marketing, especialmente si estás orientado a la tecnología. (Porque si es así, tendrá una tendencia natural a pasar más tiempo en asuntos tecnológicos que en marketing, incluso si tiene una red de afiliados).

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

5. Maximice sus esfuerzos para reducir la cantidad de soporte que está brindando. Cuanto menos apoyo tenga, más tiempo tendrá para hacer cosas más interesantes. En el momento en que el producto sea ficticio, los clientes estarán agradecidos y también lo estarán sus ventas y su personal de soporte.

6. Haga que los desarrolladores reales realicen parte del soporte (una o dos horas por día, para que no pierdan contacto con la realidad) y deles una mano libre para sugerir cualquier reingeniería / cambio del producto (UI, funcionalidad) si identifique cualquier cosa que les haga pasar 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 cree que el producto va a morir, decida matarlo aquí y allá y trabaje en el siguiente paso. Déjalo morir, de verdad. Una vaca de efectivo es una vaca de efectivo; cuando haya cumplido su propósito, envíelo al carnicero. Hágalo con cuidado (para los clientes), pero no deje que su supervivencia prolongada engulle demasiado tiempo si la sobrecarga de mantenimiento es tal que su competencia, con el beneficio de llegar tarde y haber acumulado alguna deuda técnica , implementará nuevas funciones más rápido de lo que puede de todos modos.

Una línea a la vez. Tómese un poco más de tiempo para cada solución, limpie los hacks y agregue pruebas automáticas a medida que avanza. A menudo, hacer algo bien termina siendo mucho más rápido que agregar otra revisión. Si la administración empuja a su 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 normalmente durante el sprint. 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 gerencia apoya 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 su amigo.

Lo mejor que puedes hacer es parar el autobús y mirar hacia atrás. Tu amigo deberia

• Elabora un informe de cada problema en el sistema y el razonamiento detrás de por qué son malos. Deben destacarse los problemas de diseño y la cantidad de refactorización necesaria.
• Se deben dar plazos aproximados para solucionar los problemas.
• El informe debe entregarse a sus gerentes y luego a los interesados ​​en el sistema.
• Todos los desarrollos de características deben detenerse durante el período de fijación.

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