Planeamiento y prioridad

Obtenga información sobre cómo identificar los objetivos de los esfuerzos de ingeniería de plataforma en función del modelo de funcionalidad de ingeniería de plataformas, recorrer escenarios comunes y buscar formas de medir el éxito. Mida el éxito alineando sus metas con los objetivos empresariales.

Identificación de objetivos y escenarios clave

Para empezar, primero evalúe dónde está su organización mediante el modelo de funcionalidades de ingeniería de plataformas. Use el modelo para trazar dónde se encuentra su organización en seis funcionalidades principales de ingeniería de plataforma: inversión, adopción, gobernanza, aprovisionamiento y administración, interfaces y medidas y comentarios. Todas las organizaciones están más avanzadas en algunas funcionalidades que en otras. Una vez que sepa dónde se encuentra su organización en la actualidad, puede elegir qué funcionalidades le gustaría crecer. Para más información, consulte Evaluación de las prácticas actuales y establecimiento de objetivos futuros.

Puede planear y actualizar continuamente los objetivos de ingeniería de plataforma a lo largo del tiempo. Tener claro lo que desea obtener al invertir en su trayectoria en la ingeniería de plataformas puede ser de gran ayuda para crear apoyo organizacional.

Como responsable de ingeniería de plataformas una vez dijo, "No hago algo para la ingeniería de plataformas hasta que tengo algo que ganar". – Peter, responsable de ingeniería de plataformas, empresa tecnológica multinacional

A medida que piense en sus objetivos, consíquelos a objetivos empresariales relacionados con el esfuerzo de ingeniería de plataforma, en lugar de los detalles de un equipo de desarrollo determinado. Entre los objetivos comunes comunes de ingeniería de plataformas de alto nivel se incluyen:

• Aumente la calidad de la aplicación y reduzca los errores y problemas durante la versión.
• Mejore la seguridad y reduzca el número de incidentes de seguridad, o detecte vulnerabilidades y exposiciones comunes (CVE), una vez en producción.
• Reduzca el riesgo a través de un mejor cumplimiento en áreas como licencias, accesibilidad, privacidad o regulación gubernamental.
• Acelere el tiempo para obtener valor comercial al reducir la complejidad, la sobrecarga y promover el uso compartido de código a través de prácticas inner source.
• Reduzca los costos de desarrollo o operaciones, minimice la duplicación y mejore la automatización.

Elegir su objetivo principal es fundamental, ya que su objetivo impulsa cómo enfoca su priorización.

Mejor aún, el acuerdo sobre los objetivos y los resultados clave (OKR) con su liderazgo y asociados internos ayuda a establecer objetivos medibles para la fase actual de sus inversiones. (Otros enfoques de planeación tienen conceptos similares si su organización usa otra cosa). Los mejores OKR son los que se pueden establecer en función de una medida concreta, ya que elimina la subjetividad.

Escenarios y trabajos que se van a realizar

Después de identificar sus objetivos, elija los escenarios clave para desarrollar su trabajo pendiente y hoja de ruta. Por ejemplo, consulte los siguientes escenarios y los trabajos asociados que se van a realizar.

Escenario: Inicio de la creación de una nueva aplicación

• Descripción y aplicación de procedimientos recomendados y directivas de la organización
• Creación de un repositorio
• Herramientas de aprovisionamiento
• Aprovisionamiento de una infraestructura común
• Concesión de acceso a los miembros del equipo
• Establecer canalizaciones de CI/CD
• Aprovisionamiento de la infraestructura de desarrollo
• Implementación inicial para probar "tuberías"

Escenario: Agregar o quitar un nuevo miembro a un equipo existente

• Actualización del acceso a herramientas y servicios
• Configuración de una máquina para desarrolladores
• Formar al miembro del equipo en las aplicaciones
• Cree un entorno de espacio aislado para aplicaciones
• Primero, cree y revise la solicitud de incorporación de cambios.

