archivo

Archivos Mensuales: noviembre 2010

El hecho de que los responsables del área TIC en una organización no ocupen un puesto directivo tiene entre otras consecuencias (no es la más grave) que cada departamento de la organización pueda llegar a pensar que somos una caja negra a la que se le piden servicios, con urgencia y que tiene la obligación de hacerlos y con la celeridad que se demanda.

Eso podría ser así si por un lado el departamento TIC tuviera una estrategia anual de sistemas de información pactada con la alta dirección y un presupuesto acorde a esa responsabilidad (toda urgencia que requiera un determinado desarrollo no pactado debería ir a cargo del presupuesto del departamento demandante). Cuando no es así y tenemos departamentos que están continuamente pidiendo servicios y no aportan presupuesto para los mismos, nos encontramos en una situación problemática ya que los recursos no se pueden estirar hasta el infinito, lo cual tiene como agravante que los presupuestos internos de los departamentos TIC se están reduciendo como consecuencia de la crisis y, por tanto, la distancia que podemos recorrer es menor que la que podíamos recorrer antes.

Las generalizaciones son injustas ya que existen directores usuarios muy conscientes de que de igual manera que sus actuaciones pueden llegar hasta donde lleguen sus presupuestos (e incluso sufren lo mismo que nosotros, terceras presiones para intentar sacar un trabajo adelante que está por encima de las posibilidades reales presupuestarias), las actuaciones de informática pueden llegar hasta donde se haya invertido y si no han invertido dinero, no pueden exigir que hagamos magia. Sin embargo, existe una mayoría que no tienen en cuenta eso, que piensan que el departamento TIC tiene que resolver como sea sus problemas y que si no lo consigue en tiempo y forma no es culpa de ellos.

Una cita de Peter Drucker que refleja un hecho sobre el que no me caben dudas es la siguiente: “La mejor estructura no garantizará los resultados ni el rendimiento. Pero la estructura equivocada es una garantía de fracaso.”.

No se le da suficiente importancia a las estructuras. Las organizaciones se van transformando y sin embargo no se cuida el desarrollo de esa metamorfosis sobre todo si las cosas vienen bien dadas. Cuando hay dinero, las estructuras crecen, se superpoblan, se tiende hacia lo irrelevante, olvidando de consolidar lo relevante, se potencian áreas donde se es débil en lugar de potenciar aquellas donde se es fuerte, donde se marca la diferencia, la que si funciona bien o mal condiciona nuestros resultados presentes y futuros.

¿Qué pasa después? Pues que cuesta mucho dinero mantener lo que se ha creado (además de que las grandes estructuras tienen menor capacidad de adaptación) y en el momento en que se ingresa menos de las expectativas de beneficio o, lo que es peor, menos que los gastos toca adelgazar la estructura algo que supone mucho más esfuerzo y problemas que lo que costó crearla (básicamente igual que cuando se quiere perder peso), algo que se ve empeorado porque se tiende, con esta visión salomónica que nos caracteriza a todos, a que aunque algunas áreas se adelgacen más que otras, la mayoría terminan perdiendo estructura y muchas de ellas son las más relevantes para el funcionamiento y/o negocio de la organización.

En el artículo “altibajos” donde hice una serie de reflexiones sobre el libro “Cimas y Valles” de Spencer Johnson puse una cita del mismo, que viene muy bien para dar cierre a este tema, que decía: “Las cimas y los valles está conectados. Los errores que cometes en los buenos momentos del presente crean los malos momentos del mañana. Y tus aciertos en los malos momentos del presente crean los buenos momentos del mañana”

Uno de los aspectos que más descuidan las empresas es el trato de sus empleados con los clientes, independientemente de que este sea directo o a distancia (teléfono, correos electrónicos, etc…). Directamente sueltan los empleados con los clientes y que se las arreglen.

Esto es un error y en función del tipo de cliente y el tipo de trabajo que desempeñen con el mismo puede tener mayor o menor trascendencia. Hay muchos que pensarán que casi nunca pasa nada, pero cuando pasa, pasa y siempre es mejor, en cualquiera de los casos, dar una buena imagen.

Es frecuente la recepción de correos electrónicos con faltas de ortografía, hablar con proveedores que prácticamente acabas de conocer que te tratan como a un colega (o como a un enemigo hostil), tratar con personas que no se comunican con facilidad ante personas con las que no tienen confianza, etc…

