Haciendo una pausa respecto a mis temas actuales, quiero dejar en este post y compartir con ustedes algunas experiencias ganadas,  aprendizajes y lineamientos  respecto a los dolores y sufrimientos que esos enormes proyectos IT en los que he participado alguna vez me han dejado (Grandes lecciones). Pero antes de iniciar la revisión de cosas a evitar en grandes proyectos IT (aquellos con mas de 1 año de duración) las preguntas básicas son:  Es hoy en día aconsajable abordar un gran proyecto informático?. Por otro lado, estamos utilizando la forma correcta de enfrentar estos tipos de proyectos?. Sin duda hay ocasiones en que las problemáticas y operatorias de una gran empresa en ciertos momentos críticos del desarrollo organizacional fuerza el abordar este tipo de proyectos. En lo personal soy partidario de evitar o dividir estos mega proyectos por el riesgo que con llevan. Pareciera ser que contra mas grande es un proyecto IT mayor es la probabilidad de convertirse en un fracaso. Y esto no debería ser sorpresa para nadie. Así, en una empresa normal en el periodo de un año, sin mediar proyectos y a la velocidad en que los mercados se mueven hoy en día. Se producen múltiples cambios de personal, de tecnologías, cambios normativos, políticos, coyunturales, económicos, etc. Y aun así estos mega proyectos IT o Proyectos IT-VL (Very Large) como yo los denomino, se siguen emprendiendo y sobre ellos poco se a escrito. Permitame indicar algunos tips y mas preguntas al respecto, después del link…

A) Es el porque, el correcto?

Supongamos un proyecto de IT, cuya gantt es de 3 años de desarrollo en base a una tecnología X, con cierto nivel de desarrollo y muy prometedora. La tecnología principal a usar en el proyecto es publicitada por los grandes compañías de informática y apoyada por expertos como algo con un futuro prometedor. Ademas, el proyecto se apoya en las tradicionales herramientas, metodologías y áreas de desarrollo de software, así como en plataformas de Hardware, Bases de Datos, Diagramas de Procesos, Cluster o arreglos de discos y de servidores para la infraestructura de datos, redes, etc.  Asumamos también un gran equipo de desarrolladores para los periodos Pick de codificación que pudiesen llegar a una centena de programadores sin contar ademas los analistas,  Managers, etc.

Este tipo de mega proyectos IT que justifiquen tamañana inversión (Varios pares de US$ Millones) necesitan en su promesa final ante directorios o dueños para promover ventajas y beneficios suficientes que promuevan tamaña aventura. Podemos citar entre estos los siguientes:

• Reducir costos de administración y de operación de los sistemas core (reducir la planta de personal IT y contar con costos de mantencion y operación menores)
• Continuidad del negocio – el sistema actual ya no da para mas y requiere un alto nivel de procedimientos manuales con riesgo operacional alto (pero el sistema legacy aun funciona)
• Aprovechar tecnologías innovadores actuales para generar una diferenciación respecto a la competencia en la eficiencia y rapidez de ofrecer los servicios actuales y futuros.
• Contar con sistemas core altamente adaptables a normativas cambiantes y a mercados en evolución.

Lo mas probable es que sea una mezcla de los puntos anteriores la promesa del Gerente IT, CIO o como se llame en dicha empresa, hacia el directorio y/o dueños. Este punto lo dejo de manera explicita pues es el que finalmente junto a los plazos comprometidos iniciales indicaran finalmente si el proyecto es o no exitoso, o si por el contrario fue un fracaso.

Lo anterior respecto a la pregunta A) sin embargo es lo básico y los argumentos citados anteriormente no responden al porque, en un sentido profundo. Esto es, cual es la creencia y no la necesidad que impulsa tamaña aventura? Por supuesto dependerá de la misión de la empresa y de las creencias de sus directores. Quiero mencionar este punto en particular ya que debe ser el lineamiento base que fije las conductas responsables cuando las externalidades, problemáticas o desafíos nuevos se presenten en el andar del proyecto. Por sobre todo. Consecuencia. Para un liderazgo correcto.

B) Es el como, el Correcto?

