¿Qué harías si estuvieras en una situación en la que el proyecto en el que estás 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 ¿son felices?
¿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 sigo la corriente?
Respuestas:
Si los clientes están contentos, estás haciendo algo bien. Mucha gente disfruta de los hot dogs sin saber cómo están hechos ...
Si la aplicación es una buena solución al problema pero le preocupa que la base sea defectuosa, descubra cómo mejorar las cosas de manera incremental y elabore un plan para implementar esas mejoras a medida que actualiza el producto. Incremental es la clave: si tiene ganas de reescribir partes enteras, su gerente va a decir con razón que 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 delantera porque "tuvieron que" reescribir Navigator.
Si la interfaz de usuario de la aplicación es un desastre, los clientes pueden estar contentos porque la están comparando con "la forma difícil" e incluso un programa con errores puede ser mucho mejor que eso. Lo está comparando con un ideal que puede imaginar debido a sus antecedentes y habilidades. Nuevamente, considere cómo puede mejorar las cosas de manera incremental y proponga eso como parte del plan.
No dejes de preocuparte: quieres que tu 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.
No es una pesadilla para ellos. Será una pesadilla para ti y parecen pensar que sabes lo que estás haciendo, por lo que se solucionará. ¿Prefieres que las personas que no entienden la programación piensen que tu aplicación es peor de lo que realmente es? Esta no es la excepción. Disfrútalo mientras puedas. Es mejor que espere que el cliente supere esta aplicación. Pueden ir tan lejos en otra dirección como negocio que esto es absolutamente inútil. Podrías reescribirlo por un conjunto de razones completamente diferentes de lo que piensas.
No creo que deba dejar de preocuparse, incluso si parece que la alta dirección se ha detenido. Creo que lo importante 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 próximo grupo de gerentes para el que trabaja.
Comenzaría a presentar ideas para los próximos pasos de desarrollo que incluyen la refactorización para mejorar la calidad del código. Manténgase alejado de profundizar demasiado en los detalles técnicos, pero señale cómo las soluciones que sugiere significarán la satisfacción continua del cliente. Esté preparado para mezclar la limpieza con las nuevas funciones, ya que la gerencia siempre estará buscando algo nuevo para vender.
En general, a los clientes no les importará 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.
Usted no Utiliza el éxito para asegurar la financiación / permiso / aceptación para comenzar a refactorizar hacia lo técnicamente correcto y fácil de mantener. O utiliza el éxito para salir del departamento "Tengo que mantener la base de código antigua".
Quizás su prioridad / punto de vista sea incorrecto.
Lo más importante sobre cualquier proyecto de software es que satisface los requisitos de los usuarios.
Esto es muchísimo más importante que ser "correcto" según las modas de diseño de C / S de este mes.
Sí, debe 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 una manera sólida y sostenible.
Un sistema verdaderamente mal escrito que realmente satisfaga una necesidad comercial siempre es mejor que un código maravillosamente escrito maravillosamente documentado que nadie quiere o tiene alguna razón para usar.
Trate de comunicarse con los usuarios actuales y pregúnteles qué aspectos creen que necesitan mejorar. Luego, podría mejorar algunos aspectos que cree que necesitan mejoras y también mejorar los aspectos que los usuarios propusieron. 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 dedicado.