Español

Levantamiento de requisitos que no muta durante el desarrollo

Faltan dos días para el lanzamiento. El panel de control está construido, probado y en cola para la demostración del lunes. Luego llega el correo: "Oye, ¿puedes agregar una cosa más? También lo necesitamos segmentado por región. Y quizás por antigüedad. Ah, y el CFO mencionó que quería una vista YoY." Se queda mirando la pantalla. Escribió un documento de requisitos. Realizó una reunión de inicio. Envió notas de reunión. Nada de eso detiene la solicitud, porque nada de eso es el artefacto que previene la mutación.

En teoría, esto es culpa del BA. No capturó los requisitos. No hizo las preguntas correctas. Debería haber sabido que al CFO le importaría el YoY. Ingeniería reconstruye el mismo gráfico por tercera vez en dos semanas. Las partes interesadas lo bajan silenciosamente de "socio de confianza" a "procesador de tickets." Empieza a añadir un 40% a cada estimación solo para absorber el inevitable retrabajo.

La solución no es más documentación. Es documentación diferente, escrita en los primeros 90 minutos, firmada antes de que se cree un solo ticket. Una página de entrada, una página de salida, con fecha, con nombre y enviada por correo electrónico a una persona con autoridad para decir sí. Todo lo demás es teatro.

Este es el Playbook que aplico en cada solicitud interna ahora: panel de control, análisis, herramienta interna, análisis ad hoc. Tarda 90 minutos en ejecutarse correctamente. Ahorra entre 2 y 3 semanas de reconstrucción por proyecto. La matemática no es sutil.

El formulario de admisión: una página, cinco casillas

El formulario de admisión es de una página. No de cinco. No de ocho. Una. Si se extiende a una segunda página, está permitiendo que el solicitante oculte un pensamiento vago detrás de un muro de texto. Cinco casillas. Si alguna de las cinco está en blanco, el proyecto no comienza. Eso no es una pauta. Es la regla.

Casilla 1: El problema. ¿Qué está roto ahora mismo? No "necesitamos un panel de control." Eso es una solución. El problema es "el responsable de CS pasa 4 horas cada lunes construyendo un informe de abandono de clientes a partir de tres archivos CSV y los números no coinciden con Salesforce." Si el solicitante responde "necesitamos un panel de control" de nuevo, pregunte: ¿qué le permitiría dejar de hacer el panel de control? Insista hasta que el verbo se elimine, no se agregue.

Casilla 2: La decisión que informará el resultado. Cada panel de control, cada informe, cada análisis existe para informar una decisión. Escriba la decisión. "Si ampliar el equipo de SDR a 12 u 8 representantes el próximo trimestre." "Si cancelar el plan heredado." "Si trasladar el presupuesto de marketing de redes sociales de pago a eventos." Si el solicitante no puede nombrar una sola decisión específica, la solicitud es decoración, no apoyo a la decisión. La casilla 2 es el eliminador de expansión del alcance más efectivo del formulario.

Casilla 3: La métrica de éxito. ¿Cómo sabremos que esto funcionó, seis semanas después? No "la gente lo usa." No "es útil." Un resultado medible: "El tiempo del informe de CS del lunes cae de 4 horas a menos de 30 minutos." "La decisión de cancelación se toma para finales de Q2 con justificación documentada." "El memorándum de reasignación del presupuesto de marketing hace referencia a este análisis." La casilla 3 es lo que comprueba en la validación posterior a la entrega. Si es vaga aquí, es inconmensurable más adelante, y el proyecto entra silenciosamente en el cementerio de "¿importó algo esto?"

Casilla 4: Dentro del alcance. Específico, con viñetas, finito. "Tasa de abandono de clientes por mes, por nivel de plan, por cohorte de registro. Filtrado a los últimos 12 meses. Se actualiza diariamente." Entre cinco y ocho viñetas máximo. Si tiene 14 viñetas, no está definiendo el alcance de un panel de control, sino de una plataforma.

Casilla 5: Fuera del alcance. Esta es la casilla que todos olvidan. Enumere explícitamente lo que no está construyendo. "Sin desglose por región. Sin desglose por representante de ventas. Sin historial más allá de 12 meses. Sin actualización en tiempo real. Sin exportación a Excel." La casilla de fuera del alcance es la única que se amortiza diez veces. Cuando el solicitante regrese en la semana tres pidiendo el desglose regional, usted señala la casilla 5. Él la nombró. Él la firmó. La conversación es breve, objetiva y sin emoción.

Si alguna de estas cinco casillas está en blanco o respondida a medias, rechace el proyecto. Con cortesía. "No puedo empezar hasta tener una respuesta específica para la casilla 2. ¿Qué decisión informará esto? ¿Podemos reservar 30 minutos para definirlo?" Rechazar no es grosero. Comenzar con una solicitud vaga y luego "perderse" los requisitos dos semanas después es grosero.

