¿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?
project-management
client-relations
James P. Wright
fuente
fuente
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.
fuente
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.
fuente
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.
fuente
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".
fuente
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.
fuente
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.
fuente