¿Qué hacer cuando su proyecto "fallido" es realmente "exitoso"?

14

¿Qué haría si estuviera en una situación en la que el proyecto en el que está trabajando obviamente está mal construido y tendrá fallas en el futuro y será una pesadilla para mantener ... pero la gerencia lo considera un "éxito"? ¿Porque los clientes están contentos?

¿No debería importarme? ¿Está bien que los clientes ni siquiera se den cuenta de que podrían tener una mejor aplicación que esta?

¿En qué punto dejo de preocuparme por construirlo correctamente y simplemente seguir el flujo?

    
pregunta James P. Wright 01.08.2011 - 22:25

7 respuestas

37

Si los clientes están contentos, estás haciendo algo bien. Mucha gente disfruta de los perros calientes sin saber cómo se hacen ...

Si la aplicación es una buena solución al problema, pero le preocupa que la base esté defectuosa, descubra cómo mejorar las cosas incrementalmente y planifique un plan para implementar esas mejoras a medida que actualiza la producto. La clave es incremental: si tiene ganas de reescribir partes enteras de ella, su gerente dirá con razón que eso no es razonable. Lo perfecto puede ser enemigo de lo bueno. Busque la historia de jwz de cómo Netscape dejó que IE tomara la iniciativa porque "tenían que" volver a escribir Navigator.

Si la interfaz de usuario de la aplicación es un desastre, los clientes pueden estar contentos porque lo están comparando con "la manera más difícil" e incluso un programa con errores puede ser mucho mejor que eso. Lo estás comparando con un ideal que puedes imaginar debido a tus antecedentes y habilidades. Nuevamente, considere cómo puede mejorar las cosas de manera incremental y aplique eso como parte del plan.

No deje de preocuparse: desea que su trabajo sea lo mejor posible. Pero también recuerde que es el cliente el que paga sus facturas y usted está escribiendo software para ellos, no usted.

    
respondido por el benzado 01.08.2011 - 22:36
4

No es una pesadilla para ellos. Será una pesadilla para ti y parece que piensan que sabes lo que estás haciendo, por lo que se solucionará. ¿Prefieres que las personas que no entienden la programación creen que tu aplicación es peor de lo que realmente es? Esta no es la excepción. Disfrútalo mientras puedas. Será mejor que esperes que el cliente supere esta aplicación. Pueden ir tan lejos en otra dirección como negocio que esto es absolutamente inútil. Podría estar reescribiéndolo por un conjunto de razones completamente diferente de lo que cree.

    
respondido por el JeffO 01.08.2011 - 22:40
3

No creo que debas dejar de preocuparte, incluso si parece que la gerencia superior se ha detenido. Creo que lo importante para sacar de esta experiencia es recordar y documentar todas las cosas que crees que salieron mal. Evitar estos errores en el futuro eventualmente será reconocido, si no este grupo actual de gerentes, tal vez el siguiente grupo de gerentes para los que trabaja.

    
respondido por el djnotepad 01.08.2011 - 22:59
2

Comenzaría a presentar ideas para los próximos pasos para el desarrollo que incluyen re-factoring para mejorar la calidad del código. Evite profundizar en los detalles técnicos, pero señale cómo los arreglos que sugiere significarán continuado la satisfacción del cliente. Prepárese para combinar la limpieza con las nuevas funciones, ya que la administración siempre estará buscando algo nuevo para vender.

En general, a los clientes no les importa el mantenimiento hasta que algo salga mal. Idealmente, su empresa se preocuparía por su reputación y querría protegerla manteniendo el código.

Sin embargo, si este producto se considera a muy corto plazo, es posible que no haya un valor agregado para hacerlo correctamente. En ese caso, busque las soluciones baratas, las cosas con poco esfuerzo que tienen un gran valor para la cordura del desarrollador.

    
respondido por el bethlakshmi 01.08.2011 - 22:31
2

No lo haces. Utiliza el éxito para asegurar la financiación / permiso / compra para comenzar a refactorizar hacia lo técnicamente correcto y fácil de mantener. O utiliza el éxito para obtener un ascenso del departamento "Tengo que mantener el antiguo código base".

    
respondido por el Wyatt Barnett 01.08.2011 - 22:31
0

Quizás tu prioridad / punto de vista es incorrecto.

Lo más importante de cualquier proyecto de software es que cumple con los requisitos de los usuarios.

Esto es un millón de veces más importante que ser "correcto" según las modas de diseño de C / S de este mes.

Sí, debería usar patrones de diseño correctos, usar la tecnología correctamente, etc., etc. pero solo en la medida en que facilita la implementación de los requisitos de los usuarios de forma robusta y mantenible.

Un sistema realmente mal escrito que realmente satisface una necesidad comercial siempre es mejor que un código maravillosamente bien escrito que nadie quiere o tiene alguna razón para usar.

    
respondido por el James Anderson 02.08.2011 - 09:24
0

Intente comunicarse con los usuarios actuales y pregúnteles qué aspectos consideran que necesitan mejoras. Entonces podría mejorar algunos aspectos que cree que necesitan mejoras y también los aspectos que propusieron los usuarios. Puede justificar sus mejoras como "necesarias para implementar las mejoras propuestas por los usuarios"

Por ejemplo: si los usuarios piensan que la función de búsqueda es lenta. Puede mejorar eso creando una mejor capa de datos que obviamente sirve más que solo la búsqueda, pero luego puede justificar el tiempo invertido.     

respondido por el Bazzz 02.08.2011 - 10:04

Lea otras preguntas en las etiquetas