«La gente la usará en el móvil» no zanja la decisión. Una aplicación web puede funcionar en el navegador de un móvil. Tampoco basta con «necesitamos acceso sin conexión»: el comportamiento sin conexión hay que diseñarlo, y algunas aplicaciones web pueden admitirlo. La pregunta útil es qué enfoque puede cubrir su flujo de trabajo real con restricciones aceptables.
Una aplicación web se ejecuta en un navegador. Los usuarios suelen acceder mediante una URL, y la interfaz puede adaptarse a un teléfono, una tableta o un equipo de escritorio. Sus capacidades dependen de los navegadores y dispositivos que usted admita.
Una aplicación móvil nativa se construye para una plataforma concreta, como iOS. Se instala en el dispositivo y usa las convenciones de interfaz y las APIs disponibles de esa plataforma. Admitir otra plataforma nativa supone trabajo adicional de entrega y verificación.
Una aplicación web progresiva, o PWA, usa tecnologías web con capacidades adicionales, como la instalación y un comportamiento sin conexión diseñado a propósito. La documentación de MDN sobre las PWA explica esas posibilidades. Su disponibilidad y su comportamiento aún deben comprobarse en sus dispositivos de destino; «PWA» no es una promesa de que todas las funciones nativas funcionen en todas partes.
Use los requisitos siguientes para elegir la primera plataforma del producto.
En una pantalla estrecha, desplace la tabla hacia los lados para leer todas las columnas.
| Requisito | Aplicación web: qué comprobar | App nativa: qué comprobar |
|---|---|---|
| Los clientes llegan mediante un enlace | ¿Pueden completar el recorrido en los navegadores admitidos sin instalar nada? | ¿Es aceptable que instalen una app antes de recibir valor? |
| El trabajo abarca escritorio y teléfono | ¿Los diseños y las interacciones sirven para ambos? | ¿Los usuarios de escritorio necesitarán también una interfaz web? |
| Una función del dispositivo es esencial | ¿La API necesaria está disponible y es fiable en los navegadores exactos que debe admitir? | ¿La plataforma ofrece la capacidad, y qué permisos y restricciones se aplican? |
| La conexión no es fiable | ¿Qué acciones funcionan sin conexión y cómo se sincronizará el trabajo almacenado? | Se aplican las mismas preguntas; instalar la app no hace que funcionen sin conexión las acciones que dependen del servidor. |
| Se necesitan varias plataformas | Verifique el comportamiento en las combinaciones de navegador y dispositivo admitidas. | Defina el alcance de cada plataforma y las pruebas, el trabajo de publicación y el mantenimiento que necesita. |
| Las versiones deben cambiar con frecuencia | Planifique el despliegue, la compatibilidad y la recuperación para los cambios en el servicio en funcionamiento. | Tenga en cuenta también la distribución, la revisión cuando proceda y los usuarios con versiones antiguas de la app. |
No trate esto como una puntuación en la que gana quien suma más marcas. Una sola capacidad esencial puede determinar el enfoque. Varias preferencias pueden no justificar plataformas adicionales.
Un portal de aprobación para clientes: los clientes reciben un enlace, revisan documentos, aprueban trabajos y a veces completan la tarea desde el teléfono. El personal gestiona los registros desde un escritorio. Una aplicación web adaptable es una primera candidata razonable. Antes de construir una app, compruebe si instalarla mejoraría en algo el recorrido importante.
Una herramienta de registro en campo: el personal captura información durante todo el día en lugares con mala conexión. El producto necesita un comportamiento específico del dispositivo, registros locales y sincronización posterior. Evalúe una app nativa y una PWA frente a esos requisitos exactos. Un pequeño experimento de capacidad en los dispositivos reales puede resolver la elección mejor que una comparación genérica de funciones.
Son flujos de trabajo hipotéticos, no afirmaciones sobre resultados de clientes de AL+. El primero favorece el acceso sencillo desde distintos dispositivos; el segundo pone en el centro el comportamiento del dispositivo y de la conexión. Ninguno determina la arquitectura de todos los productos de su categoría.
Describa qué ocurre antes, durante y después de que falle la conexión:
Una pantalla en caché y una transacción de negocio sin conexión son requisitos distintos. Por ejemplo, mostrar una cita cargada antes no demuestra que se pueda confirmar una reserva nueva sin conectar con el sistema que gestiona la disponibilidad.
Tanto las implementaciones nativas como las web requieren decisiones sobre datos, conflictos y recuperación. Consulte la documentación de la plataforma pertinente y verifique el comportamiento crítico en lugar de prometerlo por el nombre de una tecnología.
Una app instalada puede seguir dependiendo de cuentas, registros compartidos, pagos, notificaciones y herramientas administrativas que funcionan en otro lugar. Una aplicación web puede necesitar esos mismos servicios.
En ambos casos, identifique qué backend existe ya, quién lo controla, qué interfaces hay disponibles y qué hay que construir. Llevar la interfaz a un teléfono no resuelve una integración poco fiable ni una titularidad de los datos poco clara.
Incluya el flujo de trabajo administrativo. Si alguien tiene que corregir un registro o atender a un cliente, decida cómo lo hará. Una experiencia móvil para el cliente y una interfaz web de administración pueden ser dos interfaces distintas de un mismo producto, pero ambas forman parte del alcance.
Pida a cada propuesta que separe el trabajo común del producto del trabajo de cada plataforma:
No existe un porcentaje universal fiable por el que un enfoque sea más barato que el otro. Un backend existente, una capacidad imprescindible del dispositivo o una segunda interfaz pueden cambiar la comparación. Compare la misma versión útil, no dos recuentos de pantallas ni dos tarifas por hora.
Nuestra guía del costo de una app móvil (en inglés) explica el trabajo que implica una estimación de una app nativa para iOS. Es una lista de verificación del alcance, no la promesa de un precio estándar de proyecto.
Escriba estas seis líneas antes de pedir a un desarrollador que elija la tecnología:
Si una capacidad pudiera cambiar la decisión, solicite una comprobación técnica concreta antes de construir todo. Si la incertidumbre es cómo usan las personas la interfaz, un prototipo puede ser el primer paso adecuado.
AL+ crea aplicaciones web a medida y apps nativas para iPhone y iPad, y se responsabiliza de los servicios conectados y del mantenimiento tras el lanzamiento. Podemos hablar de la primera plataforma a partir de la tarea, los dispositivos de destino y el sistema existente.
Escriba a AL+ sobre su proyecto web o iOS. Envíe el briefing de seis líneas para que la conversación empiece con los requisitos que determinan el trabajo.
]]>Si está comparando proveedores, pida a cada uno que valore el mismo alcance. Una cifra mensual que excluye el despliegue, las actualizaciones de dependencias y la investigación de incidentes no puede compararse con otra que sí los incluye.
El precio de la construcción original no le dice a un nuevo proveedor si sus copias de seguridad se restauran, si sus dependencias tienen soporte o si la integración de pagos falla sin avisar. Antes de tomar cualquier estimación como un compromiso, determine qué funciona en producción y qué partes requieren atención.
Anote lo siguiente:
Si el desarrollador original se ha ido, use la lista de verificación para el traspaso de código para identificar los accesos y los conocimientos que faltan. Puede reunir esta información sin haber elegido antes a un nuevo proveedor.
Un equipo nuevo necesita entender la producción, comprobar los accesos, establecer un despliegue repetible y verificar la recuperación. La falta de documentación o un framework sin soporte pueden añadir trabajo antes de que empiece el mantenimiento normal.
Pregunte qué entrega el alcance inicial y qué haría necesaria una estimación revisada. Manténgalo separado del servicio mensual continuo para que ambas partes vean el costo de heredar el sistema.
Enumere el trabajo planificado: actualizaciones de dependencias y de seguridad, comprobaciones de las versiones, pruebas de restauración de copias de seguridad, monitorización y documentación operativa. Acuerde con qué frecuencia se hace cada tarea y qué constancia recibe usted.
Las facturas de alojamiento, base de datos, correo y otros proveedores también forman parte del presupuesto de operación. Indique si las paga usted directamente o a través del proveedor de mantenimiento. El tiempo de ingeniería y las facturas de infraestructura son costos distintos.
Especifique el horario de cobertura, la zona horaria, el canal de contacto y qué se considera urgente. El tiempo de respuesta significa que alguien empieza a evaluar el problema; no significa que el problema se resuelva en ese plazo.
Para una empresa de Estados Unidos o Canadá que trabaja con un equipo remoto, hable explícitamente de la coincidencia de horarios. No dé por hecho que un acuerdo de mantenimiento mensual incluye atención nocturna o en fin de semana.
Separe la corrección de errores de los cambios en el funcionamiento del producto. Una nueva integración o un cambio grande en un flujo de trabajo necesita su propio alcance, aunque el mismo equipo se ocupe del mantenimiento y del desarrollo.
Acuerde cómo se priorizan las tareas, cómo se aprueban las estimaciones y qué ocurre cuando el mes trae más trabajo que capacidad disponible. Esa conversación importa más que el nombre del paquete.
Rellene estas líneas antes de comparar presupuestos:
En cada presupuesto, pida al proveedor que marque qué está incluido, qué está excluido y qué aún no se sabe. Pregunte cómo se tratan la capacidad no utilizada y el trabajo que supera el alcance acordado. No dé por hecho que se acumulan para el mes siguiente ni que se facturan automáticamente.
Un proveedor puede ofrecer legítimamente un servicio acotado. El riesgo es un vacío sin responsable: soporte de la aplicación sin actualización de dependencias, monitorización sin una persona que reciba las alertas, o copias de seguridad sin prueba de restauración.
Pregunte quién responde de cada vacío. Puede conservar una tarea dentro de su empresa, contratar a un especialista o incluirla en el alcance del mantenimiento. El resultado útil es que cada tarea tenga un responsable explícito.
Si la aplicación tiene soporte y es fácil de desplegar, puede bastar con el mantenimiento periódico. Si primero hace falta actualizar un framework, reparar el despliegue o migrar datos, defina ese trabajo por separado.
Nuestra guía para decidir entre reparar o reescribir ayuda a distinguir el trabajo puntual de la sustitución. El presupuesto de mantenimiento debe reflejar esa decisión, en lugar de esconder un proyecto de modernización dentro del mantenimiento rutinario.
AL+ ofrece servicios de mantenimiento de software para aplicaciones web y productos SaaS existentes, incluidos los sistemas creados por otro desarrollador o agencia.
Escriba a paul@alplustech.com sobre el mantenimiento de software. Describa la aplicación, su tecnología si la conoce, su país, el problema actual y el horario de soporte que necesita. Envíe primero una descripción; no incluya en el correo contraseñas, claves de API ni datos de clientes.
]]>La lista tiene ocho partes. Cada punto es una pregunta con respuesta de sí o no. Un «no» no es motivo para rechazar el sistema. Es una línea del plan.
El fallo más común en un traspaso es descubrir, semanas después, que una cuenta crítica pertenece a alguien que se ha ido.
Si alguna respuesta es «no lo sabemos», deténgase y averígüelo antes de cambiar nada.
El repositorio le dice lo que se pretendía. La producción le dice lo que es cierto.
Los datos son la parte de un sistema que no se puede regenerar.
Restaure una copia de seguridad en un lugar seguro durante la revisión. Una copia de seguridad que nunca se ha restaurado es una esperanza, no una copia de seguridad.
Va a necesitar cambiar el sistema. Averigüe lo peligroso que es.
Si la respuesta a la última pregunta es no, arreglar ese circuito es la primera tarea de ingeniería, antes de cualquier función nueva.
Esto no es una prueba de penetración. Es lo mínimo que debe saber antes de hacerse cargo del sistema.
Pregunte por decisiones, no por código: por qué esta base de datos, por qué este alojamiento, qué cambiarían, qué les daba miedo. Anote las respuestas.
Escriba las respuestas en un único documento, con una lista de los «no» ordenada por riesgo. Esa clasificación se convierte en las primeras semanas de trabajo: primero los accesos y la facturación, después las copias de seguridad y los despliegues, luego las partes frágiles y por último las que se desean. Un traspaso hecho en este orden le hace esperar una función nueva más de lo que quería, pero nunca le muestra una caída del servicio.
Si prefiere que nosotros hagamos esta revisión y después nos hagamos cargo del sistema, para eso está nuestro servicio de traspaso de software. Si prefiere hacerla usted mismo, la lista es suya.
]]>Son compras distintas. Una demostración pulida no incluye necesariamente el tratamiento de datos, los permisos, el proceso de publicación o el soporte que necesita un producto en funcionamiento. Antes de comparar propuestas de desarrollo, nombre la pregunta que quiere que responda el trabajo.
Los nombres varían de un equipo a otro. Acuerde el resultado que se pretende en lugar de fiarse del nombre que figure en una propuesta.
En una pantalla estrecha, desplace la tabla hacia los lados para leer todas las columnas.
| Entregable | Pregunta a la que responde | Qué debería poder observar | Qué no demuestra |
|---|---|---|---|
| Prototipo | ¿Pueden los usuarios entender y completar esta interacción propuesta? | Las personas prueban un recorrido limitado; usted ve dónde dudan o lo malinterpretan. | Integraciones fiables, funcionamiento en producción ni disposición a pagar. |
| Prueba de concepto | ¿Puede funcionar un enfoque técnico concreto con las restricciones relevantes? | Un experimento acotado demuestra una capacidad, por ejemplo leer los datos necesarios de un proveedor. | Un producto completo ni una experiencia de cliente utilizable. |
| MVP | ¿Puede un producto pequeño y funcional aportar el valor previsto a sus primeros usuarios? | Usuarios reales completan la tarea principal; usted recoge comentarios y observa el uso. | Encaje del producto con el mercado, captación rentable ni preparación para todos los clientes futuros. |
Un prototipo puede ser un boceto en papel, un diseño en el que se puede hacer clic o una interfaz programada y limitada. Su utilidad viene de lo que se aprende, no de la cantidad de código que contiene. La guía de la fase alfa de GOV.UK (en inglés) hace la misma distinción práctica: probar las hipótesis arriesgadas con prototipos en lugar de tratar el código experimental como software de producción.
Un MVP puede ofrecerse a un grupo pequeño de invitados. No necesita todas las funciones, pero quienes lo usan necesitan una forma de completar la tarea prometida y de obtener ayuda cuando falla.
Pregúntese qué podría convertir en un derroche la siguiente inversión en desarrollo.
No tiene por qué comprar los tres en secuencia. Si el flujo de trabajo ya se entiende y la tecnología está consolidada, un prototipo aparte puede aportar poco. Si una integración imprescindible no puede funcionar, construir antes el resto del producto es el orden equivocado.
Piense en un producto hipotético de reservas. Los clientes deben elegir una cita disponible, recibir una confirmación y modificar la reserva si hace falta. Es un ejemplo ilustrativo, no un resultado de un cliente de AL+.
Un prototipo podría mostrar la selección de la cita, la pantalla de confirmación y el flujo de cancelación. Compruebe si las personas entienden las opciones y si el personal puede usar la vista administrativa propuesta. Las citas y las confirmaciones pueden estar simuladas si se les explica a los participantes.
Una prueba de concepto podría examinar el proveedor del calendario. ¿Puede la aplicación leer la disponibilidad, crear una reserva y reconocer un cambio en conflicto, con el acceso que el negocio puede obtener realmente? Documente qué probó el experimento, el entorno utilizado y qué queda sin probar.
Un MVP podría permitir que un grupo limitado haga reservas reales de un servicio en un local. También necesitaría las reglas pertinentes sobre zonas horarias, conflictos, cancelaciones, acceso del personal y recuperación ante fallos. Un gran panel de informes puede esperar; evitar que dos personas reserven el mismo horario, quizá no.
La decisión depende de la incertidumbre y del resultado prometido. «Solo cinco pantallas» no basta para distinguir esos alcances.
Rellene estas seis líneas. Si no puede responder a alguna, anótela como pregunta abierta en lugar de como suposición.
En el ejemplo de las reservas, un criterio de aceptación podría ser: «Un cliente invitado puede reservar un horario realmente disponible, recibir la confirmación y cancelarlo; el personal ve el cambio». Eso describe el comportamiento del producto. «La app tiene una pantalla de reservas» describe una interfaz y deja sin resolver el trabajo importante.
Use la guía del costo de desarrollar un MVP (en inglés) para comparar estimaciones del mismo entregable con las mismas exclusiones.
Un alcance pequeño no elimina las responsabilidades que crean los usuarios y los datos reales. Identifique cuáles se aplican antes del lanzamiento:
Esos requisitos deben ajustarse a la publicación real. No añada infraestructura para una escala imaginaria, pero no omita una vía de recuperación para la información que no puede permitirse perder. La guía de la fase beta de GOV.UK (en inglés) ofrece un modelo útil: invitar a un grupo limitado, aprender del uso real y planificar la capacidad para sostener ese aprendizaje.
A veces. Primero examine lo que contiene realmente el prototipo. Puede que la interfaz sea reutilizable, mientras que los datos simulados, la autenticación provisional o la configuración solo local deban sustituirse. A veces sale más barato descartar el código escrito para un experimento que hacerlo fiable.
Pida al desarrollador que separe el trabajo reutilizable, el trabajo de producción que falta y las hipótesis sin resolver. Un prototipo creado con IA necesita la misma revisión; una demostración convincente es prueba de que la demostración funciona, no de que el producto esté listo para los clientes.
AL+ ofrece desarrollo de MVP para fundadores que necesitan un primer recorrido completo y una titularidad clara tras el lanzamiento. Envíenos el briefing de seis líneas, cualquier prototipo existente y sus limitaciones de presupuesto o de plazo.
Escriba a AL+ sobre su prototipo o MVP. Podemos hablar de qué entregable responde a la pregunta que usted necesita resolver.
]]>Use esta lista de verificación antes de pedir una propuesta. Le ayuda a comparar lo que entregará cada proveedor, en lugar de comparar precios de interpretaciones distintas de la misma idea.
Escriba una frase: «Un [usuario] necesita [completar una tarea] para que [resultado útil]». Por ejemplo, un responsable de operaciones necesita aprobar una reserva sin copiar datos entre tres sistemas. Es un flujo de trabajo ilustrativo, no un resultado de un cliente.
Enumere a las demás personas implicadas. Un cliente, un administrador y un responsable de finanzas pueden necesitar permisos distintos aunque usen el mismo registro.
Explique el proceso actual, incluidas las hojas de cálculo, los correos y las comprobaciones manuales. Indique el paso que consume tiempo o provoca errores. Incluya un ejemplo anonimizado de los datos de entrada y del resultado esperado.
No envíe contraseñas, registros de clientes ni credenciales de producción en el primer correo. Describa los sistemas implicados; el acceso adecuado se organiza una vez acordado el proyecto.
Elija un flujo de trabajo que un usuario real pueda terminar. Especifique qué lo inicia, qué hace el software y cómo sabe el usuario que ha funcionado. Incluya el caso de fallo: ¿qué ocurre cuando los datos son incorrectos, se rechaza una aprobación o una integración no está disponible?
Ponga todo lo demás en una lista aparte para más adelante. Una primera versión pequeña puede tener menos funciones y aun así necesitar un tratamiento fiable de los datos, control de acceso y una forma de recuperarse de un fallo.
Nombre cada servicio externo, la información que se intercambia y quién controla el acceso. Indique si el proveedor tiene una API documentada y si existe acceso de pruebas. Son preguntas por resolver, no capacidades que dar por supuestas.
Si hay que trasladar datos de un sistema antiguo, describa su formato, su tamaño aproximado, sus problemas de calidad y el período en que ambos sistemas tendrán que funcionar a la vez. La migración es trabajo adicional a la construcción de las pantallas nuevas.
Incluya los límites de presupuesto, cualquier fecha fija y su motivo, la accesibilidad exigida, las restricciones sobre la ubicación de los datos y quién usará el sistema. Si los requisitos exigen asesoramiento legal o de seguridad especializado, identifique quién lo aportará.
En el trabajo remoto, acuerde cómo se registrarán las decisiones, quién puede aprobar el alcance y qué coincidencia de horarios es necesaria. Una decisión estancada puede retrasar la entrega aunque la implementación sea sencilla.
El costo del desarrollo de software depende de los flujos de trabajo, las reglas de permisos, las integraciones, el trabajo con datos y los requisitos de operación. El mismo número de pantallas puede esconder cantidades de trabajo muy distintas.
Pida a cada proveedor que separe el alcance conocido de las suposiciones. Compare estos cinco puntos:
Un precio sin esos límites es difícil de comparar. Esta lista no ofrece un precio universal para un proyecto; una estimación creíble necesita los requisitos reales.
Redacte las comprobaciones en términos del usuario: «Un operador puede aprobar una solicitud, el cliente recibe la actualización correcta y la decisión queda registrada». Defina ejemplos representativos y los errores que el sistema debe gestionar.
Acuerde cómo verá el avance y probará las versiones. Acuerde también quién es titular del repositorio, de las cuentas de infraestructura, de la documentación, del proceso de despliegue y de las copias de seguridad. La lista de verificación del traspaso de software (en inglés) describe los elementos que debería poder recibir.
Su primer correo puede ser breve: el usuario, el flujo de trabajo, lo que existe hoy, la integración importante y sus limitaciones de presupuesto o de plazo. No hace falta una especificación terminada.
AL+ ofrece servicios de desarrollo de software a medida y el código es de su empresa. Escriba a paul@alplustech.com con esos datos para hablar de su proyecto con las personas que lo construirían.
]]>Las reescrituras rara vez se proponen porque el sistema no tenga arreglo técnico. Se proponen porque nadie en el equipo actual entiende el sistema, y reconstruirlo parece la única manera de recuperar ese conocimiento.
Es una motivación honesta. También es la forma más cara de lograr el objetivo. Una reescritura recrea el conocimiento recreando el software, y todo lo que el sistema antiguo aprendió en años de producción, cada caso límite y cada corrección, hay que volver a aprenderlo.
El segundo motivo habitual es la frustración. Los cambios lentos, los incidentes recurrentes y una tecnología desconocida hacen atractivo empezar de cero. La frustración es real. El remedio suele ser que alguien se responsabilice, no sustituir el sistema.
No respondemos a la pregunta de reparar o reescribir en la primera reunión. La respondemos después de una revisión que cubre cinco aspectos.
Qué hace el sistema. No lo que dice la documentación ni lo que recuerda el fundador. Lo que hace en producción, para qué usuarios y con qué frecuencia. Muchas reescrituras se dimensionan según un uso imaginado.
Dónde está el riesgo. Qué partes fallan, qué partes nadie toca y qué partes guardan datos que no se pueden perder. El riesgo suele concentrarse en una parte pequeña del código.
Si se puede cambiar con seguridad. ¿Hay una forma de desplegar un cambio y saber que ha funcionado? ¿Hay pruebas, entornos de preproducción, copias de seguridad y marcha atrás? Si no, eso va primero sea cual sea la decisión final, porque una reescritura sin ello es una versión más grande del mismo problema.
Cuánto cuesta mantener la tecnología. Los frameworks y los entornos de ejecución llegan al final de su vida útil. Las facturas de alojamiento crecen. Para algunas tecnologías es difícil contratar personal. Son costos reales, pero medibles, y a menudo menores que los de una reescritura.
Qué necesita el negocio a continuación. Un sistema que necesita tres funciones pequeñas al año tiene requisitos distintos de otro que debe duplicar su capacidad. La decisión de reescribir depende del destino, no solo del estado actual.
Reparar es la respuesta con más frecuencia de la que los equipos esperan. Las señales:
Reparar significa establecer quién es responsable, añadir una red de seguridad (pruebas alrededor de las partes de riesgo, monitorización, despliegues fiables) y después mejorar el sistema sin sustituirlo, con un cambio acotado cada vez. Los usuarios ven primero estabilidad y después mejoras. No se tira nada hasta que su sustituto ha demostrado funcionar.
Algunos sistemas sí hay que sustituirlos. Las señales son concretas:
Aun así, reescribimos por partes siempre que podemos. Un sistema nuevo que va asumiendo una responsabilidad cada vez del antiguo mantiene el negocio en marcha y mantiene reversible la decisión.
Los cinco aspectos de la revisión anterior se reducen a una tabla pequeña. Puntúe cada fila para el sistema que tiene delante; la columna con más marcas es la recomendación, y un solo «sustituir» en la fila de la plataforma prevalece sobre el resto.
| Pregunta | Apunta a reparar | Apunta a modernizar sin sustituir | Apunta a reescribir o sustituir |
|---|---|---|---|
| ¿La plataforma tiene soporte? | Sí, versiones actuales | Sí, pero varias actualizaciones por detrás | No, y no se puede actualizar |
| ¿El modelo de datos se ajusta al negocio? | Sí | En su mayor parte; algunas estructuras chocan con las funciones nuevas | No; cada función lo rodea |
| ¿Hay una forma segura de cambiarlo? | Sí | En parte; hay pruebas y marcha atrás para algunas partes | No, y añadirlas cuesta más de lo que valen las partes |
| ¿Dónde está el riesgo? | Concentrado en dos o tres módulos | Repartido en una capa que se puede sustituir por separado | En todas partes; no hay un diseño coherente que conservar |
| ¿Cuánto se sigue usando? | La mayor parte | La mayor parte, con zonas muertas que eliminar | Una minoría; el resto atiende casos que ya no existen |
| ¿Qué necesita el negocio a continuación? | Funciones pequeñas y estabilidad | Una capacidad nueva importante sobre los mismos cimientos | Un producto distinto |
Reparar es mantenimiento con un plan. Modernizar sin sustituir es nuestro servicio de reparación y modernización. Una reescritura también se hace por partes siempre que podemos, con el sistema antiguo funcionando hasta que cada pieza haya demostrado su valía.
Entender el sistema, lograr que sea seguro cambiarlo y después decidir. Los equipos que saltan directamente a la reescritura se saltan la parte en la que aprenden qué están sustituyendo, y ese conocimiento es lo más caro de reconstruir.
]]>