archivo

Archivo de la etiqueta: rendimiento

El único combustible de larga duración de la productividad somos nosotros mismos. Nuestra visión sobre el trabajo, sobre lo que creemos que debemos hacer y comportarnos y los objetivos personales que nos fijemos son el verdadero motor de nuestros actos en el ámbito laboral y lo que nos ayudará a continuar de esta forma. También nuestra formación y experiencia personal y profesional contribuirán a su durabilidad.

Hay acelerantes de la productividad, como por ejemplo notar que se consiguen resultados, el reconocimiento, la consecución de objetivos parciales o finales, etc… que incrementan la motivación y como consecuencia la productividad. Estas circunstancias son como chispas, pueden incrementar nuestra productividad un tiempo, pero una vez pasado su efecto se volverá al estado anterior (en el mejor de los casos) ya que en ocasiones estos subidones tienen como efecto secundario su adicción de manera que si no sentimos una de estas circunstancias puede ocurrir que entremos en un bucle de dudas (¿lo estaré haciendo bien?, ¿sirve para algo todo esto?, ¿por qué me cuesta tanto sacar adelante esta tarea?, ¿por qué ahora no me dicen que les gusta lo que hago?, etc…) que dará lugar a una reducción de nuestro rendimiento, principalmente por una pérdida de confianza en nosotros mismos (algo totalmente injustificado ya que la confianza no es algo que transmita un virus o nos llegue por ósmosis, la confianza nos la creamos nosotros mismos y nadie más, por mucho que nos digan que hacemos bien o mal nuestro trabajo, la única valoración que debe valer para nuestras tareas es la que nos hagamos nosotros mismos y cada uno de nosotros sabemos si hemos podido dar en un proyecto o en una tarea todo lo que se podía acorde a las circunstancias individuales de cada uno y del contexto del trabajo encomendado).

También hay retardantes de la productividad como el hecho de que no se valore de manera objetiva o justa nuestro trabajo de manera que impida la consecución de determinados hitos u objetivos personales, como por ejemplo, ascensos, mejoras de las condiciones laborales, aumentos de sueldo, etc… Cada uno de nosotros conoce perfectamente, tal y como he comentado en el párrafo anterior lo que nos merecemos en el ámbito laboral, para ello es necesario hacer autocrítica y mirar con una visión imparcial hacia afuera (lo mismo he trabajado bien, pero hay otros que lo han hecho mejor, lo mismo he trabajado bien pero las circunstancias de la organización no me permiten cumplir los objetivos). Si percibimos que se ha sido injusto con nosotros, eso crea desmotivación y desconfianza lo que tendrá efectos negativos en la productividad (y más duraderos que la chispa que mencionaba anteriormente, ya que la rabia tarda más en eliminarse). Al final, para alcanzar de nuevo el equilibrio ya sea en la misma organización o en otra (si se decide cambiar de aires al no atisbar vías de solución) es siempre importante la existencia de esa base personal que constituye la productividad de cada individuo.

Ya nos pasó a todos cuando estudiábamos. Cuando más conseguíamos rendir era en los días previos a los exámenes. Muchas veces ese sprint final permitía que llegásemos al aprobado o consiguiéramos mejores notas, pero si se dejaba todo en manos de ese último impulso podría ocurrir que no diera tiempo de estudiarnos todo el temario con la suficiente profundidad y suspender (o no sacar la nota que nos habíamos marcado como objetivo).

Los seres humanos somos así, la cercanía del momento decisivo hace que nos pongamos las pilas y empecemos a rendir con el nivel que hubiéramos deseado desde el principio.

En el proceso de desarrollo de software se repite, como no podría ser de otra forma, esta máxima, normalmente la proximidad de una fecha de entrega mejora el rendimiento y productividad del equipo (por regla general, también la cantidad de tiempo que se dedica al proyecto, empujado por la necesidad de querer cumplir los plazos). También es cierto que la mala evaluación de las fechas de entrega, siendo demasiado exigentes en muchos casos, obliga en gran cantidad de ocasiones a hacer este sprint final por mucho que se apriete o se mantenga un nivel alto de rendimiento en todo el proyecto.

Por tanto, el sprint final va a ser necesario en la mayoría de los proyectos de desarrollo de software (esos famosos picos de trabajo), que va a durar más cuanto peor esté estimado el proyecto en tiempo y/o recursos (picos de trabajo continuos (y que darán lugar además de tener quemado al equipo del proyecto a una merma en la calidad del producto y a un más que probable retraso en la entrega)) pero que en cualquier caso es necesario mantener un ritmo constante para terminar el proyecto en fecha, ya que si no se ha avanzado lo suficiente antes del sprint final será muy complicado que se puedan cumplir los plazos con un nivel de calidad aceptable.

Hace bastante tiempo comenté en un artículo que mis mayores logros profesionales hasta la fecha han sido conseguidos gracias a trabajar con el equipo de personas con el que he colaborado en cada uno de mis proyectos.

También comento muchas veces que es bastante fácil conseguir títulos con el Barcelona o con el Madrid, pero que lo difícil es conseguirlo con un equipo de tercera división. Yo tengo la suerte de trabajar con personas de nivel de Champion League, por lo que el resultado de los trabajos tiene ese nivel y si alguna vez no se consigue la culpa no es exclusiva del equipo (todo gran equipo juega, en ocasiones, malos partidos), también lo es mía (en gran parte) y del público (el conjunto de usuarios).

Lo que es complicado realmente es sacar rendimiento de personas que carecen de ese nivel y conseguir que ejecuten un trabajo más que digno y a la altura de personal con mayor talento. Esas personas, las que son capaces de conseguir sacar los proyectos hacia adelante buscando recursos hasta debajo de las piedras y sacándoles el máximo partido son las que realmente tienen mérito.

Es evidente que una organización debe buscar siempre contratar el personal con el mayor talento y nivel de implicación posible, pero hay veces que se falla, que el mercado no ofrece más o bien que es necesario que pase un período de transición y aprendizaje (que puede durar más o menos tiempo, en función de cada persona) y es sacar el mayor partido posible de estas personas donde está la clave y el mérito, ya que al fin y al cabo a la organización le suponen un coste y son recursos que no pueden ser sustituidos por otros, por lo que la clave está en darles su sitio, asignarles un trabajo en el que puedan rendir y ser provechosos para los proyectos, ¿qué a veces pueden resultar un lastre? sí, pero si no se intenta poner un remedio, si no se trata de buscar una solución, el lastre continuará siempre ahí, si se intenta por lo menos se da la oportunidad de revertir la situación y que la persona sea cada vez más de utilidad para el proyecto. Si una persona puede ahorrar al resto del equipo de proyecto una hora diaria de trabajo, ¿no será mejor esto que no ahorre nada de trabajo?, ¿y si dentro de un mes ahorra una hora y media?, ¿y si dentro de dos ahorra una hora y tres cuartos?. Conozco personas que empezaron de grabadores de datos y hoy en día son directores regionales de importantes empresas TIC (y por méritos propios), por eso nunca hay que menospreciar la capacidad de progresión de una persona y la posibilidad de sacarles el mayor rendimiento, hay personas que son capaces de rendir extraordinariamente a la semana de empezar a trabajar y otras que necesitan un par de años.

Muchos de vosotros, pensaréis, ¿no será mejor echar a quién no rinda y contratar a alguien que sí rinda? Evidentemente esa es la solución más fácil, pero no siempre se puede aplicar. Hay circunstancias donde si la personas después del rodaje siguen sin funcionar (sobre todo por falta de implicación o voluntad) es recomendable que se prescinda de ellas, ya que a mi juicio gran parte de la falta de talento se puede suplir con trabajo y voluntad, pero si no existe esa voluntad por mejorar o ese nivel de implicación con la empresa lo mejor es que cada cual, empresa y trabajador, busquen caminos distintos. Lo mismo la empresa o sus superiores no han sido capaces de motivar al trabajador o el trabajador no ha sido capaz de motivar a la empresa sobre su continuidad (nunca la culpa es de alguien al 100%).

Por tanto, tan importante son las personas que son capaces de sacar proyectos hacia adelante con las mayores ganancias posibles, como aquellas que son capaces de hacer madurar a los recursos humanos de la organización, haciéndolos mejores y más válidos.

Hace unos meses en una reunión donde se proponía el desarrollo de un gran sistema que gestionaba un proceso importante de mi organización, el cual también existía en el resto de organizaciones que comparten el mismo paraguas institucional, uno de los participantes de la misma dijo que los sistemas centralizados estaban obsoletos, anticuados y que lo que molaba eran los sistemas distribuidos, es decir, que cada entidad de la organización gestionase su instancia del proceso como quisiera y después al final se consolidase la información en el sistema central.

Yo no soy a priori partidario de los sistemas centralizados ni de los sistemas distribuidos, creo que hay que estudiar primero el problema, la infraestructura tecnológica que le puede dar soporte y después buscar la mejor solución.

En el caso del sistema que se debatía en la reunión, la solución sencilla es la construcción de sistemas independientes que alimentasen al gran repositorio central, sin embargo presentaba dos inconvenientes que eran importantes tener en cuenta: Al ser un proceso horizontal en la organización hay muchos subprocesos comunes, esto se hace más patentes si subimos la escala y en lugar de la organización tomamos como referencia la institución, esto implicaba repetir la implementación de un mismo subprocesos en distintos sistemas de información, además si no existe una visión común de los mismos, en cada organización o departamento se le puede dar una solución distintas, con la inseguridad desde el punto de vista jurídico que eso conlleva, el coste de implementación (repetir varias veces la solución a un determinado problema) y de mantenimiento. Otro problema importante es la duplicación de datos en repositorios distintos, lo que puede provocar problemas de coherencia en el caso de que los mecanismos de sincronización no estén debidamente ajustados, tengamos en cuenta que en el caso del sistema que nos ocupa debería tener información alfanumérica, cartográfica y documental (y en gran volumen).

Por todo lo anterior yo defendía una solución centralizada, la cual era más complicada de desarrollar ya que necesitaría de instrumentos normativos que obligase a los distintos departamentos a trabajar de una determinada manera y además requería poner a un mayor número de personas de acuerdo. La solución no obstante sería mixta en algunos aspectos, ya que probablemente por motivos de rendimiento, podría ser recomendable que cada organización o departamento manejasen, como mínimo sus propios repositorios cartográficos y documentales, implementándose por tanto los procedimientos de sincronización oportunos.

¿Qué pasó finalmente? Pues que un proyecto tan ambicioso requería forzosamente una gran inversión económica y en la época en la que estamos no está el horno para muchos bollos. Supongo que algún día se retomará y espero que con una solución centralizada.

De nada te sirve tener los sistemas de información más maravillosos del mundo. Al final, los sistemas se irán al traste si el rendimiento es deficiente.

Los usuarios quieren agilidad cuando utilizan un programa, no quedarse esperando a que la aplicación cambie de una pantalla a otra.

Es cierto que el rendimiento puede ser provocado por el sistema ya sea por un deficiente diseño o codificación del mismo o de algunos de los componentes externos que tiene que utilizar y si es así hay que buscar soluciones cuanto antes (de hecho, en un mundo ideal un programa así nunca debería haber llegado al entorno de producción, pero claro, eso es en un mundo ideal).

No obstante si las comunicaciones no son buenas, da igual el esfuerzo dedicado a optimizar el software, ya que irá de pena. Lo peor de todo es que los usuarios al final siempre echan la culpa al sistema de información, ya que ellos lo único que entienden es que el sistema va a pedales y por tanto, siempre caerán las culpas sobre el producto software.

Otra fuente de mal rendimiento de una aplicación es una mala configuración o una carga excesiva del servidor de aplicaciones, del sistema de gestión de base de datos (o de las máquinas que las sustentan), probablemente hable de esto en un post más adelante.