Cómo medir la productividad de los desarrolladores: casos reales de Google, Notion y otras empresas

xguru · 2024-01-22T11:06:01+09:00

Un análisis profundo de cómo 17 empresas tecnológicas como Google, LinkedIn, Peloton, Amplitude, Intercom, Notion y Postman miden la productividad de los desarrolladores 1. Métricas de productividad de desarrolladores en 17 empresas tecnológicas Medir la productividad de los desarrolladores es un problema complejo, y en un trabajo basado en conocimiento como la ingeniería de software, el significado mismo de ser "productivo" es ambiguo Equipos llamados de productividad de desarrolladores (DevProd) o experiencia de desarrolladores (DevEx) apoyan a los desarrolladores para que puedan desplegar software de alta calidad con facilidad Estos equipos necesitan métricas de productividad de desarrolladores para medir la productividad y los obstáculos de los equipos de ingeniería, y para rastrear si su trabajo realmente tiene impacto Métricas de productividad de desarrolladores que usan estas empresas Facilidad de entrega (Amplitude, GoodRx, Intercom, Postman, Lattice) Velocidad de experimentación (Etsy) Estabilidad del servicio/aplicación (DoorDash) Métricas SPACE (Microsoft) Horas semanales de enfoque por ingeniero (Uber) Se seleccionaron 4 grupos según el tamaño de la empresa Google: más de 100,000 empleados LinkedIn: más de 10,000 Peloton: entre 1,000 y menos de 10,000 Scale-ups (entre 100 y menos de 1,000 ingenieros): Notion, Postman, Intercom, Amplitude, GoodRx, Lattice 2. El enfoque de Google Google suele mencionarse como una referencia en medición de productividad de desarrolladores, pero también se argumenta que imitar el nivel de inversión de Google es imposible para la mayoría de las empresas El equipo de Developer Intelligence de Google es un área especializada que mide la productividad de los desarrolladores y proporciona insights a los líderes Google cree que una sola métrica no puede capturar la productividad, y la observa a través de tres dimensiones: velocidad, facilidad y calidad Speed velocidad: ¿cuánto tiempo toma completar una revisión de código? Ease facilidad: ¿qué tan fácil o difícil es para un desarrollador avanzar por el proceso de revisión de código? Quality calidad: ¿qué tan buena es la retroalimentación recibida a través de la revisión de código? Google calcula sus métricas mezclando mediciones cualitativas y cuantitativas 3. LinkedIn LinkedIn opera de forma independiente dentro de Microsoft y emplea a más de 10,000 personas LinkedIn cuenta con un equipo de Developer Insights que mide la productividad y satisfacción de los desarrolladores y transmite insights al resto de la organización LinkedIn captura métricas usando encuestas trimestrales, un sistema de retroalimentación en tiempo real y métricas basadas en sistemas Encuestas trimestrales: El equipo de Developer Insights evalúa la experiencia de los desarrolladores en distintas herramientas, procesos y actividades mediante encuestas trimestrales La encuesta incluye unas 30 preguntas y los desarrolladores pueden responderla en unos 10 minutos La encuesta se ofrece a través de una plataforma propietaria desarrollada y administrada por el equipo de Developer Insights, que permite una personalización y adaptación avanzadas de las preguntas basadas en datos recopilados por el sistema de retroalimentación en tiempo real y el sistema de métricas Sistema de retroalimentación en tiempo real: Para recopilar retroalimentación entre encuestas trimestrales, LinkedIn desarrolló un sistema de retroalimentación en tiempo real que rastrea eventos y acciones que los desarrolladores realizan dentro de las herramientas de desarrollo y envía encuestas dirigidas según disparadores específicos Este sistema usa un mecanismo inteligente de throttling para evitar que a los desarrolladores les lleguen demasiadas solicitudes de retroalimentación Métricas basadas en sistemas: LinkedIn también usa datos del sistema para calcular métricas y así obtener mediciones de alta precisión sobre elementos como tiempo de build y frecuencia de despliegue El equipo de Developer Insights mantiene un sistema global para recopilar y analizar estos datos, al que llaman Developer Insights Hub (o iHub) Este sistema permite que todos los equipos de LinkedIn creen dashboards y métricas personalizadas según sus necesidades LinkedIn considera tanto métricas cualitativas como cuantitativas Satisfacción neta de usuario del desarrollador (Developer Net User Satisfaction, NSAT): mide qué tan satisfechos están en general los desarrolladores con los sistemas de desarrollo de LinkedIn. Se mide trimestralmente Tiempo de build del desarrollador (Developer Build Time, P50 y P90): mide en segundos cuánto tarda un desarrollador esperando que un build termine localmente durante el desarrollo Tiempo de respuesta del revisor de código (Code Reviewer Response Time, P50 y P90): mide cuánto tarda un revisor de código en responder a cada actualización de revisión de código del autor, en horario laboral Velocidad de CI post-commit (Post-Commit CI Speed, P50 y P90): mide en minutos cuánto tarda cada commit en pasar por el pipeline de integración continua (CI) Determinismo de CI (CI Determinism): el concepto opuesto a la inestabilidad de pruebas. Significa la probabilidad de que el resultado de una suite de pruebas sea válido y no un error Tasa de éxito de despliegue (Deployment Success Rate): mide con qué frecuencia los despliegues a producción tienen éxito Medias winsorizadas (Winsorized Means): una forma de reconocer mejoras dentro de métricas con valores atípicos. Se calcula reemplazando los valores más altos y más bajos por números más cercanos al centro Índice de experiencia del desarrollador (The Developer Experience Index): una métrica especial que LinkedIn proporciona a sus equipos. Es una puntuación compuesta basada en varias métricas como las enumeradas anteriormente 4. Peloton Peloton es una empresa grande con alrededor de 3,000 a 4,000 empleados, mucho más pequeña que LinkedIn El enfoque de medición de Peloton comenzó obteniendo insights cualitativos a través de encuestas de experiencia de desarrolladores, y después las usó junto con métricas cuantitativas Peloton mide la productividad enfocándose en cuatro áreas principales: participación, velocidad, calidad y estabilidad Participación (Engagement): puntaje de satisfacción de los desarrolladores Velocidad (Velocity): tiempo hasta el primer y décimo PR de todos los nuevos ingresos, lead time y frecuencia de despliegue Calidad (Quality): proporción de PR con menos de 250 líneas, cobertura de líneas y tasa de fallas por cambio Estabilidad (Stability): tiempo de recuperación del servicio La encuesta de experiencia de desarrolladores, que mide gran parte de estas métricas, es liderada por el equipo de soporte técnico y experiencia de desarrolladores de Peloton, que forma parte de la organización de operaciones de producto El equipo de soporte técnico y experiencia de desarrolladores también se encarga de analizar los resultados de la encuesta y compartirlos con los líderes de toda la organización 5. Scale-ups y empresas pequeñas Varias scale-ups como Notion, Postman, Amplitude, GoodRx, Intercom y Lattice emplean entre 100 y 1,000 ingenieros Estas empresas se enfocan en "métricas movibles (Moveable Metrics)" Las métricas movibles son aquellas que un equipo de productividad de desarrolladores puede "mover" al impactarlas positiva o negativamente con su trabajo. Son útiles para que el equipo de productividad de desarrolladores demuestre su impacto Métricas comunes Facilidad de entrega (Ease of Delivery, moveable): La mayoría de las empresas mide la facilidad de entrega, una escala cualitativa sobre qué tan fácil o difícil sienten los desarrolladores que es realizar su trabajo Varios líderes de DevProd dicen que esta métrica es la 'estrella polar' de su trabajo, porque el objetivo del equipo es hacerles la vida más fácil a los desarrolladores Esta métrica también es útil para mostrar impacto porque es bastante movible Desde una perspectiva teórica, esta métrica también captura aspectos clave de la experiencia de desarrolladores, como la carga cognitiva y los ciclos de retroalimentación Participación (Engagement) Se rastrea la participación, que mide qué tanto interés y estímulo sienten los desarrolladores respecto a su trabajo Normalmente la participación se mide en encuestas de RR. HH., pero los equipos de DevProd también destacan su enfoque en participación por esta razón La participación del desarrollador y la productividad están estrechamente relacionadas. Es decir, así como se dice que "un desarrollador feliz es un desarrollador productivo", la participación del desarrollador puede verse como un indicador de productividad El verdadero beneficio de medir la participación es que puede equilibrar otras métricas que enfatizan la velocidad. Entregar software más rápido es bueno, pero no debe hacerse a costa de reducir la felicidad de los desarrolladores Pérdida de tiempo (Time Loss, moveable) GoodRx y Postman ponen atención al promedio de pérdida de tiempo Se mide como la proporción del tiempo de los desarrolladores que se pierde debido a obstáculos en el entorno de trabajo Esta métrica es similar a la facilidad de entrega en el sentido de que proporciona una métrica movible que puede verse afectada directamente por el trabajo del equipo de desarrollo Tiene la gran ventaja de que puede traducirse a costos, por lo que los líderes de negocio pueden entender fácilmente la pérdida de tiempo Por ejemplo, si en una organización con un costo de personal de ingeniería de 10 millones de dólares una iniciativa reduce la pérdida de tiempo de 20% a 10%, eso se traduce en un ahorro de 1 millón de dólares Tasa de fallas por cambio (Change Failure Rate) Esta es una de las cuatro métricas principales del programa de investigación DORA (DevOps Research and Assessment) Es una métrica de alto nivel que rastrean varias empresas, incluidas Amplitude y Lattice El equipo de DORA define la tasa de fallas por cambio de la siguiente manera: "el porcentaje de cambios liberados a producción o a los usuarios que provocan una degradación del servicio (por ejemplo, una interrupción o caída del servicio) y luego requieren corrección (por ejemplo, hotfix, rollback, corrección hacia adelante o parche)" 6. Hallazgos interesantes Las métricas DORA y SPACE se usan de manera selectiva, y todas las empresas emplean tanto mediciones cualitativas como cuantitativas DORA: DevOps Research and Assessment SPACE: Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow Hay un gran énfasis en el "tiempo de enfoque", y Stripe y Uber compartieron métricas concretas como "días con suficiente tiempo de enfoque" y "horas semanales de enfoque por ingeniero" Métricas únicas Adoption Rate (DoorDash, GoodRx, Spotify) Design Docs Generated per Engineer (Uber) Experiment Velocity (Etsy) Developer CSAT/NSAT (Chime, LinkedIn) 7. Cómo elegir tus propias métricas Es recomendable usar el framework Goals, Signals, Metrics (GSM) de Google para guiar la selección de métricas Primero define el objetivo del problema que quieres resolver, luego encuentra las señales que indiquen que lograste ese objetivo, y después elige las métricas adecuadas Definir objetivos Google: "Ayudamos a los desarrolladores a entregar excelentes productos de forma rápida y fácil." Slack: "Proporcionamos un entorno de desarrollo fluido para cada ingeniero." Stripe: "Hacemos que la ingeniería de software sea más fácil." Trabajar hacia atrás desde el objetivo para definir métricas de alto nivel Qué tan fácil es para los desarrolladores entregar software (Ease): Ease of Delivery, Deployment Lead Time, Build Failure Rate Qué tan rápido entregan software los desarrolladores (Speed): Perceived Delivery Speed, Perceived Productivity La calidad del software entregado (Quality): Incident frequency, Perceived Software Quality Si eres CTO, VPE o líder de ingeniería El mejor consejo es "replantear el problema (reframe the problem)" Elegir métricas de tres buckets Impacto de negocio ¿Por qué hay que construir esto ahora? ¿De qué manera este proyecto genera ingresos o apoya los objetivos del negocio? ¿Este proyecto va bien o está retrasado? Desempeño del sistema ¿Los sistemas de ingeniería son rápidos y estables? ¿La infraestructura es segura y está bien mantenida? ¿Los usuarios están satisfechos con los servicios que usan? Eficiencia de ingeniería Medir con una mezcla de métricas cualitativas y cuantitativas es algo común en todas las empresas Vale la pena inspirarse en las distintas mediciones que usa cada empresa Hay grandes diferencias en qué se mide con más énfasis según las prioridades y la cultura de ingeniería de cada empresa

