archivo

Archivos Mensuales: abril 2012

Comenta Kent Beck que “la planificación también es diseño”.

Si a esto le sumamos que el diseño no es solo la apariencia externa del producto, su arquitectura o en términos más teóricos, la concreción del análisis en una solución técnica, sino que también debería considerarse diseño la ejecución final del producto (es una visión más heterodoxa, pero muy en consonancia con la visión que del diseño tienen muchas personas en la industria, como por ejemplo Steve Jobs), llegaríamos a la conclusión de que la planificación y el diseño son dos elementos horizontales o transversales en el proceso de desarrollo.

Y es que la planificación lo condiciona absolutamente todo, así como las sucesivas decisiones que modifican la misma vía feedback de los desarrollos o por contingencias externas al proyecto. La planificación llega incluso al día a día, qué hemos hecho ayer y qué vamos a hacer hoy. Y si el diseño abarca desde la concepción del producto hasta la propia ejecución, se verá afectado como no podía ser de otra forma por la planificación y a su vez afectará a la misma, ya que el diseño impondrá restricciones que hará más simple o más complicado el proceso de adaptación al cambio.

Ordenador personal, ordenador personal con interfaz gráfica de usuario y revolución en el campo de la animación por ordenador. Tres grandes hitos a las espaldas de Steve Jobs, en los casi cuarenta y dos años con los que volvió a Apple.

Muchas cicatrices, interminables horas de trabajo.

Y seguía con hambre.

Volvió a Apple y tomó decisiones esenciales que permitieron sobrevivir a una empresa que estaba en profunda decadencia y con un futuro más que incierto.

Jobs seguía sintiendo a Apple como suya, como algo inseparable de él y así fue hasta el final. De hecho ese fue otro de sus grandes secretos, su identificación con una marca, a la que asoció a su causa, la continua innovación proporcionando nuevos productos a la sociedad que a su vez fomentaron a la competencia a ser cada vez mejor.

Tuve que hacer un importante recorte de gastos que tuvo como eje, la reducción del portfolio de productos a solo cuatro, un ordenador de sobremesa y un portátil dirigidos por un lado al ámbito doméstico y por otro al ámbito empresarial.

Se focalizan los esfuerzos en menos productos pero con el objetivo de centrar en ellos toda su atención. En este caso, menos es más, menos productos más calidad y más innovación.

Se rodeó de un equipo de confianza, esperaba una larga travesía en el desierto y para ello necesita contar con personas que compartieran sus decisiones. Eso lo llevó tanto al ámbito del Consejo de Administración como en los principales responsables de área.

Llevar la calidad a su máxima expresión, introduciendo el diseño como parte del propio producto y no solo como su envoltorio e innovar para sacar productos que no tengan competencia.

Para ello confió en una figura que en esta etapa sería relevante tanto para Jobs como para Apple. Jony Ive al frente del diseño industrial trabajando codo a codo con Jobs, desarrollaron diseños innovadores y transgresores para los productos, que si bien trajeron de cabeza a los ingenieros de Apple, proporcionaron una experiencia de usuario, en muchos casos incomparable al de otros productos similares.

Se intentó recuperar su imagen de marca, esa imagen que hacía que contase todavía con infinidad de incondicionales dado que debería pasar todavía bastante tiempo para enderezar el rumbo (cuesta mucho trabajo dar la vuelta a una deriva negativa), era necesario que esa masa de fieles se sintieran identificados con la causa y confiasen en que más pronto que tarde se recuperaría el espíritu que se estaba perdiendo.

Para ello puso en marcha la campaña Think Different, que trataba de expresar los valores de la compañía y de sus seguidores.

Jobs fue un revolucionario en la aplicación de las técnicas de marketing, ya lo hizo con el famoso anuncio de presentación del Mac en la Super Bowl y llevó esa práctica a lo largo de toda su carrera, si bien fue en su segunda etapa en Apple donde la explotó al máximo, no solo en los anuncios, sino en las propias presentaciones de los productos tanto en los meses previos a la misma como en su puesta en escena.

Es un tema polémico, posiblemente con tantas opiniones como personas, probablemente muchas de estas opiniones, incluso encontradas, tendrán parte de razón.

Desde mi punto de vista la dirección de proyectos software no debe ser vista como un elemento independiente al tipo de producto que desarrollamos, es decir, hacemos software y sabemos que este proceso presenta a lo largo de su ciclo de vida una serie de particularidades que hacen que su proceso de desarrollo sea especial y distinto a otros procesos de construcción o en general a otro tipo de proyectos.

