De la Sede Electrónica

La ley 11/2007 (LAECSP) exige a las AAPP el establecimiento formal de una Sede Electrónica que (en consecuente interpretación de la voluntad del legislador) garantice el acceso electrónico normado de los ciudadanos a los servicios públicos. En realidad se trata de garantizar la constancia reglada de un punto de partida electrónico que procure cobijo informado a los ciudadanos para iniciar, mantener o denunciar sus relaciones, también electrónicas, con las AAPP.

La situación parece sencilla: si una ciudad dispone de una casa consistorial, ¿cómo no habría de darse una similar sede en el ámbito electrónico? Se trata, en definitiva y simplificando, de establecer el domicilio social electrónico de las AAPP; pero las AAPP resuenan muchas y distantes, así que nos restringiremos a los ayuntamientos: se trata, pues, de establecer la sede oficial del ayuntamiento electrónico. Fácil, ¿eh?

Claro que... si revisamos las normas promulgadas e incluso las proyectadas, la inmensa mayoría afirma que la sede electrónica radica en el sitio Web del ayuntamiento. O, peor, que se accederá desde tal sitio Web. Así que se dice algo parecido a... "la sede del ayuntamiento de Burgos está en la ciudad de Burgos, o estará en algún punto accesible a través de las entradas a la ciudad de Burgos" ¡Claro! ¿Qué significa, con esto, que la sede electrónica esté o resida en www.ciudad.es? Pues, simplemente, que se encuentra en algún punto contenido en ese dominio; así que... ¡menuda imprecisión!

Los sitios Web municipales son escaparates electrónicos de las diferentes actividades y proyecciones del ayuntamiento, de sus ciudadanos y de otros medios, compañías o instituciones (prensa, cines, parkings, etc.)… ¡sin ninguna forma reglada más allá del protocolo de acceso: HTTP! Es decir: en una Web de un ayuntamiento tienen cabida informaciones propias, informaciones ajenas, opiniones, publicidad y todo tipo de actuaciones, con diferentes grados de seguridad y distintos cualificaciones de identificación. Así, en la Web se dan parecidos planteamientos que en una oficina “física” de Atención a la Ciudadanía: pasquines informativos, publicidad, noticias de otros en tablón de anuncios… y también trato directo con los ciudadanos, acceso a sus expedientes y… ¡un momento, un momento! ¿La Web es tal mixtura? ¡Pues claro! Un sitio Web municipal permite un medio de acceso y comunicación distinto para actuaciones similares a las presenciales. Pero, entonces, la Sede Electrónica… ¿es la Web municipal en sí? ¿Toda ella? Yo creo que no; no, no; definitivamente no.

Si atendemos a lo anterior, la definición de Sede Electrónica municipal debe eliminar dudas (sobre todo en los ciudadanos que accedan a ella) sobre lo que representa una información, una opinión o… ¡un dialogo “oficial” con el ayuntamiento! De hecho, parece claro que una Sede Electrónica debiera obligar, por sus contenidos, al publicador (en nuestro caso, el ayuntamiento) frente al ciudadano (pues en otro caso éste no sabría, al menos de forma intuitiva, si una comunicación es oficial o no), y, por otro lado, debe estar bien acotada, para que su usuario ciudadano pueda delimitar cuándo se encuentra en un sitio (o sede) oficial y cuando no (por ejemplo, cuando un hiper-enlace lo lanza a… ¡quién sabe dónde!). Pero vayamos por partes.

¿Cómo se acota una Sede Electrónica? ¿Mediante un certificado del ayuntamiento? Si fuera así nos encontraríamos con que la Sede Electrónica es el subconjunto de la Web municipal sujeto a comunicación segura mediante un certificado oficial. Pero esto supondría que no se podría dar este enfoque fuera de la Sede Electrónica, lo que no tiene sentido, pues al fin se trata de un protocolo de seguridad certificada que un ayuntamiento podría dedicar a fines diferentes a los establecidos para la Sede Electrónica. Por otro lado, y como ya hemos visto, la simple mención de la Web municipal (o su consideración de “punto de entrada”) no sirven como lindes (y esto es especialmente cierto cuando la Sede Electrónica se amplíe con otros sufijos de dominio, como “.tel” o “.mobi”, o con otros protocolos de comunicación -FTP, etc.). Nuestra propuesta es que el portal de la Sede Electrónica municipal resida en “http://SedeElectronica.ayuntamiento.sufijo” (por ejemplo, http://SedeElectronica.Vitoria-Gasteiz.org) y que su contenido oficial esté limitado a lo estrictamente contenido en tal subdominio. De esta manera, además del certificado municipal, un usuario/ciudadano podría validar inmediatamente la “oficialidad” de la Sede.