(newsletter.pragmaticengineer.com)

53 puntos por xguru 2024-01-22 | 1 comentarios | Compartir por WhatsApp

Un análisis profundo de cómo 17 empresas tecnológicas como Google, LinkedIn, Peloton, Amplitude, Intercom, Notion y Postman miden la productividad de los desarrolladores

1. Métricas de productividad de desarrolladores en 17 empresas tecnológicas

Medir la productividad de los desarrolladores es un problema complejo, y en un trabajo basado en conocimiento como la ingeniería de software, el significado mismo de ser "productivo" es ambiguo
Equipos llamados de productividad de desarrolladores (DevProd) o experiencia de desarrolladores (DevEx) apoyan a los desarrolladores para que puedan desplegar software de alta calidad con facilidad
Estos equipos necesitan métricas de productividad de desarrolladores para medir la productividad y los obstáculos de los equipos de ingeniería, y para rastrear si su trabajo realmente tiene impacto
Métricas de productividad de desarrolladores que usan estas empresas
- Facilidad de entrega (Amplitude, GoodRx, Intercom, Postman, Lattice)
- Velocidad de experimentación (Etsy)
- Estabilidad del servicio/aplicación (DoorDash)
- Métricas SPACE (Microsoft)
- Horas semanales de enfoque por ingeniero (Uber)
Se seleccionaron 4 grupos según el tamaño de la empresa
- Google: más de 100,000 empleados
- LinkedIn: más de 10,000
- Peloton: entre 1,000 y menos de 10,000
- Scale-ups (entre 100 y menos de 1,000 ingenieros): Notion, Postman, Intercom, Amplitude, GoodRx, Lattice

