Este artículo es la tercera parte de una serie de cuatro partes titulada Cómo mantener sus sistemas en funcionamiento, reducir el riesgo y permitir el crecimiento después de Covid-19. Los eventos recientes han causado un cambio en los riesgos de la tecnología de los mercados financieros y nuestra miniserie le ayudará a reequilibrar sus presupuestos para:
- Garantice la integridad de sus servicios actuales en estas circunstancias únicas
- Simplificar y reducir los riesgos, así como los costos a medio plazo
- Desarrollar nuevos productos y servicios que permitan el crecimiento en línea con las nuevas técnicas de presupuestación
Se deben construir nuevos productos y servicios
Un nuevo medio de presupuestación debe cumplir con el requisito de proporcionar nuevos productos y servicios a un menor costo, plazos más cortos y con la capacidad de cambiar los requisitos a corto plazo mientras el proyecto está en vuelo. Esto parece casi imposible, sin embargo, la técnica ya existe y está siendo desplegada por varios bancos.
Los presupuestos de cambio tradicionales se han centrado en proyectos con funcionalidad y plazos definidos. Esto es fácil de medir y, por lo tanto, calcular los rendimientos. Sin embargo, ofrece una adaptación limitada y costosa. La medida de la capacidad de TI de una institución ya no es tiempo y costo para la implementación, sino más bien el beneficio completo y la pérdida del negocio. Lo importante es el resultado del cliente, no el método y el estilo de los proyectos individuales. Esto se respeta cuando nos fijamos en la transformación digital en todas sus formas, pero en particular con entregas ágiles. ¿Cómo funcionan?
Los métodos ágiles no se basan en documentos de requisitos empresariales, tiempos de compilación definidos y pruebas antes de la producción. Más bien se basan en historias de usuarios, escuadrones, sprints y despliegue constante de cambios valiosos en la producción tan pronto como estén disponibles. ¿Qué significa todo eso?
Historia del usuario
En lugar de un documento de requisitos empresariales escrito por un analista de negocios, revisado por varias personas y luego firmado para el desarrollo, una historia de usuario es una breve descripción de qué característica quiere un usuario y por qué. Son más como una conversación y, de hecho, pueden ser escritos por los propios usuarios o sus gerentes. Este enfoque “suficiente” proporciona una manera muy sencilla de describir piezas más pequeñas de funcionalidad que agregarán valor. Con el tiempo, las muchas historias de usuario escritas se convertirán en un sistema sustancial.
Escuadrones
Un gerente de proyecto, dos analistas de negocios, ocho programadores, un arquitecto, personal de pruebas y personas de control de calidad son todos necesarios para los proyectos, ¿verdad? Ya no, no con ágil. En lugar de grandes equipos de esta naturaleza, los métodos ágiles utilizan escuadrones que son redondeados en la naturaleza. Siempre incluirán una persona centrada en el negocio llamada Propietario del Producto y pueden ser típicamente entre cinco y doce personas dependiendo del tamaño del trabajo que deben realizar. Varios quads se implementan en la misma organización y utilizando métodos ágiles con microservicios en la nube pueden desarrollar varias partes del mismo sistema sin entrar en conflicto entre sí. Un escuadrón recibe una historia de usuario y es responsable de implementar esa historia en producción. Su conjunto de habilidades combinadas proporciona todo lo necesario para la entrega. De hecho, recibirán y desplegarán constantemente nuevas historias a medida que se escriban.
Sprints
Los sprints son exactamente lo que parecen. Ráfagas cortas de desarrollo, generalmente en ciclos de aproximadamente 2 semanas, donde los escuadrones entregan historias de usuario sin producción. Cuántas historias se establece como objetivo al principio del sprint. Sin embargo, las cosas pueden cambiar y es totalmente permisible permitir que algunas historias se retrasen al siguiente sprint o que permitan una nueva historia en un sprint mientras está en vuelo. Lo importante con los sprints es respetar la duración del sprint para el escuadrón, pero permitir que la funcionalidad sea flexible. Todo esto, pero elimina el costoso control de cambios y permite a la organización adaptarse muy rápidamente a las circunstancias cambiantes.
Despliegue constante
La implementación constante se puede lograr mediante el método DevOps de integración continua e implementación continua. Este documento no entrará en los tecnicismos, excepto para decir que tal método garantiza que la organización obtenga el beneficio más pronto posible de las construcciones de tecnología. Garantizar una tasa rápida de retorno para el gasto tecnológico será esencial en el nuevo mundo.
Desde una perspectiva de presupuestación, esto significa que NO se deben establecer presupuestos para proyectos, en particular, ya que ahora es probable que cambien de prioridad y dimensión en un plazo corto. Los presupuestos deben establecerse para los escuadrones con una organización teniendo en cuenta cuántos escuadrones cree que debe financiar para el año financiero. Para un gran banco esto podría ser hasta 200 – 300 de 6 – 10 personas cada uno. Otras organizaciones escalarán en consecuencia. El CIO será responsable de asegurar se asegurará de que tenga un proceso para la aprobación adecuada de las historias de usuario a un ritmo y calidad suficiente para mantener los escuadrones completamente ocupados durante el año.
Esta miniserie fue tomada de un artículo escrito por nuestro CEO, Terry Boyland. Para leer todo el papel, haga clic en este enlace.