Decir que no a un feature (con una alternativa)

A veces un pedido es razonable del lado del negocio y destructivo para el modelo. Editar una factura saldada. Borrar una entrega que ya ocurrió. Asignar stock que todavía no existe.

El instinto es explicar por qué está mal. Rara vez funciona: del lado del cliente la explicación suena a excusa, y ellos tienen un problema real ahora.

Separar el pedido de la solución

Casi siempre hay una necesidad genuina debajo, y la implementación específica que pidieron es solo la primera que se les ocurrió:

• “Dejame editar esta factura” suele ser “me equivoqué y necesito que el cliente tenga el documento correcto”. La respuesta es una nota de crédito y una reemisión — que quizás no saben que existe.
• “Borrá esta entrega” suele ser “esto no debería contar en el reporte”. Eso es un estado, no un borrado.
• “Dejame vender stock que no tengo” muchas veces es una práctica comercial real — la venta en falta / backorder — que merece modelarse en vez de esquivarse con un workaround.

Entonces la respuesta no es “no”. Es: esto es lo que entiendo que necesitás, esta es una forma de lograrlo que el sistema puede sostener, y esto es lo que la versión original nos costaría después.

Las dos cosas en las que aprendí a ser firme

Nada que haga mentir a la trazabilidad se construye, en ninguna versión. No es una preferencia mía: los protege a ellos.

Cuando acepto un atajo a sabiendas, dejo escrito que es un atajo y por qué — para que sea una decisión y no un accidente.

Decir que no sin una alternativa es, simplemente, ser difícil.