Cómo convertir una necesidad operacional en un proyecto tecnológico

Toda empresa tiene necesidades operacionales que podrían resolverse con tecnología. "Necesitamos que los vendedores sepan en tiempo real qué hay en stock", "necesitamos que los clientes puedan hacer el seguimiento de sus pedidos sin llamar", "necesitamos que el área de finanzas no tenga que conciliar pagos a mano todos los meses". Pero entre esa necesidad —expresada en una frase— y un proyecto de software listo para empezar a desarrollarse, hay una distancia que muchas empresas recorren mal: sin método, sin criterios claros, y con la expectativa de que el equipo de desarrollo va a traducir la necesidad por sí solo.

El resultado de recorrer mal esa distancia es previsible: proyectos que arrancan sin un alcance definido, que cambian de dirección cada dos semanas, que consumen más presupuesto del estimado y que, cuando finalmente se entregan, no resuelven el problema que motivó el proyecto.

Este artículo propone un método para convertir una necesidad operacional en un proyecto tecnológico bien definido, en cinco pasos. No es un método teórico: es el que usamos en Código Startup para asegurarnos de que cada proyecto arranca con los pies en la tierra y con un entendimiento compartido entre la empresa y el equipo técnico.

Paso 1: Describir el problema, no la solución

La necesidad casi siempre se expresa como una solución: "necesitamos una app para que los clientes hagan seguimiento de sus pedidos". Pero "una app de seguimiento" no es una necesidad: es una de las muchas formas posibles de resolver un problema. El problema real podría ser que los clientes llaman demasiado para preguntar por el estado de sus pedidos, y eso satura al equipo de atención. O que los clientes cancelan pedidos porque no saben cuándo van a recibirlos. O que el equipo de ventas pierde tiempo respondiendo consultas de seguimiento en lugar de vender.

El primer paso es describir el problema sin nombrar la solución. Para eso, hay que responder tres preguntas:

• ¿Qué está pasando hoy que no debería pasar? Describí la situación actual con hechos concretos, no con interpretaciones. No "la atención al cliente es ineficiente" sino "el equipo de atención recibe un promedio de treinta llamadas diarias de clientes que preguntan por el estado de su pedido, y cada llamada toma entre cinco y diez minutos".

• ¿Qué impacto tiene ese problema? Cuantificá el costo en tiempo, dinero, clientes perdidos o errores. "Las treinta llamadas diarias consumen entre quince y veinticinco horas semanales del equipo de atención, que dejan de atender consultas de ventas. Además, aproximadamente un diez por ciento de los clientes que llaman para hacer seguimiento cancelan el pedido si la respuesta no es satisfactoria."

• ¿Cómo sabrías que el problema está resuelto? Definí el resultado esperado en términos medibles. No "los clientes están más contentos" sino "las llamadas de seguimiento bajan a menos de cinco diarias, las cancelaciones por incertidumbre sobre la entrega bajan del diez al dos por ciento, y el equipo de atención recupera al menos quince horas semanales para dedicar a consultas de ventas".

Si no podés responder estas tres preguntas con datos concretos, el problema no está lo suficientemente entendido como para convertirlo en un proyecto de software. Seguí en la etapa de diagnóstico hasta que puedas.

Paso 2: Mapear el flujo actual, no el deseado

Una vez que el problema está descrito, el segundo paso es documentar cómo funciona hoy el proceso que se quiere mejorar. No cómo debería funcionar, no cómo funcionará con el software nuevo: cómo funciona hoy, con todas sus imperfecciones.

Este paso es incómodo porque obliga a mirar de frente las ineficiencias, las redundancias y las soluciones provisorias que se acumularon con los años. Pero es indispensable: si no entendés el punto de partida, no podés diseñar un camino que llegue al resultado esperado.

Documentar el flujo actual implica:

• Listar todos los sistemas, planillas, correos y canales que intervienen en el proceso. Si el vendedor consulta el stock en una planilla de Excel que actualiza el depósito una vez por día, eso tiene que estar documentado. Si el cliente pide seguimiento por WhatsApp y el vendedor le responde con un pantallazo del sistema de despacho, también.

• Identificar quién ejecuta cada paso. No el cargo, la persona o el rol concreto. "Mariana, del área de atención al cliente, revisa la bandeja de correo de reclamos cada dos horas". Esto es importante porque más adelante, al diseñar la solución, vas a necesitar saber qué personas van a interactuar con el sistema nuevo y en qué momento del proceso.

• Señalar los puntos de fricción. Dónde se producen demoras, dónde se acumulan errores, dónde el proceso se detiene porque depende de que alguien esté disponible. Estos puntos de fricción son los que el proyecto de software debería eliminar o reducir.

El artículo sobre qué información preparar antes de hablar con una empresa de software detalla cómo estructurar esta documentación para que el equipo técnico pueda entender el contexto sin tener que hacer una inmersión de semanas en la operación de la empresa.

Paso 3: Definir qué entra y qué queda fuera del alcance

