Modelo de Madurez de Ingeniería de Plataforma

¿Por qué y cómo los usuarios descubren y utilizan las plataformas internas y sus capacidades?

La adopción describe no solo cómo y cuánto una organización utiliza las capacidades de una plataforma sino también qué los motiva a hacerlo. En las primeras etapas, muchos usuarios pueden no notar en lo más mínimo que están usando una plataforma, en su lugar, ven sus herramientas como un conjunto de capacidades ad hoc de varias fuentes internas. Esto puede madurar en un grupo de capacidades que se gestionan y presentan de manera consistente a los usuarios; ya sea una o más plataformas. A medida de las capacidades se vuelven más refinadas y descubribles, es común que el motivador para el uso de plataformas se aleje de motivaciones externas como mandatos o incentivos. Esto lleva a que los usuarios elijan por sí mismos usar capacidades de la plataforma y aún en casos ideales, inviertan sus propios esfuerzos en el más amplio ecosistema de la plataforma.

Nivel 1, Provisional — Errática

La adopción de plataformas y capacidades compartidas es esporádica e inconsistente. No existe una estrategia organizacional ni guías para elegir e integrar servicios y tecnologías de apoyo. Los equipos individuales pueden apoyarse en prácticas de plataforma para mejorar sus propios procesos, pero no hay un esfuerzo coordinado o estandarización en la organización. Este nivel de adopción se caracteriza por la ausencia de un enfoque coherente y la idea de que las herramientas externas son más efectivas que aquellas provistas internamente.

Características:

• Herramientas, servicios y capacidades se gestionan y consumen de forma aislada por diversos equipos y departamentos de la organización.
• Se adoptan servicios gestionados por un proveedor (“cloud”) y se utilizan con inconsistencia y sin prácticas ni políticas estándar, dado que es dificil encontrar y usar configuraciones internas.
• Los equipos de aplicaciones y servicios descubren herramientas y capacidades de forma anárquica, mediante rumores o conversaciones casuales, en lugar de contar con un proceso más centralizado.
• La coordinación y reutilización de componentes y capacidades sólo ocurre por los usuarios finales (equipos de aplicaciones), si es que ocurren.
• Los equipos de producto mantienen cada cual sus propios conjuntos de scripts o herramientas para desplegar sus aplicaciones.

Escenarios de ejemplo:

• Un servicio de banca requiere una base de datos. Un desarrollador se entera por un amigo u otro equipo que puede solicitar una cuenta en AWS y configurar allí una base de datos RDS. De parte de otro equipo, consigue un script de Terraform para aprovisionar esa base de datos. Para monitoreo, ellos utilizan CloudWatch según les parece: copian secretos manualmente desde la consola de AWS a una instancia de Hashicorp Vault antes de ejecutar el script de Terraform.

Nivel 2, Operativo — Empuje extrínseco

La organización reconoce el valor de las plataformas compartidas y sus capacidades y procura y alienta su sustento. Directivas internas incentivan o incluso requieren el uso de servicios compartidos de plataformas para algunos casos de uso. Algunos equipos de producto usan las capacidades de plataforma más que otros; las capacidades cubren casos de uso típicos en la organización pero no casos inusuales; y resulta dificil agregar estos casos inusuales a la plataforma común.

El descubrimiento de los usuarios sobre las capacidades y cómo utilizarlas es inconsistente; puede ocurrir que un usuario de un equipo de producto no descubra una capacidad soportada a menos que un equipo de la plataforma se la indique.

Características:

• Algún grado de ímpetu externo lleva a utilizar las capacidades de plataforma, por ejemplo:
  • Incentivos, como revisiones personales
  • Órdenes, como requerir su uso para los releases en producción o recibir financiación
• La utilización de las capacidades de plataforma es fragmentada: los usuarios pueden aprovechar las ventajas de una capacidad, pero podrían no tener conocimiento o interés para adoptar otras capacidades disponibles.
• Los usuarios tienen poca motivación para aprender cómo usar las capacidades de la plataforma y dependen mucho de la colaboración de los proveedores por medio de foros de colaboración o mesa de ayuda.
• Se alienta a los usuarios de plataforma a que se unan a comunidades informales de práctica para compartir problemas y soluciones, pero la asistencia es limitada.

Escenarios de ejemplo:

• Una organización de ingeniería elige una herramienta estándar de despliegue e instruye a todos los equipos a usarla. Se construyen nuevos procesos (comunicación de notas de release, etc) sobre ese estándar. Los equipos son instruidos para dejar de utilizar otros tipos de scripts de despliegue y usar en su lugar la herramienta común. Esto resulta difícil para algunos equipos cuyas necesidades no quedan cubiertas por el nuevo proceso pero no saben cómo o no tienen permitido extenderlo.

Nivel 3, Escalable — Tracción intrínseca

Los usuarios de equipos de producto y servicios elijen usar plataformas y sus capacidades por el claro valor que proveen en la reducción de carga cognitiva sobre los equipos de producto a la vez que proveen servicios de soporte de mayor calidad. La documentación e interfaces ergonómicas permiten a los usuarios del equipo rapidez en el aprovisionamiento y uso de las capacidades de la plataforma. Los usuarios eligen implementaciones internas de plataformas ante otras alternativas como desarrollar por ellos mismos las capacidades o contratar un proveedor.

Características:

• La adopción de plataforma es autosuficiente: el primer motivador para la adopción no es un factor externo o iniciativa que ordene a los usuarios a usar las capacidades ofrecidas por la plataforma, sino el propio valor que éstas ofrecen.
• Luego de usar y apreciar una o varias de las capacidades de la plataforma, los usuarios buscan otras y encuentran que la experiencia es similar entre todas las capacidades. Existe una expectativa de que una capacidad individual no sea algo aislado sino una funcionalidad entre un amplio conjunto de funcionalidades.
• Los equipos de plataforma alientan la adopción natural de las mismas obteniendo retroalimentación de los usuarios, compartiendo roadmaps y manteniendo foros abiertos para conversar con los usuarios.
• Los equipos de aplicación y producto valoran las capacidades de la plataforma lo suficiente como para pagar por ellas, por ej. mediante un sistema de reembolso.
• Los usuarios pueden compartir opiniones y aprender sobre próximas funcionalidades mediante foros abiertos y roadmaps compartidos.
• Portales de autoservicio, plantillas con “golden-path” y otros documentos habilitan su rápido uso.

Escenarios de ejemplo:

• Un equipo de aplicaciones tuvo éxito en el pasado solicitando una nueva base de datos. El proceso fue sencillo de entender y casi no tuvo tiempo de espera. Además, se incluían capacidades clave como respaldos y monitoreo, que permitieron al equipo progresar en su uso durante todo el camino hacia producción sin problemas. Esta experiencia implicó que posteriormente, cuado el equipo necesitó una cola, su primer instinto fue chequear si había una opción disponible en la plataforma interna. Si bien la intención original era usar una tecnología específica de cola, al final elijieron utilizar la que se ofrecía internamente dado que conocían lo bien integrada que estaría la solución para su organización.

Nivel 4, Optimizable — Participativa

Los usuarios de equipos de producto promueven la inversión en capacidades de plataforma uniéndose al ecosistema y contribuyendo con él. Algunas contribuciones mejoran y reparan capacidades existentes; otras introducen nuevas capacidades y funcionalidades para atender nuevos casos de uso. Se definen procesos y servicios que habilitan a los usuarios a identificar requerimientos y coordinar contribuciones entre varios equipos de producto y plataforma. Se publican nuevas capacidades por medio de interfaces y portales consistentes, con documentación completa y versionado estándar.

Características:

• Los usuarios de equipos de app/servicios son empoderados para contribuir con soluciones, funcionalidades y retroalimentación para las capacidades de plataforma.
• Los proyectos externos y estándar son apalancados estratégicamente para reducir los costos de mantenimiento, acelerar la entrega de nuevas funcionalidades y aprovechar los empleados de la organización con mayor efectividad.
• Se coordinan asincrónicamente nuevas capacidades y mejoras mediante tableros de temas y tracción de requerimientos. Los documentos y listas de chequeo habilitan el desarrollo auto motivado de contribuidores.
• Desarrolladores promotores y embajadores internos construyen y soportan una comunidad de usuarios interna que extiende la participación también a equipos de aplicaciones y servicios.
• El uso de capacidades de la platforma es visto como la mejor forma de trabajar en la organización, tanto por el liderazgo como por los contribuidores individuales.
• Los ingenieros de plataforma participan en la planificación de los equipos de producto para aprender sobre los requerimientos y sugerir capacidades existentes en la plataforma.

