Cuánto le hace ganar realmente un desarrollador: la verdad sobre el margen en el outstaffing
«Estaba seguro de que ganaba el 40% con cada desarrollador. La primera vez que hicimos el desglose por persona, salió el 11%. La diferencia era el banquillo, algo que sencillamente nunca consideré un costo.»
Esas son las palabras de un dueño que dirige un estudio de outstaffing de 14 ingenieros. La historia le resulta familiar a casi cualquiera que alquila un equipo por horas: la tarifa del cliente menos el salario del desarrollador parece ganancia. En realidad, entre esos dos números se esconde media empresa — y hasta que no desglose los costos por persona, está gestionando ingresos, no margen.
Por qué «tarifa menos salario» miente
Tomemos un desarrollador mid-level típico. Le factura al cliente $35 la hora; el desarrollador le cuesta cerca de $3.000 al mes después de impuestos. En la cabeza del dueño eso es $35 contra unos $20 — un margen cercano al 43%. Se ve genial, y es exactamente el número en el que la gente se apoya al decidir contratar más, dar un descuento o subir un salario.
El problema es que un desarrollador no entrega 160 horas facturables al mes. Entre proyectos, está en el banquillo. Incorporar a un nuevo cliente consume una semana mientras la persona se familiariza con código y procesos ajenos. Sume reuniones, revisiones de código, capacitación, días de enfermedad, vacaciones. La utilización real — la proporción de horas que el cliente realmente paga — rara vez supera el 75% incluso en estudios saludables. Y cada punto porcentual no facturable lo financia usted de su propio bolsillo.
El desglose para una persona
Contemos con honestidad, con los mismos números.
| Línea | Monto / mes |
|---|---|
| Tarifa al cliente | $35 / hora |
| Horas facturables (utilización del 75%) | 120 h |
| Ingreso del desarrollador | $4.200 |
| Salario + impuestos | −$3.000 |
| Contribución directa | $1.200 |
| Parte de gastos generales (oficina, PM, reclutamiento, administración) | −$700 |
| Ganancia real | $500 (12%) |
El 43% en el papel se convirtió en 12% en la vida real. Y ese es todavía el buen escenario. Si la utilización cae al 60% por un mes sin trabajo, el mismo desarrollador pasa a números negativos — aunque usted siga pagando el salario igual.
Calculemos para todo un año
La cifra mensual engaña porque el banquillo no es uniforme. Tomemos al mismo desarrollador mid-level durante un año. Diez meses trabaja al 80%, un mes al 40% (un proyecto terminó, el siguiente aún no había empezado), y en total una semana se va en días de enfermedad y capacitación. Durante el año, el cliente pagó aproximadamente 1.250 horas en lugar de las 1.920 teóricas. Ingresos: unos $43.750. Salario con impuestos: $36.000. Gastos generales por persona: $8.400. Ganancia anual del desarrollador: unos −$650. El mismo ingeniero que «da un margen del 43%» terminó el año ligeramente en negativo — todo por un mes vacío y algunas semanas no facturables repartidas a lo largo del año.
«El banquillo no aparece en ninguna factura, así que nadie lo ve. Y se come más que cualquier descuento a un cliente.»
Tres costos que todos subestiman
Primero, el banquillo. El tiempo entre proyectos lo paga usted, no el cliente. Una semana vacía al mes es un 25% menos de ingreso por persona con el mismo salario. En un estudio de 14 personas, incluso un banquillo promedio del 10% equivale a mantener a una persona y media que no aporta nada.
Segundo, las horas no facturables dentro de un proyecto. Standups diarios, sincronizaciones con el cliente, revisiones, investigación, retrabajo tras cambios en los requisitos. El cliente paga por 6 horas mientras se ocupan 8. Esas dos horas diarias también son su costo, solo que invisible.
Tercero, los gastos generales de gestión. Cada cinco o seis ingenieros necesitan un project manager, y reclutar o reemplazar a una persona cuesta cerca de un mes de su salario, más los meses hasta que el recién llegado alcanza la velocidad plena. Ese dinero no está ligado a ninguna factura, lo que hace fácil pasarlo por alto — hasta que calcula la ganancia por persona después de los gastos generales.
Cómo se ve esto en la vida real
El problema se escucha en frases típicas dentro del estudio. «Tenemos muchos proyectos, pero poca ganancia.» «Crecimos a 20 personas, pero el dueño gana como si tuviera 12.» «Se cayó un cliente — no pasa nada, ponemos a la persona en un proyecto interno» (es decir, en banquillo completo a costa suya). «Démosle a este cliente un descuento del 10%, es grande» — mientras el margen en esa cuenta ya era del 12%, y el descuento la vuelve deficitaria.
Todo esto son síntomas de una sola cosa: el estudio calcula la diferencia tarifa-menos-salario y nunca calcula la ganancia por persona después del banquillo y los gastos generales. Los ingresos son grandes, y el dueño se pregunta adónde se fue la ganancia.
Cómo ver el margen de cada desarrollador
Para gestionar esto, necesita ver los ingresos y los costos por persona o por proyecto, no todo junto en una sola olla. En Finmap usted crea proyectos y direcciones, registra el ingreso del cliente y el costo directo de la persona que hace el trabajo — y ve el margen bruto por ingeniero y para el estudio en conjunto. El banquillo deja de ser invisible: un mes vacío aparece de inmediato en el informe, no seis meses después como un vago «la ganancia bajó por alguna razón». También ve qué cliente trae un margen normal y cuál solo ocupa a la gente casi gratis.
Relacionado — en qué se diferencia la contabilidad de gestión de la contabilidad en IT y cómo medir la utilización del equipo.
Qué hacer al respecto
- Fije una utilización objetivo y vigílela semanalmente, no una vez al trimestre. Una semana vacía detectada a tiempo todavía se puede cerrar con una venta.
- Incluya el banquillo en el precio: la tarifa debe cubrir no solo las horas ocupadas, sino también las inevitables horas vacías. Si la utilización objetivo es del 75%, la tarifa se calcula a partir de eso, no del 100%.
- Mida la ganancia por persona después de los gastos generales, no la diferencia bruta tarifa-menos-salario. Solo la primera cifra dice la verdad.
- Observe el margen por cliente: un cliente grande con descuento a menudo trae menos que uno pequeño a tarifa completa.
- Planifique reemplazos y contrataciones según la carga de trabajo, no «por si acaso». Cada persona «para el crecimiento» sin proyecto es banquillo puro a costa suya.
El outstaffing parece un negocio simple hasta que empieza a calcular por persona. En cuanto lo hace, queda claro quién realmente gana, quién está en el banquillo y por dónde se filtra el margen a través de las horas no facturables. Y entonces las decisiones sobre contratación, descuentos o un nuevo proyecto se toman con números, no con la sensación de que «hay mucha gente, así que todo debe estar bien».
Money Doesn't Disappear. You Just Don't See It.
Pruebe Finmap gratis durante 14 días y vea el margen de cada desarrollador y proyecto este mismo mes — sin armar planillas a mano.
Preguntas frecuentes
Una referencia saludable es entre el 75% y el 85% de horas facturables. Por encima del 90% suele significar agotamiento y cero tiempo para el desarrollo; por debajo del 70% significa que el banquillo se está comiendo su margen. Lo importante es medirlo con regularidad, no calcularlo a ojo.
Sí. Si la tarifa cubre solo las horas ocupadas, financia cada semana vacía con su ganancia. Incorpore una utilización objetivo en el precio para que la tarifa resista las pausas normales entre proyectos.
La forma más simple es de manera proporcional a las horas facturables o al ingreso de cada persona. Lo clave es hacerlo de la misma manera cada mes para que la ganancia por persona se mantenga comparable a lo largo del tiempo.
Los clientes grandes casi siempre piden un descuento por volumen, y además suele mantenerse gente «de reserva» para escalar el equipo rápido para ellos. El descuento sumado a ese banquillo dedicado fácilmente convierte una cuenta aparentemente atractiva en la más pobre en términos de margen.
No, si es un banquillo puntual entre proyectos. La alarma empieza cuando el número negativo se mantiene durante dos o tres meses seguidos: entonces, o la tarifa es demasiado baja, o la persona no está ocupada, y eso ya es un problema estructural.
