Antes de escribir una línea de código, hay preguntas que definen si el proyecto va a funcionar o no. Una guía concreta para fundadores y gerentes que están por encargar desarrollo de software.
Construir software es una de las inversiones más significativas que puede hacer una empresa que no es de tecnología. Y también es una de las que más frecuentemente termina en resultados que no están a la altura de lo que se esperaba. Casi siempre, el problema no está en el desarrollo en sí —el código funciona, las pantallas se ven bien, los botones hacen lo que tienen que hacer— sino en las decisiones que se tomaron, o se dejaron de tomar, antes de que el desarrollo empezara.
La diferencia entre un proyecto de software que entrega valor y uno que consume recursos sin mover los indicadores del negocio no está en la calidad del código. Está en la claridad con que se respondieron un conjunto de preguntas antes de escribir la primera línea. Este artículo recorre esas preguntas, organizadas en cinco bloques, y explica por qué cada una importa.
Antes de hablar de funcionalidades, pantallas o tecnologías, hay que poder describir el problema que el software va a resolver con suficiente precisión como para que alguien que no trabaja en tu empresa lo entienda.
¿Qué problema resuelve este software? La respuesta más común —y más peligrosa— es una descripción de la solución disfrazada de problema. "Resuelve la falta de una aplicación para que los clientes hagan pedidos" no describe un problema: describe una herramienta. El problema es "nuestros clientes tienen que llamar por teléfono para hacer pedidos, y eso genera demoras, errores en la toma de datos y pérdida de ventas fuera del horario de atención". Esa diferencia no es cosmética: cambia lo que se construye, cómo se mide y qué se considera éxito.
¿Para quién es un problema? Hay que identificar a las personas concretas que experimentan el problema. No "los clientes" en abstracto, sino un perfil reconocible: "los encargados de compras de empresas manufactureras medianas que hoy gestionan sus pedidos por correo electrónico". Cuanto más específico es el perfil, más fácil es validar si el problema es real y diseñar una solución que lo resuelva.
¿Qué tan grave es el problema? No alcanza con que el problema exista: tiene que ser suficientemente grave como para justificar la inversión. La gravedad se mide en consecuencias: horas perdidas, ventas no concretadas, errores que cuestan plata, clientes que se van. Si no podés cuantificar el impacto del problema, no podés decidir si vale la pena resolverlo con software.
Cada vez que durante el desarrollo surja una discusión sobre si incluir o no una funcionalidad, volvé a esta pregunta: ¿esto nos acerca a resolver el problema que definimos al principio? Si la respuesta es no, probablemente no debería estar en esta versión.
El software no lo usan empresas: lo usan personas. Y entender a esas personas —su contexto, sus limitaciones, sus motivaciones— es tan importante como entender el problema.
¿Quiénes van a usar el software? Puede haber más de un perfil: el que carga datos, el que consulta reportes, el que aprueba operaciones, el administrador que configura parámetros. Cada perfil tiene necesidades distintas, niveles de familiaridad tecnológica distintos, y momentos del día distintos en los que usa el sistema. Ignorar esas diferencias produce software que técnicamente hace todo lo que se pidió pero que en la práctica resulta incómodo o directamente inusable para alguno de los perfiles.
¿En qué contexto lo van a usar? No es lo mismo un software que se usa sentado frente a una computadora en una oficina que uno que se usa parado en un depósito, con una mano ocupada y mala conexión a internet. El contexto de uso define decisiones de diseño —tamaño de botones, cantidad de pasos para completar una tarea, funcionamiento sin conexión— que son difíciles de cambiar después.
¿Qué nivel de familiaridad tecnológica tienen? Si los usuarios no usan software en su día a día más allá del correo electrónico y WhatsApp, una interfaz compleja con múltiples opciones y filtros avanzados va a generar rechazo y errores, por más potente que sea. Diseñar para el usuario real, no para el usuario ideal, es una de las decisiones más rentables del proyecto.
Definir qué va a hacer el software —y, tan importante como eso, qué no va a hacer— es quizás la decisión más difícil y la que más impacta en el presupuesto y los plazos.
¿Qué funcionalidades son indispensables para la primera versión? La respuesta no puede ser "todas". Hay que hacer el ejercicio incómodo de separar lo que el software necesita para funcionar y entregar valor de lo que sería lindo tener. Una forma de forzar esa separación es preguntar: "si tuviéramos que lanzar en la mitad del tiempo, ¿qué dejaríamos afuera?". Lo que sobrevive a esa pregunta es lo indispensable.
¿Qué funcionalidades quedan para después? Decidir qué dejar afuera no es abandonar esas ideas: es ordenarlas en el tiempo. La primera versión resuelve el problema central. Las versiones siguientes agregan funcionalidades basadas en lo que se aprendió de los usuarios reales usando la primera versión —no en lo que se supuso antes de que existiera—.
¿Qué procesos o sistemas existentes tiene que respetar el software? El software nuevo no existe en el vacío: tiene que convivir con los sistemas que la empresa ya usa —contables, de facturación, de inventario— y con los procesos que las personas ya ejecutan. Ignorar ese ecosistema y pretender que el software nuevo va a reemplazar todo desde el día uno es una receta para la resistencia interna y el fracaso en la adopción.
La habilidad más subestimada en la definición de alcance es la capacidad de decir que no a funcionalidades que son razonables pero no indispensables. Cada "sí" a una funcionalidad adicional es un "no" a entregar antes, a probar antes con usuarios reales y a corregir antes lo que no funciona.
Si no definís de antemano cómo se va a medir si el software funcionó, cualquier resultado puede presentarse como un éxito. Y proyectos que no se miden tienden a no entregar resultados.
¿Qué debería cambiar en el negocio si el software funciona? La respuesta tiene que ser observable y, en lo posible, cuantificable: "los pedidos se van a procesar en el mismo día en lugar de en tres días", "los errores de facturación van a bajar del cinco por ciento al uno por ciento", "los clientes van a poder consultar su estado de cuenta sin llamar por teléfono". Si no podés describir el cambio esperado en términos operativos, no tenés forma de saber si la inversión valió la pena.
¿Cómo vamos a medir ese cambio? Si el cambio esperado es reducir el tiempo de procesamiento de pedidos, necesitás saber cuál es el tiempo actual —medido, no estimado a ojo— y tener un mecanismo para medirlo después del lanzamiento. Sin línea de base, no hay comparación posible. Sin mecanismo de medición, no hay datos.
¿Cuánto tiempo después del lanzamiento debería verse el cambio? Algunos resultados son inmediatos —si el software automatiza un paso manual, el ahorro de tiempo se ve desde el primer día—. Otros requieren tiempo —si el software busca aumentar la retención de clientes, el impacto se mide en meses, no en semanas—. Definir expectativas realistas de tiempo evita que el proyecto se declare fracaso antes de haber tenido oportunidad de mostrar resultados.
Un software no termina cuando se termina de construir. Empieza. Y lo que pase después —mantenimiento, soporte, evolución— define si la inversión inicial rinde o se diluye.
¿Quién va a mantener el software actualizado? Los sistemas operativos se actualizan, las dependencias de terceros cambian, las necesidades del negocio evolucionan. Si no hay un plan —interno o con un proveedor— para mantener el software funcionando y actualizado, en uno o dos años va a estar obsoleto o directamente inutilizable.
¿Quién va a dar soporte a los usuarios? Cuando un usuario no sabe cómo hacer algo, o el sistema se comporta de una forma que no esperaba, necesita a quién preguntarle. Si esa persona no existe, el software se abandona. Definir quién da soporte —y con qué disponibilidad— es parte del diseño del proyecto tanto como definir las funcionalidades.
¿Cómo se van a gestionar los cambios futuros? El negocio va a cambiar —nuevos productos, nuevos procesos, nuevas regulaciones— y el software va a necesitar adaptarse. Tener claro el mecanismo para solicitar, priorizar y ejecutar cambios evita que cada ajuste se convierta en una negociación desde cero.
Para profundizar en qué información preparar antes de hablar con un proveedor de software, el artículo sobre qué información debes preparar antes de hablar con una empresa de software detalla los documentos y definiciones que aceleran la conversación inicial. Si querés una guía más amplia sobre todo lo que un fundador debería saber antes de construir, revisá qué debería saber todo founder antes de construir software.
Responder estas preguntas lleva tiempo. Requiere conversaciones difíciles, aceptar que algunas suposiciones iniciales estaban equivocadas y postergar el momento gratificante de empezar a construir. Pero es tiempo que se recupera con creces durante el desarrollo —porque el equipo sabe exactamente qué tiene que construir y para quién— y después del lanzamiento —porque hay criterios claros para evaluar si funcionó—.
La alternativa —arrancar a construir sin haber respondido estas preguntas— es más rápida al principio pero mucho más lenta y costosa después. Porque las preguntas que no se respondieron al inicio van a aparecer igual, pero en el peor momento posible: cuando ya hay código escrito, plazos comprometidos y plata gastada.
¿Quieres evaluar cómo aplicar esto a tu proyecto?
Cuéntanos tu caso →