Archivo del Autor: mvcarrillo

Conceptos caducos.

Retomo el blog, tras mucho tiempo sin tiempo para actualizar, repasando algunos conceptos caducos pero aún presentes en la mayoría de empresas, que son origen de muchos problemas.

  1. Conocimiento es poder.
  2. Opacidad
  3. Horarios
  4. Jerarquías
  5. Enchufismo

Caducidad

Conocimiento es poder.

Fue Sir Francis Bacon quien pronuncio esta frase, pero estoy seguro de que cuando la dijo no pensaba en las connotaciones negativas de la misma.

Cierto es que disponer de conocimientos proporciona una ventaja sobre el resto, más aún cuando eres el único que los posee en su totalidad.

Pero en la actualidad este concepto puede perjudicar más que ayudar cuando hablamos del global, de la empresa, pues es un mundo donde el conocimiento se transmite a la velocidad de la luz y se encuentra a unos pocos clicks de distancia, son muchos los que han optado por defender su posición secuestrando dicho conocimiento.

Mucha veces es la inseguridad a perder ese poder o ventaja sobre los demás, la que ha llevado a muchos a crear espacios estancos donde puedan controlarlo todo mediante la exclusividad de los conocimientos que se aplican. De esta forma en muchas empresas se crean ‘chiringuitos’ donde alguien ostenta el máximo poder, controlando a quien trabaja para él y no permitiendo que nada salga del mismo.

¿Problemas?

Por una parte se convierten en ‘imprescindibles’, dado que son los únicos que lo saben todo. Por otra parte impiden la lógica evolución de tu negocio, el cambio necesario para mejorar y ser mejores, manteniéndose en desventaja contra otros competidores o generando altos costes al no permitir que se optimicen procesos o se creen mejores soluciones.

Y muy importante también es que la gente que cae en uno de estos departamentos estancos tiene poca movilidad dentro de la empresa, al limitarse su visión y conocimientos a lo que allí se hace, perdiéndose las ventajas de compartir experiencias y conocimientos con otros grupos dentro de la organización.

Opacidad.

opacidad

Del lat. opacĭtas, -ātis.

1. f. Cualidad de opaco.

opaco, ca

Del lat. opācus.

1. adj. Que impide el paso a la luz, a diferencia de diáfano.

2. adj. Oscuro, sombrío.

3. adj. Triste y melancólico.

Cuando hablo de opacidad me refiero a la falta de transparencia, a esas empresas donde la información apenas circula pero más allá de esos espacios estancos a los que me refería en el primer punto.

La falta de fluidez entre las capas o estratos dentro de la jerarquía de la empresa, cuando información importante sobre los objetivos y políticas de la empresa (o incluso su buena o mala marcha) no se transmite, manteniendo a quien está por debajo en tinieblas y sin saber qué se hace, hacia dónde se va o cómo encaja su trabajo dentro de la empresa.

El problema con este punto es el malestar que se genera, la inseguridad de no saber si lo que se hace es importante o no, o la incertidumbre sobre la viabilidad de la propia empresa cuando las cosas no van bien y surgen los rumores.

 

Horarios.

Este es un punto importante y muy en boga hoy en día con el tema de la conciliación laboral.

Dentro de las tareas que una persona puede realizar siempre habrá tareas para las que necesite interactuar directamente con otros, y tareas que puede realizar solo.

Hoy en día la tecnología nos permite ahorrarnos miles de euros en viajes para acudir a una reunión con un cliente (sobre todo si está en otro país), mediante tele o video conferencias.

Pero a nivel de empresa, aún sigue muy arraigado el concepto de horarios estrictos y poco flexibles que hay que cumplir a rajatabla, que pueden suponer un problema para quienes tengan familia y deban cuidar de ellos, para quienes son más productivos a horas del día distintas a las habituales, o para quien tiene que realizar un largo desplazamiento diario para acudir a un centro de trabajo.

Obviamente la actividad de una empresa debe regirse por un horario siempre que se pueda, pues ayuda a coordinar esfuerzos, pero hay que ser flexible cuando se pueda y la gente lo requiera.

Un padre o madre que pueda acudir sin prisas a recoger a sus hijos a la salida del colegio, o que pueda quedarse a trabajar en casa cuando lo requiera. Una persona que pueda ahorrarse 2-3 viajes semanales, ahorrando tiempo y dinero, cuando sus tareas y planificación lo permitan.