La pregunta "¿qué haría con la respuesta?"

Esta es la pregunta más útil en el trabajo de BA, y casi nadie la hace.

El contexto: el solicitante quiere un panel de control que muestre las puntuaciones de salud de los clientes. Usted pregunta, con calma: "Si la puntuación del Cliente X es 72, ¿qué haría? ¿Y si es 45? ¿Y si es 88?" Ocurren tres cosas.

Si puede responder con claridad ("Por encima de 80, sin acción. Entre 60 y 80, el CSM reserva un seguimiento. Por debajo de 60, va a la cola de retención"), tiene un requisito real. Los números se asignan a acciones. El panel de control es apoyo a la decisión.

Si vacila y dice "bueno, miraríamos la tendencia" o "depende" o "lo discutiríamos en la reunión semanal", tiene un requisito de decoración. Quiere que el número exista, no porque cambie el comportamiento, sino porque se siente responsable rastrearlo. Los requisitos de decoración representan entre el 60 y el 70% de las solicitudes internas, según mi experiencia. Constrúyalos y estarán sin usar durante seis meses.

Si se incomoda y dice "lo sabremos cuando lo veamos", tiene un requisito de percepciones. Peor que la decoración, porque el solicitante cree que sus percepciones son una especificación. Los requisitos de percepciones mutan a diario porque nunca fueron una especificación desde el principio.

El guion para hacer la pregunta sin sonar confrontacional importa. No diga "¿esto tiene alguna utilidad?" Diga: "Quiero asegurarme de construir lo correcto. Descríbame qué haría un lunes por la mañana si abriera esto y el número fuera [X]. Luego haga lo mismo si fuera [Y]." Está enmarcando el problema como suyo ("quiero construir lo correcto"), no como un interrogatorio. El solicitante generalmente responde honestamente porque no se da cuenta de que está revelando si el requisito es real o decorativo.

Si la respuesta es decoración o percepciones, tiene tres opciones. Opción uno: retirarse con cortesía, citando capacidad. Opción dos: construir una versión más pequeña y económica (una consulta SQL que puedan ejecutar, no un panel de control completo) y revisarlo en un mes. Opción tres: tener una conversación franca sobre si la pregunta de fondo es "no sabemos cómo gestionar esto todavía", que es un problema de descubrimiento, no un problema de panel de control, y probablemente necesita una hora de analista, no un Sprint de ingeniería.

Primero el prototipo, cuando sea posible

Antes de escribir cualquier SQL. Antes de crear cualquier ticket. Dibuje el panel de control.

Figma funciona. Google Sheets funciona mejor, honestamente, porque permite falsificar los datos y el solicitante puede escrutarlo como escrutaría la cosa real. PowerPoint con rectángulos funciona en apuros. El punto no es la herramienta. El punto es poner una imagen de la respuesta frente al solicitante antes de comprometer horas de ingeniería.

Una maqueta de 30 minutos elimina aproximadamente el 80% del retrabajo que de otro modo ocurriría durante el desarrollo. Ese número no es exacto. Es lo que he observado en aproximadamente 60 proyectos internos en los últimos años. A veces es el 95%. A veces es el 60%. Nunca está por debajo del 50%.

Lo que ocurre en la revisión del prototipo es que el solicitante finalmente ve de forma concreta lo que pidió y se da cuenta de una de tres cosas. (a) "Ah, en realidad necesito las filas ordenadas de otra manera." (b) "Pensé que quería un gráfico de barras, pero un gráfico de líneas con una media móvil de 4 semanas es lo que realmente necesito." (c) "Esto no responde mi pregunta. Necesito ver el desglose por [elemento no incluido en la solicitud original]." Los tres descubrimientos son gratuitos en una maqueta de Google Sheets. Son costosos en un panel de control construido.

El principio de primero el prototipo no aplica a todo. Cambios de backend, trabajo de integración, limpieza del pipeline de datos, migraciones de esquema: no hay una maqueta útil de 30 minutos para "necesitamos fusionar dos tablas de clientes." Cuando el principio de primero el prototipo no aplica, el sustituto es un ejemplo de salida escrito: "Aquí está la fila de datos que obtendrá de esta integración. Aquí están los cuatro campos. Aquí está lo que significa cada campo en inglés sencillo." Los ejemplos escritos son el equivalente del prototipo para el trabajo de backend. El mismo propósito: detectar malentendidos sin costo.

Aprobación formal de requisitos: escrita, con fecha, con nombre

Este es el párrafo más importante de todo este Playbook.

