Frecuentregables

Los entregables (deliverables), como concreción de los hitos en proyectos tecnológicos, son huesos duros de roer, tanto para el que los emite y desea cobrarlos, como para el que los contrató y tiene que validarlos. Si los entregables son piezas de código no se genera tanta tensión, pues, salvo contadas y honrosas excepciones, se espera que el software entregado funcione, por lo que con tal prueba (y con independencia de la bondad de los procedimientos, unitarios o funcionales, que corroboren este “buen comportamiento”) se libera la ansiedad entre contratante y contratado, que viene a ser sustituida por otra, tal vez más agobiante, relacionada con los plazos. Pero, ¡ay!, si los entregables son documentos, entonces… ¡que San Tito nos asista, a todos!

Para intentar lidiar con esta inquietud (“desinquietud”, que diría mi madre) los documentos de un proyecto tecnológico/software (especificaciones, requisitos, escenarios, análisis, diseños, etc.) han sido sometidos históricamente a distintos enfoques asociados a su evolución respecto del ciclo de vida total de los proyectos mismos. Tales enfoques, esencialmente pasados por agua, se pueden resumir en los siguientes:

Cascada [entregables rígidos]: cada fase pre-establecida genera documentos que se asemejan a cubos de platino-iridio (incluso en el precio), pues pueden ir cayendo por la cascada, entre piedras y fases, y no modificarse en absoluto.  Resulta ideal para los contratados, pues siempre se puede elaborar un documento correcto cuyo alcance no cubra su presupuesto, pero el contratante nunca podrá validar que está completo ni que, por tanto, se ajusta a sus necesidades.

Fuente [entregables flexibles]: los documentos son bien rocas bien trozos suficientemente sobados de plastilina, con cierta intención de forma inicial, y se espera que limen sus aristas y adquieran su forma de cantos rodados tirándolos muchas veces arriba y abajo, contra el suelo, contra ellos mismos. Se trata de un modelo similar al de la cascada, a la que se ha añadido un costoso procedimiento para subir las piedras y lanzarlas de nuevo, desde el principio o desde cualquier parte de la cascada. Para los consultores, tal costo adicional (de subida) debiera asumirlo el cliente, así que se parapetan en una política clara: la cascada es suya y las piedras son del cliente una vez que las aprueba, así que si hay que realizar cualquier esfuerzo posterior… ¡que lo pague el contratante, pues se deberá a su propio error de apreciación! Así que el resultado final de estas técnicas, asociadas a OORA/OOA/OOD suele ser… ¡el mismo que en el enfoque de cascada! Pero, eso sí, se admiten pequeños cambios en los documentos que no supongan costes significativos para el contratado.

Granizo [micro-entregables rígidos]: como consecuencia del esquema intermedio anterior, los clientes deciden limitar su riesgo troceando las piedras grandes en gravilla, que podrá ser así controlada mejor y validada con mayor seguridad: tal es lo que proponen los Métodos Ágiles. El problema es que, por tratarse de documentos tan cortos (micro-escenarios de negocio, objetivos concretos, etc.), se establece de antemano que una vez aprobados cualquier cambio supondrá… ¡un nuevo documento! Así que no hace falta motor hidráulico para devolver las piedrecitas a la cascada: se trata de granizo que cae del cielo, sólo desde arriba hacia abajo. Y, usualmente, causa parecido daño.

Al final uno no sabe qué es peor (o mejor); sobre todo en las AAPP, que por sus características de contratación tienen que anticipar los métodos en los que enmarcar los entregables. ¿Hay solución? ¡Pues claro! El problema reside, precisamente, en que los anteriores esquemas se centran en el marco metódico de composición, entrega y validación de los documentos, en lugar de centrarse en su generación práctica (no metódica); así que si cambiamos el foco de atención y lo dirigimos hacia objetivos prácticos, tal problema deja, en muchas casos, de tener sentido.

Lo que aquí propugno es la imposición de “frecuentregables”: es decir, de entregas frecuentes de documentación, ¡pero no de documentos!, configurando así una suerte de [micro-entregables flexibles]. Pasemos, sin más, al lado luminoso de La Fuerza.

El mayor problema de los documentos es que una vez terminados de redactar difícilmente pueden ser reformulados o cambiados esencialmente –al menos por sus autores–, sino tan sólo levemente modificados o matizados. Por otro lado, para el revisor, leer un documento implica asumir paulatinamente su estructura, de forma que finalmente se introducen correcciones pequeñas, que el consultor solventa y vuelve a presentar, de forma que a cada corrección resuelta se torna más difícil echar atrás un documento. Por fin, la tarea de revisión se realiza a golpes, sobre mucho trabajo anterior, sobre muchas páginas y bajo demasiado riesgo. Para evitar esto hay que forzar a que el contratante tenga acceso, en todo momento, a cualquier texto redactado por el contratado, de manera que cada día se cuente con el diferencial de lo hecho el día anterior (la funcionalidad de revisión de MS Word y similares –como la línea base de los ficheros MS Project– es fantástica a este fin); y esto sólo se consigue cuando no se trabaja con un fichero en local que se “sube” a un servidor en un momento dado (o, peor, se envía por correo electrónico): se consigue cuando el fichero está, directamente, en un servidor de ficheros (wiki, MS Sharepoint, MS Groove, etc.). En definitiva, se deben imponer las siguientes normas:

·         Una versión de trabajo de un documento es, simplemente, la que supone cualquier modificación respecto del documento previo. Una versión estable es aquella que, de entre todas las de un documento, se ha calificado así en un momento dado y sirve para asegurar emocional y presupuestariamente su uso como referencia temporal de otros documentos y trabajos. Un hito será una versión estable solo-lectura.

·         Las versiones de trabajo siempre residirán en el servidor, y se actualizarán directamente allí ante cualquier cambio, por pequeño que sea. Si las versiones se aportan sin que haya control de cambios (bien por el programa en sí, como MS Word, bien por el sistema de soporte –por ejemplo, un wiki), se rechazarán sin más explicaciones (hacen perder el tiempo al revisor).

·         Si se aportan versiones cuya diferencia respecto de los ficheros anteriores sea excesiva (muchas páginas), se considerará que el contratado no ha “colaborado ofimáticamente” con el contratante, y se rechazará de plano el documento completo, que deberá ser re-redactado mediante pequeñas adiciones, cada una de ellas sujeta a revisión.