2. El enfoque de Google

Google suele mencionarse como una referencia en medición de productividad de desarrolladores, pero también se argumenta que imitar el nivel de inversión de Google es imposible para la mayoría de las empresas
El equipo de Developer Intelligence de Google es un área especializada que mide la productividad de los desarrolladores y proporciona insights a los líderes
Google cree que una sola métrica no puede capturar la productividad, y la observa a través de tres dimensiones: velocidad, facilidad y calidad
- Speed velocidad: ¿cuánto tiempo toma completar una revisión de código?
- Ease facilidad: ¿qué tan fácil o difícil es para un desarrollador avanzar por el proceso de revisión de código?
- Quality calidad: ¿qué tan buena es la retroalimentación recibida a través de la revisión de código?
Google calcula sus métricas mezclando mediciones cualitativas y cuantitativas

3. LinkedIn

LinkedIn opera de forma independiente dentro de Microsoft y emplea a más de 10,000 personas
LinkedIn cuenta con un equipo de Developer Insights que mide la productividad y satisfacción de los desarrolladores y transmite insights al resto de la organización
LinkedIn captura métricas usando encuestas trimestrales, un sistema de retroalimentación en tiempo real y métricas basadas en sistemas
- Encuestas trimestrales:
  - El equipo de Developer Insights evalúa la experiencia de los desarrolladores en distintas herramientas, procesos y actividades mediante encuestas trimestrales
  - La encuesta incluye unas 30 preguntas y los desarrolladores pueden responderla en unos 10 minutos
  - La encuesta se ofrece a través de una plataforma propietaria desarrollada y administrada por el equipo de Developer Insights, que permite una personalización y adaptación avanzadas de las preguntas basadas en datos recopilados por el sistema de retroalimentación en tiempo real y el sistema de métricas
