Hay varias cosas de este proyecto de IDEO y el BBVA en busca de un nuevo sistema de cajero automático que me parecen geniales. Lamentablemente no hay manera de insertar el vídeo en la entrada de un modo legal, así que antes de continuar leyendo recomiendo verlo siguiendo este enlace.

El resultado es muy bueno, con soluciones simples y elegantes que aseguran una buena interfaz. El paso de la tarjeta y los billetes del mundo digital al material es, además de una chulada, muy intuitivo. Establece una linealidad; el usuario ve dónde comienza y termina el proceso y lo mantiene – o tiene la impresión de mantenerlo – bajo control. La interfaz sigue tendencias marcadas en los últimos años como el recuerdo de las costumbres del usuario o el uso de un teclado táctil en la pantalla, mucho más flexible que uno físico.

Hasta ahora, en los equipos instalados en las calles, estos avances están limitados por el hardware. Las costumbres del usuario deben ser dos, ya que no caben más en las pequeñas pantallas de los cajeros. Las pantallas táctiles tienen que convivir con los teclados tradicionales, y a veces no sólo con el conjunto alfanumérico, sino también con los selectores alrededor de la pantalla. En ocasiones resulta imposible no dudar sobre qué teclado utilizar cuando hay tres disponibles y además uno de ellos, por virtual, no es explícito. Este proyecto supone precisamente un paso adelante porque trabaja el interfaz tanto sobre el hardware como sobre el software para crear eso que tanto se busca y tantas veces se oye: una experiencia mejor.

Se evita el baile de la mano al oír funcionar la maquinaria interna del cajero con una única ranura para recibos y billetes, para ingreso o retirada. Se eliminan las teclas y se emplea una pantalla táctil mucho mayor. El mayor cambio físico es el giro de 90º sobre el muro para ganar privacidad. Es el punto que veo más complicado de implantar, sobre todo en las unidades instaladas en la calle. No tengo nada claro que los concejales de urbanismo estén de acuerdo con que cada cajero automático se apropie de un metro cúbico de espacio en las aceras. Quizá por no haber sido atracado en un cajero también me parece uno de los puntos más prescindibles.

Si el producto me parece muy bueno, su explicación me parece genial. El vídeo es claro, cualquiera puede entenderlo y convencerse de los beneficios que aporta el nuevo cajero. Pero la web es aún mejor. Simple, con la información sobre el proyecto más importante para el usuario: los que quieran saber más preguntarán a Google. Y, sobre todo, austera en logotipos, sin lemas corporativos, sin colores coporativos, sin degradados corporativos. Una gran manera de explicar un gran proyecto.

Las cinco unidades piloto existentes están instaladas en Madrid, siguiendo con el proceso de evolución. Doy por hecho que una de ellas estará en la oficina hermana de BBVA Innovación. Intentaré confirmarlo y probarla. Prometo noticias.

Después de semanas sin tocar esto toca retomarlo con la última parte dedicada a la introducción de conceptos comunes.

Sección I, Estructura de la Gestión de Proyectos.

Capítulo 3, Los procesos de la Gestión de Proyectos

La gestión de proyectos se ocupa de cuidar la relación de muchas variables, relacionadas siempre a través de los conceptos de coste, tiempo y alcance.

Esta competencia clásicamente se expresa en la forma del Triángulo de la gestión de proyectos: algo muy simple pero también muy gráfico. En sus vértices tenemos los conceptos de coste, tiempo y alcance.

Debemos ser conscientes de que existe una dependencia entre estas variables, de tal manera que no es posible desplazar uno de los vértices sin que esto afecte a los demás. En estas relaciones debemos buscar lo imposible para conseguir lo improbable sin perder de vista la realidad.

En el tiempo en el que la calidad se ha convertido en un concepto en tendencia, se han propuesto esquemas en los que el triángulo se convierte en un cuadrilátero, con el vértice calidad compitiendo frente a los tres originales. A mi entender esto no debe plantearse de esta manera, ya que se puede convertir en un factor de fiabilidad exigible al resultado del proyecto frente al mismo proyecto, cuando toda la fiabilidad es exigible. Si de lo que realmente hablamos es de calidad del producto, esta debe ir especificada en el alcance, bien sea en tolerancias de fabricación industrial o en los tristes planes de obsolescencia.