Todas esas personas valorarán más positivamente nuestra empresa y la comodidad que les proporcionamos, considerándolo un valor añadido.

Jerarquías.

De acuerdo, un barco siempre necesita un capitán, pero ese capitán debe liderar más que mandar, y sobre todo dejar que quienes le acompañen en su travesía hagan su trabajo.

El exceso de jerarquía, el exceso de personas que ostentan algún cargo con capacidad de decisión o de bloqueo, nos perjudican al hacer que nuestra empresa sea mucho menos ágil de lo que nos convendría.

En un mercado tan global, donde todo se sucede tan deprisa, ser lento es lo peor que puedes ser para competir y participar en los negocios.

Por ello tener un exceso de ‘jefes’ supone un enorme lastre cuando las decisiones que no deberían llevar más de unas horas o días, se convierten en paseos de meses en los que perdemos cualquier tipo de ventaja y nos obliga a ir siempre a remolque.

O cuando dificultan que las decisiones y políticas de empresa, se difundan con la suficiente rapidez y claridad a todos.

Además las enormes jerarquías añaden más opacidad, generan más departamentos estancos y son confusas para el resto de trabajadores que cuando miran hacia arriba solo ven un montón de jefes que en lugar de ser aliados se convierten en escollos que salvar.

Una estructura más plana, donde se reduzca el número de jefes pero se permita que emerjan más líderes, es mucho más cómoda para los trabajadores y más efectiva para la dirección.

 

Enchufismo.

Seamos claros, pese a que muchas empresas hayan intentado tomar medidas, el enchufismo sigue estando a la orden del día.

Seguro que muchos podríamos explicar casos claros en el día a día de nuestro trabajo, donde familiares de algún jefe o ese ‘colega’ se ven continuamente beneficiados desde arriba, hagan lo que hagan (o lo que es peor, aunque no hagan nada productivo).

La primera consecuencia es el malestar entre los trabajadores, que tienen que soportar al enchufado de turno y ver cómo promociona mientras ellos siguen estancados.

Luego están los errores cometidos por personas que ostentan puestos a los que han accedido sin estar preparados, que además suelen repetir en sus errores al sentirse protegidos desde arriba, que acarrean costes extras por planificaciones no cumplidas o cumplidas con deficiencias importantes.

Aunque para mí el peor es que mata cualquier tipo de iniciativa en el resto, que o bien terminan marchándose o bien se acomodan a lo que hay tras perder cualquier ilusión de progresión.

Por ello, es importante que una empresa se base en la meritocracia, recompensando los esfuerzos y méritos individuales y de grupos, para conseguir una mayor implicación en el trabajo diario.

El juego de equipo.

Al ver esta mañana en las noticias que en la final de la NBA, los San Antonio Spurs habían sorprendido a los Miami Heat y ganado el primer partido fuera de su casa, he recordado un vídeo que quería compartir con vosotros.

El vídeo es un homenaje a un equipo, los San Antonio Spurs, y el juego de equipo que han logrado perfeccionar a lo largo de varios años de trabajo, con el que se han venido imponiendo a las grandes individualidades del que han hecho gala otros equipos.

De este vídeo podemos extraer algunas lecciones útiles en nuestro trabajo diario y en especial con nuestros equipos:

  1. Los grandes jugadores son brillantes, pero los grandes jugadores que juegan en equipo lo son aún más.
  2. La suma de los talentos de un equipo que trabaje junto es mayor que la suma de cada talento individual.
  3. Una gran estrella puede ganar un partido, pero un gran equipo puede lograr mayores logros.
  4. En un gran equipo lo importante son los logros colectivos, por encima de los individuales.
  5. Un gran líder es capaz de aprovechar lo mejor de sus compañeros y construir grandes jugadas de equipo.

Y estas son tan solo las 5 primeras que me vienen a la mente, seguro que se pueden sacar muchas más.

Y vosotros ¿sois más de jugar en equipo o de jugadas individuales?

Desarrollo, mantenimiento… evolución (I)

Llevo desde hace tiempo con la idea de escribir esta entrada, a partir de experiencias personales en el mundo laboral, y la noticia sobre el fin de soporte a Windows XP por parte de Microsoft me ha animado a escribirla.

Podemos leer en Tweaktown.com la siguiente noticia:

ATM operators to replace Windows XP with Linux.

Many banks and ATM operators are making plans to migrate its ATM systems to Linux as Windows XP’s support will no longer be provided from April 8th. The report indicated that this will allow companies and operators to have more control over the hardware and software of the machines.

Si habéis estado atentos a las noticias de tecnologías de los últimos meses, ya sabréis que Microsoft anuncio el fin de soporte a Windows XP hace unos cuantos meses.

Anuncio fin soporte XP

Algo normal si pensamos en que el veterano SO de Microsoft cuenta ya con 12 años de vida, que ha sido parcheado muchas veces y ha recibido hasta 3 Services Pack en todos esos años. Muchos dirán que todo esto no es más que una estratagema para obligar a los usuarios a migrar a Windows 7 o Windows 8 (el primero tiene mucha más aceptación en las empresas), pero lo cierto es que habiendo probado XP y W7 debo decir que me quedo con el segundo de lejos.

Aunque Windows XP supuso en su día un SO de éxito y un soplo de aire fresco en comparación con W98, NT o W2000 en las empresas, no está libre de sus ‘achaques’ y pegas, como su progresivo deterioro en su rendimiento a medida que pasa el tiempo.

Además de que nunca ha contado con una versión de 64bits en condiciones, quitando una versión que tenía sus problemas, lo que en un entorno donde lo habitual son equipos con un mínimo de 4GB de RAM supone desperdiciar recursos por culpa de las limitaciones de XP.

Pero lo realmente llamativo de todo este asunto, no es que XP desaparezca, sino el hecho de que haya pillado a tantas y tantas empresas con el pie cambiado, y que sus respectivos departamentos de TI no hayan previsto antes esta eventualidad (más aún en un sector como el bancario).

Nada es para siempre.

Efectivamente, como dice el dicho no hay nada eterno, y mucho menos en el mundo del Software donde todo discurre a una velocidad de vértigo.

Sin embargo, aún es muy habitual encontrarse con software ‘heredado’ (Legacy Software) de una época anterior que de repente, como en el ejemplo de Microsoft y XP, pasa de ser una verdad absoluta a ser un quebradero de cabeza para los responsables de TI o del propio software porque ‘se queda desfasado’.

Entonces, de repente, ese software que hasta entonces nadie cuestionaba y todos usaban, al que tan solo había que dedicar un poco de mantenimiento, pasa a ser considerado con uno o varios de los siguientes adjetivos: obsoleto, anticuado, ineficaz, desfasado, problemático, inútil…

Pero si nos fijamos, resulta que la mayoría de calificativos se pueden unificar en uno solo: antiguo.

Antiguos Sistemas Informáticos

Pero, realmente ¿es algo que ha sucedido sin más de un día para otro?

En realidad no, pero en este mundo del Software, como mencionaba antes, el tiempo es aún más inexorable de lo habitual y lo que hoy se considera ‘moderno’, en apenas unos cuantos años se ve superado por los avances que surgen, y más adelante se van quedando obsoletos porque nada permanece inmutable, ni el software, ni nuestra empresa, ni nuestro método de trabajo, ni nuestros productos y ni siquiera nosotros mismos.

Y si hablamos de sistemas que surgen ligados a plataformas hardware propietarias, o que con el tiempo no evolucionan como la competencia y se van quedando atrás, o simplemente no tienen la debida acogida y son descontinuadas, el problema es aún más grave puesto que ya no se trata solo de que nuestro software esté ‘mayor’, sino que encima el hardware sobre el que funciona también puede fallarnos y encontrarnos con el problema de no poder encontrar ni los repuestos necesarios.

Pero, ¿podemos evitarlo o al menos prevenir futuros problemas?

Trabaja en el presente, pero pensando en el mañana.

Hace años, cuando la Informática empezó a llegar a las empresas (antes de hacerlo masivamente en los hogares) lo habitual era ver cómo una empresa se gastaba mucho dinero en adquirir sistemas propietarios que se iban amortizando a lo largo de los años. Eran sistemas que se adquirían pensando en que durasen muchos años, en una época en que las innovaciones iban llegando más despacio, lo que daba margen a acometer en un momento dado del futuro la migración de estos sistemas a futuros sistemas (compatibles o no).