Escenario: Adición o actualización de la infraestructura para la aplicación existente

• Descripción de los procedimientos recomendados de la organización, las opciones disponibles
• Actualizar o agregar infraestructura como artefactos de código
• Crear entorno de sandbox de aplicaciones
• Comprobación de actualizaciones
• Implementación de cambios en otros entornos

Escenario: Agregar o actualizar herramienta para el equipo existente

• Descripción de los procedimientos recomendados de la organización, las opciones disponibles
• Solicitar el uso de una nueva herramienta
• Actualizar el acceso de los miembros del equipo a las herramientas
• (Si procede) Integración de la herramienta en clientes o canalizaciones de CI/CD

Escenario: Búsqueda o reutilización de la API, el SDK o el servicio existentes

• Detección de API, SDK o servicios disponibles
• Evaluar si satisface las necesidades
• Póngase en contacto con el equipo propietario si tiene alguna pregunta.
• Adoptar para la aplicación

Escenario: Respuesta a un incidente de operaciones

• Notificación de un problema
• Evaluar si el código de la aplicación o la infraestructura están relacionados (o ambos)
• Creación de un entorno de espacio aislado que refleje prod (si es diferente)
• Realizar cambios, probar y liberar fuera de banda

Escenario: Corrección rápida del incidente de seguridad

• Notificación de un problema
• Evaluar la amplitud de los problemas (qué sistemas)
• Comprender si los clientes se ven afectados directamente
• Creación de un entorno de espacio aislado que refleje prod (si es diferente)
• Realizar cambios, testear y lanzamiento fuera de banda
• Comunicarse con cualquier persona afectada

Escenario: Desuso de la herramienta

• Descripción del uso de herramientas
• Notificar a los usuarios la desaprobación
• (Opcional) Coordinar la migración de usuarios a una nueva herramienta

Escenario: Lanzamiento del nuevo modelo de aplicación de arquitectura

• Arquitectura propuesta piloto
• Ajustar en función de los resultados piloto
• Actualizar la documentación de las mejores prácticas
• Crear plantillas, actualizar automatización, políticas y gobernanza

Auditar el cumplimiento de aplicaciones (RGPD, accesibilidad, estándares de infraestructura)

• Descripción de las reglas de cumplimiento actuales
• Comprobación de que la aplicación cumple las reglas
• Establecer fecha límite para correcciones de desviaciones
• Realizar cambios, probar, liberar

Muchos escenarios se aplican a más de un rol. Piense en las métricas para medir la mejora.

Desde problemas a conceptos

A continuación, comprenda los problemas más importantes a los que se enfrentan los desarrolladores y otros roles con los escenarios y los trabajos que identificó. Puede ser tentador empezar a investigar nuevos productos para llenar las brechas percibidas, pero si estos productos no resuelven un punto de dolor importante, es poco probable que se adopten o aprecian.

Hay varios enfoques que pueden ayudarle a realizar este tipo de investigación, como el marco de progresión de hipótesis. Incluso si no usa un proceso formalizado como el marco de progresión de hipótesis, debe entrevistar a los desarrolladores sobre un trabajo que se va a realizar para definir el ámbito de la discusión y, a continuación, identificar sus mayores problemas en la realización de su trabajo. Una vez que tenga un buen sentido de lo que son estos problemas, continúe con los planes para resolverlos. Esto ayuda a garantizar que cree características que los desarrolladores quieran usar.

Para poder repetir rápidamente este proceso, identifique a alguien que pueda representar la voz del cliente directamente en el equipo interno de la plataforma para desarrolladores. Normalmente, este rol se denomina administrador de productos (incluso si tienen un puesto de trabajo diferente) y a medida que crece su conocimiento, pueden predecir con precisión los resultados para las decisiones más pequeñas y determinar cuándo necesita realizar más entrevistas. Esto mantiene su agilidad al mismo tiempo que garantiza que se centra en ofrecer valor a los clientes internos.

