El software hecho en casa

Este artículo continúa la serie que comencé con :

• Soluciones caseras, gratis y de código libre: Preguntas para contestar luego ...
• Soluciones caseras, gratis y de código libre: Software gratis y código libre

Llamaremos software casero a las aplicaciones que son desarrolladas para uso interno por personas pertenecientes a una institución. Repito aquí algunas de las razones por las cuáles desarrollar software casero pudiera ser problemático:

• No se cuenta con personal capacitado.
• Se tiene personal capacitado, pero no tienen suficiente tiempo para completar el proyecto en un tiempo razonable.
• El producto final podría depender tanto del equipo de desarrolladores que, una vez estos desaparecen, el apoyo técnico se va con ellos.

No se cuenta con personal capacitado

Este inconveniencia ocurre cuando se tiene personal (docente o no docente) con un escaso o inexistente trasfondo en programación o personal con un repertorio de lenguajes y técnicas de programación que no ha sido actualizado en varios años.

Contratar personal para áreas afines a la Informática sin habilidades demostradas en programación es un error. Es comprensible si el mercado no ofrece alternativas. En ese caso, habría que exigirle adiestramientos en programación y ayudarlo a recibirlos (dinero, tiempo).

El problema está en que la institución tendrá una dependencia total de los ofrecimientos comerciales externos. Además del indeseable costo, también depende de tener la suerte de que alguna empresa ya haya identificado el problema antes y haya desarrollado una solución. Es posible no encontrar paquetes comerciales que hagan, exacta y exclusivamente lo que necesitamos. Mas, si tenemos personal que puede desarrollar el software necesario en sus horas laborables, el costo adicional se reduce, hasta podría ser nulo, si utilizan herramientas que ya están en inventario o que sean software gratis.

Tener empleados con posiciones regulares que sólo pueden crear programas en Cobol, RPG o FORTRAN, es otro problema. Estos no son lenguajes muertos, todavía se usan. Pero estos lenguajes no son los mejores en una era en la que las aplicaciones Web con bases de datos imperan. Algunos lenguajes populares y apropiados para esas tareas son Java, PHP, Python, JavaScript, C++ o VisualBasic. La actitud de estos empleados debe ser la de estar en la mejor dispocisión de aprender cosa nuevas: lenguajes y técnicas; de lo contrario, dejarán anclada a la institución en la tecnología del pasado, que pierde apoyo técnico según pasa el tiempo. Por otro lado, la institución que los emplea debe obligarlos a adiestrarse y debe apoyarlos significativamente con dinero o tiempo.

Existe el caso de personal que quiere ponerse al día, que quiere expandir su portafolio de habilidades, pero se encuentra con que la institución donde labora no apoya sus iniciativas. Toda institución que requiera personal en áreas de la Informática debe estar lista, dispuesta a invertir en su adiestramiento; la Informática es un campo sumamente dinámico en el que las innovaciones surgen a diario. Es ser ingenúo pensar que una empleada que programa, digamos, en Java no necesitará aprender otros lenguajes o técnicas durante los próximos cinco años. El mismo Java, ha cambiado y se ha expandido bastante en los últimos cinco años.

Se tiene personal capacitado, pero no tienen suficiente tiempo para completar el proyecto en un tiempo razonable

En estos días, estar sobrecargado de deberes familiares y laborales es común. No se salvan ni nuestros hijos con su vagón de tareas escolares y actividades extracurriculares. No me salvo yo.

En mi propia universidad tenemos cinco colegas del área técnica atendiendo un recinto con más de 3500 estudiantes, una centena de profesores, dos decenas de laboratorios y cerca de 400 computadoras en total. Todos los días estos titanes atienden problemas de la red local, Internet, impresoras, ataques de virus, computadoras "congeladas", usuarios paranoicos violentos e instalaciones de software . Algunos de ellos quisieran desarrollar proyectos con Moodle, Linux, MySQL, VisualBasic, PHP, Macromedia Breeze, VoIP ... pero no tienen tiempo.

Sé que algunos de ellos han dedicado de su tiempo "libre" para por lo menos desarrollar prototipos, pero la universidad jamás les pagará por eso y sus familias, con mucha razón, se lo recuerdan.

Una solución al problema de la escasez de tiempo es contratar personal para atender instalaciones de software, impresoras y otros trabajos técnicos considerados básicos, y así liberar tiempo para los empleados que desean desarrollar proyectos de interés para la institución. Es frustrante para un especialista en redes o en programación el que su tarea principal sea desatascar impresoras o instalar antivirus.

Otra forma de apoyar y motivar la creación de software casero es pagar compensaciones adicionales por la participación efectiva en esos proyectos. No solamente puede ser costo eficiente, también puede mantener intelectualmente activo y hasta motivado al personal.

El producto final podría depender tanto del equipo de desarrolladores que, una vez estos desaparecen, el apoyo técnico se va con ellos

Exija documentación. Para que la institución no se quede a la deriva con aplicaciones caseras huérfanas, pida una guía para el usuario y una para el programador. El proceso de documentación debe ser "segunda naturaleza" para programadores de proyectos complejos. No es fácil desarrollar buenos hábitos de documentación, ni tampoco suele ser divertido hacerlo, pero es necesario para quien deba enfrentar nuestras creaciones en el futuro.

Comentario final

El desarrollo de software casero debe estar considerado en los planes estratégicos del área de Informática. No podemos suponer que siempre podremos tirarle dinero a todos los problemas. Solamente Microsoft puede hacer eso sin sufrir pérdidas.

Desarrollar internamente software ofrece estas gratas oportunidades:

• reducir costos en adquisición de software comercial
• desarrollar de soluciones hechas a la medida; no más, no menos de lo que se requiere
• mantener empleados motivados y activos en su campo
• obtener prestigio por desarrollar software que otras instituciones encuentran útil
• adquirir ingresos por conceder licencias del software a otras instituciones (esta no me agrada, pero puede ser un atractivo) o por ofrecer consultoría en su uso (esta me parece más propia de la Academia, mi opinión)
  

Sin embargo existen obstáculos reales, especialmente para instituciones cuyo presupuesto no permite la contratación de personal adicional o personal con altas cualificaciones en el área de Informática. El desinterés del personal o de la administración por mantenerse actualizado en el campo también es un reto mayor al desarrollo local de software. También lo son los prejuicios contra las habilidades del personal local, el síndrome de "nadie es profeta en su tierra".

Categorías: Tecnología Educativa, software libre