No hace falta hacer un master para tratar con clientes, pero sí es conveniente detectar cuándo una persona está preparada o no y eso es responsabilidad de quien gestiona ese equipo de trabajo y la relación con el cliente. Además, en función de la tarea a realizar, unos serán más adecuados que otros (hay personas que destacan más en labores comerciales, otras en tareas técnicas, otras en situaciones de conflicto, etc…).

También hay que asumir que habrá empleados que no sirvan para trabajar directamente con clientes (pero que después tengan otras fortalezas que hagan que en determinados tipos de tareas sean extraordinariamente eficientes y productivos) y no es cuestión de echarlos a los leones, tanto por la empresa como para ellos mismos.

Volviendo a un tema que toqué en diversos artículos desde que publiqué mis reflexiones sobre el documental “La oscura era digital” os comento una breve charla que tuve con la responsable de archivo de mi organización.

Resulta que un departamento quiere hacer una limpia importante de documentos que no tienen trascendencia, pero que como suele pasar en estos casos, cuesta deshacerse de ellos por si en algún momento fuera necesario acudir a ellos. Como buena parte de los mismos procedían de listados de un sistema de información actualmente sustituido por otro y en el proceso de migración se mapearon los datos origen a otros distintos (para mejorar, entre otras cosas, la calidad de los mismos), los responsables del departamento querían conservar una copia en el archivo de mi organización, de los datos de la aplicación antigua, los cuales se encuentran todavía en la base de datos de explotación ya que el cambio de sistema se realizó no hace excesivo tiempo y por si acaso, queremos tenerlo a mano por si hiciera falta acudir a ellos (tampoco hubiera habido problema si se hubiera decidido tenerlo almacenado en cinta).

Traté de explicarles que en informática nos encargaríamos de hacer una copia del esquema de base de datos cuando se vaya a quitar de producción pero como es lógico, ellos querían tocar pelo y tener custodiado en el archivo una copia en soporte digital en el archivo. Al fin y al cabo los responsables de los datos son ellos y si prefieren hacerlo así, poco más allá puedo ir.

Una vez que finalmente decidieron la opción del archivo, la responsable de archivo me pidió un manual que permitiera que a partir de la información almacenada en el soporte físico se pudiera recuperar la información en el caso de que sea necesario. Esto puede parecer una petición lógica, pero, ¿se nos habría ocurrido a nosotros?, ¿se nos habría ocurrido qué tal vez dentro de de bastantes años sea necesario recuperar esa información y tal vez la tecnología de base de datos utilizada ya no sea la predominante o bien exista otros paradigmas de almacenamiento de datos?. Lo que parece trivial no lo es tanto y lo expone perfectamente el documental “La oscura era digital”.

A la mayoría de nosotros nos ha supuesto un fastidio todo el proceso metodológico de desarrollo de software en el que hay que generar y a ser posible, ser validados, diferentes entregables documentales y que suponen un obstáculo de lo que realmente nos gusta que no es otra cosa que ponernos a programar.

Sin embargo, cuando estamos en esa fase de análisis o diseño y tenemos que integrarnos con terceros productos o aplicaciones resulta que necesitamos información de las mismas: su modelo de datos, una explicación del mismo, sus interfaces de comunicación, etc… y que resulta muy complicado que alguien nos la facilite. En esos momentos nos preguntamos, ¿cómo que no está documentado esto? y se realizan quejas al cliente ya que se requiere un mayor esfuerzo en el proyecto para poder investigar esos terceros sistemas con los que hay que interoperar.

Por tanto, nos quejamos de que haya que documentar e intentamos eludir esa tarea como sea y sin embargo también nos quejamos cuando necesitamos información de otro sistema y comprobamos que no hay nada o que lo que hay es de escasa calidad y además está desactualizado.

Como tantas veces he defendido en este blog, es absolutamente necesario que el proceso de desarrollo de software esté procedimentado y que dentro del mismo el proceso de documentación y revisión de la misma tenga la importancia que se merece y que por supuesto, salvo excepciones, no se escriba ninguna línea de código hasta que análisis y diseño estén finalizados y aprobados.

Otra cita de Peter Drucker que resulta muy esclarecedora es la siguiente: “Nadie debería ser nombrado para una posición directiva si su visión se enfoca sobre las debilidades, en vez de sobre las fortalezas de las personas.”.

