archivo

Archivos diarios: abril 28, 2012

El autor y especialista en bases de datos Thomas L. Holaday tiene una cita que refleja el sentir de muchos de los que nos dedicamos a esto, cuando nos encontramos de manera frecuente con resistencias que no hacen sino complicar más lo que ya es complejo de por sí (traducción libre): “La clave que explica el atractivo de los desarrolladores por los videojuegos no son ni los monstruos que escupen fuego o las pálidas sirenas semidesnudas, sino la experiencia de llevar a cabo una tarea de principio a fin, sin los requisitos cambiantes de los usuarios”.

Las resistencias no son solo los requisitos cambiantes de los usuarios, es más, en muchos casos no son su variable más significativa. Si cambiamos el “requisitos cambiantes de los usuarios” del final de la cita por “habituales bandazos y resistencias que afectan al ritmo del proyecto”, reflejaría, al menos en mi caso, mi estado de ánimo en muchas, tal vez demasiadas, ocasiones.

En 1986, Jobs compró Pixar por 5 millones de dolares, además de otros 5 millones de dolares que invirtió inicialmente en la misma, en total 10 millones de dolares. En 2006 Disney se hizo con Pixar pagando más de 7000 millones de dolares y convirtiendo a Jobs en el principal accionista a título individual de Disney.

Sin embargo, la aventura no resultó nada fácil, ya que Jobs ejerció de banquero principal de Pixar y la inversión inicial se multiplicó con el paso de los años. A estos hay que sumar que Pixar triunfó en el mundo de la animación (y en ello tuvo mucho que ver el software que desarrolló) pero la idea inicial era la venta de su hardware y software especializado en el tratamiento de imágenes.

Cuando todo estaba casi perdido, se llegó a un acuerdo con Disney para la realización de tres largometrajes. El éxito de Toy Story (que costó muchísimo esfuerzo sacarla adelante) y de la salida a bolsa de Pixar, crearon un cimiento muy sólido al que le siguieron éxito tras éxito.

John Lasseter fue la persona clave en este período, como lo fue Steve Wozniak en su primera etapa en Apple. Director creativo de Pixar y realizador, de su cabeza salió Toy Story y los siguientes éxitos de Pixar. Fue muy respetado por Jobs, que como artista sentía una profunda admiración por aquellos que poseían un talento superior al suyo

Lo he vivido ya en más de una ocasión y lo he sufrido no durante semanas, sino meses y en algún caso hasta años.

Poner en marcha un sistema de información en su totalidad o en gran parte sin que ningún usuario lo haya utilizado en un entorno o contexto real es una condena para el propio sistema de información y para quienes lo gestionan.

Llegarán peticiones de mejora e incidencias superiores a la capacidad que se tendrá para dar respuesta (si es que dispones de esa capacidad, ya que pocas veces se prevé que lo que se desarrolla hay que mantenerlo, de hecho los responsables o directores funcionales del sistema es lo que pensarán si no se les explica de manera adecuada y con carácter previo qué es un desarrollo de software y qué consecuencias tiene los cambios en las especificaciones sobre el coste del proyecto) y la puesta en marcha del sistema se convertirá en una cuesta arriba que no parece tener fin a la vez que no termina de aflojar su pendiente.

Es la consecuencia de la aplicación de metodologías clásicas y del efecto bola de cristal donde se piensa que todo lo definido hace meses (cuando no años) por personas que lo mismo ya no trabajan en la organización o están en otro departamento sigue siendo válido cuando se pone en marcha el sistema. Esto sucederá en la mayoría de los casos incluso habiendo realizado un análisis muy riguroso (en todo caso, la calidad del análisis reducirá los problemas, algo que, sin duda, se agradece, pero que no resuelve el problema de fondo).

Para empezar habría que definir qué se entiende cómo documentación de calidad. Para mi una documentación de calidad es un instrumento que sirve como herramienta para un desarrollo debiendo estar ajustada a las posibilidades y contexto del proyecto.

Por tanto, la documentación debe ser la precisa, ni más ni menos y por ese motivo debe ser el proyecto el que determine la que resulta necesaria. ¿Formalismos? Puedo entender que una organización quiera una homogeneidad en la documentación de los proyectos pero las normas deben ser lo suficientemente flexibles para que cumpliendo ese objetivo no sobrecarguemos a los desarrollos con exceso de documentación (más documentos de los necesarios), con excesos en cada documento (que cada documento tenga más contenidos de los necesarios) y con exceso de formalismo.

Una documentación de alta calidad no es el resultado de los formalismos que se establezcan sobre la misma sino por la adecuación de sus contenidos a los propósitos del proyecto. Tener una documentación de un proyecto perfecta a nivel formal no asegura que el producto final satisfaga las expectativas que se tenían puestas en él, lo único que asegura es la inversión de un esfuerzo que se podría haber utilizado para entregar un producto más depurado y con menor deuda técnica.