Para poder observar las relaciones que forman cualquier proyecto es necesario primero fraccionarlo, identificar sus unidades fundamentales y clasificarlas según su orientación y función. Anteriormente en esta serie de entradas hablé de las fases de los proyectos. Cada fase tiene múltiples subfases y se articulará sobre distintas tareas y funciones.

Por ello y en paralelo a las fases del proyecto debemos establecer un concepto relacionado, el proceso. Un proceso es una serie de acciones que busca un resultado. Una fase es un contenedor con cara a un resultado, un proceso es un contenedor de acciones conexas. Directamente ligado a las fases del proyecto aparecen los procesos orientados al producto. Son aquellos que influirán en el producto del proyecto. Son aquellos procesos que influyen directamente en el producto del proyecto. Por otro lado, están los procesos de gestión de proyectos, aquellos que darán soporte a la planificación, control y evaluación del proyecto. Son aquellos procesos que podemos entender como parte de la burocracia proyectual, tienen influencia en el proyecto, pero no se verá de un modo. Los procesos orientados a la gestión y los orientados al producto se retroalimentan, tanto en datos como en funcionamiento. No es posible documentar el resultado de un prototipado sin que exista tal prototipo.

Según el PMBOK, los procesos orientados a la gestión del proyecto se clasifican en:

Los grupos de procesos se entrelazan a diferentes niveles; primero iterativamente dentro de cada fase, repitiendo el ciclo Planificación – Ejecución – Control: planificamos, ejecutamos y controlamos la conceptualización, también planificamos ejecutamos y controlamos la industrialización y cualquier otra fase. Posteriormente, fase tras fase, los Procesos de Cierre dan paso e incluso se solapan con los Procesos de Iniciación. Si vamos a escalas menores, a las subfases, sucederá exactamente lo mismo.

Esta estructura es muy fácil de extrapolar a un proyecto de diseño de producto. Es claro el paralelismo entre Planificación – Ejecución – Control y la iteración que existirá en las fases de de-brief, conceptualización, desarrollo. Simplemente hay que recordar de que Planificación, Ejecución y Control son grupos de procesos orientados a la gestión del proyecto. Se planificará, ejecutará y controlará el desarrollo del proyecto. Esto significará que se planificarán acciones enfocadas al de-brief, se ejecutarán las tareas desarrolladas en el plan y finalmente de controlarán los resultados y procesos empleados en el de-brief. Una vez más, lo que vincula un grupo de procesos con el siguiente es el tránsito de información de unos a otros.

Que un proceso no esté descrito en el planteamiento del proyecto no quiere decir que no se pueda hacer. Es necesaria una flexibilidad que permita incluir un testeo no previsto o la cotización de un servicio que inicialmente se iba a realizar inhouse.

La lista de procesos dentro de cada grupo descrita en la Guía del PMBOK es muy larga, con mucha información que puede ser interesante aunque debe tomarse con cierta perspectiva. El encargado de la planificación debe tener en cuenta que sobrecargar de burocracia el proyecto puede ser tan negativo como dejar que funcione sin control. Es una fuente de herramientas, pero no es necesario siempre emplearlas todas. También, en el extremo opuesto, algunos proyectos concretos pueden necesitar acciones concretas, a fin de fragmentar el trabajo y la información a tratar.

Todos los grupos están someramente explicados por su nombre y deberían ser fáciles de entender para diseñadores, dedicados a la práctica proyectual. Sin embargo, teniendo en mente la aplicación de estas técnicas al Diseño, puede ser interesante profundizar en la definición de los Procesos de iniciación.

Estos son los que permiten una relectura del proyecto y comprobar si estamos dentro del alcance. En equipos pequeños y compactos, con poca variabilidad en su composición puede ser suficiente con una recapitulación y puesta en común. Sin embargo, si en un cambio de fase tenemos una entrada de nuevo personal será muy importante mostrar cómo se ha llegado a este punto, hacer que los procesos de iniciación sean participativos y el ingeniero eléctrico que ha de dar soporte a los diseñadores llegados a la fase de preproducción comprenda no sólo los resultados si no también el camino transitado. Esto puede evitar trabajar sobre campo ya arado y tropezar varias veces con la misma piedra.