Esta gran pregunta es la que mas dudas a despertado en el ámbito de la creación de tecnologías o productos como software o aplicativos. Considera el contexto. Las IT en lo que se refiere a su administración y gestión de proyectos es una disciplina basicamente juvenil (en el mejor de los casos). Las metodologías o formas para confección de infraestructura, como puentes, construcciones, etc. Tienen centenas y décadas de experiencia acumulada. Y en las ultimas décadas esa experiencia se ha normalizado en iniciativas y metodologías que han nacido bajo el amparo de este tipo de creaciones. Es así como las metodologías predictivas tales como PMI han irrumpido fuerte en el área de las IT, y sin duda han ayudado a poner orden en el caos original. Son sin duda la base para partir. Sin embargo nosotros no construimos puentes, construimos aplicativos, software algo básicamente intangible y representativo de conocimiento y procesos. En la ultima década un movimiento original en base a metodologías ágiles, para ponerles un nombre común han irrumpido fuerte en la forma de construir software y han presentado ventajas indiscutibles en el desarrollo de software.

Por otro lado la base de la información que soportara el sistema normalmente se encontrara en un modelo relacional clásico SQL. No obstante y tal vez por una formación académica de visión estrecha, en muchos casos he visto como por doctrina y ortodoxia teórica se terminan sistemas con modelos de datos de mas de 1500 tablas. Algo que a todas luces repercutirá en los costos de mantencion post salida al aire del sistema. La dificultad y errores a corregir y la dinámica de estas operaciones de manutención que se presentan cuando se administra tamaño nivel de tablas y entidades en las etapas de explotación del sistema (cuando se requieren pequeñas adaptaciones mínimas demandadas por el negocio) oculta finalmente el real TCO del proyecto. Los fundamentos que he escuchado en el tiempo que explican semejante nivel de entidades son los siguientes:

• “Hemos separado las entidades y normalizado el modelo a fin de dar la mayor flexibilidad posible de forma que soporte toda posible futura variación”.
• “El contrato indicaba que el modelo del sistema debía ser altamente flexible en el manejo de la información”
• “Menos entidades implicaría tener tablas que comparten información de mas de una entidad, y eso no corresponde a un modelo SQL normalizado”
• “Menos entidades implicaría repetir información en mas de una entidad y esto conlleva un mayor consumo de espacios en almacenamiento”

Todas estas explicaciones son validas para un sistema que no tenga mas de un centenar de tablas como mucho. Pero mas halla de esto lo que para un escenario era correcto para otro ya no necesariamente lo es. Analizemos los hechos:

De que me sirve tener 1500 tablas si desde el punto de vista de la flexibilidad tendre que tener absoluta claridad sobre que hace cada una de ellas. Tema no menor que impactara el area de documentacion. Pero mas halla que eso vea en la practica cuantas tablas o entidades es posible que un manager o programador senior del sistemas tenga en su cabeza. En lo personal creo que una excesiva normalizacion del modelo es inoperante y no eficaz cuando tenemos semejante nivel de entidades, puesto que lo que sale barato a nivel del modelo de datos. Se traspasa directamente al nivel de codificacion de aplicativos, a la revision de los mismos y a sufrir con un modelo enorme.

Por el contrario imagine que su modelo cuenta con un numero menor de entidades, algunas decenas como mucho, algunas normalizadas y otras no. Pero altamente entendibles. Entonces lo que hay que evaluar en este punto es: Que es mas adecuado?, pagar el costo de un altertable para modificar el modelo?, trabajar con un modelo semi-normalizado pero mas pequeño?,agregar una entidad mas cuando se requiera al modelo? o contar con un modelo enorme que contempla muchos escenarios futuros pero tal vez no todos y ciertamente mas costoso a la hora de generar nuevos aplicativos.

“NOSQL”: Sabe usted que base de datos SQL usa FaceBook o Google o enormes sistemas de administración de información de la era Web actual?. Se sorprendería saber que muchos ya no usan SQL. FaceBook  y Google usan tecnologías NOSQL con sistemas de repositorios de información no relacional. Pensados para volumnes de data enormes. La tecnología ”NOSQL” esta emergiendo a pasos agigantados y soluciones como MongoDB entre otras traerán aire fresco a la estructuras de datos de grandes proyectos.

C) Es el que, el Correcto?

