Una jefa a la que recuerdo con cariño solía decirnos al equipo: “Lo que se acuerda, se hace; lo que se empieza, se acaba, y lo que se hace, se hace bien”. Tres sentencias tan buenas como necesarias en cualquier actividad humana y empresarial. Los proyectos software no son una excepción.
En una información sobre la primera jornada “Testing & Tools Day” organizada por Sogeti se decía que el 70 por ciento de los proyectos de Tecnologías de la Información (TI) se terminan sin ser un éxito absoluto y que las soluciones no son lo que esperaban finalmente los clientes. Este hecho, recoge el artículo, obliga a revisar varias veces el producto software antes de su puesta en producción, con los retrasos y costes que ello supone. Es decir, que lo que se acordó no estaba hecho, se dejó a medias o no se hizo bien.
Sogeti apuesta por realizar pruebas desde el principio para solucionar el problema, lo que disminuiría los costes y el tiempo de desarrollo. Pero el testing, siendo importante, no implica que el software esté bien construido. Indica simplemente que funciona, no que el producto tenga calidad.
En la mayoría de las ocasiones, el verdadero origen de la falta de calidad es, precisamente, la falta de un modelo de calidad durante todo el ciclo de vida del software.
Actualmente, en muchas empresas de desarrollo de software se incurre en la desorientación ante la diversidad de modelos de calidad y técnicas de trabajo definidas a lo largo de los últimos años. Las empresas pueden optar por trabajar “en modo apagafuegos”, o elegir una metodología y aplicarla. Para desarrollar software, trabajar sin metodología es una opción más, pero en estos casos los resultados dependerán directamente de lo buenos que sean los empleados que hacen los desarrollos. Es lo que se denomina programación heroica porque todo el peso del resultado recae sobre el buen hacer de los programadores.
SEI (Software Engineering Institute) afirma que esta forma de producir software es propia de organizaciones poco maduras. El nivel de calidad, de predicción de resultados o de eficiencia es mínimo. Con ello no quiere decirse que los desarrollos sean malos, sino que la probabilidad de tener desarrollos óptimos es muy baja.
En todas las organizaciones maduras hay normativas y estándares más o menos consensuados que, en forma de modelos, ayudan a mejorar y/o evaluar la calidad de los sistemas. Cada campo de la ingeniería tiene reguladas las técnicas de trabajo para ofrecer las garantías necesarias en la construcción de sus respectivos “ingenios”. Pero la ingeniería del software es una excepción. No hay un consenso similar.
El problema en este momento no es la falta de estándares, modelos o técnicas, sino la abundancia de los mismos: CMMi, ISO 15504, DSDM, MSF, RUP, SCRUM, CISQ, etc. No se trata de determinar el mejor modelo que existe sino de elegir trabajar con uno, aquél que se adapte mejor a las características y necesidades del proyecto. Trabajar sin modelo es una opción pero no es una metodología y sin metodología, no podemos asegurar ningún nivel de calidad.
Frente a la gestión sistemática propiciada por las metodologías, se encuentra la gestión lineal que consiste en abrir el botiquín y buscar un apaciguador de síntomas. Pero no hay que confundir este tipo de gestión con los “métodos agiles” tan de moda hoy en día. Las metodologías ágiles son, como indica su nombre, metologías.
La gestión lineal carece de la perspectiva necesaria y responde a la presión del día a día que ofrece un atajo muy tentador: obtener y presentar datos que ofrezcan un buen comportamiento. Presionar a los desarrolladores también es propio de una gestión lineal que busca soluciones a corto plazo. Mantener la presión como norma genera una degradación en la calidad de lo producido y una desmotivación en las personas, que empeora aún más la situación.
Pero no siempre la calidad de los procesos asegura un producto final de calidad. Hay otros dos aspectos, sumados al anterior, que son igualmente importantes en todo proyecto software: la tecnología (la adecuada, ni la última ni la más cara) y el equipo (capacitados, de perfil específico, competentes y bien dimensionado), es decir, el capital estructural y el capital humano. Estos tres factores son los que determinan el éxito o el fracaso en cualquier proyecto. Cada elemento actúa con un determinado peso, diferente en función del sistema y del desarrollo. La empresa debe analizar y descubrir la potencia de cada uno de estos tres factores y componer el diseño de un sistema de desarrollo a su medida.
La mayoría de los clientes piden precios bajos y una fecha de entrega determinada, y dan por supuesta la calidad. Cuando se entrega un producto y éste no corresponde a lo esperado por el cliente, se podrán alegar mil y un motivos para justificarlo: problemas organizacionales, de recursos, de fechas, del “yo creía” o del “no me dijo nadie”. Pero la culpa “no” fue del chachachá negando lo que cantaba Gabinete Caligari en los años 80. La culpa fue de no haber conseguido que los procesos, la tecnología y las personas formaran una ventaja competitiva. Y, por supuesto, el cliente no debería pagar las consecuencias.
Imagen: Fernando
Soluciones y Sectores
Te puede interesar
-
Lecciones aprendidas en la implantación de la salud digital
Recientemente se celebró la III Semana de Salud Digital, que incluía, como parte fundamental, el X Congreso Internacional de ...
-
Cómo llegar con la comunicación a la Luna con ayuda de la tecnología: MoonBack
Una de las conclusiones del informe “El puesto de trabajo en España" es que uno de los principales beneficios ...
-
Smart Workplace y el curioso caso de Benjamin Button
A principios de año ya anunciaba en este blog el lanzamiento del servicio Smart Workplace, una nueva propuesta de ...
