archivo

Archivos Mensuales: febrero 2010

Es cierto que hay que ganarse las habichuelas de una determinada manera y el desarrollo de software no es más que una forma tan digna como otras de hacerlo. No obstante, hay que tener un cierto amor por lo que se hace para dedicarse a esta profesión.

Es más, me atrevo a decir, que las personas con más éxito en este negocio son aquellas que más amor sienten por él (habrá excepciones claro está), además de existir personas con más amor incluso que los que tienen éxito, que no consiguen alcanzar esas cotas (algo que es lógico, ya que el amor aún siendo una herramienta importantísima, no es el único factor que influye).

El amor viene acompañado del respeto, por lo que los que estamos enamorados de esta profesión sentimos un importante respeto por ella y por los que se dedican a ella. Este es uno de los pilares en los que se fundamenta la ética informática: la defensa de la profesión y de sus profesionales. Si los que nos dedicamos a la informática en general o al desarrollo de software en particular echamos por tierra la profesión, nos estaremos haciendo un flaco favor a nosotros mismos, ya que la estaremos desprestigiando y quitándole parte de la importancia que tiene. De esto tenemos que aprender de otras muchas profesiones más antiguas que han entendido perfectamente todo esto y que ha permitido que tengan la consideración social y económica que se merecen (y en algunos casos, incluso más). Cuando los que nos dedicamos a la informática, desplacemos un poquito el ego, entendamos que juntos podemos hacer más cosas y nos respetemos más entre todos, probablemente la situación empiece a cambiar, tal vez no drásticamente, pero sí que aunque el crecimiento sea lento, lo empezaremos a notar.

No sólo basta con que no critiquemos injustamente nuestra profesión, sino que también hay que defenderla en todos los foros en los que sea posible, desde van desde nuestra casa, pasando por el trabajo o por cualquier medio en el que se menosprecie o se ataque a la misma. Esto no quiere decir que no podamos ser capaces de reirnos de nosotros mismos, eso es treméndamente sano y constructivo y un gran ejercicio que todos deberíamos hacer tanto en el ámbito profesional como en el personal, o que no podamos aceptar críticas, siempre que estas sean constructivas, ya que siempre nos ayudarán a crecer como profesión, pero una cosa es eso y otras las críticas injustas, sin base alguna o aquellas basadas en rancios estereotipos.

Quiero dejar bien claro, que cuando hablo de profesión informática no estoy restringiéndome a aquellas personas que hayamos estudiado Informática, ya sea en la Universidad o en un Ciclo Medio o Superior, sino al conjunto de profesionales de la informática, sea cual sea su procedencia. El asunto de las titulaciones, es otra materia objeto de estudio, pero creo que antes, hay que solucionar otros aspectos importantes en nuestra profesión antes de entrar en un debate sobre este aspecto que a día de hoy rompería nuestra profesión por la mitad y se gastarían energías en una guerra que no conduciría a nada.

La ética informática no sólo trata de la defensa de lo nuestro, sino que hace referencia a otros comportamientos que deberíamos tener los que nos dedicamos a esta profesión. Tal vez, haga referencia a ellos en algún futuro artículo sobre la materia.

Siento amor por mi profesión, como todo amor y como todo en la vida hay altibajos, pero ahí sigo, haciendo lo que me gusta y por eso me puedo considerar un auténtico privilegiado.

Todos sabemos que cuanto mayor sea la ayuda de los usuarios en un proyecto de desarrollo de software, mayores serán las probabilidades de éxito que tenga el mismo.

No obstante es importante hacer algunas matizaciones:

1) El proyecto no se hace sólo, porque incluso existiendo una gran ayuda por parte de los usuarios, si no se consigue interpretar con precisión lo que quieren y no se dinamiza un feedback continuo de los mismos durante todo el proceso de desarrollo, se incrementarán las posibilidades de que algún requisito funcional no se haya recogido adecuadamente o de que se haya realizado un software con una usabilidad incómoda para los usuarios.

