Calculadora de productividad de equipos

Este sitio está pensado para ayudar en el primer paso, un análisis general, cuando estás pensando en cambiar un equipo: ¿sumar más personas aumentará la producción del equipo, o poner al día a los recién llegados y mantener a todos coordinados costará más de lo que aportan? También muestra qué pasa si alguien se va, o si cambias a una persona por otra. Si indicas cuánto tardaría un proyecto, también muestra cuándo terminaría.

• Proyectos personales: una mudanza, una reforma, cocinar para una fiesta, organizar un evento, limpiar el jardín con amigos.
• Trabajo: decidir si sumar a alguien a un equipo o proyecto (incluido uno que va con retraso), comparar a un becario con una contratación con experiencia, ver qué pierde un equipo cuando alguien se va, y ver hasta qué tamaño puede crecer un grupo antes de que cada persona extra deje de compensar.

Úsalo como primer filtro. Muestra si un cambio claramente vale la pena, claramente no, o si está demasiado ajustado para decidir. La decisión final necesita más pasos: un análisis más detallado de costes y presupuesto, plazos, el plan de incorporación, qué tareas se pueden dividir y repartir, la ruta crítica y los cuellos de botella, qué tareas requieren habilidades o permisos especiales, la disponibilidad de las personas, calidad, riesgo, etc.

• No lo alimentes con números optimistas. Las estimaciones de quienes no hacen el trabajo, o de quienes quieren un resultado concreto, suelen ser demasiado optimistas. En dos experimentos en los que equipos montaban modelos de LEGO, los equipos de cuatro personas necesitaron entre un 45 y un 54% más de minutos-persona que los de dos, y la gente subestimó esa diferencia, sobre todo quienes observaban desde fuera. En datos de 594 proyectos de software, las estimaciones eran más optimistas cuanto más grande era el equipo (Staats, Milkman & Fox, 2012).
• Acuerda los números con personas con experiencia que hacen el trabajo: lo productiva que es realmente una persona nueva al principio, cuánto tarda en alcanzar su ritmo pleno, cuánta fricción hay hoy en el equipo y cuánta añade alguien nuevo. El resultado solo es tan bueno como los números: si entra basura, sale basura.
• No mezcles roles en un mismo escenario. La calculadora suma producción, así que todas las personas de la tabla deben hacer el mismo tipo de trabajo (todos desarrolladores, todos enfermeros, todos de mudanza), con distintos niveles de experiencia. Un tester añadido a un equipo de desarrolladores no hace que el trabajo de los desarrolladores avance más rápido. Para un equipo con varios roles, crea un escenario por rol.
• No trates el resultado como un presupuesto, un calendario o un veredicto final. El modelo deja fuera el dinero, los plazos y qué tareas dependen de otras (consulta “¿Qué no tiene en cuenta esta calculadora?”).
• No tomes un mal resultado como motivo para renunciar a conseguir ayuda. Describe la situación tal como la introdujiste, y muchas veces eso se puede cambiar (consulta la siguiente pregunta).

No necesariamente. Pregúntate qué tendría que cambiar para que los números mejoren, y luego prueba esos cambios en la calculadora para ver cuáles importan más.

