archivo

Archivos Mensuales: febrero 2010

Ese es el título del libro que me acabo de leer y cuyo autor es Bernabé Tierno. Me ha encantado, ya que me ha proporcionado una visión conjunta de los aspectos psicológicos y biológicos que rigen la conducta de un ser humano. Os recomiendo la lectura del mismo, porque os aportará muchas cosas positivas y os ayudará a conocer mejor a ese ser tan cercano, pero que no por ello suficientemente conocido y que no es otra cosa que nosotros mismos.

Hasta ahora, los distintos libros que había leído de estas características se centraban en el comportamiento y en la psicología, ahora los pone en contexto con los procesos biológicos de nuestro organismo y con nuestra propia naturaleza física y para mi ha sido como encontrar una pieza de puzzle que me ha permitido interconectar determinados conceptos que tenía dispersos y que no terminaba de comprender del todo. Todavía tengo otros muchos sin conectar y sin comprender, pero es lógico, ya que la vida es un continuo aprendizaje y con el paso del tiempo seguiré encontrando más piezas de puzzle, ya sea en libros y/o en la vida misma.

Somos seres vivos, seres humanos, somos química y eso nos condiciona sobre manera, nos contextualiza y provoca reacciones y sentimientos que proceden de nuestro interior de forma inherente a nuestra naturaleza y que afectan a nuestro comportamiento para con nosotros mismos y con los demás. Que nos afecte, no quiere decir que no los podamos controlar de manera consciente o inconsciente, para ello será necesario evolucionar como personas, intentando conocernos mejor a nosotros mismos y a través de ello entender y empatizar mejor con nuestro entorno personal, tanto a las personas que amamos, como al conjunto de personas con la que nos relacionamos.

He hablado de evolución y no de transformación, ya que el desarrollo personal es algo gradual, con altibajos e imperfecto, es decir, que controlemos nuestros actos, nuestras reacciones y reenfoquemos nuestra visión de determinados aspectos de la vida, no quiere decir que caigamos muchas veces en reacciones viscerales, irracionales y nos dejemos llevar por la ira, ya que esto forma parte de nosotros mismos, de nuestra química y debemos respetar nuestra propia naturaleza de ser humano, pero lo importante es que cuanto esto suceda, que como he dicho sucederá en innumerables ocasiones, reflexionemos y aprendamos de ello y extraigamos como conclusión de que para evitar cada vez más este tipo de circunstancias, es necesario seguir evolucionando como seres humanos y trabajando para aprender cada vez más sobre nosotros mismos y sobre los demás.

Cuando Bernabé Tierno titula el libro como “Los pilares de la felicidad”, no lo hace por casualidad, ya que es una constante en ese tipo de literatura y es un hecho absolutamente real, no es ninguna teoría, el principal combustible de un ser humano es la felicidad. Si se es feliz todo lo demás es más fácil, incluso en aquellas situaciones que son muy cuesta arriba se afrontar de otra manera. No existe un índice que mida la felicidad (al menos yo no lo conozco), de hecho, como los altibajos, la felicidad y la infelicidad están interconectadas, ya que es difícil precisar en los límites inferiores de la primera y los límites superiores de la segunda dónde realmente está la frontera. Por tanto, a veces se estará más feliz, otras veces menos y en otras se será infeliz, pero eso la vida misma, una montaña rusa y sea cual sea la situación en la que nos encontremos debemos implementar los mecanismos necesarios para volver a una situación de felicidad.

Según Bernabé Tierno, la felicidad se sustenta en diez pilares: amor, humor, empatía, sabiduría, libertad, salud, motivación, valentía, autocontrol y la fortaleza y grandeza de espíritu, que debidamente desarrollados permitirán conseguir ese estado ideal para el ser humano que no es otro que ser feliz.

El hecho de que algunas operadoras hayan expresado en los últimos días que les gustaría pillar algo de la tarta de Google no es de extrañar. Como todas las corporaciones, buscan dinero y negocio por todos lados, está en su ADN y como tal es hasta comprensible que lo hagan, otra cosa bien distinta es que se les tenga en consideración en estos deseos o aspiraciones.