Justificar las inversiones iniciales

Una vez que tenga un conjunto de problemas y conceptos validados, está en una buena posición para decidir dónde invertir. Sin embargo, considere la inversión inicial y el mantenimiento a largo plazo necesarios al evaluar soluciones. La solución de menor esfuerzo que puede resolver el problema tiende a ser la adecuada para empezar, pero a menudo es el trabajo de mantenimiento que, en última instancia, decide si la inversión es correcta.

Dicho de otra manera, no cree soluciones que se enfoquen en las fases posteriores de tu recorrido, a menos que realmente lo necesite.

Después de identificar la plataforma viable mínima (TVP) (como un producto mínimo viable para su plataforma), pilótelo con un conjunto de equipos de desarrollo dispuestos a proporcionar comentarios. Si la solución piloto resuelve los problemas a los que se enfrentan estos equipos, no debe tener problemas para encontrar a alguien interesado en participar.

Debe capturar algunas métricas clave a medida que piloto una nueva funcionalidad o cambios para poder medir si el concepto se realizó correctamente antes de implementarlo.

Medir el éxito y demostrar el valor

Medir el éxito es una parte importante de una mentalidad de producto. Incluso pequeños éxitos con inversiones modestas pueden sentar el fundamento sobre el cual construir inversiones más grandes.

Por ejemplo, puede ser difícil asegurar la financiación o el consenso para los esfuerzos de cumplimiento normativo porque se pueden percibir como un impuesto operativo por los equipos de desarrollo que ofrecen valor empresarial. Una mentalidad de producto puede cambiar esa percepción. Con una mentalidad de producto, está intentando asegurarse de que los clientes de su plataforma de desarrollador interna estén satisfechos y que se cumplan los objetivos empresariales de las partes interesadas. Las métricas le colocan en una posición para usar hechos para demostrar que proporciona valor empresarial. Establecer OKRs puede ayudar, especialmente si tiene métricas que puede usar para ayudar a eliminar el sesgo subjetivo. Aunque no estés midiendo nada aplicable hoy, puedes establecer un OKR de aprendizaje para establecer una línea base que luego refinarás después de que se conozca esta línea de base.

A continuación se muestran ejemplos de métricas conocidas que puede medir para determinar si los equipos con los que trabaja obtienen valor de lo que está creando. Céntrate en aquellos que te ayudan a medir si tú y los clientes de tu equipo de desarrollo están logrando sus objetivos. Por ejemplo, lo siguiente es un conjunto de métricas que le ayudan a evaluar si la plataforma contribuye a una organización de ingeniería eficaz:

• Velocidad y tiempo para el valor empresarial: mediana de días para completar la primera solicitud de incorporación de cambios (incorporación), mediana de minutos para los procesos de compilación y prueba (por ejemplo: CI), mediana de tiempo para combinar la solicitud de incorporación de cambios.
• Calidad del software: incidentes (problemas) creados por mes por desarrollo (recuento normalizado a número de desarrolladores), tiempo medio de recuperación (MTTR), tiempo medio para investigar y corregir el problema de seguridad.
• Facilidad de uso de la plataforma: satisfacción del usuario neto (NSAT)
• Ecosistema pujante: puntuación media para cada una de las siguientes preguntas encuestadas: "Estoy capacitado para hacer mi mejor trabajo", "la mayoría de los días que estoy energizado por el trabajo que hago", "el trabajo que hago es significativo para mí".

A continuación, puede desglosar estas métricas por organización, equipo o proyecto. Debe medir algunas líneas base para empezar, pero puede observar que estas métricas cambian a medida que mejora la plataforma.

Otras métricas que usted o sus patrocinadores podrían estar interesados en medir incluyen:

La recopilación de métricas requiere tiempo y esfuerzo, por lo que es importante centrarse en las métricas críticas para los objetivos principales identificados, especialmente en aquellos que impulsan los OKR. Los productos basados en OpenTelemetry, como Application Insights, pueden ayudar.