- Sistema de retroalimentación en tiempo real:
  - Para recopilar retroalimentación entre encuestas trimestrales, LinkedIn desarrolló un sistema de retroalimentación en tiempo real que rastrea eventos y acciones que los desarrolladores realizan dentro de las herramientas de desarrollo y envía encuestas dirigidas según disparadores específicos
  - Este sistema usa un mecanismo inteligente de throttling para evitar que a los desarrolladores les lleguen demasiadas solicitudes de retroalimentación
- Métricas basadas en sistemas:
  - LinkedIn también usa datos del sistema para calcular métricas y así obtener mediciones de alta precisión sobre elementos como tiempo de build y frecuencia de despliegue
  - El equipo de Developer Insights mantiene un sistema global para recopilar y analizar estos datos, al que llaman Developer Insights Hub (o iHub)
  - Este sistema permite que todos los equipos de LinkedIn creen dashboards y métricas personalizadas según sus necesidades
LinkedIn considera tanto métricas cualitativas como cuantitativas
- Satisfacción neta de usuario del desarrollador (Developer Net User Satisfaction, NSAT): mide qué tan satisfechos están en general los desarrolladores con los sistemas de desarrollo de LinkedIn. Se mide trimestralmente
- Tiempo de build del desarrollador (Developer Build Time, P50 y P90): mide en segundos cuánto tarda un desarrollador esperando que un build termine localmente durante el desarrollo
- Tiempo de respuesta del revisor de código (Code Reviewer Response Time, P50 y P90): mide cuánto tarda un revisor de código en responder a cada actualización de revisión de código del autor, en horario laboral
- Velocidad de CI post-commit (Post-Commit CI Speed, P50 y P90): mide en minutos cuánto tarda cada commit en pasar por el pipeline de integración continua (CI)
- Determinismo de CI (CI Determinism): el concepto opuesto a la inestabilidad de pruebas. Significa la probabilidad de que el resultado de una suite de pruebas sea válido y no un error
- Tasa de éxito de despliegue (Deployment Success Rate): mide con qué frecuencia los despliegues a producción tienen éxito
- Medias winsorizadas (Winsorized Means): una forma de reconocer mejoras dentro de métricas con valores atípicos. Se calcula reemplazando los valores más altos y más bajos por números más cercanos al centro
- Índice de experiencia del desarrollador (The Developer Experience Index): una métrica especial que LinkedIn proporciona a sus equipos. Es una puntuación compuesta basada en varias métricas como las enumeradas anteriormente