·         Las carátulas, hojas de aprobación, dibujitos, etc. no tienen mucho sentido en este esquema, así que, en lo posible, se relegarán a versiones estables e hitos.

·         La propiedad de los documentos es siempre del contratante, por lo que, con independencia de su autoría, autoriza su modificación por cualquier integrante del proyecto, sin restricciones (asumiendo que se cuenta con un sistema de versionamiento razonable).

·         No se eliminará ningún documento en ningún momento, bajo ninguna circunstancia. Tan sólo se versionarán, incluso mediante un documento intencionadamente en blanco, con la mención “eliminado” y una explicación de la causa de esta acción.

·         No se darán aprobaciones expresas sobre versiones de trabajo: tan sólo modificaciones o vetos.

De esta forma se eliminan muchas de las dudas y quejas relacionadas con la elaboración de documentos: las copias desde “trabajos anteriores” (el celebérrimo “copy-n-paste” de las consultoras de prestigio) se tornan más costosas que su elaboración desde cero (es ciertamente difícil simular que se está redactando un documento que ya está redactado; y, además, en cada adición se puede producir un cambio de rumbo, sin lastre moral o presupuestario para el revisor); el ajuste, por otro lado, con la situación concreta a modelar (el objeto de la contratación) podrá ser revisado mejor así; adicionalmente, y sin necesidad de controles presenciales, se podrá controlar mejor la evolución del proyecto, simplemente estimando el diferencial de trabajo realizado de un día a otro, y no respecto del total del proyecto; y, por último, el contratante dispondrá con mayores eficacia y eficiencia de su tiempo, adaptando las revisiones a su agenda de tareas.

La idea es muy simple: ante alguien que te debe un millón de euros y no te paga porque prefiere pagarte de golpe (o en dos o tres golpes), uno confía más en el que te paga 100€ al día, en tanto sobrevienen “los golpes”. Y aquí, como saben contratantes y contratados, también se trata de euros.

La Restauración de las AAPP

En su interesante libro “Cómo quiero que me sirvan el vino”, Arturo Pardos dibuja una curiosa situación de colisión de propiedad y voluntades, que en su descripción parece una paradoja de dimensiones cósmicas: al servir el vino en un restaurante el sumiller sostiene la botella, que no es suya, (pues es del cliente, que por lo tanto puede rechazarla o cambiarla) y lo acerca a la copa del cliente, que no es suya sino del restaurante (por lo que el servicio de éste puede sustituirla cuando quiera, trasegando el vino, claro), y en esta fusión entre la posesión y la tenencia se encuentra el placer del servicio… del vino. Y he notado que esta situación es “curiosa” no porque sea rara, sino porque hasta leer esta parte yo no había sido consciente de que en los restaurantes, a diferencia de los supermercados, el vino es de uno antes de pagarlo, porque se asume un contrato y un buen fin; y también me di cuenta de que los comensales no pueden opinar sobre la vajilla (o sobre la decoración del comedor), sino tan sólo sobre su limpieza.

En la Administración Pública (AP) ocurre algo similar, y muchas veces sus actores operan (igual que los comensales piden platos o los camareros sirven comandas) sin ser conscientes de la colisión entre propiedad y voluntad. Y es que en las AAPP también se da un contrato que presume de la buena voluntad de las partes y que trastoca la propiedad de los hitos y resultados de los contratos de servicios; y especialmente de los de servicios tecnológicos y, madre mía, de software.

Un viejo lugar común establece que hay dos tipos de presupuestos: los americanos (aquellos en los que se acepta cualquier proyección razonable, pero luego se discuten con fruición las desviaciones, por pequeñas que sean) y los alemanes (los que necesitan un largo proceso de aprobación y consenso para su planificación básica, y en la que, por mor de tal cuidado, las desviaciones no pueden ser imputables al proponente, sino al aceptante). Pues bien, la mayoría de los contratos con las AAPP son… ¡germanos! Los procesos concursales son tan exhaustivos y se apoyan de tal manera en la oferta/presupuesto de los trabajos, que cualquier desviación futura sólo podrá achacarse, salvo raros casos de negligencia demostrable, a la propia Administración. De esta manera las AAPP se suelen encontrar en la misma tesitura que el comensal que siente que tal vez debiera devolver un vino, pero que no está seguro de si realmente está encorchado, demasiado evolucionado… ¡o no! Y es que el sumiller (se supone que) sabe más, así que, en el colmo de la inseguridad, algunos preguntan: ¿pero de verdad este software tiene que funcionar así? Y el mal consultor/socio (perdón, sumiller), en lugar de atender al gusto del comensal, y atendiendo al suyo o al del restaurante/consultoría, dice algo así como… “yo lo encuentro normal, en sus parámetros; pero si de todas formas el señor –con cierto retintín– quiere que cambiemos…”; y el comensal (la Administración) entonces suele decidir que, bueno, será que ése no es su negocio, que por eso han acudido a una firma consultora cara y de prestigio (esto, errrr…. perdón: a un restaurante de campanillas). Y es que en este caso las grandes consultoras de prestigio son como los restaurantes Michelin: uno no espera un servicio más confortable, sino más opciones; y, en contrapartida, uno (el mismo uno) se encuentra con menos para reclamar.

Recapitulemos: una AP decide acudir a una consultora (restaurante), y ésta le procura un montón de métodos y procedimientos (la vajilla), pues para eso tienen mucha mucha experiencia… en servir vajillas. La AP eligió así por las múltiples opciones que el consultor parecía ofrecer (amplia bodega, sumilleres de prestigio, ayudantes/becarios controlados), pero al Jefe de Sala (el socio) sólo le ven en los momentos críticamente triviales (bienvenida, saludos, despedida), de forma que el resto del tiempo son atendidos por postulantes/becarios (supuestamente bien vigilados –a distancia, usualmente– por el socio/restaurador). A la AP no le gustan las incertidumbres con el precio, así que ha ido allí por el menú degustación (tras comparar, en concurso, varios de ellos, en varios restaurantes posibles)… ¡pero el vino no suele estar incluido! El mensaje básico del restaurante es: “nos comprometemos a servirles platos cuyos ingredientes están relacionados con los que aparece en nuestros procedimientos… hemmm, esto… en nuestra carta; el vino (el maridaje, la completa satisfacción) lo pueden elegir ustedes y se cobra aparte”.