La aprobación formal es el artefacto. No el documento. No la reunión. No el hilo de Slack. El correo electrónico con el resumen de una página adjunto, enviado al solicitante y a su manager, solicitando una respuesta escrita que diga "aprobado." Ese correo electrónico, con el sello de fecha y la respuesta, es lo único que se interpone entre usted y la expansión del alcance.

La mecánica: escriba un resumen de una página de las cinco casillas. Envíelo por correo electrónico (no por Slack, no por Teams, no como comentario en Jira) al solicitante y a su manager directo. El cuerpo del correo dice: "De acuerdo con nuestra conversación de admisión del [fecha], aquí está el resumen de lo que estamos construyendo, la decisión que informa, la métrica de éxito, lo que está dentro del alcance y lo que está explícitamente fuera del alcance. Por favor, responda 'aprobado' para continuar. El trabajo de ingeniería comienza al recibir la aprobación."

Dos razones para incluir al manager en copia. Primera, el manager es generalmente quien tiene la autoridad presupuestaria y quien será consultado sobre "¿a dónde fueron las horas de ingeniería?" si el alcance muta. Debe ver la solicitud original. Segunda, el manager es también quien más probabilidades tiene de añadir alcance durante el desarrollo ("oye, ya que estás..."), y tenerlo en el correo de aprobación original le da el artefacto para resistir.

El sí verbal no es sí. El pulgar arriba en Slack no es sí. "Suena bien" en una reunión no es sí. Respuesta con "aprobado" por correo electrónico, con fecha, con solicitante y manager en el hilo. Eso es sí. He perdido discusiones sobre expansión del alcance cuando tenía un sí verbal y ningún rastro de correo electrónico. No he perdido ni una sola cuando tenía el correo electrónico.

El registro escrito con fecha es la única defensa del BA cuando el alcance muta. Esa frase no es dramática. Es la razón entera por la que existe este paso. Sin él, cada cambio de alcance disputado es un concurso de memoria, y el BA siempre pierde los concursos de memoria contra solicitantes con mayor rango en la organización.

Gestión de la expansión del alcance: tres síes, siete noes

Durante el desarrollo, el solicitante quiere agregar algo. Esto ocurrirá. No es señal de fracaso. Es el estado estable del trabajo interno.

Hay tres razones legítimas para ampliar el alcance durante el desarrollo, y siete ilegítimas.

Tres razones legítimas (usted dice sí, con una nueva fecha):

  1. Cambio regulatorio. Llegó un nuevo requisito de cumplimiento que afecta el resultado. El panel de control debe mostrar el nuevo campo o no puede publicarse. Sí, y aquí está la nueva fecha.
  2. Error bloqueante o problema de datos. Durante el desarrollo, descubre que los datos subyacentes son incorrectos, incompletos o contradictorios de una manera que hace imposible la especificación original. Sí, y necesitamos pausar para corregir los datos; la nueva fecha es X.
  3. Sorpresa de dependencia. Un sistema upstream que no conocía (o que acaba de cambiar) hace que el enfoque de integración original sea inviable. Sí, y necesitamos rediseñar esa parte; la nueva fecha es X.

Siete razones ilegítimas (usted dice "sí, y aquí está la nueva fecha", pero la fecha es la negociación):

  1. "Ya que estás..." La parte interesada pensó en algo nuevo.
  2. "[Persona de alto rango] vio el prototipo y quiere..." La revisión del prototipo generó una nueva solicitud.
  3. "Marketing también quiere..." Un nuevo solicitante está siendo introducido subrepticiamente en el proyecto original.
  4. "Sería útil ver también..." Expansión del alcance por decoración.
  5. "Cambiamos de opinión sobre la métrica." La casilla 3 se está reescribiendo en pleno vuelo.
  6. "¿Puedes hacerlo dinámico?" Lo hardcodeado a lo parametrizado es una reconstrucción, no un ajuste.
  7. "Solo una cosa pequeña." Esta frase es casi siempre una señal de alerta. Pequeño para pedir, grande para construir.

Observe que tanto para las razones legítimas como para las ilegítimas, la respuesta es "sí, y." Nunca "no." La palabra no lo convierte en un burócrata. La frase "sí, y aquí está la nueva fecha" lo convierte en un socio que por casualidad es honesto sobre el costo.

La plantilla de control de cambios que se muestra a continuación es lo que hace que "sí, y" sea aplicable. Sin ella, "sí, y" se convierte en "sí", porque nada está documentado y la nueva fecha vuelve silenciosamente a la fecha anterior en la mente del solicitante.

Plantilla de control de cambios

Cinco campos. Correo electrónico. Con fecha. Firmado.

ASUNTO: Solicitud de cambio -- [nombre del proyecto] -- [fecha]

