La nueva era del desarrollo de software para los negocios

Black Hole

Resumen ejecutivo

Este artículo expone una nueva forma en que los empresarios pueden volver a confiar en el desarrollo de software y usarlo para transformar sus empresas dándoles una ventaja competitiva solo limitada por su imaginación. El desarrollo de software no es término grato cuando se pronuncia en el contexto de empresarios. Siempre está asociado con proyectos horriblemente atrasados; se puede usar el término “El hoyo negro”, es decir, le echas dinero, gentes, esfuerzos y procesos; todo se consume. Y no es que los empresarios no quieran o entiendan el software; el problema es que han sido tantas veces que han pasado por el “Hoyo negro” que tiemblan ante la posibilidad de volver a hacerlo.
 


¿Sr. Empresario, alguna vez ha gestionado exitosamente un proyecto de desarrollo?

 Específicamente:
  • ¿Le han terminado por lo menos un proyecto de software a tiempo, dentro de presupuesto, que satisfaga las necesidades de su negocio y que no tenga fallas?
  • ¿De los proyectos que si le han terminado, le agregan valor real día a día realmente a su negocio?
  • ¿El software que su empresa ha desarrollado, le da una ventaja competitiva real?
  • ¿El valor que le saca a la tecnología es sustancialmente mayor a lo que ha invertido?

No esta solo, solo un porcentaje muy pequeño de las organizaciones (privadas o públicas) a nivel mundial pueden contestar positivamente todas estas preguntas.

La búsqueda de valor en la empresa moderna

Las empresas siempre están buscando valor y lo hacen aumentando ventas, bajando costos y aumentando productividad. Sin embargo, nunca es fácil. En la era moderna de competitividad global el valor no es tan fácil de encontrar.
 
La tecnología en general y el software en particular son herramientas que han demostrado facilitar la aportación de valor, sin embargo han estado plagados de lo contrario, al grado de ser llamados “Hoyos negros” de valor.

Lo que típicamente pasa

Business Value

Tradicionalmente resultado de alguna búsqueda de valor por la gente encargada de tan “superficial” tarea alguien sugiere desarrollar un “sistemita”.
 
El mismo que sugiere hacer el “sistemita” dice que conoce a un “tremendo” programador que ya hizo uno igualito y que solo es cuestión de hablarle para que le haga algunas modificaciones, que solo sería cuestión de un par de meses.
 
Se contrata al “Tremendo” y este pide un conjunto de recursos de los que solo se aprueba la mitad; promete que en 6 meses queda listo el sistema (por aquello de los recursos negados) y se autoriza el nuevo “sistema” (a estas alturas se le cae el diminutivo). Todo esto ocurre solo para arrancar el proyecto, ahora si empieza lo bueno...
 
“El tremendo” y su equipo (que a estas alturas ya están en la nómina) empiezan a analizar, se entrevistan con “todos” los usuarios, escriben un montón de documentos y dibujan muchos diagramas que nadie entiende, bosquejan pantallas, re-inventan procesos y 24 meses después piden 6 más porque ya las falta muy poco; al final de esos 6 (que en realidad se convierten en 9) entregan un programa que tiene más fallas que el encuentro de dos placas tectónicas y ahora hay que empezar a modificarlo porque las cosas ya han cambiado, el sistema no cumple con lo más básico y el gobierno ya invento nuevas regulaciones que no se consideraron.
 
En otro escenario pasa más o menos lo mismo que el primero pero en este caso se le “asigna” el proyecto al departamento de sistemas de la empresa que ya de por sí trabaja con recursos limitados y aparte acaban de perder a la única persona que sabe programar, alguien de apellido “Tremendo”.

La “crisis” del software

La crisis del software es un fenómeno perfectamente conocido y ampliamente documentado1, se puede resumir de la siguiente forma. 
  • Proyectos por encima de presupuestos
  • Proyectos por encima de fechas prometidas
  • Software de baja calidad
  • Software que pocas veces cumple los requerimientos
  • Los proyectos son inmanejables y el código difícil de mantener.
Sería cosa rara encontrar una empresa que se haya aventurado a financiar el desarrollo de software y que no haya sido plagada por los anteriores efectos.
 
