archivo

Archivos diarios: octubre 17, 2011

Alan Curtis Kay lleva más de cuarenta años en el negocio. Ha trabajado en el sector privado en empresas como Xerox, Atari, Apple, Walt Disney y HP y ha sido profesor universitario (UCLA, MIT, etc…). Es considerado como uno de los pioneros de la programación orientada a objetos y uno de los padres de las arquitecturas modernas de interfaces gráficas de usuario.

Que una persona con ese Currículum realice la siguiente reflexión es para tenerlo muy en cuenta: “La mayoría del software actual se parece mucho a las pirámides egipcias con millones de ladrillos apilados uno encima de otro, sin integridad estructura y realizados mediante fuerza bruta y miles de esclavos”.

Es una crítica dura a gran parte del software que se realizaba hace unos años y que todavía se realiza. La crisis del software es un término totalmente vigente como también lo es que la ingeniería del software es parte del antídoto para combatirlas.

Antes de desarrollar un software hay que tener una estrategia y unos procesos que apoyándose en una metodología adecuada, en la experiencia y habilidades del equipo de proyecto y en unas relaciones adecuadas con el área usuaria permitan desarrollar un producto de calidad (y por tanto mantenible) y con un esfuerzo adecuado a la naturaleza del trabajo a realizar.

Que un proveedor de servicios de desarrollo de software no tenga entre sus procesos una mínima metodología de verificación y validación de los artefactos que se van generando en los proyectos de desarrollo de software me parece una temeridad y eso que es algo con lo que me encuentro con demasiada frecuencia.

Es decir, se deja al buen o mal hacer del equipo de desarrollo la responsabilidad da revisar los artefactos (entre ellos, el más importante, el software) sin que exista unos procedimientos establecidos para ello. ¿Cuál es la consecuencia de todo esto? La organización no tiene una estrategia para garantizar unos mínimos de calidad en los desarrollos y eso es malo a corto plazo pero todavía peor a largo plazo ya que en un entorno tan competitivo como este negocio, la calidad puede ser aquello que te haga distinto de la competencia porque al final muy pocos se atreven a trabajar con quienes han tenido malas experiencias o tienen malas referencias por muy barato que sean sus precios o por muy maravilloso que sea lo que te vendan.

Que el cliente tenga sus propios mecanismos para intentar conseguir unos umbrales de calidad aceptables no debe eximir a que el proveedor los tenga ya que no es algo que deba depender del cliente con el que se trabaja sino que tiene que formar parte de la cultura de la organización.

Lo peor que tiene esta pregunta es que gran parte de los gerentes de cuenta o jefes de proyecto (por no decir la mayoría) considerarán que un proyecto ejecutado con éxito es aquel que como mínimo ha igualado el umbral de beneficio esperado o lo que es lo mismo, el grado de satisfacción del cliente y/o del usuario es secundario.

Tampoco es un proyecto de éxito uno que deje satisfecho al cliente y/o usuario sin pensar en la cuenta de resultados, pero si me apuráis es preferible esta opción a la contraria, ya que tal vez este proyecto no haya ido bien económicamente pero puede ser el punto de inicio de una colaboración a más largo plazo con el cliente en la cual no solo pueda recuperar lo perdido sino obtener beneficios.

La satisfacción del cliente y/o usuario no hay que considerarla con una visión cortoplacista, hay veces donde están satisfechos del resultado en primera instancia, pero después conforme van avanzando en el uso y conocimiento del sistema o cuando tienen que realizar mantenimientos del sistema de información, esa satisfacción puede convertirse en todo lo contrario.

Entonces, ¿qué es un proyecto ejecutado con éxito? Son muchas cosas y probablemente haya tantas definiciones como personas estén leyendo este artículo y también es más que posible que la mayoría de ellas incluso no sean excluyentes, ya que el éxito no siempre es fácil de medir.

Para mi un proyecto ejecutado con éxito es aquel que cumple las expectativas del cliente y/o usuario tras la entrega y pasado un tiempo de uso del software (se entienden expectativas funcionales y no funcionales), que tiene una deuda técnica ajustada a los umbrales presupuestarios del proyecto, donde el plazo de entrega se ha cumplido dentro de unos límites admisibles y en donde el proveedor ha visto también satisfechas sus expectativas económicas, sea en el proyecto o con una visión más a largo plazo con el cliente.