«Esto es solo un momento»
Cualquiera que trabaje en la creación o mantenimiento de una página web, aplicación o sistema conoce este mensaje.
«¿Podéis cambiar solo este botón?»
«Es una corrección muy pequeña.»
«Solo moved este elemento, por favor.»
«¿Se puede hacer rápido?»
«¿No serán cinco minutos de trabajo?»
Y a veces realmente lo es.
A veces cambiar el color de un botón lleva unos minutos. A veces corregir una falta de ortografía requiere un solo clic. A veces el desarrollador abre el código, mira, cambia una línea y listo.
El problema es que no todo cambio que parece pequeño desde la perspectiva del usuario es pequeño desde la perspectiva del sistema.
Y el problema es mayor cuando hay varias de esas «pequeñas correcciones»: decenas o cientos al mes. Entonces empieza a ocurrir algo interesante.
La empresa puede tener la impresión de que no está pidiendo nada importante. Y al mismo tiempo el equipo de TI dedica una parte significativa de su tiempo a realizar precisamente esas pequeñas tareas.
Y aquí surge la pregunta: ¿Cuánto cuesta realmente un botón «Arreglen esto rápido»?
Empecemos con un ejemplo simple
Imaginemos que el departamento de marketing envía al software house este mensaje:
«Hola, solo necesitamos cambiar el texto de un botón. En vez de «Ver oferta» debería decir «Conocer la oferta». Es una tontería, por favor hacedlo rápido.»
Suena banal. Pero desde el punto de vista técnico puede ser muy distinto.
El desarrollador debe:
1. Analizar la solicitud
¿Dónde está ese botón?
¿Está solo en una página?
¿Aparece en varias versiones de la página?
¿El texto está escrito directamente en el código?
¿Se gestiona desde un CMS?
¿El cambio afecta a la versión de escritorio y a la móvil?
¿El botón forma parte de un componente reutilizado en otros lugares?
2. Implementar el cambio
Cambiar el texto.
Reestructurar el componente.
Actualizar el contenido en el CMS.
O modificar el código.
3. Comprobar el resultado
¿Sigue el botón viéndose correctamente?
¿No se sale el texto del área del botón?
¿Funciona bien en el móvil?
¿El cambio no ha afectado a otras partes?
4. Probar
¿Se puede hacer clic?
¿El enlace lleva adonde debe?
¿No ha aparecido ningún error?
5. Desplegar el cambio
Si el cambio requiere un deploy, hay que ponerlo en el entorno de producción.
Y de repente resulta que: «Solo cambiar el texto»
no necesariamente significa: «Solo cinco minutos de trabajo».
¿Cuánto puede costar un pequeño cambio?
Supongamos un escenario muy conservador.
El desarrollador dedica:
- 15 minutos al análisis,
- 20 minutos a implementar,
- 15 minutos a las pruebas,
- 10 minutos a preparar y desplegar.
Total: 60 minutos de trabajo.
Y aquí llegamos a un punto importante. Si la tarifa horaria del equipo es, por ejemplo, 200 zlotys netos, un cambio aparentemente pequeño cuesta alrededor de: 200 zlotys netos.
Pero eso no es todo. En el proceso real pueden aparecer:
- transferencias de la tarea,
- aclaraciones del alcance,
- preguntas al cliente,
- espera de respuesta,
- revisión del resultado por la persona que lo pidió,
- corrección tras el feedback,
- nuevo despliegue.
Una hora puede convertirse muy fácilmente en dos. Y un pequeño cambio en varias horas de trabajo de todo el equipo.
Lo más caro no siempre es ejecutar el cambio
Puede parecer paradójico. A veces la ejecución en sí lleva 10 minutos. Pero prepararse lleva otros 20. Luego vienen las pruebas, el despliegue, la comunicación y el cambio de contexto.
Y precisamente este último elemento suele estar muy infravalorado.
Context switching: el coste oculto de las tareas pequeñas
El desarrollador trabaja en una funcionalidad grande. Tiene el código abierto. Analiza el problema. Está concentrado.
De pronto aparece el mensaje: «Hola, solo una cosa pequeña. ¿Puedes arreglar el botón?»
El desarrollador interrumpe su trabajo. Abre la solicitud. Revisa la página. Busca el lugar en el código. Introduce el cambio. Prueba. Despliega. Vuelve a la tarea anterior...
Y entonces tiene que recordarse a sí mismo: «¿En qué estaba yo exactamente?»
Eso es el context switching, cambiar de contexto. Y puede ser muy costoso. No porque cada cambio requiera mucho trabajo, sino porque cada cambio interrumpe el proceso mental.
Cuanto más compleja es la tarea, mayor es el coste de volver a concentrarse. Por eso 10 microtareas no siempre equivalen a 10 × 10 minutos. En la práctica pueden ser mucho más.
Un botón no es nada. Cien botones ya son un proceso.
Supongamos que la empresa envía al equipo técnico:
- 20 pequeños cambios al mes,
- cada uno tarda de media 45 minutos.
Esto da: 15 horas de trabajo al mes.
A una tarifa de 200 zlotys netos: 3000 zlotys netos al mes.
Anual: 36 000 zlotys netos.
Y hablamos solo de 20 tareas pequeñas al mes. Sin funcionalidades grandes. Sin desarrollo de producto. Sin nuevos módulos. Sin integraciones. Sin diseño.
Solo: «cambiad», «arreglad», «moved», «añadid», «eliminad».
Ahora imagina una organización con 50 de estas tareas al mes. O 100.
La escala cambia por completo...
Las microtareas tienen otro coste: bloquean el desarrollo
Este es uno de los elementos más importantes del rompecabezas.
Si el equipo de desarrollo dedica un 20% de su tiempo a correcciones pequeñas, no puede dedicar ese 20% al desarrollo del producto. Suena obvio. Pero en la práctica a menudo no se ve.
La empresa pregunta: «¿Por qué la nueva funcionalidad aún no está lista?»
El desarrollador responde: «Porque tuvimos muchos temas operativos.»
«¿Qué tipo?»
«Correcciones, pequeños cambios, actualizaciones, tareas menores.»
Cada una era pequeña. Pero juntas crearon un gran bloqueo de trabajo. Es como las notificaciones del teléfono: una no molesta; diez ya un poco; cien?... De pronto descubrimos que pasamos el día reaccionando.
Con las microtareas pasa lo mismo.
«Pequeña tarea» no siempre es una tarea pequeña
También hay que entender que no todos los cambios son iguales. Cambiar un texto en un CMS puede llevar realmente unos minutos.
Pero cambiar un texto en una aplicación puede requerir:
- localizar el componente,
- modificar código,
- actualizar traducciones,
- realizar pruebas,
- reconstruir la app,
- desplegar.
Cambiar un solo campo puede implicar modificaciones en:
- front-end,
- back-end,
- base de datos,
- API.
Un cambio en un elemento puede afectar a otros elementos del sistema.
Por eso la pregunta: «¿Cuánto tardará cambiar este botón?»
sin conocer la arquitectura del sistema a menudo no tiene una respuesta sensata.
Primero hay que comprobarlo. Solo entonces se puede estimar.
¿Por qué a veces el desarrollador dice: «Tengo que revisarlo»?
No es para evitar dar una respuesta. A menudo es una muestra de profesionalidad.
Un buen desarrollador no debería prometer: «Sí, claro, cinco minutos»
si no sabe qué hay debajo.
Debería decir: «Voy a comprobar dónde se usa ese elemento y os aviso.»
Eso puede llevar 10 minutos. Pero esos 10 minutos pueden ahorrar varias horas de problemas. Porque el cambio más caro no suele ser el que lleva una hora.
Lo más caro es el que:
- rompe otra funcionalidad,
- provoca un error en producción,
- requiere un rollback urgente,
- genera más incidencias,
- necesita la intervención de varias personas.
Por eso el análisis antes del cambio forma parte del trabajo, no es una pérdida de tiempo.
Cómo puede el cliente reducir el coste de las microtareas
No se trata de dejar de solicitar pequeños cambios. Las pequeñas modificaciones son una parte normal del desarrollo de producto. Se trata de gestionarlas bien.
1. Agrupa las tareas pequeñas
En lugar de enviar:
«Cambiad el botón.»
«También corregid el título.»
«Y por cierto, añadid este enlace.»
«Y moved este elemento.»
Mejor agruparlas en un solo paquete.
El equipo podrá hacer varios cambios en un único ciclo de trabajo.
Menos cambio de contexto.
Menos comunicación.
Menos despliegues.
Menor coste.
2. Establece prioridades
No todo es urgente.
Si todo tiene el estado:
URGENTE
ninguna cosa lo es realmente.
Conviene clasificar las tareas en:
- críticas,
- importantes,
- planificables,
- cosméticas.
Así el equipo puede trabajar con más eficiencia.
3. Pregúntate si necesitas cambiar el código
Si la empresa cambia con frecuencia:
- textos,
- imágenes,
- banners,
- enlaces,
- mensajes,
tal vez el problema no sea la velocidad del desarrollador.
Quizá el problema sea la arquitectura.
Si cada cambio de contenido requiere un programador, vale la pena considerar un CMS o un panel de administración.
Un sistema bien diseñado debería permitir que el personal de negocio gestione de forma autónoma aquello que realmente no necesita intervención de un desarrollador.
Un buen sistema debe responder a la pregunta: ¿quién debe hacer este cambio?
Esta es una regla de diseño muy importante. No todos los cambios deben llegar al desarrollador.
Si marketing puede por sí mismo:
- cambiar textos,
- reemplazar imágenes,
- añadir artículos,
- cambiar el orden de secciones,
no tiene sentido involucrar a un programador.
El desarrollador debe ocuparse de lo que requiere sus competencias.
Por ejemplo:
- crear nuevas funciones,
- desarrollar el sistema,
- integraciones,
- optimización,
- seguridad,
- arquitectura,
- resolver problemas técnicos.
Si no, la empresa acaba pagando a un programador por trabajo que podría hacer el usuario del sistema.
Es como contratar a un mecánico para poner gasolina en el coche. Sí, sabe hacerlo. Pero ¿realmente lo necesitamos?
¿Cuándo decir: «Hagámoslo de otra manera»?
Si la misma petición aparece con regularidad, conviene pararse y preguntarse:
¿Por qué tenemos que hacerlo manualmente cada vez?
Si cada semana pedimos cambiar el mismo elemento, quizá deberíamos crear:
- una opción en el CMS,
- configuración,
- un panel administrativo,
- automatización,
- un mecanismo de autoservicio.
El coste único de crear esa solución puede ser mayor. Pero luego cada cambio costará segundos en lugar de horas.
Esa es la diferencia entre pagar por cada cambio y invertir en un sistema que permite a los usuarios hacer los cambios por sí mismos.
Microtareas y modelos de colaboración con un software house
Esto también es importante para los clientes.
Si la colaboración con el software house se basa exclusivamente en el modelo: «reportáis - presupuestáis - aceptamos - hacéis», cada pequeño cambio puede generar una sobrecarga organizativa adicional.
Por eso, en relaciones continuas, suelen funcionar mejor:
- paquetes de horas,
- suscripciones de mantenimiento,
- un equipo fijo,
- backlog de tareas,
- sprints regulares,
- ventanas de despliegue acordadas.
No significa que todos los clientes deban elegir el mismo modelo. Se trata de adaptar la forma de trabajo al carácter del proyecto.
Si la empresa necesita un cambio al mes, un proceso complejo puede ser innecesario. Si envía 50 tareas al mes, la falta de proceso puede ser muy costosa.
¿Conviene contabilizar cada cambio?
Depende.
En algunos proyectos tiene sentido contabilizar cada minuto. En otros puede generar más administración que ahorro.
Por eso es importante ver la colaboración en perspectiva.
La pregunta más importante no es: «¿Cuánto costó ese cambio?»
Mejor preguntar: «¿Cuánto nos cuesta la forma en que gestionamos todos los cambios?»
Si la empresa paga 200 zlotys por un cambio y con ello evita errores y tiene la seguridad de que todo funciona correctamente, puede ser razonable.
Pero si cada mes paga varios miles de zlotys por decenas de microtareas, conviene plantearse si no es mejor resolver el problema de forma sistémica.
¿Las palabras más caras en TI?
Tal vez suenen así: «Esto es solo un pequeño cambio.»
No porque los cambios pequeños sean malos. Son necesarios.
Un producto digital vive. Cambian las necesidades de los clientes. Cambia el mercado. Cambia el marketing. Cambia la tecnología. Los cambios son naturales.
El problema surge cuando la organización no ve su coste acumulado.
Un pequeño cambio? — Nada urgente.
Diez? — Aún poco.
Cien? — Ya es un proceso.
Y si hay varios procesos así? De pronto la empresa no gasta en desarrollar producto. Gasta en arreglar pequeñas cosas constantemente.
En vez de contar botones, contemos tiempo
Un desarrollo de producto bien gestionado no consiste en prohibir que el cliente solicite cambios pequeños.
Consiste en saber:
- qué cambios requieren realmente a un desarrollador,
- qué pueden hacer los usuarios por sí mismos,
- qué conviene automatizar,
- qué hay que agrupar,
- qué es verdaderamente urgente,
- qué se puede planificar,
- qué merece una solución sistemática.
Porque a veces la mejor respuesta a: «Arreglad esto rápido.»
no es: «Bien, lo haremos.»
sino: «Pensemos por qué dentro de un mes tendremos que arreglar esto otra vez.»
Aquí el software house deja de ser solo un ejecutor de tareas y pasa a ser un socio tecnológico. Un buen socio no solo realiza solicitudes. También ayuda a ver que a veces lo más barato no es hacerlo más rápido; lo más barato es no tener que hacerlo por centésima vez.
Y por eso un botón «Arreglen esto rápido» puede costar una hora.
Pero un sistema bien diseñado puede hacer que las siguientes cien correcciones las hagas tú mismo en unos minutos.
No es un ahorro en desarrolladores. Es una inversión en mejor proceso, mejor arquitectura y un uso más inteligente del tiempo de todo el equipo.
