Mucho se habla de gestión de riesgos, ya sea en metodologías ágiles como en, cof cof, waterfall, y claro, mucho se colocan tablas y con una mayor o menor pericia se indican los impactos y probabilidades respectivas, hasta ahí "lo normal".

Lo usual es que por lo usual los criterios de experiencia que se toman están basados en el tipo de proyecto: ERP, almacén, web o desktop o también en el grado de complejidad del negocio, estado de las relaciones con el cliente, primera vez, time to market etc, nada fuera de lo habitual.

El problema es que muchas veces la visión "de negocio" logra opacar al criterio técnico en un factor muy importante: no todas las tecnologías tienen igual riesgo, y no, no me refiero al hecho de que por ejemplo un consultor de SAP cobre mas que un diseñador gráfico (llevándolo a extremos), sino que las diversas tecnologías tienen diferentes niveles de disponibilidad de recursos de aprendizaje, lo cual quieras que no, impacta en las previsiones que se requieren tomar para un proyecto.

En algunos casos es evidente que hay muchos mas recursos (ojo, en este blog nunca hablamos de personas como "recursos", ¿ok?) para SQL Server y Oracle que para Informix o Sybase, por lo cual el tiempo en que un equipo puede llegar a ser productivo en un proyecto con estas dos tecnologías "raras" es mayor, pero mal que bien se puede solventar con la experiencia previa en otros motores de base de datos, así que tenemos un riesgo ligeramente mayor, pero justificable.

Visto a este contexto debemos pasar a un diferente tipo de escenario, los frameworks o soluciones "listas para usar", productos que se espera que puedan ser usados directamente por un usuario final, "casi" sin necesidad de desarrollo, pero claro eventualmente terminan pidiendose personalizaciones y como la aplicación tiene una API en un lenguaje "conocido" como PHP, C# o Java pues se empieza el desarrollo tomando los mismo criterios que cualquier otro proyecto a medida y .. ahi empiezan los problemas.

En concreto estas aplicaciones (concretamente los CMS que son con los que he tenido experiencia) presentan dos problemas que los hacen "bestias" diferentes a cualquier desarrollo a medida:

1. Esfuerzo extra para configurar los entornos, tanto de desarrollo, como de producción, en el caso de SharePoint por ejemplo era muy complicado, tan así que no se podía trabajar contra un servidor compartido sino que cada desarrollador debía de tener una Maquina Virtual para tener un entorno de trabajo, todo lo cual involucraba un esfuerzo que no era trivial.
2. Cambio de paradigma respecto a como desarrollar y/o depurar, pues aquí no eres tu desarrollando una aplicación, estas intentando construir algo sobre los cimientos que alguien mas hizo, y que le puso reglas que pueden ser no usuales (y sobre todo contraintuitivas), pero necesarias para que el producto funcione, lo cual deriva en una necesidad de conocimiento (y tiempo de aprendizaje) mas allá de cuan experto uno crea ser en el lenguaje en cuestión.

Queda claro que estos dos factores tienen alta probabilidad de incidir sobre el tiempo que le puede tomar al equipo implementar la solución, por lo que seria un grave error asumir proyecciones sin tomar en cuenta el esfuerzo extra mencionado, si, es difícil acometer estas cosas que nos dejan productos como Magnolia, Vignette, o SharePoint, pero al final son retos técnicos que terminan siendo superados, a menos claro que la dirección asuma que ".net es .net" y no tome en cuenta detalles como estos en sus proyecciones, ahora que si a estas dos cosas, se le suma la poca experiencia local, o poca documentación actualizada en foros, asumimos grandes riesgos que no podemos dejar de informar de antemano, y créanme, en el caso de CMS (salvo que tengas miembros del equipo que actúen como pilares del resto) siempre pasa algo de lo mencionado, por lo que debemos estar alertas, regresando al titulo de este post, no todo tiene igual riesgo (técnico).