Escenarios de ejemplo:

• Un equipo quiere un plan de backup alternativo. Luego de proponer esto como una oferta general, se declara de baja prioridad debido a su mínima reutilización. El equipo que hizo la propuesta elige integrar su solución en el marco de la plataforma y hacerlo disponible para la organización. Originalmente es una oferta alfa pero una vez que cumpla con todos los requisitos operativos puede promoverse como capacidad central de la plataforma.

¿Cómo interactúan y consumen los usuarios las capacidades de la plataforma?

Las interfaces provistas por plataformas afectan a cómo los usuarios interactúan con las ofertas de capacidades que ofrece para aprovisionar, gestionar y observar. Las interfaces pueden incluir sistemas de tickets, plantillas de proyecto y portales gráficos así como APIs automatizables y herramientas de línea de comandos(CLI).

Las características principales de una interfaz incluyen qué tan descubribles y amigables resultan ser para el usuario durante sus tareas clave, como requisito inicial, mantenimiento o triaje de incidentes. Aquí los niveles de madurez más elevados reflejan interfaces más integradas, consistentes, automatizadas y soportadas.

Nivel 1, Provisional — Procesos personalizados

Existe un conjunto variado de procesos para aprovisionar diferentes capacidades y servicios, pero no se considera la consistencia de la interfaz. Procesos personalizados a medida atienden las necesidades inmediatas de individuos o equipos que dependen de intervención manual aun si el proveedor usa algunos scripts de implementación automatizada.

El conocimiento de cómo solicitar estas soluciones se comparte de persona en persona. El proceso de requerir un servicio no está estandarizado ni es consistente. El aprovisionamiento y uso de un servicio de plataforma suele requerir bastante soporte del proveedor de la capacidad.

La falta de requerimientos centrales y estándares hace de este nivel el apropiado cuando una compañía aún no ha identificado y documentado expectativas. Puede ser particularmente efectivo para equipos de compañías o esfuerzos de plataforma en etapa temprana. En estos entornos los equipos tienen la libertad de evolucionar procesos y capacidades para sus necesidades, lo que les permite entregar con mayor rapidez y pagar el precio de estandarizar a posteriori, solo cuando sea necesario.

Características:

• La interacción de usuarios no es un tema clave de discusión y las interacciones rara vez (o ninguna) son probadas durante el diseño y entrega de nuevas capacidades.
• Las capacidades son provistas principalmente mediante solicitudes manuales, si bien los proveedores pueden elegir automatizar algunas o todas las actividades necesarias para aprovisionar una solicitud de usuario.
• Las solicitudes que se encuentran en fase “simple” se vuelven complejas debido la dificultad para encontrar el proceso adecuado a seguir.
• En ocasiones un proceso se muestra como autorizado, pero los usuarios tienen problemas cuando un departamento o equipo diferente se involucra.

Escenarios de ejemplo:

• Un equipo de plataforma quiere realizar una prueba de rendimiento de su nuevo cambio. Para esto, quieren un entorno aislado que contenga suficientes datos de prueba que permita obtener una lectura precisa del rendimiento. La última vez que realizaron esta solicitud, un antiguo compañero de equipo logró acceder a un entorno, pero ya no está en el equipo y nadie sabe cómo recrearlo. Al final, contactan con un ingeniero del equipo de infraestructura quien puede aprovisionarles un entorno en unos pocos días.
• Un equipo en la fase exploratoria de un desarrollo de producto usa un proceso a medida para aprovisionar un nuevo servicio de nube sin tener que validar que su solución merezca mayor inversión.

Nivel 2, Operativo — Herramientas estándar

Existen interfaces consistentes y estandarizadas para el aprovisionamiento u observabilidad de las plataformas y capacidades y cubren amplias necesidades. Los usuarios pueden identificar qué capacidades están disponibles y tienen la posibilidad de solicitar otras capacidades que pudieran requerir.

Se proveen “rutas pavimentadas” (“paved roads”) o “rutas doradas” (“golden paths”), en forma de documentación y plantillas. Estos recursos definen cómo aprovisionar y gestionar las capacidades típicas utilizando patrones probados y conformes con las definiciones de la organización. Si bien algunos usuarios pueden usar estas soluciones por sí mismos, las soluciones aún suelen requerir un alto grado de especialidad y por lo tanto el soporte de quienes las mantienen sigue siendo vital.

