El SOW Técnico: Cómo lo Armo, Desde la Primera Reunión Hasta que el Cliente lo Firma

Martes, nueve de la mañana. Del otro lado de la mesa está Andrés, el dueño de una tostadora de café de especialidad en Pereira. Lo primero que dice, antes de sentarse del todo, es: «Queremos una tienda virtual, con app y todo. ¿Cuánto vale más o menos?».

Esa pregunta es la que más proyectos ha hundido antes de empezar. No porque sea mala, sino porque casi siempre alguien la contesta ahí mismo. Andrés no existe: es un caso inventado para este post. Pero la frase la vas a escuchar, casi palabra por palabra, en tu primera preventa.

En este post sigo a Andrés de punta a punta: la reunión, lo que escuché, cómo pasé de esa conversación a un SOW técnico, cómo lo estimé, quién lo valida antes de que salga y cómo llega hasta la firma. Es el proceso que uso hoy como líder técnico y arquitecto cada vez que el comercial me trae una oportunidad.

Qué es un SOW técnico

SOW viene de Statement of Work, la declaración de trabajo. Es el documento que dice qué se va a construir, qué no, bajo qué supuestos, con qué entregables, en qué fases y cómo se va a dar por aceptado.

Se confunde mucho con otros dos papeles. La propuesta comercial la escribe el comercial y habla de precio, forma de pago y condiciones. El contrato lo revisa legal y habla de garantías, confidencialidad y propiedad intelectual. El SOW lo escribo yo, y traduce lo que el cliente necesita en algo que se puede construir, estimar y verificar. Si la propuesta dice cuánto y el contrato dice bajo qué reglas, el SOW dice qué exactamente. Y cuando hay una pelea seis meses después, nadie abre la propuesta: abren el SOW.

El comercial y yo

Con el comercial queremos lo mismo, ganar el proyecto, pero no respondemos por lo mismo. Ella sabe quién decide, cuánta plata hay, contra quién competimos y para cuándo es la decisión. Yo respondo porque lo que se firme se pueda construir en ese tiempo y con esa calidad. Cuando esa línea se borra, el comercial termina prometiendo arquitectura y yo termino negociando precio, y los dos lo hacemos mal.

Por eso trabajamos con cuatro acuerdos que no se negocian:

1. No sale un número sin estimación técnica. Ni un «más o menos» por WhatsApp. Un número dicho en voz alta se vuelve compromiso.
2. Las fechas se validan antes de prometerlas. Si el cliente necesita salir en un mes, el SOW dice lo que cabe en un mes, no lo que el cliente pidió.
3. El precio no se negocia delante del cliente. Si en la reunión preguntan «¿y si lo dejamos en tanto?», la respuesta es «lo revisamos y te respondemos».
4. Cuando hay que bajar el precio, se baja alcance, no horas. Esta es la que más cuesta sostener. Apretar la estimación para que cuadre con un presupuesto no hace el trabajo más corto; lo único que garantiza es que el proyecto arranque perdiendo. Lo que sí se puede mover es el alcance, las fases o la solución.

Antes de la reunión con Andrés, Camila, la comercial, me mandó un brief de cinco líneas: tostadora con tienda física y venta por WhatsApp, sin presupuesto definido, decide el dueño, quiere salir antes de diciembre, y está cotizando con otra agencia. Con eso llegué sabiendo qué preguntar.

Este es el recorrido completo que sigue cualquier SOW. Cada paso tiene el color de quien lleva la batuta: amarillo el cliente, violeta el comercial, turquesa yo, rosado QA y DevOps, y verde la firma.

La reunión, simulada

Así habría quedado la transcripción si la reunión hubiera sido por Meet. Fue una llamada de casi una hora, así que dejo los momentos que importan. Los nombres son inventados, menos el mío.

Esa respuesta vale más que cualquier requerimiento: hay urgencia, hay una fecha y hay un dolor concreto. Fíjate también en quién contestó qué: el recorrido de un pedido no lo conocía el dueño, lo conocía Daniela. Por eso a la primera reunión pido que venga quien hace el trabajo todos los días, no solo quien firma.

Después vino la app, y casi al final, lo que siempre aparece al final:

Una app nativa no resuelve ninguno de los problemas que acababan de contar, así que iba para fuera de alcance, como una fase posterior. Lo de la caja lo anoté con un signo de interrogación grande. Y la devolución del minuto 49 es la mitad del discovery: lo que el cliente corrige en ese momento es justo lo que habría salido mal en el SOW.

Cuando colgamos, Camila quería mandar la propuesta al otro día. Le pedí hasta el jueves y le dije una sola cosa: «Lo del inventario no se lo prometamos hasta saber qué sistema es».