Estas circunstancias son fuente de innumerables problemas en las fases finales del proyecto y provocan retrasos, sobrecostes y grandes dificultades para cerrar el proyecto, además de crear conflictos con el cliente que pueden perjudicar las relaciones futuras con el mismo. Esto hace que sea fundamental el papel que desempeñan tanto el jefe de proyectos, como el equipo de analistas funcionales y analistas programadores.

2) Es importante que entre el grupo usuarios asignados al proyecto haya usuarios que vayan a estar implicados en el futuro uso del sistema de información, es decir, no es suficiente que el equipo de usuarios esté formado por “ideólogos” o “teóricos” que se nutrirán del resultado del trabajo de la herramienta, sino que es fundamental que participen usuarios que después se tengan que poner el mono de trabajo y vayan a trabajar con el software. Es importante conseguir la combinación de ambos tipos de usuarios (tampoco es positivo que en el grupo de usuarios no participen usuarios directores, ya que pueden existir conflictos entre usuarios que éstos deben solucionar y también es recomendable que el software no sólo se diseñe para el corto plazo, sino que sirva para tareas de gestión, planificación, etc… y esta visión la proporcionan principalmente los usuarios directores), por lo que el jefe de proyectos debe poner en conocimiento del cliente esta necesidad, como es lógico explicando los riesgos de que no se aplique esta estrategia.

3) Los analistas están para ayudar y para colaborar con los usuarios en la especificación y diseño de la solución, pero no están para “dar lecciones” a los usuarios y enseñarle cómo deben hacer su trabajo. Si los usuarios hacen su trabajo de una determinada manera, aunque no sea la más ortodoxa, siempre tendrá una justificación que sólo se entendería si realmente estuviéramos haciendo su trabajo durante un tiempo y viéramos los problemas con los que se enfrentan cotidianamente. La clave por tanto está en la colaboración y en el diálogo, es decir, se pueden proponer cosas al usuario, se le pueden dar ideas, pero no se le puede dar una vuelta al calcetín de cómo hacen sus tareas, salvo que ellos mismos lo soliciten y procurando en estos casos y en consenso con los usuarios que los cambios sean tranquilos.

4) Es fundamental documentar el proyecto, en primer lugar con la documentación que se especifique en las normativas de desarrollo de la organización para la que se realiza el servicio, con las matizaciones que indique el Director del Proyecto, en segundo lugar con la documentación que establezcan las normativas internas de calidad de tu organización (no requerirá un sobreesfuerzo, ya que en la mayor parte de los casos coincidirá) y a todo lo anterior sumarle toda la documentación de trabajo que sea necesaria para trabajar con los usuarios, que no tienen por qué entender de modelos de datos, de diagramas de casos de uso, etc…, es más, es un error trabajar con los usuarios utilizando dichas herramientas, ya que estas son de utilidad técnica y no hablan el mismo lenguaje de los usuarios. Este tipo documentación, por tanto, no tiene por qué tener los formalismos de la técnica y tiene como objetivo que el usuario capte lo que el analista está interpretando y se pueda ir perfilando a partir de esto, tanto requisitos, como casos de uso, interfaces, etc… Es muy importante trabajar todo esto, ya que comenzar demasiado pronto con la construcción, es algo muy arriesgado, ya que los costes de modificar algo en las distintas fases de la construcción pueden ser muy importantes y provocar que se tengan que reconstruir varias veces distintas funcionalidades de la aplicación.

La innovación depende mucho de la competencia, en una situación en la que exista ausencia a la misma, las organizaciones no se verán obligadas a innovar, más allá de la necesidad de ir sacanzado productos nuevos (que no necesariamente innovadores) para tentar a los propietarios de versiones anteriores a que los adquieran. Por ese motivo siempre veréis en mis artículos que independientemente de mis preferencias por un producto o por una determinada solución, no tengo inconveniente en desear que a sus competidores le vayan bien, porque al final en esta competencia, ganaremos todos. Como es lógico esta es la visión de un usuario, los propietarios o accionistas de empresas posiblemente tendrán una visión distinta.