No Sr. Empresario, no le ha pasado solo a Usted. Le ha pasado a los mejores, a los grandes y los pequeños, a empresas privadas, públicas y a los mismos gobiernos. Un reporte2 publicado en '95 determino que:
  • 31.1% de los proyectos se cancelan antes de ser terminados
  • 52.7% de los proyectos cuestan 189% más de lo inicialmente estimado
  • Solo el 16.2% de los proyectos se terminan en tiempo y dentro de presupuesto, sin embargo solo cubren el 50% de las necesidades.
  • Entre más ambicioso el proyecto, más altas las probabilidades del fracaso.

Porque no funciona bien el desarrollo de software

Durante mucho tiempo se pensó que los proyectos de desarrollo debían ser manejados de forma similar a un proyecto de construcción (de hecho a la fecha se usan los mismos términos):
  • Especificaciones
  • Diseño
  • Construcción
  • Pruebas
  • Instalación
  • Mantenimiento
Puesto que se determino que una vez codificado el software es muy caro modificarlo (un mito, porque de hecho la adaptabilidad es la gran ventaja del software para los negocios), se busca en las etapas de definición contemplar todas y cualquier posibilidad de cambio; por esto se le asigna la mayor cantidad de tiempo, tiempo dedicado básicamente a preguntar, pensar, discutir, escribir, diseñar y repetir.
 
Al final se busca una aprobación de todo ese trabajo previo. Así entonces se “congelan” los planos y se inicia la construcción. Meses después se empieza a probar y si todo sale bien (cosa rara) se empieza a instalar. Todo este trabajo parece lógico, sin embargo no siempre lo más lógico es lo más correcto.
 
Fundamentalmente el software es difícil porque:

  • Es altamente incierto, lo que se necesita no se conoce con anticipación. Frecuentemente hasta que no se ve el software se empiezan a clarificar las necesidades.
  • La tecnología cambia muy rápido.
  • Los expertos del negocio no son expertos en tecnología y viceversa.
  • A pesar de muchos esfuerzos, el proceso es casi totalmente manual; hay que escribir a mano miles de líneas de código y todas tienen que estar bien.
  • El entorno cambia más rápido que lo que se tarda en terminar el sistema
  • La gestión del esfuerzo no puede hacerse con prácticas de otras industrias. El “Project Management” no funciona, de hecho lo retrasa.

Como “hacerlo” bien

Basándose en gestión adaptiva y en las lecciones aprendidas de los fracasos de la crisis del software, la industria desarrolla durante los 90 y consolida en 20013 un conjunto de prácticas y recomendaciones que a la fecha se conocen como el “Manifiesto Ágil”. En este documento se plasman las mejores ideas y conceptos probados en proyectos altamente exitosos.
 
Las prácticas comunes de cualquier metodología ágil son:
  • Gestión iterativa:
    El proyecto se desglosa o subdivide en mini-proyectos conocidos como iteraciones de duración estrictamente fija no mayor a 30 días, siendo 15 días lo más común. Se hacen tantas de estas iteraciones como sean necesarias para tener software que de valor al negocio, pero el empresario es quien finalmente decide cuando terminar las iteraciones. Cada una de las iteraciones se concluye con software funcionando y potencialmente listo para ser usado. Es decir, al final de cada iteración se tiene software que se puede ver y usar.
  • Equipos pequeños y multi-disciplinarios:
    El trabajo es realizado por equipos no más grandes que 8 personas incluyendo los expertos del negocio, formando parte integral del equipo. Todos hacen de todo y lo hacen todo el tiempo.
  • Inspección frecuente:
    El esfuerzo del proyecto se inspecciona diariamente por el equipo y demás interesados.
  • Gestión de productividad y calidad:
    Se aplican prácticas enfocadas a la productividad y la calidad. Es casi automático duplicar la productividad y no es difícil multiplicarla 3 o 4 veces. La calidad del producto es controlada y mantenida mediante un proceso continuo de pruebas automatizadas a lo largo del proyecto. No se hacen las pruebas al final, se prueba todos los días muchas veces por día de forma casi automática.
  • Mejora continua
    A lo largo de todo el proyecto se inspecciona el proceso para encontrar oportunidades de mejorar productividad, calidad y satisfacción del cliente.

Los resultados

Sorprendentemente el primer principio del Manifiesto Ágil es:
 
“Nuestra más alta prioridad es satisfacer al cliente mediante la entrega temprana y frecuente de software valioso”.
 
