archivo

Archivos Mensuales: septiembre 2009

Hace un tiempo, nos hicieron una presentación de una herramienta software.

La persona que nos hizo la presentación, la cual no conocía de antes, aunque tenía referencias de ella, demostró en la misma una brillantez que muy pocas veces había visto. Sin embargo lo que más me llamó la atención no fue eso, sino su honestidad. A una reflexión que hice sobre lo que yo esperaba de herramientas de las características de la que nos estaba presentando, me contestó que tenía razón y que lo realmente importante no era la herramienta en sí, siempre que esta alcanzase unos mínimos, sino las personas que la utilizaban.

Evidentemente ni en lo que yo dije, ni lo que él me respondió, se descubrió nada que no se supiera, lo importante es que no se escudó en el producto, pese a ser excelente, sino que contestó realmente lo que pensaba y lo apoyó con razonamientos.

Unos de los principales inconvenientes que tengo en el desempeño de mi trabajo (y debo ponerle remedio algún día) consiste en la gran variedad de tareas que realizo, que van desde tareas muy operativas hasta tareas que están muy por encima de mi puesto de jefe de proyectos.

El inconveniente no trata de que no me guste realizar esas tareas, antes al contrario, tanto las operativas como las de alto nivel me gustan muchísimo, cada una me aporta cosas, las primeras me permiten no perder el pulso del trabajo del día a día, de estar inmiscuido en los procesos, en el trato con los usuarios, con mis compañeros y las segundas intentar llevar a la práctica mis esquemas mentales de cómo deben hacerse determinadas cosas. El inconveniente es que en demasiadas ocasiones ambas cosas me restan tiempo para mi trabajo como jefe de proyectos y también en demasiadas ocasiones la proporción de tiempo que dedico a tareas de carácter operativo supera con creces a las tareas de nivel táctico y estratégico. Por este motivo necesariamente y ya lo llevo aplicando desde hace un tiempo, voy desligándome poco a poco de las tareas de carácter operativo, lo que repercute en una mayor disponibilidad de tiempo para las tareas de jefe de proyectos y aquellas otras tareas que me tienen encomendadas en mi departamento.

Un aspecto importante, los que hayáis leído mi artículo sobre los roles de las personas en las organizaciones, podréis ver una contradicción entre el contenido del mismo y lo que comento en este post y en el caso personal que acabo de comentar. Sobre esto comentar algunas cosas:

– Aunque es cierto que la realización de otro tipo de tareas me quitan tiempo, la parte fundamental y nuclear de las tareas que realizo están relacionadas con la dirección de proyectos informáticos, siendo para mi prioritario la realización de las mismas.

– Entre el negro y el blanco, hay toda una escala de colores. Asumir un rol no debe implicar falta de flexibilidad para realizar o asumir otras tareas de forma puntual o con una mayor persistencia en el tiempo, sino el ser consciente que el nuevo rol debe ser la porción más importante de la jornada laboral.

– La organización a la que pertenezco tiene muy poca flexibilidad, por lo que muchas de las tareas que realizo, las hago para cubrir huecos no cubiertos en procesos y apoyar la realización de determinadas tareas para los que no existen puestos de trabajo específicos en mi organización.

Cualquier propuesta de diseño o implementación de un Datamart o de un Datawarehouse termina chocando con el concepto de calidad del dato. De nada vale hacer una implementación modélica de los modelos de datos del Datamart o el desarrollo de unos procedimientos ETL que permitan extraer la información de diferentes sistemas o fuentes de información y coloquen los datos en el repositorio listos para ser explotados haciendo uso de las herramientas correspondientes, si al final el problema está en la base, en la información de partida, ya que si el objetivo final de todo Datamart es la explotación de la información con un determinado propósito, el resultado final estará contaminado si los datos de partida están contaminados.

Hace unos días en una reunión volvió a salir este tema, ¿se debe parar el desarrollo de Datamarts sin que los datos de partida estén del todo bien? Mi respuesta a esto es que si el desarrollo de Datamarts es un objetivo de la organización (como es en este caso), no debe parar la iniciativa el recurrente problema de la calidad del dato, ya que entre otras cosas, los Datamarts y las distintas alternativas existentes para explotar la información, tienen la ventaja de que permiten descubrir datos incompletos, inexistentes y erróneos, y además, el problema de la calidad del dato, es un tema que no se soluciona de manera sencilla y que generalmente se afronta como un proceso de mejora continua (en la mayoría de los casos bastante lento).