4. Peloton

Peloton es una empresa grande con alrededor de 3,000 a 4,000 empleados, mucho más pequeña que LinkedIn
El enfoque de medición de Peloton comenzó obteniendo insights cualitativos a través de encuestas de experiencia de desarrolladores, y después las usó junto con métricas cuantitativas
Peloton mide la productividad enfocándose en cuatro áreas principales: participación, velocidad, calidad y estabilidad
- Participación (Engagement): puntaje de satisfacción de los desarrolladores
- Velocidad (Velocity): tiempo hasta el primer y décimo PR de todos los nuevos ingresos, lead time y frecuencia de despliegue
- Calidad (Quality): proporción de PR con menos de 250 líneas, cobertura de líneas y tasa de fallas por cambio
- Estabilidad (Stability): tiempo de recuperación del servicio
La encuesta de experiencia de desarrolladores, que mide gran parte de estas métricas, es liderada por el equipo de soporte técnico y experiencia de desarrolladores de Peloton, que forma parte de la organización de operaciones de producto
El equipo de soporte técnico y experiencia de desarrolladores también se encarga de analizar los resultados de la encuesta y compartirlos con los líderes de toda la organización

5. Scale-ups y empresas pequeñas

Varias scale-ups como Notion, Postman, Amplitude, GoodRx, Intercom y Lattice emplean entre 100 y 1,000 ingenieros
Estas empresas se enfocan en "métricas movibles (Moveable Metrics)"
- Las métricas movibles son aquellas que un equipo de productividad de desarrolladores puede "mover" al impactarlas positiva o negativamente con su trabajo. Son útiles para que el equipo de productividad de desarrolladores demuestre su impacto
Métricas comunes
- Facilidad de entrega (Ease of Delivery, moveable):
  - La mayoría de las empresas mide la facilidad de entrega, una escala cualitativa sobre qué tan fácil o difícil sienten los desarrolladores que es realizar su trabajo
  - Varios líderes de DevProd dicen que esta métrica es la 'estrella polar' de su trabajo, porque el objetivo del equipo es hacerles la vida más fácil a los desarrolladores
  - Esta métrica también es útil para mostrar impacto porque es bastante movible
  - Desde una perspectiva teórica, esta métrica también captura aspectos clave de la experiencia de desarrolladores, como la carga cognitiva y los ciclos de retroalimentación
- Participación (Engagement)
  - Se rastrea la participación, que mide qué tanto interés y estímulo sienten los desarrolladores respecto a su trabajo
  - Normalmente la participación se mide en encuestas de RR. HH., pero los equipos de DevProd también destacan su enfoque en participación por esta razón
  - La participación del desarrollador y la productividad están estrechamente relacionadas. Es decir, así como se dice que "un desarrollador feliz es un desarrollador productivo", la participación del desarrollador puede verse como un indicador de productividad
  - El verdadero beneficio de medir la participación es que puede equilibrar otras métricas que enfatizan la velocidad. Entregar software más rápido es bueno, pero no debe hacerse a costa de reducir la felicidad de los desarrolladores
