Maldivas – Implantación

Hace ya casi un año que Maldivas comenzó a funcionar, me gustaría deciros que todo el proyecto ha sido un camino de rosas y que todo ha funcionado a la perfección, sin embargo en estos últimos años hemos luchado lo indecible para sacar este proyecto adelante.

Por el camino y a pesar del conocimiento de muchos de los problemas que se producen en el desarrollo de un proyecto y aunque no es intención de este post buscar responsabilidades, si me gustaría comentar que hemos vuelto a cometer muchos de los errores que se pueden realizar en una gestión de proyectos (si no todos), estimaciones erróneas realizadas por personas ajenas al desarrollo, constantes interrupciones, múltiples cambios de contexto, problemas con la arquitectura y con las herramientas de trabajo, problemas con el equipo de desarrollo, decisiones como dejar de lado la calidad para intentar hacerlo más rápido, muchas horas de trabajo sin descanso, etc.

Maldivas 1

Maldivas – Erp

La parte positiva es que hemos aprendido de primera mano la importancia de una buena gestión de proyectos, de la utilización de pruebas unitarias, de la aplicación de reglas con herramientas como FxCop y ReSharper que tanto nos han ayudado, de la utilización de algunos patrones de diseño, de la importancia de las reglas de estilo en un equipo de trabajo, de la aplicación de metodologías de trabajo, de la automatización de procesos, de las ventajas de una formación continua y sobre todo, de la importancia de la colaboración entre todas las personas que participan en el proyecto.

No tiene sentido hablar del éxito o del fracaso del proyecto, ya que en este apartado y aunque me pese en cierto sentido, son los usuarios los que han de responder a esta cuestión, también aquí hemos tenido diversidad de opiniones, desde los que dicen que es una maravilla respecto al sistema anterior, algunos que no notaron ningún cambio o aquellos que argumentan que a pesar de las mejoras prefieren sin lugar a dudas el sistema de gestión antiguo. Todas las opiniones son válidas y debemos valorarlas, es importante entender que a lo largo de un proceso de desarrollo, todos cometemos errores y estos deben ayudarnos a mejorar, recuerdo el Sprint Retrospective basado en la mejora continua.

Un aspecto que si he aprendido en este proyecto es el relativo al equipo de trabajo, casi siempre diferenciamos el equipo de desarrollo (‘los raritos y frikis de la empresa’) de los demás, pero aquí más que en ningún otro proyecto en los que he trabajado, he aprendido la importancia que tiene el hacer partícipes a todas las personas del proyecto desde el inicio y que quizás, es mejor pararse o no hacer algo si no contamos con el suficiente apoyo e implicación de estos. Si alguien piensa que tener un buen equipo de desarrollo es garantía de éxito en un  proyecto es que no tiene ni idea de lo que está hablando, el cliente es parte indivisible del equipo, podemos tener un equipo de desarrollo de nivel medio y un cliente que colabore con nosotros y nos aporte feedback para mejorarlo, si tuviera que elegir apostaría siempre por lo segundo. Sin colaboración no hay proyecto posible, da igual lo buenos o malos que sean los desarrolladores, será un fracaso total, al menos hasta el día que estos puedan leer la mente del cliente, que pensándolo bien, quizás con mi Kinetic y aplicando cierta técnica Jedail todo es posible…

Maldivas - Stocks

Maldivas – Erp

Respecto a los usuarios, muchos realizaron su trabajo correctamente lo que nos permitió anticiparnos y resolver los problemas al finalizar cada entrega, mucho antes de la puesta en funcionamiento del sistema, de esta forma su transición fue mucho mejor, sus problemas minimizados y algunos mejorados porque nos aportaron Feedback, los costes fueron menores pues los abordamos en el momento adecuado. Sin embargo, otros usuarios alegaban tener una carga de trabajo alta, lo que les impedía destinar tiempo a comprobar y testar sus aplicaciones al finalizar cada sprint, algunos por diversos motivos creían que sus atribuciones no eran la de testar los módulos con los que iban a trabajar y otros pocos simplemente pasaban de hacerlo. Por supuesto para este segundo grupo, la transición al nuevo sistema fue mucho peor, corrijo, ‘para nosotros fue mucho peor’, ya que tuvimos que trabajar más horas en corregir aquellas incidencias no detectadas para que estos pudieran realizar su trabajo a tiempo, ha veces tuvimos que modificar ciertas reglas de negocio que afectaban a muchos módulos relacionados y tuvimos que abordarlas en un tiempo muy limitado.

