Cambió el mundo del cliente: ¿cómo manejamos esto?

Hace algún tiempo, nos encargaron un proyecto para entrar y reemplazar el antiguo sistema Mainframe de un cliente con una nueva solución ASP.NET de intranet que utiliza SQL Server como back-end. Parte de esto fue también una reingeniería del negocio: esencialmente, a medida que cambiamos el sistema, pensamos en cómo podemos hacer mejores negocios.

Entonces, la primera tarea era entrar y hacer los modelos de datos lógicos y luego físicos. El cliente estaba involucrado en estas discusiones y tenía un cierre completo. La siguiente fase fue hacer el diseño y la construcción de cada módulo. Bueno, para resumir, la programación se ha realizado y ahora estamos en pruebas paralelas del sistema. Las cosas están yendo maravillosas para la mayoría de los módulos hasta ahora, excepto uno.

Tenemos un sistema donde: si solo permitiera que los usuarios comerciales vieran la aplicación y los informes, todo estaría bien. Funciona con el nuevo flujo de trabajo integrado y automatiza procesos previamente manuales y funciona muy bien según las especificaciones. Sin embargo, las pruebas paralelas han descubierto algunos problemas con los datos heredados migrados. Los creadores del sistema heredado están teniendo dificultades para comprender el nuevo esquema y el proceso comercial, por lo tanto, están teniendo dificultades para comprender cómo tomar los datos heredados y ponerlos en el nuevo esquema. Debido a esto, están convocando a reuniones de usuarios comerciales y partes interesadas y diciéndoles que el nuevo sistema no proporciona datos que el sistema anterior proporcionó (cuando realmente lo hace); esto hace que el nuevo sistema se vea mal.

Esto es frustrante, por decir lo menos. El nuevo sistema funciona muy bien y proporciona todo lo que necesita y desea, y si no fuera por la incapacidad del personal de TI de completar las nuevas tablas con los datos antiguos, los usuarios comerciales estarían contentos con las nuevas características y funcionalidades.

Estoy pidiendo sugerencias sobre cómo manejar esto. Debido a algunos movimientos políticos, el nuevo "arquitecto" no tiene idea de cómo funciona el sistema y no puede comprender completamente las ramificaciones de los cambios que solicita el personal de TI. El personal de TI quiere algunos cambios fundamentales en el sistema, que son esencialmente innecesarios y en realidad son un mal diseño, pero SON el cliente.

¿Alguna idea?

Su equipo necesita hacer la conversión de datos por ellos. Realmente deberías haberlo hecho por ellos en primer lugar.

He estado involucrado en varias migraciones de plataformas costosas y el proveedor siempre, siempre tiene su propio equipo de conversión de datos que es responsable de comprender el sistema heredado, escribir todos los scripts de migración, hacer todas las pruebas y, en general, asegurarse de que todo hace lo que se supone que debe hacer.

Algunas compañías pueden tener un personal de TI brillante que puede hacerlo por sí mismo. Otros pueden afirmar que pueden hacerlo ellos mismos, pero en realidad no pueden. En este último caso, debe ser lo suficientemente humilde como para sentarse, pero también debe estar preparado para intensificar si la gerencia decide que el equipo interno no está haciendo un trabajo lo suficientemente bueno.

Este es su sistema y su implementación. Usted y usted solo son responsables de asegurarse de que tenga éxito. No espere que el cliente pueda hacer ninguna parte de esto por sí mismo. Solo si insisten absolutamente en hacer esta parte ellos mismos, incluso debe considerar esa opción, y en ese caso, debe cubrirse los traseros: debe haber algo en el contrato que diga que si eligen hacerlo ellos mismos, entonces son responsables por su resultado.

Pueden pagarle para cuidar a su equipo si lo desean, y pueden pagarle para comenzar de nuevo si lo desean, pero no desperdicie ciclos innecesarios sin algún tipo de acuerdo. Especialmente si tiene un contrato por tiempo limitado o costo fijo, esta situación es la muerte.

El punto es que, como usted dice, son el cliente, lo que significa que no funcionan para usted. De hecho, si eres un cínico como yo, podrías sospechar que algunos de ellos están trabajando activamente contra ti para mantener su seguridad laboral. Confiar en el cliente para realizar cualquier parte de su implementación es un error.

Si tiene que contratar un par de esclavos de ingreso de datos de salario mínimo para realizar la conversión de datos manualmente , hágalo. Cualquier cosa para volver a poner el resultado en tus manos.