Asegúrese de medir la facilidad de uso de la plataforma y de realizar encuestas regularmente para asegurar que tiene un ecosistema próspero. Estas métricas a menudo se pierden en los sistemas internos y son un indicador inicial sobre si cumple sus objetivos empresariales más amplios, ya que la participación comprometida es fundamental para el éxito. También le ayuda a saber si es el momento de realizar más desarrollo de clientes para comprender dónde ir a continuación.

Otras sugerencias

Independientemente de cómo empiece, tenga en cuenta que debe planear el cambio, empezar con nuevas aplicaciones para pilotos, centrarse en mejorar las experiencias de usuario existentes, adoptar el principio de privilegios mínimos, planear la experimentación controlada y minimizar la personalización.

Plan de cambio

La plataforma de aplicación de destino evolucionará con el tiempo y es posible que no pueda migrar todas las inversiones existentes a la vez. Piense en cómo puede admitir más de una variación a lo largo del tiempo y planear el cambio.

Validación de ideas con aplicaciones más recientes

Comience con nuevas aplicaciones de un tamaño razonable al probar las nuevas capacidades de la plataforma. Esto también le ofrece experiencia en la administración de la plataforma como producto. Evite iniciar proyectos de replatforming ya que aprenderá sobre la marcha, y las aplicaciones existentes de gran tamaño suelen tener necesidades únicas que solo se descubren durante el esfuerzo de replataformación. Debido a eso, vincular su éxito a este tipo de esfuerzos puede dar lugar a desajustes de expectativas o a problemas que surgen tardíamente. Comenzar con algo más nuevo puede darle confianza en su orientación y en el valor que aporta. Esto reduce el riesgo de abordar estos esfuerzos más grandes. Dicho de otra manera, si estás seguro/a de que las personas pueden empezar bien y mantenerse así, entonces resulta más fácil impulsar una campaña adecuada basándote en lo que aprendes de la experiencia. Si este enfoque no es posible, se debe realizar análisis cuidadosos, establecer expectativas y dar pasos incrementales en lugar de intentar cambiar todo de una vez.

Céntrese en los centros de gravedad existentes para las experiencias del usuario antes de crear otros nuevos.

Es más probable que los desarrolladores adopten y se adhieren a nuevas funcionalidades cuando se muestran en algo que ya les gusta y usan. A medida que se evalúan los conceptos para ofrecer nuevas funcionalidades, asegúrese de investigar las opciones que amplían los centros de gravedad existentes. Por ejemplo, editores o IDE (Visual Studio, VS Code), conjuntos de DevOps (GitHub, Azure DevOps), CLIs existentes o un portal interno existente pueden ser más eficaces que un portal completamente nuevo u otra experiencia de usuario. Para más información, consulte Experiencias del usuario.

Asumir el principio de privilegios mínimos

Supongamos que los desarrolladores tienen acceso limitado a los sistemas de bajada para cosas como la infraestructura de aprovisionamiento. Necesitará una manera controlada de habilitar este acceso para experiencias de autoservicio.

Planear la experimentación controlada

Experimente antes de implementar cambios importantes o peligrosos. No todo tiene que estar totalmente automatizado para empezar. Un flujo de trabajo manual desencadenado automáticamente puede ser una excelente manera de probar ideas.

Minimizar la personalización de la plataforma de aplicaciones

Evite desarrollar capacidades personalizadas de la plataforma de aplicaciones que podrían ser eclipsadas por las capacidades que los proveedores de software liberan a lo largo del tiempo. Por ejemplo, el hospedaje en tiempo de ejecución, las mallas de servicio, los sistemas de identidad, etc. Si encuentra una necesidad urgente en un área que sospecha que podría ser similar a esta, planee varias opciones de implementación, dado que el mantenimiento a largo plazo probablemente le hará cambiar con el tiempo.

Contenido relacionado

• Aplicación de sistemas de ingeniería de software