Casi todos los proyectos empiezan igual. Alguien tiene una idea que lleva tiempo rondándole la cabeza: una app, una plataforma, una herramienta que resuelve un problema que conoce muy bien. La ha imaginado funcionando, sabe a quién va dirigida y, muchas veces, hasta tiene claro qué pantalla querría ver primero.
Y aun así, cuando llega el momento de explicarla en una reunión, aparecen las dudas: ¿esto cómo se hace?, ¿cuánto cuesta?, ¿por dónde se empieza? Esa mezcla de seguridad y vacío es, probablemente, el punto de partida más común de todos. Y no tiene nada de malo.
Tener una idea clara no es lo mismo que tener un proyecto
Una idea es una intención. Un proyecto es esa intención traducida a decisiones concretas: qué hace exactamente el producto, para quién, en qué orden se construye, qué pasa cuando el usuario hace clic aquí en lugar de allá.
Entre esas dos cosas hay un trabajo que casi nadie ve, pero que marca la diferencia entre un desarrollo que avanza con sentido y uno que se llena de sorpresas a mitad de camino. Ese trabajo es traducir lo que tienes en la cabeza a algo que un equipo pueda construir.
Lo que llega definido... y lo que llega en blanco
Lo habitual es que un cliente llegue con algunas partes muy pensadas y otras prácticamente sin tocar. No porque haya hecho mal su trabajo, sino porque es imposible tenerlo todo resuelto desde fuera del desarrollo.
Un ejemplo típico: alguien quiere lanzar una app para que sus clientes reserven un servicio. Tiene clarísimo el aspecto que debe tener la pantalla de reserva, los colores de su marca y el mensaje que quiere transmitir. En cambio, no ha pensado qué ocurre si dos personas intentan reservar la misma hora a la vez, cómo se gestionan las cancelaciones, o si hace falta un panel para que su equipo vea las reservas del día.
Ninguno de esos huecos es un problema. Son, simplemente, las preguntas que todavía no se ha hecho porque no tenía por qué hacérselas.
Por qué esto es completamente normal
Nadie monta una cocina profesional la primera vez que decide que le gusta cocinar. Con un producto digital pasa igual: la idea nace de tu negocio y de tu experiencia, no de saber cómo funciona el desarrollo de software por dentro.
Esperar que un cliente llegue con todo cerrado sería como pedirle a alguien que dibuje el plano de la casa antes de hablar con el arquitecto. El plano es el resultado de la conversación, no el requisito para empezarla.
Las preguntas correctas, al principio
Aquí es donde entra el trabajo de un buen estudio. Antes de escribir una sola línea de código, dedicamos tiempo a entender el proyecto de verdad: qué problema resuelve, quién lo va a usar, qué es imprescindible para la primera versión y qué puede esperar.
Ese proceso, la recogida de requisitos, consiste sobre todo en hacer las preguntas adecuadas en el momento adecuado. Algunas son evidentes. Otras destapan cosas en las que nadie había pensado y que, de no salir ahora, habrían aparecido más tarde en forma de retraso o de coste extra.
El objetivo no es interrogarte. Es ayudarte a ver tu propia idea con más nitidez, hasta que los huecos dejan de ser dudas y se convierten en decisiones.
Un buen estudio no espera que lo tengas todo claro
Si algo distingue a un equipo con experiencia es justo esto: no da por hecho que el cliente llega con el proyecto resuelto. Da por hecho que llega con una idea valiosa y con preguntas pendientes, y entiende que su trabajo es acompañar ese paso.
Así que si tienes una idea clara en unas cosas y muchas dudas en otras, estás exactamente donde tienes que estar. Ese es el punto de partida normal, y desde ahí es desde donde construimos.
En Liquid llevamos años convirtiendo ideas en productos digitales. Y casi siempre empezamos por lo mismo: una buena conversación.