Ellos son los que pagan las cuentas, así que al final tienes que darles lo que están pidiendo a pesar de que no sería la mejor solución y un paso atrás.

Sin embargo, debe tener en cuenta que quizás las personas que solían usar el mainframe tienen razón. Mi esposa solía trabajar para un banco donde usaba algún sistema mainframe para ingresar varias transacciones financieras usando cientos de diferentes tipos de códigos. Era esencialmente su propio mini idioma. Cuando el banco gastó millones de dólares implementando un sistema basado en GUI que redujo en gran medida la complejidad y los pasos involucrados, descubrieron más tarde que la productividad se desplomó y nunca volvió a subir.

El hecho es que, si bien el sistema mainframe era innecesariamente complicado y tenía una curva de aprendizaje alta, eran MUCHO más rápidos que el sistema GUI porque se volvieron expertos en ingresar cientos de transacciones por hora simplemente escribiendo rápidamente en un teclado. Condujo a un rechazo masivo por parte de la base de usuarios y el proyecto fue descartado como un completo fracaso. Productividad devuelta.

La moraleja es, no descarte por completo las preocupaciones de los clientes. Tome sus consideraciones en serio y pregúntese si la solución que está brindando satisface las necesidades de TODAS las partes interesadas.

ellos que el nuevo sistema no proporciona datos que el sistema anterior sí (cuando realmente lo hace).

Deberías tomar esto MUY en serio ...

Entonces:

1) Asegúrate de que estás trabajando con los chicos de Legacy para resolver todas tus preocupaciones.

2) Asegúrese de comprender completamente lo que dicen que falta y por qué es necesario. Trabaja con los tipos heredados para asegurar esto. Luego RESTABLEZCA el problema y pídales que digan "Sí, esa es nuestra preocupación".

Si está de acuerdo con sus preocupaciones, entonces:

3) Luego proponga una solución, obtenga la entrada \ validación \ de los equipos heredados de la solución.

4) Proceder con medidas correctivas.

Si no está de acuerdo con los chicos de Legacy y cree que sus preocupaciones no son válidas, entonces:

3) Exprese sus preocupaciones a la gerencia que usa el mismo lenguaje que los Legacy Guys dijeron que era correcto. Y haga que la Administración decida dónde o no debería preocuparse por ello.

"Los muchachos heredados temen que XXX, no estoy seguro de que sea un problema por AAAA. ¿Están en lo cierto en lo que concierne?"

Sugiero un gran correo electrónico asfixiante de pánico, golpee a todos los asociados, no solo a su administración. Sea breve y conciso.
2 puntos:

1) Podemos abordar sus inquietudes en una reunión / llamada telefónica (proponer una hora)

2) Tenemos total confianza en el sistema tal como está sin la molestia y el gasto de cambios adicionales

Parece que tiene una lista de sus preocupaciones y puede revisarlas punto por punto en la reunión. Solo necesita detener el pánico, dejar que se enfríen un poco y luego golpearlos con la verdad. Incluso ofrezca entrar y ayudar con la asignación de datos antiguos a nuevos. Si todavía exigen cambios ... bueno, es su dinero.

Primero, quiero señalar que, si bien la sección de TI puede ser su interfaz, el cliente real NO ES la sección de TI, sino el negocio para el que trabaja la sección de TI. Hacer algo que perjudique al negocio para apaciguar a TI no sería un buen servicio.

Siéntate con TI, informalmente. Cómpralos donas. Asuma el papel de alumno ante su maestro y pregúntele "¿Qué tiene de malo nuestro diseño de software?" Escuche tanto lo que dicen como lo que no dicen. Es posible que tengan un punto que se haya pasado por alto en las especificaciones originales o que tengan preocupaciones basadas en problemas pasados. Por otra parte, podrían estar reaccionando debido al miedo a algo nuevo. Pero el punto es que si conoce sus objeciones íntimamente, está en una mejor posición para lograr un resultado positivo y responder a sus objeciones.

Usted mencionó que el problema estaba en la migración de datos del sistema heredado al nuevo sistema. Si la sección de TI tiene problemas para migrar los datos, consideraría crear una pequeña herramienta para hacerlo de manera rápida y limpia.

Consulte con el personal de TI de su cliente para respaldar la migración de los datos antiguos al nuevo sistema. Alguien de su empresa que entienda el nuevo formato de datos debería ir físicamente allí y ayudar a los técnicos de TI a realizar la migración.

De esa manera, esperamos que puedan enseñar a los técnicos de TI sobre el nuevo sistema, que los datos se migren correctamente y que su implementación sea más fluida.