Un alcance de servicio claro y sin ambigüedades: 10 elementos para que el cliente sepa qué compra

La normativa federal estadounidense vigente para servicios basados en resultados recomienda describir el trabajo principalmente mediante los resultados exigidos, en lugar de imponer cómo debe realizarse o limitarse a indicar un número de horas. También contempla estándares de desempeño medibles y, en las declaraciones de objetivos, elementos como propósito, alcance, periodo y lugar de ejecución, contexto, resultados requeridos y restricciones operativas. [1]

El Digital, Data and Technology Playbook del Gobierno del Reino Unido también promueve especificaciones claras orientadas a resultados. Recomienda expresamente centrarse en el usuario y en el problema que debe resolverse, y no imponer de antemano una solución técnica concreta. [2]

La guía británica actual sobre distribución de riesgos y enfoques de precios añade que los indicadores de desempeño deben ser medibles y objetivos, y que el proveedor debe responder por resultados sobre los que realmente puede influir. [3]

Estas fuentes pertenecen a la contratación pública y no constituyen una plantilla universal para todos los servicios. Sin embargo, muestran un principio muy útil: un buen alcance debe nombrar el resultado esperado, cómo puede evaluarse y los límites de la responsabilidad.

Una buena descripción debe ayudar al mismo tiempo:

Al cliente - a entender qué recibirá, qué no recibirá y qué se le pedirá.

Al especialista - a definir los límites de responsabilidad, los supuestos y el momento en que una nueva petición se convierte en un cambio de alcance.

A ambas partes - a acordar cómo determinar razonablemente que el trabajo pactado ha sido completado.

Si la descripción cumple bien solo una de estas funciones, todavía puede dejar demasiado espacio para disputas o interpretaciones diferentes.

Empieza explicando por qué se necesita el servicio.

No comiences por una lista de herramientas o tareas si el cliente todavía no entiende el objetivo.

En lugar de:

"Configuración de analítica, informes y eventos."

mejor:

"El objetivo es obtener datos fiables sobre las etapas del formulario en las que los usuarios abandonan con mayor frecuencia, para que el equipo pueda identificar los puntos que necesitan mejora."

Este enfoque coincide con el principio de describir necesidades y resultados en vez de imponer una solución, promovido por el Digital, Data and Technology Playbook británico. [2]

El objetivo responde a "¿por qué?", mientras que el resultado responde a "¿qué debe existir o ser cierto al terminar el trabajo?"

Un resultado puede ser, por ejemplo:

• un documento terminado,
• una función operativa,
• una configuración implementada,
• una investigación finalizada con conclusiones,
• un conjunto de materiales preparados,
• una sesión realizada con un resumen definido.

Para los servicios basados en resultados, la FAR describe los requisitos principalmente mediante los resultados requeridos y no solo por la forma de ejecución. [1]

Esto no significa que cada servicio deba garantizar un resultado empresarial que el especialista no controla. Se puede comprometer a lanzar una campaña dentro del alcance acordado, pero garantizar un aumento del 30% en ventas puede depender de muchos factores fuera del control del proveedor.

El alcance debe nombrar las partes concretas del trabajo incluidas en el acuerdo.

Por ejemplo, en un proyecto de sitio web puede incluir:

• revisión del sitio actual,
• preparación de la arquitectura de información,
• diseño de un número definido de vistas,
• versiones para dispositivos móviles,
• implementación del diseño aprobado,
• documentación básica de entrega.

No se trata de crear la lista más larga posible. Se trata de nombrar los elementos principales que afectan al esfuerzo y a las expectativas antes de empezar el trabajo.

El alcance describe el trabajo, mientras que los entregables describen qué recibirá realmente el cliente.

Por ejemplo:

• un archivo fuente,
• un informe en un formato definido,
• un módulo operativo,
• un repositorio de código,
• un conjunto de gráficos,
• una grabación,
• documentación,
• una lista de recomendaciones,
• acceso a un entorno configurado.

Si la forma del resultado importa, indícala. "Informe" puede significar dos páginas de texto o un documento detallado con análisis, prioridades y ejemplos. El nombre por sí solo no siempre basta.

Los criterios de aceptación responden a la pregunta: ¿cómo se puede determinar que el resultado acordado se ha entregado conforme al requisito?

Pueden referirse, por ejemplo, a:

• integridad,
• cumplimiento de la especificación acordada,
• un formato concreto,
• funcionamiento en dispositivos o entornos indicados,
• un número máximo de errores de una categoría definida,
• tiempo de entrega,
• parámetros de calidad determinados.

