Pasar a freelance en IA: las decisiones que conviene cerrar antes

El paso de asalariado a freelance suele contarse como una sucesión de trámites. En la práctica, la parte difícil está en otro sitio: a un asalariado se le contrata para un puesto, a un freelance se le contrata para un proyecto delimitado. No se prepara igual, ni se defiende igual.

Vender un proyecto no es presentar una candidatura

Una candidatura deja sitio a lo desconocido de forma deliberada: se contrata a una persona por tiempo indefinido apostando por su capacidad de aprender el contexto. Un proyecto funciona al revés: está delimitado, tiene un motivo para existir, un resultado esperado y un final. El cliente no compra potencial, compra que alguien se haga cargo de un problema identificado.

Por qué una experiencia demasiado amplia es difícil de comprar

Un perfil que dice cubrir datos, machine learning, IA generativa, cloud, puesta en producción y acompañamiento al cambio deja al cliente en una posición incómoda. No porque resulte inverosímil, sino porque entonces es él quien debe decidir qué encargarte, y esa decisión es justamente el trabajo que quería externalizar.

• Una oferta amplia obliga al cliente a imaginar el alcance: la mayoría no tiene ni tiempo ni legitimidad para hacerlo.
• Hace imposible la comparación: junto a un especialista, un generalista se lee como un perfil « por si acaso ».
• Complica fijar un precio, porque el precio se ancla en un valor y el valor en un problema con nombre.
• Anula el boca a boca: se recomienda a alguien « para un tema », no « para la IA en general ».

Acotar no significa rechazar todo lo demás. Significa elegir la puerta de entrada: un problema en el que tu legitimidad sea visible y a partir del cual los demás temas llegarán solos cuando exista la relación.

Convertir la experiencia por cuenta ajena en pruebas utilizables

Un CV de asalariado cuenta puestos y periodos. Una prueba de freelance cuenta una situación y una responsabilidad. La materia prima es la misma; cambia el encuadre. Basta con una estructura sencilla, válida para casi cualquier experiencia.

1. 1

   El problema

   2 frases

   Qué no funcionaba, para quién y por qué se convirtió en algo que había que resolver. Sin el problema, lo demás parece una lista de tareas.

2. 2

   Tu responsabilidad

   1 frase

   Qué era exactamente tuyo y qué era de otros. Es la parte que más a menudo queda difusa y la que más se mira.

3. 3

   El enfoque

   3 o 4 frases

   Cómo lo abordaste, en qué orden y con qué restricciones. Aquí se lee la competencia real.

4. 4

   Las decisiones

   2 frases

   Los arbitrajes que sostuviste y lo que descartaste. Una decisión asumida vale más que un resultado sin explicar.

5. 5

   Resultado y límites

   2 frases

   Qué cambió y qué no llegó a resolverse. Nombrar un límite es lo que hace creíble todo lo demás.

Hablar de proyectos confidenciales sin revelar nada

Buena parte de la experiencia está bajo NDA o en contextos sensibles. Eso impide citar nombres, datos, arquitecturas precisas o elementos contractuales. No impide demostrar competencia, porque lo que se demuestra no es la información del cliente: es tu razonamiento.

• Sustituye el nombre del cliente por su tipo y tamaño: « una aseguradora », « una plataforma de comercio electrónico », « un fabricante de software ».
• Describe la naturaleza de los datos, nunca los datos: « documentos contractuales multilingües », sin ningún extracto.
• Habla de la clase de problema y no de la implementación exacta: « búsqueda documental sobre un corpus heterogéneo y versionado ».
• Explica los arbitrajes sin los entregables: una decisión de arquitectura se cuenta sin un esquema interno.
• Mantén los resultados en términos cualitativos: qué podía hacer el equipo después que no podía hacer antes.
• Ante la duda, pregunta: muchas antiguas empresas aceptan por escrito una formulación genérica.

Una prueba anonimizada pero precisa convence más que un nombre de cliente prestigioso seguido de tres líneas vagas. Lo que evalúa quien lee es tu manera de razonar.

Encuadrar una necesidad y proponer un alcance

El primer proyecto se juega a menudo antes del proyecto: en la capacidad de escuchar una petición imprecisa y volver con algo sostenible. Es la competencia freelance más visible de inmediato y la que un asalariado pocas veces ha ejercido en solitario.

1. 1

   Descubrimiento

   primera conversación

   Entender el detonante: por qué ahora, a quién afecta, qué se ha intentado ya. Las peticiones formuladas como solución (« necesitamos un chatbot ») casi siempre esconden otro problema.

2. 2

   Cualificación

   antes de proponer

   Comprobar que hay una persona que decide, acceso a los datos o a las personas y una definición posible de éxito. Sin esos tres elementos, el proyecto será ingobernable por muy alto que sea tu nivel técnico.

3. 3

   Alcance y entregables

   por escrito

   Decir qué está incluido, qué no y en qué forma se entrega el trabajo. Un entregable con nombre protege al cliente tanto como a ti.

4. 4

   Dependencias e hipótesis

   por escrito

   Nombrar de qué dependes: accesos, entorno, interlocutores, decisiones pendientes. Una dependencia no escrita pasa a ser tu responsabilidad por defecto.

5. 5

   Criterios de éxito

   por escrito

   Cómo sabréis, conjuntamente, que el proyecto ha cumplido su objetivo. Con un sistema probabilístico exige un trabajo de definición más explícito que en otros casos.

6. 6

   Comunicación y fuera de alcance

   desde el inicio

   Ritmo de seguimiento, formato de reporte y qué ocurre cuando una petición sale del marco. Lo que queda fuera de alcance no es un conflicto: es una modificación, siempre que se haya previsto.

Estar preparado no es saberlo todo

La idea de que hay que ser un experto absoluto antes de lanzarse es falsa y paralizante. Un cliente no espera que un freelance lo sepa todo: espera que sepa decir dónde se sitúa. Lo que debe ser sólido es la lucidez, no la exhaustividad.

• Qué sabes asumir tú solo, de principio a fin.
• Qué no sabes asumir y prefieres no vender.
• Las hipótesis sobre las que se sostiene tu propuesta.
• Las dependencias que, si fallan, cambian el calendario.
• Los riesgos que identificas y cómo propones reducirlos.
• El momento en que recomendarías incorporar una competencia complementaria.

Decir « esta parte queda fuera de lo que domino, puedo encuadrarla pero recomiendo a otra persona para ejecutarla » se lee, para la mayoría de clientes, como profesionalidad. Es también lo que separa una relación duradera de un proyecto que acaba mal.

Preparar en concreto el primer proyecto

Antes incluso de buscar, algunos elementos merecen existir por escrito. No por estética, sino porque escribirlos te obliga a cerrar preguntas que el primer cliente hará de todos modos.

• Una presentación de tu posicionamiento en pocas frases, comprensible para alguien no especialista.
• Dos o tres pruebas redactadas como problema, responsabilidad, enfoque, decisiones, resultado y límites.
• Una descripción de tu forma de trabajar: ritmo, disponibilidad, presencial o remoto, herramientas de seguimiento.
• Una lista de lo que no asumes, lista para decirse sin incomodidad.
• Una plantilla de propuesta sencilla y reutilizable con alcance, entregables, dependencias y criterios de éxito.

El primer proyecto tiene además un valor propio: produce tus primeras pruebas como independiente, las que podrás contar sin apoyarte en tu pasado como asalariado. No es necesariamente el mejor pagado ni el más impresionante; es el que sabrás defender, entregar y después contar.

• Freelance
• Encuadre de proyecto
• Posicionamiento