El ahora notorio lanzamiento del sitio web de la central de seguros de salud norteamericana de la Ley de Protección al Paciente y Cuidados Asequibles, heathcare.gov, sacó a la luz pública el problema de las fallas en los productos de software. Aunque es una de las fallas de software de TI más notoria que se recuerde recientemente, está lejos de ser la única. Estas fallas ocurren todos los días en las empresas de toda clase de industrias en el mundo.

Falla de comunicación entre TI y el negocio
¿Qué hay detrás de estas fallas? Tony Orlando, vicepresidente ejecutivo de ventas y marketing en 3Pillar Global, firma de entrega de soluciones y software, con oficinas principales en Fairfax, Virginia, señala como culpable a la desconexión entre los grupos de interés de las unidades de negocio (ventas, marketing, finanzas) y TI.

“Una de las razones por la que enfrentamos estos retos en los proyectos de TI, estas fallas en las nuevas iniciativas, es que el lado de negocios y el lado de TI no desean estar sincronizados”, señala Orlando.

“Lo que consigue es una compañía que no puede ver el panorama -que con la madurez de la economía digital, los clientes esperan un producto o un servicio que ofrezca una experiencia. Esa experiencia de usuario debe ser un componente y un reflejo de una estrategia general de negocio; no puede continuar viendo a la tecnología, o al negocio, o a las experiencias de usuario por separado”, señala Orlando.

Bajo esas metas aparentemente contradictorias es que nació el framework de desarrollo ágil, y sus principios son incluso más importantes en el clima de negocios de hoy.

Su negocio es tan ágil como su software. Ser capaz de responder rápidamente a la demanda del cliente y a la vez satisfacer las necesidades del negocio, requiere que los desarrolladores de software tengan la libertad de construir software rápida y eficientemente, para cumplir con los estándares del usuario final, y que los grupos de interés de la empresa tengan visibilidad del proceso de desarrollo, señala Orlando.

“Los desarrolladores desean escribir un código bueno y limpio. Los chicos de marketing y finanzas desean ver que los productos tengan éxito. Los clientes demandan una buena experiencia de usuario. ¿Cómo puede asegurarse que todo esto ocurra y que usted no aparezca en los titulares cuando las cosas fallen?”, pregunta Orlando.

Debe cambiar, pasar de enfocarse en el proyecto a enfocarse en el producto, y poner énfasis en la colaboración y la comunicación entre las líneas de negocio y los departamentos que podrían parecer disparejos, precisa Orlando.

Antes del modelo ágil, explica Dan Klaussen, director de administración de producto en 3Pillar Global, la mayoría de los proyectos de software fueron construidos siguiendo una especie de proceso tipo “cascada”. Esto significaba establecer cada uno de los requerimientos que un producto posiblemente necesitaría satisfacer, antes de comenzar a construir el producto.

“Aunque es bueno tener requerimientos bien definidos, con demasiada frecuencia son escritos en una especie de espacio vacío en donde realmente no es posible prever el desorden del mundo real”, señala Klaussen.

“Los usuarios realmente no se comportan de la forma en que se dice que lo harán, los retos del software algunas veces son más difíciles de lo esperado, los competidores cambian y se mueven en formas inesperadas, el soporte a la gerencia va y viene. El desarrollo ágil apareció como una respuesta a la noción de que tenía que haber alguna forma de permitir cierta flexibilidad en el proceso de desarrollo de software”, señala Orlando. O, como explica, “la idea principal es iterar, rápida y repetidamente, para mantenerse al día con el mercado. Lleve su idea en una mínima expresión al mercado rápidamente, y obtenga retroalimentación del cliente, de modo que pueda iterar y adaptar ese producto en tiempo real a las necesidades de los clientes”, agrega.

Desarrollo sensible
Hay grandes riesgos de por medio en el desarrollo de un nuevo producto en el actual ambiente altamente conectado y fuertemente involucrado en los medios sociales, señala Orlando. El margen para el error es sumamente delgado, y si algo sale mal, 24 horas de noticias al respecto de seguro harán que su negocio reciba una paliza pública. La probabilidad de ocurrencia de las fallas está reduciendo la tolerancia al riesgo de los negocios y los está forzando a considerar nuevas formas de asegurar que sus productos serán exitosos, agrega Klaussen, de 3Pillar Global.

“Los propietarios de negocios no desean, o incluso no están en capacidad de, financiar un proyecto con una baja probabilidad de lograr los resultados de negocio esperados”, anota Klaussen.

“Estos promotores de proyectos desean estar implicados de forma tal que se les permita tocar, sentir y probar el producto tan pronto como sea posible para validar que sus productos están avanzando en la dirección correcta”, añade Klaussen.

Y el movimiento hacia un framework ágil se ha visto impulsado por los mismos desarrolladores, indica Klaussen. No hay nada peor para un desarrollador que escribir miles de líneas de código que nadie usará nunca, agrega. Es especialmente deprimente para los desarrolladores ver que el producto en el cual están trabajando no cumple con los objetivos (de negocios o del consumidor) mientras lo están escribiendo, señala.

“Sin embargo, mostrar su código a usuarios reales y a los grupos de interés de la empresa de manera regular -usualmente cada dos semanas- y obtener una retroalimentación honesta y directa que agregue valor, bueno, eso es muy motivador”, indica Klaussen. “Ahora ellos saben exactamente cómo agradar a sus usuarios”.