De la reunión al documento

De esa hora salieron cinco cosas, y son las que le busco a cualquier reunión: el problema real (pedidos y pagos que se pierden en el chat), cómo vamos a saber que funcionó (cero pedidos perdidos y facturas sin digitar), la restricción (1 de diciembre), lo que no entra (la app nativa) y lo que todavía no sé (el sistema de la caja).

Con eso armo el SOW. Mis documentos siguen casi siempre la misma estructura:

1. Contexto y objetivo, en el lenguaje del cliente.
2. Alcance, por módulos, con detalle suficiente para que dos personas lo entiendan igual.
3. Fuera de alcance, dicho explícitamente.
4. Supuestos y dependencias.
5. Solución técnica y diagramas.
6. Entregables y fases.
7. Criterios de aceptación por entregable.
8. Estimación y equipo.
9. Riesgos.
10. Control de cambios.
11. Garantía y soporte.

Las que van en negrilla son las que no me salto nunca, porque son las que evitan las peleas. Para Andrés, ese corazón del documento quedó así:

Una prueba que le hago a cada SOW antes de seguir: si le doy el documento a alguien de mi equipo que no estuvo en la reunión, ¿estimaría más o menos lo mismo que yo? Si no, al alcance le falta detalle.

Del Meet al primer borrador

El SOW no lo empiezo en blanco. La reunión con Andrés fue por Meet, y Gemini me deja la transcripción completa al colgar. Esa transcripción, junto con mi plantilla de SOW (las once secciones de arriba, con las tablas ya armadas), es lo que le paso a Claude para sacar el primer borrador.

Lo que le pido no es un SOW terminado. Le pido que ordene lo que se dijo en cada sección, que proponga el alcance y lo que queda fuera, y sobre todo que liste lo que en la conversación quedó a medias: el sistema de la caja, quién entrega las fotos, si la cuenta de Wompi ya existe. Esa lista es oro, porque de ahí salen los supuestos y las preguntas para el cliente.

Ese borrador es la versión 0.1, y de ahí en adelante el trabajo es mío. Corrijo lo que la herramienta entendió mal, decido qué entra y qué no, y la tabla de estimación la lleno yo, tarea por tarea: ninguna herramienta conoce mi equipo ni mi histórico de horas. Después lo pulo en Google Docs con Gemini.

Cuando hace falta presentación, la armo en Gamma a partir del SOW ya cerrado. Gamma me da la estructura y el diseño en minutos, pero el orden de la historia y las cifras las reviso una por una, porque es justo lo que el comité va a cuestionar.

Recomendación: si vas a pasar la transcripción de un cliente por una herramienta de IA, revisa antes qué permite tu acuerdo de confidencialidad y usa una cuenta empresarial. Esa transcripción tiene nombres, cifras y problemas internos del cliente.

Cómo estimo las horas

Yo estimo descomponiendo. Parto el alcance hasta que cada pieza sea tan pequeña que pueda decir, sin mentirme, cuánto cuesta. Mi límite es de 4 a 40 horas por tarea: si algo me da más de 40, todavía no lo entiendo.

Para cada tarea pongo tres números, el optimista (O), el más probable (M) y el pesimista (P), y saco el esperado con la fórmula PERT: (O + 4M + P) / 6. Para la tienda de Andrés, el desarrollo quedó así:

Fíjate en la pasarela: 16 horas si todo sale bien, 48 si no. Justo el triple. Es la fila que más me preocupa de la tabla, porque en una pasarela casi siempre aparece algo: las credenciales de producción tardan, el modo de pruebas no se comporta igual que producción o la confirmación del pago llega tarde o llega dos veces. Cuando el pesimista pasa del triple del optimista, para mí esa tarea es una zona gris y ya no la dejo así en la estimación: la convierto en un supuesto o la saco a una fase aparte, como cuento más abajo.

Las horas de desarrollo no son el proyecto. Sobre ese subtotal sumo todo lo que no es código:

Esos porcentajes son mi punto de partida, no una ley. Cada vez que cierro un proyecto comparo lo estimado contra lo real, y eso es lo que corrige el siguiente.

Cuando la incertidumbre es real, no doy un número: doy un rango, «entre 170 y 210 horas», y digo qué lo mueve. Y nunca convierto horas en plata. Yo entrego horas, perfiles y riesgos; el precio lleva márgenes y condiciones que decide el comercial, no yo.

Recomendación: nunca estimes en la misma reunión en la que te cuentan el proyecto. Pide un día. La estimación dicha en caliente es la que más se parece a lo que el cliente quiere oír.

Lo que todavía no tengo claro