Así que los consultores/restauradores suelen entregar al principio de la comida un papelito con los platos a degustar (una suerte de MS Project, vamos), en papel de gran gramaje y atrevidos motivos; y también dejan caer en la mesa el libro de vinos/opciones. El menú no tiene réplica: el comensal aceptó el contrato implícito y puede dejar de comer, pero difícilmente quejarse, aunque no le satisfaga: fue eso lo que contrató, influido típicamente por la fama del servicio que, de todas todas, ha de pagarse al final. Y si uno se hace a la idea de a dónde ha ido a parar… bueno, es cuestión de acostumbrarse. Pero… ¿y la satisfacción de la comida completa? ¿Y el maridaje? ¿Y la integración del menú de consultoría con lo que uno realmente desea: una comida inolvidable? ¡Ay! Los consultores, en sus contratos con las AAPP, sólo ponen la vajilla; el vino es cosa del contratante.

Tras algunos titubeos y una elección primera, el sumiller (Jefe de Proyecto) se acerca con el vino y enseña la botella: “¿Es éste?”, pregunta, siquiera con la mirada. Y el comensal asiente: “Sí, sí”, a veces sin reparar en la añada e incluso sabiendo que la botella no le dice nada; que él lo que quiere es el vino que está en su interior, así que no puede, nunca puede, prejuzgar y asiente de nuevo con la cabeza. Pero llega el momento de la colisión: el Jefe de Proyecto acerca el vino/software elegido (que es propiedad del cliente: se ha comprometido a pagarlo) a la vajilla… ¡que es suya! Y en esos momentos (estamos al principio de la comida/proyecto) el cliente se siente más fuerte: quizás puede hasta decir que el vino no le parece adecuado o que no está en condiciones. No importa: el camarero consulta con el socio y, sin mediar palabra adicional, cambian el vino… ¡que resulta sospechosamente parecido al primero! Y es que, claro, el comensal, cuando decide cambiar, se justifica en el vino, no en lo inapropiado de su elección, así que le traen “otra” botella del mismo vino. Pero ahora ya no es como al principio: al comensal se le hace difícil devolver la siguiente botella (y aún más si es la tercera). La vajilla, la cristalería, el aplomo del servicio y el elevado precio del menú parecen garantizar que no se pueden dar tantos errores. Y, además… ¡qué demonios! ¡Si no sale bien… no volveremos! (piensan, ingenuamente, los clientes).

El esquema es sencillo: vamos a pagar por un menú que deberíamos conocer (estaba en la oferta), y que nos reiteran antes de empezar el servicio; y del quizás podamos cambiar algún plato (no siempre). Cada servicio se acepta o no (entregables e hitos certificados), pero no se puede alegar que no se conocía el menú, y, además, cuando se ha aceptado el primer plato (el primer hito), al comensal le resulta mucho más difícil deshacer o rechazar el resto del contrato y, sobre todo, de los platos. Si queremos algo fuera del menú o de la vajilla, nos costará alrededor de un 20% sobre el total presupuestado; y si queremos satisfacción… ¡Ay! Si queremos satisfacción deberíamos haberlo planteado antes de sentarnos.

¡Cómo añoramos comer en casa tras varios días en restaurantes caros! ¡Cómo echamos de menos a nuestros propios becarios caseros, más cercanos quizás! ¡Cuánto agradecemos la cotidianeidad del gusto, del saber que lo que decidimos se ampara tan sólo en nuestras necesidades, y no en el entorno que, voluntariamente, nos alejó del hogar! ¿La solución a tantas cuitas? Bueno, existen soluciones parciales que mitigan los síntomas: el corkage, el catering, etc. Una solución más global es la propugnada por L’Atelier. Y, sin duda, la mejor es la que se da en los mejores bares de sushi en Japón: se insta al maestro de sushi a que adivine nuestro gusto, a su gusto, sin mediar explicaciones: se trata de un acercamiento incremental en el que el maestro nos tienta con delicias y observa gravemente nuestras reacciones para determinar rápidamente una dirección, un proyecto, una línea exitosa de servicio que demuestre y exhiba por qué él es un maestro de sushi y nosotros meros comensales. Este enfoque de continua revisión (en Xtreme Programming, Kent Beck ponía el ejemplo de que incluso en una carretera recta, para mantener la dirección recta teníamos que modificar continuamente la dirección al volante, mediante pequeñas correcciones) es la mejor solución para el binomio (AP, Consultoría), así que merece un artículo aparte.

“Hay otros mundos, pero están en éste” (Paul Eluard); “Hay otros servicios, pero están en ti” (conclusión apócrifa).

(c) Ricardo Devis

Payasos Informáticos

“He contratado a un equipo de payasos y…”, “Pero… ¿qué estás haciendo, so payaso?”, y “¿Qué pintan aquí estos payasos?” son frases corrientes… ¡en cualquier proyecto software! De hecho esta correspondencia (informáticos = payasos) está tan asumida y extendida (“¡Ay, es que son tantos…!”) que sorprende que no exista un cuerpo doctrinal sobre el que basar estrategias, tácticas y números circenses de mayor calado. Pero vayamos primero a los antecedentes.

El problema básico de los informáticos (al menos en su devenir profesional) siempre ha sido su carencia de identidad, en cualquiera de sus roles adoptados: “programador” se ha asimilado a “persona sin vida social” (y, por tanto, con limitadas capacidades de comunicación); “analista” a “consultor”; “consultor” a “vendedor”; “analista-programador” a “vendedor sin vida social”; “diseñador” a “mitad vendedor, mitad programador”; y, en fin, “ingeniero-analista-programador” se ha asociado, típicamente, a “semoviente con ciertas capacidades táctiles”. Esta confusión ha complicado enormemente la gestión interna de los equipos informáticos, y su presentación externa (“¡Hola, soy Isabel Morcillo, analista-ingeniera de diseño de programación. Y me odio por esto!”).

