La épica del informático

programmingHoy toca una entrada para alabar la tarea de nuestros trabajadores del conocimiento (eufemismo clase Dios) que son, como no, ninguneados e ignorados silenciosamente por el público en general y por sus jefes en particular. Pero esperad, antes de eso, un “mea culpa”… ¿Porqué los profesionales de la informática son tan despreciados en esta, una sociedad construida en base a su esfuerzo? Os diré mi opinión… Porque acostumbramos mal a nuestros clientes. Nos piden lo imposible y se lo damos, nos quejamos, nos revolvemos contra la ignoracia atrevida del que nos pide la luna pero finalmente cedemos y eso es lo que nos conduce inexorablemente a las mazmorras de nuestro propio talento.

Si alguien pide un presupuesto a un fontanero para que le ponga un grifo debajo de la cama (por estúpido que eso sea) y consigue un profesional que no se descojone de su ocurrencia y le de el presupuesto lo más normal es que consiga su grifo y nada más. Imaginemos la conversación:

  • Cliente: ¿Qué es esto que me has puesto aquí?
  • Fontanero: un grifo
  • Cliente: pero está debajo de la cama, ¿cómo voy a poder usarlo así?
  • Fontanero: es lo que pidió
  • Cliente: si, claro, pero es de sentido común que un grifo debajo de la cama debe tener algo que permita que se use desde encima de la cama
  • Fontanero: eso no es mi problema
  • Cliente: venga, no me vengas con esas, un grifo que no se puede usar no te lo voy a pagar.
  • Fontanero: es lo que has pedido y es lo que tienes que pagar
  • Cliente: ya, pero al menos harás que se pueda usar desde la cama
  • Fontanero: solo tienes que bajar de la cama y amorrate al caño
  • Cliente: eso no es práctico
  • Fontanero: ya ¿y?
  • Cliente: venga, me haces un apaño para que pueda usarlo desde la cama y luego te contrato la pila del baño
  • Fontanero: ni de coña, aquí tiene la factura.
  • Cliente: bueno, vuelve dentro de un mes y te pago junto con el resto de..
  • Fontanero: ahora
  • Cliente: esto…
  • Fontanero: ¿Pagas o me llevo el grifo y se te inunda la casa?

Bueno, algo así… Los clientes suelen ser más razonables con los fontaneros que con los informáticos, porque, total, seguro que a los informáticos les gusta hacer mal su trabajo y no ponen todas las cosas que tienen que poner porque son vagos.

¡Pues no!

Los informáticos, y los programadores principalmente, son héroes. Gente que consigue lo imposible, que cumple con requisitos inverosímiles, que estira el tiempo disponible hasta lo absurdo para conseguir terminar algo que, probablemente, luego sea mal juzgado por algún ignorante en la materia. Los programadores más experimentados crean obras de arte en unas líneas de código que, aunque podrían ser admiradas en museos donde otros programadores no puedan más que deshacerse en halagos, al final son ejecutados una vez por alguien que no está preparado ni para programar una lavadora y obtienen un comentario estúpido sobre el número de clicks que hay que hacer… Estos héroes anónimos mueven nuestro mundo, allí donde mires hay un programa que escribió alguien, que hace más sencilla tu vida, o que te permite hacer cosas impensables hace solo unos años. Estos héroes sin nombre que, por lo menos en España, están mal pagados, mal vistos (como si picar código al azar en un editor fuese programar), mal dirigidos por gente sin criterio y sin empatía. Formando parte de hojas excel que los mide en kilos de carne y los vende y los compra a otros patanes con ínfulas que creen que hacer informática es un simple problema de coste.

Por todo ello, amigo gerente, si alguna vez un programador te intenta explicar lo difícil que es conseguir algo, entiéndelo como un cumplido que te hace intentando dejar que veas una porción pequeña de su complejo mundo interior. Intenta comprender que no te está intentando dar una excusa, sino describiéndote el peligroso campo de batalla en el que va a meterse en tu nombre y dar hasta su última gota de sudor y sangre para acabar con el enemigo y conseguir esa funcionalidad que tu describes en una frase pero que eres completamente incapaz de explicar en sus detalles (o, simplemente, no quieres hacerlo por pereza).

Día a día, proeza a proeza, sin parar, sin esperar recompensa, sin aparecer en los libros de historia (ni siquiera viendo reconocida su propiedad intelectual muchas veces), el programador anónimo sigue siendo el motor de esta sociedad y, desde aquí mi más sincero agradecimiento a todos ellos. Y, por favor, dejad de tratar a los gerentes como niños, que ellos no quieran escuchar los problemas no significa que estos no estén ahí y que merezcan verlos con sus ojos… Igual así despiertan y os empiezan a tratar como lo que sois, los nuevos magos de la tecnología moderna.

