Archivo de la etiqueta: Gestión

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

Dame un objetivo.

Hace unos días, tras el regreso de las vacaciones, un compañero me comentaba que tras la última reorganización aún no tenía claro en qué situación quedaba ni qué debía hacer, dado que su hasta entonces responsable ya no le comunicaba qué debía hacer, y su nuevo responsable estaba aún en la vorágine del cambio y no había hablado con él.

Le pregunté entonces sobre qué estaba haciendo, respondiéndome que seguía con el trabajo que le habían asignado antes de irse de vacaciones y realizarse los cambios, pese a que sabía (de forma no oficial) que posiblemente no valdría para nada.

 

Esto me hizo recordar la importancia de la comunicación en una empresa, pero también la necesidad de que en nuestro día a día tengamos siempre un objetivo claro y que asumamos como válido y útil, para poder afrontar cada jornada laboral.

En este caso claramente la comunicación no estaba funcionando al 100%, pero  en parte también porque, como supe después, desde arriba aún estaban por decidir las nuevas estrategias y objetivos a seguir.

Lo curioso del caso es ver cómo ante una falta temporal de liderazgo, este compañero (como otros más) habían optado por aferrarse a su anterior objetivo, pese a saber que no tendrá continuidad.

Esto me hizo pensar en que en una empresa, al igual que en un ejército en una batalla, todos necesitamos tener una serie de objetivos que nos ayuden enfocar nuestro trabajo y esfuerzos, y una persona que nos dirija hacia ellos.

 

No en vano, la palabra objetivo proviene de ‘ob-jactum‘ que significa ‘a donde se dirigen nuestras acciones‘, y no solo nos valen para saber qué buscamos cuando realizamos nuestro trabajo, si no también como refuerzo de la legitimidad de lo que hacemos (vamos por el buen camino/hacemos lo que debemos hacer) y evaluar nuestra eficacia y productividad.
Por todo ello, todos los que tenemos la responsabilidad de liderar o supervisar a un grupo de personas, desde los niveles más inmediatos a los superiores, debemos tener siempre presente no solo la necesidad de mantener los canales de comunicación adecuados si no también de ser consciente de que tengan claros sus objetivos.
Y además de transmitir los objetivos adecuados, asegurarnos de:

  • Mantener su validez o cambiarlos por unos nuevos ante cambios estratégicos.
  • Que sean realistas para que cada persona, o las personas, que los reciban crean en ellos y no los den de lado. Unos objetivos no creíbles, pueden ser aún peor que no tener objetivos claros.

 

No tener esto en cuenta, dejando que tu equipo, o equipos de trabajo, trabajen sobre objetivos poco claros, no realistas o sin la convicción de que sirvan para algo, terminan provocando situaciones caóticas y desmotivadoras que afectan negativamente al trabajo y la productividad.

Productividad, costes y salarios.

Asistía hoy a un aula virtual, donde se trataba el tema de la situación económica actual en España, el tema del ‘rescate’ por parte de la UE y posibles salidas a la situación.

El caso es que en la ronda de preguntas, tras haberse mencionado el tema de ‘bajar los costes salariales’ para mejorar la productividad, yo he preguntado:

¿La rebaja de los salarios no supone también penalizar el ahorro y lastrar la recuperación? Los salarios ya son bajos y antes de la crisis la facilidad de acceso al crédito sostenía el consumo y causaba un alto endeudamiento, pero hoy el consume cae y bajarlos lastra la recuperación.

Aquí la respuesta ha sido que reducir los costes salariales nos hace más competitivos, puesto que consigue que se produzca más barato y facilita las exportaciones (en el 1er trimestre del año la balanza comercial nos es favorable).

Y aquí, si bien reconozco que el argumento es válido, no puedo estar totalmente de acuerdo.

El hecho es que si miramos la relación entre productividad y costes, vemos que la relación es la siguiente:

Productividad = Producto Generado / Coste

Está claro que no descubro nada nuevo, pero normalmente cuando se habla de los costes, es habitual escuchar siempre el término ‘costes salariales’ como único coste, o al menos como único coste ‘reducible’.

Lo cierto es que esto no es así, puesto que en los costes entran varios factores, y aún ciñéndonos solo a los ‘salariales’  debemos tener en cuenta que este coste se compone de:

Coste por hora * hora de trabajo

Y de nuevo no descubro nada, ya que esta relación es lógica y conocida.

Pero aquí debemos plantearnos una cosa, las hora de trabajo ¿son todas efectivas?

Todos sabemos que en una jornada media de 8h obtener un 100% de horas efectivas es imposible, debido a las distracciones, los pequeños problemas del día a día o que simplemente las personas no somos máquinas que puedan trabajar 8h sin descanso.

Pero asumiendo esa realidad, lo único que nos queda de hora a obtener una mayor productividad, es asegurarnos de que las horas improductivas no se disparan y que las horas efectivas sean lo más productivas posibles.

Y aquí entran diversos factores, como son:

  • dotar a cada trabajador de las herramientas adecuadas.
  • realizar un análisis de riesgos que nos permita adelantarnos a los problemas que puedan bloquear el trabajo.
  • identificar las tareas que no dependen de nosotros, pero requerimos o requeriremos en algún momento, y coordinar los esfuerzos de los equipos involucrados para evitar retrasos.
  • tener una planificación clara y accesible para que todos sepan qué deben hacer y cuándo…

En el mundo del desarrollo software hace tiempo que se vienen haciendo esfuerzos en este sentido, con modelos como el de CMMI que en su nivel 4 ya contempla estas cosas:

4 – Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos. El
software resultante es de alta calidad.

Así, cada vez más empresas que se embarcan en obtener la certificación, muchas veces exigida por grandes clientes y administraciones públicas, van incorporando formas de contabilizar las horas trabajadas y las métricas asociadas a la productividad.

O con frameworks de trabajo como Scrum, en los que además de buscar un mayor conocimiento de la propia capacidad del equipo y su avance, las figuras del Scrum Manager o el Product Owner ayudan a la hora de orientar los esfuerzos de una forma mucho más eficaz.

Pero fuera del mundo SW y de las grandes empresas que se embarcan en obtener estas certificaciones e incorporar métricas e indicadores de productividad, la norma general es encontrarse con innumerables empresas que descuidan muchos estos aspectos.

Desde empresas que no han automatizado muchos procesos, que no conocen mayor informatización que la de comprar PCs y un programa de contabilidad para su departamento de administración, o que simplemente no consideran analizar sus procesos de trabajo para ver dónde mejorar y ganar tiempo en sus tareas diarias.

Incorporar un CRM que te ayude a dar un mejor servicio a tus clientes, para que sus pedidos sean más cómodos y nos roben menos tiempo, o conocer las bondades de un BPM que nos ayude a conocernos mejor, identificar donde podemos mejorar o cambiar para ser más eficaces, son realidades al alcance de muchas empresas que por desgracia aún ven con reticencia y poco útiles.

Por todo esto es por lo que creo que a la hora de hablar de productividad, no solo debemos contar con los costes salariales como única variable de ‘abaratamiento’, si no que también debemos pensar en mejorar nuestras estructuras y procesos como empresa, como vía de reducir nuestros costes totales y mejorar la productividad.

Sirva un ejemplo:

Un desarrollador que diariamente emplea un 25-30% de su tiempo de trabajo en esperar a que determinados procesos (compilación, despliegue, rearranque de servidores, etc…) finalicen para poder continuar.

Quizás su equipo no sea el adecuado porque cuente con un viejo PC obsoleto, o el entorno de desarrollo o pruebas no es el adecuado.

Y aquí una inversión de unos 1000€ (el precio del HW en la actualidad ha bajado mucho)  podría suponer reducir ese 30% a un 10%, con lo que si el coste por hora es de 30€, un 20% de mejora supondría un ahorro de 48€ diarios (8h*30€ = 240€ diarios), es decir, en 21 jornadas de trabajo (1 mes) habríamos recuperado la inversión realizada y empezaríamos a ahorrar en costes.

Obviamente no siempre es tan sencillo ver el ahorro, pero una consultoría (aunque a priori nos parezca otro ‘gasto’) puede mostrarnos áreas de mejora, aconsejarnos soluciones y cómo modelar nuestro negocio para ser no solo más productivos (y por tanto más ‘baratos’) sino además más eficaces.

Si nos fijamos en nuestro sector, las empresas de mayor renombre (Google, Microsoft, Atlassian, …) son conocidas por los profesionales, entre otras cosas por pagar cifrar desorbitadas a sus desarrolladores.

Volviendo a la formula apuntada:

Productividad = Producto Generado / Coste

queda bien claro que mejorar la productividad no solo se consigue bajando el coste. También se consigue mejorando el valor Producto Generado, y esta parte es la que se olvida habitualmente.

Es muy facil cuadrar presupuestos al principio del proyecto bajando el salario. Pero, ¿que pasa con el presupuesto cuando ha pasado el 150% del tiempo planificado para hacer el proyecto y aquello no hay por donde agarrarlo?

En Madrid, por experiencia, si contratas a un desarrollador por menos de 22.000€, bajas los costes, pero consigues, iba a decir trabajo basura (que también), pero queda mas claro si digo Producto basura. Y ojo, es posible tener auténticos cracks contratables por debajo de 22.000€, en la misma proporción que puedes encontrar un Cristiano Ronaldo por menos de 1 millon de € de traspaso.

Entre 22.000 y 30.000 hay mucha mediocridad y algunos valores con futuro, pero tu equipo de desarrollo por esos precios de media, no van a hacer un Producto decente.

Sin embargo, por encima de 40.000, y teniendo cuidado con lo que se contrata, puedes aumentar exponencialmente el valor de tu Producto. Y es que, por mucho lo parezca, 2*22.000 no es igual a 1*44.000,  es bastante menor os lo puedo asegurar.

Ya lo decía mi abuela, que no era directiva ni se había pagado ningún Master en una escuela de negocios, “hay hijo, un día de darás cuenta de que, lo barato, a la larga,  sale caro”.

Claro que los que piensa que no es así, son los mismos que piensan que 9 embarazadas hacen un niño en 1 mes, porque caen en el recurrente error de considerar al valor humano como un mero ‘recurso’ y considerar a todos sus ‘recursos’ como igual de productivos y válidos.

Por último, un par de gráficos y un artículo que vienen a corroborar lo dicho, donde podemos ver que la productividad española está en la media de la UE (desterrando el mito de nuestra baja productividad), donde los más productivos no son los países con manos de obra más barata, pero sí los que cuentan con mano de obra cualificada (y bien remunerada) y empresas que apuestan por innovar y mejorar.

Expansión:

¿Quien trabaja más en Europa y cual es el país más productivo?