• Haz que los recién llegados sean productivos antes. Escribe las respuestas a las preguntas que hace cada persona nueva (unas preguntas frecuentes), prepara guías o vídeos cortos a los que puedan volver, prepara tareas de práctica o pequeños retos que enseñen el proyecto paso a paso, documenta los procesos poco intuitivos, asígnales un mentor y ten las herramientas y los accesos listos desde el primer día. En una encuesta a 411 ingenieros de software recién contratados en Microsoft, los mentores, los conocimientos previos, la formación y unas primeras tareas bien elegidas les ayudaron a ponerse al día, mientras que la documentación inexistente o desactualizada y la espera para obtener accesos los retrasaron (Rastogi et al., 2015).
• Reduce la fricción. Divide el trabajo para que pequeños grupos o parejas se encarguen cada uno de una parte, con pocos traspasos; deja claros los roles para que nadie tenga que esperar a nadie; elige a personas con las que sea fácil trabajar; y reduce al mínimo la política de oficina. Una revisión de 78 estudios encontró que las personas se esfuerzan menos en grupo, pero mucho menos cuando la contribución de cada uno es visible, la tarea les importa o trabajan con personas a las que valoran (Karau & Williams, 1993). El estudio de Google sobre 180 de sus equipos encontró que la seguridad psicológica (sentirse seguro para hacer preguntas y admitir errores) era lo que más importaba para el buen funcionamiento de un equipo (Google re:Work), en línea con investigaciones anteriores de Amy Edmondson (Edmondson, 1999).
• Incorpora a las personas antes. El coste de arranque llega primero y se recupera con el tiempo, así que cuanto antes entre alguien, más tiempo tiene para recuperarlo. Simulaciones de proyectos de software con retraso encontraron que, para cada proyecto, hay un momento antes del cual sumar suficientes personas puede ayudar (Hsia, Hsu & Kung, 1999).

La fricción (a efectos de esta calculadora) es la producción que se pierde porque hay otras personas: explicar cosas, aclarar malentendidos, negociar, responder preguntas, revisar y corregir el trabajo de los demás, más mensajes y reuniones, esperarse unos a otros y, en el trabajo físico, estorbarse, etc. Es la parte del tiempo de cada compañero que se va en coordinarse con el resto del equipo, en lugar de en su propio trabajo.

En la calculadora, cada persona tiene su propia fricción: la parte del tiempo de cada compañero que cuesta. Todos los demás del equipo pierden esa parte. Así, en un equipo de 3 donde cada uno causa un 5%, cada persona pierde 2 × 5% = 10% de su tiempo, y el equipo rinde como 2,7 personas a plena productividad. Por eso la producción se muestra en personas a plena productividad y no en número de personas. Los recién llegados y las personas con menos experiencia suelen causar más fricción al principio, y menos a medida que se adaptan.

Siempre quedará algo de fricción. Si una sola mente pudiera controlar dos cuerpos, trabajarían en perfecta sincronía y la fricción sería del 0%. Dos personas distintas, por bien que se lleven, siempre tendrán algo de fricción, aunque sea poca: siguen necesitando contarse qué hacen, ponerse de acuerdo y a veces esperarse. Por eso la fricción a largo plazo nunca es cero.

Esto se ha medido durante más de un siglo. En 1913, el ingeniero francés Maximilien Ringelmann observó que las personas que tiraban de una cuerda en grupo tiraban cada una con menos fuerza que solas, y menos cuanto mayor era el grupo. Una repetición del experimento en 1974, en la que los demás “miembros del equipo” solo fingían tirar, sugirió que gran parte de la caída se debe a que las personas se relajan en grupo, y no solo a una mala coordinación (Ingham et al., 1974; véase también Ringelmann effect). La tabla resumen de Ringelmann muestra que la producción de cada trabajador cae más o menos lo mismo, 7–8 puntos porcentuales, con cada persona extra, que es el patrón en línea recta que usa la calculadora. No dijo de qué tarea salía esa tabla, y sus mediciones tirando de la cuerda caían de forma más suave: los hombres que tiraban en grupos de 7 tiraban cada uno con unas tres cuartas partes de la fuerza que solos (Kravitz & Martin, 1986).

Para estimarla, pregunta a las personas con experiencia que hacen el trabajo qué parte de su jornada dedican a coordinarse con el resto del equipo, y divídela entre el número de compañeros con los que se coordinan. Esa es la fricción a largo plazo por persona, la que se alcanza cuando todos tienen experiencia. Por ejemplo, si cada persona de un equipo de 4 dedica alrededor del 15% de su tiempo a coordinarse con los otros 3, la fricción a largo plazo es de unos 15 ÷ 3 = 5% por persona. El valor inicial de una persona nueva es la parte del tiempo de cada compañero que se va en ayudarla al principio. Lo mejor es acordar estos números con personas que ya hayan formado a recién llegados para este tipo de trabajo.

