Este post se ha dividido en dos partes:
- 1 – Cinco elementos clave en una buena externalización del desarrollo software (I/II). (1) los acuerdos de nivel de servicio (SLA), (2) el proceso de externalización.
- 2 – Cinco elementos clave en una buena externalización del desarrollo software (II/II). (3) los requerimientos a cumplir por la fábrica de desarrollo software, (4) la especificación de los trabajos a desarrollar y (5) la recepción del producto y la evaluación de su calidad
—
Desde casi los principios de Kybele Consulting participamos en varios proyectos cuyo objetivo era ayudar a organizaciones de gran tamaño a preparar la externalización de un volumen importante de sus desarrollos software. Aprovechando que estaba recopilando información para otro proyecto de este tipo, he desarrollado en este post una breve lista de los principales factores a tener en cuenta cuando una organización da el paso de externalizar el desarrollo software. Estos no dejan de ser una mera lista de consideraciones a tener en cuenta, y no una metodología de externalización, pero pueden venir bien como una primera “checklist”.
Por externalización entendemos la transferencia a terceros de ciertas actividades, en nuestro caso de desarrollo – mantenimiento de software. En los últimos años la externalización de desarrollos software ha crecido considerablemente, y ciertas organizaciones han tenido que prepararse para ello, para ese diferente modo de trabajar. Las razones de este crecimiento son muchas, si bien las más destacadas suelen ser el ahorro de costes, desarrollar productos más rápido, aumentar la capacidad de desarrollo, disponer de especialistas en cierto tipo de desarrollo software durante momentos puntuales, etc.
Pasar de un desarrollo “en casa” a que el software sea desarrollado por un tercero no es un tema trivial, y en muchas ocasiones tiene impactos negativos para la empresa que ha externalizado. Cuando se pasa a un desarrollo externalizado aparecen, entre otros, los contratos, las especificaciones detalladas, la distancia física con el equipo de desarrollo, la falta de visibilidad del trabajo que se está desarrollando, diferentes culturas, necesidad de validar las entregas, periodos de garantía, articular el cómo mantener en el futuro un software que nosotros no hemos desarrollado, etc., que implican una gestión diferente del proyecto, y que de no gestionarse pueden hacer de la externalización una autentica pesadilla.
Existen numerosos estudios que recogen los principales puntos a considerar en la externalización, uno bastante útil es el de (Ramu, 2008), que muestra seis áreas de conocimiento: la gestión de la cadena de suministro, de las comunicaciones, del equipo, del proyecto, del conocimiento y de la calidad. Y en este sentido, este post resume algunas de cuestiones clave a tener en cuenta a la hora de externalizar el desarrollo – mantenimiento software: (1) los acuerdos de nivel de servicio (SLA), (2) el proceso de externalización, (3) los requerimientos a cumplir por la fábrica de desarrollo software, (4) la especificación de los trabajos a desarrollar, (5) la recepción del producto y la evaluación de su calidad.
1 – Los acuerdos de nivel de servicio (SLA).
Una parte esencial para el éxito de la externalización, y a la vez una de las partes más difíciles de especificar y negociar, son los “acuerdos de nivel de servicio”, también conocidos como SLAs (de Service Level Agreement). Normalmente estos se basan en indicadores o métricas, que nos ayudan a la hora de determinar la efectividad del servicio que nos presta la empresa de desarrollo software, de la manera más objetiva y cuantitativa posible. Y que debieran definirse antes de externalizar, e incluirse en el contrato de externalización.
Ejemplos típicos de indicadores que nos ayudan a determinar la calidad del servicio son la desviación respecto a la planificación, el tiempo de resolución de problemas, las incidencias que aparecen durante las pruebas o en explotación, incumplimientos de la normativa de calidad software (por ejemplo, el porcentaje de código que se ha repetido o si se ha seguido el estilo de codificación establecido), etc.
Normalmente los SLA tienen asociado un modelo de penalización que especifica las posibles penalizaciones o bonificaciones que se aplicarán al proveedor en función del valor que tomen los indicadores, y que suelen ser un porcentaje que disminuye o aumenta el importe económico de las tareas desarrolladas.
2 – El proceso de externalización
El cómo se va a trabajar con los proveedores, los roles de los involucrados, las herramientas, actividades, flujo de comunicación, etc., son también factores fundamentales a definir. En este punto existen varias propuestas, modelos y normas, que como base y guía nos pueden ayudar, aunque, como siempre, tendrán que ser adaptadas a nuestra problemática, seleccionando lo que nos aplica y lo que no. Hay propuestas de carácter general (no específicas de la externalización) que nos pueden servir de base y de las que podemos extraer buenas prácticas, como la ISO 20000, otras que contemplan la externalización en alguno de sus procesos, como la norma ISO/IEC 12207 o el modelo CMMI-DEV, y otras específicas como el modelo CMMI-ACQ. Como comentábamos, aquí hay que trabajar en saber qué nos aplica, ya que modelos como CMMI-ACQ están pensados para grandes volúmenes de externalización, por lo que puede haber muchas cosas que no necesitemos, y llevarnos a un proceso de externalización excesivo para nuestro caso.
—
- Cinco elementos clave en una buena externalización del desarrollo software (I/II). (1) los acuerdos de nivel de servicio (SLA), (2) el proceso de externalización.
- Cinco elementos clave en una buena externalización del desarrollo software (II/II). (3) los requerimientos a cumplir por la fábrica de desarrollo software, (4) la especificación de los trabajos a desarrollar y (5) la recepción del producto y la evaluación de su calidad.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Pingback: Cinco elementos clave en una buena externalización del desarrollo software (II/II) | Javier Garzás
Hola Javier, está genial este POST. Gracias