La Clienta Que Quería Saltarse las Conversaciones
Hace unos años, una dueña de negocio me llamó con un objetivo muy claro. Tenía una empresa pequeña de logística y quería una app para sus choferes. "No necesito reuniones", me dijo. "Necesito que empieces a construir."
Entendí perfectamente esa sensación. Las reuniones se sienten lentas. Construir se siente como avanzar. Así que entiendo por qué quería saltar directo a la parte de hacer cosas.
La convencimos de invertir dos semanas en planear antes de escribir código. No le encantó la idea. Pero tres meses después, me agradeció haber insistido.
Esto fue lo que pasó. Durante esas dos semanas descubrimos que no todos sus choferes usaban el mismo tipo de teléfono. Algunos tenían celulares Android viejos, sin señal confiable en las zonas donde manejaban. Si hubiéramos empezado a programar el primer día, habríamos construido una app que la mitad de sus choferes no podían usar. Y nos habríamos enterado justo después de terminarla — el momento más caro posible para descubrirlo.
Esas dos semanas de planeación le ahorraron, según nuestro propio cálculo, al menos seis semanas de reconstrucción más adelante. Es la historia que recuerdo cada vez que alguien me pregunta por qué no podemos "simplemente empezar a construir".
Qué Es Realmente una Fase de Descubrimiento
Una fase de descubrimiento es, en pocas palabras, el tiempo que se dedica a entender un problema antes de intentar resolverlo.
Piense en contratar a alguien para remodelar su cocina. Un buen contratista no llega con un mazo el primer día. Pregunta qué cocina usted, cómo usa su familia el espacio, por dónde pasan las tuberías y cuál es realmente su presupuesto. Después dibuja un plan. Solo entonces empieza a tumbar paredes.
El software funciona igual. Antes de escribir una sola línea de código, alguien necesita entender:
- Quién va a usar realmente este software, y cómo
- Qué problema necesita resolver
- Con qué otras herramientas debe funcionar (como su sistema contable o su sitio web)
- Cómo se ve "terminado", para que todos estén de acuerdo más adelante
Eso es todo. No es un proceso técnico. Es una conversación, hecha con cuidado, con las preguntas correctas.
Qué Pasa Durante Esta Etapa, en Palabras Simples
Una fase de descubrimiento suele durar entre una y cuatro semanas, según el tamaño del proyecto. Durante ese tiempo, un buen desarrollador o consultor va a:
- Hacerle muchas preguntas. No solo "qué quiere", sino "quién más va a usar esto", "qué pasa si estos datos están mal" y "cómo hace esto hoy sin el software".
- Observar cómo trabaja usted actualmente. A veces las mejores respuestas se obtienen viendo a alguien usar una hoja de cálculo o un formulario en papel, no pidiéndole que lo describa.
- Escribir lo que aprendió, en un lenguaje simple que usted pueda leer y corregir. Suele ser un documento corto, no una especificación técnica.
- Dibujar cómo podría verse el producto terminado, muchas veces con bocetos o maquetas simples, antes de que empiece la construcción real.
- Señalar las partes difíciles desde el inicio — las cosas que podrían costar más, tomar más tiempo o necesitar una decisión suya.
Al final, debería quedar algo por escrito con lo que ambas partes están de acuerdo. Si va a surgir un desacuerdo, este es el momento en que debe surgir — cuando solo cuesta una conversación, no una reconstrucción.
Qué Sale Mal Cuando Se Salta Este Paso
Quiero ser específico aquí, porque decir "saltarse la planeación es riesgoso" suena vago, y lo vago no convence a nadie.
Este patrón es muy común. Un dueño de negocio contrata a un desarrollador y le dice: "hazme un sitio web donde los clientes puedan reservar citas". El desarrollador, con ganas de empezar, construye exactamente eso. Tres meses después, el dueño lo abre y pregunta: "¿dónde veo todas las citas de hoy en un solo lugar?" O bien: "¿cómo se conecta esto con el calendario que ya usa mi equipo?"
Nadie hizo esas preguntas al principio. No porque alguien fuera descuidado, sino porque nadie apartó tiempo para hacerlas. Ahora el desarrollador tiene que regresar, y muchas veces tiene que reconstruir partes del sistema que se hicieron asumiendo algo que no era cierto.
Este es uno de los patrones mejor documentados en el desarrollo de software: un malentendido es barato de corregir mientras sigue siendo solo una conversación. El mismo malentendido es caro de corregir una vez que ya quedó construido dentro de código que funciona, porque ahora hay que deshacer algo antes de poder rehacerlo. No hace falta una estadística sofisticada para entenderlo — piense en lo mucho más barato que es cambiar de opinión sobre el color de una pared antes de pintarla, comparado con después.
Ya he hablado antes sobre los errores que cometen los dueños de negocio antes de iniciar un proyecto de software, y saltarse este paso es, por sí solo, el más grande de todos. No es que la gente sea descuidada. Es que "empecemos a construir ya" se siente productivo, mientras que hacer preguntas se siente como una demora. En realidad, es al revés.
Cómo Asegurarse de Que Quien Contrate Realmente Haga Esto
La buena noticia es que no necesita volverse una persona técnica para protegerse. Solo necesita hacer las preguntas correctas antes de firmar nada.
Pregúntele a cualquier desarrollador o agencia que esté considerando:
- "¿Cómo es su fase de descubrimiento, y cuánto dura?"
- "¿Qué voy a tener por escrito al final de esa etapa?"
- "¿Con quién de mi equipo necesitan hablar, y por cuánto tiempo?"
- "¿Qué pasa si nos saltamos este paso?"
Una buena respuesta suena segura y específica. Una respuesta vaga — "no se preocupe, lo vamos resolviendo sobre la marcha" — es una señal de alerta. "Resolverlo sobre la marcha" muchas veces significa resolverlo con su dinero, después de que algo ya se construyó mal.
Si está comparando opciones, esta es también una de las señales más claras de cómo trabaja realmente un socio tecnológico. Hablo más de esto en cómo elegir un socio de desarrollo de software — un proceso real de descubrimiento es una de las formas más rápidas de distinguir a un socio cuidadoso de uno que solo quiere empezar a cobrar horas.
En Resumen
El descubrimiento no es una demora antes de que empiece el trabajo real. Es el trabajo real — la parte donde los errores costosos todavía son baratos de corregir. Saltárselo no le ahorra tiempo. Solo mueve el costo hacia más adelante, y lo hace más grande cuando finalmente llega.
Si está por iniciar un proyecto de software o de sitio web y quiere que alguien haga las preguntas difíciles antes de escribir código, con gusto puedo conversarlo con usted.