Siempre queda algo sin aclarar, y la tentación es meterlo calladito dentro de la estimación. Con Andrés era el sistema de la caja. Hoy cada duda sale por una de estas cuatro puertas, de la más liviana a la más pesada:

1. Preguntar por escrito. Una lista de preguntas que le llega al cliente por medio del comercial, con fecha de respuesta.
2. Convertir la duda en supuesto. «Se asume que la tostadora ya tiene cuenta con Wompi en modo de pruebas». Si no se cumple, se activa el control de cambios y nadie se sorprende.
3. Sacarla del alcance y proponerla aparte. Fue lo que hice con la caja: queda fuera, con una nota que dice que se estima cuando sepamos qué sistema es.
4. Proponer una fase de descubrimiento. Cuando lo incierto es el centro del proyecto, lo honesto es vender primero dos o tres semanas de entrevistas, prototipo y revisión de los sistemas existentes, y escribir el SOW grande con lo que salga de ahí.

Lo que no hago es inflar la estimación «por si acaso» sin decir por qué. Un colchón invisible no hay cómo defenderlo en una sustentación. Un supuesto escrito, sí.

Los diagramas que sí van

No siempre hacen falta. Una landing page no necesita un diagrama de arquitectura, y un SOW lleno de diagramas que nadie va a leer es ruido. Mi regla es meter un diagrama solo cuando responde una pregunta que el cliente o su área de TI se van a hacer:

• Contexto: casi siempre que hay integraciones. Es el que hasta un gerente entiende.
• Contenedores o componentes: en proyectos medianos o grandes, o cuando el cliente tiene TI propia que va a operar la solución.
• Secuencia: para flujos donde importa el orden, como un pago o una conciliación.
• Despliegue: cuando el alcance incluye nube o DevOps, sobre todo si el cliente va a pagar esa infraestructura.
• Modelo de datos: cuando hay migración desde un sistema anterior.

Lo que no meto son diagramas de clases ni detalle de implementación que va a cambiar en la segunda semana. El SOW compromete el qué; el cómo fino se decide construyendo.

Para Andrés bastó el de contexto. En amarillo lo que es del cliente, en turquesa lo que construimos y en gris lo que no controlamos:

Fíjate en la línea punteada: el sistema de la caja está en el diagrama, pero se ve distinto. Así el cliente ve, sin leer una sola línea, qué está dentro y qué todavía no.

QA, DevOps y lo que no es desarrollo

Las horas de QA nunca van escondidas dentro de las de desarrollo. Si un día hay que recortar, lo primero que se va es lo que no se ve, y el que lo paga es el cliente cuando sale a producción.

Cuando QA o DevOps los pone mi equipo, van como línea propia, con horas y perfil. Cuando los pone otra área de la empresa, esa área estima su parte; yo no estimo por ellos. Para Andrés, le pasé el alcance a la líder de QA y a DevOps el martes en la tarde, y el miércoles tenía de vuelta sus 27 y sus 16 horas, cada una con su explicación. Y cuando los pone el cliente o un tercero, van como supuesto, con lo que pasa si no llegan a tiempo: «el proveedor de facturación entrega el ambiente de pruebas antes de la semana 3».

Para que no haya dudas de quién hace qué, al final del SOW va una tabla corta de responsabilidades. Para la tostadora tenía cuatro filas: la integración con Wompi la hace nuestro equipo y la aprueba Andrés; los textos y las fotos los entrega Daniela; las pruebas de aceptación las ejecuta el equipo de Andrés con nuestro acompañamiento; y la cuenta de facturación electrónica la gestiona su contadora.

Explicarlo con plastilina

Hay conceptos que en una reunión técnica son obvios y que para el cliente son humo: un ambiente de pruebas, una integración, por qué el panel administrativo cuesta casi lo mismo que la tienda. Cuando veo caras de duda, dejo la jerga y saco la plastilina.

La que más uso es la de la casa. Los planos son la arquitectura. Los cimientos son la infraestructura: nadie los ve, nadie los presume y nadie discute por qué la casa los necesita. La obra negra es el backend, los acabados son la interfaz, y QA es la interventoría, el que llega con el metro antes de que uno se mude.

Con esa casa en la mesa, la pregunta del panel se contesta sola. La tienda es la fachada que ven los clientes de Andrés. El panel es toda la casa por dentro: la cocina, las tuberías y la instalación eléctrica, lo que Daniela va a usar cincuenta veces al día en diciembre. Una casa con fachada bonita y sin cocina no se puede habitar.

Si la analogía no alcanza, dibujo. Tres cajas y dos flechas en una hoja explican una integración mejor que diez diapositivas. Y si tampoco, cuento la historia de un pedido suyo: entra a las nueve, se paga con PSE a las nueve y cinco, se factura sola, y a las once Daniela lo despacha sin abrir el Excel.