Los rangos de la ayuda “?” son reglas prácticas propias, no resultados de investigación: fricción a largo plazo del 1–3% en trabajo independiente y del 5–10% en trabajo muy conectado; al inicio, del 5–15% para alguien con experiencia y del 20–40% para un becario.

La productividad (a efectos de esta calculadora) es cuánto trabajo útil hace la persona comparada con los mejores profesionales de tu sector, que cuentan como 100%. El valor inicial se aplica cuando entra: un becario puede aportar casi nada al principio (0–10%); alguien que ya ha hecho este tipo de trabajo en otro sitio puede empezar en un 60–90%. El valor a largo plazo es donde termina una vez adaptado.

Fijar el 100% en los mejores del sector, y no en la mejor persona de tu equipo, permite ser honesto sobre dónde está un equipo. En un equipo o una empresa que aún está madurando (procesos poco claros, herramientas que faltan, poca experiencia en este tipo de trabajo), incluso sus mejores personas pueden quedarse en un 70–80%, y vale la pena decirlo en voz alta: muestra cuánto se podría ganar mejorando el equipo, no solo sumando personas. Las personas a tiempo parcial, y las que tienen poco interés o aptitud para el rol, también se quedan por debajo del 100%.

El tiempo hasta el largo plazo es cuánto tarda, desde que entra, cada valor en llegar a su nivel a largo plazo, por separado para la productividad y la fricción. La fricción suele bajar en semanas o meses, cuando la persona nueva ya conoce a la gente, las herramientas y dónde están las cosas. La productividad puede seguir creciendo mucho más tiempo: en una tarea física sencilla pueden ser minutos u horas; en un trabajo cualificado, meses; y un júnior que crece hasta un rol sénior puede tardar años. Las personas que ya están en el equipo y se han adaptado por completo tienen 0 en ambos.

Igual que con la fricción, lo mejor es acordar estos números con personas que ya hayan formado a recién llegados para este tipo de trabajo.

Es frustrante, pero útil. Hace más difícil completar las cifras, pero también saca a la luz un problema que ya existía: las personas del equipo ven de forma distinta cómo funciona. Vale la pena saberlo, decidas lo que decidas. Y es normal: los expertos que juzgan el mismo caso discrepan mucho más de lo que creen (Kahneman, Sibony & Sunstein, Noise, 2021).

Primero, comprueba si el desacuerdo importa. Introduce las cifras más prudentes y las más optimistas como dos escenarios (“Duplicar el escenario actual”, en “Más opciones”). Si ambos dan la misma respuesta, puedes decidir ya y dejar la discusión para más adelante.

Si importa, averigua por qué hay desacuerdo.

• No hablan de lo mismo. Una persona compara con los mejores del sector y otra con los mejores del equipo. Antes de las cifras, conviene acordar las definiciones (consulta las dos preguntas anteriores).
• Ven partes distintas del trabajo. Quien forma a los recién llegados es quien más nota su fricción. En las discusiones en grupo, se tiende a hablar de lo que todos ya saben y a pasar por alto lo que solo sabe una persona (Stasser & Titus, 1985), así que pregunta a cada uno qué ve que los demás quizá no vean.
• Nadie lo sabe de verdad. Para un puesto que el equipo nunca ha tenido, cualquier cifra es una suposición. Dilo, y usa un rango.

Cada uno estima por su cuenta; luego se comparan. Pide a cada persona que anote sus cifras antes de que nadie comparta las suyas. El primer número que se dice en voz alta arrastra a los demás hacia él (Aranda & Easterbrook, 2005). En una empresa de software, las estimaciones acordadas de esta forma fueron menos optimistas que las estimaciones individuales simplemente combinadas, y a veces más precisas (Moløkken-Østvold & Haugen, 2007).

