archivo

Archivo de la etiqueta: diseño

En el desarrollo de software los extremos no son buenos. A veces se le da al programador un diseño tan detallado que básicamente lo que hace es traducirlo a código fuente en el contexto del framework con el que trabaja. Otras veces no existe diseño o bien las especificaciones no son completas y son los programadores solos o en colaboración con analistas los que rellenan los huecos.

Desde mi punto de vista es importante que el programador sepa lo que tiene que hacer, es decir, que las especificaciones las conozca y que también conozca los objetivos no funcionales pero sobre esa base es necesario darle libertad para que dentro de esas restricciones pueda realizar la solución que resulta más conveniente.

Es necesario tener en cuenta que si se realiza un desarrollo en base a un análisis y/o diseño que se realizó hace tiempo es muy posible que quien lo hiciera no tuviera en cuenta determinados factores que sí son conocidos en el presente y no resulta lógico no echar cuenta a una solución mejor por tener en cuenta un trabajo que se efectuó sin conocer determinados tipos de detalles.

También es importante precisar que ese margen de maniobra permite que el programador dentro de esas restricciones pueda expresar su creatividad (algo que todos llevamos dentro) y realice su trabajo más motivado, algo que todos sabemos termina produciendo resultados de mayor calidad.

Como siempre es importante evaluar el contexto. No hay verdades absolutas. Es posible que en determinadas situaciones tener un nivel de detalle importante resulta fundamental, por ejemplo, cuando se externaliza a otro equipo de trabajo las tareas propias de programación de un desarrollo (o parte de él), aunque incluso en estos casos hay que tener en cuenta que la comunicación seguirá siendo necesaria (y se debe considerar un problema si no la hay) porque siempre quedará algún detalle que no se ha especificado al 100%.

Para Bob C. Martin un software que presenta algunos de los siguientes defectos tiene un mal diseño:

1) Rigidez: Es complicado realizar cambios porque cada cambio afecta a otras partes del sistema.
2) Fragilidad: Cuando realizas un cambio, partes insospechadas del sistema empiezan a fallar.
3) Inmovilidad: Es difícil reutilizar código en otra aplicación porque no puede ser separado de la aplicación en la que se está usando.

Es importante incidir en que Martin se está centrando en aspectos de diseño y de arquitectura y no en aspectos de programación (pese a que al final estos problemas se hagan evidentes en el proceso de desarrollo y en las actividades de mantenimiento o evolución del sistema), por ese motivo los defectos que plantea están relacionados con factores como la modularidad, el alto acoplamiento, la baja cohesión y la alta complejidad ciclomática (entre otros).

Un buen diseño se valora cuando has trabajado con sistemas que no lo tienen, en los cuales realizar cualquier tarea de mantenimiento se encuentra con una resistencia que hace que los costes se disparen, sin que por ello se garantice que el producto va a pasar a producción con menos errores que los que tenía antes.

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.

La estrategia de Steve Jobs respecto a los productos se basaba en una idea simple pero a la vez muy complicada de conseguir. Consiste en crear o evolucionar un producto nuevo o ya existente hasta tal punto que la innovación y calidad de los mismos sea tal que no tenga competencia, al menos, a corto y medio plazo.

Esto lo pudimos ver, en ejemplos recientes, con el iPhone y en mayor medida con el iPad, donde casi dos años después todavía la competencia que es mucha y muy fuerte no ha encontrado una respuesta eficaz.

Para Jobs, la calidad era algo esencial, tanto como la innovación y en los productos de Apple la lleva hasta el extremo, desde un diseño sofisticado y atractivo exterior e interior (incluso en las piezas que no se ven), hasta un funcionamiento del producto fluido, intuitivo y eficaz que vaya de la mano del diseño y que permita tener un experiencia de usuario no comparable a la que hayas tenido anteriormente con un producto de similares características (si es que existía).