Por otro lado, en la ingeniería del software se están aplicando desde hace años exitosos esquemas de estudio del comportamiento de los usuarios basados en técnicas de Diseño de Interacción y de la segmentación de tales usuarios en “personas” (es decir, personajes prototípicos del análisis), lo que facilita su trato, comprensión y posible maltrato posterior una vez armados con el software. Así que… ¿por qué no aprovechar las técnicas del Diseño de Interacción para tratar con los integrantes de un equipo de desarrollo software? Como sostenía Recesvinto Pérez… “si los payasos pueden saludarse en un congreso e identificarse rápidamente (“Hola, yo soy un augusto”, “¿Qué tal? Yo ejerzo de payaso blanco, pero estoy pensando en pasarme a trombo, porque cargo con demasiada presión”)… ¿por qué no habrían de hacer lo mismo los informáticos en el ámbito reducido de un proyecto?”.

Así que vayamos a la correspondencia: en cada equipo software habrá que asignar los siguientes roles, lo que se podrá conseguir muy rápidamente, pues los comportamientos están bien asentados:

• Jefe de Pista: es el que hacer desfilar a los demás y los presenta, saluda al público, emite sonidos guturales y muchas veces uno piensa que en realidad es un impostor. En nuestro caso suele ser un socio de consultoría.
• Payaso Blanco: es el payaso elegante, hierático y de comicidad pasiva (le ocurren cosas, pero no hace casi nada). Se equipara con el Jefe del Proyecto.
• Augusto: es el payaso tosco y burlón, le gusta la anarquía y le ocasiona muchos quebraderos de cabeza al payaso blanco; además hace reír mucho al público con sus ocurrencias ridículas. Su figura se asocia, inequívocamente, a la de “programador listo”.
• Trombo (o segundo Augusto): se trata de un payaso risible, pero sin los méritos del augusto para provocar situaciones ridículas de valía, así que es un apoyo del primer augusto para procurar quebraderos de cabeza al payaso blanco. En la práctica es un programador del montón.
• Excéntrico: es un augusto listo, de la misma catadura que un pueblerino sabio, como Josep Pla; así que sabe que hace reír al público, pero mantiene más dignidad que el augusto clásico en su pose y en su tozudez. Se asimila a un diseñador Web.
• Vagabundo: es un augusto solitario, sin relaciones sociales y que suele dar risa porque da pena. Esta figura se suele asociar a un analista software.
• Mimo: no habla, pero parece dotado de buenas cualidades físicas y de movimiento. Suele encargarse de la intendencia (instalación de software, redes, café, etc.) en los proyectos.

Bien: con esto ya estamos preparados para comunicarnos mejor entre proyectos. Así, si un colega me cuenta… “tengo un payaso casi-blanco, 2 augustos en liza, un excéntrico a ratos, dos vagabundos peleones, diez trombos[-ados] y ningún mimo”… inmediatamente uno se hace a la idea de cómo será el proyecto. Pero, claro, esto no dice nada del resultado, porque el resultado de los proyectos siempre es… ¡algo! Y es que… ¡Ay! Lo malo de la informática es que el software, al final, siempre funciona :-(.

P.S.: Tengo que agradecer la inspiración de este artículo, por orden, a Recesvinto Pérez, a ClownPlanet y a Michel Tournier.

(c) Ricardo Devis

Las Excepciones del Diseño

¿Se han fijado en la fachada de las tiendas de juguetes Imaginarium? Tienen dos puertas: una grande (para las personas mayores) y otra pequeñita (para los niños). Desde el punto de vista informático… ¡esto es una barbaridad! Si el niño cabe por la puerta grande, ¿por qué esforzarse en fabricar una pequeñita, por la que, encima, no cabe un adulto? Un informático diría: si el caso “puerta grande” comprende al caso “puerta pequeña”… ¡sólo hay un caso! Y obvian que a los niños les encanta su puerta pequeña, que se ha convertido en una suerte de marca visual física para la marca Imaginarium, lo que permite que niños de todo el mundo identifiquen rápidamente sus tiendas; obvian que a los niños adoran disponer de una puerta a su medida… precisamente por la que no pueden pasar sus acompañantes “viejos”. Se trata de una interpretación del comportamiento plausible, de los deseos de los usuarios (y grandes prescriptores, en este caso). Por otro lado, ¿no pasa igual con las compuertas para gatos que vemos en las puertas de las películas americanas (sobre todo :))? Aquí prima la utilidad, aunque sigue siendo cierto que el gato cabría perfectamente por la puerta para humanos. ¿De dónde viene, pues esta discrepancia informática? Opino que se trata de la conjunción de dos comportamientos demasiado bien asentados en la composición software y, por tanto, en su proceso constructivo típico:

Generalización Culpable: se recogen elementos discretos, después de caras entrevistas, laboriosas sesiones de análisis y sesudas comparaciones sobre cómo acoplar lo que hemos visto a lo que ya sabíamos que posiblemente íbamos a dar como resultado (la experiencia no es que sea un valor aquí: usualmente es el único valor). Así que tras haber segmentado los requisitos en unidades manejables, se aúnan de nuevo en una solución global… ¡que los contemple a todos! Es decir: se maneja la misma ponderación para todos los requisitos, que bien están incluidos en una solución plausible (para el analista), bien son rechazados. Pero no hay excepciones. Este comportamiento se basa en un lema intuitivo, asumido sin reparos en toda la industria informática… ¡y absolutamente equivocado!: “Cuesta menos diseñar una interfaz común que diseñar una interfaz (y sus procesos asociados) para cada caso”. Y, claro, lo que importa no es el coste, sino la relación coste-beneficio, que simplemente no se considera, por principio, en los análisis típicos informáticos.

Personalización Forzosa: parece que, una vez conseguido el objetivo de modelar todas las situaciones con un esquema básico común, los diseñadores caen en la cuenta de que ese modelo, monstruosamente grande y genérico, no es que no sea reusable: ¡Es que ni siquiera es utilizable! Así que urge reducir el caudal de información hasta que alcance niveles asumibles por las personas (los destinatarios originales del esfuerzo de modelado, que pasaron rápidamente a ser “usuarios elásticos”, y ahora, en el momento de las pruebas, vuelven a ser parcialmente importantes), para lo que se utilizan tres diferentes técnicas de aplicación progresiva: la búsqueda, la suscripción y la re-decoración:

• Búsqueda: se dota al usuario con un potente (?!) motor de búsqueda, de forma que, sin conocer la profundidad o estructura de la información, encuentre lo que necesita, que suele ser muy poco de lo dispuesto.
• Suscripción: se insta a los usuarios a que señalen aquellos temas que les interesen, para mostrárselos. En realidad se trata de una versión remozada de la “búsqueda” anterior, en la que los resultados van hacia el usuario sin que éste tenga que requerirlos en cada ocasión: consiste, en la práctica, en guardar ciertos términos de búsqueda y que el ordenador se encargue de buscarlos y pasar al usuario los resultados instantáneamente o no, en razón de cuando éste quiera recibirlos.
• Re-decoración: como finalmente un usuario puede contar con demasiadas suscripciones, ¿por qué no permitirle elegir entre ellas para que sean mostradas de forma más o menos prominente, en sitios también determinados por su futuro lector? Así que se provee al usuario con herramientas de disposición de elementos visuales: puede añadir y quitar cajitas o ítems, y situarlas en diferentes partes de la pantalla.

De estos dos enfoques se desprende que, en la informática común, la que le aplican a uno, las particularidades de comportamiento en análisis se consideran anomalías a integrar (de forma muy parecida a como se consideraban la homosexualidad o la capacidad intelectual de la mujer en el pasado cercano), por lo que se busca una opción global que contemple todas las opciones que se han querido/podido contemplar. Así que se diseña para asimilar las excepciones, lo que precisamente impide que se den diseños excepcionales.

El Diseño de Interacción (ID) intenta establecer primero los comportamientos para luego, más adelante, decidir si se requieren procesos e interfaces diferentes para cada uno de ellos… ¡o no! Pero, como ocurre con tantos otros métodos y con la mayoría de las instrucciones de los electrodomésticos que nos favorecen… ¡No los leemos ni seguimos!

¿Debería tratarse de forma diferente a aquél que no sabe lo que quiere que a aquel otro que lo sabe exactamente? ¿Deberían los ayuntamientos incluir secciones especiales para niños (tipo “Imaginarium”) en sus sitios Web, y no sólo “información para niños” (que sería el equivalente de la “puerta para adultos”? ¿Deberían las instituciones ajustar las normas de accesibilidad AA para cumplir los objetivos de los niños (jugar) en vez de facilitar el acceso a una información que, a ellos, no les suele interesar (aunque tal vez sí a sus padres)? ¿Se manejan, en el ámbito de ejercicio de su profesión, los periodistas o documentalistas en un sitio Web como el resto de los mortales, y tal vez necesiten puertas periodísticas especiales? ¿Es la generalización –primero, y la especialización forzosa después– el único camino? Sí, sí, sí, no y… ¡claro que no!

Hablaremos (y yo escribiré) en el futuro sobre el Exception-aware Design (ED), y lo calificaremos (ya verán ustedes) de Diseño Excepcional :). Al tiempo

(c) Ricardo Devis

Zero Consulting

Justo antes de morir un viejo pastor legó a sus hijos su exiguo rebaño de ovejas: la mitad para el primogénito y un tercio para el menor. Pero… ¿cómo repartir así 5 ovejas? ¡Ay! ¿Qué hacer? ¿Cómo liberarse de un problema así? ¡Pues consiguiendo que no sea un problema propio, sino una tarea de otros; consiguiendo que expertos consultores se ocupen del asunto!

Dicho y hecho: los primeros consultores contratados sugirieron que un reparto de 3 y 2 ovejas resultaría lo más apropiado, y aportaron estadísticas sobre la posible satisfacción de padres muertos con tales repartos. Los siguientes consultores decidieron que lo mejor sería trocear a las ovejas y repartir la proporción legada por el estricto criterio del peso, y aportaron baremos ponderados que avalaban esta opción. Los siguientes consultores opinaron lo mismo, pero sostenían que primero habría que matar a las ovejas. No encontrando una solución emocionalmente satisfactoria, los hijos probaron con consultores alternativos: los documentalistas se perdieron primero en la definición de “oveja legada”, y luego de “un medio”; los tecnólogos de nuevo cuño encontraron hasta siete razones distintas para crear redes sociales con el dinero obtenido de la venta de las ovejas; los consultores de ZAP no se presentaron, y a los de Mikroloft les pareció que el balido de las ovejas se asemejaba demasiado a la huella fonética de Gooooooble; por último, a Pauhlo Coeeeehlo el asunto le pareció poco cósmico, aunque aprovechó la experiencia para escribir 2.345 artículos sobre los problemas de comunicación entre padres e hijos que no leyeran al mismo autor, contados por un monje zen siempre rodeado por 5 ovejas.

Así que… ¡Ay, de perdidos al río! Ante tamañas insatisfacciones y desazones, los hijos decidieron probar aquello en lo que nunca habían creído y que habían jurado que jamás pagarían: Zero Consulting. Al día siguiente apareció un consultor que con voz lenta les dijo: “Señores, el problema no importa en sí mismo: lo que importa es la actitud para abordarlo. Túmbense a mi lado que vamos a concentrarnos en…”, y no pudo decir más, porque los hermanos se dieron cuenta de que se trataba, otra vez, de Pauhlo Coeeehlo disfrazado y lo echaron de su casa con prisas razonables. En fin: esa misma tarde el auténtico consultor Zero se presentó con ropa cómoda y sin corbata (venía justo de una reunión en Gipuzkoa) y con una pequeña oveja atada a un cordel, y les dijo: “Señores, el problema no importa en sí mismo: lo que importa es la actitud para abordarlo…” –y cuando vio que los hermanos cogían algunas armas y objetos punzantes (todavía escamados por el asunto Coeeehlo) rápidamente añadió: “así que vengo a regalarles esta oveja”. “Y seguidamente” –prosiguió– “vayamos al problema: ahora contamos con 6 ovejas, de las que corresponden la mitad al primogénito (3 ovejas) y un tercio para el hijo menor (2 ovejas); así que, después de repartir justamente el legado de su padre, les sobra una oveja, que es precisamente la mía (y aquí los hermanos entendieron por qué esta oveja era tan pequeña), así que, si les parece bien, dado que la aporte con buena voluntad y ahora les sobra, podría quedármela y así no me deberían ningún favor”.