La FAR exige que los estándares de desempeño en contratos de servicios basados en resultados sean medibles y permitan evaluar la ejecución. [1]

La guía británica sobre riesgos añade que las medidas deben ser objetivas y referirse a resultados sobre los que el proveedor pueda influir. [3]

Por eso, "el cliente estará satisfecho" es un criterio mucho menos útil que uno vinculado a un resultado específico y observable.

Un servicio suele depender de acciones de la otra parte.

Conviene indicar si el cliente debe proporcionar:

• acceso a sistemas,
• contenidos o materiales,
• datos,
• información de marca,
• decisiones y aprobaciones,
• una persona de contacto,
• un entorno de prueba,
• respuestas dentro de un plazo definido.

Si la falta de materiales del cliente puede detener el trabajo, debe quedar claro.

La responsabilidad por los plazos no debería redactarse como si el especialista controlara acciones que en realidad no controla.

El precio y el plazo suelen ser válidos únicamente bajo determinados supuestos.

Ejemplos:

• la base de datos existente está disponible y funciona correctamente,
• el cliente tiene derechos sobre los materiales que entrega,
• un sistema externo dispone de una interfaz operativa,
• el proyecto no requiere migrar datos históricos,
• el número de versiones lingüísticas está fijado de antemano,
• las decisiones serán tomadas por una persona designada.

La guía de GAO sobre estimación fiable de costes considera importantes la definición clara del alcance, la base técnica, las reglas y supuestos, así como el análisis de riesgo e incertidumbre. [7]

Un servicio pequeño no necesita copiar un proceso pensado para grandes programas. Sin embargo, la regla sigue siendo útil: si la estimación depende de algo que puede resultar falso, indícalo.

Las exclusiones no son señal de una mala oferta. A menudo indican que el compromiso está bien definido.

Si algo puede confundirse fácilmente con una parte incluida, conviene indicar expresamente que no está incluido.

Por ejemplo:

• compra de licencias,
• creación de contenidos,
• imágenes de pago,
• traducciones,
• mantenimiento después del lanzamiento,
• trabajo sobre otro sistema,
• revisiones ilimitadas,
• costes de servicios de terceros.

No hace falta listar todo lo que el especialista no hará. Las exclusiones más útiles son aquellas que el cliente podría considerar razonablemente parte del servicio.

Un plazo debería decir algo más que "unas dos semanas" si el progreso depende de aprobaciones o materiales del cliente.

Conviene aclarar:

• qué evento inicia el plazo,
• si existen etapas intermedias,
• qué decisiones cierran cada etapa,
• cuánto tiempo tiene el cliente para responder cuando eso afecta al calendario,
• cómo se comunican los retrasos,
• cómo funciona la aceptación final.

En un servicio simple pueden bastar unas pocas frases. En una colaboración mayor, las etapas ayudan a ambas partes a entender qué ya se ha completado y qué debe suceder después.

Una buena descripción debe explicar qué ocurre cuando aparece un requisito nuevo una vez iniciado el trabajo.

Un mecanismo práctico puede ser muy sencillo:

"El trabajo fuera del alcance descrito requiere confirmar el nuevo alcance, su impacto en el plazo y cualquier precio adicional antes de comenzar ese trabajo."

También conviene indicar claramente:

• el modelo de cobro,
• el precio o cómo se calcula,
• las reglas de pago,
• costes adicionales que puedan aparecer,
• reglas para rondas adicionales de revisión.

Esto no elimina los cambios. Hace que el cambio sea una decisión consciente y no una ampliación oculta del compromiso original.

Un alcance claro no exige controlar cada paso del trabajo del especialista.

El Digital, Data and Technology Playbook británico advierte contra la especificación excesiva de la solución y señala que las especificaciones basadas en resultados pueden dejar al proveedor espacio para proponer una forma más eficaz de resolver el problema. [2]

La FAR también prefiere describir los resultados exigidos en lugar de imponer exactamente cómo debe ejecutarse el trabajo. [1]

Por eso:

"el sitio debe admitir correctamente los escenarios acordados en los dispositivos indicados"

puede ser un requisito mejor que imponer los detalles de implementación cuando la tecnología en sí no es una restricción esencial.

Por supuesto, en algunos servicios el método importa por seguridad, cumplimiento, integración o un estándar técnico requerido. En esos casos debe describirse.

Al definir el alcance es importante distinguir entre:

el resultado directo del trabajo del especialista y un resultado empresarial que depende también de otros factores.

Un especialista puede comprometerse a:

• preparar y lanzar una campaña dentro del alcance acordado,
• realizar un análisis,
• entregar un número definido de materiales,
• implementar una función que cumpla criterios establecidos.

Se debe tener mucha más cautela con garantías sobre ventas, número de clientes, posición en buscadores u otros resultados que dependan del mercado, el presupuesto, el producto, las acciones del cliente o sistemas externos.

La guía británica actual sobre distribución de riesgos indica expresamente que el proveedor debe responder por resultados sobre los que pueda influir. [3]

Una buena descripción no debilita la responsabilidad. La coloca allí donde existe control real.

No todos los servicios necesitan un documento de varias páginas.

En una tarea simple, toda la información esencial puede caber en unos pocos párrafos. En un proyecto mayor, el mismo razonamiento puede convertirse en una especificación detallada, un calendario, criterios de aceptación y un proceso formal de cambios.

Un ejemplo de Terms of Reference publicado por el Banco Mundial señala que el documento debe expresar claramente los requisitos de los servicios de consultoría y las expectativas de la entidad contratante, y adaptarse al proyecto concreto y a las circunstancias locales. [4]

La clave no es la longitud. La pregunta importante es si una información ausente podría cambiar de forma realista el precio, el plazo, la responsabilidad o el resultado esperado.

La descripción de un servicio en una web o perfil puede ser solo una parte del proceso contractual. Las obligaciones legales concretas dependen del país, el tipo de transacción, la condición de las partes y la forma de venta.

En relaciones entre empresa y consumidor en la UE, el portal oficial Your Europe identifica información previa al contrato como las principales características del servicio, el precio total con cargos, las condiciones de pago y ejecución y, cuando proceda, la duración del contrato. [5]

La guía de la UE para empresas también indica que las condiciones estándar de contratos con consumidores deben ser justas y redactarse en lenguaje claro y comprensible, de modo que el consumidor pueda entender sus consecuencias económicas. [6]

Estos requisitos afectan a determinadas relaciones de consumo en la UE. No deben extenderse automáticamente a todas las transacciones entre empresas ni a otras jurisdicciones.

Este artículo es una guía editorial sobre cómo describir servicios, no una plantilla contractual ni asesoramiento jurídico.

1. ¿El cliente entiende el problema u objetivo que aborda el servicio?
2. ¿Está nombrado el resultado final?
3. ¿Está claro qué se incluye en el alcance?
4. ¿El cliente sabe qué elementos concretos recibirá?
5. ¿Existe una forma razonable de evaluar la finalización?
6. ¿Está claro qué debe proporcionar o gestionar el cliente?
7. ¿Son visibles los supuestos más importantes?
8. ¿Están descritas las exclusiones evidentes que podrían causar confusión?
9. ¿Los plazos y etapas reflejan dependencias de ambas partes?
10. ¿Está claro qué sucede cuando cambia el alcance?
11. ¿El precio, el modelo de cobro y los costes adicionales se presentan en el momento adecuado?
12. ¿La descripción evita prometer resultados que el especialista no controla?

La mejor prueba de una buena descripción es sencilla.

Después de leerla, cliente y especialista deberían responder de forma parecida a estas preguntas:

¿Qué debe lograrse? ¿Qué se hará? ¿Qué recibirá el cliente? ¿Qué no está incluido? ¿Qué debe hacer el cliente? ¿Cómo sabremos que el trabajo está terminado? ¿Qué sucede si cambia el alcance?

Si las respuestas coinciden, el precio y el plazo tienen un contexto mucho mejor.

Si las respuestas son distintas, el problema muchas veces no empieza durante la ejecución. Empieza ya en la descripción del servicio.

[1] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
Abrir fuente

[2] UK Government - The Digital, Data and Technology Playbook
Abrir fuente

[3] UK Government - Risk Allocation and Pricing Approaches Guidance Note
Abrir fuente

[4] World Bank - Sample Consultants Terms of Reference
Abrir fuente

[5] Your Europe - Contract information: what you should know before buying
Abrir fuente

[6] Your Europe - Contracts with consumers
Abrir fuente

[7] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
Abrir fuente

Nota metodológica: las fuentes tienen ámbitos distintos y no forman un único estándar común para describir servicios. El artículo utiliza solo los principios que realmente respaldan: orientación a resultados, medición, alcance claro, supuestos, responsabilidad sobre factores bajo control del proveedor y transparencia de la información para el cliente.