archivo

Archivos diarios: mayo 12, 2012

Producto, siempre el producto, por encima de los procesos, sin que estos deban obviarse o dejarse de lado.

Se ha enfocado y asociado de manera errónea la calidad del producto a la calidad del proceso, lo que ha provocado que los esfuerzos se hayan centrado en el proceso, de tal forma que en muchos casos se considera un fin y no un medio para conseguir el verdadero objetivo que es desarrollar software de calidad.

Y todavía peor que eso, se asocia en muchos casos la calidad del proceso a la cantidad del papel generado y por tanto, de manera transitiva, el producto software era tan bueno como kilos de papel se hubieran generado en el desarrollo.

Por ese motivo, la realización de análisis o conclusiones finales sobre proyectos que se centren exclusivamente o principalmente en aspectos procedimentales me parece un error, entre otras cosas porque incluso en aquellas circunstancias en las cuales el proyecto haya ido bien y haya sido a nivel de proceso ejemplar nos podemos encontrar con que el producto final es muy costoso de mantener por tener una deuda técnica alta o por tener una arquitectura no escalable.

El proceso debe estar al servicio del producto y a las necesidades que se tengan en su proceso de desarrollo, las cuales estarán muy condicionadas por las circunstancias y contexto en que se realiza.

Hace poco un programador me comentó que una tarea de mantenimiento le estaba llevando más tiempo del previsto debido a que la mayoría de los métodos de las clases que estaba tocando tenían un nombre que daba lugar a una mala interpretación con respecto a su función real y que en otros casos no tenía absolutamente nada que ver (algo así como si en lugar de crear un método nuevo se hubiera reutilizado otro ya obsoleto y no se hubiera cambiado su nombre).

Pueden parecer detalles pequeños, sin importancia, pero la realidad es que cuestan dinero no solo porque se requiera más tiempo para realizar un mantenimiento sino porque la probabilidad de que se produzcan errores en el mismo se multiplica.

La programación no es solo crear y encajar piezas. Es muy importante tener en cuenta que otras personas después tendrán que trabajar con él y no solo eso, escribir código de forma clara e inteligible es una señal de calidad que puede marcar la diferencia entre un tipo de programadores y otros o entre una empresa y otra.

Los hechos deben suceder a las palabras. Las palabras tienen caducidad si detrás de las mismas no hay hechos consecuentes con las mismas. El problema no es solo que las palabras dejen de tener valor sino que también lo pierde el que las pronuncia.

Las palabras son muy fáciles de ser pronunciadas o escritas, los hechos requieren el valor de la acción. Las palabras son solo teoría, los hechos son la práctica.

Esto no quiere decir que no podamos rectificar, al contrario, si nos hemos equivocado rectifiquemos cuanto antes, pero expliquemos antes por qué lo hemos hecho, después el tiempo dirá si la primera intención era la acertada o no, tal vez el tiempo también dicte si las sucesivas rectificaciones también lo eran.

No se trata tanto de acertar como de ser consecuente con el discurso y con los cambios que se hagan en el mismo. Acertar tiene su valor pero como persona, como gestor o como compañero pierdes valor si tu voz y tus actos siguen caminos divergentes.

¿Por qué algo que a todas luces es beneficioso e incrementa la productividad en las organizaciones y en las relaciones entre ellas y sus clientes (sean otras empresas o particulares) no termina de extenderse de manera generalizada?.

Los motivos pueden ser muchos. Yo no soy un profesional del mundo de la firma electrónica y los certificados digitales por lo que lo más probable que aquellos que se dedican directamente a esto tengan un criterio más acertado y sólido que el mío.

Un problema importante que nos solemos encontrar cuando queremos realizar la firma electrónica o la autenticación es la fragmentación tan importante que existe en el software que permite hacer estas funciones, algo que podemos notar sobre todo en su compatibilidad con los navegadores. Es decir, para una organización concreta hacer un trámite implica una conjunción planetaria para instalar una versión de navegador que te permita realizarlo (probablemente una versión obsoleta del que ya utilizas u otro navegador que juraste desterrar para siempre jamás de tu sistema operativo), después de haber conseguido esta magia, toca de nuevo hacer un sortilegio cuando vayamos a intentar hacer otro con otra organización.

Es evidente que tener una amplia matriz de compatibilidad con los navegadores es una ventaja competitiva para este tipo de software y que todas las empresas que se dedican a esto invierten en esto, sin embargo los clientes de las mismas, sobre todo si se trata de administraciones tardan en recibir e instalar las actualizaciones, entre otras cosas por la fragmentación que existe en las mismas en relación a los servidores locales que tienen instalados.

Otra ventaja competitiva de las empresas de este sector podría ser minimizar el tiempo que existe entre la liberación de una nueva versión del software y su instalación en el cliente con el menor impacto posible (a ser posible nulo) sobre el software que hace uso de los servicios de autenticación y firma electrónica.

Sin embargo los propios acuerdos de licencia que se suelen establecer favorecen la fragmentación ya que suelen restringir las actualizaciones del software, obligando a volver a realizar un nuevo contrato de licencia tras una evolución significativa (o tal vez no tanto) del producto.

Es lógico que las empresas quieran ganar dinero pero a veces lo que se gana por un lado se pierde por el otro, ya que este tipo de circunstancias no favorecen ni mucho menos la expansión del negocio.

Otro aspecto que se suele olvidar es que el ciudadano de a pie está acostumbrado a que documentos serios tengan una rúbrica, eso da legitimidad al documento desde el punto de vista psicológico. Eso está impregnado en la sociedad y dudo muchísimo que a corto/medio plazo eso varíe.

No se trata de emular la rúbrica, en cierto modo eso ya se hace con el “sello de firma” que se suele colocar en los documentos que se han firmado electrónicamente cuando son descargados o se envían a una persona o entidad concreta, entonces, ¿dónde está el problema? pues en la escasa capacidad que tiene el receptor del documento en un formato físico de verificar si efectivamente ese documento es válido o no, en unos casos porque no se ofrece esa posibilidad y en otros por la fragmentación existente en este tipo de sistemas, lo que te obligaría a tener que llamar a prácticamente tantas “puertas” distintas (en el caso de que las haya) como entidades u organizaciones de las que has recibido este tipo de documentos.