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.

Y aún creerán haber ganado

Después de la triste escena de ver como el consejo de ministros aprobaba, tal cual, la Ley de Economía sostenible con la “ley antidescargas” instalada en ella, aún me pregunto. ¿Creerán ellos que han ganado?

Cuando digo “ellos” me refiero a los magnates de la industria de los soportes “musicales, videográficos o telepáticos”, ya que los autores ya sabemos de antemano que no van a ganar nada más que las migajas que ya les dejaba la industria. Y refieriendome a esa industria, mi pregunta es: ¿Prohibiendo el acceso a las descargas por internet ganarán más dinero?

La respuesta es: NO, es sencilla, es directa… El mercado no va a dedicar más dinero a la música, ni al cine, ni a los libros. El dinero es el que hay y, a pesar de que se ha gastado más dinero en música el 2009 que en el año anterior (con P2P incluido), no hay expectativas de que se gaste más. ¿Qué han conseguido, entonces?

Han conseguido el equivalente a cerrar las bibliotecas. Esos sitios donde ibas y te dejaban un libro para leer sin pagar nada, ya que no querías o no podías comprartelo… En internet, las canciones y las películas son prestadas igual que en las bibliotecas: lo que no quieres comprar, lo tomas prestado de ahí. Lo que crees que vale dinero, lo compras, o vas al cine, o a un concierto.

Al igual que cerrando las bibliotecas no conseguirían vender más libros, sino cercenar el derecho de acceso a la cultura, cerrando las webs de enlace conseguirán lo mismo, pero aplicado al resto de cultura, disponer de un rebaño de borregos con menos acceso a cultura y más acceso a “medios afines” que aplaudan decisiones sin sentido como estas.

Espero que Alejandro Sanz y Rosarillo mientras descorchan el champagne y se ponen a cantar por bulerías (calculando cuanto ha costado el lobby y cuantos mercedes dejarán de estrenar por ello) se darán cuenta del gran error cometido. De la cantidad de personas que dejarán de escuchar su música o ver sus videos y de lo poco fiel que es la industria con los que ya no les dan dinero (y será dentro de pocos años).

Mientras, al otro lado de las barricadas, los pobres internautas tendremos ahora una inseguridad jurídica manifiesta. Nadie podrá poner una web en España sin ser amiguito de la nueva comisión “sin perdón”, ya que si el cierre de tu web no atenta contra los derechos fundamentales (no eres un periódico o similar) el juez dictaminará que no hay problema en cerrarla y será la comisión la que, alegremente, podrá poner el cartel de “cerrado” en la misma.

Así pues, cualquier negocio en internet se convertirá en posible blanco de una comisión arbitraria y sin control ninguno. Si mañana quiero poner una red social de admiradores de Nino Bravo y a alguno de los usuarios se le ocurre poner un enlace al torrent de su obra completa, igual me la cierran. Dando igual los euros invertidos o lo prometedor de la inversión en I+D para mejorar la tecnología del sitio… Vamos, que a nadie se le ocurrirá poner una web en el suelo patrio (a tomar por… los hostings nacionales).

Pero lo que es peor, es que esta ley abre un boquete inmenso en la libertad de expresión, al igual que en China, el derecho de lo que pueden ver los españoles en internet acaba de ser limitado… Y de la peor manera posible. Todavía queda el trámite de la aprobación parlamentaria… A ver si hay suerte y se les encienden las lucecitas del entendimiento y el sentido común.