La experiencia de usuario no es solo cuestión de sensaciones cuando haces uso de un producto porque la sensación es tu primera reacción al producto y solo es duradera si el producto en cuestión te ofrece un funcionamiento que cumple o supera tus expectativas.

Y es que para Jobs la experiencia de usuario era fundamental, al fin y al cabo, ¿quiénes van a ser sus clientes?. Por eso, cuando me encuentro con productos software que desprecian la experiencia de usuario, siento que su implantación va a ser costosa, la productividad de uso por debajo de lo esperado y el retorno de la inversión, si es que llega, muy tardío.

Steve Jobs, resume todo lo anterior en la siguiente cita: “Diseño no es solo lo que se o lo que se siente. El diseño es también cómo funciona”.

Una máxima en el desarrollo de software debe ser la búsqueda de la solución más simple que satisfaga las expectativas del usuario y con la menor deuda técnica posible.

La búsqueda de esa solución no es fácil ya que implica tener una importante capacidad de abstracción, una experiencia significativa en el desarrollo de sistemas de información para el tipo de cliente y proceso de negocio con el que se está trabajando y tener la capacidad de entender que el producto final no es para que lo utilicemos nosotros, sino para que lo utilicen un conjunto de usuarios y que por tanto, su opinión resulta muy importante y se tiene que materializar en las sucesivas iteraciones del producto a partir del feedback obtenido de los mismos.

Cuando olvidamos este propósito o ponemos por encima de él nuestro espíritu creativo es cuando se corre el riesgo de entrar en este antipatrón en el que el producto gana en complejidad en proporción directa al nivel de ego satisfecho por parte del arquitecto o analista orgánico que definen la arquitectura y el diseño del sistema de información.

Defiendo absolutamente la posibilidad de que en una organización se pueda progresar horizontalmente de manera que técnicos que disfruten con la programación y con la ingeniería del software puedan tener la oportunidad de conseguir mejores condiciones laborales si su desempeño, experiencia y conocimientos les hace merecedores de ello.

Lo anterior es absolutamente compatible con una carrera profesional de índole más técnica orientada a la arquitectura del software.

Es posible que a un programador solo lo puedas vender dentro de un umbral precio/hora (es el reverso tenebroso de los proyectos tipo taxímetro o bolsa de horas), pero en proyectos donde prestas un servicio tener a desarrolladores altamente cualificados, motivados y productivos puede ser la diferencia entre ganar o perder dinero.

Un apunte: No hablo de sobredimensionar la cualificación de los equipos, ya que eso puede jugar incluso en contra del proyecto ya que puede provocar en algunos casos (proyectos de complejidad medio o baja) pérdida de motivación y de rendimiento, lo que unido a mayores costes, puede hacer que el proyecto no sea tan rentable como cabría pensar y encima tienes ocupado en el mismo a gran parte del potencial de tu organización.

Cuando el coste/hora y no la productividad es la que marca los pasos, se pueden llegar a tomar decisiones poco comprensibles como que arquitectos software o analistas orgánicos centren su esfuerzo en definir arquitecturas, frameworks o diseños y dejen a un lado el día a día de la programación.

Todos sabemos como evoluciona el mundo del desarrollo de software y eso hace que ese tipo de decisiones se consideren un antipatrón, ya que cuanto más alejado esté un arquitecto de la realidad de la codificación, más alejadas se encontrarán sus soluciones de las necesidades que pueda tener el equipo de programadores y el proyecto.

La creatividad desmesurada que nos caracteriza puede provocar que el arquitecto elija soluciones más teóricas (cuando no experimentales) que prácticas, alejando al proyecto del objetivo de simplicidad máxima que cumpla las expectativas del usuario. Este defecto lo tiene cualquiera que realice análisis, diseños o arquitecturas y empeora sensiblemente cuando se está alejado del día a día de los proyectos (un analista que no trata con usuarios y con sus problemas, tenderá a hacer soluciones más complejas).