Y quizás de aquella época también se ha heredado ese pensamiento de que el sistema que empecemos a diseñar hoy y al que migremos mañana, vendrá para quedarse durante mucho tiempo o será una solución casi eterna.

Pero lo cierto es que aunque incluso los sistemas en sí, nuestra aplicación, pueda tener una vida ‘larga y próspera’, deberemos de tener siempre un ojo puesto en el futuro. No solo por las futuras funcionalidades que debamos de integrar el día de mañana porque nuestro negocio evolucione, o las que debamos actualizar si nuestro negocio cambia, sino también por los cambios tecnológicos que surgirán:

  • Evolución del hardware.
  • Evolución del Sistema Operativo.
  • Evolución de los COTS (Software de terceros) que utilicemos.
  • Evolución de los Lenguajes de Programación.

Así, si lo que estamos estudiando es integrar un Software de Terceros al completo (por ejemplo un sistema SAP) deberemos de tener en cuenta además de lo obvio: ¿soluciona mis necesidades y requisitos?; cosas como cuál será su evolución, tiempo de vida y soporte de la empresa propietaria a la versión que adquiramos, si el software está ligado a una plataforma hardware cerrada o podemos cambiarla sin un gran impacto, cómo de complejas son las migraciones entre versiones, el coste de dichas migraciones (en tiempo y dinero por los upgrades a versiones superiores), o incluso el software que usa por debajo para estar seguros de que en el futuro no nos dejarán colgados.

Y si nuestro caso es el de contratar un desarrollo a medida, además de los puntos anteriores también deberemos tener en cuenta las características más técnicas de la solución que nos propongan:

  • Arquitectura SW de la aplicación: escalabilidad (en el futuro puedo necesitar más servidores), flexibilidad (para incluir nuevas funcionalidades, incluso debiendo mantener las antiguas o distintas versiones de la misma funcionalidad), robustez, seguridad…
  • Arquitectura HW: ¿va ligado a un HW específico? ¿puedo instalarlo en el HW de otro fabricante sin problemas?
  • Lenguaje de implementación: versión usada para el desarrollo, conocer los ciclos de vida de las versiones y si se asegura retrocompatibilidad, cómo de conocido y aceptado está por la comunidad de desarrolladores (un lenguaje muy potente pero poco conocido dificultará encontrar gente que lo mantenga o evolucione), si hay más empresas que trabajen con él (en un momento dado podemos querer cambiar de proveedor).
  • COTS: quién los evoluciona y da soporte, si están basados en estándares o son propietarios, si requieren de contratar soporte externo, compatibilidad de los mismos entre ellos, con la plataforma HW o con el lenguaje que los implementa.

El haber previsto en mayor o menor medida todo esto nos ayudará a poder migrar nuestros sistemas, ya sea de forma total o solo en lo que respecta al SW de base y/o plataforma que usemos, consiguiendo así que no solo no se quede ‘antiguo’, sino que su vida útil se pueda alargar.

Tener en cuenta además de que en el caso de desarrollos de grandes sistemas a medida, desde el momento en que se toma la decisión de diseñarlo y solicitar su desarrollo, hasta su puesta en funcionamiento pueden haber pasado 2-4 años, tiempo más que suficiente para que la vida útil del HW o los COST usados se haya reducido a unos pocos años más.

En la próxima entrada, veremos con un ejemplo real cómo se detectó y solventó una de estas situaciones.
photo credit: x-ray delta one via photopin cc

Backups en Android.

En la entrada sobre el error de “Mala conexión inhabilitada” me he encontrado algún comentario sobre las reticencias a hacer un Factory Reset para resolver el problema.

Para ayudar a los indecisos os dejo un par de formas de reducir el impacto de hacer este Factory Reset.

La primera es aprovechar la funcionalidad de Copia de Seguridad de Google:

Habilitando esta copia de seguridad, cuando hagáis el Factory Reset y volváis a ingresar vuestra dirección de GMail, se descargarán las aplicaciones y configuraciones que tuvieseis antes (hacerlo vía WiFi).

Copia de Seguridad.

Copia de Seguridad

La segunda es usar una aplicación de backup, como ‘MyBackup Pro’, que permite hacer un backup de aplicaciones, datos, imágenes, registro de llamadas y SMSs, para posteriormente restaurarlo.

 

MyBackupPro

MyBackupPro