Los hermanos quedaron maravillados de la sabiduría del consultor Zero, así que se dispusieron a acompañarle a la puerta de su casa y despedirle entre grandes elogios, cuando el consultor remarcó suavemente: “Parece que se olvidan ustedes de mi pago”. Los hermanos simularon no haber oído nada y empujaron, firme pero también suavemente, al consultor hacia la salida, mostrando a la vez ademanes de prisa y signos visibles de sueño profundo incipiente. Pero el consultor Zero, tal vez esperando el sueño y las prisas, colocó a la pequeña oveja entre el marco y la puerta, forzando así la conversación. “Miren” –les dijo, sonriendo– “mis honorarios son un sexto del caudal total tratado, pero… aquí son cinco ovejas, lo que troca difícil la partición; y teniendo en cuenta una proporción media, yo diría que las cabezas representan la sexta parte del volumen de cada oveja, por lo que podría considerarme pagado con cinco cabezas de oveja”. Oh, dios mío, pensaron los hermanos: hemos repartido bien para dividir mal. Pero rápidamente el consultor Zero les ofreció una salida: “¿Qué tal si les vendo esta oveja… por un precio razonable? Seguidamente, con 6 ovejas en su poder, podrían pagarme un sexto devolviéndome exactamente la pequeña y ruin oveja que les he vendido, por lo que su patrimonio ovejero no disminuiría y, a la vez, me pagarían en razón del precio de una oveja… cuyo tamaño no les importa, porque no se la van a quedar, así que espero un precio más que razonable”.

Tras una breve consideración, los hermanos consideraron justa la proposición y cerraron el trato, así que el consultor Zero volvió a su empresa, devolvió al becario a su pradera y guardó (y lavó) el traje de oveja para que estuviera en condiciones en su próximo proyecto. Es cierto, con todo, que los hermanos, una vez liberados de la –fuerte– influencia electromagnética del consultor Zero, recabaron que la solución adoptada había sido la misma sugerida por los primeros consultores; pero también asimilaron que la diferencia aquí es que se habían cumplido exactamente, sin interpretación, los deseos de su padre, que al fin únicamente habían sido cambiados por dinero, sin que el resto del patrimonio o de la autoestima personal de los hermanos sufriera merma alguna. Además, finalmente habían decidido atar y engordar a Pauhlo Coeeeehlo, demasiado insistente en sus últimas visitas inesperadas a la casa familiar, por lo que pensaron que el balance había sido… ¡Zero! Positivo, al fin (al menos en parte: negativo también, pero sobre cero… ¿qué más da?)

(c) Ricardo Devis

Mariano Rajoy y Facebook

Parece que Mariano Rajoy se ha instalado en Facebook, en una cuenta de perfil público (visible para cualquiera) y en la que se ha añadido una aplicación de fotos (My Flickr) como único elemento nuevo sobre la configuración básica. Y digo que “parece” porque aunque todo suena muy serio y las referencias son las correctas (sitio Web del PP, cargos públicos, etc.), faltan elementos de garantía que faciliten la veracidad de la correspondencia entre persona pública y página en Facebook (como también faltan, de forma más ostentosa, en la página Facebook de José Luis Rodríguez Zapatero, probablemente falsa). Si suponemos que la página de Rajoy es auténtica (como así parece desprenderse de la multitud de entradas sobre la misma que se dan en los foros del PP en su sitio Web)… ¿qué falla aquí? Veámoslo:

Bucle de garantía: se tendría que haber generado (al menos) una entrada en “Notes” o “Posted Items” con el título “Ésta es la página oficial de Mariano Rajoy en Facebook. ¡Compruébalo!”, que contendría un texto muy simple pero eficaz: “Con el fin de que tengas la seguridad de que esta página es la oficial de Mariano Rajoy, presidente del Partido Popular, abre una nueva ventana de tu navegador y teclea (para evitar suplantaciones) la siguiente URL: http://www.pp.es/facebook [no existe actualmente, pero debería existir], y allí, en el sitio Web oficial del Partido Popular, hallarás un enlace que te llevará a la página oficial soportada por el partido (y que comprobarás que es esta misma en la que te encuentras)”.

Página Impersonal: la página de Mariano Rajoy, al estar embebida en el grueso de páginas de amigos de Facebook, permite que se envíen regalos, invitaciones para aplicaciones y, sobre todo, impele a “amigarse con ella” :). Es decir, cualquiera (yo mismo, como efectivamente hice) puede solicitar ser “amigo Facebook” de Mariano Rajoy. Y en breve recibe una notificación de que Mariano Rajoy ha aceptado su amistad (en Facebook, claro). Pero esto supone una vulneración del espíritu de Facebook, porque uno no se imagina a Don Mariano contestando directamente las peticiones de amistad electrónica hacia su perfil Facebook, que pueden ser decenas de miles. Y es posible que pueda llegar a hacerlo él mismo, pero uno no se lo imagina. Así que la imaginación del que recibe la confirmación de tal amistad se encamina más bien a pensar que hay personal detrás de esta página que se encarga de gestionarla. Pero… ¡Entonces no se trata de una página personal! En realidad Mariano Rajoy (o su equipo), tras habilitar su cuenta “personal” debería haber creado una “Página de Facebook” (distinta de la página de perfil personal ya creada), en la categoría de “Public Figure – Politician”. Esta “page” (como nuestra propia “page” en FB) dependería de su perfil personal, pero permitiría que, en lugar de amigos, Mariano Rajoy contara con “fans”; y, lo mejor: para ser un “fan” basta con quererlo, no hace falta que nadie conteste, con lo que el esfuerzo de gestión disminuiría y el efecto de “celebridad” se reforzaría. Por último, las actualizaciones de este tipo de páginas llegan a los “fans” de forma distinguida respecto del resto de comunicaciones entre perfiles, por lo que son del tipo: “te-lo-envío-porque-dijiste-que-eras-un-fan-mío”, y se aceptan de muy buen grado.

Elementos de Convicción: en la página de perfil actual de Mariano Rajoy se da interacción mediante el uso de mensajes en la pared (wall) de la cuenta. Esta aplicación (de la propia Facebook) permite la comunicación entre distintas paredes de usuarios… pero no parece probable que Mariano Rajoy vaya a darle ese uso, así que se queda en una suerte de libro de loas (las quejas o los comentarios inconvenientes pueden ser borrados). ¿No sería mejor utilizar otros mecanismos de comunicación, sobre todo en la página de celebridad sugerida anteriormente? Éstos podrían ser: “Reviews”, comentarios de blogs del PP, etc.

