¿Quién debería aprender el "viejo" sistema?

Question

He estado involucrado en varios proyectos que básicamente involucraron el reemplazo de un sistema "antiguo" con un "nuevo" sistema. Invariablemente, el patrón ha sido que prácticamente nadie en el equipo que construye el "nuevo" sistema tiene ningún conocimiento real del "viejo" sistema. Cada vez que cuestioné esto, me dijeron que esto tiene un propósito ... al no conocer el "viejo" sistema, el equipo puede pensar de manera diferente y no estar limitado por cómo se hicieron las cosas allí. Entonces, lo que sucede es que generalmente hay solo 1 o 2 personas en el equipo que saben algo sobre el "viejo" sistema y se les consulta cada vez que surge una pregunta sobre cómo el "viejo" sistema hizo algo.

Pero lo que siempre parece suceder es que después de que se entregue el "nuevo" sistema, siempre hay preguntas del usuario de la forma "¿Cómo hacemos X (que era fácil en el sistema anterior) en el nuevo sistema ? " Para los desarrolladores, esta es a menudo la primera vez que oyen hablar de X. Por lo tanto, tienen que investigar qué es X y, a menudo, la respuesta que les dan a los usuarios es "no se puede" o "se puede", pero es realmente incómodo ".

Esto no me parece correcto ... me parece que se ganaría mucho si todos los desarrolladores del "nuevo" sistema conocieran bien el "viejo" sistema, y ​​eso no necesariamente mataría su creatividad, si tienen un diseño decente y habilidades de desarrollo.

¿Alguna idea de qué enfoque es el mejor?

Answer 1

Sustitución de un sistema antiguo por uno nuevo implica generalmente iso-funcionalidad (es decir, la capacidad de hacer por lo menos lo que el viejo sistema era capaz de hacer)

Así, mientras que un conocimiento profundo del sistema antiguo no es obligatorio, conocer las interfaces y construir un conjunto de suites de pruebas funcionales es útil para desarrollar eficientemente el nuevo sistema.
Ese conjunto va a ser utilizado para la validación de los resultados del nuevo desarrollo, teniendo en cuenta que el resultado nunca debe ser del 100% (de lo contrario, tendría éxito reproducido los errores del primer sistema!)

Además, para un sistema muy grande, se necesitan al menos tres implementaciones para su nuevo programa:

• nadie capaz de dialogar con el viejo sistema
• una sustitución de partes de la antigua
• uno completo de tomar sobre el programa antiguo

Si hablamos de un gran período de tiempo, eso implica también un arquitecto capaz de gestionar la evolución del sistema anterior (que no puede quedarse quieto, esperando varios meses o años antes de que el nuevo lo reemplace), manteniendo esas evoluciones en la misma dirección que su nueva implementación.

Answer 2

Necesita mejores analistas comerciales. Ellos son los que deberían revisar el sistema anterior y definir exactamente (y completamente) lo que el nuevo sistema debe hacer. Deben proporcionarle una lista completa de requisitos para que todo lo que deba suceder se haya tenido en cuenta.

Quien escriba los requisitos debe ser más completo. Si eso no es posible, entonces es posible que deba involucrarse y aprender el 'viejo sistema'.

Sin embargo, siempre se perderán cosas, así es la naturaleza humana. Obviamente, deberías tratar de hacer que el 'nuevo sistema' sea lo más flexible posible, de modo que se puedan agregar características necesarias cuando los usuarios se den cuenta de que han sido olvidados.

Entiendo tu dolor.

Answer 3

Parece que la especificación para el nuevo sistema era incompleta porque alguien (el gerente del proyecto, el iniciador del proyecto) no se aseguró de documentar y verificar la funcionalidad del sistema anterior para ver lo que el cliente realmente usaba.

Si esto se hace, entonces no debería importar que nadie conozca el sistema anterior, ya que la especificación es algo contra lo que se está desarrollando.

Si no tiene una especificación, además de todos los otros problemas que tendrá, todos deben conocer el sistema anterior para evitar este problema.