Después, usa las diferencias para mejorar el equipo. Habla con el equipo sobre cómo es un alto rendimiento o una fricción baja, qué impide mejorar, qué hábitos causan más fricción, a qué ritmo mejoran las cosas de forma realista, etc. Céntrate en comportamientos y procesos, no en personas concretas, o la conversación se convertirá en una búsqueda de culpables. Vale la pena: en una revisión de 31 estudios, los equipos que revisaban con regularidad su propio rendimiento mejoraron de media en torno a un 25% (Tannenbaum & Cerasoli, 2013).

Si aun así no hay acuerdo, conserva los escenarios y compáralos con la realidad. Anota qué espera cada uno (por ejemplo, cuándo un recién llegado podrá encargarse de las tareas por su cuenta) y vuelve a mirarlos al cabo de unas semanas o meses. El escenario más cercano a lo que pasó muestra en qué estimaciones confiar la próxima vez.

Lecturas recomendadas: Difficult Conversations (Stone, Patton & Heen, 1999); The Fearless Organization (Edmondson, 2018); Project Retrospectives (Kerth, 2001).

Indicar la duración de un proyecto es opcional. Es cuánto estimas que tardaría el proyecto con las personas que ya están en el equipo (marcadas como “Ya en el equipo”), estén marcadas o no. Eso fija el tamaño del proyecto: el trabajo que esas personas harían en ese tiempo, incluida su propia fricción y la de quien aún se esté adaptando.

Luego la calculadora calcula cuándo harían la misma cantidad de trabajo las personas marcadas. El gráfico muestra las dos fechas de finalización (cambia entre la vista del proyecto y la de largo plazo encima del gráfico), y una sección sobre el proyecto muestra cuánto antes o después termina y a partir de qué duración del proyecto compensa el cambio.

Sin duración de proyecto, el resultado trata de la producción del equipo a lo largo del tiempo: cuánto cae, cuándo se recupera y dónde se estabiliza.

Los costes llegan primero: la persona nueva aún no es plenamente productiva, y las que ya estaban pierden tiempo ayudándola. Los beneficios llegan después, cuando se ha puesto al día. En un proyecto corto no queda tiempo suficiente para que la producción extra recupere el coste de arranque. La sección sobre el proyecto muestra a partir de qué duración del proyecto empieza a compensar el cambio.

Cuando entran personas, la producción del equipo suele caer al principio y luego subir por encima de donde estaba. Hay dos momentos importantes:

• La producción se recupera: el momento en que la producción del equipo vuelve a su nivel anterior. En el gráfico, es donde se cruzan las dos líneas (el punto).
• La caída se compensa: más tarde, el momento en que la producción extra ha recuperado todo lo perdido durante la caída, de modo que el equipo ha hecho tanto trabajo en total como habría hecho sin el cambio. A partir de ahí, va por delante.

Ese segundo momento es también el proyecto más corto para el que compensa el cambio: un proyecto que al equipo actual le llevaría más tiempo termina antes con el cambio; uno más corto termina después. A veces hay dos cruces, por ejemplo cuando una persona útil entra de inmediato y un becario entra unas semanas después; entonces el resultado da los dos.

El resultado también indica cuándo compensa cada incorporación: cuando el equipo con ella ha hecho tanto trabajo en total como habría hecho sin ella. Dos personas que acaban siendo igual de productivas aportan lo mismo a largo plazo, pero una contratación con experiencia puede compensar en semanas y un becario solo después de un año.

