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).