Fecha de aprobación original: [fecha]
Proyecto: [nombre]

1. QUÉ CAMBIÓ (una oración): _________________________________

2. POR QUÉ (una oración, enlace a la razón legítima o, si no aplica, nombre la compensación):
   _________________________________

3. IMPACTO EN LA FECHA (nueva fecha de entrega en AAAA-MM-DD):
   Fecha anterior: _______
   Nueva fecha: _______

4. IMPACTO EN OTROS SOLICITANTES (qué otros proyectos se retrasan y por cuánto tiempo):
   _________________________________

5. APROBACIÓN FORMAL DEL SOLICITANTE SOBRE LA NUEVA FECHA: Responda "aprobado" para confirmar la nueva fecha.

Eso es todo. Cinco campos. Envíelo en la hora siguiente a la solicitud de cambio de alcance. El solicitante responde "aprobado" o no lo hace. Si no lo hace, el alcance y la fecha originales se mantienen.

Nunca verbal. Nunca sin fecha. Nunca "simplemente lo absorberemos." Absorber alcance sin documentarlo es cómo los BA terminan agotados, culpados e incapaces de señalar un momento exacto en que el proyecto se descarriló.

Validación posterior a la entrega: el seguimiento a las dos semanas

Dos semanas después de la entrega, reserve 30 minutos con el solicitante. Una pregunta: ¿la métrica de éxito de la casilla 3 se movió realmente?

Si es sí, anótelo. Dos oraciones en su documento de portafolio, su paquete de evaluación de desempeño, su autoevaluación de fin de año. "Construí el panel de control de abandono de clientes para el equipo de CS. El tiempo del informe del lunes cayó de 4 horas a 22 minutos en tres semanas desde el lanzamiento (objetivo: menos de 30 minutos). Decisión: el responsable de CS usó el panel de control para justificar una contratación de más 2 CSM en la planificación del Q3." Ese tipo de artefacto hace que los BA sean promovidos. Las viñetas vagas de "panel de control entregado" hacen que los BA sean renovados, no promovidos.

Si es no (y esta es la parte en que la mayoría de los BA se equivoca), eso no es un fracaso que ocultar. Es un hallazgo de descubrimiento. Escríbalo: "Construí el panel de control. Dos semanas después, el responsable de CS lo ha abierto 3 veces. El tiempo del informe del lunes no ha cambiado. Hipótesis: la decisión subyacente (qué CSM asignar a qué cuentas) se toma en base a la relación, no a los datos, y el panel de control no aborda el verdadero cuello de botella."

Ese documento es oro. Es el insumo para la próxima solicitud de admisión. Es la razón por la que su próxima solicitud del mismo equipo será más precisa, porque tiene datos sobre lo que no funcionó la última vez. Los fracasos enterrados se desperdician. Los fracasos revelados se acumulan en experiencia.

El seguimiento a las dos semanas también cierra el ciclo con el solicitante. Se siente acompañado. Es más probable que le traiga el próximo problema real en lugar de la próxima solicitud vaga, porque ha aprendido que a usted le importa realmente el resultado, no solo el entregable.

El flujo de trabajo en 90 minutos

De principio a fin, el trabajo inicial toma noventa minutos.

  • 30 minutos: llamada de admisión. Recorra las cinco casillas. Haga la pregunta "¿qué haría con la respuesta?" Anote la decisión y la métrica de éxito.
  • 30 minutos: cree el prototipo de la respuesta (Sheets, Figma o ejemplo de salida escrito). Envíelo al solicitante. Pregunte "¿es esto con lo que haría algo un lunes por la mañana?"
  • 30 minutos: escriba el correo electrónico de aprobación formal de una página. Incluya al manager en copia. Solicite "responder con aprobado." Espere la respuesta.

Total: 90 minutos. Después de eso, comienza el trabajo de ingeniería. Durante el desarrollo, cualquier solicitud de cambio de alcance recibe el formulario de control de cambios de cinco campos en una hora. Dos semanas después de la entrega, ejecute la verificación de validación.

Noventa minutos de disciplina inicial reemplaza entre dos y tres semanas de retrabajo por proyecto. También reemplaza la erosión lenta de la confianza que ocurre cuando las partes interesadas sienten que cada proyecto se entrega tarde y ligeramente desviado. Ambos costos son invisibles hasta que deja de pagarlos. Una vez que lo hace, no vuelve atrás.

El documento no es el artefacto. La reunión no es el artefacto. El hilo de Slack definitivamente no es el artefacto. El correo electrónico con fecha, con nombre y con aprobación formal es el artefacto. Construya el resto de la práctica en torno a obtener ese correo electrónico, cada vez, antes de que se escriba cualquier código.

Aprenda más