¿Recuerdas cuando Dorothy, el Hombre de Lata, el León y el Espantapájaros se acercaron al Mago de Oz En cada caso ya sabían lo que necesitaban. Habían hecho su propio análisis aproximado de necesidades. Para pensar en la migración a software de origen libre, también debe comenzar desde una perspectiva de análisis de necesidades. Este marco de migración es paralelo a un modelo de planificación utilizado para ubicar una fábrica o centro de producción. Al situar un negocio de este tipo, los planificadores necesitan sopesar el acceso a los mercados de materias primas/productos, los costos de transporte de materias primas/productos, así como cualquier requisito especial como fuentes de energía particulares, o centros de investigación y desarrollo. Dependiendo de las necesidades identificadas, algunas industrias están orientadas a los materiales (situadas más cerca de los sitios de materias primas), algunas orientadas al mercado (situadas más cerca de los mercados), algunas orientadas al transporte (situadas más cerca de los medios de transporte) y otras orientadas a la energía o a la investigación (situadas más cerca de sitios como presas hidroeléctricas o centros de investigación universitarios) (Dunlop, 1987). Tu trabajo es descubrir si el software de código abierto o libre proporciona una alternativa viable para reubicar tus necesidades.
Cuando un posible adoptante mira el cambio de software, tiene que ocurrir una forma de triangulación, teniendo en cuenta lo siguiente:
- Disponibilidad y comparabilidad con el software comercial propietario actual: esta primera consideración tiene que ver con saber qué tipos de software están disponibles actualmente. Como esta información cambia casi a diario, debe mantenerse actualizado con los desarrollos en software de origen libre. Cuanto más cerca estén los programas de software de origen libre y propietario en términos de apariencia, facilidad de uso, características y funciones, más suave será la transición y más rápida será la adopción. Además, si la nueva opción de código abierto puede aproximar o mejorar el producto antiguo mientras entrega las necesidades deseadas y expresadas de actualizaciones, más segura será la transición.
- Viabilidad del software: aquí revisa qué versión se estaba considerando, cuánto tiempo ha existido el programa y qué tan robusta se ha construido una comunidad de usuarios y/o una comunidad comercial alrededor del producto. Ciertamente, productos como Moodle, ATutor y Sakai son apuestas más seguras. La experiencia ha demostrado que cuanto más longevas y robustas sean las comunidades, más exitoso será el software de origen libre.
- Costos de implementación y soporte: recuerde que si bien el código fuente es gratuito, debe tener la experiencia para manejarlo. Esto incluye no solo las compras de hardware necesarias, sino la habilidad para implementar y apoyar el software en su grupo o institución, o el costo de cualquier externalización necesaria.
- Nivel de personalización deseado: a diferencia del software propietario, el software de origen libre es altamente personalizable. Debes saber lo que quieres de la aplicación de software. Si se desea la personalización, las preguntas clave incluyen: ¿existe experiencia presupuestada en nuestra organización para lograr la personalización a través de la modificación de programas? o sería necesario subcontratar este trabajo, y ¿a qué costo?
- Historial de sucesión de software: generalmente, cuando las organizaciones experimentan una rápida sucesión de transiciones de software que implican cambios/desafíos significativos, la resistencia a la adopción de cualquier software nuevo aumentará. Tus transiciones deben ser gestionadas para la relativa comodidad de tus usuarios.
- Evaluación de riesgos: esto implica un examen de cuánto riesgo es aceptable en una transición a opciones de origen libre. Esto puede medirse por la confianza en la reputación, la disponibilidad de garantías o la asunción de responsabilidad por el software. Si es deseable un riesgo bajo, entonces un grupo o institución puede experimentar con aplicaciones más establecidas, o aquellas con garantías y/o soporte de proveedores. Si un programa juega un papel crítico, entonces se debe buscar una alta viabilidad del software, generalmente a un costo mayor. El nivel de suposición de riesgo que está dispuesto a hacer afectará si su grupo o institución se sentirá cómodo con programas más nuevos, menos comprobados y verdaderos, o un programa de primera línea como Moodle o ATutor.
Análisis de Necesidades
Primero necesitas un equipo o individuo en tu grupo o institución mejor posicionado para hacer una revisión de software. Esta es probablemente la (s) persona (s) responsable (s) de comprar, mantener y monitorear su tecnología. Quieres ver las aplicaciones que estás ejecutando actualmente en tu organización. Determina cuáles son los más caros, tienen los costos más asociados para actualizaciones, mantenimiento, etc. ¿De cuáles se queja tu gente, o desea que fueran mejores? ¿Para cuáles solicitan alternativas las personas? Cuando hayas establecido una lista base, examina estos programas en busca de las funciones y características que tus usuarios necesitan, las que no usan y las que desean que tengan los programas. Use esto para crear su lista de deseos de funciones y características para una alternativa de origen libre. Esta lista formará la base para una cuadrícula de análisis de software cuando revise sus opciones de software.
- Resultados: Informe de análisis de necesidades, formal o informal; listas de deseos de funciones y características del software.
- Recursos: Tiempo del empleado de tecnología para el análisis.
- Costos: Salarios de empleados por tiempo de análisis de necesidades.
Investigación y Análisis
Ahora es el momento de averiguar si hay algo en el mundo de origen libre que pueda cumplir con la mayoría de las características y funciones de su lista de deseos. Construye un equipo de investigación: invita a uno o más expertos en tecnología con experiencia en programación de tu grupo o institución a trabajar con tu grupo de análisis de necesidades (podrían ser uno y el mismo) así como con uno o más usuarios finales potenciales que hayan demostrado ser los primeros en adoptar la tecnología. Los usuarios finales pueden ser personal administrativo, instructores, profesores, contadores, etc. Siempre tenga en cuenta exactamente quién terminará usando el software. En definitiva, tendrán que estar satisfechos con el nuevo software. A veces tu equipo solo puede estar formado por dos o tres personas, y eso está bien para comenzar, pero necesitarás aumentar tus participantes en etapas posteriores. La retroalimentación de los usuarios finales es vital. Si la interfaz, el front-end de la aplicación, es demasiado difícil de usar o no es amigable para el usuario, o claramente supera otros beneficios, busque algo más, hágalo desarrollado o espere hasta que se desarrolle. Tenga en cuenta que muchas comunidades de usuarios aceptarán solicitudes que se acumulen con el tiempo para impulsar la dirección del desarrollo de software.
Haga que el equipo investigue posibles alternativas para su uso en su organización a la luz del análisis de necesidades realizado y su (s) lista (s) de deseos. Parte de este proceso debe evaluar la viabilidad de alternativas de origen libre, incluido el hardware existente y los costos potenciales de nuevo hardware o externalización. También debe generar estimaciones del tiempo de soporte tecnológico requerido para la migración al nuevo software para las pruebas iniciales. Otro aspecto importante de la evaluación es la comunidad de desarrollo/apoyo para el programa específico. Las aplicaciones sólidas de origen libre tienen comunidades vibrantes que apoyan su uso. También podrías ver posibles organizaciones asociadas con necesidades y objetivos similares que podrían aportar recursos o apoyar tus actividades migratorias. Usando su lista de deseos desde la etapa de análisis de necesidades, cree una cuadrícula de comparación de software que incluya cualquier consideración adicional que pueda tener para que pueda evaluar sus opciones una al lado de la otra. Dependiendo del ítem en la cuadrícula, es posible que tengas una X o una marca de verificación (para indicar que un ítem está presente) y/o un marco de puntuación de 1 a 5 (por ejemplo, para facilitar su uso donde 1 es más difícil y 5 es más fácil).
Si tu equipo determina que existen opciones viables de origen libre, el siguiente paso en el proceso de evaluación es crear y presentar un esquema de proyecto con un borrador de presupuesto para determinar si tu grupo o institución está preparado para comprometer más recursos. Asegúrese de incluir tiempo de reunión para que el equipo del proyecto discuta el proyecto, revise informes, genere comunicaciones, etc. Al redactar su presupuesto, también debe preparar una justificación para una migración. Asegúrese de comparar los costos existentes y proyectados del software/aplicaciones comerciales patentadas actuales en uso con la implementación de las opciones de origen libre. Observe los costos de licencia proyectados para el versionado, etc. Revise los ciclos de versionado de productos del software existente para determinar la frecuencia con la que se requiere actualizar y los costos asociados. Este suele ser un gran punto de venta para la conversión a programas de origen libre.
- Resultados: Cuadrícula de comparación; informe de investigación y análisis formal o informal con recomendaciones específicas de la organización; borrador de presupuesto/costo que incluye estimaciones de expertos en tecnología para la migración de datos organizacionales limitados a aplicaciones/programas de origen libre.
- Recursos: Tiempo de proyecto del empleado para la investigación y redacción de propuesta.
- Costos: Salarios de los empleados para investigación y análisis.
Implementación de Prueba
Si llegas a esta etapa, ya has determinado que existen alternativas viables y posibles socios potenciales para convertir a software de origen libre. Usted ha redactado una propuesta con un posible presupuesto de conversión que ha sido aceptada. Ahora se han comprometido recursos para determinar si las opciones de origen libre funcionarán para su organización. Si aún no lo ha hecho, designe a un jefe de proyecto o líder que ayude a redactar horarios, realizar un seguimiento de tareas, monitorear presupuestos, etc. Esta es una posición crítica y ayudará a mantener el proyecto en buen camino. En un mundo perfecto, este individuo tendría capacitación o experiencia en gestión de proyectos. Durante la primera ola de implementación, probablemente probarás un conjunto de aplicaciones seleccionadas con tus primeros usuarios en implementaciones limitadas.
Las pruebas iniciales podrían considerar de tres a cinco aplicaciones durante una semana o mes y luego reducir el campo a solo una o dos opciones para una prueba más larga. Los primeros usuarios ejecutan los programas, comentan los beneficios, trampas, etc., mientras trabajan con los expertos en tecnología. Esas reuniones periódicas de equipo para las que presupuestaste deben guiar el proceso de poda del programa. Asegúrese de recibir comentarios de todos: las personas que instalan, mantienen y ajustan el código fuente, así como de los usuarios finales. Si las aplicaciones funcionan bien, estos primeros usuarios pueden convertirse en sus mentores de desarrollo profesional que luego capacitarán a otras personas para usar el nuevo software.
Uno de los resultados de este trabajo puede ser la decisión de abandonar el software de prueba, pero si has encontrado algo que funcione bien, necesitarás comunicar esa noticia a través de tu organización. Muéstrale a la gente lo que has hecho, qué tan bien funciona, conversa sobre los beneficios de una conversión más amplia. Plantar las semillas de interés en el nuevo software y redactar un plan de proyecto para una adopción organizacional más amplia. El plan del proyecto para la segunda fase de implementación debe incluir una justificación, un presupuesto, un plan de gestión del cambio, capacitación/desarrollo profesional, etc. Para una implementación más completa, definitivamente debe involucrar a un gerente de proyecto con experiencia que esté capacitado para administrar el cambio organizacional. Sin embargo, si las opciones de origen libre no funcionan para usted en este momento, proporcione un informe de cierre del proyecto que indique los problemas con el software, pero recuerde, el software de origen libre continuará desarrollándose y se presentarán nuevas opciones. Estar abierto a más alternativas e investigaciones en el futuro.
- Resultados: Instalación de programas/aplicaciones; conversión limitada de datos organizacionales a nuevos programas/aplicaciones; capacitación de personal selecto de la organización en nuevos software/aplicaciones; reuniones e informes periódicos sobre desafíos y éxitos con los nuevos programas/aplicaciones; evaluaciones de si los el proyecto debe continuar/expandirse; planificar el proyecto para una adopción organizacional más amplia, o informar sobre el cierre del proyecto.
- Recursos: Salarios de los empleados, incluido el tiempo de reunión para el equipo del proyecto; recursos adicionales designados en el borrador del presupuesto.
- Costos: Dependiente del presupuesto.
