Detecta las lagunas de tu PRD antes que los revisores
6 min de lectura
La mayoría de los PRD sale después de una sola lectura de quien los escribió. Eso atrapa las erratas, pero rara vez la laguna que hace que la misma pregunta de aclaración aparezca en los comentarios de cada documento que envías, porque ya sabes la respuesta y lees de largo por donde falta. Un PM que ha cargado el contexto de una función en la cabeza durante dos semanas lee un PRD sobre ella de forma completamente distinta a un ingeniero que abre el documento en frío por primera vez.
Advertencia
Una lectura del autor revisa si el documento tiene sentido para alguien que ya conoce la función. No revisa si tiene sentido para quien no la conoce, que es el revisor real.
El PRD que sobrevive a tu propia lectura es el que menos calificado estás para juzgar.
Por qué la misma pregunta sigue apareciendo en la revisión
Escribiste el documento con todo el contexto ya en la cabeza, así que una laguna en los requisitos no te parece una laguna, te parece obvia. El revisor no tiene ese contexto, así que el mismo tipo de pregunta, un caso límite sin atender, un supuesto sin decir, reaparece documento tras documento. Si tres de tus últimos cinco PRD recibieron el mismo comentario preguntando cómo debe comportarse la función para un tipo de usuario específico, eso no es mala suerte, es un patrón en cómo escribes el alcance.
Piensa en un PRD para una función de exportación masiva que especifica exactamente qué pasa para un usuario estándar que exporta hasta 10,000 filas. No dice qué pasa con 100,000 filas, ni para un usuario de un plan gratuito con límites de exportación, porque el autor pensaba en el caso común todo el tiempo que lo escribía. Un ingeniero que retoma el documento no tiene forma de inferir esas respuestas, y el hilo de comentarios resultante, “¿qué pasa por encima del límite de filas?”, es la misma pregunta que habría surgido en los últimos tres PRD también, si alguien hubiera pensado en revisar.
Antes: escribir el PRD, leerlo una vez, decidir que está claro, enviarlo a revisión.
Después: dárselo a Claude con el contexto real de la función, preguntar específicamente si el alcance está claro y qué casos límite faltan, y arreglar lo que encuentre antes de que un revisor tenga que preguntar.
Un proceso para probar un PRD antes de la revisión
- 1
Dale a Claude el borrador real y el contexto de verdad
Pega el planteamiento del problema y los requisitos tal como están escritos, no un resumen, junto con para quién es esta función. Un PRD para una herramienta administrativa interna necesita una cobertura de casos límite distinta a la de una función de cara al público, y el mismo caso límite ausente importa más o menos según quién resulte afectado.
- 2
Pregunta específicamente si el alcance está claro
Un vago “¿esto tiene sentido?” recibe una respuesta vaga. Pregunta directamente si alguien sin contexto previo podría decir qué está en el alcance y qué no solo con el documento, que es la prueba real que enfrentará un ingeniero que retoma el documento en frío.
- 3
Pide los casos límite que faltan, no una crítica general
Pide los casos límite específicos que los requisitos no atienden, no retroalimentación abierta. Un caso límite ausente es concreto y corregible; “esto podría estar más claro” no lo es.
- 4
Arregla las lagunas antes de que alguien más vea el documento
Actualiza directamente la sección de requisitos con lo que Claude señaló. La versión que ve un revisor ya debería reflejar las preguntas que de otro modo recibirías en los comentarios, para que el tiempo de revisión se vaya a desacuerdos reales en lugar de aclaraciones básicas.
Aquí están el planteamiento del problema y la sección de requisitos de mi PRD para una función de exportación masiva. Dime con honestidad si el alcance está claro y señala cualquier caso límite que no haya atendido.
”Para una función con una restricción técnica específica que ya conoces, un límite de tasa, un tope de tamaño de datos, una frontera de permisos, vale la pena decírselo directamente a Claude para que la revisión de casos límite se base en el sistema real y no en suposiciones genéricas.
Nuestro sistema de exportación tiene un límite duro de 500,000 filas a nivel de infraestructura, que no se menciona en ninguna parte de este PRD. Dada esa restricción, ¿qué casos límite en torno a los límites de filas deberían atender explícitamente los requisitos?
”
Dentro de Claude Tutorial
Probar un documento contra un lector que no tiene tu contexto es transferible.
Revisar si algo tiene sentido para alguien sin tu trasfondo, en lugar de confiar en tu propia lectura, sirve mucho más allá de los PRD. La app tiene una lección completa sobre esto, con práctica que aplica a cualquier documento que escribas para que alguien más actúe.
Cuando las lagunas siguen viniendo de la misma sección
Si los casos límite siguen apareciendo en la misma parte de tus PRD, vale la pena notarlo como un patrón, no volver a arreglarlo desde cero cada vez. Una laguna recurrente, digamos, en la sección de permisos suele significar que esa sección necesita una lista de verificación permanente, no otra revisión puntual. Arreglar la misma categoría de laguna tres veces por separado es señal de que el hábito de fondo necesita cambiar, no solo el documento actual.
Consejo
Pídele a Claude que compare las lagunas de este PRD con las de tus últimos documentos, si los tienes. Un patrón a lo largo de varios PRD es una señal más fuerte que los casos límite de un solo documento, y te dice dónde armar una lista de verificación reutilizable.
Este es el tercer PRD seguido en que los revisores preguntaron por el manejo de permisos. Aquí está la sección de permisos de este borrador. ¿Qué falta y qué tendría que cubrir de aquí en adelante una lista de verificación permanente para esta sección?
”Una vez que existe una lista así, vale la pena pasar la sección pertinente de cada PRD nuevo por ella antes de la primera revisión, en lugar de depender de la memoria para atrapar cada vez la misma laguna recurrente.
Aquí está la lista de verificación de permisos que armamos la última vez y aquí está la sección de permisos de un PRD nuevo. Contrástala con la lista y señala todo lo que la lista cubre y este borrador todavía no tiene.
”Sigue leyendo
- Escribir un PRD a partir de una solicitud de función de una línea: acertar con la estructura desde el inicio, antes de la pasada de revisión y corrección que cubre este artículo.
- Convertir tickets de soporte en temas priorizados: de dónde suelen venir, en primer lugar, los casos límite que un PRD necesita cubrir.
- Primeros pasos con Claude: los hábitos de fondo, contexto, iteración, especificidad, sobre los que se construye todo este proceso.