Entornos y metodologías de desarrollo en el software de gestión

Parte del dimensionamiento de un proyecto de software de gestión se basa en la elección adecuada de los necesarios entornos de desarrollo, así como de las metodologías de desarrollo usadas.

En cuanto a la elección de los entornos de desarrollo, desde el punto de vista de la imprescindibilidad, podríamos ordenarlos (de mayor a menor) en: entorno de producción y entorno de preproducción en el cliente; entorno de desarrollo, entorno de integración y entorno de pruebas en el fabricante. El uso de éstos se aconseja en función de las características y volumen del proyecto.

Hacemos prescindibles ciertos entornos si…

• Entorno de desarrollo: el alcance funcional del proyecto no implica nuevos desarrollos o éstos son mínimos. Si bien es cierto que entornos de desarrollo siempre habrán, no tiene porqué haberlos específicamente para un proyecto.
• Entorno integración: solo hay un desarrollador (o ninguno) en el proyecto.
• Entorno de pruebas: el developer y/o tester realiza una amplia batería de pruebas y éstas no son de elevada complejidad y criticidad.
• Entorno preproducción: el entorno de pruebas fuese suficientemente parecido al entorno real y los desarrolladores y tester hiciesen las verificaciones y validaciones en profundidad.
• Entorno de producción: NUNCA.

El entorno de producción es el imprescindible por una cuestión obvia, es aquel donde se realizan todas las transacciones reales de la organización. El resto de entornos cobran mayor relevancia cuanto más desarrollo requiere el proyecto o cuanto más exigente o necesidad de garantías requiere.

En cuanto a la metodologías de desarrollo, profesionalmente he pasado por el modelo de desarrollo en cascada, sobre todo cuando hacíamos proyectos muy importantes de desarrollo a medida. Aunque no tiene porqué ser así, éste es un modelo más orientado a este tipo de proyectos donde la funcionalidad de los nuevos desarrollos ha de entregarse prácticamente de forma íntegra, o por lo menos un número discreto de veces. El inconveniente principal es que el cliente no es consciente del trabajo realizado, siendo el momento de la entrega situaciones altamente críticas debido a que no siempre resultaba ser lo esperado por el cliente.

Sin embargo, hoy me encuentro en una situación de gran verticalización y especialización de las soluciones, y aun cuando existen proyectos donde se hacen amplios desarrollos (que normalmente quedan para el estándar), se hace siguiendo una metodología de desarrollo iterativa y con una gran interacción con el cliente. La realidad es que la verticalización te permite un gran conocimiento del sector, frente a clientes que solo en muy raras ocasiones son capaces de definir los requerimientos, así que normalmente nuestra percepción no suele ir muy desencaminada. Si a eso añadimos múltiples entregas y refinamientos, la integración de los nuevos desarrollos y la nueva funcionalidad requerida por el cliente suelen ir parejos.

La metodología ágil estrictamente hablando no la usamos, aunque de alguna forma, diariamente usamos ciertos conceptos en nuestra metodología iterativa. Así por ejemplo usamos una lista de tareas (backlog) y una asignación de prioridades.

De momento, la opción más viable para mi modelo de negocio es una metodología iterativa e incremental. Ahora bien, ello requiere una correcta promoción de los desarrollos a los entornos cliente.

Una correcta promoción de los desarrollos puede ser la «delgada línea roja» que separa el éxito del fracaso de un proyecto. Veamos qué efectos puede producir una inadecuada promoción:

• Promoción al entorno de integración: paralización del resto del equipo, desconfianza de los compañeros y pérdidas para la empresa desarrolladora.
• Promoción al entorno de pruebas: múltiples retornos al entorno de desarrollo, deterioro del ambiente laboral y frustración del tester.
• Promoción al entorno de preproducción: desconfianza hacia el sistema por parte del cliente y deterioro imagen.
• Promoción al entorno de producción: desconfianza mayor hacia el sistema, pérdida mayor de imagen e incluso pérdidas económicas.

El tradicional problema de la metodología en cascada.

Cualquier promoción incorrecta tiene por resultado los retrasos y costes económicos importantes, tanto para el cliente como para la empresa desarrolladora, así que hacerlo correctamente no garantizará el éxito de una implantación, pero sí ayudará a lograrlo.

Anécdota

En una ocasión trabajé para un cliente cuyos requerimientos eran «nulos». Era incapaz de definir ni una sola tarea en condiciones. Sus requisitos se reducían a algo así como «Hay que controlar la sección de embalaje» o «Hay que controlar el almacén». De hecho una expresión muy típica suya era «Yo sé lo que quiero y no tengo ni idea de informática ni quiero saber, así que dime cómo». Era una relación absurda, porque se desentendía de todo y solo quería llegar al resultado final sin «sufrir» el proceso. Ni siquiera tenía personal cualificado para trasladarnos sus necesidades, era él el interlocutor.

Como ya nos conocíamos, en una ocasión me comentó que quería que el resultado de una máquina de corte de tela trasladase la información de las tareas realizadas y los consumos al ERP. Por supuesto le comenté las dificultades que eso implicaba y los desarrollos en los que podía incurrir, pero en su miope visión me dijo que solo quería conocer ciertos datos. Se le hizo un análisis del «pequeño» alcance solicitado, y por supuesto le pareció bien (no lo leyó claro), donde aparecía una alcance bastante limitado.

Cuando llegamos a implementar el desarrollo, su necesidad ya era otra, no solo más amplia, sino también distinta. La máquina de corte no era una, sino cuatro de distintas marcas (y por tanto cada una con un software distinto), los modelos que quería controlar ya no eran modelos, sino agrupaciones de modelos, … 

Bueno, un caos, aun así para no deteriorar la relación mi jefe procedió a ceder en la mayoría de aspectos, pero cada día el desarrollo se iba convirtiendo en exponencial. Mi empresa asumió el coste del desarrollo (unas 4 veces lo presupuestado) por un individuo incapaz de ver más allá de su nariz.

Por supuesto, el cliente estaba muy descontento, a pesar del coste que supuso para mi empresa y no para la suya, y finalmente prescindió de nuestros servicios.

(En el Master en Software Libre de Gestión: Open Source & ERP II, estamos analizando situaciones como la que aquí acabamos de mostrar).

Recibe nuevos artículos mediante suscripción por e-mail, RSS o Feedly

Email