El bonus de hoy no guardaba relación con el texto, pero esta parte es tan árida como necesaria y sonreír un poco con Eugenio no está de más.

Llevo ya más de dos meses en Madrid, pero hasta ahora no me había asentado. Llegué para cambiar de aires y han cambiado; las cosas van bien e irán mejor. Vivo en Chamberí, con uno de mis mejores amigos y rodeado de más gente que suele alegrarme el día. Como hizo Sofía cuando me dio el lienzo que pintó para mi nueva habitación. Joy Division, Unknown pleasures: soy previsiblemente contentable.

Me ha gustado mucho el trabajo de Stephen Wilkes, para la revista Fortune, tanto este time lapse como las fotografías.

Wal-mart es la mayor compañía del mundo por volumen de facturación, y también el mayor empleador y minorista. Son los más grandes, pero sólo pueden sobrevivir siendo los más grandes, creciendo, acelerando. Cuando han tenido que pelear en un entorno en el que no lo eran, como en Alemania, se han retirado derrotados. Necesitan que el tráfico de norteamericanos de clase media-baja acudiendo a sus tiendas no pare. Ahora tienen un problema: la propia compañía achaca la caída en las ventas del último período de facturación – entre otros – al hecho de que sus clientes tienen problemas para pagar la gasolina para llegar a Wal-Mart.

Esa clase media-baja que han ayudado a colocar en una situación insostenible con deslocaciones de producción, una competencia insalvable para el pequeño comercio y una necesidad parcialmente inducida de consumo irresponsable puede llevarlos ahora a una situación insostenible. Sería un precioso ejemplo de equilibrio cósmico, podría llegar a sacar una sonrisa, si no fuera porque al final quien sufriría la hipotética quiebra no sería el tiburón que maneja la compañía desde Bentonville, si no el cajero a media jornada de Wichita.

Hoy, desde mi suprema ignorancia y soberbia (siempre bien ligadas) voy a postular mi primera afirmación lógica. Si la Primera Ley de Parkinson¹ afirma que:

El trabajo se expande hasta llenar el tiempo de que se dispone para su realización.

Yo propongo como primer corolario para esta ley:

Siendo t₀ el momento de inicio del trabajo, existirá un momento t_n a partir del cual la relación entre el tiempo transcurrido y tiempo necesario para terminar el trabajo se mostrará de manera asintótica, no siendo posible finalizar el trabajo jamás.

Esto es aplicable a proyectos de diseño, pero también a limpiezas, mudanzas o toma de decisiones en el campo de las compras de moda.

1. Las Tres Leyes de Parkinson fueron descritas por el historiador británico Cyril Northcote Parkinson en 1957 en su libro La Ley de Parkinson y otros estudios. Estas leyes, crítica irónica de la burocracia, están basadas no sólo en la sorna de su autor, si no en la observación del comportamiento del funcionariado del Servicio Civil Británico. Más info en Wikipedia.

Hoy va de generalidades.

Sección I, Estructura de la Gestión de Proyectos.
Capítulo 2, El contexto de la Gestión de Proyectos

Para un equipo de diseño el empleo de las técnicas de la gestión de proyectos debe aportar orden, certeza y seguridad. A mi modo de ver, junto a una clara y compartida definición del alcance, la planificación de las fases del proyecto es la mayor motivación para adoptar estas herramientas en el mundo del diseño. De esta manera se establece el ciclo de vida del proyecto, lo que es el comienzo no sólo para marcar tareas a lo largo del tiempo, si no además quién participará en ellas, los recursos necesarios o qué información debe ser comunicada en cada momento. Es la base.