Como suele ser el mensaje de Peter Drucker, la cita está llena de sentido común, es decir, tenemos un equipo de personas, ¿cómo podemos extraer el máximo rendimiento? pues centrándonos en las cualidades individuales de cada persona en lugar de dirigir nuestra atención a sus defectos.

Esto que parece sencillo, es una quimera para muchos gestores que olvidan con demasiada frecuencia que las personas no son números, sino personas. Fútbol es fútbol, personas son personas. ¿Tan difícil es?.

Para poder sacar el máximo provecho a un equipo de trabajo hay que conocer sus virtudes, de manera que se pueda conocer dónde se puede extraer el máximo potencial, los estados de ánimo, qué necesita cada uno para ofrecer su máximo rendimiento. Esto implica meterse en el charco y preocuparse por conocer a las personas. Tal vez el máximo dirigente de una organización no pueda llegar a ese punto, pero para eso existen otros mandos intermedios a distintas escalas que sí que podrían, por lo menos, intentar conocer las inquietudes de cada uno.

Mantenerse al margen de los equipos de trabajo implica directamente dejarse llevar por las apariencias, ya que al no entrar en detalle solo se pueden sacar conclusiones a través de pinceladas y de igual forma que por la noche todos los gatos son pardos, con pinceladas todo el mundo puede llegar a aparentar lo que no es y los que no se esfuercen en aparentar, no serán nada.

Una gestión basada en fortalezas no es una gestión blanda, antes al contrario, es decir, se dirige a cada persona a dónde se le puede sacar el máximo rendimiento y se trata de potenciar sus cualidades (si una persona puede saltar ocho metros en longitud, ¿para qué entrenarle para que pueda lanzar martillo?). Si las áreas donde esa persona puede presentar su fortaleza están ya ocupadas por gente mejor que él o bien hay gente que viene por detrás que pueden ofrecer mejores prestaciones, será cuestión en ese momento de analizar si conviene o no segur manteniendo a esa persona en la organización.

Una gestión basada en debilidades es poco productiva ya que se tiende a tomar decisiones en sentido negativo, es decir, este no puede hacer este trabajo porque no se le da bien por lo que se le asigna una tarea donde no es débil y no ser débil no implica ser fuerte.

Es absolutamente necesario que cada uno de los hitos de un proyecto esté asociado a una fecha. Sin referencias el proyecto tendrá muchas posibilidades no solo de ser nefasto en lo económico sino de que los diversos entregables sean de escasa calidad (al no existir referencias, al final se pondrá una por parte del cliente cuando éste empiece a impacientarse que será además muy difícil de cumplir ya que el proyecto no habrá avanzado acorde a como debería haber ido, entre otras cosas, además porque se habrá cometido el error de no informar al cliente de cómo van las cosas).

Hay veces donde las fechas de los diferentes hitos (sobre todo, la entrega final del producto) no se pueden aplazar, pero en la mayoría de los casos sí que se pueden mover. La flexibilidad en las fechas de entrega si se utiliza de manera arbitraria producirá malos resultados, es decir, los equipos de desarrollo tendrán la impresión de que como nunca pasa nada y disminuirán su productividad, es decir, estaríamos en una situación similar a la ausencia de fechas.

Si se tiene que mover una entrega que sea por causas justificadas, como por ejemplo, que realmente el esfuerzo estimado no sea acorde con el que se requiere, modificaciones en los requisitos, cambios en el equipo de proyecto acordados entre cliente y proveedor, etc… y siempre poniendo un nuevo plazo que sea asumible por las dos partes y a la altura de lo que realmente le falta al hito (de equivocarnos la poner el nuevo plazo es mejor siempre que sea un poco por encima que por debajo). El nuevo plazo podrá ser reajustado de nuevo si hay causas que lo justifiquen y así sucesivamente.

Nunca hay que tener miedo de proponerle al cliente un aplazamiento. La mayoría lo entenderán si se les avisa con tiempo y se les justifica, ya que siempre será mejor tener un retraso razonable (salvo que la fecha de entrega sea inamovible por algún motivo) que recibir una entrega de peor calidad, ya que al final provocará problemas en el producto y en consecuencia mayores costes para el cliente y el proveedor.