Agilidad ajustable
El framework ágil enfatiza la flexibilidad, la constante iteración y, por encima de todo lo demás, la colaboración, de acuerdo a la Agile Alliance, una organización dedicada a dar soporte a desarrolladores y grupos de interés de las empresas que aplican los principios ágiles.

Dentro del framework Agile: Cortesía de The Agile Alliance.

“En pocas palabras, el proceso ágil está diseñado para permitir a los principales grupos de interés de la empresa validar continuamente que un proyecto está alineado con, y satisface los objetivos de, la empresa”, señala Klaussen. “Es la noción de que el software que construyes nunca se termina y nunca es estático”, agrega.

El framework ágil fuerza la colaboración, anota Brian Bargmann, gerente de programación en ESPN. (Bargmann señala que su opinión sobre el tema es propia y no necesariamente representa o refleja la de ESPN).

“Tienes a las áreas de negocios de TI trabajando juntas, colaborando, y eso es lo que hará la diferencia”, señala Bargmann. “Primero todos sienten como si fueran ‘forzados’ a trabajar juntos, pero una vez que se vuelve aparente que la meta para ambos equipos es la mejora continua, entonces se comienza a ver el valor”, agrega.

Con una metodología ágil, si los productos son dirigidos en la dirección equivocada, los problemas serán abordados de forma temprana, agrega Klaussen, y la metodología está diseñada para permitir cambios en la hoja de ruta del producto en general sin mucha pérdida -en términos de capital, recursos y tiempo. Esos son beneficios reales que son vistos y percibidos por los grupos de interés de la empresa -el lado de negocios, los desarrolladores, y los clientes- afirma.

“El proceso ágil anima al equipo a construir el proyecto de forma tal que puedan tocarlo y sentirlo, que puedan jugar con él y probarlo frecuentemente. Esto significa construir -en base al valor- el producto en partes, como la funcionalidad para el usuario final, que generalmente requiere que un poquito de cada una de las partes de la solución trabajen juntas”, sostiene Klaussen, de modo que los equipos de desarrolladores frecuentemente integren los componentes del front-end, middleware y del back-end para asegurar la funcionalidad en lugar de intentar ajustar todas las piezas juntas a último minuto.

“Lo que esto elimina -señala Bargmann de ESPN- son aquellas situaciones en las que sus equipos de desarrollo estimaron, digamos, una ventana de nueve meses para un proyecto, y luego se dan cuenta de que no podrán terminarlo, o tienen que regresar e integrar otras funciones, o arreglar errores. Así que van con los grupos de interés del negocio y les dicen ‘lo siento, va a tomar un par de semanas más’”, precisa.

Con Agile, agrega Klaussen, “tiene la visión, crea el plan. Pero cuando hace su aparición la realidad, cuando se necesita incorporar la retroalimentación, cuando los objetivos del negocio cambian, seguir una metodología que sirve para esto le permite al equipo ser más resiliente y el resultado entregado llevará valor real al negocio”, agrega.

Mientras que en los frameworks tradicionales de desarrollo de software incorporar la retroalimentación en la hoja de ruta del producto era visto como una falla, dentro de Agile es visto como algo positivo, señala Klaussen.

“Esto es positivo porque el equipo comprendió que no lo hacían correctamente y fueron capaces de arreglarlo rápidamente. La mayoría de las otras metodologías tratan esto como una falla. No estaba adecuadamente especificado y entonces se produce la culpa. Sin embargo, es humano escuchar, especificar e implementar una solución. Y cuando el equipo crea una rutina que revisa que estén creando una funcionalidad significativa, más rápido aprenden cómo hacerlo bien”, añade Klaussen, y así ofrecen un mayor valor para el negocio.

Ser ágil no es la respuesta completa
Por supuesto, ‘ser ágil’ solo en palabras no cambiará mucho, señala Bargmann. Tiene que hacer al menos un salto parcial hacia una mentalidad verdaderamente enfocada en el producto y los resultados de negocio, afirma el ejecutivo.

“Cualquier equipo de desarrollo puede decir, ‘mire, puedo darle una solución rápida que satisfaga las necesidades del negocio’, pero ¿qué significa eso realmente si no está enfocado en un resultado completo del negocio?”, se pregunta Bargmann.

“Esto se traduce en lo que se ha denominado la ‘hamburguesa de ardilla’. Si su cliente dice ‘Quiero una hamburguesa. Ahora mismo’, y el desarrollador dice: ‘Bueno, tomará algo de tiempo conseguir la carne, molerla, aplanarla y cocinarla’, pero el cliente dice: ‘Deme cualquier cosa’ y usted llega con una ‘hamburguesa de ardilla’. Es un poco de carne entre dos rebanadas de pan, es ‘algo’, pero no es lo que usted necesita. No es lo que usted pidió y, ciertamente, no satisface las necesidades del negocio o del cliente”, sostiene Bargmann.

Ser ágil en sí no cambia los resultados del negocio -anota Klaussen- si no se soluciona la parte del problema de la colaboración y la iteración. “Resulta que tener éxito con una pequeña cantidad de funcionalidades es mucho mejor que fallar con un gran plan. El tiempo extra que toma rehacer la visión que ha fracasado será más largo y será un camino mucho más doloroso para todos los involucrados”, afirma.

-Sharon Florentino, CIO