Hace unos dias en una reunion conoci a un egresado de Ing. Informatica de una de las universidades surgidas a la amparo de la Ley de Promoción de la Inversión en la Educación durante el fujimorismo, y sin querer la conversacion derivo a conversar sobre el enfoque que se da a nuestra carrera en las universidades.. y fue mas o menos asi.

Comentaba sobre el hecho de que algunos egresados de una tercera universidad tenian a honra el hecho de casi no haber programado, y que cuando les toco hacerlo contrataron a alguien para que lo hiciera por ellos, actitudes como esa serian desconcertantes en la UNI o en la PUCP pero a este caballero le parecia lo mas normal del mundo, arguia que lo importante era el negocio que todo formaba parte del negocio, etc etc, y que al final el programa final es lo de menos. Un poco mas y casi se dirige al lugar comun de que el codigo es la pieza mas basica del todo y que un Ing. Civil no necesita saber colocar ladrillos para hacer su trabajo. Eh??? Si, no es raro que se llegue a dicha peregrina conclusion, ignorando que los diversos modulos de una solucion tienen una tarea intelectual detras de ellos, que no homogenea precisamente.

Vayamos por partes, si... las aplicaciones informaticas al final de cuentas deben estar alineadas a los objetivos de la organizacion, y significar un medio para la mejora de sus procesos o para lograr ventajas competitivas, hasta ahi las cosas claras. El problema que ocurre es que a veces se llega a un nivel tan abstracto en el como implementar las cosas, todo diluido en pilas de documentacion e informes a la gerencia, que en la practica tratan de enmascarar que no se esta cumpliendo los objetivos que se tenia con la implementacion o desarrollo planificado. Y nos olvidamos que dentro de nuestro ambito de competencia lo que importa es la entrega de lo realizado, la obra visible y que sea de utilidad a la organizacion.

(Aprovecho para recordar los principios del Manifiesto Agil:

Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:

A los individuos y su interacción, por encima de los procesos y las herramientas.
El software que funciona, por encima de la documentación exhaustiva.
La colaboración con el cliente, por encima de la negociación contractual.
La respuesta al cambio, por encima del seguimiento de un plan.
Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.)

Parte de los problemas que se tiene en los procesos de desarrollo de aplicaciones vienen dados por malas estimaciones y una gestion irrealista de las expectativas del cliente, situaciones que en varios casos vienen dadas porque dichos pasos han sido dados por profesionales que han visto la informatica de manera muy ligera, osea: no saben la clase de complejidades que puede implicar el desarrollo de tal o cual funcionalidad, o no saber las limitaciones que puede tener cierta tecnologia y el impacto en los plazos de entrega que tendra el "puentear" dichas limitaciones. Se me dira que si, pero que un jefe de proyecto no esta para tirar lineas de codigo, y doy toda la razon, pero voy al hecho de la necesidad de este jefe de proyecto de haber tenido, ya sea en su educacion o experiencia previa, de un conocimiento interno de que es lo que hay detras de las aplicaciones informaticas.

Cierto, he tenido jefes que no han pasado por la programacion y han sido capaces de sacar adelante sus proyectos, pero en estos casos han tenido el suficiente sentido comun de saber escuchar a la gente tecnica que lo rodea, pero aun asi, de mi experiencia puedo decir que a un jefe que haya pasado por las trincheras es mucho mas dificil pasearlo, y que ademas te dara una estimacion fiable.

Por otro lado esta el otro perfil de nuestra carrera, el que permanece siempre detras de las lineas de codigo, si, es facil decir que con un curso de medio año ya se puede programar, pero olvidamos la importancia de una formacion matematica y logica en el perfil de un programador de calidad, la necesidad de introducir principios de eficiencia, programacion metodica, y por que no? algo de elegancia al momento de plantear las ideas en codigo.

Entonces, llegamos al punto de la importancia que tienen las bases (programacion, matematicas, logica, ciencias de la computacion) en la formacion de un ingeniero informatico, independientemente del curso profesional que luego se siga (gestion, programacion, comunicaciones), esas bases son las que nos definen y las que hacen que no seamos Administradores de Empresas con conocimientos de Informatica, que es lo que parecia el perfil de mi interlocutor de entonces.