Contratación de Software Basada en Resultados

El sector de Tecnologías de la Información se ha visto muy afectado por el movimiento de  externalización de las empresas. Gran parte del desarrollo y mantenimiento de los sistemas ya no se hace más internamente.

Sin embargo, esta medida trajo efectos secundarios inesperados (y no deseados) para muchas organizaciones que han adoptado esta iniciativa. Uno de los problemas se refiere a las prácticas de contratación de estos servicios de terceros. En las secciones siguientes se comentan las formas más comunes de la contratación de servicios de desarrollo de software.

La contratación por hora-hombre

En esta forma de contratación, también conocida como body shopping, el cliente contrata a profesionales para la asignación en el desarrollo de software, generalmente en conjunto con su propio equipo, algunas veces con varios proveedores de mano de obra, y utiliza su infraestructura logística interna. La remuneración del proveedor se calcula basándose en el nivel de cualificación y experiencia de los profesionales que trabajan, en las horas trabajadas y otros gastos posibles.

En este tipo de contrato, la remuneración del proveedor está orientada a los procesos "internos" a la producción de software. El precio final de un proyecto se determina a partir de consideraciones tales como: la cantidad de trabajo que requiere, el perfil y la cantidad de profesionales movilizados para su aplicación, y la complejidad de la gestión. El control de precios está en manos del proveedor, que en teoría, tiene más experiencia en estos aspectos técnicos del proyecto que el cliente, cuya actividad económica tiende a ser diferente al desarrollo o mantenimiento de software.

Este modelo es fácil de administrar y proporciona una gran flexibilidad tanto para el cliente y como para el proveedor. Una vez que se hayan establecido las relaciones comerciales, el cliente es capaz de ser más ágil en el cumplimiento de los picos de demanda del servicio. En el caso de que exista cambio de las necesidades, no es necesario renegociar el contrato con el proveedor. Sin embargo, aumentar el alcance provoca un  incremento del trabajo (horas), así como del costo del proyecto. Es justo que haya remuneración al proveedor por este esfuerzo adicional, ya que la gestión del alcance es responsabilidad directa del cliente.

El aspecto más crítico de este tipo de contratación, es que el cliente es responsable por la gestión del equipo de servicio, incluyendo la productividad del proveedor. Esto requiere un nivel de competencia que puede no estar disponible internamente. Además, la remuneración del proveedor no está vinculada a los resultados producidos,  sólo al número de horas realizado. No hay incentivo para que el proveedor mantenga o aumente los niveles de productividad y calidad, lo que debería ser parte de su responsabilidad. El incentivo es negativo: en cuanto más esfuerzo se demande por parte del  proveedor, mayor será la remuneración. ¡Y esta es la antítesis de la productividad!

Otro obstáculo está relacionado con las garantías de servicio. Si la asignación implica más de una empresa, es muy difícil aislar las responsabilidades de cada empresa y exigir la garantía. El cliente paga por un servicio y también por cualquier mantenimiento posterior  correctivo asociado a éste.

Contratar a un precio fijo

Este tipo de contratación, también conocido como fixed price, favorece el enfoque de proyecto con un comienzo y un final bien definidos (y por supuesto, del alcance). Además, este modelo requiere un mayor nivel de organización del cliente y del proveedor. Si los requisitos están mejor definidos hay menos posibilidades de fricción entre las partes.

Sin embargo, es probable que el proveedor no tenga mucha información, no domine el problema o no dedique tiempo para un análisis detallado de los requisitos para la preparación de su propuesta de negocio. Como resultado, habrá un subdimensionamiento o sobredimensionamiento del presupuesto presentado. Cuando la competencia es intensa, es probable que el primer caso se produzca.

Ambos casos son indeseables. En el primero, el proveedor tendrá dificultades para atender al cliente. Si los requisitos no están bien definidos, es probable que se cree un callejón sin salida y una nueva negociación comercial tendrá que ser considerada. Aunque los requisitos hayan sido bien definidos, el presupuesto por el proveedor puede haber sido insuficiente y la calidad del producto se vea seriamente afectada o incluso el proyecto no pueda ser completado.

En este modelo hay una transferencia del riesgo del cliente al proveedor, y surgen los cuestionamientos con respecto al riesgo del alcance (¿los cambios serán alojados sin coste adicional?) y de la productividad (¿cuál es el nivel de control sobre los vectores que afectan el trabajo?). El precio propuesto por los proveedores debe tener en cuenta estos riesgos.

El uso de este enfoque se complica cuando se asume que los requisitos no cambiarán (o habrá poco cambio) después del inicio del proyecto. El entorno de una organización se es dinámico, los requisitos también lo son. En cuanto más larga sea la duración del proyecto, es más probable que hayan cambios en los requisitos. Aparte es difícil de estimar cómo estos cambios afectan el presupuesto original del proveedor. De acuerdo con [7] más de 2% de los requisitos cambian mensualmente después de la fase de requisitos. En este caso, es probable que sea necesaria una renegociación. Si esto ocurre, el cliente no tendrá la misma condición original, ya que dependiendo de qué fase el proyecto esté, no hay competencia, ni una unidad para comparar el precio originalmente acordado con los precios cobrados de acuerdo a las nuevas características solicitadas.

En este modelo de contratación, el control sobre la cantidad a pagar lo tiene el proveedor. Es muy común que la formación de precios se efectúe en términos de la estructura de descomposición del proyecto de trabajo, la cantidad de las horas y el perfil de profesionales asignados a esa actividad. Esto también ocurre con la contratación por hora-hombre, el control está bajo quienes poseen los conocimientos técnicos de ingeniería de software y la aplicación de sus disciplinas.

Un modelo alternativo de contratación

Con el tiempo, algunas organizaciones comenzaron a experimentar con formas alternativas de contratación de servicios de software que promovían una mejor distribución de los riesgos y resultados. En el modelo hora-hombre, la productividad del trabajo es un problema de gestión del cliente, cuando debería ser preocupación del proveedor. La administración del alcance también es responsabilidad del cliente, ya que el proveedor no tiene control sobre los requisitos. En el modelo de precio fijo, la productividad es responsabilidad del proveedor, lo que es justo, ya que este es responsable del proceso de trabajo. Sin embargo, cualquier cambio o incertidumbre de los requisitos, que es responsabilidad del cliente, impacta este modelo de contrato.

Por lo tanto, un modelo de contratación óptimo sería la remuneración de acuerdo con las unidades de resultado del servicio realizado. Esto promueve el balance de riesgos y responsabilidades entre cliente y proveedor. En este caso, la productividad es  responsabilidad del proveedor, ya que existe un riesgo de lesiones si hay retraso en las unidades de producción. Además, en el caso de que exista un aumento en el alcance, se debe construir más unidades para el servicio y el proveedor es remunerado por ello.

El gran desafío de este enfoque es encontrar una unidad que sea reconocida de manera inequívoca, uniforme y consistente tanto para el cliente como para el proveedor. Ejemplos de unidades podrían ser: pantallas, informes, tablas, casos de uso, líneas de código, stored procedures, webservices, puntos de función, entre otros. Pero no todas estas unidades cumplen con los criterios para ser reconocidos por el cliente y el proveedor de forma consistente.

Al analizar las unidades de carácter más técnico, no se tiene en cuenta la visibilidad de estas por parte del cliente. La relación (si existe) entre las líneas de código, por ejemplo, y algo de valor tangible al cliente es muy débil. El cliente no siempre tiene toda la experiencia para atribuir valor a un servicio que involucró a escribir un cierto número de líneas de código. A menudo, una de las razones para la externalización es precisamente la búsqueda de un proveedor con más conocimientos especializados en un tema, que no es de interés para el cliente y no le generará interés de tener dominio.

Al analizar algunas unidades menos técnicas, tales como pantallas, tablas, informes, casos de uso o los puntos de función, estos tienen unidades que son fácilmente reconocidas y comprendidas por ambas partes. La cuestión ahora es encontrar una definición consistente para esta unidad. En el caso de las pantallas, tablas, informes y casos de uso, no hay definición normalizada. A pesar de que hay buenas prácticas, y hacen uso del sentido común para definir lo que debería ser o no un caso de uso o una pantalla, estas unidades no son suficientes para ser utilizadas como una unidad de medida de contratos. En un extremo el cliente puede manejar el servicio de todo el sistema si se especializa en solo un caso de uso para minimizar el costo; en caso contrario,  el proveedor puede dividir la especificación del sistema en casos de uso para aumentar su remuneración.

El tamaño funcional puede ser considerado una unidad viable de medida en los contratos, precisamente porque son una medida de carácter no técnico, con una definición estándar, y consistente.

Por otra parte, la contratación de los servicios basado en los resultados entregados, permite al cliente tener más control sobre los costos.

La medición funcional del software

La medición funcional mide el software mediante la cuantificación de sus tareas y servicios, es decir, las características que el software proporciona al usuario. En resumen, mide los requisitos funcionales del software.

La idea es que la medición funcional sea:

• Lo suficientemente simple para reducir al mínimo el costo adicional del proceso de medición.
• Una medida consistente entre los diversos proyectos y organizaciones.

El resultado de la medición es llamado tamaño funcional y a menudo expresado en una unidad llamada punto de función (PF).

Hay cinco métodos de medición funcional estándares: IFPUG (ISO/IEC 20926), NESMA (ISO / IEC 24570), Mark II (ISO / IEC 20968), COSMIC (ISO/IEC 19761) y FISMA (ISO/ IEC 29881).

Modelo de costos

Un modelo para la prestación de servicios de software basado en el tamaño funcional puede ser representado por las fórmulas siguientes, que en la práctica son similares.

Esfuerzo = Tamaño x Tasa de entrega (1)

En esta primera fórmula, el esfuerzo del proyecto que se ejecutará es estimado (en horas) teniendo en cuenta el tamaño (en puntos de función) y una tasa de entrega pre-definida (horas por puntos de función). Esta tasa es definida, de acuerdo con el proveedor y un estudio de  productividad del cliente basado en una muestra histórica de proyectos ya implementados. El costo del proyecto se deriva simplemente de la multiplicación del esfuerzo calculado por un valor de horas acordado entre el cliente y el proveedor.

Costo = Tamaño x Precio por Unidad (2)

En esta segunda fórmula el costo del proyecto se calcula directamente con el tamaño funcional multiplicado por el precio unitario de este. Para establecer el precio que se ofrece, los proveedores deben tener en cuenta todo el proceso de trabajo definido por el cliente en el Request for Proposal.

Ambas fórmulas son equivalentes, ya que el esfuerzo se puede convertir en costos, como en el precio unitario es definido (o debería ser definido) según la productividad esperada para el contrato.

Al igual que las características de los servicios que se exigen en el contrato, el modelo puede ser refinado (y por lo general esto se hace) con el uso de diferentes indicadores de  la tasa de entrega (H/PF) o el precio de la unidad ($/PF), calibrado para especificidades de cada tipo de servicio.

Para organizaciones grandes los procesos de contratación son a menudo largos y costosos. Por lo tanto, el modelo descrito anteriormente se aplica generalmente no en un proyecto individual, sino a un volumen de puntos de función predefinidos para ser utilizados en varios proyectos durante un período por lo general de doce o más meses.  Este volumen se determina normalmente basado en los proyectos previstos por el área de sistemas en la planificación estratégica.

A medida que el tamaño funcional se realice con base a la vista externa del usuario, en contraste con una vista interna de la ingeniería de software, el cliente ejerce el control efectivo y la gestión de contratación. El perfil de los profesionales movilizados o la cantidad de horas trabajadas dejan de ser factores definitivos para el análisis. Se trata de un modelo en el que el tamaño funcional no cumple el papel de la estimación de esfuerzo o costo, sino de prescribir la cantidad que se pagará independientemente de su costo o esfuerzo real.

Al igual que los contratos de precio fijo, este modelo tiene riesgos. Sin embargo, con una mejor distribución. Las consideraciones acerca de la complejidad del trabajo en sus diversas dimensiones (excepto alcance de las funciones solicitadas y entregadas al usuario), y el perfil y la cantidad de profesionales asignados serán consideradas cuando se defina el precio por unidad ($/PF) o la tasa de entrega (H/PF).

El precio unitario, junto al tamaño funcional, prescribe la forma en la que el proveedor será recompensado por cada servicio prestado.

En un análisis específico de cada  proyecto entregado, la recompensa (o esfuerzo) aumenta o disminuye en comparación con lo realmente realizado. Este modelo utiliza como base el precio medio (o promedio de productividad) para la derivación del costo. Dado que hay una buena definición de los parámetros de precios, estas variaciones entre los proyectos tienden a anularse entre sí cuando se considera el conjunto de proyectos llevados a cabo en un horizonte de tiempo más largo (por ejemplo, un año).

