Yosemite Fitness
Related Articles
Si hay algo que no le falta a un equipo de ingeniería de plataformas son ideas. Cuando sus clientes son sus colegas y amigos, tiene una lista de deseos en constante expansión para mejorar la experiencia del desarrollador: ¡solo tiene que preguntar! Pero como ocurre con cualquier equipo de producto, existen recursos limitados y la necesidad de equilibrar los objetivos comerciales y técnicos. Hay tantas partes interesadas que influyen en la hoja de ruta de la experiencia del desarrollador que puede resultar difícil priorizar. Sí, necesitas una hoja de ruta. ¿Lo más importante que distingue a la ingeniería de plataformas de las plataformas de arriba hacia abajo de los tiempos tecnológicos de antaño? Nadie debería usarlo. Cuando crea una herramienta de experiencia de desarrollador, ya sea una plataforma o un portal para desarrolladores internos o simplemente un directorio o mejor documentación, necesita crear algo que sus ingenieros realmente quieran usar. Su estrategia de plataforma, a veces llamada experiencia de desarrollador o estrategia DevEx, debería hacer la vida de los desarrolladores mucho más fácil que necesiten una buena razón para abandonar ese camino dorado. La ingeniería de plataformas requiere una mentalidad de plataforma como producto, llena de diseño, prototipos y días de demostración centrados en el usuario. Tus colegas se convierten en tus clientes. No solo necesita una hoja de ruta interna del producto, sino que también debe publicarla activamente dentro de su organización. De esta manera, no solo se compromete a resolver los problemas de su cliente-desarrollador, sino que también cierra el ciclo de retroalimentación, de modo que su equipo de plataforma sepa desde el principio y con frecuencia si está creando algo que ellos quieren o necesitan. Conozca a sus partes interesadas Quizás incluso más que cuando se trabaja con usuarios externos, un equipo de plataforma, como administrador de la experiencia del desarrollador, está en deuda con muchas partes interesadas. Como señaló Sergiu Petean de Allianz Direct, un antipatrón común para los equipos de plataforma solo se dirige a la parte interesada del ingeniero de software. Cuanto más grande sea la empresa, más regulada esté su industria y más partes interesadas deberá considerar desde el primer día. En el gigante de los seguros, su equipo inicialmente destacó ocho partes interesadas diferentes, cada una con demandas diferentes: Usuarios finales Calidad Seguridad Entrega de software Sostenibilidad de datos Gestión de incidentes Cumplimiento Más tarde se dieron cuenta de que la plataforma tiene la capacidad de interactuar con un número incluso mayor que los equipos. Trabaje para construir una relación con cada una de sus partes interesadas técnicas y comerciales. Descubra qué parte del ciclo de vida del desarrollo de software es más importante para ellos. Y luego introdúzcalos en sus ciclos de retroalimentación que impacten la hoja de ruta del producto de su plataforma de ingeniería. Aprenda a priorizar Cuantas más partes interesadas identifique, más solicitudes de funciones recibirá. Sin embargo, según una investigación realizada por DX, el equipo de experiencia de desarrollador promedio representa una fracción de toda la organización de ingeniería. Esto puede parecer abrumador, pero una estrategia de ingeniería de plataformas consiste en centralizar y resolver las frustraciones a escala. ¿Cómo es posible equilibrar tantas demandas contradictorias? Michael Galloway, jefe de ingeniería de plataformas de HashiCorp, recomienda intentar quitar la piedra del zapato. Los mayores puntos de fricción serán un proceso continuo, pero, como dijo, “Muchas veces, los ingenieros han estado en un lugar durante suficiente tiempo en el que han desarrollado soluciones alternativas o se han acostumbrado a los problemas. Se ha convertido en una experiencia conocida. Así que tenemos que observar su flujo de trabajo para ver qué son los guijarros y luego eliminarlos”. Los equipos de plataformas exitosos relacionan periódicamente el programa con sus clientes. Es una forma eficaz de generar empatía. Otra cosa a priorizar es preguntarse: ¿son solo uno o dos equipos los que hablan, o es algo sistémico en toda la organización? Nunca complacerás a todos, pero tu trabajo en ingeniería de plataformas es crear soluciones que alrededor del 80% de tus desarrolladores estarían felices de adoptar. Apuesta por lo más fácil Otra forma en que la ingeniería de plataformas se diferencia de las gigantescas plataformas heredadas es que no se trata de una implementación gigantesca y única. De hecho, Team Topologies tiene el concepto de plataforma más delgada viable. Empiece con algo pequeño pero sólido sobre el que pueda desarrollar su estrategia de plataforma. Para la mayoría de las empresas, la mayor pérdida de tiempo es encontrar cosas. Su primer TVP suele ser un directorio de quién posee qué o mejor documentación. Pero no confíes en ese instinto: pregunta primero. Realizar una encuesta de productividad de desarrolladores le permitirá saber cuáles son las mayores frustraciones para sus desarrolladores. Haga preguntas específicas, no abiertas. Puede comenzar conociendo los 25 impulsores de la productividad de los desarrolladores, que desde una perspectiva sociotécnica van desde la respuesta a incidentes y la experiencia de guardia hasta la recopilación de requisitos y plazos realistas. Combine esto con conversaciones informales y combine la codificación con sus desarrolladores para descubrir problemas grandes y pequeños que necesitan solución. Como sugiere el consultor de startups Lenny Rachitsky, puedes calificar cada idea del 1 al 5 según la X del impacto que tendrá en la resolución de un problema y la Y del esfuerzo necesario. Sólo asegúrese de que todo lo que aparece en ese «gráfico de hipótesis» cumpla con el requisito de resolver un problema para la mayoría de sus desarrolladores, porque un equipo de plataforma nunca debería trabajar para un solo equipo de desarrollo. No olvide revisar soluciones rápidas para aliviar el dolor. Siguiendo la práctica ágil de “caminar sobre el tablero”, priorice las funciones más cercanas a Listo. Esto permite lograr avances tempranos para promover a los defensores de la plataforma, lo que puede contribuir en gran medida a aumentar la adopción. Esté abierto al cambio Como dijo el CTO de Carta, Will Larson: “Si algo terrible está sucediendo en su empresa, entonces ese es el lugar para involucrarse. Nada más importará si no se aborda esta cuestión”. Tu hoja de ruta es solo eso, un mapa: siempre hay más de un camino por recorrer. Debes estar preparado para desviarte y cambiar tus prioridades. Podría ser una pandemia global o un parche de vulnerabilidad urgente. Es posible que deba adoptar una nueva tecnología de desarrollo porque le ayudará a trabajar con un socio de integración de renombre. Especialmente en una industria bien regulada, las partes interesadas en ciberseguridad y cumplimiento pueden influir en muchos cambios. El hecho de que la ingeniería de plataforma sea voluntaria no significa que no pueda facilitar algunos cambios obligatorios. Cualquiera sea el motivo, es importante comunicar cualquier fluctuación a los clientes internos y explicar por qué han cambiado las prioridades de la hoja de ruta. Medir continuamente La ingeniería es una ciencia, por eso sabemos que no se puede mejorar lo que no se mide. Esta «visión respaldada por métricas», como la llama Diogo Correia, gerente de producto de experiencia de desarrollador en Pipedrive, impulsa la mejora continua, no solo para la estrategia de su plataforma sino también para sus desarrolladores. Su equipo utiliza DX para encuestas trimestrales a desarrolladores. Por eso desarrolló y abrió un taller de experiencia para desarrolladores de una hora para ayudar a los equipos de desarrollo no solo a descubrir sus propios puntos débiles, sino también a definir las áreas de enfoque de los equipos individuales para la próxima Q. Tiene un impacto inmediato en términos de sentimiento». y prioridades que reporten en el próximo trimestre», afirmó. Por ejemplo, muchos desarrolladores se quejan de la deuda técnica, pero casi nadie quiere dedicar tiempo a arreglarla. Este conocimiento impulsó la rotación de los equipos de Pipedrive para centrarse en pagar esa deuda en lugar de lanzar nuevas funciones. «Los talleres ayudan a identificar servicios o bibliotecas concretos que tiene un equipo determinado y con los que la mayoría de los desarrolladores del equipo tienen dificultades», continuó Correia. Esto ayuda al equipo a priorizar y planificar la refactorización, «en lugar de sufrir durante años y años, como antes». En última instancia, la medida más importante de cualquier estrategia de experiencia de desarrollador es si sus clientes de desarrollo interno la adoptan y utilizan. Trabaje para estrechar ese circuito de retroalimentación interna para asegurarse de que está construyendo lo que ellos quieren. Sólo así logrará un éxito mensurable y a largo plazo.