Por todo eso, un portazo a la innovación es la falta de competencia, ya sea por la ausencia de competidores o por acuerdos de exclusividad.

La innovación en muchas organizaciones es un gasto secundario, es decir, si les va bien o si les sobra algo de dinero, se puede tomar la decisión de destinarlos a I+D. El portazo en este caso es pensar que la inversión en I+D no es algo productivo y que se aleja de los problemas de subsistencia del día a día de la empresa (o lo que es lo mismo, creer en lo tangible que es el dinero y no creer en lo que podría ser, la inversión en innovación). Cierto es que invertir en I+D no tiene porque garantizar resultados, es decir, existe un riesgo de que la inversión no sea rentable, pero también es cierto que es el I+D lo que puede marcar en un momento dado la diferencia en el mercado a nivel de producto (después entrarán en juego otros factores para que éste tenga éxito o no) o con la competencia a nivel de producción.

Como comenté en el párrafo anterior, la innovación necesariamente requiere de una inversión, es decir, se tendrá personal y equipos dedicados exclusivamente o en parte a mejorar productos, mejorar el proceso de producción, obtener nuevas soluciones, etc… y todo eso vale dinero. Por tanto, para poder innovar, se requiere tener capacidad económica para hacerlo y ésta se obtiene o bien del mismo proceso innovador o del negocio de la compañía (hasta que los resultados del departamento de I+D sufraguen sus gastos). El negocio al final se reduce a la fórmula de ingresos-gastos y por tanto para que haya dinero se puede conseguir aumentando los ingresos y/o reduciendo los gastos. Donde me gustaría incidir es en los gastos, ya que estos, en mi opinión, originan otro portazo a la innovación, estos gastos pueden ser indirectos, como la falta de productividad o directos (pagos de impuestos, suministros, servicios, etc…), por tanto es necesario optimizar los mismos (sobre esto quiero aclarar que los costes de personal, sólo deberían ser un problema cuando no están acordes a la productividad y sus resultados y que la optimización, por ejemplo, la fiscal, la entiendo siempre y cuando ésta revierta sobre la organización y se mantenga dentro de unos niveles éticos). Cierto es que algunos de vosotros pensará, ¿y por qué no incides en los ingresos?, pues porque aunque es otra variable de la fórmula y por tanto también se debe tener en cuenta, desde mi punto de vista el equilibrio se consigue a través de un entorno productivo donde los costes estén controlados y sean racionales.

Por tanto, el proceso innovador no es algo sencillo o casual, requiere un entorno de competencia, que se crea firmemente en él y que se dispongan de medios para llevarlos a cabo.

Aunque no lo sea. Cuando trates con un cliente, tu equipo es el mejor que existe sobre la faz de La Tierra y todos los que participan en él son unas auténticas máquinas.

Como es lógico esto es una exageración y no es necesario llevarlo a este extremo, pero sí que es conveniente que ante el cliente los miembros de tu equipo nunca sean criticados por otro miembro del equipo de proyecto o de la organización. Estas críticas, no aportan absolutamente nada y casi siempre se terminan volviendo en contra del proveedor, ya que le estás dando al cliente de forma gratuita argumentos para justificar por qué un determinado tipo de proyecto no está funcionando adecuadamente.

Por otro lado, los responsables de proyecto deben dar la cara siempre ante el cliente ante cualquier problema, haciéndose precisamente eso, responsables, de cualquier contingencia que ocurra y defendiendo a los miembros de tu equipo. No es algo agradable comerse una bronca, tenga o no razón el cliente, pero eso está en el sueldo de los jefes de proyecto y en sus funciones y es totalmente injusto que la reciba una persona que está a tu cargo y todavía más si se le falta al respeto, incluso aunque haya metido la pata hasta el fondo. Después ya habrá tiempo de depurar, si fuera necesario, responsabilidades, pero siempre, como he comentado, entre las cuatro paredes de tu organización, ya que los trapos sucios siempre deben lavarse en casa.