- Pérdida de tiempo (Time Loss, moveable)
  - GoodRx y Postman ponen atención al promedio de pérdida de tiempo
  - Se mide como la proporción del tiempo de los desarrolladores que se pierde debido a obstáculos en el entorno de trabajo
  - Esta métrica es similar a la facilidad de entrega en el sentido de que proporciona una métrica movible que puede verse afectada directamente por el trabajo del equipo de desarrollo
  - Tiene la gran ventaja de que puede traducirse a costos, por lo que los líderes de negocio pueden entender fácilmente la pérdida de tiempo
  - Por ejemplo, si en una organización con un costo de personal de ingeniería de 10 millones de dólares una iniciativa reduce la pérdida de tiempo de 20% a 10%, eso se traduce en un ahorro de 1 millón de dólares
- Tasa de fallas por cambio (Change Failure Rate)
  - Esta es una de las cuatro métricas principales del programa de investigación DORA (DevOps Research and Assessment)
  - Es una métrica de alto nivel que rastrean varias empresas, incluidas Amplitude y Lattice
  - El equipo de DORA define la tasa de fallas por cambio de la siguiente manera:
  "el porcentaje de cambios liberados a producción o a los usuarios que provocan una degradación del servicio (por ejemplo, una interrupción o caída del servicio) y luego requieren corrección (por ejemplo, hotfix, rollback, corrección hacia adelante o parche)"

6. Hallazgos interesantes

Las métricas DORA y SPACE se usan de manera selectiva, y todas las empresas emplean tanto mediciones cualitativas como cuantitativas
- DORA: DevOps Research and Assessment
- SPACE: Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow
Hay un gran énfasis en el "tiempo de enfoque", y Stripe y Uber compartieron métricas concretas como "días con suficiente tiempo de enfoque" y "horas semanales de enfoque por ingeniero"
Métricas únicas
- Adoption Rate (DoorDash, GoodRx, Spotify)
- Design Docs Generated per Engineer (Uber)
- Experiment Velocity (Etsy)
- Developer CSAT/NSAT (Chime, LinkedIn)

7. Cómo elegir tus propias métricas

Es recomendable usar el framework Goals, Signals, Metrics (GSM) de Google para guiar la selección de métricas
Primero define el objetivo del problema que quieres resolver, luego encuentra las señales que indiquen que lograste ese objetivo, y después elige las métricas adecuadas
- Definir objetivos
  - Google: "Ayudamos a los desarrolladores a entregar excelentes productos de forma rápida y fácil."
  - Slack: "Proporcionamos un entorno de desarrollo fluido para cada ingeniero."
  - Stripe: "Hacemos que la ingeniería de software sea más fácil."
- Trabajar hacia atrás desde el objetivo para definir métricas de alto nivel
  - Qué tan fácil es para los desarrolladores entregar software (Ease): Ease of Delivery, Deployment Lead Time, Build Failure Rate
  - Qué tan rápido entregan software los desarrolladores (Speed): Perceived Delivery Speed, Perceived Productivity
  - La calidad del software entregado (Quality): Incident frequency, Perceived Software Quality
Si eres CTO, VPE o líder de ingeniería
- El mejor consejo es "replantear el problema (reframe the problem)"
- Elegir métricas de tres buckets
  - Impacto de negocio
    - ¿Por qué hay que construir esto ahora?
    - ¿De qué manera este proyecto genera ingresos o apoya los objetivos del negocio?
    - ¿Este proyecto va bien o está retrasado?
  - Desempeño del sistema
    - ¿Los sistemas de ingeniería son rápidos y estables?
    - ¿La infraestructura es segura y está bien mantenida?
    - ¿Los usuarios están satisfechos con los servicios que usan?
  - Eficiencia de ingeniería
Medir con una mezcla de métricas cualitativas y cuantitativas es algo común en todas las empresas
- Vale la pena inspirarse en las distintas mediciones que usa cada empresa
- Hay grandes diferencias en qué se mide con más énfasis según las prioridades y la cultura de ingeniería de cada empresa

1 comentarios

demorier 2024-01-24

Me interesaba desde el artículo anterior relacionado con McKinsey, y me gustó que estuviera resumido y sirviera como recordatorio.