archivo

Archivo de la etiqueta: rendimiento

Su enunciado es el siguiente: “La calidad de los sistemas comienza a disminuir a menos que se mantengan de forma rigurosa y se adapten a los cambios en su entorno de funcionamiento (operacional)”.

En esta ley, Lehman trata el problema de la disminución de la calidad desde diferentes puntos de vista:

– El usuario tiende a ser más exigente conforme mayor sea la inversión dedicada a la evolución del producto y conforme se den cuenta (independientemente de que sepan interpretar su complejidad o no) de la maleabilidad del software.

– La calidad del software se ve afectada por en incremento de la complejidad del sistema conforme se va evolucionando y eso afecta a diferentes escalas: codificación/arquitectura (deuda técnica), usabilidad, etc…

– Por otro la propia convivencia del sistema con su entorno tecnológico (software y hardware), el cual evoluciona de la misma forma que los sistemas y en muchos casos con características muy similares. En esa evolución se tratan de corregir fallos de seguridad, se trata de dar una mayor estabilidad, a la par de incluir nuevas funcionalidades que puedan resultar de utilidad (y distinguirla de otras opciones del mercado).

Si un sistema no se adapta a esos cambios y las características de los nuevos entornos operacionales que se estén montando no son compatibles, estamos acotando el sistema a seguir subsistiendo con versiones en muchos casos sin soporte de los mismos y que además, se irá quedando marginada porque el esfuerzo central del Departamento de Sistemas se centrará en los entornos en los que se encuentre el grueso de los sistemas de información de la organización, además de aquellos que sean considerados críticos.

El alcance de esta séptima ley se puede extender al propio framework de desarrollo del producto y al conjunto de librerías dependientes que utilice, de manera que surgen nuevas versiones de las mismas que mejoran las anteriores a la vez que corrigen defectos en las mismas.

También puede ser extensible a una menor calidad como consecuencia de no aplicar medidas conforme se incrementa la complejidad del producto (en este caso se asimilaría a la segunda ley de Lehman).

Las expectativas del usuario y la calidad del software están muy por encima de las especificaciones funcionales, por eso que el producto final termine satisfaciendo el catálogo de requisitos funcionales (por mucho que se hayan refinado) no asegura ni el éxito del producto ni su calidad final.

Si solo pensamos en requisitos funcionales estamos limitando nuestra visión sobre lo que debe ser el producto final. Cada uno puede tener una definición de lo que considera calidad del software, en la mía no es condición suficiente la verificación de los requisitos funcionales (y probablemente muchos de vosotros estéis de acuerdo conmigo). Son importantes, no digo lo contrario, pero no es lo único.

Por un lado tenemos las expectativas que, si bien podría englobar los aspectos funcionales, contiene ingredientes adicionales como son la experiencia de usuario y la productividad en el uso de la herramienta (muy ligado a la anterior).

Y por otros los requisitos no funcionales (algunos de ellos serán detectados de manera temprana por los usuarios y podrían afectar a las expectativas del usuario sobre el producto), como por ejemplo, la mantenibilidad (deuda técnica), la disponibilidad, el rendimiento, los recursos que requiere y consume, etc…

Hay una cita bastante polémica de Robert Hummel en la que comenta que: “Ordenadores más rápidos y potentes crían programadores lentos y perezosos”.

¿Que hay de cierto en esa cita?, ¿sobre qué se nos quiere advertir?.

Hago la siguiente pregunta, ¿desarrollaríamos igual si no supiéramos que la máquina en la que se va a ejecutar nuestro software tuviera muy limitada su capacidad?. Lo más seguro es que no, que trataríamos de hacer un desarrollo lo más eficientemente posible en términos de rendimiento.

Nos centramos en ejecutar trabajo, el rendimiento en ese contexto es algo secundario y dependerá el hecho de tener mejores o peores resultados de la experiencia y buenas prácticas del programador, así como del tiempo disponible para realizar la tarea.

Yo me he encontrado con casos donde no se tenía siquiera monitorizadas las máquinas de un entorno concreto de producción porque se consideraba que estaban tan sobredimensionadas que no era necesario. Mal hecho, porque después puede haber otro tipo de problemas que no se puedan detectar de manera proactiva sin esa monitorización y porque nunca hay suficientes recursos para un software mal diseñado.

A lo anterior hay que sumarle la aparición de generadores de código y frameworks que simplifican en gran medida las tareas del programador. No seré yo quien los critique, ya que creo en ellos, sin embargo hay que tener en cuenta que en muchos casos alejan al programador de los fundamentos y de las bases de la programación, tardando mucho más en adquirir una experiencia que les resultaría muy válida para ser más eficaces, a la vez que adquieren la mala costumbre de que cuando el desarrollo no puede ser tan automático su rendimiento disminuye en gran medida.

No estoy de acuerdo con Robert Hummel ya que me parece muy extrema su afirmación, si bien es cierto que en un contexto de abundancia se ponen pocos reparos a los excesos.

Nuestra productividad alta o baja no tiene efectos exclusivamente sobre nosotros mismos, sino que también tiene un efecto a nuestro alrededor, de la misma forma que la de los demás también influye en nosotros.

Se suele trabajar en equipo y cuando alguien falla o destaca inevitablemente tiene efectos sobre los demás.

Cada uno de nosotros tiene una capacidad de empuje, una motivación, un nivel de resiliencia, una experiencia, unos conocimientos, una técnica y podemos ser más o menos ajenos a lo que pasa en nuestro proyecto y mantener durante más tiempo nuestra regularidad, sin embargo resulta a largo plazo poder mantener un nivel aceptable de productividad cuando la teoría de las ventanas rotas se ha instaurado en nuestro contexto laboral y la improductividad solo trae más improductividad.