Un jefe de proyectos que da la cara por los miembros de su equipo y los trata con justicia gana respeto y credibilidad y proporciona una barrera de seguridad que hace que las personas que trabajan en el proyecto ganen en confianza y se crean lo que su jefe de proyectos le está diciendo. Ambas cosas son muy importantes, ya que un equipo sin confianza es un equipo desmotivado y que produce muchísimo menos y un equipo que no cree en su responsable difícilmente podrá mantener su compromiso y dedicación mucho tiempo, lo que también tendrá consecuencias en la productividad.

Como es lógico, se podría haber empezado con una hoja en blanco y empezar el proyecto con la ronda de entrevistas indicada anteriormente, pero por experiencia previa en otros proyectos de similares características, por muy preparadas que se pretendan tener las entrevistas y enviando con suficiente antelación documentación explicativa de lo que se quiere obtener, si no hay nada concreto y no se les hace llegar a los entrevistados previamente, un listado de indicadores que puedan servir de referencia y/o se trabaja con uno de ellos en la reunión, al final se terminará improvisando por parte del usuario (que además por sus características concretas en este caso tendrá poco tiempo para ser entrevistados y es posible que incluso sufra interrupciones durante la reunión) y se dejarán indicadores importantes en el tintero. Por tanto, lo que pretende esta primera versión del catálogo es servir de apoyo a la elaboración de una versión que sí ha contado con la participación de las personas (los responsables de los Centros Directivos) que a través de sus equipos de trabajo van a obtener provecho de la explotación de este Datamart.

Una vez consolidada una nueva versión del catálogo de indicadores, tras la revisión y depuración por parte del equipo de proyecto (será necesario porque se obtendrá información en bruto de las entrevistas y es conveniente hacer ese trabajo), la siguiente fase será realizar un prototipado de diferentes cuadros de mando que se pueden obtener a partir de la explotación de los indicadores. Esta fase tiene su razón de ser para este proyecto concreto, ya que no pretende quedarse sólo en la construcción del Datamart y de los procesos de extracción, transformación y carga, sino que pretende darle desde el principio una salida práctica a los responsables de los centros directivos y su equipo, mediante la construcción de cuadros de mando. ¿Sería interesante esta fase si el proyecto se quedase simplemente en la construcción del Datamart y éste se explotase mediante herramientas de análisis de datos o de otro tipo? Pues tal vez no, pero si se realiza permitirá una mayor depuración del Datamart antes de ser construido, ya que los usuarios, por regla general, funcionan mejor cuando ven realidades, aunque estas vengan en forma de prototipo. Como en este caso, tenemos que producir de salida un conjunto de cuadros de mando, no nos planteamos esta pregunta, procedemos a la elaboración de prototipos y a una segunda ronda de entrevistas, que permitirá acertar más en el diseño de los cuadros de mando y depurar el listado de indicadores que más que probablemente volverá a modificarse en esta fase.

Tras la finalización de la segunda ronda de entrevistas con los responsables de los centros directivos, tendremos unos prototipos trabajados y validados, así como un conjunto de indicadores más depurado, por lo que ya se estaría en disposición de construir el Datamart, los procedimientos ETL y posteriormente el conjunto de cuadros de mando.

Como veréis en este tipo de proyectos, le doy mucha importancia a la fase de análisis, lo cual puede dar a entender que el proceso de construcción no es complejo, algo que no es así. ¿Por qué le doy tanta importancia entonces? Pues porque en proyectos de estas características, si no se acierta en los indicadores que sirven de base para la construcción del Datamart, todo el trabajo que se realice no sirve de nada. Algunos diréis, “Cierto, pero eso pasa en todos los proyectos de desarrollo de software, ya que en todos hay requisitos.” y yo os tendré que dar la razón, pero si ya es complicado obtener un catálogo de requisitos y un conjunto de casos de uso preciso en un proyecto de desarrollo estándar, todavía lo es más cuando se pasa a algo más abstracto como es la definición de indicadores, que van más orientados a una gestión a medio y largo plazo, que a la gestión o trabajo operativo o a corto plazo que hacen los usuarios con los sistemas de información.