• Alguien que se va ahora: desmárcalo. El resultado muestra el equipo sin esa persona, comparado con el equipo tal como está.
• Alguien que se va más adelante (ha renunciado, o vuelve a su propio equipo): indica cuándo en “hasta”. Se aplica a las dos líneas del gráfico, ya que va a ocurrir en cualquier caso, así puedes ver si contratar a alguien cubre el hueco.
• Alguien prestado durante un tiempo: indica cuándo entra y cuándo se va. Ayuda mientras está, pero el equipo paga el coste de ponerlo al día, y puede que ese coste no se recupere antes de que se vaya.

La calculadora deja fuera el traspaso de trabajo y el conocimiento que se va con una persona, así que el coste real de que alguien se vaya suele ser mayor que el que se muestra.

En este tipo de modelo, sí. Cada persona que se suma aporta su propia producción, pero todos pierden la fricción de esa persona, así que cada persona extra aporta un poco menos que la anterior. En algún momento, sumar una persona más reduce la producción del equipo. Por ejemplo, si todos son plenamente productivos y causan un 5% de fricción, un equipo de 10 rinde como 10 × (1 − 9 × 5%) = 5,5 personas a plena productividad; 11 personas rinden como 11 × 0,5 = 5,5; y 12 personas rinden como 12 × 0,45 = 5,4, un poco menos.

Una regla rápida cuando todos tienen la misma fricción: el tamaño ideal es de aproximadamente (1 + 1 ÷ fricción) ÷ 2. Con un 5%, eso es (1 + 20) ÷ 2 ≈ 10 a 11 personas. Puedes probarlo sumando personas a la tabla y viendo lo poco que aporta cada persona extra al resultado a largo plazo.

Esto encaja con investigaciones que sugieren que los equipos grandes son ineficientes. Un análisis de QSM de 564 proyectos de software de tamaño similar encontró que los equipos de más de 20 personas terminaban solo una semana antes, aproximadamente, que los de menos de 5 (8,92 frente a 9,12 meses) (QSM, 2012). La regla práctica del investigador de equipos J. Richard Hackman era “nada de dos cifras” (Harvard Business Review, 2009); en un experimento anterior, personas que trabajaban en grupos de distintos tamaños sentían que su grupo no era ni demasiado pequeño ni demasiado grande con unos 4,6 miembros (Hackman & Vidmar, 1970).

Es el tiempo ahorrado dividido entre el tiempo que tardaría el proyecto con el equipo actual. Por ejemplo, terminar en 7,46 semanas en lugar de 8 ahorra 0,54 semanas, y 0,54 ÷ 8 ≈ 6,7% más rápido.

Los costes necesitan cifras que mucha gente no tiene a mano, o que preferiría no escribir en un sitio web: sueldos, gastos generales, penalizaciones por retraso, lo que vale terminar a tiempo o antes, etc. El dinero también haría que el resultado pareciera más preciso de lo que puede ser un modelo sencillo.

Tampoco muestra el esfuerzo total en horas-persona. Eso trataría todas las horas como iguales, cuando una hora de un becario y una hora de una persona experta son muy distintas: la idea central de The Mythical Man-Month es que las personas y los meses no son intercambiables.

Para valorar el coste por tu cuenta, compara lo que te cuestan las personas añadidas durante el tiempo que participan con lo que vale para ti terminar antes, o la producción extra a largo plazo. Por ejemplo, si sumar 2 personas hace que el proyecto termine 30 días antes, participan durante 60 días y cada una te cuesta 400 $ al día, terminar un mes antes cuesta 48.000 $. Que valga la pena depende del plazo, de los ingresos o de las penalizaciones en juego.