Un aspecto en el que también sufrimos fue la migración de datos que comenzamos al inicio del desarrollo utilizando Data Transformation Services y que finalmente tuvimos que abandonar para utilizar scripts ya que las reglas de integridad y los cambios constantes en las estructuras hicieron de la migración un problema muy complejo que abordar. Finalmente conseguimos realizar una actualización completa de un sistema a otro, que pudimos ejecutar varias veces hasta poner en marcha el proyecto, esto mejoro también el testeo de los usuarios ya que podrían hacerlo con datos reales un factor importante a tener en cuenta en futuros desarrollos, logramos hacer la migración completa sin que ningún usuario introdujese ningún dato, todo un logro para un sistema con más de 500 tablas.

Maldivas - Proformas

Maldivas – Erp

Sigo pensado que la presión en el trabajo no hace que este mejore sino todo lo contrario, nos hace equivocarnos y cometer más errores. Creo que este debe ser un aspecto a reflexionar con detenimiento, algo que también he observado aplicando Scrum y es la presión que ha veces se ejerce al finalizar cada Sprint, a veces, si la estimación no es adecuada hace que esta aumente cuando el equipo de desarrollo trata de finalizar cada Sprint, es importante tratar de mejorar en las estimaciones para que estos cada vez se adapten mejor, aunque muchas veces cuando hacemos algo nuevo de lo que no tenemos información es ciertamente difícil acertar, debemos recordar que en el Sprint Review también se analizan aquellas tareas que por los motivos que sean no han podido ser finalizadas y trabajar en disminuir la presión del equipo de desarrollo, esta solo nos entorpece y bloquea.

Al final, mucha de la parafernalia de una gestión de proyectos ya sea utilizando Scrum, CMMI o cualquier otra metología se puede resumir en una sola palabra ‘confianza’, la mayor parte de lo que hacemos solo sirve para justificar ante nuestros clientes nuestro buen hacer, me pregunto, si tuviéramos confianza plena, ¿Sería necesario esforzarse tanto para tener una buena gestión de proyectos?, seguro que se pueden argumentar mil y una razones para hacerlo, que si queremos controlar su coste o conocer las desviaciones, que si los requerimientos deben quedar claros, etc., etc., pero no nos engañemos, la respuesta es ‘no’. Lo cierto es que los desarrolladores no ofrecemos demasiada confianza y esto es porque hay algo que todavía no hacemos bien. Estoy convencido de que la confianza de un cliente, debe basarse en entregas constantes de software, estas entregas son las que deben convencer al cliente, si no hay entregas, que más dan los análisis, la documentación y todo el trabajo que hayamos realizado, las entregas demuestran nuestro trabajo, hay algo que funciona y que hemos terminado, que a veces el cliente puede comenzar a amortizar y a utilizar mucho antes de que el proyecto finalice, que esta abierto a mejoras con la aportación del feedback, minimizando los costes al asumir cambios de forma temprana, que mejor demostración de nuestro trabajo que la entrega de software, aunque lo cierto es que también hay clientes complicados, pero bueno, el mundo no es perfecto.

Maldivas - Centros

Desde la puesta en marcha del proyecto, a pesar de las pruebas unitarias y del trabajo que hemos realizado por escribir código de calidad, se han resuelto más de 1600 incidencias y se han realizado unas 800 nuevas propuestas de mejora. Día a día continuamos progresando y adaptando el sistema a nuevas especificaciones. Debemos recordar que las pruebas unitarias no garantizan el correcto funcionamiento de un programa, existen muchos tipos de pruebas mas que debemos abordar para que una aplicación funcione correctamente, la aportación de la visión de los usuarios es siempre indispensable para asegurar un correcto funcionamiento, es muy difícil simular todo aquello que puede hacer un usuario con un programa y si encima es lunes o ha bebido un par de copas la cosa se torna imposible… 🙂

