archivo

Archivos Mensuales: junio 2009

Me comentaba hace un poco un jefe sobre un aspecto del que se hablaba mucho, pero que él no conocía ningún caso y me decía que era como el quinto polvo, algo del que todo el mundo había oído hablar pero que nadie conocía a alguien que hubiera llegado a él o había experimentado en persona si era cierto.

Pues hay otro mito por ahí, que es la tercera certificación en Java. Estoy harto de revisar currículums de personas en los últimos años y todavía no me he encontrado con nadie, absolutamente nadie, que presente al menos tres certificaciones oficiales Java. Un número reducido presenta la certificación SCJP, un número todavía más reducido presenta la SCJP y la SCWCD, un número aún más reducido presenta la combinación SCJP y la SCBCD, pero más allá de esto no me he encontrado a nadie que tenga tres certificaciones Java.

Utilizando el ejemplo que me puso uno de mis jefes y haciendo una analogía, es igual de complicado llegar al quinto polvo que sacarse la tercera certificación Java y ajustando un poco el planteamiento, tal vez solo sean capaces de llegar al quinto polvo aquellos que consigan obtener la tercera certificación Java.

¿En cuántos proyectos en los que ha participado o desarrollado tu organización habéis empezado desde cero, es decir, desde el framework (si es que hay framework)?.

Si se tiende a cero, mala cosa, por muy potente o poderoso que sea el framework.

Me pongo a analizar algunas empresas desarrolladoras de software de éxito, sobre todo alguna emergente en los últimos años y no me canso de ver el mismo producto base revendido hasta la saciedad o bien adaptaciones del mismo (sin ser productos excepcionales, ni novedosos). Por muy baratos que los vendan (que además no siempre se venden baratos), el beneficio es prácticamente íntegro.

Hay muchos proyectos que por necesidades del cliente sí que se tienen que hacer desde cero e incluso con variaciones en el framework si así lo estiman las normas de desarrollo del cliente. En esto no entro. Sí que entro en otros proyectos donde el cliente tenga unas normas de desarrollo más relajadas y lo que le interese sea obtener un producto que colme sus necesidades, con un precio y plazo de ejecución razonable.

Salvo proyectos muy específicos, en la mayoría de los casos siempre hay partes que se pueden reutilizar de un proyecto a otro. En muchos posts he hablado ya no solo de la necesidad de disponer de un framework lo más potente posible, sino de disponer de un catálogo de componentes de más alto nivel reutilizables. En este post voy más allá, existirán proyectos donde lo que se puede reutilizar es la misma aplicación en sí, variando lo que se tenga que cambiar en la capa cliente (ya sabemos todos que simplemente cambiando la capa cliente una misma aplicación puede parecer otro totalmente distinta aunque la funcionalidad sea la misma) y en la capa de negocio o de acceso a datos. Para que un analista pueda hacer eso, necesita tener un conocimiento general de las aplicaciones que se desarrollan en la casa. Es por esto (aunque el objetivo no sea enseñar los productos para que se reutilicen) por lo que muchas empresas, de vez en cuando (una vez cada cuatro meses o semestralmente), hacen unas jornadas de divulgación entre los empleados, enseñándole a los mismos los proyectos más significativos que han terminado su ejecución en ese período o que están a punto de terminar.

También es cierto que es más complicado reutilizar cuando eres agente pasivo en una contratación, es decir, ganas un concurso (con esto no quiero decir que no se pueda reutilizar, pero digamos que la iniciativa, la lleva como es lógico el que contrata y te puede poner una serie de restricciones en el proyecto que te impidan en gran medida la reutilización), pero es más sencillo si eres agente activo, es decir, tienes un software que resuelve una temática concreta de un negocio y lo vendes a un tercero. Eso sí, en el acuerdo de venta debe quedar muy claro, hasta donde va a llegar la personalización, ya que en caso contrario, te puedes encontrar con que te desvistan entero el producto y sea lo mismo que empezar desde cero.

Hay algo a lo que todavía no me he acostumbrado y es a lo desproporcionado que le parece a personal no relacionado con la informática el coste del desarrollo de proyectos informáticos.

Es una situación que no alcanzo a entender sobre todo cuando esas personas que se sorprenden incluso cuando comentas cantidades irrisorias se gastan muchísimos dinero en hacer otras actuaciones que sí que son realmente caras en relación al precio de los proyectos informáticos.

Esto provoca que en muchas ocasiones se subestime el coste de un proyecto informático con todos los problemas que esto supone, ya que como he comentado en otras ocasiones, los profesionales de la informática no tenemos una varita mágica que haga surgir un análisis y su codificación posterior de la nada, por lo que si el importe del proyecto es inferior a lo que cuesta realmente lo más probable es que el proyecto no vaya bien, por muy diligente que sea el responsable del proyecto y por muchas horas que dediquen los programadores.

Los profesionales de la informática tenemos que hacer sobre esto una labor didáctica, de manera que las personas con las que trabajamos y costean los proyectos entiendan que el desarrollo de software es una actividad tremendamente compleja y como tal tiene su coste.

Si se externalizan procesos completos, es necesario el establecimiento de acuerdos de nivel de servicio.

Dichos acuerdos, permiten que no se vaya a ciegas en la ejecución de un servicio y que se pueda demostrar de forma objetiva que el desempeño del mismo es positivo. Esto es bueno, tanto para el proveedor como el cliente.

El acuerdo de nivel de servicio establece un marco de referencia para el desarrollo de los servicios y propicia la mejora continua de los procesos ya que se basa en la medición de determinados indicadores para determinar si el servicio se está realizando de forma adecuada o no.

Ya he hecho referencia en posts anteriores en la importancia de la medición como pieza fundamental para mejorar la calidad, por tanto el establecimiento de acuerdos de nivel de servicio, permiten garantizar la calidad del servicio y una mejora continua del mismo.

Bien es cierto, que es complicado en ocasiones realizar la medición de los indicadores que determinan el cumplimiento del acuerdo de nivel de servicio, será la experiencia tras la implantación del servicio la que vaya buscando los indicadores más adecuados y busque las estrategias más óptimas para realizar el proceso de medición de los mismos.

Si algo funciona… no lo toques.

Los que nos dedicamos a la profesión informática tenemos la gran virtud de ser personas, por lo general, muy creativas, pero esa virtud se torna en defecto cuando la creatividad choca con la practicidad.

Vamos a ver, si tienes un producto que en otra organización similar ha funcionado, ¿para qué ponerse a tocar el núcleo de la aplicación?. Toca lo que haga falta de la capa de cliente y ajusta lo necesario en el negocio, pero no lo desvistas completamente para volverlo a vestir, porque probablemente se puede producir el mismo efecto que cuando compras un mueble que tienes que montar, ¿cuál es? que te sobre algún tornillo.

Si importante es un análisis de requisitos, no menos importante es hacer un buen modelo de datos.

Hacer un buen modelo de datos no consiste en abstraer la información que hay que persistir a una serie de entidades que verifican al menos la tercera forma normal. Sino en hacer un modelo de datos inteligible y que asegure un buen rendimiento del sistema. Si hay que desnormalizar algunas tablas se desnormaliza. De nada te vale una base de datos teóricamente perfecta si en la práctica hacer una consulta requiere el cruce de miles de registros.

El modelo de datos es importante y la posterior implementación en el sistema de gestión de base de datos final también, ya que además de verificar las directrices de implementación que indiquen los administradores de base de datos del cliente, se debe realizar una implementación que permita exprimir todas las posibilidades que ofrezca el sistema de gestión de base de datos.

Ya comenté la necesidad de especialistas en análisis de requisitos, aqui también resultaría interesante esa especialización o al menos la existencia de un arquitecto de la información que revise los modelos de datos de los diferentes proyectos, los optimice y se preocupe por realizar la implementación más adecuada en el sistema de gestión de base de datos destino.

Un problema que ocurre desgraciadamente con relativa frecuencia consiste en no tener dentro del departamento TIC de una organización un entorno de preproducción.

En muchos casos, existe un entorno que se utiliza para probar aplicaciones, pero que dista mucho de ser considerado entorno de preproducción, ya que suelen tener las siguientes características:

– No se tiene seguridad al 100% que si un producto funciona en el entorno de pruebas funcione en el entorno de producción. Esto va a provocar que se produzcan casos donde una misma versión de una aplicación funcione correctamente en pruebas y no en el entorno de producción y al revés, es decir, que funcione en producción, pero que no funcione en pruebas.

– Además del problema de la falta de coherencia con el entorno de producción, se le suelen dedicar muy poco recursos hardware, esto hace que tampoco resulten muy significativas las pruebas de rendimiento que se realicen. Esto provoca además, que la realización de pruebas funcionales o pruebas de aceptación sean desesperantes, ya que suelen ser entornos con un mal tiempo de respuesta.

Es cierto que mejor tener un entorno así que nada (pero la diferencia entre eso y la nada no es mucho), pero no es conveniente conformarse con eso. La inversión en un entorno de preproducción es algo esencial, evitará muchísimos problemas y además posee un rápido retorno de la inversión.

Por tanto un entorno de preproducción resulta esencial en todo departamento TIC, por lo que no hay que mimar solo las infraestructuras de producción, debiéndose dotar de recursos hardware, software y humanos suficientes al entorno de preproducción para que sea coherente con el de producción, garantizándose que si el producto funciona correctamente en preproducción, además de cumplir los requisitos de seguridad, rendimiento, etc…, tendrá un comportamiento similar en el entorno de producción.

Es muy importante visitar a clientes y potenciales clientes. Que sepan que sigues existiendo aunque haga tiempo que no trabajas con ellos, que sepan que sigues evolucionando, ganando proyectos y consiguiendo casos de éxito.

Estas visitas tienen por regla general la característica de que en poco tiempo tienes que intentar que tu empresa se luzca, en aspectos que le resulten de interés al cliente (si no hay un orden del día marcado o una temática concreta hay que saber adaptarse o interpretar a lo que el interlocutor o interlocutores están interesados) y además sin parecer prepotente o pedante (casi mejor marcharte sin nada, que dejando al cliente o posible cliente con una mala sensación).

Un aspecto muy importante es intentar que la reunión sea para intentar cubrir una necesidad que no tiene cubierta el cliente, si vas por ejemplo a vender al cliente un sistema que resuelve una determinada problemática de negocio y el cliente ya tiene uno que resuelve dicha problemática y está contento, lo mejor es que te ahorres la visita. Por eso a veces es mejor, si se puede, conseguir una primera reunión sin más objetivo que conocer al posible cliente y a partir de ahí plantear una nueva reunión (si realmente interesa) sabiendo por donde se puede intentar conseguir algo.

Si el objetivo no es conseguir una venta a corto y medio plazo y lo que quieres es simplemente mantener el contacto con el cliente o el posible cliente, sí que se puede enfocar una reunión más generalista y de marketing.

Ser un buen comercial es muy complicado, supongo que como todo, habrá parte que lo dará el rodaje y el aprendizaje, pero creo que gran parte del éxito de un comercial viene de serie con él, es decir, se tiene esa cualidad o no se tiene, es cuestión de instinto. Por este motivo, porque los buenos comerciales no se fabrican en serie, están tan bien cotizados en el mercado.

Por regla general nos encontramos con que en muchas organizaciones existen procedimientos que se dictan como reglas generales y que después al no estar suficientemente detallados son interpretados de diferente forma en función de quien lo esté aplicando.

No tener homogeneizado un mismo procedimiento en toda la organización es tremendamente improductivo, además de no garantizar que ante una misma circunstancia todos actuén de la misma forma, lo cual provoca inseguridad jurídica si el procedimiento tiene repercusiones legales.

Si un procedimiento no está reglado en detalle y cada cual lo interpreta a su forma y además lleva mucho tiempo funcionando así, es tremendamente complicado plantear una solución homogénea si no es a través de una instrucción de la dirección de la organización. Por tanto, la homogeneización procedimental requiere sin duda el apoyo de la alta dirección de la organización, la cual debe ser consciente de que si quiere eficiencia debe tomar medidas para conseguirlo.

Además de la instrucción que describa con detalle cómo es el procedimiento y que obligue a hacerlo como se indica es necesario un proceso de gestión del cambio para que todos los implicados comprendan cómo se debe ejecutar el procedimiento y entiendan lo necesario e importante que era el proceso de homogeneización de procedimientos.

Hace poco un amigo me preguntó que si me sonaba eso que había escuchado por ahí y que se llamaba “Teoría de la decisión milticriterio discreta”. Le respondí de forma parecida a como me lo explicaron a mi, cuando lo escuché por primera vez:

“Imagínate que hay varias posibles soluciones u opciones entre las cuáles poder elegir, pues bien la teoría de la decisión multicriterio discreta sería algo así como abrir una hoja de cálculo, poner en cada fila las distintas posibles opciones, en cada columna distintos parámetros por los que valorar la opción y darle un valor a la opción para cada uno de esos parámetros, los cuáles no tienen por qué tener el mismo peso. Después sumas los resultados teniendo en cuenta el peso y la que tenga más puntos gana.”

Evidentemente a esta definición habría que aclararle muchas cosas, ya que la Teoría de la Decisión Multicriterio Discreta tiene una importante base teórica por detrás, pero básicamente el objetivo es ese, servir de instrumento para la toma de decisiones cuando hay más de una opción que elegir y hay más de un criterio que contrastar, es decir, tendremos varias opciones, hay que elegir una, hay diversos indicadores sobre los que valorar cada opción y en base la puntuación de los indicadores se escoge la mejor opción. En cierto modo es lo que solemos hacer los seres humanos cuando tenemos que tomar una decisión trascendente, ver los pros y contras de las diversas opciones y elegir la que creemos mejor.

El la teoría de la decisión multicriterio discreta, al tener una base teórica por detrás se tienen en cuenta más detalles, por ejemplo, si hay un criterio en el que las distintas opciones empatan o casi empatan, se podría tomar la decisión de anularlo o asignarle una ponderación inferior a la inicialmente asignada, lo mismo al revés, es decir, si hay un criterio donde las distintas opciones presentan valores dispares podría tomarse la decisión de incrementar su ponderación.

Asimismo, existen diversas técnicas para elegir la mejor opción en función de la valoración de los diversos criterios, como por ejemplo, en lugar de una suma ponderada, considerar como mejor opción aquella que gane en más criterios o utilizar mecanismos de selección más complejos como Electre y Promethee.