• Pasos que deben hacerse en orden. Si una parte de un proyecto solo se puede hacer paso a paso, más personas no pueden acelerar esa parte: si el 10% de un proyecto es así, ni siquiera una ayuda ilimitada puede hacerlo más de 10 veces más rápido. En informática esto se conoce como la ley de Amdahl (1967); en gestión de proyectos, la cadena más larga de pasos que dependen unos de otros se llama ruta crítica.
• Límites físicos. En una cocina pequeña o en una escalera de mano solo cabe cierto número de personas.
• Cómo crece la fricción con el tamaño del grupo. Cada persona añadida cuesta a todos una parte fija de su tiempo, así que el coste total crece aproximadamente con el número de parejas, como describió Brooks: 3 personas forman 3 parejas, 10 personas forman 45. Los grupos grandes suelen dividirse en equipos más pequeños para reducirlo, algo que la calculadora no modela, así que para incorporaciones grandes el resultado puede ser demasiado pesimista.
• Aprendizaje curvo. Aquí la productividad y la fricción cambian en línea recta; en la realidad, la gente suele aprender rápido al principio y luego más despacio.
• Todo lo demás: horas extra y cansancio, la moral del equipo, la reputación de la organización, calidad y retrabajo, dinero, etc.

No hace falta, y los roles suelen funcionar mejor: “desarrollador sénior”, “becario”, “diseñadora nueva”. La calculadora solo necesita los números de cada persona.

Los nombres solo se guardan en tu navegador, pero se incluyen en los enlaces para compartir, y cualquiera que reciba el enlace puede verlos. Anotar lo productivo que es un compañero con nombre y apellido, o cuánta fricción causa, también puede resultar personal si se comparte. Si usas nombres, guárdate el escenario para ti o acuérdalo con las personas implicadas.

Los chatbots de IA son buenos para darle vueltas a una decisión y para la planificación detallada que viene después de este primer filtro. Esta calculadora tiene algunas ventajas frente a una IA:

• Mismos números, misma respuesta. Sigue siempre un único modelo fijo y probado. Una IA puede responder distinto cada vez que preguntas, sobre todo cuando se actualiza su modelo, o hacer las cuentas de otra manera.
• Neutral. No se deja llevar por la respuesta que esperas. Las IA pueden inclinarse por respuestas que te agraden.
• Fácil de compartir y discutir. Todos ven los mismos datos y el mismo resultado, así que las conversaciones sobre mejorar las condiciones de trabajo y el proyecto pueden centrarse en los datos.
• Puedes verlo y probarlo al instante. Los gráficos y los números muestran en tiempo real el impacto de cambiar las suposiciones.
• Privado. Lo que escribes se queda en tu navegador y no se usa para nada más.

Varias líneas de investigación, de hace más de un siglo, apuntan en la misma dirección, con excepciones importantes:

• Los grupos pierden parte de su potencial. Los experimentos de Ringelmann tirando de una cuerda (1913) mostraron que el esfuerzo individual caía a medida que crecían los grupos. El psicólogo Ivan Steiner (1972) describió la productividad real de un grupo como su potencial menos las “pérdidas de proceso” causadas por la forma en que sus miembros trabajan juntos. Una revisión de 78 estudios encontró que el hecho de que las personas se esfuercen menos en grupo (“holgazanería social”) es un efecto sólido en distintas tareas y poblaciones (Karau & Williams, 1993).
• La ley de Brooks. La versión más conocida de la idea es “Añadir personal a un proyecto de software con retraso lo retrasa aún más”, del libro de Fred Brooks The Mythical Man-Month (1975). El propio Brooks la llamó después una “simplificación escandalosa” (Wikipedia).
• Los equipos grandes son menos eficientes, y la gente lo subestima. En experimentos montando LEGO y en datos de 594 proyectos de software, la gente subestimó cuánto esfuerzo extra necesitan los equipos grandes (Staats, Milkman & Fox, 2012). Un análisis de QSM sobre su base de datos de más de 13.000 proyectos estimó que, para un proyecto típico de 100.000 líneas de código, un equipo de 32 usaría unos 178 meses-persona frente a unos 25 de un equipo de 4, produciría más de cinco veces más defectos y terminaría solo una semana antes, aproximadamente (QSM). En un estudio de 26 equipos de diseño de productos, las personas de los equipos más grandes rendían peor individualmente, sobre todo porque se sentían menos apoyadas y no sabían a quién pedir ayuda (Mueller, 2012).
• Pero sumar personas puede funcionar. Unas simulaciones encontraron que añadir personas a un proyecto de software con retraso siempre aumentaba su coste, pero no siempre lo retrasaba más: los retrasos solo ocurrían cuando suficientes tareas tenían que hacerse en secuencia, y sumar suficientes personas con suficiente antelación podía ayudar (Hsia, Hsu & Kung, 1999). Steve McConnell argumentó que los proyectos bien controlados se ven mucho menos afectados que los caóticos, y que un proyecto caótico que va con retraso suele ir con retraso porque se subestimó desde el principio, no porque se sumaran personas (McConnell, 1999).
• La incorporación y la cultura del equipo marcan la diferencia. Los mentores, la documentación y unas primeras tareas bien elegidas ayudaron a nuevos ingenieros de Microsoft a ponerse al día (Rastogi et al., 2015). Llegar al dominio completo lleva mucho más: en un gran proyecto de software, la producción bruta de los recién llegados se estabilizó después de alrededor de un año, pero siguieron asumiendo trabajo más difícil y central durante al menos tres años (Zhou & Mockus, 2010). Google encontró que la seguridad psicológica era lo que más importaba para la eficacia de sus equipos, mientras que el tamaño del equipo no tenía una relación significativa con ella en ese estudio (Google re:Work).
• Estimar las cifras en grupo. En las discusiones en grupo, se tiende a hablar de lo que todos ya saben y a pasar por alto lo que solo sabe una persona (Stasser & Titus, 1985). Un número dicho al principio arrastra hacia él las estimaciones posteriores (Aranda & Easterbrook, 2005), y en una empresa de software, las estimaciones acordadas después de que cada uno mostrara primero la suya fueron menos optimistas que las estimaciones individuales simplemente combinadas, y a veces más precisas (Moløkken-Østvold & Haugen, 2007). Una revisión de 31 estudios encontró que los equipos que revisan con regularidad su propio rendimiento mejoran de media en torno a un 25% (Tannenbaum & Cerasoli, 2013). Consulta “¿Y si mi equipo no se pone de acuerdo sobre las cifras de productividad o fricción?”

El modelo de la calculadora es nuestra propia simplificación de estas ideas, con curvas de aprendizaje y fricción en línea recta. Sirve para hacer visible el equilibrio, no para predecir una fecha exacta.

Tus escenarios se guardan solo en este navegador, en este dispositivo. Nada de lo que escribes se envía a nosotros ni a ningún servidor, y no hay cuenta. Al borrar los datos del navegador se borran tus escenarios guardados, y otros navegadores o dispositivos no los verán.

Los enlaces para compartir llevan el escenario en la parte de la dirección que va después de “#”, que los navegadores no envían al servidor del sitio. Pero cualquiera que tenga el enlace puede ver todo lo que contiene, incluidos los nombres o roles de la tabla, y la aplicación con la que lo envíes (por ejemplo, correo o chat) puede guardar una copia. Si lo prefieres, usa roles como “becario” en lugar de nombres (consulta “¿Debería poner nombres reales?”).

La página carga sus archivos de diseño, gráfico y tipografía desde una red pública de distribución de contenidos (jsDelivr). Como cualquier sitio web, puede ver que se cargaron los archivos, pero no tus escenarios.

Usamos Google Analytics para ver cómo se usa el sitio: cuántas personas lo visitan, desde qué países y sitios, y qué funciones usan (por ejemplo, añadir una persona o abrir un ejemplo). Nunca recibe nada de lo que escribes: ni nombres, ni números, ni resultados. Solo guarda una cookie si aceptas en el aviso; si rechazas, Google sigue recibiendo recuentos de visitas básicos y anónimos sin cookies (volver a mostrar el aviso).