La planificación de las fases debe entenderse como una estratificación: cada estrato se define por la interfase entre él y los que lo separan. Esta interfase será cada entrega, cada cambio de proceso, cada aprobación. Comúnmente, a este momento se le llama hito, y al cambio de estado del proyecto que hace que exista un hito se le llama prestación. No tiene sentido marcar un número exagerado de hitos en la planificación del ciclo de vida de un proyecto de diseño, esto puede afectar negativamente al trabajo de los diseñadores, con cambios de rumbo cuando se encuentran trabajando. El diseño es iterativo; y romper el proceso abductivo será contraproducente. Es importante ver resultados y que estos se presenten en tiempo. Pero no es tan importante que cada semana haya una revisión.

Los hitos no deben ser vistos únicamente como una meta volante a la que se ha llegado olvidando el camino recorrido y con la vista puesta en la siguiente meta. Deben servir como puntos de reflexión en los que se evalúe el proceso y el resultado, es el momento de hacerse preguntas. En caso de que sea necesario deben ser también puntos de inflexión en los que aplicar las medidas necesarias para que el proyecto llegue a buen fin.

Son pocos (o ninguno…) los proyectos desarrollados de una manera completamente lineal en los que una fase no comienza si no se ha terminado la anterior. Lo más normal es que las fases discurran con solapamientos o con tramos en paralelo. Los solapamientos tienen un cierto riesgo que hay que considerar, ya que permiten que comencemos la fase X sin haber terminado la Y. Seguro que necesitaremos información proveniente de Y para completar X, y si existen cambios cuando la segunda fase ya ha comenzado lo que parecía una manera de ganar tiempo puede convertirse en un derroche de esfuerzos. Además no conoceremos el resultado de la evaluación del proceso que tantos beneficios puede traer.

Un ejemplo muy sencillo. La fase III de un proyecto consiste en el modelado mecánico de un equipo de maquinaria industrial, la fase IV preparará los planos. Cuando las primeras piezas están modeladas puede ganarse tiempo haciendo sus planos. Sin embargo esto puede ser una pérdida de tiempo si en el ensamble del conjunto se encuentran problemas en una pieza y esta debe ser rediseñada. Avanzar empleando el fast tracking¹ puede hacernos ganar tiempo, pero el riesgo debe estar siempre bajo control.

Hay infinitas maneras de llamar a las fases, y no todos los proyectos tendrán las mismas. Es muy fácil justificar una estructura en un manual y venderla como la más adecuada, pero lo importante no es definir si la conceptualización es parte del anteproyecto, o si los testeos forman parte del desarrollo del producto. Lo importante es que la estructura esté interiorizada y sea muy fácil de entender. Esto es lo que ayudará a que seamos capaces de distinguir dónde comienza una fase y termina la siguiente, en qué tarea y con que requerimientos. Permitirá además flexibilizarla o adaptarla a distintos proyectos.

Cada manera de presentar el ciclo de vida del proyecto se va a adecuar a las necesidades de un tipo de proyecto concreto. Sin embargo, para el campo del diseño yo crearía un diagrama de Gantt² muy simple acompañado por una hoja de tareas. ¿Por qué? El diagrama de Gantt es un clásico, casi un estándar, cualquier programa de gestión de proyectos lo emplea como base, es muy fácil extraer la ruta crítica a partir de él y, sobre todo, es extremadamente fácil de leer. Es visual y es muy sencillo aprender su lenguaje. Si lo acompañamos de una hoja de tareas en texto exponiendo en qué consiste cada tarea, quién la desarrollará, la información necesaria como imput y la información exigida como output, cualquier miembro del equipo puede tener acceso a un montón de información de un modo muy sencillo y sin necesidad de recibir formación sobre el tema. Se trata de ganar tiempo y seguridad, no de perderlos.

Hay también muchas maneras de llamar a aquellos a los que afecta el proyecto: stakeholders, clientes, usuarios… Cada nombre tiene sus matices, pero no es mi objetivo teorizar sobre esto. Lo importante es ser consciente de qué personas, grupos y organizaciones se van a ver afectados por el proyecto y su resultado y cómo serán afectados. Posiblemente el punto más peliagudo sea controlar las expectativas de todos, mantenerlas dentro de la realidad y en la misma dirección. En mi humilde opinión, ante un conflicto de intereses el usuario debe ser el que salga ganando, así ganará el producto y finalmente el cliente. Esto es muy simple pero hace falta recordarlo.