Y… ¿aún podría mejorar? ¡Claro que sí! “Politics on Line” es una asignatura pendiente de los partidos políticos españoles (y, sobre todo, de los minoritarios –en el conjunto total del Estado Español): asunto para otra entrada de este blog.

(c) Ricardo Devis

Segmentación Social: Viejas Querencias, Nuevas Reglas

Como Facebook se abrió recientemente (y con gran éxito) al público en general, algunos de sus usuarios originales consideraron que se estaba pervirtiendo la idea básica de interacción entre estudiantes de colegios y universidades, dando paso a un universo de… ¿qué? ¡Oh! ¡Un pútrido universo de “mayores de edad”, repleto de intenciones aviesas y de extraños intereses! Por eso no es de extrañar que en Facebook empezaran rápidamente a aparecer grupos sobre la conveniencia de forzar a la empresa a retornar a su supuesta intención inicial: la ingenuidad social de los estudiantes y el soporte a sus tácticas, también ingenuas (pero, con todo, un tanto ajadas) de flirteo.

Hubiera sido (y lo sigue siendo) fácil prever que diferentes iniciativas comerciales prestarían una caja de resonancia a tales actitudes, y bajo este paraguas se han fraguado y comercializado distintos enfoques comerciales de recuperación de “ese valor juvenil inasible”, algunas con más fortuna y acierto que otras, aunque en general con pocas perspectivas (ConnectU, CampusMatch, etc.), bien reflejadas en el artículo The Old College Try: Who Will Give Students Their Facebook Back? La última iniciativa publicitada es la de College Tonight, que, por mor de su pretendido enfoque exclusivo, sólo admite usuarios con direcciones “.edu”. Analicemos la situación:

• College Tonight: si sólo se admiten direcciones de e-mail acabadas en .edu se está restringiendo peligrosamente la adición de estudiantes no norteamericanos (mírense, si no, las URLs de las universidades europeas, que acoplan sufijos nacionales [be, es, co.uk, etc.] o globales [com, org, net] a sus direcciones. Por otro lado… ¿no se permitirá el cambio de una dirección .edu… en ningún momento? Si es así, esto supondrá la generación de un mercado publicitario secundario en el que se comprarán o se adjudicarán tales direcciones (como ocurre con las transferencias de la presencia y prestigio de vendedores en eBay, tan real que ha sido tasado por el Fisco norteamericano). Y si se abre la veda y se admiten otras direcciones… ¿cómo se podrá discriminar después entre estudiantes? Es decir: todo lo que no aparezca en los criterios iniciales difícilmente podrá instaurarse más tarde, a no ser que haya sido previsto… o que los principios no son tan importantes J. Y, por último… ¿serán las direcciones .edu una suerte de número de la seguridad social, no concluyente pero suficientemente identificatorio? Difícil panorama, que en el caso de College Tonight no está explícitamente resuelto y que, por tanto, parece una mera estrategia comercial (que, por otro lado, puede atraer a un número importante de usuarios en sus comienzos, que se pueden fidelizar por los servicios “típicamente estudiantiles” que abraza).

• Facebook: ¿Quién ha dicho que no se puede segmentar de nuevo a los estudiantes sin renunciar a la apertura global de esta plataforma a todo tipo de usuarios? Imaginemos que Facebook añade una simple (muy simple) característica en los perfiles que permita insertar una dirección .edu que, tras ser verificada (mediante el envío de un típico e-mail de comprobación) facilite una restricción en el tipo de amigos que se desea mantener en la red personal de cada uno. Es más: según el esquema actual de Facebook, ni siquiera la empresa anfitriona tendría que esforzarse en esto, sino que cualquiera, desarrollando una aplicación específica a este respecto, podría generar una subred con aplicaciones específicas y amigos concretos también (como hace, por ejemplo, la sub-comunidad Facebook de Human Pets) ¿Dónde está el reto? ¿Dónde la dificultad?

Quizás la única conclusión lógica sea, por el momento, que “la apertura facilita el recogimiento voluntario, mientras que las restricciones iniciales impiden la extensión de las voluntades”. Y el problema es que las mentes siguen pensando como antes, en términos de segmentación dirigida de mercados, y no en esquemas de “habilitación” de mercados. Interesante .

(c) Ricardo Devis

Ego-Publicidad

¡Ay! Los tiempos cambian, los comportamientos se modifican, aparecen nuevos utillajes por doquier y las personas se relacionan de otra manera, de forma más excitante. Y no, no hablo de sexo, aunque… bueno, errr… también :). En fin, los cambios van deprisa, y las mentes no pueden seguir el ritmo: esto es lo que se llama “juventud retro-adquirida” o, simplemente, catatonia; o, en el peor de los casos, ignorante despreocupación culpable. Examinemos, si no, la publicidad en Internet, y concretamente en el buscador Web de Google.

El asunto es sencillo: en la modalidad más usual de publicidad, cualquier sujeto puede componer un corto anuncio de texto, elegir unas palabras o frases determinadas y pujar por ellas; es decir, pujar porque el anuncio aparezca de forma más o menos prominente cuando alguien, utilizando el buscador Google, teclee una o más de los términos elegidos. Así que se siguen, como base, los criterios de la publicidad tradicional: si nuestra empresa se dedica a X (decoletaje, escorting, armas, golf, paraguas, etc.), o simplemente quiere atraer a los que les gusta X (sexo gratis, programas gratuitos, Angelina Jolie, etc.), pujamos por X para que la empresa aparezca cuando alguien busque X en Google. Hasta aquí nada especial. Y entonces pregunto… ¿pujaría/pagaría su empresa por una frase de búsqueda que fuera… ¡su propio nombre!? La respuesta inicial suele ser de esta guisa: “¡Claro que no!”, o “¡Ya estamos muy bien posicionados en el buscador, así que… ¿por qué habríamos de pagar por algo que ya hemos conseguido gratuitamente” (gratuidad que a veces no es tal, pues se ha pagado, muchas veces lamentablemente, a una empresa de “posicionamiento en buscadores” para conseguir ese supuesto resultado).