Pero, en el caso propuesto, ¿qué ocurre cuando, como se anunció antes, se desea o requiere utilizar otros protocolos, situados fuera del ámbito del subdominio citado? Pues bastaría, únicamente, publicitar en un directorio reglado (y, por tanto, indicado expresamente en la ordenanza municipal) de la Sede Electrónica (por ejemplo, en http://SedeElectronica.Vitoria-Gasteiz.org/ExtensionesAutorizadas) las URLs de base para tales adiciones: http://vitoria-gasteiz.tel, http://buzon.vitoria-gasteiz.org, etc. Este directorio incluiría, por supuesto, la dirección base oficial de la Sede y serviría para disipar dudas sobre la oficialidad de sub-sitios Web, subdominios y, en general, “puntos de acceso autorizados” a la Sede en sí. Y, de paso, eliminaría la necesidad de tener más de una Sede Electrónica por municipio, usualmente basada en diferentes necesidades departamentales o de servicio (lo que, en puridad, tiene poco sentido, incluso en su transposición física a edificios).

Y es que la norma escrita tiene que describir completa e inequívocamente los accesos y límites de la Sede Electrónica, de forma que opere como referencia y comprobación de la validez de ésta. Por otro lado, las ventajas de la acotación formal resultan evidentes, pues un diseño de interacción plausible aconsejaría que, para el subdominio de la Sede Electrónica, se habilitaran cabeceras Web diferenciadas, que indicaran expresamente su condición y garantía.

Pero todavía hay más. Cuando en un edificio municipal (el Registro oficial, por ejemplo) no se puede prestar servicios se indica, tal vez en la misma puerta y quizás en otros medios de comunicación, tal circunstancia e incluso se pueden establecer opciones alternativas. Sí la Sede Electrónica estuviera embebida de forma no acotada en la Web municipal, podría darse que no funcionaran los certificados y que, sin embargo, se pudiera acceder a cierta información, tal vez no vinculante, lo que originaría confusión en la ciudadanía, pues la supuesta Sede funcionaría y no funcionaría a la vez. Si se atiende a nuestra propuesta de subdominio específico, en la norma que lo regule se habría de establecer también al menos una URL separada (o, idealmente, varias), en un dominio distinto del municipal (tal vez en una página de la Web del Gobierno Autonómico correspondiente, o en el de un servicio Web con garantías), en la que se pudiera monitorizar el estado electrónico de la Sede y, en su caso, se pudieran publicar notas u opciones alternativas en el caso de que el portal de la Sede Electrónica no fuera accesible o funcionara, total o parcialmente, de forma anómala. Esta “URL de seguridad” se publicitaría también en la misma Sede Electrónica, en un directorio al efecto (http://SedeElectronica.Vitoria-Gasteiz.org/Alternativa), en una página que replicaría la externa y que, además, permitiría el acceso a aquélla.

Entiendo que la norma que regule la Sede Electrónica debiera ser tan precisa que habría de regular, además de su acotación, sus mecanismos individuales (por página o acceso) de validación y los esquemas de su identificación corporativa (cabeceras, certificados, etc.), pero… ¿ha de reglar también los puntos de acceso desde páginas Web –u otros medios– desde fuera del dominio legal? ¡No! Hay que distinguir entre “Puntos de Acceso Autorizados” (los detallados en la misma Sede Electrónica) e hiper-enlaces a los mismos (que podrían darse en cualquier página, y singularmente en la página “home” de la Web municipal, sin necesidad de reglarlo). El férreo y claro establecimiento de lindes así procurado permitiría normar, también, los elementos de que constaría el portal de la Sede Electrónica, que se corresponderían, como mínimo, con los exigidos por la Ley 11/2007, de forma que los hiper-enlaces, en tal portal, a sitios externos se podrían validar, adicionalmente, en el directorio de Extensiones Autorizadas de la Sede.

Con el enfoque planteado sería fácil incorporar como Punto de Acceso Autorizado una dirección específica para teléfonos móviles (del tipo, por ejemplo, http://m.vitoria-gasteiz.org ó http://vitoria.gasteiz.mobi) que ofreciera mecanismos de identificación diferentes a los del sitio Web general (de la Sede, nos referimos), garantizando, en todo caso, la cadena “oficial” de validación de aquello a lo que el ciudadano accede. O se podría dar carta de validez incluso a subsitios externos, perfectamente acotados, hospedados por otras instituciones o empresas (redes sociales, administraciones locales de otras regiones o ámbitos, etc.).

En definitiva: todo lo anterior intenta hacer reflexionar sobre la inconveniencia de la ecuación “SedeElectrónica = SitioWebMunicipal” y sobre las ventajas de la precisión normativa y de los lindes electrónicos en la relación con los ciudadanos. Así que… pues eso… ¡A reflexionar! J

¡E...special!

No me pude resistir al reclamo comercial: "Leslie cree que es un superhéroe. El resto del mundo simplemente cree que es un superimbécil". La película "Special" es especial en muchos sentidos, porque publicita a su protagonista (un medido Michael Raraport) por encima de su director (directores, vamos), y... espera, espera: esto es lo usual cuando los directores no son estrellas y el argumento no se puede resumir bien (la sinopsis en el DVD es... está... absolutamente equivocada :)). Al fin, se trata de una película mediocre, pero tierna en su voz en off; mediocre pero tremendamente sugestiva :)

El protagonista, merced a un fármaco experimental que pretende potenciar la auto-confianza, cree verse armado, in crescendo, por superpoderes; y cree igualmente que su uso le ocasiona un grave desgaste físico. En realidad, cada vez que cree atravesar una pared, se estrella en ella; y cuando se lanza al vacío para levitar... se da de bruces contra el suelo, sin que nada de eso destruya su interpretación interior de sus nuevos dones. Y, claro, nuestra interpretación más amable sería que los superpoderes están precisamente ahí, en la confianza; pero la película, en su lento discurrir, nos hace descreer de esta opción ilusionante. El mejor episodio es cuando el protagonista, Leslie, hace desaparecer a sus enemigos trajeados (los empresarios farmacéuticos) y, de seguido, recibe una paliza descomunal, atacado por enemigos invisibles. La pena es que Leslie no muera, claro.

Pero... ¿por qué cuento esto? ¡Pues porque me recuerda el comportamiento típico en redes sociales, basado en la ingestión de un cierto fármaco bien publicitado y sustentado en sus efectos de asunción personal! Nuestro e-protagonista tendría aquí super-e-poderes: para ser simpático y atractivo (cientos e incluso miles de amigos); para hacer oír/valer su voz (broadcasting masivo e irredento); para que valoren sus actitudes (grupos, iniciativas, e-recaudaciones). Y, como en la película, la reputación del super-héroe dependería del espectador, así que la media se asegura con la difusión exponencial.

La red se estira cuando el malvado trajeado enuncia que "nadie se enteraría de su desaparición", y se contrae cuando el raro super-héroe le espeta lo mismo, de retruque, a aquél. Estos dos momentos son los que de verdad ocasionan pavor... ¡mediático!

Que te… ¿qué? ¡Ah, no! ¡Keteke… Beta! ¡Ay! ¡Lo siento! :(

Como parece haber hecho siempre, Telefónica, en la Web, se encamina hacia un lugar… ¿sorprendente? ¿misterioso? ¡No! ¡No hay misterio aquí (lamentablemente)! Keteke es la nueva apuesta para ganar… ¿qué? Pues usuarios, claro: se trata de Web 2.0 (o superior) y de Telefónica 1.7 (subiendo). Así que se trata de una novedosa (!?) red social que… bla-bla-bla y… ¡Ay! Lo de siempre, pero a la manera Telefónica, claro.

Keteke-Beta (desde que la presunción de premura se ha convertido en índice de novedad atractiva; desde que se apreció que en Google casi todo es Beta y funciona… ¡ay! ¡versiones beta a mansalva!) es una red social que se centra en… ¿el usuario? ¿en sus relaciones? ¿en su estado/status? ¡Pues claro que no! ¡Se focaliza en la funcionalidad! Bueno, más bien en el acopio de funcionalidades conocidas: KetekeCity (al modo Second Life), Galería (a la manera… iba a decir Flickr, pero… ¡es ya tan común!), Mis Mensajes (e-mail restringido), Imagenio/Móvil/PC, Mis amigos (lo e-social típico, vamos), Mi Perfil, y… vaya, casi de todo. Claro que… ¿a quién le importa la acumulación funcional? ¡Pues a los analistas funcionales, claro! :)

El problema (como casi siempre en estas iniciativas) reside en el Diseño de Interacción: bueno, realmente en su carencia. Y me explico: se exige un apodo, pero el acceso se dará por el número del móvil; se establece la clave por SMS… en la Web; en mi perfil se dice… “Estás aquí: Mi perfil / Mi perfil / devis” y… ¡ay, ay, ay! En mi perfil aparecen dos epígrafes (Últimas Fotos y Últimos Vídeos) con la etiqueta común “No hay contenidos para mostrar”, todo circundado por… ¡qué sé yo! Tres columnas de anchura fija y la sensación de que estamos en una red social de segunda división.

Pero me explico mejor: si se hubiera dado Diseño de Interacción (ID: Interaction Design) mediante escenarios de comportamiento… se podrían haber publicado para validar sus presunciones no con un Focus Group (coincido con Google en obviar a este tipo comunal) sino con los usuarios de hecho. Y es que, de hecho también, los escenarios de interacción de ID reflejan (deben reflejar) las presunciones de uso del producto software en lenguaje natural… ¡legible! Y, además, basándose no en lo que se ofrece (la funcionalidad), sino en el comportamiento plausible de sus posibles usuarios: así que la prueba de que se han aplicado técnicas de ID es que… ¡se muestran en el sitio Web que las escenifica! Si los escenarios de interacción no se publican es… ¡que no existen! Tan fácil, tan claro, tan difícil, tan… tan, tan tan: claro, así tenemos sitios [tan] chiripitifláuticos.

¿Se podría mejorar? ¡Sin duda! ¿Dónde está la duda, pues? :)

