Equilibre las compensaciones entre innovación y confiabilidad manteniendo el código estable, deleitando a los usuarios y evitando la tecnología por el bien de la tecnología.
por Isaac Sacolick
Los directores de TI y los líderes de TI están atrapados en una paradoja de prioridades en competencia con respecto al desarrollo, la mejora y la modernización de aplicaciones. Por un lado, buscan innovación, experiencias que deleiten a los usuarios finales y prácticas de devops ágiles que permitan la entrega rápida de nuevas capacidades comerciales. Por otro lado, les preocupa el aumento de la deuda técnica, garantizar que las aplicaciones pasen por las validaciones de seguridad adecuadas y demostrar si los prototipos pueden funcionar y escalar en entornos de producción.
Sí, los directores de TI y los líderes de TI también quieren tener su pastel y comérselo. Conocen todos los deseos, los imprescindibles y las listas de deseos de sus desarrolladores y líderes de entrega. Más tiempo para desarrollar código “de la manera correcta”, más personas en el equipo, mejor capacitación, infraestructura de desarrollo más ágil, herramientas de desarrollo de aplicaciones modernas, mejor participación de las partes interesadas y prioridades bien definidas están en la lista de todos.
Los líderes de TI están alineados con sus equipos en sus necesidades, pero también deben enfrentar las realidades comerciales para impulsar la transformación digital, trabajar con restricciones presupuestarias y cumplir con los requisitos de cumplimiento.
Los CIO quieren que los equipos de desarrollo de aplicaciones sepan cómo tomar decisiones prudentes en torno a las compensaciones, qué pasos tomar para garantizar que lo desarrollado sea compatible y por qué la colaboración con los usuarios finales, las partes interesadas, los arquitectos y las operaciones es tan importante como obtener la aplicación. hecho.
Para abordar estas paradojas, los CIO esperan que sus equipos de desarrollo comprendan los principios de desarrollo y las compensaciones. Aquí hay cinco para considerar.
Equilibrar la deuda técnica y la innovación
Es muy fácil para los equipos de desarrollo emocionarse persiguiendo innovaciones o agregando picos alrededor de nuevas tecnologías a la acumulación. Los CIO y los líderes de TI quieren innovación, pero también se preocupan cuando los equipos de desarrollo no abordan la deuda técnica. Una cartera de pedidos ágil y saludable debería mostrar equipos ágiles que completan un equilibrio de picos, deuda técnica, nuevas funcionalidades y mejoras operativas.
La priorización de los equipos ágiles debería recaer en el propietario del producto. Pero los líderes de TI pueden establecer principios si los propietarios de productos no priorizan la deuda técnica o si fuerzan las prioridades de las funciones sin considerar los picos de innovación recomendados por el equipo ágil.
Los directores de TI también son realistas y saben que las nuevas implementaciones probablemente conlleven una deuda técnica adicional. Entienden que a veces los desarrolladores deben tomar atajos para cumplir con los plazos o identificar opciones de codificación más eficientes durante la implementación. Es razonable esperar que la deuda técnica recién creada esté codificada en el código fuente y en los ágiles retrasos, y que los equipos busquen abordarlos según las prioridades.
Desarrolle siempre código seguro y mantenible
Los equipos de desarrollo se encuentran bajo una presión significativa para entregar características y capacidades a los usuarios finales rápidamente. Esa es ciertamente una de las razones por las que los equipos crean nuevas deudas técnicas, pero es una mala excusa para desarrollar código que no se puede mantener o que pasa por alto los estándares de seguridad.
Los líderes de TI no quieren código espagueti, ni tampoco un código demasiado complejo que requiera mantenimiento de ingenieros avanzados. Los líderes de TI son responsables del mantenimiento a largo plazo del código que entregan, sabiendo que los desarrolladores y los equipos se reasignan a nuevos proyectos. Esperan que el código siga patrones de arquitectura, estándares de codificación, convenciones de nomenclatura, patrones de registro y manejo de excepciones.
También esperan que los equipos de desarrollo colaboren en la definición y evolución de los estándares. A medida que la tecnología, las plataformas y las mejores prácticas continúan evolucionando, las organizaciones no pueden confiar en que los arquitectos posean y especifiquen todas las pautas.
Cree experiencias de usuario agradables que funcionen y escalen
En los primeros días del desarrollo web, los equipos de software tenían dificultades en la arquitectura y el diseño de aplicaciones.
Un enfoque hizo que el proceso de desarrollo comenzara con equipos que diseñaran la base de datos back-end y codificaran la lógica empresarial. Los ingenieros crearon soluciones escalables y reutilizables, pero la implementación a menudo limitaba la experiencia del usuario y los diseños.
En el otro enfoque, los equipos de desarrollo web comienzan con los diseños de front-end y brindan excelentes experiencias a los usuarios finales. Pero estos diseños a menudo implementaban la lógica empresarial dentro de las plantillas del lado del servidor o realizaban frecuentes llamadas de servicio, lo que resultaba en aplicaciones que no funcionaban bien o no escalaban según lo requerido.
Los CIO deben ofrecer una gran experiencia y rendimiento. Hoy en día, los equipos de desarrollo pueden utilizar herramientas de wireframing, plataformas de bajo código, capacidades de marcado de características, patrones de diseño de microservicios, mejores prácticas de devops, automatización de pruebas y arquitecturas en la nube para ofrecer ambos.
Evite la codificación para resolver problemas de tecnología por el bien de la tecnología
Cuando me siento con los equipos de desarrollo durante sus sesiones de planificación ágil, escucho las declaraciones del problema subyacente y las coloco en una de varias categorías. Las mejores características e historias tienen como objetivo ofrecer o mejorar las capacidades de un grupo específico de usuarios finales. También puedo ver picos dedicados para probar nuevas soluciones o crear prototipos de nuevas capacidades. A veces, la deuda técnica se aborda dentro de la implementación de una historia de usuario. Otras veces, el trabajo es lo suficientemente significativo como para requerir múltiples historias dedicadas a la acumulación. Todos estos son buenos ejemplos de trabajo que el propietario del producto debe revisar y priorizar.
A veces veo trabajo dirigido a resolver una necesidad tecnológica. En el extremo inferior, podrían ser clases de servicios públicos para admitir configuraciones y conexiones de servicio. También he visto equipos que intentan crear soluciones de gestión de microcontenido, capacidades de bajo código y herramientas de gestión de API.
La mayoría de los equipos de desarrollo deben evitar crear capacidades tecnológicas que resuelvan problemas tecnológicos. Las soluciones sólidas para los problemas técnicos suelen estar disponibles a través de bibliotecas de código abierto, servicios de computación en la nube pública, capacidades de código bajo y servicios de software comercial. Los arquitectos y los equipos de desarrollo deben evaluar estas opciones antes de registrarse para desarrollar soluciones de “tecnología por la tecnología”.
Adherirse a los estándares de gobernanza de datos
Lo último que los directores de TI y los líderes de TI quieren ver cuando los equipos de desarrollo crean o mejoran aplicaciones son más silos de datos, fuentes de datos duplicadas o estructuras de datos mal diseñadas. Para la mayoría de las organizaciones, el tamaño de la deuda de datos a menudo excede la deuda técnica y el impacto comercial es significativo. Simplemente pídale a cualquier científico de datos que le dé sentido a la expansión urbana de fuentes de datos que viven en los almacenes de datos empresariales y los lagos de datos.
Hoy en día es increíblemente fácil crear nuevas bases de datos relacionales, almacenes de datos NoSQL y lagos de datos. Eso es tanto una bendición como una maldición, y el problema es cómo ayudar a los equipos de desarrollo a saber qué fuentes de datos están disponibles y la mejor manera de interactuar con ellas. La revisión de catálogos de datos, portales de API y fuentes de datos maestros debe ser el primer paso para los equipos de desarrollo antes de crear nuevas estructuras de datos.
Si se necesitan nuevas estructuras de datos, los equipos deben usar herramientas de modelado de datos y seguir los estándares de gobierno de datos como prácticas no negociables.
En resumen, los directores de TI y los líderes de TI quieren innovación, velocidad, usuarios finales satisfechos y equipos de desarrollo entusiasmados por resolver los desafíos comerciales. Pero también necesitan confiabilidad, rendimiento, eficiencia, escalabilidad, seguridad y aplicaciones que puedan mantenerse a largo plazo. Estos no son objetivos mutuamente excluyentes, pero en cada lanzamiento, sprint e historia de usuario surgen compensaciones prácticas. Las organizaciones de TI deben definir los principios de ingeniería y debatir sus implementaciones como parte de su proceso de desarrollo.
Sobre el autor:
Isaac Sacolick es el autor de Driving Digital: The Leader’s Guide to Business Transformation through Technology , que cubre muchas prácticas como ágil, devops y ciencia de datos que son fundamentales para programas exitosos de transformación digital. Sacolick es un reconocido CIO social superior, bloguero desde hace mucho tiempo en Social, Agile and Transformation y CIO.com , y presidente de StarCIO.
Fuente: https://www.infoworld.com/article/3586248/5-things-cios-want-from-app-developers.html
