Por qué el portafolio no basta
Un portafolio muestra lo que salió bien y se puede enseñar. No muestra los proyectos que se entregaron tarde, los que se rescataron a medias ni los que terminaron en tribunales. Tampoco distingue entre el equipo que hizo aquel trabajo y el que atenderá el tuyo, que puede no coincidir en una sola persona.
Las preguntas que siguen sirven para otra cosa: no miden talento, miden cómo se comporta un proveedor cuando algo se complica. Eso es lo que vas a comprar en realidad.
Las nueve preguntas
1. ¿Quién va a escribir el código, y puedo hablar con esa persona?
En muchas agencias la persona que vende no es la que construye, y a veces ni siquiera trabaja en la misma empresa. No es descalificante por sí solo, pero necesitas saberlo. Mala señal: evasivas sobre quién integra el equipo, o la promesa de “asignar los mejores recursos disponibles” sin nombres ni una conversación técnica antes de firmar.
2. ¿De quién es el código al terminar?
La respuesta debe ser inequívoca y estar en el contrato, junto con la entrega del repositorio, la documentación y los accesos a la infraestructura. Mala señal: que la propiedad quede “sujeta a los términos de la licencia de la plataforma”, o que el sistema sólo pueda operar en la infraestructura del proveedor sin una salida documentada.
3. ¿Qué pasa si quiero irme a la mitad?
Todo proyecto largo puede terminar antes de tiempo. Un proveedor serio ya pensó en eso: hay entregables parciales que funcionan, hay una forma de cortar limpio y hay un traspaso previsto. Mala señal: que el valor sólo exista al final, en una entrega única. Eso concentra todo el riesgo en el cliente.
4. ¿Cómo entregan? ¿Cuándo veo algo funcionando?
La distancia entre firmar y ver software real corriendo es el mejor predictor de sorpresas. Por etapas cortas, el error se detecta cuando todavía es barato. Mala señal: meses de análisis y diseño antes de la primera demostración, o un cronograma de doce semanas sin nada revisable hasta la semana diez.
5. ¿Qué hacen cuando el alcance cambia?
Va a cambiar. La pregunta es si existe un mecanismo —cómo se estima, quién aprueba, cómo se refleja en costo y fecha— o si se resuelve por conversación informal hasta que alguien se molesta. Mala señal: “todo lo que necesites, lo incluimos”. Eso no es generosidad, es una discusión aplazada.
6. ¿Quién opera el sistema después de lanzarlo?
El lanzamiento no es el final: alguien tiene que actualizar dependencias, atender incidentes y sostener la infraestructura. Las tres respuestas válidas son que lo haga el proveedor, que lo haga tu equipo con un traspaso formal, o un esquema mixto explícito. Mala señal: que la pregunta no se haya considerado, o que el mantenimiento aparezca como un anexo sin definir.
7. ¿Cómo miden que el proyecto salió bien?
Un buen proveedor traduce el proyecto a una métrica del negocio —horas ahorradas, errores evitados, tiempo de ciclo, ingresos atribuibles— y no sólo a funcionalidades entregadas. Mala señal: que el éxito se defina exclusivamente como cumplir la lista de requerimientos. Esa lista puede cumplirse completa y aun así no cambiar nada.
8. ¿Qué parte de lo que propongo NO deberíamos hacer?
Es la pregunta más reveladora de las nueve. Cualquiera con experiencia real puede señalar en tu propia solicitud lo que sobra, lo que puede esperar o lo que se resuelve comprando algo hecho. Mala señal: entusiasmo con todo. Un proveedor que nunca te quita nada del alcance está optimizando el tamaño del contrato, no el resultado.
9. ¿Puedo hablar con un cliente cuyo proyecto se complicó?
Las referencias felices las tiene cualquiera. La referencia que importa es la del proyecto que se atrasó o cambió de rumbo, porque ahí se ve cómo se comunicó el problema y cómo se resolvió. Mala señal: que no exista ninguno. Significa poca experiencia, o poca memoria.
Cómo comparar propuestas sin engañarte
Cuando llegan dos o tres cotizaciones, la tentación es ordenarlas por precio. Es la comparación menos informativa que existe, porque casi nunca describen el mismo trabajo. Antes de comparar cifras, normaliza:
- ¿Incluyen infraestructura, o la pagas aparte después?
- ¿Incluyen la migración de los datos que ya tienes? Suele ser de lo más laborioso y de lo primero que se omite.
- ¿Incluyen pruebas, o las pruebas son tu equipo usando el sistema en producción?
- ¿Cuántas rondas de ajustes contempla, y qué pasa con la siguiente?
- ¿Qué pasa el mes trece? Es donde vive el costo total, y donde casi ninguna propuesta mira.
Después de normalizar, la propuesta más barata a veces sigue siéndolo. Pero ya sabrás por qué, que es distinto a suponerlo.
Tres señales de alarma que valen por todas
- Una cotización cerrada sin haber preguntado casi nada. Un precio firme sobre un problema que nadie exploró no es eficiencia: o lleva un colchón grande, o el ajuste llegará después como cambio de alcance.
- Certidumbre absoluta sobre la tecnología antes de entender el problema. Cuando la respuesta es la misma pila para cualquier caso, estás comprando el catálogo del proveedor, no una solución a lo tuyo.
- Urgencia fabricada. Descuentos que vencen el viernes, cupos que se agotan. La presión de tiempo es una técnica de venta, y en un compromiso a doce meses es exactamente la razón equivocada para firmar.
Si estas preguntas te resultan difíciles de evaluar porque el problema todavía no está claro del todo, ése es el problema a resolver primero, y no hace falta un proyecto completo para hacerlo: un diagnóstico corto de consultoría tecnológica deja por escrito qué conviene construir, qué comprar y en qué orden — y sirve igual de bien para evaluar propuestas de terceros que las nuestras.