La Web X.0

¡Mira que tengo que leer basura tecnológica… sin cesar! Por cada libro bueno (ya no recuerdo el último y… bueno, sí lo recuerdo: “Perfect Software and Other Illusions about Testing”, de Gerald M. Weinberg) que atisbo he de tragarme veinticinco malos, anodinos, culpables o simplemente aburridos: sobre movilidad, sobre la web numerada (2.0, 3.0, 3.1), sobre economía-ficción. Así que ando entre O’Reilly y ForrersterResearch e innombrables: anido entre basura a precio de saldo… también. Y hete aquí que, interesado en las redes sociales y, por encima de todo, en su comportamiento asociado, encuentro una película que lo resume todo con gran energía y sensibilidad: “Be Kind Rewind”, de Michel Gondry. He leído transposiciones del negocio tradicional al nuevo 2.0 y me ha costado diferenciar estos libros de los que encerraban las historias de los Golfos Apandadores (¡gran traducción: ininteligible, pero grande!) de Walt Disney. Pero la película de Gondry… ¡ay! Se nota el amor al cine, se apunta un cambio de modelo de negocio basado en la participación, se impone lo que se ama (creación y propiedad) a lo que “se echa” (como las pelis de Hollywood, como los comerciales de medianoche), casi se puede notar la pulsión participativa y… el final no es feliz (es, simplemente, el final). El trabajo del gamberro Gondry (atención a las "suecadas", como la Suecada Google) se centra en la satisfacción por la participación, en la variación emocional del que participa respecto de esquemas pulidos de producción para impresionar a cualquiera… que nunca es uno mismo. En el fondo se trata de la satisfacción del “made-it-by-you” de YouTube o de las cortas auto-conversaciones seriadas de Seesmic: se trata del diferencial estimativo causado por la participación en la creación y en la propiedad de una obra. Se trata de la Web X (como la de Malcolm). Así que al ver esta película me he sentido X, uno más, posiblemente uno más, posiblemente.

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 ante 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).

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.