La calidad del dato está relacionada con la visión que tenga el usuario sobre la información que está grabando en el sistema, es decir, si considera que el sistema de información como un instrumento a corto plazo, en el que introduce unos datos y le proporciona unos servicios (y la calidad del dato no resulta fundamental para obtener el servicio), los datos por regla general no serán buenos, ya que el usuario no tiene conciencia de la utilidad que tiene que los datos estén más o menos completos o más o menos bien.

También existen otros factores, como la usabilidad del sistema de información (cuanto menos usable sea un sistema de información, peores serán los datos), la flexibilidad del sistema (este caso es un poco paradójico, ya que la flexibilidad de un sistema está intimamente ligada a su usabilidad), pero resulta que en un sistema muy flexible (sin apenas controles) se deja prácticamente la responsabilidad de lo que se graba en el usuario y por tanto en la visión que él tenga de la necesidad de grabar datos con calidad.

Otro factor muy importante es la visión corporativa que tenga la organización de la información, es decir, si en la organización no existe conciencia de que una información consistente, coherente y de calidad sobre una determinada temática, requiere de un repositorio de información de procedencia (aunque sea alimentado por distintas fuentes (distintos usuarios)) y que esos repositorios se alimentan a través de sistemas de información, será mucho más difícil que los datos que se graben tengan calidad, ya que la gestión se centra en cumplir con las tareas del día a día y no existen unas instrucciones generales o normativa interna, que por un lado obligue a utilizar los sistemas de información corporativos y por otro que haga que los datos que se introduzcan en ellos sean los más completos y exactos posibles.

Lo que más puede llamar la atención es el concepto de portabilidad, un ejemplo sencillo, en casa utilizo la distribución Linux Ubuntu, en el trabajo Windows, si quisiera instalar Microsoft Office en mi PC doméstico (suponiendo que tuviera la licencia oportuna) no podría (quitando otras posibles soluciones como tener un sistema operativo Windows como máquina virtual, Wine, etc…), este ejemplo es extensible a una gran cantidad de software que funciona en unos sistemas operativos y que en otros no (salvo que se rehaga completamente). La portabilidad se puede ver desde diferentes puntos de vista, portabilidad a nivel de código fuente, es decir, tener una aplicación que sin tocar el código fuente pueda funcionar en diferentes sistemas operativos mediante su compilación en los mismos, portabilidad a nivel de ejecutable o de software interpretable, la están proporcionando las soluciones basadas en máquinas virtuales, como por ejemplo Java, Mono, etc…, portabilidad de datos, etc… La portabilidad es, a mi juicio, una de las causas que está afectando al impulso definitivo de Linux, ya que la cantidad de software disponible en Windows y Mac (sobre todo en el primero y sobre todo a nivel de diferentes opciones a elegir) es sensiblemente superior. No obstante, la orientación del uso de aplicaciones en la nube y la aparición de cada vez más software en Linux, puede romper esa tendencia.

La portabilidad de la información no es un concepto que debamos dejar de lado, ya publiqué hace un tiempo un artículo que lleva el mismo nombre que el documental que me inspiró el mismo “La oscura era digital”. Es muy importante, si queremos que la información persista en el tiempo que el formato lógico en que se almacena se base en un estándar abierto, de lo contrario si queremos persistir la información, necesitaremos tener una copia del programa que lo interpreta y si el sistema operativo en el que se ejecuta tampoco es abierto una copia de dicho sistema operativo y así sucesivamente hasta llegar al hardware más básico de la máquina en que se ejecuta el software.

En resumen, los sistemas abiertos surgieron como una necesidad, casi como un mecanismo de defensa ante una evolución de la industria de las TIC que no era coherente para sus organizaciones usuarias, esta necesidad cambió las reglas del mercado y propició una importante evolución en el mundo de la informática que no hubiera sido posible (o por lo menos hubiera sido mucho más lenta) de otra forma. La estandarización, las especificaciones abiertas, fueron la llave de todo.

En la actualidad, pese a que los sistemas abiertos es una filosofía aplicada de forma general en el mundo de las TICs, en la actualidad y en el futuro existirán muchos productos hardware y software de uso cotidiano que no tienen publicadas sus especificaciones. La tendencia estratégica de estos y otros fabricantes dependerá muy mucho de las reglas del juego que queremos los usuarios que existan.

