archivo

Archivos diarios: octubre 6, 2012

Un error muy común en los planes de sistemas es que solo tienen en cuenta el contexto actual (hay muchos que ni siquiera eso, se basan en un modelo general o en un modelo que se han utilizado en otras organizaciones similares y se tratan de ajustar) y muy poco la posible tendencia de la organización.

Incluso teniendo en cuenta esa tendencia, no tienen en cuenta la necesidad de revisarlo cada cierto tiempo (se puede establecer un período fijo, nunca más de un año y abriendo la puerta a actuaciones de urgencia en caso de modificaciones sensibles de contexto).

Una organización que no tenga como objetivo racionalizar los sistemas de información (y en general las TIC) tendrá la pesada carga de mantener un parque de aplicaciones superior al necesario (con tecnologías diferentes) y muchos datos incoherentes lo que complica, cuando no hace casi imposible, la explotación global de esa información, algo que puede ser fundamental para tomar decisiones tácticas y estratégicas en la organización.

Es fundamental, por tanto, tener una estrategia que vaya hacia la racionalización, yo a esto lo denomino plan de sistemas (no hace falta generar una enciclopedia para llevarlo a cabo, lo importante es tener claro hacia donde se quiere ir) y que tenga en cuenta los contextos. Si es necesario tenerlo en cuenta en un determinado proyecto de desarrollo de software, ¿cómo no tenerlo en cuenta en una estrategia que tiene un mayor recorrido?.

Tenemos los extremos de tener sistemas absolutamente cerrados y tener sistemas totalmente configurables. ¿Qué extremo es el más válido? Dependerá, como es lógico, del sistema de información que se desarrolla.

Si hablamos en términos generales, un sistema totalmente cerrado, sin posibilidad de configurar nada, requiere cambios en el código para realizar cualquier tipo de modificación. En mi opinión, este comportamiento no es deseable.

Por otro lado, un sistema totalmente configurable requiere un nivel muy importante de su abstracción en su desarrollo y la definición de modelos de datos generalistas. Esto requiere un coste adicional y puede dar lugar a dificultades con la explotación de la información y el rendimiento. También, si son muchas las opciones de configuración el usuario puede perderse en ellas.

Configurable es que el comportamiento de determinadas funcionalidades, la realización de determinados cálculos o la aplicación de determinadas restricciones varíe en tiempo de ejecución (o en tiempo de arranque del servidor) pero va más allá de eso, ya que configurable también es la posibilidad de poder actualizar manualmente (sin entrar directamente en las tablas de la base de datos) los valores de las tablas maestras o de determinados parámetros. Esto que parece obvio no lo es tanto cuando ves incrustados en el código determinados dominios de datos o se le impide al usuario modificar valores de una tabla maestra.

Pese a que los generadores de código prácticamente te ahorran el tiempo de desarrollo (o buena parte de él) de la gestión CRUD existe mucha pereza en los desarrolladores a dedicarle tiempo a esto: “Total, siempre existe la posibilidad de hacerlo directamente a través de base de datos”. ¿Qué pasa después? Pues que podemos tener un sistema con doscientas tablas y un montón de ficheros de configuración y a ver quién mantiene eso. Desde luego el usuario no, por lo que la responsabilidad recaerá en el departamento TIC, debiendo dedicar unos recursos a realizar estas tareas que con el paso del tiempo suponen un mayor coste del que hubieran tenido si las cosas se hubieran hecho bien desde un principio.

La gestión de expectativas es más efectiva cuanto más cerca se encuentre de la realidad del proyecto, la cual está condicionada por el estado actual de los trabajos, de las actuaciones y decisiones pasadas y del contexto en que nos encontremos.

Trabajar con ilusiones, deseos y fantasías dando lugar a una realidad paralela solo nos lleva a un sitio que no es otro que el fracaso en el proyecto y es que no se puede esperar otra cosa si las expectativas son falsas y si no se han tomado las medidas adecuadas ante las desviaciones y contingencias que se hayan producido.