Por eso me resulta francamente decepcionante que un político, como nuestro actual ministro de Industria, Turismo y Comercio salga diciendo que “es una opción posible que hay que discutir y barajar”.

La neutralidad de la red es algo innegociable, ya que su ruptura terminaría con la red tal y como todos la conocemos, puesto que en un entorno donde se privilegiasen unos determinados tipos de tráfico o de contenidos sobre otros o simplemente no se permitiera un determinado tipo de tráfico o de contenido por no pagar una cuota o por no verificar algún tipo de criterio, terminaría siendo un entorno menos democrático, popular y abierto, en el que al final el criterio económico u otros interesen serán los que primen sobre el interés general.

He escrito algunos artículos en mi blog donde he tratado este asunto:

¿Qué pretenden algunos que sea la web 3.0?
Más sobre la batalla de los buscadores y de los contenidos: Rupert Murdoch mueve ficha
Neutralidad
Aporta tu granito de arena

Si una operadora quisiera finalmente intentar cobrar a Google (o a cualquier otro, porque Google es la punta del iceberg, después irían a por otros servicios y empresas que tenga ganancias en Internet) un canon (la propia palabra ya hasta resulta fea) por ganar dinero utilizando sus infraestructuras y se planteara tomar algún tipo de medida si no paga yo no querría tener nada que ver con ella en el caso de que fuera cliente suyo y probablemente a la mayoría del resto de clientes les pasaría exáctamente lo mismo. Los clientes ya estamos pagando el acceso a la infraestructura para acceder a información y servicios, si la infraestructura no me proporciona o no me quiere proporcionar la libertad para acceder a aquellos que estime conveniente, pues nos iremos probablemente a otro que sí nos la proporcione.

También Google se podría plantear cobrarle a las operadoras, ya que gracias a sus servicios (que han sido resultado de inversiones económicas multimillonarias en investigación y desarrollo y en adquisiciones), se ha podido promover un mayor uso de Internet, lo que ha redundado en un mayor número de clientes para las mismas. Esto sería tan absurdo como el planteamiento de las operadoras.

Yo espero que Google ni siquiera se plantee entrar a negociar con las operadoras porque sería darles cancha en un asunto donde no merecen tenerla.

Tenemos que tener muy claro que la defensa de la neutralidad de la red es esencial y que debe estar por encima de cualquier interés económico, político o de cualquier tipo y estar atentos ante los movimientos que se puedan producir en ese sentido que no van a parar, ya que por un lado a muchos no le gusta el nivel de libertad que hay en la red, a otros no les gusta que no puedan controlar lo que la gente lee o publica y a otros más les gusta por encima de otras cosas obtener beneficios económicos.

Sobre este asunto ya he tratado alguna que otra vez en mi blog, pero me viene otra vez a la cabeza tras una charla que mantuve sobre este tema hace unos días con un compañero.

Cuando se hace un sistema de información ajeno a la realidad de cómo los usuarios realizan un determinado proceso (y no me refiero en este caso necesariamente a que los requisitos se hayan recogido de manera equivocada, ya que lo mismo han sido algunos usuarios los que han dicho que el sistema tiene que funcionar de una determinada manera que rompe con la forma en que se están haciendo las cosas), se incrementan las posibilidades de que el resultado final disguste a los usuarios y se dificulte considerablemente su implantación entre los mismos, si es que no deriva finalmente en el fracaso del proyecto o en la realización de parche tras parche hasta obtener una solución que disguste menos a los usuarios y que será durante un tiempo prolongado un sumidero permanente de dinero.