Lo mismo que el software libre es libertad, los sistemas abiertos también son libertad, libertad de elegir productos hardware y software compatibles entre sí a través de especificaciones que son públicas y convertidas en estándar a través de los organismos correspondientes de estandarización (especificaciones que son controladas por un número reducido de empresas, no forman parte de un sistema abierto, ya que es el mismo problema que dió lugar a los sistemas abiertos, solo que ahora cada pastel se lo reparten entre unos cuantos).

La necesidad de la existencia de sistemas abiertos provocó, por ejemplo, que las administraciones públicas tomasen cartas en el asunto y establecieran normativa en lo que respecta a la contratación pública, evitándose salvo en circunstancias excepcionales la adquisición de sistemas basados en especificaciones cerradas.

Conceptos íntimamente relacionados con los sistemas abiertos son los de interoperabilidad, portabilidad y escalabilidad. La interoperabilidad es la posibilidad de que máquinas (y el software que funciona sobre ellas) de diferentes fabricantes puedan comunicarse entre sí. La portabilidad se refiere a la posibilidad de que un software pueda ejecutarse independientemente de la máquina en la que se ejecute (con las limitaciones de los requerimientos que necesite la aplicación para funcionar). La escalabilidad hace referencia a la posibilidad de adecuar la infraestructura hardware y software a unas necesidades específicas, pudiendo ampliar o reducir dicha infraestructura conforme sea necesario, con los productos que en cada momento se consideren convenientes.

La no existencia de sistemas abiertos provocaba, como es lógico, una incertidumbre muy grande en las organizaciones, ya que la adquisición de una solución hardware resultaba toda una apuesta, ya que suponían una inversión importante y estaban a merced del fabricante. Imaginemos la siguiente situación, una empresa contrata una infraestructura hardware que con el software adecuado permite almacenar las compras y ventas que realiza, la empresa está muy contenta con dicha infraestructura ya que soporta perfectamente los requerimientos que se necesitan, además también está contenta con el fabricante porque tiene un servicio de atención al cliente excelente. Sin embargo resulta que un buen día el fabricante decide que deja de dar soporte a dicha infraestructura ya que ha sacado dos o tres familias de equipamiento más avanzado y conviene promocionarlo. La empresa si quiere reducir riesgos (ya que si falla algún componente hardware no va a encontrar recambio) tendrá que realizar una inversión en una nueva infraestructura que sí se encuentre soportada por el fabricante.

Esto creaba de forma totalmente evidente una auténtica cautividad ante el proveedor, ya que la evolución de las infraestructuras informáticas de una organización estaban totalmente supeditadas a la estrategia comercial del proveedor. En el ejemplo que he puesto por lo menos existía la posibilidad de migrar a una versión superior, imaginemos que el fabricante hubiera declarado quiebra y cerrado la línea de producción, esto hubiera obligado en aquella época a cambiar de proveedor, a cambiar el software y a una costosa y compleja migración de datos.

Esta situación de poder de los fabricantes (que interesaba, como es lógico a aquellos a los que les iba bien) minaba absolutamente la competencia, la posibilidad de componer una infraestructura de servidores, comunicaciones y demás componentes hardware y aplicaciones con productos de diferentes proveedores, lo que permitiría reducir costes y conducir a una situación más lógica, en la que los departamentos TIC decidieran con mayor libertad cuál debía ser su estrategia.

El concepto de sistemas abiertos surgió como una respuesta al crecimiento desorganizado que tuvieron las TICs desde poco antes de la aparición de los ordenadores personarles, época en el que el coste de tener una infraestructura informática se redujo lo suficiente para que se popularizase su uso en el ámbito corporativo. Este concepto pese a que apareció a finales de la década de los setenta y principios de los ochenta y que propició una estabilidad en el sector en la década de los noventa y en la actual, es algo que sigue siempre de actualidad, ya que choca contra los intereses de determinadas compañías del sector.

¿Cuál fue la causa que dió origen a los sistemas abiertos? Pues la existencia de múltiples soluciones hardware y de software cada una de las cuales era incompatible con las demás. Por ejemplo, si una empresa disponía de un software de contabilidad que le resultaba óptimo para su gestión, además de tener almacenada la información de mucho tiempo y sin embargo el equipamiento físico que daba soporte a ese software empezaba a quedarse obsoleto (o se estropeaba), si quería seguir utilizando ese software, tenía que comprarse un hardware compatible con el anterior que sería de la misma marca, aunque existiesen soluciones en el mercado más competitivas en cuanto a funciones y/o precio. Otro ejemplo podría ser al revés, es decir, la empresa utiliza un software de contabilidad que no se ajustaba a las necesidades de la empresa, pero había hecho una inversión importante en infraestructuras y equipos informáticos que todavía estaba lejos de amortizarse y resulta que tras un estudio descubren que la mejor solución la proporciona otro software que es incompatible con la infraestructura hardware instalada.

Esta situación que hoy en día puede resultar un tanto chocante (no tanto si nos ponemos a pensar en ejemplos que suceden hoy día), era el día a día con el que tenían que enfrentarse las organizaciones en aquella época y no solo eso, ya que me he centrado en dos ejemplos muy concretos, cuando podía contar muchísimos más.

Últimamente está muy de moda lo de hacerse una marca personal o mejorarla (a través de la red) y yo lo veo bien. De hecho, ¿quién sabe?, lo mismo algún día salgo del armario, digo quién soy y dónde trabajo, me compro un dominio y me monto un blog con WordPress en un servidor, ya veré (algunos de los lectores de mi blog ya me conocen, porque ya eran amigos y/o compañeros antes de empezar con esto y más de uno que lo lea asiduamente (o me googlee) podrá hacerme un perfil y más o menos tenerme situado en un tipo de trabajo en un tipo de organización).

Lo de hacerse una marca personal es una forma de venderse a uno mismo aunque también, puede ser una forma de que no te compren, es decir, hacerte con una marca personal es una apuesta, aunque si uno sabe qué puede decir, qué no puede decir y qué debe decir (y publicar, ya que no todo tiene por qué ser texto y ya sabéis que una imagen vale más que mil palabras) en un blog (o en un conjunto si se tiene uno o varios personales y se colabora en otros), en Twitter o en cualquier red social no te asegura tener éxito, no te asegura ganar atención, pero por lo menos te puede evitar que tu marca tenga connotaciones negativas.

Como ya dije hace poco (reflexionando sobre un post de Borja Prieto), escribiendo un blog o participando asiduamente en las redes sociales no te hace rico, pero sí te puede hacer ganar dinero si te haces con una marca y te pones a dar conferencias por aquí y por allá, te contratan de consultor estratégico y/o para escribir columnas en prensa digital (o tradicional). Evidentemente eso no es sencillo y solo unos pocos (muy pocos) que llegan a hacerse con una marca sólida, bien relacionada, bien vendida y que han conseguido generar atención lo consiguen (esto requiere un gran esfuerzo (escribir mucho en el blog y leer y responder los comentarios, participar en otros blogs (aunque sea haciendo comentarios) y en otras redes sociales, asistir a múltiples eventos, si te haces lo suficientemente conocido colaborar con medios, etc…), gran preparación y, muy importante, una buena y extensísima red de contactos). Por tanto, el objetivo final de hacerse con una marca personal no debería ser este último (el de hacerte prácticamente un profesional de la divulgación en el campo profesional al que pertenezcas) o por lo menos no se debería considerar antes de haber alcanzado muchísimas metas intermedias. Es como si tras lanzar un producto tu empresa quisiera conseguir un segmento de mercado de la noche a la mañana, a veces se consigue, pero no es lo que suele pasar.

A todo lo anterior hay que sumar como dificultad para hacer que tu marca genere atención es la gran competencia que existe, lo cual se ha agravado con la moda de las marcas personales y lo sencillo que resulta conseguir los medios para dar a conocer dichas marcas (pero insisto, una cosa es que los medios sean sencillos y gratuitos y otra es que se consiga que tu marca tenga repercusión). Por tanto, en la actualidad una marca personal que se lance lo tiene más complicado que si esa marca se hubiera lanzado hace unos años (¿puede haber excepciones? Sí, pero las excepciones, son eso, excepciones) y lo tendrá más fácil que si se lo plantease dentro de unos años.

Un aspecto importante que quiero señalar es que dependiendo de los objetivos que se busquen con la marca personal generar una gran atención puede resultar algo secundario, lo mismo para conseguir los objetivos que pretendes con la marca es suficiente con que se llegue a una audiencia muy concreta (a un entorno más local o a un colectivo determinado). No obstante, en este artículo me he centrado en lo que sería genéricamente conseguir una marca personal en la red y que tenga repercusión suficiente para que ésta tenga el peso necesario para llegar al objetivo u objetivos que haya tras la consecución de dicha marca.

En mi opinión el primer objetivo (en muchísimos casos será más que suficiente) de conseguir una marca personal, debe ser dar a conocerte desde el punto de vista profesional y cuáles son tus ideas y experiencias. Una buena marca personal te hará que tengas más peso en el mercado y también la empresa que te contrate (o te paga en la actualidad), ya que la marca de una empresa también se encuentra influida por la marca individual de cada uno de sus empleados (evidentemente depende del tipo y tamaño de la empresa el peso que pueden tener las distintas marcas individuales). De hecho (y es mi opinión) las empresas deberían favorecer el desarrollo de las marcas individuales de los empleados que quieran hacerlo (no deja de ser otra apuesta, ya que el prestigio de los empleados, además de hacerlos más caros, les abre puertas en otros sitios, pero en cualquier caso la fuga del talento se puede producir siempre).

Hacerse con una marca personal, como indiqué antes, no es sencillo, ni siquiera ese primer objetivo de darte a conocer, ya que para eso necesitas ganar atención y la atención cuesta muchísimo conseguirla y retenerla.

Como todas las marcas, la personal también puede estar sujeta a críticas y estas además suelen crecer conforme se va ganando en popularidad, ya que es lógico que con audiencias mayores surjan en proporción un mayor número de personas que no estén de acuerdo con lo que comentas. Por tanto, en este juego hay que saber que críticas van a existir, una más constructivas otras menos y que hay que sabir convivir con ellas.

Los lectores habituales de mi blog, me habrán visto siempre muy crítico con la postura y comportamiento de los usuarios, pero también habrán tenido la oportunidad de apreciar como defiendo que el resultado final de un producto debe ser siempre satisfacer al usuario y no solo funcionalmente.

Los usuarios son unos de los mejores maestros que pueden tener los profesionales de las TIC en general y los que se dedican al desarrollo de software en general y no me refiero a los directores usuarios o usuarios que actúan de enlace para capturar los requisitos o participar en diversas fases del proceso de desarrollo de software, sino el usuario de paisano, el que no ha tenido nada que ver en el desarrollo y se encuentra delante de un programa que generalmente siempre le causa más problemas que soluciones.

Es muy enriquecedor (aunque quema bastante) trabajar con los usuarios sin filtros (Centros de atención a usuario de por medio) e incluso con filtros de por medio si de alguna manera puedes leer lo que solicitan o incluso tienes que ponerte en contacto con ellos (otra forma muy interesante de conocer a los usuarios es a través de los cursos de formación). Hasta que uno no trata con usuarios, no se tiene una percepción real de lo que es el desarrollo de software. Se puede ser un técnico excelente, extraordinario, fuera de lo común, pero sin el trato con los usuarios se pierde una pizca de realidad que considero muy importante.

Yo noto muchísimo cuando un profesional de la informática ha trabajado con usuarios y cuando no. Cada uno da importancia a cosas distintas en el proceso de desarrollo de software (la diferencia en algunos casos es inapreciable y en otros bastante significativa).

Hace un tiempo tuve la oportunidad de leer en un foro el debate suscitado entre un par de personas en el que una hacía referencia a la calidad de la documentación que le generaba un determinado proveedor y otra hacía mención a la calidad del código que le generaba otro proveedor. Por lo visto ambos conocían a los proveedores y precisamente lo que destacaban de uno era lo que le faltaba al otro.

¿Cuál es mi opinión al respecto? Pues que si bien es valorable que un proveedor entregue documentación de calidad y otro entregue código de calidad, ambos tendrían mucho que aprender de un proveedor que entregue una buena documentación (aunque no sea excelente) y además un buen código (aunque tampoco sea excelente).

Entiéndase por calidad no sólo el continente, sino el contenido (sobre todo el contenido), porque se puede entregar una documentación excepcional que para nada refleje en su conjunto lo que el usuario desea y se puede entregar un código que saque roce el diez en la realización de las pruebas unitarias y en una revisión estática de código, pero que después no verifique el conjunto de requisitos funcionales.

No obstante, hay un aspecto que es importante señalar: una documentación de calidad siempre es un buen punto de partida, una mala (o nula) documentación supone siempre un riesgo muy importante para el proyecto.