Por tanto, al menos en el desarrollo de software, la dirección de proyectos no debería ser contemplada como algo que está por encima de todo, sino que debe adaptarse, contextualizarse y personalizarse a nuestro negocio, eliminándose interfaces o elementos de proceso artificiales que en nada benefician al proyecto.

Claro que existen buenas prácticas que pueden extender a proyectos software y no software, eso es indudable y no aprovechar el conocimiento existente puede suponer errores perfectamente evitables, ahora bien, también es un error pensar que se dispone de un martillo de oro o de una bala de plata que sirve independientemente del contexto (esto puede pasar con algunas buenas prácticas, pero desde luego no con todas).

El desarrollo de software requiere especialización y la gestión o dirección de proyectos no puede mantenerse al margen.

El otro compromiso, tal vez el más importante es el que tiene uno consigo mismo. Este compromiso varía en cada persona en función de su escala de valores.

En el ámbito laboral mi compromiso personal es sacar adelante de la mejor manera posible los proyectos en los que participo, eso no quiere decir que todos vayan a tener éxito sino que lo voy a intentar, que voy a tratar de poner lo mejor de mi, sea mucho o poco, para que el objetivo se cumpla.

Ese compromiso, está por encima de mi contexto laboral. ¿Eso quiere decir que me hago inmune a él? No y muchas veces afecta a mi rendimiento y me genera en demasiadas ocasiones frustración e ira, sin embargo, no recuerdo ninguna situación en la que haya terminando bajando los brazos, incluso cuando la consecución de los objetivos en el proyecto ya no eran posibles.

No soy mejor que tu por esto, quiero que lo tengas claro, es solo mi forma de entenderlo.

Mi compromiso está por encima de lo que puede ofrecerme mi organización porque me niego a estar limitado por la misma, sería un doble castigo, no sentirme valorado y autolimitarme como consecuencia de lo anterior. No obstante, respeto, muy mucho a quien decide que hasta aquí hemos llegado, siempre y cuando sea objetiva la falta de compensación entre lo que compromete la organización y lo que compromete la persona, si bien, y desde mi punto de vista, cuando eso ocurra, el camino no debería ser la autolimitación, sino la búsqueda de otras alternativas profesionales, ya que tu libertad para reducir tu nivel de compromiso debe mantenerse en equilibrio con tu entorno y no es justo que tus compañeros carguen con tus problemas.

No puedes esperar o pedir compromiso si tu no le ofreces lo mismo.

Por otro lado, todo tiene un límite. Una persona podrá ser comprometida con su trabajo, con el proyecto y contigo pero si la organización a la que pertenecéis no lo valora en su justa medida terminará disminuyendo su nivel de compromiso, tal vez no en este proyecto, tal vez no en el siguiente, pero sí lo hará tarde o temprano y lo más probable es que te termine comentando sus motivos (si tiene confianza en ti).

Hay personas más mayor capacidad de comprometerse que otras, que pueden tener más paciencia o aguante, pero si el compromiso no se alimenta terminará por desaparecer paulatinamente o provocará que busquen otras alternativas profesionales en las que sí encuentren lo que hasta ahora se les estaba negando.

Me he encontrado a lo largo de mi trayectoria profesional muchos más técnicos y desarrolladores excepcionales que técnicos y desarrolladores con compromiso.

Lo primero sin lo segundo es como tener un coche de alta gama sin fiabilidad: tiene mucha potencia, es muy bonito, tiene muchos extras pero te puede dejar tirado en cualquier momento.

Comprometerse a un proyecto y con unos compañeros es fundamental para sacar adelante un trabajo colaborativo como el nuestro.

La falta de compromiso se evidencia cuando eludes responsabilidades que te corresponden, cuando de manera unilateral decides no hacer determinadas tareas o reduces la calidad de las mismas, cuando incumples plazos o entregas de manera injustificada, cuando entiendes que tu tiempo es más importante que el de tus compañeros, cuanto entiendes que tus objetivos personales y profesionales son más importantes que nada, cuando incrementas tu bienestar a costa de reducir el de otros, etc…

Quien se compromete contigo se hundirá en el barco contigo cuando todo se acabe, quien no, aprovechará la primera oportunidad para salvarse.

El talento es importante, muy importante, marca diferencias. No reniego del talento, al contrario, quiero el mayor talento posible en los equipos que trabajan conmigo, ahora bien, no quiero talentos sin compromiso.

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.