La gestión de proyectos no es una atalaya desde la que se controle el desarrollo del diseño, está en contacto y bajo la influencia de muchas otras actividades. El PMBOK describe las características de aquel que debe tener las responsabilidades de PM dentro del equipo de diseño: liderazgo, capacidad de comunicación, habilidades de negociación y solución de problemas, tener un espíritu inspirador… Dejando a un lado las apreciaciones personales, todas estas características son ciertas y deseadas, pero en la mayor parte de los casos, lamentablemente, el gestor de proyectos será el diseñador con más años o uno de los socios de la empresa, sin tener en cuenta que cumpla con estos requerimientos o que tenga conocimientos sobre gestión de proyectos. Esto es algo que debe cambiar.

Bonus: Video del Maestro Herbert von Karajan en un ensayo. Muchas veces he oído que el project manager tiene que ser un director de orquesta, capaz de tocar todos los instrumentos, que debe saberse la partitura de memoria y motivar a todos los los miembros de la orquesta. Creo que es bueno quitar a todo esto un poco (bastante) de importancia. Por favor, que cada Karajan que nazca se convierta en director de orquesta, que no se le ocurra gestionar proyectos.

Esta entrada forma parte de un conjunto de anotaciones sobre las técnicas y herramientas descritas en el PMBOK del PMI para la gestión de proyectos, enfocadas a la gestión de proyectos de diseño.

1. Fast tracking es el nombre que se da a los solapamientos en fases o tareas. Consiste en poner a trabajar en paralalo procesos que en otro caso discurrían uno tras otro, siendo los outputs del primero los imputs del segundo.
2. El diagrama de Gantt es una representación gráfica sobre unos ejes ortogonales de las tareas de un proyecto frente al tiempo y de sus interacciones.

Me voy de Barcelona. Es un cambio de aires que necesito y confío que me vendrá muy bien. No quiero hacer de esta entrada una recapitulación de nostalgias por llegar – que llegarán – pero sí quiero decir que los últimos veinte meses han sido increíbles. Me voy para que los próximos también lo sean. Gracias a todos, gracias Barcelona.

Rompo con la norma en este post emo y, aunque sea de espaldas, el de la lomografía de la entrada soy yo. La sacó Dani en una buena tarde que pasé con él y con Marta, quien confío que llore con Christian y conmigo cuando finalmente me vaya.

Al turrón

Sección I, Estructura de la Gestión de Proyectos.
Capítulo 1, Introducción

El PMBOK comienza definiendo qué es un proyecto, y lo hace contraponiéndolo a la otra manera de ejecutar el trabajo, las operaciones. Simplificando, los proyectos se desarrollarán una vez, durante un tiempo determinado, mientras que las operaciones se desarrollan repetidas veces a lo largo del tiempo. La búsqueda de clientes por parte del equipo comercial de un estudio puede ser una operación, desarrollar un nuevo producto para uno de ellos un proyecto: existirá un único resultado – un modelo 3D, un fichero .ai, unos planos – y se desarrollará a lo largo de un período de tiempo limitado.

Profundizo un poco más en la idea de temporal. Esto significa que todo proyecto tendrá un inicio, un desarrollo y un final. ¿Cuándo llega este final? La respuesta parece sencilla: cuando se entregue al cliente. Esto no es necesariamente así, porque habrá casos en que se detecte la imposibilidad de resolver el problema o el proyecto se enfríe. Esta última es la peor de las situaciones, ya que deja el proyecto en el limbo y seguramente una relación enrarecida entre el equipo de diseño y el cliente. La temporalidad se refiere sólo al proyecto, no al producto. A Dieter Rams le tomó un tiempo determinado crear el Shelving System 606, pero hoy día Vitsœ sigue vendiéndolo y el público apreciándolo.