Hemos aplicado diversas tecnologías, como sabéis, nuestro modelo de datos está basado en entidades POCO, utilizando un data-mapper propio basado en generics y reflexión, lo cierto es que si hubiéramos contado con Entity FrameWork nos hubiéramos ahorrado un montón de trabajo pero así es la vida unas veces por delante y otras muy por detrás, pensar que un proyecto que nos ha llevado varios años y finaliza en Windows Forms, una tecnología actualmente en ‘desuso’, me entran hasta escalofríos de pensarlo, aunque supongo que en la mayoría de proyectos a largo plazo esto es así.

Maldivas - Capacidad

El desarrollo se comenzó en el 2006 con VS 2005 y se ha finalizado con VS 2010, aunque actualmente ya funciona con VS 2012, utilidades como FxCop, ReSharer, CodeRush, Stylecop, Pex and Molex, Visual Studio for Database Developers, nos han ayudado mucho a mejorar la calidad, como gestor de proyectos hemos utilizado TFS, hemos integrado la suite de controles de Devexpress, Sql Server como servidor de base de datos e IIS 7 como servidor web. Hemos implementado procesos en segundo plano utilizando programación asíncrona, paralelización, cache, Servicios Windows, Servicios web, Linq, Serialización de archivos, etc.

Maldivas - Planificacion

La aplicación tiene múltiples opciones Gestión de usuarios y permisos, enlaces con Office Outlook, Excel y Word, Gestor documental, Estructuras de fabricación, Gestión de órdenes de trabajo, Planificación en base a la demanda basada en sistemas Lean Manufacturing, , Multiempresa con bases de datos diferentes, Generación automática de asientos contables, Gestión de rutas, Enlaces bancarios norma 58 y Gestión de remesas de Confirming, Generación automática de asientos contables, Scheduler, Envió de información automatizado, Gestión de costes, Modulo de consultas y estadísticas, Diseño de Informes por usuarios avanzados, Gráficos interactivos, Cubos OLAP, Picking a través de dispositivos móviles, Comercio electrónico y muchas de las opciones que se integran en un ERP, desde el control de stocks, pasando por la Calidad, Compras, Ventas, Financiera, Recursos Humanos, etc.

Y para el futuro… pues Maldivas continuara creciendo y actualizándose, nos quedan muchas mejoras que realizar, intentaremos aumentar la cobertura de código con pruebas unitarias, integración con Sharepoint, desarrollo de parte del sistema de producción, aumento de las aplicaciones con Dispositivos móviles y porque no, quizás hasta alguna aplicación en Tablet, migración del sistema de comercio electrónico a ASP MVC, introducción de EF como modelo de entidades, creación de y adaptación de formularios en WPF, etc.

Aprovecho este post para dar las gracias especialmente a mi compañero Eduardo Obregon, que tanto me ha aguantado, sobre todo en los momentos difíciles de estos últimos años y que gracias a su calidad personal y trabajo ha contribuido a que este proyecto fuera posible, a los usuarios que nos han ayudado aportando Feedback y que han contribuido con sus ideas a mejorar este programa, a mi jefe que siempre me ha escuchado y con el que he podido discutir abiertamente de mis problemas y aquellas personas que siempre han confiado en que pese a los problemas y el tiempo invertido lograríamos realizar este proyecto del que más de una vez pensé en abandonar.

Bueno, si habéis llegado hasta aquí, (vaya rollo que os he contado), espero que al menos echéis un vistazo a unos videos que diseñamos para formación interna que os permitirán haceros una idea del proyecto. Todos los datos del video de formación son ficticios. Se realizaron pensando en que la mayor parte de los usuarios no disponía de tarjeta de sonido sin audio, pero tienen subtítulos que podéis activar desde el menú inferior de YouTube, también os aconsejo subir la resolución para visualizar correctamente el video, estos se han filmado en 1280 x 800 aunque la resolución óptima del programa es de 1440 x 900, así que algunos formularios se verán bastante comprimidos.

Video 1 – Maldivas – Características generales

La primera versión del sistema de terminales se desarrolló en el 2002 con Compaq Framework Beta 1, este ha sido adaptado para su integración con Maldivas

Video 2 – Maldivas – Terminales móviles

Video 3 – Maldivas – Terminales gestión