Lecciones informáticas: La resistencia al cambio

Hoy en día están apareciendo un montón de noticias sobre la posibilidad de reemplazar obreros por robots y los cambios económicos que esa situación desencadenaría. En efecto el temor a ser reemplazado por máquinas no es algo nuevo y viene provocado, en mayor o menor medida por una resistencia al cambio que es, en el caso de la tecnología, un freno importante a la adopción de nuevas maneras de trabajo.

301111_1462_1No pienso soltar aquí una lección sobre la resistencia al cambio, pero si que quiero dejar algunas notas sobre las resistencias más obvias que he encontrado en mi carrera y algunas recetas comunes para lidiar con ella. Como siempre, lo veremos con ejemplos reales.

Cada vez que se diseña un nuevo sistema empresarial hay que tener en cuenta no solo al cliente (que es quien paga), sino al usuario final y a aquel que va a trabajar con el sistema de alguna manera (que no tienen porqué coincidir). Las actitudes y motivaciones de cada uno de estos actores suele ser diferente e, incluso, en muchos de los casos divergente. Cuando me han encargado un sistema siempre he intentado tener en cuenta a todos los usuarios, pero hay veces que los conflictos han de solucionarse en la organización y no tiene nada que ver con el sistema. Los problemas más habituales suelen ser:

  • Falta de involucración de la dirección. A pesar de ser quien financie el sistema nuevo, hay veces que los mismos directivos encargan los sistemas para “modernizarse” sin haber pensado en serio que el sistema cambiaría la forma de trabajar de sus empleados. Si se construye el sistema siguiendo las directrices de la dirección lo más probable es que los usuarios terminen renegando del sistema y eviten por todos los medios que este pase a producción.
  • Falta de motivación entre los usuarios. Si algo funciona no lo cambies… dice la máxima de los ingenieros, y eso es así siempre que los cambios no aporten valor de verdad. Los usuarios suelen estar acostumbrados a hacer las cosas de una manera y si no somos capaces de explicarles las ventajas que traerá a su trabajo el nuevo sistema (o si estas no existen), los usuarios estarán más motivados a ignorar el nuevo sistema que a usarlo de verdad. Si el sistema no se prueba y consensúa con los usuarios es muy dificil que su uso sea voluntario.
  • Falta de comunicación entre los distintos actores. Por mucho que seamos unos desarrolladores impresionantes y seamos capaces de realizar proezas técnicas, si no hacen lo que deben o en la manera en la que puede ayudar a los usuarios a realizar su trabajo estaremos construyendo en el vacío. Solo se puede construir algo útil si nos comunicamos con todos los afectados y ellos entre sí. Consecuencia de esta falta de comunicación puede ser la falta de entendimiento sobre los objetivos del proyecto. Lo que a unos les puede parecer un sistema fundamental para el funcionamiento futuro de la empresa para otros puede verse como un gasto inutil de dinero que no va a ser utilizado.
  • Exceso de “mano izquierda”. Si alguien os dice alguna vez que es capaz de contentar a todo el mundo, simplemente te está mintiendo. Con los acuerdos (si son buenos) todo el mundo queda insatisfecho en algún aspecto, pero ha conseguido que los aspectos importantes sean tenidos en cuenta. Si algún gestor intenta tener a todo el mundo contento a base de mano izquierda, sin ceder ni exigir lo suficiente, la negociación y la implantación del sistema estarán abocados al fracaso.

¿Cómo se debería realizar una implantación exitosa de un sistema en una organización?

En primer lugar habría que recopilar todas las opiniones de todos los afectados para ver si la idea es compartida, si es una simple imposición o si nos encontramos con oposiciones frontales. En caso de que la idea no sea compartida hay que conseguir, ya desde el momento de los requisitos, involucrar a cuantos más usuarios mejor para intentar averiguar en que puntos el nuevo sistema les va a hacer la vida más sencilla… Si no conseguimos esto, bueno, estaremos ante un sistema impuesto y, probablemente, mal orientado desde la dirección… Si, podemos hacerlo, pero ya sabemos que no será adoptado sin más.

Antes de terminar el sistema se necesita que los usuarios finales (o los principales) vean resultados y hagan comentarios de mejoras que poder introducir. La mayor parte de las veces serán mejoras interesantes y, si la resistencia es fuerte, al menos mostraremos que se les tiene en cuenta. Llegados a este punto puede pasar que la cooperación no exista. Pueden pensar que no es su trabajo andar con pruebas de sistemas sin terminar o que no quieran en absoluto oir hablar del sistema. Este es un caso de manual en el que se requiere que la dirección se involucre y vuelva a explicar qué se espera del sistema y porqué se les está teniendo en cuenta en su construcción. Fallar en esta comunicación nos da muchos puntos para que lo que se termine produciendo sea tirado a la basura.

Finalmente, cuando el producto está terminado, antes de pasar a producción definitivamente habría que mantener un “paralelo” entre las formas de trabajar antiguas y nuevas de manera que se hagan patentes las ventajas. Si no hay ventajas es que algo hemos hecho mal.

Si el sistema se impone por parte de la dirección veremos que los problemas que nos surgen serán algunos de estos:

  • Quejas constantes, intentando demostrar que el sistema está mal construido y atacando de cualquier manera la posibilidad de su paso definitivo a producción.
  • Lentitud de aprendizaje. Aunque el sistema sea sencillo e intuitivo, si se da la impresión de que es difícil de utilizar se están poniendo piedras al despliegue definitivo y puede que se consiga retrasar el mismo exigiendo más formación.
  • Ignorar el sistema. Aún más doloroso que las quejas constantes es la actitud de los usuarios que cuando les salta un error deciden, por su cuenta y riesgo, volver a la forma antigua de trabajar diciendo “esto no funciona” y tirando por la borda cualquier posibilidad de arreglar el problema, informar del uso correcto o corregir el defecto.

Todavía recuerdo el día en el que entregamos un gran sistema web para muchos miles de usuarios y el empleado encargado de mantenerlo a partir de ese día (que era el responsable del sistema anterior) decidió negarse a responsabilizarse del nuevo sistema porque nadie le había preguntado. Como el proyecto era para una administración pública no había manera humana de convencer a este funcionario ni de hacerle entrar en razón, así que se tuvo que contratar a otra persona para que hiciese su trabajo, con el coste añadido que esto suponía.

También me escuece aún el recuerdo del paso a producción de un sistema que tardamos seis meses en recopilar los requisitos manteniendo reuniones semanales con todos los afectados y, tras pasar a producción el sistema, nos llamaron para decirnos… Muy bien, ya vemos que tipo de cosas hace el sistema, ahora os vamos a contar qué es lo que queremos que haga…… ¡¡¿¿??!!

Los errores SI se pagan

Tengo un jefe que dice que su empresa no paga errores y que las tareas dedicadas a depurar y corregir errores deben hacerse en el tiempo libre.

human-error-in-finance-640x324A mi, que no soy muy dado a cometer errores y que tampoco dispongo de mucho tiempo libre eso me parece simplemente una barbaridad, y no solo porque estemos hablando de ingeniería del software, sino porque estamos hablando, en general, de trabajo hecho por humanos. Es completamente imposible asegurar que el 100% de un trabajo realizado por un ser humano está exento de errores, enmiendas u omisiones. Decir que solo se paga por el trabajo “perfecto” es como decir que te están pagando solo una fracción del tiempo que dedicas. Y eso, simplemente, es explotación.

Según Frederik P. Brooks, Jr. El autor, entre otros, del conocidísimo libro “The mythical Man-month” y autoridad donde las haya en el campo de la ingeniería del sofware, el 50% del tiempo total de un proyecto software debe dedicarse a pruebas, depuración y corrección de errores. ¡Un 50%! más tiempo que el dedicado a programar o a cualquier actividad de gestión. ¿Eso significa que si se hubiese aplicado la política de “yo no pago errores” el software habría salido por la mitad de precio? No, significa que los errores en el software son inevitables y que el buen software no es el que se construye sin cometer errores sino el que se hace teniendo siempre presente que los errores están ahí y hay que corregirlos antes de sacar nada al mercado.

Escudarse en la excusa de que un programador experimentado es el que no comete errores, es una falacia completa. El programador experimentado es aquel que ya ha cometido más errores y, por tanto, tiende a no volver a cometerlos o, al menos, a reconocer los errores cuando los encuentra más rápidamente que otro programador que no ha tenido esa experiencia. Además, muchos “errores” no son más que malas interpretaciones de requisitos o malas integraciones de sistemas distintos que no se habrían podido evitar sin cambiar las políticas de comunicación de la empresa (¿alguien recuerda el pufo de las distintas unidades de medida en la Mars Climate?).

Por más controles que se pongan, por mejores herramientas que se utilicen, por más que estemos concentrados en lo que hacemos el 100%, es imposible evitar la introducción de errores en el código que se produce. Las tareas de pruebas y depuración son muy importantes y determinantes a la hora de medir la calidad del resultado final. Intentar no pagar por esas horas es como invitar a alguien a comer y decir que los entremeses y el postre lo tiene que pagar él. ¿Qué invitación es esa?