Se trabaja más cómodo obviando los problemas pero es mejor trabajar teniéndolos en cuenta porque al menos así tendremos alguna posibilidad de que el final de la historia sea feliz.

La confrontación no da buenos resultados. Sin embargo, a veces es inevitable y lo es en el momento en que una de las partes no es coherente con sus actos y trata que la otra asuma su comportamiento erróneo o negligente.

El principal damnificado de la confrontación es el producto y en consecuencia todo su conjunto de usuarios que tendrán que sufrir una solución de calidad deficiente y esto es así porque en estos casos no se piensa en el producto y en el trabajo bien hecho sino que solo se piensa en la cartera.

Es mucho más fácil de lo que parece, basta con que quién la ha fastidiado (y si han sido las dos partes, pues las dos) se haga responsable de sus actos: si el proveedor ha desarrollado basura que asuma sus consecuencias y si el cliente ha especificado basura que también asuma sus consecuencias.

Sin embargo esto que es fácil en esencia resulta muy difícil cuando en medio hay organizaciones y personas y por ende dinero y carreras profesionales. En primer lugar hay que darse cuenta que uno se ha equivocado, en segundo lugar asumir el error y en tercer lugar asumir sus consecuencias.

Generalmente cuando hay confrontación el problema se escala y lo tratan personas que no han estado en el día a día del proyecto y que tienen una información sesgada de los participantes en el proyecto que le contarán la historia que les interese (algo por otra parte peligroso porque en el transcurso de la confrontación pueden dejar en evidencia a su superior y las consecuencias de esto son más desastrosas que lo que realmente se pretende evitar).

Si quienes deben dialogar o alguno de las partes muestra una actitud similar a la que mostraron las personas directamente implicadas en el proyecto el resultado será igual de nefasto.

Una solución dialogada siempre será mejor que una basada en la confrontación, ya que en la segunda una de las partes se impondrá a la otra y este desgaste afecta al presente (al producto) y al futuro (a las relaciones entre los implicados). En cualquier caso, parte ganadora y parte vencida perderán dinero, mucho más que si la solución hubiera sido dialogada.

Voy a hacer esto, creo que hay que hacer lo otro, esta situación la vamos a cambiar, estas son las medidas que vamos a tomar, el proyecto lo sacamos adelante, entre todos podemos, tengo la solución ante las desviaciones del proyecto, yo sé cómo hacerlo, etc…

Este discurso podría ser propio de un político pero si tenemos algo de autocrítica hacia nuestra profesión o nuestro propio comportamiento es un discurso que se encuentra presente también en nuestro día a día.

Todos conocemos ese repertorio, a veces hemos sido oyentes, otras incluso el ponente (¿de verdad vas a ser tu quién tire la primera piedra?).

Estos discursos que pretenden elevar la moral de las “tropas” y que pretenden servir de base para una transformación producen un efecto totalmente contrario al deseado ya que lo que hace es generar frustración y falta de confianza en los receptores cuando descubren, más pronto que tarde, que solo eran palabras y las palabras sin acciones no son nada.

Y es que hablar es demasiado fácil, sale gratis (criticar todavía más fácil, sobre todo cuando lo hacemos sin mirarnos al espejo).

Si de verdad quieres cambiar las cosas, actúa. Aunque te equivoques, pero actúa de manera congruente a tu discurso (si haces lo contrario de lo que dices no puedes esperar aplausos). No gastes toda tu fuerza en las palabras, deja la mayoría de ella para la acción. Si eres consecuente con lo que dices, la mayoría de la gente estará contigo, si te equivocas perderás apoyos pero incluso quien deje de apoyarte sabrá que eres de confianza.

Si hay que cambiar el discurso se cambia, si cambia el contexto y/o se quieren corregir actuaciones equivocadas (es absurdo seguir un camino que no conduce a ningún sitio o a no tener en cuenta la realidad del proyecto) provocando una línea de actuación diferente, informa del por qué, sé sincero y después vuelve a actuar.

Los proyectos de desarrollo de software no salen adelante solo con palabras, recuérdalo.