El Correo Que Arruina Cualquier Lunes

Una clienta me escribió el año pasado, molesta con toda razón. Su sitio tenía una función de búsqueda. Los clientes escribían el nombre de un producto y recibían resultados. Ella quería agregar un filtro para que la gente pudiera ordenar esos resultados por precio. Para ella, eso era obviamente parte de la "búsqueda". Ya había pagado por la búsqueda. ¿Por qué le estaba cotizando trabajo adicional?

Recibo una versión de este mensaje más que casi cualquier otra cosa que escucho de mis clientes. Alguien cree que un desarrollador está inflando la factura, o negándose a arreglar algo que rompió. Casi siempre, lo que en realidad está pasando es una confusión entre dos cosas muy distintas: un error y una solicitud de función nueva.

Esta confusión causa más fricción entre dueños de negocio y desarrolladores que casi cualquier otro tema. No se trata de deshonestidad de ningún lado. Se trata de que dos personas usan la misma palabra, "roto", para referirse a dos cosas distintas. Una vez que entiende la diferencia real, la discusión casi siempre desaparece, y puede planear su presupuesto con mucho menos estrés.

La Única Pregunta Que Resuelve Todo

Aquí está la prueba simple que yo uso, y usted también puede usarla: ¿Acordamos que haría esto?

Si la respuesta es sí, y no lo está haciendo, es un error. Algo se prometió, se construyó, o funcionaba, y ahora ya no. Eso le corresponde corregirlo al desarrollador, normalmente sin costo adicional, porque es una promesa incumplida, no trabajo nuevo.

Si la respuesta es no, es decir, nadie especificó ese comportamiento, entonces es una solicitud de función nueva. No es que el software falle en hacer lo que debía hacer. Es que usted está pidiendo algo que nunca se construyó para hacer eso. Eso es trabajo nuevo, y el trabajo nuevo cuesta dinero y toma tiempo, de la misma forma en que pedirle a un contratista que agregue una habitación no está cubierto por la garantía de la casa que ya construyó.

Volvamos al ejemplo de la búsqueda. El acuerdo original cubría una caja de búsqueda que devolvía productos coincidentes. Nunca mencionó filtrar por precio. Entonces, aunque "búsqueda" se sienta como una sola función para un cliente, el filtro nunca fue parte de lo que se construyó o se acordó. Eso lo convierte en una solicitud de función nueva, no en un error.

Por Qué Esta Distinción Protege a los Dos Lados

Es tentador pensar que esta regla solo protege al desarrollador, dejándolo cobrar por cualquier cosa que no quiso construir la primera vez. En realidad, lo protege a usted igual.

Sin una línea clara entre error y función nueva, usted no tiene forma de saber si una cotización es justa. Si todo se puede etiquetar como "función nueva", un desarrollador podría cobrarle por corregir sus propios errores. Si todo se puede etiquetar como "error", usted podría seguir ampliando el proyecto gratis y nunca pagar por el valor que realmente está recibiendo. La prueba de error contra función nueva mantiene honestos a los dos lados. Dice: las promesas rotas se corrigen gratis, y el valor nuevo cuesta dinero. Eso es un trato justo, y es la misma lógica detrás de cualquier garantía con la que haya lidiado, en un auto, un electrodoméstico o una pieza de software.

Por eso una especificación real es tan importante desde el principio. Ya escribí antes sobre cómo leer una cotización de software, y la versión corta es: las cotizaciones vagas crean expectativas vagas, y las expectativas vagas son justo lo que convierte una pequeña solicitud de filtro en una llamada tensa.

Las Zonas Grises, y Cómo Manejarlas

La mayoría de los casos son claros. Un botón de inicio de sesión que antes funcionaba y de repente dejó de hacerlo es un error. Pedir una aplicación móvil completamente nueva cuando solo pagó por un sitio web es obviamente una función nueva. Pero algunas situaciones quedan en el medio, y ayuda saber cómo se suelen manejar:

  • "Debería haber sido obvio." A veces un dueño de negocio asume que una capacidad estaba implícita, aunque nadie la haya escrito. Los desarrolladores razonables suelen tratar los vacíos pequeños y genuinamente obvios de buena fe y los corrigen sin costo. Pero "obvio" es subjetivo, así que mientras más específica haya sido su solicitud original, menos aparece este problema.
  • Casos que se pasaron por alto. Si el software falla en un caso que nadie pensó en probar, como un cliente que escribe un nombre con un carácter poco común, eso normalmente se trata como un error, aunque no estuviera listado explícitamente. La intención era que la función funcionara de forma confiable, y no lo hizo.
  • "Es solo un ajuste pequeño." Muchas solicitudes de función nueva se presentan como cambios pequeños para que suenen como si debieran ser gratis. El tamaño no decide la categoría. Un cambio de cinco minutos a algo que nunca se acordó sigue siendo una función nueva. Una corrección de dos días a algo que sí se prometió sigue siendo un error.

Cuando algo cae en una zona gris, la forma más rápida de resolverlo no es discutir. Es abrir el acuerdo o la especificación original y revisar, en lenguaje simple, si ese comportamiento estaba descrito. Ese único paso termina la mayoría de las disputas en minutos.

Cómo una Especificación Clara Evita la Discusión Desde el Principio

La solución real no es un mejor argumento durante la disputa. Es evitar la disputa desde el principio. Una especificación clara y por escrito antes de empezar el trabajo, que liste lo que el software realmente hará, lo protege a usted de facturas sorpresa y protege a su desarrollador de que el proyecto crezca sin control. Cuando los dos lados pueden señalar el mismo documento y preguntar "¿acordamos esto?", ya no queda nada que discutir.

Si alguna vez se sintió sorprendido por una cotización o una factura, la solución casi nunca es cambiar de desarrollador. Es tener una conversación más específica antes de empezar el trabajo, junto con el tipo de relación de mantenimiento continuo que separa con claridad "mantener funcionando lo que ya construimos" de "construir algo nuevo".

La Conclusión

Un error es una promesa rota. Una solicitud de función nueva es una promesa nueva. Saber cuál de las dos tiene enfrente, y hacer la única pregunta que lo resuelve, le ahorra dinero, le ahorra un dolor de cabeza a su desarrollador, y mantiene su proyecto avanzando en lugar de estancado en una discusión sobre quién debe qué.

Si está viendo una cotización o una factura y no sabe de qué lado de la línea está, hablemos de su situación.