Beneficios del modelo propuesto

Una de las razones para usar el modelo propuesto es que el vocabulario de la medición funcional utiliza la terminología y define elementos de análisis que son independientes de la tecnología utilizada para desarrollar el software. El proceso de medición sólo tiene en cuenta la perspectiva de negocio como se entiende y es válida para el cliente. La eliminación de estos tecnicismos facilita la comprensión entre las partes y es un motor importante para la comunicación entre cliente y proveedor.

Otra de las ventajas de este método, especialmente para el sector público, es que contratos remunerados por el tamaño funcional permiten auditoría externa de todos los pagos hechos. Algo que no puede ser hecho en un contrato por hora-hombre. Verificar horas trabajadas después del pago es muy difícil.  

Para los contratos basados en los puntos de función, el fraude es fácilmente detectado por la auditoría. A medida que la medición  funcional refleje funcionalidades entregadas por los proyectos, no hay manera de que sean falsificados.

Service Level Agreements (SLAs)

En este modelo hay interés directo de los proveedores para maximizar el flujo de las demandas entregadas, ya que implica un aumento de los ingresos. Para el cliente esto también es beneficioso, ya que proporciona más capacidad de respuesta a las necesidades de software de la organización.

Como también hay interés por parte del proveedor para entregar un servicio de calidad, ya que las correcciones implican repetición del trabajo, sin los ingresos asociados, el costo impacta a la rentabilidad del contrato.

Pronto podremos ver una convergencia de intereses en ambos lados para una rápida entrega y una mejor calidad del servicio entregado. Sin embargo, no se puede prescindir de los Acuerdos de Nivel de Servicio (Service Level Agreements), específicamente en plazo y calidad.

Cuando hay un retraso en la entrega del servicio, incluso si el cliente tiene la previsibilidad del saldo a pagar, este retraso puede resultar en pérdida de oportunidades para el negocio. Lo mismo se aplica a los defectos, aunque no hay costo adicional para las correcciones, esto puede afectar la fecha de entrega de una solución o incluso provocar un daño muy grande al negocio si la manifestación del defecto ocurre después del despliegue del software. Por lo tanto, es una buena práctica, el uso de SLA’s en los contratos basados en la medición funcional.

Dificultades comunes

Una dificultad para la adopción del modelo de contrato basado en el tamaño funcional es la poca madurez en proyectos en muchas organizaciones. Para aquellos que están en un modelo basado en hora-hombre, existe un gran impacto para promover este cambio. La contratación por el tamaño funcional consiste en trabajar enfocado en proyectos, lo que implica una buena planificación y evaluación del alcance. Sin embargo, la falta de planificación, documentación y visibilidad de los resultados producidos es común en contratos por hora-hombre.

Otro cuidado es no copiar modelos de costos de otras organizaciones, sin la calibración necesaria de sus parámetros con datos históricos propios. Cuando se utilizan parámetros de otras organizaciones (o precio unitario), los costos de la contratación pueden elevarse  o los proveedores serán oprimidos hasta llegar al punto de  rescindir el contrato.

Otra dificultad está relacionada con las mediciones, que deben centrar exclusivamente en las necesidades del negocio. Para aquellos que están involucrados en la implementación, a menudo hay una dificultad en la abstracción de la implementación y esto se refleja en una medición a menudo incorrecta (y por lo general, más grande).

Conclusión

El modelo de contratación de servicio de software por resultados ha sido madurado principalmente en Brasil y Corea del Sur durante los últimos quince años. En varios casos fueron percibidos  mejora de productividad, mejora de la calidad de la documentación de requisitos y resultados entregados con nivel de satisfacción más alto.   

Referencias

1. Vazquez, C. E.; Simões, G. S; Albert, R. M., “Análise de Pontos de Função: Medição, Estimativas e Gerenciamento de Projetos de Software”.  13ª ed., São Paulo-Brasil:  Editora Érica, 2013.
2. International Function Point User Group. http://ifpug.org
3. United Kingdom Software Metrics Association. http://uksma.co.uk
4. Common Software Measurement International Consortium (COSMIC). http://cosmicon.com
5. NESMA. http://nesma.org
6. Finnish Software Measurement Association (FISMA) http://fisma.fi
7. C. Jones.  “Conflict and Litigation Between Software Clients and Developers”, Software Productivity Research, Versión 10 . abr. 2001