Si el cliente no le puede explicar el alcance a su socio con sus propias palabras, todavía no quedó claro, y eso es problema mío, no suyo.

Cómo se valida y cómo llega hasta la firma

El SOW no sale de mi computador directo al cliente. Antes pasa por tres manos. Un desarrollador que no estuvo en la reunión lo lee y estima las tres tareas más grandes; si su número se aleja mucho del mío, alguno de los dos no entendió el alcance, y casi siempre es el documento el que tiene la culpa. QA y DevOps validan sus líneas. Y Camila le pone precio, revisa márgenes y confirma la fecha de decisión del cliente.

Después viene el recorrido con el cliente. El documento nunca se manda solo por correo: va con una reunión en la que paso por el alcance, lo que queda fuera, los supuestos y los riesgos. Le mandamos a Andrés la versión 0.9, y en el recorrido salió lo que no había salido en la primera reunión: «Ah, es que también le vendemos al por mayor a dos cafeterías, con otro precio». Como todavía no había firma, no fue un control de cambios: ajusté el alcance, estimé las listas de precios por tipo de cliente y salió la versión 1.0. Andrés la firmó la semana siguiente.

Este es el recorrido completo, fase por fase:

Un detalle de forma que ayuda mucho: la versión que se revisa es la 0.9 y la que se firma es la 1.0. El PDF es para firmar y el editable es para trabajar, así nadie altera sin querer la versión que el cliente aprobó.

Presentación, sustentación y demo

¿Siempre va con presentación? No. Andrés era un solo decisor, leyó el documento y lo resolvimos en el recorrido. La presentación ejecutiva tiene sentido cuando hay un comité, varios decisores, una licitación o un gerente que no va a leer veinte páginas, y en ese caso sale de Gamma, como conté más arriba.

Hay casos en los que ni el documento ni la presentación bastan y toca sustentar: licitaciones, comités de compras con TI o finanzas en la sala, clientes técnicos que revisan la estimación línea por línea. Para esos, Camila y yo nos repartimos las preguntas antes de entrar: ella responde por valor, condiciones y precio, y yo por la solución, la estimación y los riesgos. Llevo escritas las respuestas a las preguntas difíciles, «¿por qué tantas horas de QA?», «¿por qué no usan tal plataforma?», «¿qué pasa si el proveedor de facturación se demora?», y si una respuesta no me convence a mí, no va a convencer al comité. La estimación se defiende con la descomposición y los supuestos, no con autoridad. Por eso los supuestos van escritos: son la evidencia.

La demo vale la pena cuando la pregunta del cliente no es «cuánto cuesta» sino «¿esto se puede?»: un agente de IA sobre sus documentos, una integración con un sistema viejo o un flujo que el cliente no logra imaginar. Si Andrés hubiera dudado de que la factura pudiera salir sola, una demo de dos días con un pedido de prueba habría cerrado la discusión. Mis reglas para cualquier demo son pocas: dura de uno a tres días, porque si necesita más ya es una fase de descubrimiento y se cotiza como tal; se dice en voz alta que es una demo y no el producto; nunca se hace sobre la producción del cliente; y con el comercial acordamos antes si se cobra y qué pasa con ella si no ganamos.

Después de la firma: el control de cambios

Todo proyecto cambia. A la cuarta semana, Andrés quiso suscripciones mensuales de café. Buena idea, pero no estaba en la versión 1.0. El SOW no existe para evitar esos cambios, sino para darles un camino: el cliente lo pide, yo lo estimo con el mismo método, se dice qué le pasa a la fecha y al costo, y se aprueba por escrito antes de construirlo. Sin ese camino, cada «cambiecito» se vuelve una discusión, y la relación se gasta más rápido que el presupuesto.

Mi lista de chequeo antes de enviar un SOW

• ¿El objetivo está escrito en el lenguaje del cliente?
• ¿Lo que queda fuera de alcance está explícito?
• ¿Cada duda importante está como pregunta, supuesto o fase aparte?
• ¿La estimación tiene QA, DevOps, gestión y contingencia como líneas propias?
• ¿Cada entregable tiene criterio de aceptación?
• ¿Hay un camino claro para los cambios?
• ¿Los diagramas responden una pregunta real?
• ¿El comercial y yo estamos de acuerdo en lo que se promete?

Para cerrar

Si te toca escribir tu primer SOW, no arranques por la plantilla. Arranca por la sección de fuera de alcance y por tres supuestos escritos. Pide un día antes de dar cualquier número. Y antes de enviarlo, dáselo a alguien que no estuvo en las reuniones: si entiende lo mismo que tú, ya tienes lo más difícil.