Tu desarrollador puede construirlo. Esa no es la pregunta
Una construcción interna compite con tu roadmap y no con una fecha, y esa diferencia decide más proyectos que cualquier comparación técnica.
La pregunta sobre capacidad es la fácil
Tu desarrollador puede construirlo. En la mayoría de los casos eso es sencillamente cierto, y cualquier comparación que empiece sembrando dudas al respecto merece desconfianza.
Las preguntas interesantes son otras. Qué deja de construirse en su lugar, y si un proyecto sin fecha llega a terminarse.
El precio invisible
Una construcción interna cuesta lo que venía a continuación en el roadmap. Ese precio nunca aparece como partida, y por eso rara vez aparece en la decisión.
Si lo que tu desarrollador entregaría en su lugar es el producto por el que pagan tus clientes, la automatización es cara de un modo que la factura nunca mostrará. Si el equipo está genuinamente ocioso, la aritmética se invierte y construir internamente es claramente lo correcto.
El movimiento útil es hacerlo explícito. Nombra la funcionalidad o el arreglo que se retrasará. Ponle una fecha. Enséñale esa fecha a quien es dueño del roadmap y mira si el intercambio sigue pareciendo obvio.
Por qué se estiran los proyectos internos
Compiten con un roadmap y no con una fecha, y un proyecto sin fecha de entrega no tiene mecanismo para terminar.
El patrón es lo bastante consistente como para planificarlo. La construcción empieza rápido y bien. Luego llega un problema urgente de cliente, luego una release, luego alguien se va, y la automatización se convierte en lo que se coge entre otras cosas.
Seis semanas de trabajo repartidas en ocho meses no son seis semanas de trabajo. El problema operativo sigue sin resolver durante esos ocho meses, y los requisitos se deslizan por debajo del sistema a medio construir.
La entrega externa no es más rápida porque la gente sea mejor. Es más rápida porque el trabajo tiene una fecha, un alcance fijo y nada más compitiendo por las mismas horas. Si construyes internamente, el arreglo es darle al proyecto esas tres cosas en vez de confiar en la suerte.
Qué gana de verdad cada lado
| Interno | Agencia | |
|---|---|---|
| Conoce tus sistemas no documentados | Sí | Los aprende, al coste de unos días |
| Tiene fecha de entrega | Rara vez | Por contrato |
| Ha visto esto fallar antes | A veces | Es lo que estás comprando |
| Sigue ahí en el mes cuatro | Sí | Solo si se contrata |
| Depende de que una persona se quede | Normalmente | No |
| Coste en la factura | Ninguno | Real |
| Coste para el roadmap | Real | Ninguno |
Las dos últimas filas son la comparación entera, y apuntan en direcciones opuestas. Todo lo demás es detalle.
El arreglo que suele ganar a ambos
No una elección. Una división.
Entrega externa contra una fecha, propiedad interna desde la primera semana. La persona que será dueña del flujo participa en la construcción en lugar de recibir un documento de traspaso al final, y el conocimiento se transfiere por participación y no por papeleo.
Es el modelo con el que trabajamos, y por eso la condición del dueño con nombre pertenece a la propuesta y no a la última semana. También produce lo que una construcción interna produce de forma natural y una externa a menudo no: alguien que entiende de verdad por qué el sistema hace lo que hace.
Sobre contratar para esto
Solo si tienes suficiente trabajo de automatización para mantener a la persona interesada, y ese listón es más alto de lo que parece.
Un ingeniero de automatización es un punto único de fallo de un modo en que una agencia no lo es. El trabajo tiene además un problema de retención que nadie menciona: construir los tres primeros flujos es interesante, mantenerlos mientras los sistemas de alrededor cambian no lo es. Las empresas que contratan para esto y luego se quedan sin cosas nuevas que construir suelen perder a la persona en un año y heredar un sistema que solo ella entendía.
Si el pipeline es real, un flujo por trimestre indefinidamente, contratar gana en economía por amplio margen. Si son dos proyectos y luego mantenimiento, compra las construcciones y quédate con la propiedad.
Antes de cualquiera de las dos
Ninguna vía ayuda si el proceso no está listo, y ni proveedor ni empleado deberían presupuestar antes de que alguien haya contado. La semana de medición se aplica igual a una construcción interna, y un equipo interno es, si acaso, más propenso a saltarse la medición porque ya cree conocer el proceso.
Normalmente conoce su parte. Eso es otra cosa, y por qué casi todos los mapas de procesos son inútiles trata exactamente de esa distancia.
01¿Sale más barato construir la automatización en casa?+
En la factura, casi siempre. En coste total, depende de algo que la mayoría de las comparaciones deja fuera por completo, que es lo que tu desarrollador deja de hacer. Una construcción interna tiene un precio real igual a lo que venía a continuación en el roadmap, y ese precio es invisible porque nunca aparece como partida. Si lo que construiría en su lugar es el producto por el que pagan tus clientes, la automatización es mucho más cara de lo que parece aunque no cambie de manos ningún dinero. Si tus desarrolladores están genuinamente ociosos, el cálculo se invierte y construir internamente pasa a ser la respuesta directa. El movimiento útil es hacer explícito el coste de oportunidad antes de decidir: nombra la funcionalidad o el arreglo que se va a retrasar, ponle una fecha, y mira si el intercambio sigue pareciendo obvio a quien es dueño de ese roadmap.
02¿Por qué los proyectos internos de automatización tardan tanto más?+
Porque compiten con un roadmap en lugar de con una fecha, y un proyecto sin fecha de entrega no tiene mecanismo para ser terminado. El patrón es lo bastante consistente como para planificarlo: la construcción empieza rápido y bien, luego llega un problema urgente de cliente, luego una release, luego alguien se va, y la automatización se convierte en lo que se coge entre otras cosas. Seis semanas de trabajo repartidas en ocho meses no son lo mismo que seis semanas de trabajo, porque el problema operativo que iba a resolver sigue sin resolver durante esos ocho meses y los requisitos se deslizan por debajo. La entrega externa no es más rápida porque la gente sea mejor; es más rápida porque el trabajo tiene una fecha, un alcance definido y nada más compitiendo por las mismas horas. Si construyes internamente, el arreglo es darle al proyecto esas tres cosas en vez de confiar en la suerte.
03¿Qué hace genuinamente mejor un desarrollador interno?+
Dos cosas, y ambas valen dinero de verdad. Conoce tus sistemas, incluidos los no documentados, el campo que significa algo distinto de lo que dice su nombre, y la integración que alguien escribió hace cuatro años y nadie ha tocado desde entonces. Un equipo externo gasta sus primeros días descubriendo exactamente eso, y en un parque poco habitual esos días pueden ser una porción significativa del proyecto. La segunda ventaja es la permanencia: sigue ahí en el mes cuatro, cuando un proveedor cambia un formulario, y su conocimiento del flujo se acumula en vez de irse con un contrato. Por eso el arreglo más fuerte no suele ser elegir entre ambos sino dividir: entrega externa contra una fecha, propiedad interna desde la primera semana, para que quien hereda haya estado en la sala todo el tiempo en lugar de recibir un documento de traspaso.
04¿Deberíamos contratar a alguien específicamente para automatización?+
Solo si tienes trabajo suficiente para mantener a esa persona interesada, y ese listón es más alto de lo que parece al principio. Un ingeniero de automatización es un punto único de fallo de un modo en que una agencia no lo es, y el trabajo tiene un problema de retención del que nadie avisa: construir los tres primeros flujos es genuinamente interesante, y mantenerlos mientras los sistemas de alrededor se mueven no lo es. Las empresas que contratan para esto y luego se quedan sin nada nuevo que construir suelen perder a la persona en un año y heredar un sistema que solo ella entendía. Si el pipeline es real, un flujo por trimestre indefinidamente, contratar gana en economía por amplio margen. Si son uno o dos proyectos y después mantenimiento, compra las construcciones y quédate con la propiedad, que cuesta una fracción de un salario y no depende de que una persona se quede.