La simple implantación de un sistema de información de por sí, ya supone un cambio para los usuarios y por regla general, todo cambio de estas características no suele ser bien acogido, ya sea sustituyendo a otro del que ya estaban más o menos acostumbrados (aunque no les gustara o estuvieran hasta las narices de él) o bien siendo un sistema que viene a dar soporte a un proceso no informatizado. Por tanto, los usuarios, van a estar en la mayoría de los casos recelosos con el nuevo producto e incluso estando perfectamente diseñado y ajustado a sus necesidades, si su objetivo era informatizar una actividad no informatizada, vendrá acompañado de numerosas quejas: “tardo más en hacer mi trabajo”, “no puedo tener la libertad que tenía antes al hacer mi trabajo”, “si el sistema no funciona, yo no puedo trabajar”, etc, etc, etc…, ya que nada, ningún sistema de información por más trillones de euros que nos gastásemos en él y por más que los diez mejores programadores y analistas funcionales del mundo hubieran trabajado en su desarrollo, podrá competir en agilidad respecto al uso de herramientas ofimáticas.

Por tanto, en la mayoría de los casos, los usuarios van a sentir un cierto rechazo sobre el nuevo producto, aún incluso sin conocerlo, este rechazo será mayor cuánto más modifique la manera en la venían trabajando hasta ahora. No se trata de clonar exáctamente lo que se venía haciendo, pero sí de proporcionar un sistema que cumpliendo unos objetivos mínimos de normalización de datos y de restricciones, les permita trabajar de manera ágil, de ahí que también sean importantes otros criterios como la usabilidad, la disponibilidad y el rendimiento. Una vez implantado el sistema y conseguido que los usuarios lo utilicen y se familiaricen con él, ya tendremos tiempo, siempre con el consenso de los usuarios temáticos del proyecto de ir moldeando el sistema con nuevas características que orienten, tanto la información que se guarda, como los procesos de trabajo que se realizan, hacia un modelo objetivo. Estos cambios deben ser siempre graduales. De esta forma, sí que existen más posibilidades de cambiar realmente una dinámica de trabajo, ¿qué hay que esperar más tiempo?, ¿qué hay que tener más paciencia?, ¿qué incluso el coste puede ser mayor?. Sobre lo de esperar más tiempo y tener más paciencia es cierto, pero mejor esto que no conseguir implantar nunca el proyecto o tener que sufrir un martirio para conseguir unos ratios de uso y de calidad del dato casi aceptables (que requieren además un tiempo importante para producirse). Sobre lo de que el coste sea mayor, desde mi punto de vista no es así, el coste de parchear, parchear y parchear, sumado a la reducción de la producción por parte de los usuarios, va a ser mayor que utilizando una estrategia más conservadora, pero más consecuente con la realidad de los usuarios.

La delegación de tareas es una de las actividades que nos resultan más complicadas a todos, independientemente del puesto que ocupemos y de las funciones que realicemos.

Ya he comentado más de una vez en este blog, que me resulta muy complicado delegar y la principal culpa de esto no la tiene ningún agente externo, sino que el problema está en mi mismo, en ser consciente de que por mucho que intente controlar o realizar personalmente determinadas tareas, ni mi capacidad de absorber trabajo ni mi conocimiento sobre determinadas materias, van a conseguir un resultado mejor que el que tendría la realización de esa tarea por parte de otro grupo de personas que tuvieran la oportunidad de seguir más estrechamente el trabajo y/o tuvieran una mayor experiencia o conocimiento sobre el mismo.

Es cierto que a veces para poder delegar es necesario tener personas (en calidad y/o en número) para poder hacerlo, pero también lo es que estas circunstancias pese a que existen, no son el principal handicap para delegar, ya que se puede tener un grupo reducido de personas en quien delegar y por tanto tener la posibilidad de asignar tareas a las mismas. Por tanto, el mundo ideal es tener una infraestructura de personas lo suficientemente amplia y preparada para poder delegar, pero como eso se va a dar en muy pocos casos, lo importante es que todo lo que podamos delegar lo deleguemos independientemente de que sean muchas o pocas cosas.