Estamos usando las herramientas de software correctas?. Tal vez los evangelistas de aplicaciones y lenguajes no demoraran en contestar que si. Yo en lo personal he empezado a ver con desconfianza cualquier asomo de ortodoxia en la elección de herramientas. Las grandes empresa de tecnología no usan grandes y novedosas soluciones, si no mas bien simples soluciones con lenguajes con decadas de historia (Google en un buen ejemplo). Por otro lado las pequeñas pero innovadoras empresas de IT, están usando modernos lenguajes de tipo dinamico como Ruby (Las StarpUp tipo Web son muy buen ejemplo de esto). En lo personal le recomendaría no dejar de evaluar Lenguajes como Python (usado ampliamente en proyectos de ingeniería, un buen ejemplo de ello es ALMA) o modernas aproximaciones de desarrollo web usando FrameWorks como ROR o Symphony. Como esta seccion puede dar para mucho les dejo un resumen de “Ques” a considerar en distintos ámbitos de grandes proyectos IT:

• Micro Modelo de Incidencias / Por sobre complejos sistemas de tracking
• No agrupar incidencias por ser del mismo tipo. (Error fatal que he visto en grandes empresas)
• Testeo en el Código TDD. Vital!
• Testeo de Aceptación BDD. Mas Vital!
• Programación en Pares. Al estilo Extreme Programming (eXP). Dos cabezas piensan mejor y se equivocan menos.
• NoSQL y SQL. Cada dia me gusta mas NoSQL!
• MVC (Modelo Vista Controlador). Al menos!
• Proceso Iterativo rápido, Sprint y Scruum por sobre modelos predictivos como PMI. Si va a desarrollar software considere los 2 puntos de vista predictivos y no predictivos en la administración de proyectos.
• REST vs SOA. Cada dia me gusta menos SOA y mas REST como alternativa minimalista.
• Capacitación Continua acerca del Negocio, Basico!
• Axure (Story Board) y no UML. No escriba documentacion para Ingenieros!
• Replica de datos en linea Horizontal VS tablas satélites y Modelo Gigante. MongoDB y modelos NoSQL.
• No BPM como parte del Core. Procesos no son el negocio!
• Salida Parcial VS BingBang en lo posible. Escuchanos señor te regamos!
• Si al Opensource donde sea mejor. Asi no mas!
• Menos capas en las aplicaciones máximo MVC.
• Compilación del Cliente de los códigos fuentes entregados por el proveedor.No se entregan binarios. Aunque no lo crea lo sigo viendo en grandes empresas!
• Control de SVN por parte del Cliente no del proveedor. Idem que arriba, lo sigo viendo, y mas seguido contra mas grande el proyecto.
• Sistema de Base de Conocimientos. Elemental, pero el mas olvidado.
• Control de Avance lo hace el Cliente no el Proveedor. No es chiste!. Lo sigo viendo en grandes empresas aun.
• Gráficos de Flujos y procesos de negocios conocidos por todos. Lo sorprenderia con las historias que tengo al respecto.
• Gráficos de Maquinas y redes conocidos por todos.Idem al anterior.
• Mismos nombres para únicos problemas. Sentido comun.
• Control presupuestario consolidado por 1 persona y reportado a Gerencia General. De preferencia externo al proyecto.
• Modelos Gráficos por sobre verbales en el conocimiento común.
• No a los script regularizadores, automatización vs correcciones manuales. La solucion barata trae grandes problemas y oculta otros peores

Contando con una base de metodología Predictiva tipo PMI (minimizada), y trabajando el día a día con Metodologías No-Predictivas (SCRUM, Ágiles, póngale el nombre que quiera). Es mas probable un exito en el desarrollo de software.

En ultimas palabras para evitar todos estos problemas en grandes y no tan grandes proyectos, me he convencido que la única forma viable real y efectiva es priorizar la comunicación  de los equipos y personas, por sobre los procesos y las herramientas.Por que cuando se priorizan las metodologías y herramientas por sobre los equipos y personas,las personas quedan relegadas. Cree usted que en ese escenario saldrá algo bueno si en ultima instancia el proyecto lo construyen, dirigen y lideran las personas?. Y si las respuestas a las preguntas: Porque?, Como? y Que? son solamente formalidades y no creencias.

Bueno espero que este breve resumen les sirva.

Saludos Cordiales
Javier Urrutia Tobar