Planear y priorizar
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 mediante el ámbito de los objetivos empresariales.
Identificación de objetivos y escenarios clave
Para empezar, primero evalúe dónde está su organización con 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 mediciones 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 cómo usar el modelo.
Puede planear y actualizar continuamente los objetivos de ingeniería de plataforma a lo largo del tiempo. Estar claro sobre lo que desea obtener al invertir en su recorrido de ingeniería de plataforma puede seguir un largo camino para ayudar a crear soporte técnico de la organización.
Como responsable de ingeniería de plataformas una vez lo puso, "No hago algo para la ingeniería de plataformas hasta que tengo algo que puedo obtener de él". – Peter, responsable de ingeniería de plataformas, Multinacional Tech Company
A medida que esté pensando en sus objetivos, consíquelos a los 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, reduzca los errores y los problemas durante la versión.
- Mejore la seguridad, reduzca el número de incidentes de seguridad o detecte vulnerabilidades comunes y exposiciones (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 valor de tiempo a negocio al reducir la complejidad, la sobrecarga y promover el uso compartido de código a través de prácticas internas de origen .
- Reduzca los costos de desarrollo o operaciones, minimice la duplicación y mejore la automatización.
Elegir el objetivo superior es fundamental, ya que su objetivo impulsa cómo piensa en su priorización.
Mejor aún, aceptar objetivos y resultados clave (OKR) con su liderazgo y asociados internos conduce 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 sacar el trabajo pendiente y la hoja de ruta. Por ejemplo, consulte estos 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 nuevo repositorio
- Herramientas de aprovisionamiento
- Aprovisionamiento de una infraestructura común
- Concesión de acceso a los miembros del equipo
- Establecimiento de canalizaciones de CI/CD
- Aprovisionamiento de la infraestructura de desarrollo
- Implementación inicial para probar "canalizaciones"
Escenario: Agregar o quitar un nuevo miembro a un equipo existente
- Actualización del acceso a herramientas, servicios
- Configuración de la máquina para desarrolladores
- Aumentar el miembro del equipo en las aplicaciones
- Creación de un entorno de espacio aislado de aplicaciones
- Creación y revisión de la primera 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
- Creación de un entorno de espacio aislado de aplicaciones
- Comprobar 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
- Solicitud de uso de la 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 disponibles, SDK, servicios
- Evaluar si satisface las necesidades
- Conexión con el equipo propietario para cualquier pregunta
- Adopción de 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, probar y liberar fuera de banda
- Comunicarse con cualquier persona afectada
Escenario: Desuso de la herramienta
- Descripción del uso de herramientas
- Notificar a los usuarios el desuso
- (Opcional) Coordinación de 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
- Documentación sobre los procedimientos recomendados de actualización
- Creación de plantillas, automatización de actualizaciones, directivas, 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, busque comprender 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. Uno es 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. Este rol se suele denominar 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 de 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.
Hacer el caso de 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.
Ponga otra manera, no cree soluciones que tengan como destino las fases posteriores del recorrido, a menos que realmente necesite.
Una vez que haya identificado su plataforma viable más delgada (TVP) (un MVP para su plataforma), lo pilote con un conjunto de equipos de desarrollo que están 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 que tiene es una parte importante de una mentalidad de producto. Incluso pequeños éxitos con inversiones modestas pueden sentar el fundamento de las inversiones más grandes para construir.
Por ejemplo, puede ser difícil asegurar la financiación o la compra para los esfuerzos de cumplimiento porque se pueden percibir como un impuesto operativo a 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 okR puede ayudar, especialmente si tiene métricas que puede usar para ayudar a eliminar el sesgo subjetiva. Incluso si no mide nada aplicable hoy, puede establecer un OKR de aprendizaje para establecer una línea base que luego refinará 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. Cero en aquellos que le ayudan a medir si usted y sus clientes del 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: media de días para completar la primera solicitud de incorporación de cambios (incorporación), minutos medio para procesos de compilación y prueba (por ejemplo: CI), tiempo medio para combinar la solicitud de incorporación de cambios.
- Calidad del software: incidentes (problemas) creados al mes por dev(count normalizado a número de desarrolladores), tiempo medio para corregir (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. Para empezar, debe medir algunas líneas de base, 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:
| Área | Métricas de ejemplo |
|---|---|
| Rendimiento de entrega de software | DevOps Research and Assessment (DORA): cambio de tiempo de ejecución, frecuencia de implementación, tasa de error de cambio, tiempo para restaurar el servicio (MTTR) |
| Operations | DORA (MTTR), tiempo medio entre errores (MTBF), tiempo medio para confirmar, disponibilidad del cliente final, latencia, métricas de rendimiento, costo por equipo, costo por implementación |
| Métricas de adopción de la funcionalidad de la plataforma | Número de equipos o desarrolladores que usan una herramienta o característica a lo largo del tiempo, porcentaje de repositorios que usan la plataforma, plantillas más populares, canalizaciones, etc. |
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 que identificó, especialmente aquellos que potencian los OKR. Los productos basados en OpenTelemetry , como Application Insights , pueden ayudar. Independientemente, asegúrese de medir la facilidad de uso de la plataforma y la encuesta que tiene un ecosistema exitoso con regularidad. 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 aplicaciones 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 funcionalidades de plataforma o plataforma. Esto también le proporcionará experiencia en la administración de su plataforma como producto. Tímida de replatar proyectos para comenzar desde que aprende a medida que avanza, y las aplicaciones existentes de gran tamaño suelen tener necesidades únicas que solo se descubren durante el esfuerzo de re-plataforma. Debido a eso, acoplar el éxito a estos tipos de esfuerzos puede dar lugar a errores de coincidencia de expectativas o problemas de interrupción tardía. A partir de algo más reciente puede darle confianza en la dirección que proporciona el valor que proporciona. Esto reduce el riesgo de abordar estos esfuerzos más grandes. Ponga otra manera, si estás seguro de que las personas pueden empezar bien y permanecer bien, entonces resulta más fácil impulsar una campaña correcta con lo que aprendes de la experiencia. Si este enfoque no es posible, querrá realizar análisis cuidadosos, establecer expectativas e iniciar paso a paso incrementalmente en lugar de intentar cambiar todo a la 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 está evaluando los conceptos para ofrecer nuevas funcionalidades, asegúrese de investigar las opciones que toman extensión de 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. Consulte experiencias de usuario para obtener más información.
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 las funcionalidades personalizadas de la plataforma de aplicaciones de compilación que los proveedores de software de funcionalidades podrían eclipser con el 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.