Una vez resuelto el primer problema que no es otro que entender que se es más eficiente delegando tareas que no haciéndolo y el segundo que no es otro que delegar todo aquello que sea posible de manera adecuada al conjunto de personas a la que podamos hacerlo, viene el siguiente problema que es la responsabilidad. La delegación de tareas no debe suponer el desentendimiento de las mismas, sino la posibilidad de poder asignar tareas que se encuentran bajo tu responsabilidad a otras, con el objetivo de que puedas tener más tiempo para hacer aquellas actividades más relevantes de tu trabajo y para que las tareas que se han delegado se puedan realizar con mayor eficacia.

Toda tarea que se delega es responsabilidad de la persona que ha realizado la delegación de la misma y por tanto debe velar porque se ejecute correctamente, debiéndose realizar el seguimiento que sea preciso, dar el apoyo y soporte que sea necesario y asumiendo personalmente cualquier problema vinculado a la misma. Por tanto, delegar no es soltar un marrón, ya que si bien no lo vas a ejecutar directamente, la responsabilidad sobre el mismo siempre va a ser tuya y así te lo va a exigir quien corresponda.

¿En cuantas reuniones con usuarios os han dicho frases como la siguiente?: “No me gusta ese color de fondo”, “me gustaría más otro tipo de de letra”, “a esa palabra se os ha olvidado ponerle tilde”, etc, etc, etc…, obviando o poniéndolos al mismo nivel o por encima de cuestiones funcionales, mucho más importantes. ¿Cuánto tiempo se ha perdido discutiendo sobre esos temas en lugar de en cuestiones más prioritarias?.

Hay un aspecto que suele fallar poco a la hora de vender un producto y es el envoltorio. Por dentro puede ser calamitoso, pero si es atractivo, tendrá muchas posibilidades de éxito. Al usuario final le dará igual si el programa está realizando siguiendo los principios de diseño por capas o si es es resultado de una serie de scriptlets jsp, lo que quiere es un programa de interfaz y usabilidad agradable, y por supuesto que funcionalmente llegue hasta el nivel requerido.

También resulta muy importante, que cuando se vaya a enseñar un prototipo, una beta o similar, se cuide mucho de que no existan faltas de ortografía, si se utilizan unidades de medida, especificarlas con la notación que haya especificado el usuario y se tenga la interfaz de usuario trabajada previamente, de lo contrario, si el objetivo es conseguir completar los aspectos funcionales de la aplicación, probablemente no se consiga y se requieran más reuniones y tiempo para alcanzar ese objetivo.

¿Quiero decir con esto que se debe olvidar uno de la calidad del software? No, nunca. La diferencia la marca precisamente la calidad del software, cualquiera puede programar, pero programar en condiciones y bien, requiere preparación, disciplina y experiencia. La facilidad para hacer software con envoltorios bonitos, es fácilmente igualable por cualquier empresa, lo que sí que resulta complicado es hacer un software de calidad, que permita en un futuro, realizar un mantenimiento más fácil sobre el mismo.
Es cierto, que también es más caro hacer software de esta manera, ya que requiere personal más cualificado o una mayor supervisión, pero este mayor coste de producción se verá paliado si se consigue un incremento de las ventas. La clave está en demostrar que a igualdad de envoltorios, el software desarrollado con calidad tiene una serie de ventajas tangibles para el usuario, que iran desde una reducción del número de errores, a una mayor eficiencia, pasando por una reducción de los costes de mantenimiento.

Evidentemente no es fácil hablar de esto con el usuario final, no dije nunca que fuera algo sencillo, pero si se tiene la habilidad suficiente para conseguir que te escuchen y demuestras que tu software es bueno, por fuera y por dentro, seguro que tu organización se habrá marcado unos cuantos puntos con dicho cliente para el futuro.

A lo largo de mi todavía corta experiencia profesional he tenido la oportunidad de vivir diversas migraciones, algunas de mayor y otras de menor calado. Entre las migraciones importantes destaco tres, por el impacto que tenían sobre el conjunto de sistemas de información de la casa, la migración de Oracle 8 a 9i, la migración de Oracle 9i a 10g y la subida de versión del sistema de autenticación y firma electrónica que utiliza mi organización.