Características:

• Las soluciones técnicas son herramientas integradas, específicas para su área de dominio, no siempre son herramientas familiares para los usuarios.
• Existe inversión en un trayecto común; sin embargo, la desviación de ese trayecto descubre con rapidez las pocas opciones de personalización debido a que el foco estuvo en construir una única opción.
• Gracias a la estandarización, grupos informales internos pueden crear y compartir buenas prácticas y superar problemas compartidos.
• Puede haber desviación en la implementación de capacidades debido a que los equipos toman las plantillas, las personalizan, pero luego no pueden fusionar los cambios con el equipo central.

Escenarios de ejemplo:

• Un equipo central adecúa una librería de módulos de Terraform, controladores de Kubernetes y CRDs para aprovisionar diferentes tipos de infraestructura.
• Una ubicación compartida contiene documentos extensos sobre las soluciones en la organización.

Nivel 3, Escalable — Soluciones de autoservicio

Las soluciones se ofrecen de tal forma que proveen autonomía a los uusarios y requieren poco soporte de quienes las mantienen. La organización alienta y dispone soluciones con interfaces consistentes que permiten el descubrimiento y portabilidad de la experiencia del usuario de una capacidad a otra. Si bien ofrecen autoservicio, las soluciones requieren información de equipo e implementación. Para mejorar esta experiencia puede haber un lenguaje interno guiado y simplificado que permita a los usuarios adoptar e integrar capacidades de plataforma con mayor rapidez. Esto genera un conjunto de capacidades focalizadas en el usuario, de autoservicios y consistentes.

Características:

• Las soluciones se ofrecen como implementaciones de “un-click”, permitiendo que los equipos se beneficien de una capacidad sin necesidad de comprender cómo se aprovisiona.
• Si bien las soluciones son fáciles de crear, puede que no haya mucha facilidad de uso construida para la gestión de la solución en el día 2 y más allá.
• Sigue existiendo un trayecto acotado de soluciones disponibles, dejando a los usuarios con requerimientos únicos para los que no se sabe bien cómo proceder.

Escenarios de ejemplo:

• Se provee una API que abstrae la creación y mantenimiento de bases de datos y provee a los usuarios la información requerida para aprovechar esa capacidad de la plataforma, como ser cadena de conexión, ubicación de datos secretos y tablero con datos de observabilidad.

Nivel 4, Optimizable — Servicios integrados

Las capacidades de plataforma están integradas con transparencia en las herramientas y procesos que los equipos utilizan para hacer su trabajo. Algunas capacidades se aprovisionan automáticamente, como observabilidad o gestión de identidades para un servicio desplegado. Cuando los usuarios llegan al límite de los servicios provistos, tienen la oportunidad de hacer a un lado las soluciones automatizadas y personalizarlas para sus necesidades, sin abandonar las ofertas internas porque las capacidades de plataforma están consideradas como bloques para armar. Estos bloques para armar se usan para construir composiciones transparentes y automáticas para cubrir los casos de uso de alto nivel a la vez que habilitan una personalización más profunda donde sea necesaria.

Características:

• Está claro qué capacidades son diferenciadoras para la organización y cuales no, permitiendo que los equipos internos inviertan en soluciones personalizadas solo cuando no puedan aprovechar los estándares de la industria.
• Si bien las capacidades presentan una navegación consistente, no hay una única forma de usar una capacidad. Algunas son más adecuadas como herramientas de línea de comandos para usar en scripts, mientras que otras se benefician de la integración con lo que el usuario utilice para escribir código en sus editores e IDEs.
• El valor de las capacidades individuales se extiende con foco en el flujo tanto del desarrollo como de liberación del software, lo que lleva a focalizar en cómo combinar capacidades en ofertas de mayor nivel.
• Si bien las capacidades usualmente se proveen en paquetes, los superusuarios pueden descomponer estas ofertas de alto nivel para optimizar cuándo y dónde se necesite.

Escenarios de ejemplo:

• Se inyectan agentes de observabilidad en toda carga de trabajo y se ubica un proxy OIDC frente a todas las aplicaciones.
• Por defecto, cada nuevo proyecto recibe un espacio en un ejecutor de tareas (pipelines) y un entorno de ejecución (namespace de K8s), sin embargo un proyecto puede optar por otras opciones, como la ejecución en entorno serverless.
• Desde un catálogo en un portal de Service Now un usuario selecciona “Aprovisionar una Base de Datos.” Un proceso automatizado aprovisiona una base de datos RDS y envía una URL y ubicación para obtener credenciales para el usuario.

¿Cómo se planifican, priorizan, desarrollan y mantienen las plataformas y sus capacidades?

La operación de plataformas implica ejecutar y soportar sus capacidades y funcionalidades en todo su ciclo de vida, incluyendo la aceptación de nuevos requerimientos, releases iniciales, actualizaciones y extensiones, mantenimiento y operación permanente, soporte a usuarios e incluso retirada y supresión. Las organizaciones y sus equipos de plataformas eligen las plataformas y capacidades a crear y mantener y pueden priorizar las iniciativas más valiosas e impactantes.

Notablemente, la mayor parte del trabajo para proveer una capacidad se realiza después de su release inicial, al proveer actualizaciones sin impacto, funcionalidades nuevas y mejoradas, soporte operativo y habilitación y educación al usuario final. Por lo tanto, una plataforma valiosa y de impacto planificará de antemano la gestión de su plataforma para operaciones a largo plazo y confiabilidad.

Nivel 1, Provisional — A demanda

Las plataformas y capacidades se desarrollan, publican y actualizan de manera reactiva, en base a pedidos y requisitos ad hoc de equipos de producto. Los equipos de producto pueden incluso necesitar planificar y construir las capacidades que ellos mismos requieren.

Los equipos que construyen una nueva capacidad para cubrir sus propias necesidades, ya sean equipos centrales dedicados o equipos de aplicaciones, solo toman una responsabilidad informal para dar soporte a otros que la utilizan. No se espera de ellos un mantenimiento activo y existen pocos procesos para vetar la calidad de la oferta. En este nivel, las implementaciones suelen ignorarse hasta que se descubre alguna vulnerabilidad de seguridad, un defecto previene su uso o se presenta un nuevo requerimiento, y en ese momento puede llegar a implementarse con rapidez otro plan reactivo.

Características:

• Las capacidades se crean para cubrir necesidades que generan presión en equipos de aplicación individuales.
• El foco está en la entrega inicial de capacidades centrales; no se hacen planes para un mantenimiento y sustentabilidad duradero.
• Las implementaciones de capacidad generalmente llegan tarde y necesitando actualizaciones.
• Aparecen picos repentinos de trabajo asociados a cambios de alto impacto introducidos de forma tardía a las capacidades, como el descubrimiento de una vulnerabilidad.
• Los cambios pueden provocar caídas de servicios tanto planificadas como no planificadas.
• Cada actualización se hace en forma personalizada y requiere tiempo e investigación para establecer un proceso en cada actualización.

Escenarios de ejemplo:

• Se anuncia la vulnerabilidad de seguridad Log4Shell y la organización se apresura a designar un equipo de especialistas para investigar dónde podría existir una vulnerabilidad en la organización e instigar la aplicación de parches. Una vez que el equipo identifica el impacto, debe trabajar codo a codo con una cantidad de equipos diferentes dado que cada uno de ellos gestiona sus propios servidores y tienen procesos de actualización diferentes. Incluso cuando este trabajo se considera finalizado, el nivel de confianza de que no existan instancias que no se hayan cubierto es escaso.

Nivel 2, Operativo — Registro central

Las plataformas y capacidades están centralmente documentadas y descubribles y los procesos para planificar y gestionar el ciclo de vida de capacidades están, por lo menos, parcialmente definidos. La responsabilidad y dueños de cada servicio y función están documentados. Los procesos de gestión del ciclo de vida varían entre capacidades, dependiendo de sus dueños y prioridades. Un equipo central mantiene, o tiene la capacidad de generar bajo demanda, un inventario de requerimientos pendientes que indique el estado de mantenimiento de las capacidades actuales. Esto permite a la organización registrar el progreso hacia la oferta de capacidades y el cumplimiento con los requerimientos de actualización.

Características:

• Los equipos de plataforma crean nuevas capacidades según se necesite para cumplir necesidades urgentes.
• Un equipo central provee un registro de servicios compartidos disponibles para toda la organización.
• Se aplican estándares flexibles a las capacidades, tales como incluir una API automatizable y documentos de uso.
• Se usa infraestructura como código para facilitar la trazabilidad de los servicios desplegados.
• Se habilitan, mediante los inventarios de servicios, auditorias para el cumplimiento de regulaciones tales como PCI DSS o HIPAA.
• Los trabajos de migración y actualización se registran en un gráfico de trabajo pendiente, que permite a la organización registrar el grado de cumplimiento y el tiempo para completarlos.
• Los registros no indican el nivel de soporte; en este nivel, las actualizaciones con frecuencia siguen siendo manuales y personalizadas.

Escenarios de ejemplo:

• PostgreSQL 11 llega al fin de su ciclo (EOL) a fin de año. La organización sabe qué bases de datos requieren una actualización y agendan el trabajo en las tareas pendientes de cada equipo.

Nivel 3, Escalable — Habilitación central

Las plataformas y capacidades no solo están centralmente registradas sino también centralmente orquestadas. Los equipos de plataforma tienen la responsabilidad de entender las necesidades más amplias de la organización y priorizar el trabajo entre equipos de plataforma e infraestructura en consonancia. Se espera de aquellos responsables de una capacidad, no solo que la mantengan técnicamente, sino también que provean experiencias estándar de usuario para integrar la capacidad con otros servicios relacionados en la organización, aseguren un uso seguro y confiable e incluso provean observabilidad.

Existen procesos estándar para la creación y evolución de nuevas capacidades, permitiendo que cualquiera en la organización pueda contribuir con una solución que cubra expectativas. Procesos continuos de entrega de capacidades y funcionalidades de plataforma permiten despliegues y restauraciones regulares. Los grandes cambios se planifican y coordinan en la medida que sean cambios de producto de cara a los clientes.

Características:

• Los equipos de aplicaciones solicitan servicios a los equipos de plataforma antes de crearlos.
• Los nuevos servicios deben adherirse a prácticas estándar como interfaces estándar, documentación y gobierno.
• Los procesos de actualización están documentados y son consistentes entre versiones y servicios.
• En los casos donde el proveedor de la capacidad no gestiona una actualización, provee herramientas y soporte a los usuarios para lograr impacto mínimo.

Escenarios de ejemplo:

• La organización va a actualizar a RHEL 9. Al hacerlo, cada equipo de aplicación necesita validar que su software continúe funcionando. Para permitir esta fase de prueba, el equipo de cómputo central está configurando entornos de prueba para cada equipo, con el software y las versiones de S.O. adecuadas.

Nivel 4, Optimizable — Servicios gestionados

El ciclo de vida de cada capacidad se gestiona de manera estandarizada y automatizada. Las capacidades, funcionalidades y actualizaciones son entregadas de forma continua sin impacto en los usuarios. Cualquier cambio importante, instigado por los proveedores de plataforma, incluye planes de migración para los usuarios existentes con responsabilidades y tiempos definidos.

Los proveedores de capacidades de plataforma asumen la mayor parte de la responsabilidad para el mantenimiento, pero hay un contrato claro, un “modelo de responsabilidad compartida”, que describe las responsabilidades de usuarios, permitiendo que ambos lados operen mayormente con autonomía.

Características:

• Un modelo de responsabilidad compartida define claramente quién es responsable de las plataformas y sus capacidades y qué se espera de los usuarios.
• Los equipos crean scripts tanto para la ejecución de la actualización y cualquier estrategia de restauración para mantener bajos el riesgo y el impacto.

Escenarios de ejemplo:

• A los usuarios de máquinas virtuales no se les requiere que gestionen nada relacionado con actualizaciones de versiones. Su única responsabilidad es tener un escenario en su pipeline de entrega que contenga una prueba de humo representativa. Luego se les pide que declaren sus aplicaciones como de baja tolerancia en caso que la misma deba esperar a un upgrade totalmente probado, o de alta tolerancia para ser considerada como pionera. La capacidad de máquina virtual gestiona luego el release automático de las actualizaciones, incluyendo restauraciones en caso de falla, ya sea tras las pruebas de humo o tras los canary releases.

¿Cómo es el proceso para obtener e incorporar retroalimentación y aprendizaje?