Es muy complicado delimitar más qué es un proyecto genéricamente, ya que su estructura, duración, fuerza de trabajo o forma legal son totalmente variables, y no harán otra cosa que ajustarse a las necesidades en cada caso. Muchas veces los proyectos forman parte de una jerarquía estratégica: programa > proyecto > subproyecto. Esto puede afectar al equipo de diseño de dos maneras. La primera es si tiene la suerte de influir en el programa, afectando la línea estratégica de la empresa. La segunda, quizá menos afortunada, es cuando tiene que trabajar bajo los requerimientos de un programa definido por otros que pueda encorsetar su trabajo.

El concepto probablemente más interesante a introducir en este punto es el de alcance. El alcance es aquello que queremos conseguir, y en ocasiones incluso cómo queremos conseguirlo. Para el mundo del diseño debemos contemplar tanto el alcance del proyecto como el alcance del producto. El alcance del proyecto es sencillamente qué objetivo tiene el proyecto: “un conjunto de archivos IGES con la carcasa de una aspiradora de mano e indicaciones previas para la inyección en plástico“. Debe definirse desde el principio, puede tener variaciones, pero estas deben ser más depuraciones que evoluciones. Debe mantenerse bajo control y ser reconocido por diseñador y cliente.

El alcance del producto es un concepto completamente distinto. Es el resultado, no el objetivo. La respuesta al problema “carcasa de aspiradora de mano en formato IGES” puede tener infinitas soluciones posibles. Si el alcance del proyecto debe estar controlado dentro de unos límites, el alcance del producto tiene una sanísima incerteza. Por muy planificado que esté el proceso, por muchos exámenes, modelos, datos y experiencias pasadas que se hayan analizado, las soluciones se conseguirán de un modo más o menos iterativo, más o menos progresivo. Nos acercaremos con el tiempo y el trabajo. El propio avance del proyecto lo definirá más y más. La gestión de proyectos aporta certezas desde el momento del planteamiento, pero esta mayor seguridad no borra las incertidumbres naturales del diseño. Es muy sencillo: al diseñar se crea algo nuevo, y por tanto algo con aspectos desconocidos que no es posible controlar por completo. El resultado es predecible, pero no anticipable.

Algo a tener en cuenta: no siempre se puede culpar al cliente de los cambios en el alcance. Los diseñadores también se alejan del brief en busca de la innovación, de conseguir un mejor producto o mayor repercusión. Además las responsabilidades en un proyecto son compartidas. Siempre. Incluso cuando el cliente intenta salirse del camino planteado es responsabilidad de quien gestione el proyecto desde el equipo de diseño recordarle la ruta.

Los campos de intersección entre las responsabilidades funcionales de la gestión tradicional y la gestión de proyectos son múltiples, yendo desde la selección de personal a la gestión de la información. Los equipos de diseño, sobre todo aquellas estructuras más reducidas, están muy acostumbrados a manejar muchas responsabilidades ajenas al diseño, a realizar labores comerciales o de comunicación y suelen ser muy flexibles.

Creo que es muy interesante aclarar que las técnicas que describe el PMBOK o cualquier otra filosofía de gestión de proyectos no son herramientas de productividad personal del estilo de GTD. Estas herramientas, muy populares actualmente, ayudan a ser más productivo en el día a día, a sentirse mejor con el trabajo realizado, a mantener el estrés bajo, y estoy seguro de que son complementarios, pero en ningún caso sustitutivos. Estas herramientas tienen un campo de actuación distinto que se extiende hasta las operaciones, pero no sirven para planificar el diseño de una nueva lámpara aunque ayuden a que aquellos encargados de modelar sus piezas a cumplir con las tareas asignadas dentro de una fase concreta en el tiempo y forma debidos.

Bonus: El vídeo de 2′ 52” que acompaña a esta entrada es un triple bonus. Se trata de Mark Adams, Director de Vitsœ, hablando sobre la atemporalidad del resultado de los proyectos temporales que desarrollan. En cristiano, de la sana pervivencia de sus productos. Solo una cita, que daría para muchas entradas:

The concept is to reuse your furniture… We see recycling as a defeat.

Esta entrada forma parte de un conjunto de anotaciones sobre las técnicas y herramientas descritas en el PMBOK del PMI para la gestión de proyectos, enfocadas a la gestión de proyectos de diseño.