De estas tres (y en general de todas las demás) puedo extraer las siguientes conclusiones:

1) La migración no es algo que se realiza en un día o en varios, sino que de por sí es un proyecto, por lo que debe tener una planificación, uno o varios responsables y un equipo que participe en ella.

2) Las migraciones afectan a varios departamentos dentro de informática, por lo que la comunicación entre todas las partes resulta esencial, así como la existencia de más de una persona que tenga una visión completa y general sobre lo que se está haciendo.

3) Las migraciones deben haberse simulado previamente en otros entornos y verificar el correcto funcionamiento de los sistemas de información en los mismos, es decir, previamente se deberán haber modificado todos aquellos sistemas de información que requieran un mantenimiento adaptativo al nuevo entorno y comprobar que tanto estos, como aquellos que no requieran cambio funcionan de manera adecuada. Todas las pruebas y modificaciones que se realicen sobre los sistemas deben estar perfectamente documentados.

4) Estos otros entornos deben ser idénticos al entorno de producción. Cuanto menos parecidos sean, más problemas nos encontraremos el día de la migración. La realización de la migración en estos entornos debe documentarse de manera detallada, destancándose todos aquellos problemas que se produjeron en el proceso de migración (ya que podrían aparecer el día de la migración).

5) Durante todo el proyecto de la migración es muy recomendable contar con el soporte de empresas expertas en los productos que se migran. Si ya es importante el soporte a lo largo del proyecto, es esencial que mientras se realice la migración, éste se encuentre presencialmente en la oficina en la que se realice la migración. Además de estos expertos, es importante contar con soporte sobre los sistemas de información más críticos afectados por la migración, valorándose si basta con que estén localizables o si es necesaria su asistencia presencial.

6) El proyecto de migración puede ser un proyecto de muy larga duración y eso es importante tenerlo presente, para evitar en precipitaciones que podrían dar lugar probablemente al fracaso de sucesivas intentonas de migración. Por tanto, sólo es recomendable migrar cuando se tenga muy clara la posibilidad de éxito de la misma.

7) Antes de realizar la migración, hay que tener claro que sistemas de información se van a ver afectados por la misma y por tanto no estarán disponibles una vez realizada la misma, ya que será necesario preparar los equipos de trabajo necesarios, para que una vez realizada la migración se pongan manos a la obra y adapten el sistema al nuevo entorno. Evidentemente dichos sistemas de información no deben ser críticos, y por tanto asumir una perdida de disponibilidad total o parcial sobre un conjunto de funcionalidades durante unos cuantos días. También como es lógico si hay algún sistema crítico que no va a funcionar tras la migración no es recomendable migrar hasta que este sistema se haya adaptado.

8) Si se espera a que todo esté perfectamente adaptado antes de realizar la migración, probablemente esta no se realice nunca. Por tanto, es esencial que los sistemas críticos estén adaptados y que la mayoría de los no críticos también lo estén, pero es necesario establecer un umbral a partir del cual la migración es realizable.

9) Es necesario documentar con detalle los diversos pasos que se van a dar el día o días de la migración y quiénes son las personas encargadas de realizar cada tarea. También es necesario que esté perfectamente documentada la posible vuelta a atrás. Dado que las migraciones cuentan con una ventana de tiempo para poder hacerse, con el objeto de disponer del mayor tiempo posible, es necesario que todas aquellas operaciones relacionadas con la migración que se puedan realizar previamente a la misma, se adelanten (siempre y cuando no afecten a los sistemas actualmente en producción).

10) Por muy bien que se haya realizado el proyecto de migración y se hayan tenido en cuenta buenas prácticas, del estilo de las que estoy comentando en mi artículo, probablemente se producirán imprevistos durante el proceso de migración, por lo que es importante saber de antemano que no va a ser un camino de rosas.