Con el problema descrito y el flujo actual documentado, el tercer paso es definir el alcance del proyecto. Esto significa decidir, explícitamente, qué funcionalidades incluye la primera versión del software, y —tan importante como lo anterior— qué funcionalidades no incluye.

La definición de alcance no es una lista de requerimientos técnicos: es una lista de capacidades que el sistema debe tener, expresadas en lenguaje de negocio. Por ejemplo:

• "El cliente debe poder consultar el estado de su pedido ingresando su número de pedido y su correo electrónico."
• "El sistema debe mostrar en qué etapa está el pedido —recibido, en preparación, despachado, en tránsito, entregado— y la fecha y hora de cada cambio de estado."
• "Si el pedido está en tránsito, el sistema debe mostrar una estimación de fecha de entrega basada en el código postal del cliente y la fecha de despacho."

Tan importante como definir qué entra es definir qué queda fuera. Esto evita discusiones posteriores sobre funcionalidades que alguien asumió que estaban incluidas y no lo estaban:

• "Esta versión no incluye la posibilidad de modificar la dirección de entrega una vez que el pedido fue despachado."
• "Esta versión no incluye un chat en vivo con el equipo de atención al cliente."
• "Esta versión no incluye notificaciones por WhatsApp: las notificaciones de cambio de estado se envían por correo electrónico."

El artículo sobre cómo definir el alcance de un MVP ofrece criterios para decidir qué incluir y qué dejar fuera sin que el producto pierda su capacidad de resolver el problema que le dio origen.

Paso 4: Priorizar en función del dolor, no de la facilidad técnica

Con el alcance definido, el paso siguiente es ordenar las funcionalidades por prioridad. La priorización por facilidad técnica —"empecemos por lo más fácil de construir"— es un error común: lo más fácil de construir no necesariamente es lo que más valor aporta, y empezar por lo fácil puede consumir presupuesto en funcionalidades secundarias mientras el problema central sigue sin resolverse.

La priorización correcta es por impacto en el problema que se quiere resolver. La pregunta no es "¿qué podemos construir más rápido?" sino "¿qué funcionalidad, si estuviera disponible mañana, reduciría más el problema que describimos en el paso 1?".

Siguiendo con el ejemplo del seguimiento de pedidos: si el principal dolor es la cantidad de llamadas que recibe el equipo de atención, la funcionalidad prioritaria es la consulta de estado por parte del cliente. Si el principal dolor es que los clientes cancelan porque no saben cuándo van a recibir, la funcionalidad prioritaria es la estimación de fecha de entrega. La priorización surge del problema, no de la tecnología.

Esta priorización determina el orden en que se construyen las funcionalidades —primero las de mayor impacto, después las secundarias— y permite definir un plan de entregas progresivas: el sistema empieza a usarse apenas la primera funcionalidad está lista, y se van agregando las demás en iteraciones sucesivas. Esto es preferible a esperar a que esté todo completo, porque el tiempo que el proyecto pasa en desarrollo sin entregar valor es tiempo en que el problema sigue generando costo.

Paso 5: Definir los criterios de éxito

El último paso —y el que más se omite— es definir cómo se va a medir si el proyecto funcionó. Sin criterios de éxito definidos de antemano, la evaluación del proyecto queda librada a percepciones subjetivas: "me parece que mejoró", "yo creo que no cambió mucho". Con criterios de éxito medibles, la evaluación es objetiva y permite decidir si el proyecto cumplió su objetivo o necesita ajustes.

Los criterios de éxito se derivan directamente de la pregunta que cierra el paso 1: ¿cómo sabrías que el problema está resuelto? Si el problema era que el equipo recibía treinta llamadas diarias de seguimiento, el criterio de éxito es que ese número baje a menos de cinco. Si el problema era que un diez por ciento de los clientes cancelaba por incertidumbre sobre la entrega, el criterio de éxito es que esa tasa baje al dos por ciento.

Estos criterios deben medirse antes de empezar el proyecto, para tener una línea de base, y después de cada entrega, para verificar si el sistema está teniendo el impacto esperado. Si después de la primera entrega los indicadores no mejoran, hay que revisar si la solución está bien orientada o si el problema era distinto al que se diagnosticó.

Por qué este método funciona

Este método no es rápido —obliga a pensar antes de construir—, pero es el que menos tiempo total consume. Los proyectos que arrancan sin este trabajo previo invierten semanas o meses en construir funcionalidades que después hay que rehacer, porque el problema no estaba bien entendido, porque el alcance nunca se definió, o porque se priorizó lo fácil en lugar de lo importante.

Convertir una necesidad operacional en un proyecto tecnológico no es un problema técnico: es un problema de claridad. La tecnología puede resolver muchas cosas, pero no puede resolver la falta de definición. Si la empresa no sabe exactamente qué problema quiere resolver, qué resultado espera obtener y cómo va a medir si lo obtuvo, ningún equipo de desarrollo —por bueno que sea— va a producir el resultado esperado. Porque para producir un resultado, primero hay que definirlo.