La lógica de este asunto no debería escapársele a nadie: como este tipo de anuncios sólo se paga cuando alguien hace clic en ellos, si tenemos una empresa bien posicionada en el buscador y los potenciales clientes/usuarios hacen clic en el vínculo gratuito… ¡no pagaremos nada por haber realizado el anuncio!; pero si, por el contrario, resulta que estamos equivocados y que cuando alguien busca el nombre de nuestra empresa (en concreto, no los asuntos a los que nos dedicamos: el nombre comercial o la razón social) y hace clic en un anuncio… ¿por qué no habría de ser el nuestro, para conducir al interesado directamente hacia nuestro sitio Web?

Los precios medios por frases no usuales (“Decoletajes Uribitarte”, “Ricardo Devis y Asociados”, “Cerrajería Astenoetxea”, etc.) son muy baratos en Google: típicamente oscilan entre 0,01€ y 0,08€ por clic. Esto supone que si alguien busca a nuestra empresa (es decir, tiene un interés claro y dirigido hacia nosotros), ¿cómo arriesgarnos a perderlo por menos de 0,10€? (y aquí habría que considerar lo que cuestan las acciones comerciales más triviales para conducir a posibles clientes hacia las empresas). ¿Que nuestra empresa ya aparece en los resultados en el primer o segundo lugar? ¡Perfecto! ¿Que además debería contar con un anuncio? ¡Por supuesto! (salvo casos atípicos, en los que el nombre de la empresa sea un término muy común).

Pero es que, además, podríamos impedir el fallo en la busca: es decir, podríamos pujar por términos y frases todavía más raros (y, por tanto, más baratos): “Iber matica” [separado], “Ricardo Debis” [error ortográfico], “Decoletages Uribitarte” [galicismo]. ¿El coste? ¡Irrelevante! ¿El ratio de conversión? ¡De los más altos posibles!

Pero, si esto es tan sencillo y claro… ¿por qué no se hace de forma masiva? ¡Ay! ¡Los tiempos cambian y las mentes renquean!

P.S.: Cuando hablo de puja no me refiero a una subasta, aunque es cierto que a veces Google marca mínimos por palabras o frases en razón de “su” mercado publicitario; me refiero a que en razón de los euros que ofrezcamos por cada clic, y sin conocer lo que ofrecen otros, nuestro anuncio aparecerá… el primero, el tercero, el último o en la página 2 (lo peor).

(c) Ricardo Devis

La Simplicidad Esforzada

“Me esfuerzo cada día en ser más simple, para así conseguir ser complejo de forma más natural” (Anónimo)”

Una cosa es la simplicidad encontrada y otra muy distinta la simplicidad buscada, que al final siempre suele ser simplicidad esforzada; una cosa es que una actividad resulte inadvertidamente simple y otra diferente que se note, que se perciba fuertemente el esfuerzo acometido para intentar que la misma actividad resulte simple.

Pagii ofrece páginas Web personales en minutos: y es cierto que la creación es fácil (sobre todo porque no se sabe lo que se está creando y las preguntas son sencillas), pero el resultado es… ¿esforzado? Es algo parecido a comprar una mascota en el mercado negro de trata de animales –lo que puede resultar turbadoramente fácil– y luego descubrir que se trata de un niño (las dificultades se amontonan con rapidez descorazonadora). Mi prueba en Pagii acabó cuando fui consciente de haber terminado el proceso y no saber bien qué hacer con el resultado, ni cómo seguir; y realmente me sentí como un niño intentando comprender el Logo con instrucciones de tortuga (arriba, atrás, 50, 100) sin asimilar muy bien la esencia del asunto y por qué, simplemente, no se cogía la tortuga para manejarla. Y algo parecido me ha ocurrido con WriteBoard (de los chicos de 37signals): pese a que se apoya en BackPack y a su parecido asombroso con Jottit, he de reconocer que la simplicidad brutal (y casi culpable) de este último me ha cautivado, así que en mi prueba con Jottit incluso he dejado algo escrito. En Jottit se nota la simplicidad, pues las cosas sólo pueden funcionar en un único sentido (y a veces hasta piensas que se te han perdido algunos botones); en WriteBoard se nota el esfuerzo. Y, con todo, la diferencia entre ambos es mínima; pero suficiente para ser percibida de forma simple.

Claro que, por otro lado, simple no es canónico; y, por ejemplo, un ordenador o un televisor puede ser más simple que otro ofreciendo, sin embargo, más opciones. Así, WordPress y Blogger son endiabladamente simples, y su ejemplo comercial se ha extendido.

El esfuerzo no es importante, pese a lo importante que haya podido ser. Puede ser meritorio que un mocoso de 3 años interprete a Chopin; pero su interpretación será lamentable, con todo. En su libro “The Laws of Simplicity (Simplicity: Design, Technology, Business, Life) ”, John Maeda expone interesantes aspectos y facetas de la simplicidad, y se despacha con varias simplezas agradables, como la mención de los libros de referencia sólo por su título, sin la parafernalia de ISBN y demás, que podrá ser encontrada en la Web. Pero Maeda, al final, cae en la simplificación esforzada, pues el texto de su libro tiene exactamente (y de forma buscada y argumentada) 100 páginas: ¿Mérito de lo simple o maquetación meritoria?

(c) Ricardo Devis

Blogs Corporativos Personales

Los blogs se han convertido en una suerte de “Wikipedia de opiniones y emociones”, se extienden con enorme celeridad y ejemplifican la voz personal de la multitud (no exactamente “La sabiduría de las masas”, sino más bien “el mercado de competencia perfecta de la vanidad”). Pero su inmediatez, su relación especial con sus seguidores (Technorati, Blogpulse, etc.) y la comprehensible facilidad de su formato han dejado huella en las relaciones entre internautas; relaciones éstas que las empresas pueden aprovechar para generar una pulsión emocional que, a su vez, cause una mejora en la percepción de sus posibles clientes. ¿Mi visión? Hela aquí, en Blogs Corporativos, que es una parte del material que uso para mis sesiones y que está disponible en mi parcela de Google Base, de la que hablaré en otra entrada, claro :).

(c) Ricardo Devis