Una vez elaborada la primera versión del catálogo de indicadores, se dividirá en una serie de partes que se encargarán de trabajar por separado diferentes subequipos del equipo de proyecto, cada uno de los cuales está formado por personal experto en la temática o temáticas en que se ha dividido y ellos a su vez se encargarán de forma autónoma de recabar la información suficiente con otros expertos de la casa para afinar lo máximo posible su subcatálogo. Una vez trabajadas cada una de esas partes se volverán a consolidar en un solo documento y a partir de ahí se empezará una ronda de entrevistas con los responsables de cada centro directivo.

Es importante señalar que se van a descartar aquellos posibles indicadores que aún siendo interesantes, no tengan clara su obtención a partir de una fuente de datos accesible, de esta manera no perdemos energía y tiempo en estudiar aquellos que no van a poder producir resultados. En todo proyecto de construcción de Datamarts sobre procesos de negocio que afectan a diferentes departamentos de una organización, las principales dificultades van a estar en localizar las fuentes de información y, por supuesto, en la definición de indicadores que sean útiles. Por este motivo, indicadores y fuentes deben ir de la mano.

Aunque las fuentes sean accesibles, hay que valorar la complejidad de diseñar los procedimientos ETL (Extracción, Transformación y Carga) a partir de las mismas.

Cuando las fuentes sean sistemas de información, la implementación de esos procedimientos es bastante simple, aunque hay que tener en cuenta que si la base son modelos de datos y no servicios, la modificación de estos, implicará una necesaria modificación de los ETL. Por este motivo, es importante no sólo desarrollar los ETL sino también documentar perfectamente la fuente de la información y las transformaciones que se hacen sobre la misma antes de cargar el dato.

Cuando las fuentes sean ficheros, la complejidad de los ETL por término medio se incrementa y en algunos casos no será posible hacer un ETL sobre alguno de ellos. Esos ficheros pueden estar en diversos formatos: OpenOffice.org Writer, OpenOffice.org Calc, Excel, Word, Access, pdf, etc… y en muchos casos no estarán estructurados. En estos casos hay que valorar la importancia del indicador, la posibilidad de que el fichero a cargar pueda ser entregado por la fuente de manera normalizada en un formato fácilmente tratable informáticamente o bien la disponibilidad de un equipo que haga estas tareas de “precocinado” previo antes de aplicar el ETL (entendiéndose el concepto de ETL como algo absoluto, es decir, como el conjunto de operaciones que se realizan sobre el juego de datos de entrada, para extraerlo y transformarlo, hasta su carga, muchos consideran que ese precocinado es parte propia del ETL, independientemente de que después ese “precocinado” tenga un tratamiento informático posterior para terminar de transformarlo y cargarlo. Yo personalmente, aunque tal vez no sea lo más ortodoxo del mundo, distingo entre las tareas previas manuales o semimanuales para preparar los datos para el ETL, del propio proceso de ETL).

¿Por qué es necesario considerar esos factores? Pues principalmente porque el presupuesto del proyecto es limitado y si nos ponemos a construir ETL complejos sobre un número elevado de indicadores, nos vamos a comer el dinero en esto, algo que no es ni práctico, ni conveniente. Además, tenemos el handicap de que podemos invertir en hacer estos ETL complejos, pero en el momento en que nos cambien el la estructura de los datos en los ficheros de entrada o su formato, la inversión realizada en el ETL complejo no habrá servido y habrá que realizar modificaciones sobre el mismo o incluso implementar uno nuevo (si los cambios en la fuente de entrada han sido importantes) ¿Que habrá que construir algún que otro ETL complejo sobre algunos ficheros para obtener directamente, sin intervención humana, la información necesaria para dar respuesta a un indicador? Pues es algo que será muy probable e incluso necesario en algunos casos, sobre todo en aquellos donde una transformación manual o semimanual sea tremendamente pesada, costosa y con probabilidad de error y el indicador o indicadores que pueden requerir esa información se consideren relevantes. Pero en el resto de casos, si es posible lo mejor es plantear un modelo objetivo de formato de la información y del fichero e intentar alcanzar acuerdos para que la información sea entregada en ese formato o bien tener medios humanos para realizar esa transformación. ¿Que no es posible alcanzar esos acuerdos o no se dispone de esos medios? Pues habrá que recurrir entonces a realizar los ETL sobre dichos ficheros, pero volvemos a lo mismo, serán procesos complejos, por lo que hay que habrá que priorizar aquellos indicadores que tengan una mayor importancia.

En cualquier caso, es fundamental documentar, como he comentado anteriormente los ETL y si hay que realizar un proceso manual o semimanual para pasar una información que viene estructurada de una determinada manera en un fichero con un determinado formato a una estructura y formato objetivo, también es necesario documentarlo, especificando además quién debe suministrar los ficheros originarles y con qué periodicidad. Esta documentación es necesario mantenerla perfectamente actualizada.

Continuará…

Hace poco tiempo se ha iniciado un proyecto en el que tengo la oportunidad de participar que tiene como objetivo construir un Datamart para la explotación de la información relacionada con los indicadores de estado y gestión de mi organización.

La organización en la que trabajo es muy grande y abarca temáticas muy variadas, esto hizo que la primera decisión que tomó el equipo de personas que participa en el proyecto fuera delimitar el alcance, ya que si intentásemos abarcar todas las necesidades de explotación de la organización a diferentes niveles, probablemente el proyecto se nos fuera de las manos. De esta manera, decidimos que este proyecto fuera una versión número uno o una primera vuelta a la espiral y que se limitase a construir el Datamart para explotar los indicadores de gestión y de estado que sirvieran para la gestión estratégica y táctica de los responsables de cada centro directivo. Más adelante, si este primer proyecto da los resultados que todos esperamos, se abordarían niveles inferiores en la jerarquía, que precisarían de información más en detalle y más variada, algo que es lógico ya que en dichos niveles se opera a más bajo nivel.

Al delimitar el alcance, reducimos la complejidad del proyecto, pero esto no significa que el camino vaya a ser sencillo, ya que a día de hoy no existe en mi organización un catálogo de indicadores de gestión y de estado (no quiero decir con esto que los que tienen que gestionar no sepan cuáles son sus objetivos y que métricas deben tener para evaluar cómo van los mismos, lo que quiero decir es que no están escritos y unificados en un sólo documento), a diferencia de otros catálogos de indicadores que si existen y están consolidados, que si bien en algunos casos tendrán indicadores coincidentes con los de gestión y de estado, en la mayoría de los casos no será así. La suma de los almacenes de datos de los catálogos de indicadores ya existentes (en la actualidad se está trabajando también en la construcción de sus correspondientes Datamarts) más el que se va a elaborar del catálogo de indicadores de gestión y de estado, constituirán el Datawarehouse de la organización, que como he indicado, una vez elaborado deberá seguir evolucionando en la parte correspondiente a estos últimos indicadores (independientemente de que sufra modificaciones, aunque se prevé que sean menores, en los otros).

La no existencia de ese catálogo hace que tengamos que empezar prácticamente desde cero, afortunadamente se cuenta con documentación suficiente para elaborar una primera versión del mismo sin necesidad de comenzar un proceso de entrevistas, entre dicha información se encuentran, planes estratégicos de mi organización, el plan de sistemas, los catálogos de indicadores ya elaborados y algunos análisis de indicadores para procesos concretos que ya se han realizado.

Afortunadamente para este proyecto, el equipo temático que participa en él, está formado por personas con un gran conocimiento de la organización, que tienen experiencia en el trabajo con indicadores, tienen los pies en el suelo y creen que a partir de él se pueden obtener unos resultados útiles. De lo contrario, este proyecto estaría abocado más que probablemente al fracaso.

Continuará…