Al reaccionar ante la retroalimentación explícita o implícita de los usuarios, las organizaciones pueden incrementar la satisfacción del usuario y asegurar sustentabilidad a largo plazo. Para mantener la relevancia de una plataforma, las organizaciones deben balancear entre la innovación y cubrir las demandas de los usuarios. A medida que la tecnología y las preferencias de los usuarios cambian, las plataformas ágiles y adaptables a estos cambios serán las que prevalezcan. Revisar y redefinir regularmente el mecanismo de retroalimentación puede optimizar aún más el desarrollo de plataforma y mejorar el compromiso del usuario.

Nivel 1, Provisional — Ad hoc

Las métricas de uso y satisfaccción se obtienen de forma personalizada, en cada plataforma y capacidad si es que se cuenta con ellas. Los resultados y medidas de éxito no están alineadas de manera consistente entre capacidades y por lo tanto no se obtiene información que se pueda corresponder. La retroalimentación de usuario y la instrumentación de uso de la plataforma no puede obtenerse o, si se obtiene, será informal. Se toman decisiones basadas en requerimientos anecdóticos y datos incompletos.

Características:

• No hay experiencia u opiniones acerca de cómo medir el éxito de las plataformas
• Se usan herramientas familiares para obtener métricas comunes con intenciones y consideracions limitadas
• Dependencia en poca cantidad de datos
• Dificultad para asegurar la participación del usuario — los usuarios creen que su retroalimentación no se tiene en cuenta
• Si se usan encuestas, las preguntas cambian entre versiones, negando la posibilidad de registrar progreso.

Escenarios de ejemplo:

• Un líder técnico de plataforma quiere mejorar la colaboración con los usuarios agregando temas principales a su próxima planificación trimestral. Se decide realizar una encuesta sobre qué les gustaría ver a los usuarios. La respuesta es abrumadora, lo que es prometedor, pero también resulta en una dificultad para organizar y responder a todas esas ideas. Si bien algunas ideas influyen en la planificación del trimestre, los usuarios no ven que sus ideas hayan sido consideradas y están menos dispuestos a responder a la próxima encuesta.
• El equipo quiere capturar más datos automáticamente, por lo que buscan oportunidades de fácil recolección como las fallas de pruebas en CI. Sin embargo, no todos los equipos usan la misma automatización de CI, por lo que los datos solo están disponibles para aplicaciones Java aun cuando algunos equipos han cambiado la codificación de sus servicios a Scala.

Nivel 2, Operativo — Recolección consistente

Las organizaciones en este nivel tienen el objetivo interno de verificar que los productos de plataforma cubran las necesidades del mercado y de sus usuarios internos. Se valora que la recolección de retroalimentación de usuarios sea procesable y estructurada. Pueden asignarse equipos dedicados o individuos para obtener retroalimentación, asegurando un acercamiento más consistente. Los canales de retroalimentación como encuestas o foros de usuario están estandarizados y la retroalimentación está categorizada y priorizada. Más allá de la retroalimentación del usuario, también hay una expectativa de que las experiencias de usuario sean instrumentadas para generar datos de uso a lo largo del tiempo.

Se mantienen los desafíos de traducir la retroalimentación a tareas concretas. Aunque hay un repositorio creciente de datos, la organización podría necesitar comprender e integrar efectivamente esta retroalimentación en el roadmap de la plataforma. Puede resultar difícil asegurar que los usuarios vean cambios tangibles derivados de su retroalimentación.

Características:

• La recolección de datos se discute en la mayor parte de las sesiones de planificación o de implementación de capacidades.
• Puede que falte alinearse sobre qué exactamente debe medirse para verificar el éxito.
• Las funcionalidades de plataforma pueden medirse por éxito, como por ejemplo medir la adopción de los usuarios o el tiempo de usuario ahorrado.

Escenarios de ejemplo:

• Un equipo de plataforma dedica el 20% de su tiempo a funcionalidades definidas por usuario, que se identifican en base a encuestas y otras técnicas de entrevista. Sus respuestas se recopilan en una herramienta que permite votar y comentar para refinar aún más las prioridades. Durante la implementación los usuarios solicitantes son abordados para que colaboren en los primeros diseños e implementaciones. Una vez implementados, se realizan anuncios que se aseguran de que los usuarios solicitantes estén informados sobre las nuevas funcionalidades y de que reciban soporte en su adopción.
• El equipo con foco en capacidades de entrega de software quiere capturar más datos automaticamente incluyendo el tiempo de ciclo, el cual se automatiza por medio de la herramienta de build desde el commit a producción. Existe un acuerdo en que el tiempo de ciclo puede incluir otras actividades como PR review, pero no está incluido en este momento.