También será complicado que no mejoremos si los hábitos y la capacidad de nuestro entorno son favorables.

Estas características provocan que las caídas o subidas de productividad en un departamento o en una organización sean muy sensibles, ya que tiene influencia no solo sobre personas concretas, sino en equipos de trabajo completos. Es necesario, por tanto, darle al capital humano el valor que se merece.

Las organizaciones para ser competitivas deben estar orientadas a la productividad, poniendo los medios adecuados para poder evaluarla y no dejando su valoración en percepciones personales y subjetivas.

Productividad no es aumentar la carga de trabajo sin más, sino sacar el mayor rendimiento posible de las personas. Se obtienen mejores resultados, aumentando la motivación, que a través del overtime o de la asignación de una carga de trabajo superior a la que que se puede afrontar en una jornada laboral normal (incluso siendo muy productivo).

Rebecca Parsons es la actual CTO de la empresa ThoughtWorks, dedicada a la consultoría y al desarrollo de software utilizando metodologías ágiles. Con anterioridad desarrolló su trabajo como profesora universitaria y colaboradora en diversas instituciones y comités. Sus trabajos se centraron en los campos de la inteligencia artificial, computación distribuida y los lenguajes de programación. En totalidad son más de veinte años lo que lleva dedicada a este negocio.

El rendimiento es una requisito no funcional, una variable en el proceso de desarrollo de software a la que no se le suele prestar demasiada atención pero que hace daño cuando el producto se encuentra en una fase avanzada de su construcción (porque requerirá esfuerzo corregirla) y todavía más en producción porque a ese coste hay que sumarle la pérdida de eficiencia y productividad de los usuarios en el uso de la herramienta y la disminución de la confianza de los mismos en el producto, lo que afectará negativamente a los gestores funcionales y técnicos del proyecto.

Es cierto que una buena arquitectura, codificación, diseño del modelo de datos, afectan implícitamente al rendimiento, sin embargo, no solemos prestar la atención que se merece a un aspecto que tiene incidencia en la calidad final del producto, pese a que Rebecca Parsons tiene razón cuando comenta que: “Nunca es demasiado pronto para pensar en el rendimiento”.

Todo el mundo tiene días malos, donde uno no rinde todo lo que quisiera, en los que no se alcanza ese umbral mínimo de productividad que cada uno tiene como referencia.

A veces no se trata solo de días, pueden ser semanas o en general una mala racha.

No somos robots y la vida no es una línea recta. Nuestra experiencia, nuestra capacidad de control sobre nosotros mismos, nuestro oficio, nuestra resiliencia, nuestro orgullo, nuestras ganas, pueden hacer que nuestro bajón de rendimiento no sea tan acusado y que volvamos en el menor tiempo posible a tener unos niveles de productividad próximos a los que veníamos desempañando.

Como los malos y los buenos momentos, cada uno de ellos con duración variable, vendrán, soy de la opinión que la productividad es también una cuestión de regularidad, en la que nuestra capacidad de sacar trabajo adelante con eficacia no se debe ver afectada por el hecho de tener un mal día, una mala semana o un mal proyecto. Por supuesto que si no alcanzamos objetivos personales o de empresa (sobre todo estos últimos) pueden tener repercusión, pero como la productividad es regularidad, si mantenemos nuestro nivel revertiremos la situación.

Todos nosotros contamos con una capacidad de trabajo y energía para cada jornada, no siempre es la misma porque no todos los días son iguales.

Son muchos los factores que pueden afectar a nuestro rendimiento pero una de ellos es, sin duda, la carga de trabajo que llevamos acumuladas. Si el día anterior eché doce horas, tendrá consecuencias en el rendimiento que tenga hoy, si hoy echo otras doce, tendrá consecuencias en el rendimiento que tenga mañana y serán mayores que las que tuve hoy.

Si ese esfuerzo se acumula en el tiempo la capacidad productiva de los trabajadores afectados disminuirá y no solo eso, muchos de ellos terminarán buscándose otros horizontes profesionales ya que una carga excesiva de trabajo sostenida en el tiempo tendrá consecuencias en la vida personal de cada uno. Tal vez si la recompensa económica o de desarrollo profesional es proporcional al esfuerzo realizado se consiga aguantar más sin que la productividad se resienta considerablemente, teniendo en cuenta que eso será a cambio de importantes sacrificios personales. Lo que pasa es que no todo el mundo está dispuesto a afrontar esos sacrificios y lo que es más común, difícilmente te encuentras con organizaciones que premian en proporción a tu esfuerzo y compromiso y todavía es más difícil conseguir esa proporcionalidad si además te encuentras en los niveles inferiores de la jerarquía.

Es razonable que existan períodos de tiempo donde existan picos de trabajo y que por muy productivo que se sea se necesiten echar más horas. Eso es asumible (aunque injusto si no se premia al trabajador en el caso de que ese sobreesfuerzo haya traído beneficios de algún tipo para la organización), lo que no es asumible es que se viva en un continuo pico de trabajo.

Las jornadas laborales deben ser racionales, no por echar más horas se produce más. El efecto es que se distribuye la energía entre el número de horas que hay que tener la mente en el trabajo o que estás ligado al trabajo (lo mismo tienes una jornada de ocho horas, pero el tiempo de comida entre la jornada de mañana y tarde hace que estés al ligado diez u once horas).

Quien es productivo y quiere serlo, pondrá los medios para conseguir los mejores resultados posibles en el tiempo disponible para hacerlo. Quien no lo es, casi que da igual el tipo de jornada laboral que haya o el número de horas que trabaje. No se trata de cantidad sino de calidad.