La primera versión del sistema de comercio electrónico se desarrolló en ASP.Net 2.0 en el año 2005 y actualmente estamos trabajando para su integración completa en Maldivas con ASP Mvc.

Video 4 – Maldivas – Comercio electrónico

Espero que os gusten y os aporten alguna idea en vuestros desarrollos.

 

Para adaptar la configuración en Youtube:

clip_image001

El icono amarillo muestra donde activar la resolución.

clip_image002
El icono amarillo muestra como activar los subtítulos.

12 comentarios sobre “Maldivas – Implantación”

  1. Gracias a ti Juan por todo lo que me has enseñado, por encima de tecnologías, a aprender a solucionar problemas, sin duda he sido un privilegiado de estar estos años trabajando contigo.

  2. Enhorabuena Juan!!!! Aunque no haya sido un camino de rosas los que te conocemos sabemos el empeño y buen hacer que has puesto en este proyecto.

    Un saludo.

  3. @Edu, se que en el fondo de tu corazón me odias profundamente, pero aunque sea todo mentira y te hayas visto obligado, te agradezco tu comentario. 🙂

  4. Joder, impresionte!!! el trabajo que habéis realizado, una pregunta, en el modelo de entidades que utilizáis como generáis las entidades, ¿ las escribís una a una ?

  5. Para generar las entidades creamos un generador basado en codedom, puedes mirar en otro post que escribi hace tiempo acerca de esto http://geeks.ms/blogs/jirigoyen/archive/2008/11/13/maldivas-arquitectura-2-entidades-y-reflexi-243-n.aspx, en cualquier caso lo hicimos porque en su día no disponiamos de Entity FrameWork, hoy en día puedes generar entidades Poco facilmente utilizando este gestor, que te proporcionara grandes ventajas frente a un modelo de datos como el nuestro.

    Un saludo y gracias por comentar.

  6. @juan, en 1er lugar felicitaciones, siempre es un placer leer a gente que escribe sobre como un equipo de trabajo mejora día a día 😀
    en 2do lugar, felicitaciones again !!! ^^

    Salu2

  7. Enhorabuena,una visión muy completa del desarrollo y su evolución en el tiempo.

    Técnicamente muy variado, VS 2012, utilidades como FxCop, ReSharer, CodeRush, Stylecop, Pex and Molex, Visual Studio for Database Developers, TFS, Devexpress, Sql Server , IIS 7
    CodeDom (http://geeks.ms/blogs/jirigoyen/archive/2008/11/13/maldivas-arquitectura-2-entidades-y-reflexi-243-n.aspx)
    programación asíncrona, paralelización, cache, Servicios Windows, Servicios web, Linq, Serialización de archivos, etc.

    Se agradecerán artículos de detalles técnicos, da sin duda, una visión muy completa.

    Saludos.

  8. @Kinetic, gracias por tus comentarios, he hablado en algunos post anteriores sobre algunas partes de la Arquitectura de Maldivas, sin embargo debido a que nuestro modelo de datos es propio y fue desarrollado en una época en la que solo podías utilizar arquitecturas basadas en Ado 2.0 o herramientas de terceros como n-Hybernate, no he querido hablar en detalle de la aplicación, pues nuestra capa de negocios esta acoplada a nuestra capa de datos y no me gustaría confundir a los lectores con estos detalles. Tengo pensado realizar algún post sobre algunos módulos interesantes que hemos desarrollado como el ‘Scheduler’ que permite configurar envíos de información recurrente a diferentes destinatarios como informes de ventas, avisos, estadísticas, tarifas, etc.

    Un saludo.

  9. @Kinetic, yo no creo en los Framework Generalistas, se deben valorar mucho dependencias, nosotros desarrollamos Maldivas para dar solución a un sistema y unas necesidades muy concretas, el atarnos a diferentes herramientas aunque sean libres y gratuitas tiene su riesgos, en este caso apostamos por utilizar el FrameWork de .NET y un desarrollo propio.

    Te aconsejo la lecturas de estos dos post, donde se habla de este tema a consecuencia de un comentario de Julio Trujillo:

    geeks.ms/…/maldivas-arquitectura-1-el-sentido-com-250-n.aspx

    geeks.ms/…/el-requeteframework.aspx

    Un saludo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *