Cómo priorizar solicitudes de funciones que se acumulan
6 min de lectura
Rastrear solicitudes de funciones resuelve dónde viven. No resuelve cuál sale primero, y esa segunda pregunta es en la que los equipos realmente se atascan. Un backlog de trescientas solicitudes, agrupadas y etiquetadas, sigue necesitando una regla de decisión, porque “construye lo más pedido” solo funciona hasta que dos solicitudes están reñidas y una tercera tiene una defensora ruidosa, que es la mayoría de semanas. Los marcos de abajo no son respuestas que compiten por la misma pregunta. Cada uno encaja con un tipo distinto de solicitud, y usar uno solo para todas suele ser el verdadero error.
¿Qué hace distinto priorizar solicitudes de funciones de priorizar un roadmap?
Una decisión de roadmap parte de la estrategia y pregunta qué construir. Una decisión sobre una solicitud de función parte de una demanda que ya existe y pregunta si actuar sobre ella, y ambas tiran en direcciones distintas con la frecuencia suficiente para que una solicitud tenga mucha demanda y aun así sea incorrecto construirla, o tenga poca demanda y aun así valga la pena porque desbloquea una cuenta estratégica. Tratar cada solicitud como un voto de roadmap se salta esa comprobación.
| Marco | Qué pesa | Dónde falla |
|---|---|---|
| Recuento bruto de peticiones | Cuánta gente pidió | Premia nombres pegadizos sobre demanda real |
| RICE | Alcance, impacto, confianza, esfuerzo | Necesita estimaciones que nadie tiene para una solicitud nueva |
| Ponderado por ingresos | Quién pidió, según el valor de la cuenta | Ignora solicitudes de cuentas que aún no valen mucho |
| Votos públicos | Señal visible y de bajo esfuerzo | Solo llega a usuarios que ya saben dónde mirar |
¿Qué es RICE, y funciona con solicitudes de funciones?
RICE puntúa una idea en alcance, impacto, confianza y esfuerzo, y luego divide los tres primeros entre el cuarto para obtener un número comparable. Se creó para ideas de roadmap en las que un equipo ya cree, donde la parte difícil es comparar apuestas distintas entre sí. Las solicitudes de funciones ya traen un número de alcance, el recuento de gente que pidió, que es más concreto que el alcance que suele tener una idea de roadmap nueva. Donde RICE se tensiona con una solicitud es en confianza e impacto: un equipo puede estar seguro de que una solicitud es real y aun así no tener base para saber cuánto moverá una métrica, porque “impacto” para una solicitud que ya tiene nombre y rastro de usuarios reales es un tipo de estimación distinto al impacto de una idea que nadie fuera de la sala ha visto todavía.
Usa RICE para solicitudes que se están considerando en serio y no están decididas. No lo apliques a cada solicitud entrante; el esfuerzo de puntuar solo se justifica en las que están lo bastante reñidas como para necesitar un desempate.
¿Debería ponderarse por ingresos, o por quién pidió?
Por quién pidió, pero no solo por ingresos. Una cuenta cerca de renovar, una cuenta que ya ha escalado antes, y una cuenta cuya solicitud desbloquea un trato en curso llevan una urgencia que una cifra de ingresos plana no captura por sí sola, y una solicitud de un registro de prueba puede seguir importando si bloquea una decisión que pronto se convierte en ingresos. La ponderación por ingresos es la más fácil de calcular de todas estas, y por eso mismo la más fácil de sobreconfiar: quita correctamente ruido de cuentas sin interés real, y con la misma facilidad puede degradar una solicitud que traería una cuenta mucho más grande que aún está en el embudo.
¿Qué papel juegan realmente los votos?
Una señal barata y continua para solicitudes que ya existen, y una mala forma de descubrir qué solicitudes deberían existir en primer lugar. Un recuento de votos solo llega a los usuarios que ya encontraron la solicitud y decidieron que merecía un clic, lo que significa que el total de votos de un roadmap público refleja tanto visibilidad como demanda: una solicitud antigua cerca de lo alto de la lista sigue acumulando votos en parte porque es fácil de encontrar, y una solicitud más nueva e igual de real empieza desde cero. El artículo sobre la roadmap pública defiende dejar los votos fuera de la roadmap por completo. Trata los votos como una señal que necesita agruparse y ponderarse por antigüedad, no como una clasificación que se construye de arriba a abajo. Tickets de soporte vs. solicitudes cubre el otro punto ciego en los conteos de votos: una brecha real puede generar casi ningún voto si las usuarias que la sufren nunca encuentran el tablero, mientras aparece con fuerza en soporte.
¿Cuándo gana la cliente más ruidosa, y es un problema?
A veces, y solo es un problema cuando nadie lo nota. Una cliente que escala con frecuencia, escribe tickets detallados o tiene línea directa con alguien del equipo verá sus solicitudes atendidas más rápido que una cliente más callada con una petición igual de válida, y un proceso de priorización que nunca lo comprueba favorecerá sistemáticamente a quien más insiste, no a quien tiene el caso más sólido. Las clientas ruidosas no son el problema que hay que arreglar; sus solicitudes suelen ser genuinamente importantes. La solución es un hábito: revisar el backlog por origen periódicamente y comprobar si el mismo puñado de cuentas explica la mayor parte de lo lanzado últimamente, y preguntarse si eso coincide con dónde está la demanda real.
¿Cómo se convierte una decisión de priorización en una respuesta?
Cada decisión aquí produce ganadoras y perdedoras, y ambas merecen una respuesta que nombre el razonamiento real, no solo un cambio de estado sin explicación. Cómo rechazar una solicitud de función cubre qué decir a una solicitud que perdió, de una forma que mantiene la relación intacta en vez de leerse como un rechazo genérico. El trabajo de agrupar y etiquetar que hace posible todo esto en primer lugar se cubre en seguimiento de solicitudes de funciones; la priorización solo funciona sobre solicitudes que ya estaban registradas y agrupadas lo bastante bien como para compararlas.
FAQ
¿Cuál es el mejor marco para priorizar solicitudes de funciones? Ninguno por sí solo. Usa recuentos brutos para encontrar la señal más ruidosa, RICE para comparar una lista corta de candidatas serias, y una comprobación de ingresos o de cuenta para detectar casos donde una demanda silenciosa de una cuenta estratégica pesa más que un grupo más ruidoso pero de menor importancia.
¿Deberían priorizarse las solicitudes de funciones igual que las ideas de roadmap? No. Las ideas de roadmap parten de la estrategia; las solicitudes de funciones parten de una demanda que ya existe. Puntuarlas juntas hace que una apuesta estratégica bien argumentada pero con poca demanda existente pierda de forma consistente frente a una solicitud que simplemente tiene más gente que la pidió.
¿Los votos de un roadmap público reflejan la demanda con precisión? Solo entre la gente que ya encontró la solicitud. Las solicitudes más antiguas y visibles acumulan votos más rápido, sin importar cuánta demanda real haya detrás de una más nueva, así que trata los totales de votos como una señal, agrupada y ponderada por antigüedad, no como una clasificación que se construye en orden.
¿Con qué frecuencia deberían reevaluarse las prioridades de solicitudes de funciones? En un ciclo fijo, no solo cuando alguien escala. Una revisión mensual o trimestral que reagrupa solicitudes y revisa la ponderación detecta desviaciones, como un puñado de cuentas que domina lo que se lanza, que un proceso puramente reactivo nunca detecta por sí solo.
Las afirmaciones técnicas de este artículo no se han revisado de forma independiente. Si algo está mal, avísanos y lo corregiremos.