En proyectos de software es normal que existan conflictos entre requerimientos, prioridades, restricciones e intereses de distintas personas. La negociación de requerimientos permite buscar acuerdos realistas cuando no todo puede satisfacerse al mismo tiempo.
Negociar no significa imponer una decisión ni aceptar todo lo que se pide. Significa analizar necesidades, valor, costos, riesgos y alternativas para llegar a una solución aceptable para el proyecto.
La resolución de conflictos es una habilidad esencial en ingeniería de requerimientos porque el software se construye dentro de organizaciones con objetivos, áreas y restricciones diferentes.
Los conflictos aparecen porque los interesados tienen perspectivas distintas. Cada área observa el sistema desde sus necesidades y responsabilidades.
Causas frecuentes:
Los conflictos pueden clasificarse según su origen.
| Tipo | Ejemplo |
|---|---|
| Conflicto de alcance | Un área quiere incluir pagos en línea en la primera versión, pero el alcance aprobado lo excluye. |
| Conflicto de prioridad | Ventas prioriza registro rápido de pedidos y administración prioriza controles de crédito. |
| Conflicto de reglas | Un área permite cancelar pedidos confirmados y otra lo prohíbe. |
| Conflicto técnico | El negocio pide tiempo real, pero el sistema externo solo permite sincronización nocturna. |
| Conflicto de calidad | Se quiere máxima seguridad, pero también acceso sin pasos adicionales. |
| Conflicto de recursos | El presupuesto no alcanza para todas las integraciones solicitadas. |
Una posición es lo que alguien pide. Una necesidad es el motivo que hay detrás del pedido.
Ejemplo:
Si se negocia solo la posición, parece que la única solución es una aplicación móvil. Si se entiende la necesidad, pueden evaluarse alternativas: sitio web adaptable, modo sin conexión, mejora del sistema actual o integración con herramientas existentes.
La negociación debe apoyarse en criterios explícitos, no solo en opiniones.
Criterios útiles:
Estos criterios ayudan a discutir con más objetividad.
Negociar muchas veces implica encontrar alternativas. Una necesidad puede satisfacerse de distintas formas.
| Pedido inicial | Necesidad posible | Alternativas |
|---|---|---|
| Crear un tablero avanzado. | Ver reclamos críticos rápidamente. | Lista filtrada, alerta por correo, tablero simple inicial. |
| Integración en tiempo real. | Tener datos actualizados para decidir. | Sincronización cada hora, consulta puntual, actualización nocturna con alerta. |
| Formulario con muchos campos obligatorios. | Evitar datos incompletos. | Guardar borrador, validación por etapa, campos obligatorios solo al confirmar. |
Una concesión es aceptar modificar una expectativa para lograr un acuerdo viable. Las concesiones deben ser explícitas.
Ejemplos:
Las concesiones deben registrarse para evitar que luego se interpreten como omisiones.
La negociación de alcance aparece cuando hay más requerimientos de los que pueden construirse en una entrega.
Preguntas útiles:
El alcance negociado debe quedar documentado.
También pueden negociarse niveles de calidad, siempre que no se comprometan aspectos obligatorios o críticos.
Ejemplos:
La calidad no debe quedar indefinida. Si se negocia, debe especificarse el nivel acordado.
Un conflicto frecuente aparece entre seguridad y facilidad de uso.
Ejemplo:
Una solución negociada podría ser solicitar confirmación adicional solo para operaciones críticas, mantener sesión activa por un tiempo razonable y registrar auditoría detallada.
La clave es entender el riesgo y el impacto en la operación.
Los sistemas suelen cruzar varias áreas. Cada una puede optimizar su propio trabajo, pero el proceso completo necesita equilibrio.
Ejemplo:
El análisis debe buscar una solución que mantenga velocidad comercial sin romper controles necesarios.
En una negociación de requerimientos, el facilitador ayuda a ordenar la conversación y mantener foco en el objetivo del producto.
Responsabilidades:
El facilitador no siempre decide, pero ayuda a que la decisión sea más clara.
No todos los conflictos pueden resolverse por consenso. A veces se necesita una persona o grupo con autoridad para decidir.
Conviene definir:
Sin responsables claros, los conflictos pueden permanecer abiertos y bloquear el avance.
Todo acuerdo importante debe registrarse.
El registro puede incluir:
Documentar acuerdos evita discusiones futuras basadas en recuerdos distintos.
Una empresa solicita que el sistema de pedidos consulte stock en tiempo real. El equipo técnico informa que el sistema de inventario no soporta tantas consultas sin afectar rendimiento.
Después de analizar la necesidad, se descubre que los vendedores solo requieren confirmar disponibilidad antes de cerrar pedidos importantes.
Acuerdo:
La solución no satisface exactamente el pedido inicial, pero atiende la necesidad principal dentro de una restricción técnica.
A veces se acepta una solución temporal para poder avanzar. Esto es válido si se registra claramente.
Ejemplos:
El riesgo es que lo temporal se vuelva permanente sin revisión. Por eso debe quedar trazado.
Algunas señales indican que un conflicto sigue abierto:
Cuando esto ocurre, conviene detenerse y resolver antes de construir sobre una base inestable.
Al negociar requerimientos, suelen aparecer estos errores:
Algunas buenas prácticas son:
La negociación de requerimientos y la resolución de conflictos permiten convertir necesidades distintas en acuerdos posibles. Son actividades fundamentales cuando existen restricciones de tiempo, presupuesto, tecnología, normativa o prioridades incompatibles.
Un buen acuerdo no siempre satisface todos los deseos iniciales, pero debe responder a objetivos reales, respetar restricciones y quedar claramente documentado.
En el próximo tema estudiaremos la especificación de requerimientos de software, donde se formaliza la información analizada, refinada y acordada.