Cómo elegir con quién desarrollar tu producto digital

Una parte importante de la gente que nos escribe no viene de cero. Viene de un intento anterior que no llegó a puerto: un desarrollo que quedó a medias, un equipo que dejó de responder, un producto que se entregó pero que nadie puede modificar. Vuelven a empezar el mismo proyecto por segunda vez, con menos presupuesto y menos paciencia.

Casi siempre, mirando hacia atrás, las señales estaban desde la primera reunión. El problema es que si no se ha pasado por esto antes, no se sabe qué mirar.

Esto es lo que nosotros preguntaríamos si tuviéramos que contratar a alguien para construir un producto.

1. ¿Quién va a trabajar realmente en esto?

Es común que a la reunión comercial vaya el perfil más senior de la empresa y que el proyecto lo ejecute después alguien mucho más junior, sin que el cliente se entere hasta que aparecen los problemas.

No es que trabajar con perfiles junior esté mal —todos empezamos ahí—, es que el precio y la expectativa se acordaron pensando en otra cosa.

Pregunten directamente: quién escribe el código, quién toma las decisiones técnicas, y si esas personas van a estar en las reuniones. Una respuesta vaga acá es un dato en sí mismo.

2. ¿Qué pasa si el proyecto se detiene mañana?

Esta es, para nosotros, la pregunta más reveladora de todas.

Si el proyecto se interrumpe a mitad de camino —por presupuesto, por un cambio de prioridades, por lo que sea— ¿con qué se quedan? ¿Tienen el código? ¿Los accesos a los servidores? ¿El dominio está a su nombre o al del proveedor?

Un producto que solo puede mantener quien lo construyó no es un activo, es una dependencia. Y las dependencias se cobran caro cuando la relación se tensa.

Lo que corresponde es simple: el repositorio, los accesos y la infraestructura a nombre del cliente desde el primer día. No al final, no "cuando terminemos". Desde el principio. Si alguien pone reparos a esto, ya saben algo importante.

3. ¿Qué dice el documento de alcance?

"Desarrollo de plataforma web — $X" no es un alcance, es un titular.

Un alcance sirve cuando dice qué entra, qué no entra y qué queda para una segunda etapa. Esa tercera categoría es la más importante y la que casi nunca aparece, porque nombrarla obliga a una conversación incómoda que mucha gente prefiere postergar.

El problema de postergarla es que la conversación igual va a ocurrir. Solo que va a ocurrir a mitad del desarrollo, cuando ya hay plata gastada y las dos partes creen tener la razón. Ahí es donde los proyectos se atascan.

Si el documento no dice qué queda fuera, pídanlo antes de firmar.

4. ¿Cada cuánto voy a ver algo funcionando?

Un proyecto que desaparece durante tres meses y reaparece con "el producto terminado" es un proyecto de altísimo riesgo, incluso si el equipo es bueno.

Lo que se busca no son reuniones de avance con presentaciones. Es algo que se pueda abrir y probar, aunque esté incompleto. Un prototipo navegable, una primera pantalla real, una parte del flujo funcionando.

La razón es práctica: los malentendidos entre lo que el cliente pidió y lo que el equipo entendió son inevitables. La única variable bajo control es cuánto tardan en descubrirse. Descubrirlos en la semana dos cuesta una conversación; descubrirlos en el mes tres cuesta rehacer.

5. ¿Me están diciendo que no a algo?

Esta señal es contraintuitiva y por eso vale doble.

Un proveedor que dice que sí a todo en la primera reunión no les está dando buen servicio: les está vendiendo. Alguien con experiencia real tiene opiniones, y algunas de esas opiniones van a contradecirlos.

Si plantean diez funcionalidades y la respuesta es "perfecto, todo se puede", desconfíen. Un equipo con criterio va a decir algo del tipo: "esto tres es lo que resuelve el problema, estas otras siete las dejaría para después porque suman costo y no cambian el resultado".

Nos ha pasado de decirle a un cliente que no necesitaba software, que el problema se resolvía ordenando un proceso interno. Es una conversación incómoda de un día. Ahorra meses de trabajo mal dirigido y bien gastado.

6. ¿Puedo hablar con alguien para quien hayan trabajado?

Un portafolio muestra el resultado en su mejor día. Una conversación de quince minutos con un cliente anterior muestra cómo fue el proceso: si se cumplieron los plazos, cómo se manejaron los imprevistos, si aparecieron costos que no estaban conversados.

Que esa conversación sea posible es, en sí misma, la mejor referencia.

7. ¿Qué pasa después de la entrega?

El día del lanzamiento no es el final. Es cuando empiezan a aparecer los casos que nadie previó, los usuarios que hacen cosas raras y las primeras solicitudes de cambio.

Conviene tener conversado de antemano: si hay período de garantía, cómo se cotizan los cambios posteriores, y —sobre todo— qué pasa si deciden trabajar con otro equipo. Si esa salida no es limpia, están frente a la misma dependencia del punto 2 con otro disfraz.

El patrón de fondo

Si miran de nuevo las siete preguntas, ninguna es técnica. Ninguna requiere saber programar.

Todas apuntan a lo mismo: ¿esta relación los deja en control de lo que están pagando?

Los proyectos que hay que empezar de nuevo rara vez fracasan por una mala decisión técnica. Fracasan porque el alcance nunca estuvo escrito, porque nadie vio nada hasta que fue tarde, o porque cuando la relación se rompió el cliente no tenía en sus manos lo que había pagado.

Todo eso se puede prevenir antes de firmar. Después es mucho más caro.