Notas de versión enterprise: qué cambia para una sola cuenta
5 min de lectura
Un producto SaaS público envía las mismas notas de versión a todo el mundo, porque todo el mundo está en la misma versión. Una clienta enterprise en una versión fija, una instancia dedicada, o un subconjunto del producto con feature flags rompe ese supuesto: las notas de versión que describen qué cambió para ella no son las mismas que las de tu blog público, y enviarle las públicas de todos modos o bien la confunde con cambios que aún no tiene, o, peor, le cuenta sobre una función que el equipo de cuenta de otra clienta enterprise te pidió expresamente retener de la suya un mes más. Buenas prácticas para notas de versión cubre el oficio general; esto trata de escribir notas de versión enterprise para el problema de ajuste que aparece en cuanto tienes clientas que no están todas en el mismo build.
¿Por qué no puede una clienta enterprise simplemente leer el changelog público?
Porque describe una versión que quizás todavía no ejecuta, funciones a las que quizás no tiene acceso, y un calendario que no coincide con el suyo. Una clienta fija a un ciclo de lanzamiento trimestral que lee sobre una función que salió a la capa pública la semana pasada no tiene forma de saber, solo con el changelog público, si esa función le llegará la semana que viene o el próximo trimestre. El changelog público responde “qué cambió en el producto”; la pregunta real de una clienta enterprise es “qué cambió en la versión que estoy ejecutando, y cuándo recibo el resto”, algo que el changelog público nunca estuvo escrito para responder.
¿Qué necesita una nota de versión privada que una pública no necesita?
Un identificador de versión o entorno contra el que la clienta pueda verificar de verdad, y una declaración explícita de qué no le ha llegado todavía. “Esta versión incluye las mejoras de exportación masiva de nuestro lanzamiento público 4.3, pero no el nuevo modelo de permisos, que llega en tu próxima actualización programada” le dice a una administradora enterprise exactamente dónde está su instancia respecto al producto en general. Una nota de versión pública nunca necesita este encuadre porque solo hay una instancia respecto a la cual ser relativa; una privada carece de sentido sin él.
| Notas de versión públicas | Notas de versión privadas (enterprise) |
|---|---|
| Una versión, una audiencia | Múltiples versiones, audiencias segmentadas |
| Asume que la lectora tiene cada función descrita | Debe decir qué tiene y qué no tiene la lectora |
| Sincronizadas con el lanzamiento público | Sincronizadas con la ventana propia de actualización de la clienta |
| Se puede hacer completamente pública de inmediato | Puede necesitar ocultar puntos que otras clientas aún no tienen |
¿Alguna vez está bien simplemente retrasar el envío de las notas públicas a clientas enterprise en vez de escribir unas separadas?
Solo si su versión de verdad coincide con la pública en ese momento, lo cual es más raro de lo que suena en cuanto tienes más de un par de cuentas enterprise en calendarios distintos. Retrasar las notas públicas funciona como parche para una clienta que va una versión atrás y está por alcanzarla; se rompe en el momento en que dos clientas enterprise están en versiones distintas entre sí, porque entonces ya no hay “las notas” únicas que retrasar, solo una matriz de lo que tiene cada una. En ese punto, ajustar las notas por cuenta, aunque sea solo una vista filtrada de las mismas entradas subyacentes, deja de ser opcional.
Notas públicas, enviadas a una cuenta enterprise que
todavía no tiene la función:
"New: Bulk export now supports custom column ordering."
(Confuso: la admin lo prueba y no está.)
Notas enterprise ajustadas para la misma cuenta:
"Available in your next update (scheduled for 2026-10-15):
bulk export with custom column ordering. Not yet available
on your current version (3.8)."¿Quién dentro de la organización de la clienta lee esto realmente, y eso cambia cómo se escribe?
Normalmente una administradora de TI o una contacto de customer success en vez de una usuaria final, y eso cambia lo que cuenta como útil. Una usuaria final quiere saber qué se ve distinto en su pantalla; una administradora enterprise quiere saber qué cambió en permisos, manejo de datos, configuración de SSO, o cualquier cosa que afecte cómo gestiona el despliegue para sus propias usuarias, porque será ella quien responda las preguntas internas. Una nota de versión privada que se lee como un changelog de consumidor, todo botones nuevos y relucientes y nada de detalle operativo, obliga a la administradora a rebuscar la información que en realidad necesitaba.
¿Cómo interactúa esto con un roadmap público o un changelog público que ya lista la misma función?
Con cuidado, porque una clienta que lea ambos notará cualquier inconsistencia. Si tu changelog público ya anunció una función que una cuenta enterprise específica todavía no tiene, su nota de versión privada necesita reconocer esa brecha en vez de fingir que la entrada pública no existe; una administradora que vio el anuncio público y recibe notas privadas que lo ignoran asumirá o bien que te olvidaste de ella, o que algo está roto. Roadmap pública cubre cómo mantener un roadmap honesto sobre qué se lanzó frente a qué está planeado; la versión enterprise de esa honestidad en notas de versión es nombrar directamente la brecha entre lo público y lo suyo.
¿Necesita una empresa pequeña con solo una o dos clientas enterprise tanta estructura?
No el sistema completamente segmentado, pero la disciplina central, decir con claridad en qué versión está la clienta y qué tiene y qué no tiene, importa en cualquier escala en cuanto tienes aunque sea una clienta que no está en tu build más reciente. El modo de falla que esto previene, una administradora confundida sobre si un anuncio público le aplica, cuesta un ticket de soporte y un golpe a la confianza sin importar si tienes dos cuentas enterprise o doscientas.
FAQ
¿Deberían las notas de versión privadas mencionar alguna vez funciones que otras clientas ya tienen pero esta no? Solo si es relevante para su propio calendario, expresado como “llega en tu próxima actualización” en vez de como comparación con otras clientas. Nombrar lo que tiene otra clienta específica cruza un territorio que no te corresponde revelar; nombrar lo que llega específicamente a esta clienta es exactamente la información que necesita.
¿Pueden las mismas entradas de changelog subyacentes alimentar tanto notas públicas como privadas? Sí, y ese suele ser el enfoque más mantenible: etiqueta las entradas según a qué versiones o niveles aplican, y luego filtra por audiencia al publicar en vez de escribir dos documentos totalmente separados que inevitablemente se desincronizan.
¿Qué pasa si una clienta enterprise pide explícitamente estar en las notas públicas en vez de en un feed privado? Respétalo, pero confirma que entiende que las notas públicas asumen la versión pública, y señala tú misma por escrito la brecha si su versión difiere de lo descrito. Esa confirmación escrita es lo que te protege después si actúa según notas públicas que en realidad no aplicaban a su build.
¿Con cuánta anticipación debería avisarse a una clienta enterprise sobre una función a la que tendrá acceso en el próximo lanzamiento? En cuanto la fecha esté confirmada, no solo al momento del lanzamiento, porque las administradoras enterprise a menudo necesitan planear su propia comunicación interna o capacitación alrededor de una función que llega, y una notificación el mismo día no les deja margen para eso.
Las afirmaciones técnicas de este artículo no se han revisado de forma independiente. Si algo está mal, avísanos y lo corregiremos.