Nivel 3, Escalable — Ideas

En esta tapa, mientras que ya existen mecanismos robustos y estándar de retroalimentación, los datos se recolectan de manera personalizada para lograr ideas y acciones específicas y estratégicas. Los resultados deseados se identifican con métricas estándar seleccionadas para identificar progreso hacia los resultados esperados. Se pueden usar marcos y estándares de la industria para beneficiarse de investigaciones sobre el impacto de ciertos comportamientos.

Se emplean equipos o herramientas dedicadas a obtener y revisar la retroalimentación e identificar las ideas viables. Se establece una relación simbiótica entre producto de plataforma y sus usuarios. La retroalimentación se considera un activo estratégico que guía las operaciones y roadmap de la plataforma. Pueden instituirse sesiones regulares de revisión de retroalimentación, donde equipos de diferentes funciones se unen para discutir y definir estrategias basadas en las ideas de los usuarios.

Características:

• Antes de entregar una nueva funcionalidad de plataforma, el equipo discute cómo evaluar el resultado de su trabajo.
• La organización está ampliamente alineada con métricas que indican el éxito de las iniciativas de plataforma.
• Un Product Manager o un miembro dedicado del equipo conduce una permanente y consistente recolección de retroalimentación y proceso de análisis.
• La organización ha establecido métricas y objetivos para observar apuntando al éxito.

Escenarios de ejemplo:

• La organización ha registrado consistentemente los tiempos de producción y ejecución de cambios. Sin embargo, ahora se dan cuenta de que, si bien son métricas fáciles de recolectar, por sí solas no ofrecen un panorama completo de la entrega de software. Con esto en mente, el equipo implementa métricas para la confiabilidad y estabilidad del servicio.

Nivel 4, Optimizable — Cuantitativo y cualitativo

La retroalimentación y las métricas están profundamente integradas en la cultura de la organización. Toda la organización, desde los ejecutivos más altos a todos los ingenieros, reconocen el valor de la recolección de datos y la retroalimentación en la evolución del producto. Hay una democratización de datos, donde varios beneficiarios, incluyendo los usuarios de plataforma y líderes de negocio, están involucrados activamente en la identificación de hipótesis para mejorar la plataforma, aportando retroalimentación duante el proceso de diseño y luego midiendo el impacto posterior a la entrega. Todas estas mediciones son consideradas al planificar iniciativas en la plataforma.

No solo se utilizan marcos estándar sino que también existe un entendimiento de que tomar medidas desde múltiples ángulos crea un panorama más holístico. Hay una inversión para comprender cómo las medidas cualitativas cambian a medida que las cuantitativas mejoran. Se tiene un foco en identificar mediciones clave que permiten anticipar funcionalidades que soportaran las necesidades de usuarios, aliviarán sus desafíos y mantenerse por delante de las tendencias de la industria y requerimientos del negocio.

Características:

• Los equipos de plataforma buscan continuamente formas de mejorar las métricas que miran y la forma en la que obtienen datos.
• La organización está familiarizada y es sensible a la ley de Goodhart: “Cuando una medida se convierte en objetivo, deja de ser una buena medida.”
• Las métricas y telemetría obtenidas son evaluadas constantemente en cuanto a vericidad de información y valor.
• La gestión de datos de métricas está bien soportada, con herramientas como capacidades estándar de la plataforma para gestionar data lakes e información derivada.
• Se promueve la colaboración inter departamental para evitar silos de datos y permitir ciclos efectivos de retroalimentación.

Escenarios de ejemplo:

• Con el tiempo, la organización ha recolectado datos que indican un aumento en el tiempo del build de más del 15%. Esto genera experiencias negativas en el desarrollo y una vez generadas, aun si el tiempo de build se reduce por debajo del tiempo original, los desarrolladores permanecen frustrados por más tiempo. Este hecho lleva al equipo de build a establecer y adherirse a un Service Level Objective (SLO), que permite la identificación temprana y mejora antes de que se instigue el ciclo negativo con sus usuarios.