archivo

Archivos diarios: junio 14, 2010

Una de las causas que puede provocar una reducción de la productividad es quedar atrapado en la maraña de flujos de información y toma de decisiones o lo que viene a ser lo mismo: convertirse en un proxy o intermediario que se encarga de recibir información, que puede procesar antes de redirigir (tomando o no decisiones en este proceso que se trasladan a un receptor o conjunto de receptores), simplemente redirigir o simplemente ser un consumidor de la misma (sea o no importante).

No quiere decir que no se trabaje si se cae en este tipo de telas de araña, es más se trabaja y mucho e incluso se puede ser productivo siendo capaces de sacar mucho volumen de trabajo por unidad de tiempo. Esto no supone una contradicción respecto a lo comentado en el primer párrafo, ya que si tu trabajo real es otro, realmente se produce una pérdida de productividad en el mismo, ya que se está dedicando demasiado tiempo y esfuerzo en tareas que no deberías estar realizando tú y sí otro tipo de perfil o bien que sólo te deberían ocupar un determinado tiempo, que es el que se tardaría en tratar los problemas realmente importantes que surjan en todo ese haz de datos e información.

Desde el punto de vista personal, desde hace tiempo estoy atrapado dentro de ese flujo de información y toma de decisiones y soy plénamente consciente de ello. ¿Por qué no pongo solución? Salir de esto supone disponer de una infraestructura que actualmente ni poseo ni estoy de disponibilidad de tener. Esta infraestructura es sobre todo de procesos y responsabilidades, casi más que de recursos humanos. No tiro la toalla y sé que tarde o temprano la situación se normalizará y podré dedicar más tiempo a aquellas actividades que constituyen o deberían constituir el núcleo de mi trabajo, de hecho he conseguido que una parte de las tareas de estas características que realizaba yo directamente, ahora simplemente las supervise. No obstante, todas las organizaciones no son de las características de la mía y sí que es posible que otras dispongan de una mayor flexibilidad en cuanto a la toma de decisiones, definición de procesos, etc.., por ese motivo esta experiencia personal no debería desanimar a nadie para intentar salir de este círculo, porque además yo soy el primero que soy optimista en este sentido.

¿Por qué hablo de procesos y responsabilidades? Los procesos definen dinámicas de trabajo, si estas son conocidas por todos y son de obligado cumplimiento no será necesario recordar a nadie cuál es su trabajo y cómo debe desarrollarse (incluidos los niveles de calidad y productividad esperados en el mismo). Las responsabilidades dan un margen de maniobra a las distintas personas encargadas de realizar una tarea para la realización de las mismas, a cambio de ese margen de maniobra son responsables de cumplir las expectativas que se tienen en su trabajo y de las consecuencias que tiene hacerlo bien y de las consecuencias que tiene hacerlo mal.

Una vez definido ese modelo de procesos y responsabilidades, tocará el siguiente paso que es la delegación de tareas, nunca es fácil delegar, sobre todo determinados aspectos que se consideran importantes, no obstante es algo necesario y en el que nunca se debe olvidar que lo que se delegan son tareas y no responsabilidades, por lo que si una tarea delegada no sale bien, la responsabilidad es de quien delega. Una vez asumida dicha responsabilidad el siguiente paso es exigir la responsabilidad al resto de la cadena de delegación hacia abajo. Además de delegar, también supone que se abandone la realización de tareas que se estaban realizando que no eran cometido de las funciones y objetivos de tu trabajo, esto suele ser más sencillo, pese a que se tenga conciencia de que si no se realizan bien puedan tener influencias negativas sobre las áreas que sean de tu responsabilidad.

NOC es otra de las métricas de Chidamber y Kemerer. Como no podía ser de otra forma, mide la complejidad de una clase desde un punto de vista diferente al del resto de métricas propuestas por estos autores. En este caso su cálculo se basa en contar el número de subclases que directamente heredan de la clase para la cual se calcula esta métrica.

Las subclases están acopladas con la clase de la que heredan, esto quiere decir que cuanto más clases hijas tenga una clase más prudencia hay que tener con cambios relacionados con el comportamiento y especificación de los métodos, ya que podría tener trascendencia sobre sus subclases. Por ese motivo, es necesario ser más exhaustivo en las pruebas de clases con un NOC alto, ya que cualquier problema en las mismas tiene un impacto importante en el programa. Por tanto, se puede deducir de esto que clases con un número de hijos elevado son más complicadas de mantener que otras con un número más bajo.

En el árbol de jerarquía de clases de un determinado programa resulta razonable que las clases situadas en los niveles más alto de la jerarquía tengan un valor de NOC superior a las clases que se encuentren en niveles inferiores, por ese motivo, la existencia de clases con un NOC alto en comparación con otras que se encuentran en niveles superior de la jerarquía, puede ser un indicador de un mal diseño de la clase o una utilización no adecuada de la herencia.

Por otro lado, clases con un NOC alto favorecen su comprensibilidad y la capacidad de implementación de nuevas reutilizaciones, ya que existe un número de clases de ejemplo donde se puede estudiar cómo han aplicado la herencia y como se ha reutilizado la clase.