He leído últimamente a varios desarrolladores de aplicaciones para el iPad hablar sobre los excesos de Apple a la hora de intentar llevar a su interfaz metáforas visuales del mundo real creando un 3D falsamente realista No es nada nuevo, pero creo que hay un salto entre el uso de un disco de 3 1/2″ como icono de guardado y la estantería de Delicious Library. Ahora parece que se ha exagerado con las directrices que da Apple para la creación de interfaces para el iPad, directrices que son ya tendencia y pronto serán norma en el mercado.

Me vienen varias razones a la cabeza por las que Apple puede haber hecho esto. Quizá sea la manera de tradicionalizar un aparato rompedor. Por hacerlo más mono. Por demostrar una atención al detalle llevada al extremo. O por crear una nueva línea visual que haga viejo lo existente y genere necesidad en el mercado. Habrá un poco de todo, pero parece que la razón ha sido la intención de hacerlo más intuitivo, más reconocible. Esto se hace difícil de justificar. Como ejemplo, algo que expone Information Architects: no es fácil entender cuánto de intuitivo tiene hacer scroll vertical en una página que imita papel y se navega lateralmente pasando páginas como un libro.

Más allá de esto, formalmente muestra la tendencia a un sobrediseño clasicista en el mundo digital, una especie de tecno-neo-barroco-raro, muchas veces prescindible y poco adecuado. Hay miles de ejemplos y la frontera entre lo molón y el kitsch está muy difusa.

Sin embargo no dudo de que esto no está limitando la posibilidad de crear un lenguaje nacido del mundo digital, eso es imposible. Simplemente forma parte del mainstream más mainstream. Gustará más o menos, pero se encuentra influido por todo lo que lo rodea y esto incluye las tendencias más clasicistas y reaccionarias.

El video es de CODECO, uno de sus iconos materializados, un disco de 3 1/2″ en punto de cruz sobre una camiseta. Es el proceso revertido.

Bonus: El corrector ortográfico de Mac OS cambia iPad por piad.

British architect Kenneth Allinson discussed in his book Getting There by Design factors that affect the perceived success of a project. (…) They are:

1. Coordination and human relations
2. Budget, schedule, and technical performance
3. Project conceptual difficulties
4. Project organizational structure and management controls
5. Project budgetary constraints
6. Project importance and public exposure
7. Team capabilities

Surprising as it may sound, Baker’s finding show that factor one, coordination and human relations was significantly the most important of the seven: “Co-ordination and relations: Team spirit, unity, human relations skills, enthusiasms, participation, etc. This factor is about four times as important as the seventh factor and about 50% more important than the second factor”.

Project Management fot Design Professionals
William G. Ramroth J

Traduciendo libremente:

El arquitecto británico Kenneth Allinson trata en su libro Getting There by Design los factores que afectan al éxito percibido de un proyecto. Estos son:

1. Coordinación y relaciones humanas
2. Presupuesto, plazos y ejecución técnica
3. Dificultades conceptuales del proyecto
4. Control de la gestión y estructura organizativa del proyecto
5. Limitaciones presupuestarias del proyecto
6. Importancia y relevancia del proyecto
7. Capacidades del equipo

Por muy sorprendente que parezca, las conclusiones de Baker muestran que el primer factor, coordinación y relaciones humanas era de largo el más importante de los siete: “Coordinación y relaciones: Espíritu de equipo, unidad, habilidades sociales, entusiasmo, participación, etc. Este factor es hasta cuatro veces más importante que el último y un 50% más importante que el segundo”.

Las sensaciones derivadas de las relaciones sociales son hasta un 50% más importantes para el éxito percibido de un proyecto que su ejecución, el cumplimiento de los plazos y el presupuesto. Puede parecer increíble, pero si confiamos en los estudios es la realidad. La realidad en el mundo anglosajón, ¿cómo estará el tema por aquí, entre los pasionales mediterráneos?

Sabiendo lo importantísima que es la confianza, y olvidando lo desesperanzador que puede ser para algunos que el reconocimiento de su trabajo dependa de sus habilidades sociales, la mejor conclusión que se debe sacar de esto es que tener un buen cliente es tener un buen proyecto.