11) Desde mi punto de vista, la vuelta atrás debe ser siempre la última opción y sólo aplicarse cuando se tenga constancia de que la migración no se va a realizar con éxito. Esto no tiene por qué ser necesariamente tras horas y horas de intentar que todo quede perfectamente ajustado, sino incluso puede ser al principio de la misma. Por tanto, si surgen problemas que pueden intentar solventarse o al menos investigarse, hay que esforzarse por corregirlos y sólo volver atrás si dichos problemas son importantes y/o afectan a sistemas críticos y se llega a la conclusión de que no se van a resolver en la ventana del tiempo disponible para la migración.

12) Si hay que volver atrás o interrumpir el proceso de migración, no hay que venirse abajo, son cosas que pasan y por tanto, que no haya salido a la primera o a la segunda, no quiere decir que no salga bien más adelante. Además se habrá ganado en conocimiento que permitirá incrementar la garantía de éxito de los siguientes intentos.

13) Es muy difícil que una migración salga limpia, por lo que además de los flecos previstos, surgirán flecos imprevistos que se tendrán que corregir los días siguientes a la migración.

14) Es en las migraciones cuando uno se da cuenta más de lo importante que resulta que las aplicaciones estén diseñadas con una tecnología y arquitectura homogénea, que estén bien organizadas en los diferentes servidores de aplicaciones y que tengan una documentación de calidad. Cuanto más de estos ingredientes se tengan más sencillo será el proyecto y el proceso de migración y, por tanto, se reducirán las posibilidades de imprevistos.

Se me está insinuando que en uno de los proyectos que coordino podría sufrir otro importante recorte presupuestario (digo otro, porque en este proyecto es la constante en estos últimos años), hasta tal punto de que lo mismo la cantidad que queda para mantenerlo es testimonial.

Hace un tiempo me lo hubiera tomado muy mal y ahora mismo estaría tremendamente fastidiado, lleno de ira y frustrado porque desde mi punto de vista no se está haciendo justicia, con el tamaño del sistema, su número de usuarios y con todo lo que se ha conseguido desde que está en marcha. No obstante, pese a que la situación no me sea ni mucho menos indiferente, he conseguido interpretar esta contingencia de otra manera, con otro enfoque. No quiero decir con esto que si mañana me sucediera una situación similar fuera a reaccionar de la misma forma, pero sí que tengo que reconocer que estoy poco a poco evolucionando en este sentido y en este caso y de manera natural he conseguido ver aspectos positivos:

– Que se me esté insinuando el recorte no quiere decir que vaya a suceder. Sé que si se produce la reducción presupuestaria es porque no habrá más remedio debido a la situación económica actual, ya que el trabajo de mis compañeros y mío en el proyecto está ahí y está fuera de toda discusión. Además, aunque me pusiera hecho un basilisco, mis jefes no tienen una máquina de hacer dinero, luego sería energía desperdiciada en vano. Ellos saben que el proyecto por una serie de razones requiere de un buen presupuesto y que es necesario realizar una migración tecnológica en el sistema de información ya que la tecnología actual está obsoleta, además si no pueden derivar la cantidad de dinero que requiere, saben que puede haber problemas, están advertidos de esta circunstancia por mi desde hace bastante tiempo (y procuro recordarlo periódicamente) y conocen y comprenden los motivos.

– Si hay otro recorte, existirá un nuevo reto que consistirá en seguir intentando dar el mejor servicio posible con menos presupuesto. Esto ya lo hemos conseguido en los últimos años, con mucho trabajo y mucha imaginación. Si todavía hay menos no queda otra que seguir trabajando duro, seguir buscando soluciones creativas e intentar equivocarnos lo menos posible. No hay otra opción, ya que la alternativa sería tirar la toalla y esa no la contemplo.

Como es lógico no poseo una varita mágica, ni tengo un don especial, por lo que puede darse el caso de que tanto yo como mis compañeros no consigamos encontrar las suficientes soluciones para que no exista una merma significativa en la calidad del servicio, si esto sucede, solo quedará no rendirse y seguir intentándolo, que al fin y al cabo es lo único que podemos hacer.