Espero que vosotros no os encontréis esta situación que, por otra parte, no debería darse entre gestores formados y experimentados en el campo de la ingeniería del software. Hora que trabajas, hora que se paga. Si eres malo en lo que haces te pagarán menos por cada hora y terminarás en la calle, pero si eres bueno, igualmente cometerás errores (y los corregirás) en horas pagadas acorde a tus habilidades. El resto son milongas.

Los diseñadores web y el mercado

Diseño web

Dejadme que os cuente una historia…

Hemos decidido rediseñar completamente el interfaz web de BiblioEteca y, para ello, necesitamos contratar un nuevo diseñador web que tenga la capacidad necesaria para abordar este desafío. Puesto que el interfaz web es nuestro front-end y de nada sirven las funcionalidades maravillosas si los usuarios no pueden encontrarlas o si les parece poco profesional la presentación. Por eso requerimos que sea bueno-bueno y de confianza.

Dicho y hecho, nos ponemos a buscar y empiezo a preguntar a la gente que conozco que ha trabajado con otros diseñadores web para que me aconsejen según su experiencia y para evitar tener que poner anuncios en infojobs que siempre es más impersonal. Como recibo pocas recomendaciones me decido a ir un poco más allá y pedir por twitter diseñadores con ganas de trabajar.

A todos los que he contactado les he pedido lo mismo, que echen un vistazo a la web y que nos propongan algo sobre cómo reharían ellos la web, de esa manera podríamos ver si el enfoque que nos proponía se acercaba a nuestra idea y así poder elegir entre los distintos candidatos. ¿Os parece algo extraño?

El caso es que varios de los que se presentaron por twitter (igual es un defecto de la plataforma) se negaron en redondo a hacernos estas propuestas si no les pagábamos por ello. De hecho, incluso alguno nos sugería que había que estar muy desesperado para hacer tal cosa gratis. Cuando les pregunté cómo hacía un nuevo cliente para saber qué es lo que recibiría antes de firmar el contrato me decían que “es una cuestión de confianza”… Si, pero, ¿y si no puede haber confianza porque no se conocen cliente y diseñador?

En una de las primeras empresas en las que estuve desarrollé labores de preventa durante unos años. Estas labores consistían, básicamente, en asistir a los comerciales en la elaboración de sus propuestas, incluyendo elementos técnicos que los clientes podrían necesitar para evaluar correctamente nuestra oferta. También incluía hacer demos y preparar prototipos afuncionales de las soluciones propuestas. Es evidente que no se hacía el mismo trabajo para todos los clientes y que los contratos a conseguir debían justificar el trabajo, aunque claro, el ratio de consecución de contratos no era, ni mucho menos, el 100%, por lo que hacíamos mucho trabajo sin obtener ingresos a cambio… Es lo que se llama labor comercial.

Sin embargo la labor comercial entre los freelances (e incluso alguna empresa) del diseño web parece que no existe. Lo máximo que puedes conseguir son dos párrafos de copiar-pegar y un presupuesto que, al final, solo hace una valoración por hora. No se si es la desconfianza de estos profesionales hacia los potenciales clientes, creyendo que estos van a utilizar sus ideas sin pagarles o, simplemente, es que les sobra el trabajo y no ven rentable hacer actividad comercial. Es cierto que se dan abusos de muchos clientes pidiendo análisis casi completos sin soltar un duro, pero también es cierto que no puedes esperar que alguien te contrate sin darle garantías del resultado a obtener y, encima, pidiendo cobrar por adelantado.

A mi que una empresa me pida que le pague por mandarme una propuesta me sienta tan mal como que me quieran cobrar por enviarme un curriculum o que me pidan dinero para venir a una entrevista de trabajo. Si no hay labor comercial y no se dedica tiempo a convencer a un cliente no se merece el trabajo.

A seguir buscando…

Introdución a Enterprise Service Bus

Una de las características de esta época nuestra que estamos viviendo es el advenimiento de nuevas “tecnologías” de integración para, de una manera u otra, poder estandarizar la forma en la que se hacen estas tareas… Sin embargo, cada vez más estoy convencido de que solo es fuego de cobertura para mantenernos estudiando nuevos estándares en lugar de trabajar sobre lo que queremos… Tengo reservado ese tema para otro post, lo que quería contaros en este es el concepto de Enterprise Service Bus, representado por el estándar JBI o por productos como MULE. Recientemente he dado un curso sobre éste aspecto y os dejo a continuación el material utilizado. Espero que os sirva para algo:

Software utilizado para las demos:

Archivos adicionales:

Para más cursos, podeis consultar la página de Digimate, donde estamos empezando a liberarlos.