Imaginemos que hay que planificar todas las tareas de un organismo o empresa para todo un año.
Dependiendo del tamaño, estas tareas pueden ser muchas o pocas. En el caso que imagino puedo asegurar que son bastantes, lo suficiente para pensar en un sistema automatizado de recogida de datos, evitando documentos individuales que posteriormente supondrá una tarea mayor de reunificación, aparte de otros problemas que todos hemos sufrido alguna vez al tratar con documentos no centralizados.
Justamente, durante esos días estaba recopilando información sobre Ruby On Rails gracias a la recomendación que me había hecho un antiguo (que no viejo) compañero tras un encuentro casi casual en Oviedo.
Esto es, por un lado existe la necesidad de recopilar toda la información sobre planificación (facilitando la recogida centralizada de datos, categorizando las tareas, relacionando las tareas con los proyectos, reutilizando información existente, generando informes estadísticos, etc.) y por otro lado, estaba empezando a experimentar con RoR para ver si es verdad eso de que “se reduce por diez el tiempo de desarrollo”. (Que dicho así y para alguien que viene de programar en Java suena un poco a cosa de otro mundo…)
Así que, que mejor manera de responder a la pregunta que experimentar y ponerse manos a la obra con el objetivo principal de hacer una implementación sobre RoR de estos requisitos.
La aplicación no tiene complejidad funcional alguna: Para un proyecto determinado, puedes añadir tareas con una descripción, estimación en jornadas, asociar las categorías y subcategorías correspondientes, etc. Lo de toda la vida: Alta, baja, modificación y listado de tareas (ABM).
Con esta información, y sin conocer Ruby ni haber instalado RoR en mi vida, me puse manos a la obra un viernes por la tarde (fuera de horario laboral ya que formaba parte de un objetivo personal…). El martes ya estaba la funcionalidad de la aplicación implementada y probada (30 horas en total).
Como este no es un post técnico sobre RoR (que intentaré abordar proximamente), resumo a continuación las tareas realizadas:
- Instalación de RoR. Estudio básico de Ruby y conocimiento de Rails.
- Diseño y creación de la BBDD
- Programación: anidar varios combos, cacheo de páginas estáticas, creación de una página de búsqueda, navegación del site, asociar categorías y subcategorías, relacionar proyectos y tareas, validaciones, definir las asociaciones entre entidades y otras tareas.
- Diseño: Adaptación a los estilos corporativos.

¿Se puede hacer entonces una aplicación en cinco días? Obviamente sí. Y, obviamente, dependiendo de las necesidades y requisitos. Este caso es un ejemplo perfecto (repito, a mi modo de ver) de la necesidad de crear una herramienta de forma rápida para resolver una necesidad sin tener que pasar por los diferentes filtros y condicionantes que a menudo existen.
¿Cuanto tiempo hubiera tardado en hacer la aplicación si me ciño a las normas estipuladas? Lo primero es que me hubiera pensado mucho hacerla, ya que me exigiría realizarla en un entorno propietario. Por otro lado, según algunas estimaciones realizadas por compañeros, crear esta misma aplicación dentro del entorno de trabajo supondría un mes de desarrollo…
Como conclusión quiero decir que, en ciertos momentos, es necesario flexibilizar los requisitos tecnológicos para poder acometer desarrollos de este tipo. Con cierta frecuencia tendemos a burocratizar (que en el fondo no es más que añadir medidas de control) la gestión tecnológica. Estamos intentando liberar de burocracia administrativa a las diferentes gestiones y, cada vez con más frecuencia nosotros mismos alimentamos la “burocracia tecnológica”.
P.D.: Por cierto, se ha optado por recoger las tareas en formato Excel…