10 Requisitos Previos de Escalabilidad Que Debes Conocer Antes de Escalar
Prepárate, porque estoy a punto de contarte la dura verdad sobre la escalabilidad.
Comenzaremos siendo realistas sobre el crecimiento en los negocios:
La mayoría de los intentos de escalar fracasan.
Entonces, ¿cuál es el ingrediente secreto? ¿Cómo se escala exitosamente un equipo y por qué es tan difícil?
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Si has estado en el sector del desarrollo de software el tiempo suficiente, lo más probable es que hayas vivido esta pesadilla:
- Al cliente se le promete una gran cantidad de funcionalidades en un plazo poco realista (que nadie se atreve a cuestionar).
- Luego, cuando la fecha límite está peligrosamente cerca, alguien con poder decide sumar más equipos al problema para cumplir con el plazo.
- Las cosas comienzan a desmoronarse.
¿Te suena familiar?
En este artículo te explicaré qué necesitas hacer para evitar volver a vivir esa situación (o, si has tenido la suerte de no experimentarla, para evitarla por completo).
Mi perspectiva en este artículo proviene de escalar equipos de desarrollo de software, pero puedes aplicar la teoría fundamental para escalar un negocio o hacer crecer un equipo en cualquier industria. Te será útil incluso si estás adoptando uno de los marcos de escalado predefinidos—Large Scale Scrum (LeSS), Scrum@Scale, SAFe.
Esto se debe a que me enfoco en varios aspectos importantes de la escalabilidad que nunca se mencionan en esas metodologías: la verdad fundamental sobre la naturaleza del crecimiento que a menudo se olvida o se ignora.
La Ley Fundamental de la Escalabilidad
La Ley Fundamental de la Escalabilidad es una observación empírica de lo que sucede en los proyectos cuando crecen:
Escalar amplifica lo malo y dificulta lo bueno.
Se me ocurrió esta formulación, pero no soy el único, ni el primero, en llegar a ese razonamiento.
Veamos qué significa la Ley en la práctica con algunos ejemplos de escalabilidad.
1. Ejemplo: Comunicación y Escalabilidad
El primero y más obvio es la comunicación. Es bien sabido que cuanto más gente hay en un proyecto, más canales de comunicación existen. Si los canales de comunicación no son lo suficientemente buenos al principio, escalar sólo empeorará el problema.
Por otro lado, si los canales de comunicación son buenos desde el inicio, escalar introducirá ciertos desafíos no solo por el aumento de personas, sino también por su distribución. A menudo los nuevos equipos se crean en diferentes ubicaciones, lo que obliga a cambiar los canales de comunicación; por ejemplo, pasar de reuniones presenciales a videoconferencias o substituir la pizarra por una herramienta electrónica.
2. Ejemplo: Integración Continua/Entrega Continua y Escalabilidad
La Ley Fundamental de la Escalabilidad también se observa en las canalizaciones de Integración Continua (CI) y Entrega Continua (CD). Cuando solo hay un equipo, todo es bastante sencillo.
Al pasar de uno a dos equipos, los sistemas de CI y CD se vuelven más complejos; habitualmente, si hay n equipos, el número de canalizaciones de CI tiende a ser n+1 (una por equipo y una para la integración). Esto tiene repercusiones evidentes en la provisión de entornos y en la coordinación entre equipos.
3. Ejemplo: Bucles de retroalimentación y Escalabilidad
Un último ejemplo: los bucles de retroalimentación. Los proyectos más grandes tienen bucles de retroalimentación más largos. Por lo tanto, refinar el sistema de manera iterativa se vuelve mucho más difícil, lo que aumenta las posibilidades de construir el producto equivocado.
Estos son solo tres ejemplos de algunos de los desafíos que aparecen al crecer. Seguro que puedes pensar en muchos más.
Supongamos que estás dispuesto/a a aceptar los sacrificios que implica. Lo siguiente que necesitas es que tu proyecto cumpla con algunos requisitos previos importantes para demostrar tu escalabilidad.
10 Requisitos Previos para Escalar
Que tengas o no un negocio, proyecto o equipo escalable depende de varios requisitos previos que detallo a continuación. Si los cumples todos, entonces tienes una alta escalabilidad. Por otro lado, si alguno de ellos no se cumple, las posibilidades de fracasar aumentan dramáticamente.
1. Presencia de objetivos claros y compartidos
Esto debería ser algo lógico, pero por mi experiencia, la ausencia de metas claras y compartidas es extremadamente común. Sin ellas, los equipos tirarán en distintas direcciones y será mucho más complicado entregar algo útil.
2. Uso de métricas adecuadas
Cuanto más grande es el proyecto, más importante es poder medir el impacto de las decisiones tomadas. Por ejemplo, ¿la incorporación de un nuevo equipo mejoró la capacidad de entrega del proyecto? ¿Estamos presionando tanto a los equipos que la calidad está disminuyendo? ¿Trabajan bien los equipos juntos o interfieren entre sí?
3. Una Arquitectura Apropiada
Si la “forma” del sistema no coincide con la estructura de los equipos, añadir más equipos solo empeorará las cosas. Este es un efecto directo de la Ley de Conway, una observación empírica bien conocida que ha sido probada en la práctica.
4. Disponibilidad de Habilidades Administrativas y Técnicas
Los problemas debidos a la falta de habilidades tendrán un efecto negativo amplificado a medida que el proyecto crece.
5. Buenos Canales de Comunicación
Cuanta más gente esté involucrada, más comunicación se genera. Para escalar con éxito se necesita una comunicación ágil.
6. Buena Priorización y Planificación
La falta de una priorización y planificación adecuadas, en mi experiencia, es un factor muy común en los fracasos de los proyectos. En particular, cuando hay más de un equipo involucrado, las actividades de priorización y planificación deben prever cómo mitigar los efectos de los retrasos y la falta de sincronización.
7. Buena Elicitación y Gestión de Requisitos
Esto va de la mano de la priorización y la planificación. Además, el efecto de requisitos incorrectos, mal entendidos o innecesarios se verá amplificado a medida que crezca el número de equipos.
8. Trabajo de Alta Calidad
Cuanto más grande es el proyecto, mayor es el efecto negativo de una mala calidad. En algunos escenarios patológicos (y comunes), algunos errores pueden volverse características, ya que los bucles de retroalimentación para corregirlos pueden ser tan largos que otros equipos podrían haber diseñado soluciones alternativas para neutralizarlos.
9. Disponibilidad de Recursos
Más equipos necesitan más escritorios, computadoras, herramientas y entornos.
10. Automatización Implacable
Cualquier actividad manual es un cuello de botella cuyos efectos se agravan con el número de personas y equipos. Un caso (muy común): actividades de pruebas manuales para asegurar que no se han introducido regresiones antes de una entrega en producción. En mi experiencia, ese es uno de los mayores cuellos de botella en cualquier proyecto, pero especialmente en aquellos que tienen más de un equipo.
Cuidado con la Escalabilidad Prematura
La escalabilidad está en la mente de las startups y los emprendedores en serie—y tienen una o dos lecciones que enseñarnos sobre escalar antes de tiempo.
Si intentas escalar antes de cumplir realmente con los requisitos indispensables para hacerlo con éxito—ya sea una empresa, un equipo u organización—el resultado es lo que la comunidad startup llama "escalabilidad prematura".
Una definición sencilla de escalabilidad prematura según el emprendedor en serie Jim Pitkow:
Escalabilidad prematura: crecer anticipando la demanda, en lugar de crecer impulsado por la demanda.
De hecho, escalar correctamente lleva tiempo—y la verdadera escalabilidad está impulsada por una necesidad real de escalar debido a la demanda, no por una noción impuesta artificialmente de simplemente volverse más grandes y hacer más cosas más rápido.
La comunidad startup ofrece un par de lecciones que podemos aplicar a nuestros equipos y proyectos al reflexionar sobre si realmente es el momento de escalar. Aquí hay algunas estadísticas del Startup Genome Report Extra sobre Escalabilidad Prematura:
- Las startups que escalan correctamente tardan un 76% más en escalar su tamaño de equipo que las startups que escalan prematuramente.
- El 74% de las startups de internet de alto crecimiento fracasan debido a la escalabilidad prematura.
- Las startups que escalan correctamente crecen aproximadamente 20 veces más rápido que las startups que escalan prematuramente.
Si te interesan más estadísticas sobre emprendimiento, consulta nuestro estudio sobre los estados más emprendedores de Estados Unidos.
¿De Verdad Estás Listo para Escalar?
Si tu proyecto está bien gestionado y cumple con los requisitos anteriores, tu próxima pregunta debería ser:
“¿Cuántos equipos pueden contribuir productivamente?”
Responderemos a esto en la próxima sección.
¿Cuál es el límite de la escalabilidad? Las leyes de Brooks y Amdhal
Es bien sabido que agregar más personas a un proyecto de software no necesariamente va a aumentar la productividad.
De hecho, en la mayoría de los casos, añadir más personas provocará una fuerte caída en la productividad.
Fred Brooks hizo esta observación en su libro The Mythical Man-Month, que luego se conocería como la Ley de Brooks:
“Agregar mano de obra a un proyecto de software retrasado lo retrasa aún más […] El número de meses de un proyecto depende de sus restricciones secuenciales. El número máximo de personas depende del número de subtareas independientes. A partir de estas dos cantidades, se pueden derivar cronogramas utilizando menos personas y más meses […]. Sin embargo, no se pueden obtener cronogramas viables usando más personas y menos meses.”
La segunda mitad de la cita anterior es, en mi opinión, la más interesante. De hecho, es básicamente la versión en lenguaje sencillo de la Ley de Amdhal: una fórmula que da la máxima aceleración teórica de un sistema concurrente:
La Ley de Amdhal
Aceleración = 1 / (s + p / n )
Donde:
s = porcentaje de tareas secuenciales
p = porcentaje de tareas en paralelo
s + p = 1
n = número de procesadores (equipos, en nuestro caso)
De hecho, un proyecto con varios equipos es una especie de sistema concurrente donde cada equipo es una unidad de procesamiento. En la práctica, la Ley de Amdhal indica que la cantidad máxima de trabajo concurrente está limitada por la cantidad de trabajo secuencial que debe hacerse.
En otras palabras, esto significa que las cosas que deben hacerse en un orden particular impondrán restricciones sobre la cantidad de tareas en las que los equipos pueden trabajar al mismo tiempo.
¿Qué es el trabajo secuencial en el contexto del desarrollo de software?
Quizás te estés preguntando qué tipo de tareas secuenciales afectan a los equipos de software.
Aquí tienes algunos ejemplos (seguro que puedes pensar en muchos más):
- Cualquier trabajo en las canalizaciones de integración y despliegue
- La fusión de cambios de software en código compartido por diferentes equipos
- Cualquier tipo de sincronización—por ejemplo, un equipo que depende de los entregables de otro antes de poder continuar su trabajo
- Esperar la provisión de recursos
Aplicando la Ley de Amdahl a la escalabilidad de equipos
El gráfico a continuación muestra las implicaciones de la Ley de Amdhal al aumentar el número de equipos en la productividad.
Podemos ver que la productividad aumentará de forma sublineal con el incremento en el número de equipos, hasta llegar a un punto máximo, a partir del cual volverá a disminuir.
Una ilustración de la ley de Amdahl: El rendimiento de entregables aumenta con el número de equipos, pero solo hasta cierto punto—y, normalmente, no es el que los gerentes esperan.
Si solo recuerdas una cosa de este artículo, que sea esta:
Aumentar el número de equipos puede incrementar el rendimiento, pero solo hasta cierto punto.
Entonces, ¿cuál es el número ideal de equipos para un proyecto determinado?
Desafortunadamente, no existen ecuaciones para calcular de antemano el número ideal de equipos para un proyecto. La única forma es utilizar un conjunto de métricas del proyecto para medir cosas como productividad y calidad, y observar qué sucede cuando se añade o elimina un equipo. Mi recomendación es empezar por poco con un equipo de 3 a 6 personas, y escalar solo cuando y si es necesario.
En algún momento, es posible que descubras que ya alcanzaste el número máximo de equipos, pero tu proyecto aún así no podrá cumplir con sus compromisos. Ahí es donde resultan útiles tus habilidades de priorización y comunicación, ya que probablemente tendrás que mantener algunas conversaciones difíciles con tus clientes.
Consideraciones sobre la estructura del equipo: ¿Equipos por funcionalidad o por componente?
Cuando incorporas un nuevo equipo al proyecto, ¿cómo debería trabajar? Para empezar, hazte estas dos preguntas:
- ¿Estarán a cargo de desarrollar funciones visibles para el cliente de principio a fin, o de cambiar algo en el sistema para alcanzar su objetivo?
- ¿Estarán a cargo de trabajar en un componente específico que provea parte de alguna funcionalidad visible al usuario?
Si respondiste sí a la pregunta #1, el equipo será un equipo de funcionalidades.
Si respondiste sí a la pregunta #2, será un equipo de componentes.
Consejos para elegir la estructura de equipo adecuada
Elegir la estructura de equipo y la organización del equipo apropiadas es muy importante, pero no es fácil. Actualmente, los equipos de funcionalidades parecen ser la opción preferida en la mayoría de las situaciones. Sin embargo, esa elección a menudo se basa en la costumbre o la rutina en lugar de en datos.
La realidad es que “depende”. Más específicamente, depende de la arquitectura del sistema. Los proyectos de software tienden a seguir lo que se conoce como la Ley de Conway, una observación empírica de Mel Conway:
“Las organizaciones que diseñan sistemas... están limitadas a producir diseños que son copias de las estructuras de comunicación de esas organizaciones”
En otras palabras, la “forma” de la estructura del equipo debe coincidir con la “forma” del sistema, o el proyecto experimentará serios problemas.
Por esta razón, siempre recomiendo a los gerentes que involucren a arquitectos senior y líderes técnicos en las decisiones sobre la estructura de los equipos; de lo contrario, realmente están diseñando el sistema sin darse cuenta (y sin las habilidades adecuadas). Eso, a su vez, puede aumentar significativamente el riesgo de fracaso del proyecto.
Dos paradojas de la escalabilidad
En mi experiencia como consultor en diferentes proyectos a gran escala, he llegado a la conclusión de que, en la mayoría de los casos, los proyectos escalan por las razones equivocadas.
He inventado dos paradojas que resumen lo que he visto en la práctica:
Primera paradoja de la escalabilidad
La mayoría de los proyectos se escalan porque no cumplen con los requisitos previos para escalar
Segunda paradoja de la escalabilidad
Los proyectos que cumplen con los requisitos previos para escalar tienen menos necesidad de escalar
La primera paradoja dice que, en la mayoría de las situaciones, los proyectos avanzan lentamente simplemente porque no están bien gestionados.
La segunda dice que los proyectos bien gestionados tendrán menos necesidad de escalar simplemente porque están bien gestionados.
De hecho, los proyectos más productivos que he visto tenían solo uno o dos equipos pequeños y cumplían con todos los requisitos previos para escalar. De todos los grandes proyectos en los que he participado, no he visto uno solo donde se cumplieran todos los requisitos previos para escalar. De hecho, todos tenían muchos problemas para cumplir cualquiera de los requisitos.
Si participas en un proyecto que está experimentando problemas y retrasos, la mejor recomendación que puedo darte es reducir el desorden antes de considerar ampliar el proyecto.
Conclusiones para escalar tus equipos de la manera correcta
Escalar equipos de desarrollo de software no es fácil y debe hacerse con sumo cuidado. Antes de irte, algunos pensamientos finales sobre cómo encontrar la manera más eficaz de escalar un equipo de desarrollo de software:
- Si trabajas en cumplir los requisitos para la escalabilidad, puedes descubrir que lo mantienes pequeño y evitas todos los problemas que conlleva un tamaño mayor.
- Por otro lado, si tu proyecto ya es grande y desafiante, entonces céntrate primero en reducir el desorden.
Aquí tienes los primeros pasos que te sugiero tomar después de leer este artículo:
- Descubre qué está pasando realmente en el trabajo diario
- Implementa algunas métricas para poder evaluar la situación actual, así como la calidad de las decisiones tomadas.
