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.

(c) Ricardo Devis

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

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

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

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