La Reunión Donde Todos Asienten
Ya conoces esa reunión. Un desarrollador dice algo como "vamos a tener que refactorizar el middleware antes de tocar la capa de API", y tú asientes. No tienes idea de qué significa nada de eso. Pero asentir se siente más seguro que preguntar. Si dices "espera, ¿qué es una API?", tal vez piensen que no eres lo bastante serio para manejar un negocio.
Yo me he sentado en los dos lados de esa mesa. Y aquí está el secreto que nadie te cuenta: no necesitas entender la tecnología para llevar adelante un gran proyecto. Solo necesitas saber describir lo que quieres, y hacer un puñado de preguntas simples. Eso es todo. Esa es toda la habilidad.
Este artículo es la guía en español simple que me hubiera gustado que tuviera cada cliente antes de arrancar su primer proyecto.
Describe el Problema, No la Solución
El cambio más grande que puedes hacer es este: deja de intentar describir la solución. Describe, en cambio, qué está fallando.
Te doy un ejemplo. Imagina que tu tienda online sigue enviando las confirmaciones de pedido al correo equivocado. Muchos dueños de negocio entran a esa conversación diciendo: "creo que necesitamos cambiar la configuración de la base de datos de la tabla de pedidos." Leyeron esa frase en algún lado, o un empleado bien intencionado la sugirió, y ahora están liderando con una suposición sobre la causa en vez de contar el problema real.
Aquí está la versión mejor: "Cuando un cliente hace un pedido, a veces la confirmación le llega a otro cliente distinto. Ha pasado cuatro veces este mes, siempre con pedidos hechos desde el celular, no desde una computadora."
Fíjate qué hace esa segunda versión. No adivina la causa. Describe exactamente qué pasa, con qué frecuencia, y bajo qué condiciones. Eso es oro puro para un desarrollador. Adivinar la causa técnica, en cambio, puede mandarlo directo por el camino equivocado, persiguiendo una teoría en vez del error real.
Tú eres el experto en tu negocio y en qué está roto. El desarrollador es el experto en por qué está roto y cómo arreglarlo. Que cada uno haga su trabajo.
Habla de Resultados y Plazos, No de Tecnología
Una vez que el problema está claro, la siguiente trampa es querer sonar técnico cuando hablas de lo que necesitas después. No hace falta usar la palabra "integración" o "API" para pedir que dos sistemas se comuniquen entre sí. Simplemente di qué quieres que pase.
En vez de: "Necesitamos una integración de API entre nuestro CRM y nuestra herramienta de facturación."
Prueba con: "Cuando cierro una venta en mi sistema comercial, quiero que la factura aparezca automáticamente en mi sistema de facturación, sin que nadie tenga que volver a escribir los datos del cliente."
Es el mismo pedido. Una versión suena impresionante y hasta puede ser inexacta. La otra le dice al desarrollador exactamente cómo se ve el éxito, y está escrita con palabras que tú realmente entiendes, así que si algo no queda claro, puedes aclararlo en el momento en vez de descifrarlo después.
Lo mismo pasa con los plazos. No preguntes "¿cuántos sprints va a llevar esto?" si no sabes qué es un sprint (es simplemente un bloque fijo de tiempo, generalmente de una o dos semanas, que un equipo de desarrollo usa para planificar su trabajo; no necesitas pensar en esos términos). Pregunta en cambio: "¿Cuándo voy a poder usar esto de verdad?" y "¿Qué voy a poder ver o probar en el camino, para no esperar tres meses y recién ahí enterarme de que algo está mal?"
Cinco Preguntas Que Vale la Pena Hacerle a Cualquier Desarrollador
Estas funcionan ya sea que hables con un desarrollador interno, un freelancer, o una agencia. Ninguna requiere que sepas un solo término técnico.
- "¿Puedes explicarme eso otra vez en palabras simples?" Un buen desarrollador siempre puede traducir. Si no puede, eso ya te dice algo.
- "Si esto tarda más de lo previsto, ¿cómo me voy a enterar, y cuándo?"
- "¿Qué incluye el precio, y qué me costaría extra más adelante?"
- "¿Qué necesitas de mí, y para cuándo, para que esto se mantenga en tiempo?" Los proyectos se atrasan con más frecuencia por respuestas que el cliente no dio a tiempo, que por falta de habilidad del desarrollador.
- "¿Me lo puedes mostrar, no solo contar?" Una demostración rápida de pantalla, un boceto, o una prueba funcionando aclara más dudas que cualquier párrafo de explicación.
Si todavía estás decidiendo a quién contratar, en cómo elegir un socio de desarrollo de software recorro los criterios que importan antes incluso de llegar a esta etapa.
Cuándo la Jerga Deja de Explicar y Empieza a Esconder
La mayoría de los desarrolladores usan palabras técnicas porque es simplemente el vocabulario de su trabajo, no porque estén tratando de perderte. Pero de vez en cuando, la jerga se usa de otra manera: para evitar dar una respuesta clara.
Aquí está la señal: una buena explicación se vuelve más simple la segunda vez que preguntas. Si dices "todavía no te entiendo, ¿me lo puedes decir de otra forma?" y la respuesta viene con todavía más palabras técnicas, o con una frase vaga como "es complicado" o "así es como funciona la arquitectura", presta atención. Generalmente eso no es un límite técnico. Es alguien que no quiere comprometerse con una respuesta real sobre el costo, el tiempo, o por qué algo se rompió.
Un experto seguro siempre puede simplificar más. Si no puede, o no quiere, vale la pena un seguimiento directo y tranquilo: "entiendo que conoces esto muy bien, solo necesito que me lo digas en palabras simples para poder decidir."
Esta es una de las razones más silenciosas por las que los proyectos se desvían. Ya escribí sobre los errores comunes en proyectos de software, y la comunicación poco clara aparece cerca del primer lugar de esa lista, siempre.
No Necesitas Aprender a Programar
Esto es lo que quiero que te lleves: no ser técnico no es una desventaja en esta relación. Tú aportas lo que los desarrolladores no pueden: conoces a tus clientes, tu negocio, y cómo se ve realmente que algo "funcione" de tu lado. Tu trabajo es describir el problema con claridad, nombrar el resultado que quieres, y hacer un puñado de preguntas honestas en el camino.
Nunca vas a necesitar saber qué es un middleware para llevar adelante un proyecto exitoso. Solo necesitas un socio dispuesto a encontrarte en un lenguaje simple, y la confianza para preguntar "¿me lo puedes decir distinto?" las veces que haga falta.