Así pues con la aplicación de agilidad al desarrollo de software se obtienen los siguientes resultados para la empresa:
  • Entrega temprana y frecuente de software (cada 2 semanas).
  • Control permanente del costo mediante la gestión de iteraciones de duración fija. El negocio decide cuando dejar de pagar iteraciones.
  • Duplicar, triplicar o incluso cuadriplicar la productividad de los programadores.
  • Alta visibilidad y control directo del esfuerzo. Los hombres de negocio deciden que desarrollar y cuando, no los programadores.
  • Prácticamente cero riesgos de implementación.
  • Alto retorno de inversión (ROI).

Como tomar ventaja competitiva del nuevo orden

Con estas herramientas en las manos de los hombres de negocio, el software tiene ahora la facultad de convertirse en un verdadero catalizador de la competitividad.
 
Los empresarios ahora en día tienen la oportunidad de tomar ventaja de su creatividad e imaginación para implementar estrategias donde la tecnología les permite una ventaja competitiva que les ayude a encontrar el tan elusivo valor.
 
Usted que dirige una empresa no puede ignorar este cambio de paradigmas ocurriendo en la industria del software. Sería un error que conociendo el nuevo orden se continué desarrollando software en el umbral del “Hoyo Negro”. Ahora con el desarrollo ágil tenemos boleto de ida y vuelta al éxito en el desarrollo. No lo desaproveche.

¿Y donde lo compro?

Seguramente ahora se preguntarán ¿donde compro el paquete de “Desarrollo Ágil”?. Esto no es un paquete que se pueda comprar o bajar del Internet; esto es un cambio de paradigmas a nivel empresarial, es una nueva forma de pensar en la gestión tecnológica.
 
La agilidad apenas se empieza a promocionar y conocer en los países de habla hispana (Argentina y España son los que tienen más agilidad) y son pocas las empresas que lo han aplicado; aunque las que lo han hecho han encontrado la experiencia muy satisfactoria.
 
Párrafo para México:
Actualmente en México, Sonora a través de diversas iniciativas impulsa la industria del desarrollo de software; específicamente la organización TI Sonora A.C. impulsa y promueve la aplicación de la agilidad en las empresas que se dedican profesionalmente al desarrollo al igual que las que lo hacen de forma interna.
 
Acérquese con TI Sonora A.C. para conocer más de cómo aplicar estos principios y metodologías.

Conclusiones

  • El desarrollo de software no tiene que ser un “Hoyo negro”, por lo contrario puede ser el catalizador de ventajas competitivas importantes.
  • La aplicación de la agilidad es de bajo riesgo.
  • El control del costo vuelve con los hombres de negocio, estos controlan cuando detener el esfuerzo, así como el Que desarrollar y Cuando.
  • El riesgo de desarrollar software disminuye drásticamente.
  • Se obtiene software valioso y de calidad rápida y frecuentemente.
  • Sonora es el primer estado que impulsa y promueve formalmente estas prácticas regionalmente a través de TI Sonora.
Más información:

Referencias

  1. Crisis del software - http://es.wikipedia.org/wiki/Crisis_del_Software.
  2. The Chaos Report (1995) - http://net.educause.edu/ir/library/pdf/NCP08083B.pdf
  3. La historia del manifiesto (ingles) - http://agilemanifesto.org/history.html.

La agilidad no es un "silver bullet"

Desde la comunidad ágil en España llega el comentario que en éste artículo la agilidad puede ser considerada como un "silver bullet", es decir, la panacea y solución a todos los problemas que aquejan el desarrollo del software en los negocios.

Es importante enfatizar que la agilidad NO es ese "silver bullet", definitivamente no lo es; de hecho, mal aplicada la agilidad puede ser mucho peor que la cascada tradicional. 

Lo agilidad lo que hace es reducir el riesgo de un proyecto de software por medio de la aplicación integral de prácticas probadas tanto en la ingenieria de desarrollo del software como en la gestión del esfuerzo de un equipo responsabilizado con la tarea de aumentar la competitividad de un negocio. 

Gracias Xavier por tus comentarios.

User login

Who's new

  • hoppiemochie
  • Antannysoca
  • Ariana Mendez
  • Orlando Cano
  • isc_jemsedano

Who's online

There are currently 0 users and 2 guests online.

Syndicate

Syndicate content