Por: Leonardo Agudelo Marín – @sweepnoise
¿Usted usa software? ¿Usted requiere software? ¿Usted contrata la construcción software?
Si alguna de las respuestas es afirmativa este artículo va dirigido a usted.
Hace poco más de 70 años se construye software, una cantidad de tiempo corta comparada con otras disciplinas como la construcción civil, con miles de años de experiencia y perfeccionamiento.
Al inicio se construían sistemas muy pequeños y usualmente se creaba todo el sistema y luego se hacían los ajustes o se corregían los errores que el cliente identificara. Para las “pequeñas” necesidades del momento esto funcionaba bien.
Con el tiempo se empezaron a necesitar sistemas más grandes y complejos y la industria del software adoptó maneras de trabajar más organizadas, formas parecidas a las que se empleaban para construir obras civiles.
Sin embargo y pese a que construir sistemas informáticos era más organizado, los productos no eran satisfactorios para los clientes, los sistemas no hacían lo que se requería, los proyectos no se entregaban a tiempo o se cancelaban y los presupuestos se sobrepasaban, para muchos la industria del software entró en “crisis”.
Poco a poco y tras muchos proyectos con problemas, la naturaleza de la construcción de software se ha ido develando: construir software no es como construir casas, más bien parece ser un proceso del que se va aprendiendo a medida que se va construyendo.
La construcción de software debe basarse en el empirismo porque los requisitos para llevarlo a cabo son altamente cambiantes, esta es la realidad a la que se han enfrentado los proyectos de desarrollo de software en la que los usuarios van entendiendo mejor sus necesidades y problemas cuando ya están haciendo uso del sistema construido, no antes.
Ante este entendimiento de cómo funciona el desarrollo de software, desde la década de los 90’s han ido surgiendo formas de trabajo orientadas a entornos altamente cambiantes, estas formas de trabajo se basan en el empirismo y han demostrado ser mejores para la creación de software que las formas predecesoras, con un 64% de proyectos exitosos frente a un 49% de las aproximaciones tradicionales[1].
Gracias al descubrimiento de mejores formas de trabajar (conocidas como aproximaciones ágiles) la industria del software tiene una gran oportunidad para ofrecer lo mejor de sí, pero aún hay muchas organizaciones que no aceptan que se trabaje de esta manera, o bien que aceptan pero su forma de contratación no permite desplegar el verdadero potencial que estas tienen.
Crear software ágilmente supone un cambio para los clientes en la forma en que participan en la construcción del mismo. Se requiere que estén presentes durante la construcción del proyecto, observando día a día lo que se construye, corrigiendo día a día el rumbo del equipo que construye, guiando el equipo para que construya software con valor para el negocio.
Para que el rumbo del equipo pueda ser corregido y para que los cambios que surgen a medida de que el software va tomando forma se puedan realizar, se requiere una forma de contratación que no considere el cambio como una tragedia sino como una ventaja competitiva, que no considere un rumbo erróneo como una pérdida de dinero y tiempo sino como un aprendizaje y un crecimiento para el equipo entero.
Existen varias formas de contratos propicios para contextos como este, una breve búsqueda en internet lo podrá orientar y los grupos de agilistas lo podrán ayudar en este aspecto.
Aún nos falta aprender más y refinar nuestra manera de trabajar, aún tenemos que lograr que el porcentaje de proyectos exitosos se acerque mucho más al 100%, aún tenemos que conseguir que los clientes y usuarios trabajen de la mano con nosotros para construir software que realmente agregue valor a sus negocios y por eso es que entre todos debemos dar el paso y evolucionar hacia estas formas de trabajo.
[1]Dr. Dobb’s Journal 2013 IT Project Success Survey posted at www.ambysoft.com/surveys/
Ágiles Colombia 