Definición gráfica de ininteligible

Retrospectiva

Pues sí. Así como el que no quiere la cosa, resulta que el blog cumple un año. Y como siempre me han gustado mucho los números y las estadísticas, he decidido hacer un post a modo de resumen de estos primeros 356 días de vida.

Los primeros datos tienen que ver con el número de posts. En total han sido 63 las entradas que he publicado, lo que hace una media de 5,25 por mes. Mi época más prolífica llegó en septiembre de 2010, con diez entradas, justo después del mes de menor actividad, que fue agosto, con una. Algo normal por aquello de que en agosto uno está para casi cualquier cosa, menos para producir, y porque precisamente eso hace que a la vuelta de vacaciones las pilas estén cargadas y la mente repleta de ideas y proyectos.

Evaluando estas cifras, me sorprende gratamente ver que he alcanzado con creces el objetivo que me he planteado todo este tiempo, que era mantener una cadencia de un post semanal. Así que en este sentido espero mantenerme, si bien el objetivo pasa a ser ahora conseguir un ritmo más regular (la diferencia de uno a diez posts en un solo mes es demasiada).

En cuanto a los temas tratados, este es el top-nine de etiquetas utilizadas:

utilidades (11)

Oracle (8)

tutorial (6)

Java (5)

jDeveloper (5)

SQL (5)

ADF (4)

Android (4)

Chrome (4)

Resulta que de lo que más he hablado es de mi experiencia con utilidades software. Algo que no estaba en un principio entre mis ideas para el blog, pero que considero que se ajusta a su temática, por lo que lo doy por bueno. Al fin y al cabo son entradas que también tratan problemas informáticos, aunque a nivel de usuario, lo que democratiza el blog. Por detrás están Oracle, lógico dado que trabajo mucho con sus productos, y tutorial. Esta etiqueta marca uno de los grandes obejtivos que me gustaría cumplir de aquí en adelante: orientarme a la creación de documentación técnica. Algo que veo complicado, ya que requiere mucho tiempo, pero quizá sea cuestión de perseguir objetivos menos ambiciosos, y hacer tutoriales menos exhaustivos. Trabajaremos en ello.

El resto, son las tecnologías con las que más he trabajado en los últimos tiempos, luego ocupan la posición que les corresponde.

¿Y qué hay de los usuarios? En este sentido no me había planteado objetivos, más que nada porque no tenía idea de por dónde podrían andar los tiros, pero lógicamente es algo muy importante; ya que uno dedica su tiempo a escribir algo, agrada que alguien lo lea. Tras un año, el blog ha recibido un total de 5400 visitas, estabilizándose en los últimos seis meses en torno a las 650 visitas mensuales, y a las 25 diarias (con grandes bajadas en fines de semana). El máximo mensual lo alcancé justamente el último mes, marzo de 2011, con 907 visitas. Lógicamente el público hispano es el que se impone por la barrera del lenguaje. Estas son las visitas por países.

España (2.045)

México (810)

Colombia (455)

Argentina (366)

Perú (311)

Chile (246)

Estados Unidos (214)

Ecuador (137)

Venezuela (93)

Bolivia (5)

Si pasamos ahora al top-ten de páginas vistas, el resultado es el siguiente:

Incluir librerías en el jar con netbeans (866)

iReport - java.lang.NoClassDefFoundError (597)

No puedo borrar el texto seleccionado en Word (356)

Cómo forzar el salto de línea (wrap) en un jLabel (221)

Fijar una vista para todas las carpetas en Windows XP (218)

Comillas en cadenas Oracle - Operador q (192)

Conectar a SQL Server desde SQLDeveloper (108)

Tutorial de Pentaho: definición de un proceso ETL usando Spoon (85)

Configurar barras de progreso en Android (79)

Error adquiriendo fuentes de datos en jDeveloper 11 (69)

El líder destacado es el post en el que explicaba cómo generar ficheros jar en NetBeans que incluyesen las librerías del proyecto. Hay que destacar que se cuelan en las primeras posiciones dos posts orientados a usuarios no técnicos, y un único tutorial. Claro que hay que tener en cuenta la antigüedad de las entradas. La única de 2011 que aparece entre las más visitadas es la que cuenta cómo configurar barras de progreso en Android.

Una conclusión clara (que era predecible) de esta información, es que los post más visitados tienen un marcado carácter técnico, y en su mayoría se reducen a explicar cómo hacer algo. Esto me alegra, puesto que la razón de ser del blog era precisamente la de dar solución a problemas informáticos (de ahí su nombre), y está visto que es ahí donde más interés consigue atraer. Entre otras cosas, y con esto enlazo con el siguiente tema, porque el punto de acceso es, casi únicamente, Google.

Y es que un blog como este tiene difícil la fidelización del lector. Dejando de lado amigos y familiares, pocas personas pueden tener interés en el blog de forma global. La mayoría (un 86% en el último mes), accede a través de motores de búsqueda, y pocas veces alguien que ha entrado buscando información sobre Android se parará a leer también un post que habla sobre Pentaho, y menos aún mis opiniones sobre nuestra maravillosa profesión.

¿Y qué busca una persona para llegar hasta aquí? Pues habiendo visto los posts más visitados, estos datos aportan poca información, pero ahí van algunos ejemplos.

java.lang.noclassdeffounderror: org/codehaus/groovy/control/CompilationFailedException

incluir librerías en jar

no puedo borrar en word

decompilar jasper

km software

4f530e43505002ef

barra de progreso android

El último aspecto que me parece interesante analizar son los comentarios. Si para el autor de un blog es gratificante tener visitas, lo es aún más que éstas participen y den feedback. En todo un año, sólo hay registrados 21 comentarios, y 9 de ellos son respuestas mías. Puede que uno de los motivos de tan poca participación sea la necesidad de logarse para comentar, así que me plantearé probar a eliminar esta restricción temporalmente, y mantenerla si el spam no fastidia mucho. En cualquier caso, aprovecho este post (que atendiendo a los datos, será un grito al viento porque poca gente lo leerá), para pedir a los lectores que comenten. Se aceptan críticas y sugerencias, por supuesto; y si es manteniendo el buen rollo, mejor.

Encuestas

Los departamentos de informática, aunque a veces no nos demos cuenta, nacen con una evidente y destacada vocación de servicio al usuario. Nosotros no somos el fin, sino el medio. Una herramienta que la empresa, sea cual sea su área de negocio (administración, salud, energía, investigación, docencia...), pone a disposición de sus empleados para facilitar la consecución de sus objetivos.

Muchas veces los departamentos de informática nos perdemos en nuestras pequeñas guerras tecnológicas, y nos olvidamos de que nuestra finalidad principal es facilitar el trabajo de los usuarios. Esto puede llevarnos a perder el rumbo y a provocar en ellos una perjudicial sensación de insatisfacción con nuestros servicios.

Me refiero a que es habitual encontrar a todo un equipo centrado en implantar un maravilloso entorno de desarrollo, con un servidor de integración continua, herramientas de control de código, fastuosos servidores de aplicaciones y demás parafernalia, mientras un usuario lleva varios días esperando que se le cree una cuenta de correo electrónico, que es lo único que necesita para trabajar.

Como proveedores de servicios informáticos es nuestro deber adecuarnos a las necesidades de los usuarios y hacer todo lo posible por satisfacerlas, ya que ese es el verdadero indicador que nos dirá cómo estamos haciendo nuestro trabajo.

Y no existe mejor forma de saber hasta qué punto está satisfecho el usuario que preguntarle a él mismo. Ahí es donde las encuestas pueden ser útiles para nosotros.

Recoger información de un grupo de personas es una tarea muy difícil. Si uno se pone manos a la obra se encontrará con gente para la que nunca es un buen momento, gente que prefiere no opinar, gente que responde cualquier cosa para cumplir, gente que piensa que dar su opinión es una tontería... el caso es que al final obtener la información lleva lo suyo, así que es muy importante hacer las cosas bien para conseguir resultados útiles.

Así que hay una serie de claves que se deben tener en cuenta para tener éxito con los sondeos a usuarios.

Lo primero, y más importante: ¿Qué quiero saber? Esta es la clave y, posiblemente, el punto en el que debamos detenernos más tiempo. Aunque suene redundante, tenemos que saber qué queremos saber. Y tenemos que saberlo de forma concreta, claro. No vale con decir que quiero saber qué es lo que el usuario piensa de mi trabajo; hay que ser más concretos, ¿qué aspectos de mi trabajo quiero que se valoren? Pongamos un ejemplo.

- Quiero saber si mis usuarios están satisfechos con el tiempo de respuesta a sus peticiones.

- Quiero saber si mis usuarios están satisfechos con la calidad de las respuestas.

- Quiero saber si mis usuarios están satisfechos con el trato ofrecido por mi equipo.

- Quiero saber si mis usuarios están satisfechos con las herramienta puesta a su disposición para notificar incidencias.

- Etcétera, etcétera.

Tan importante como identificar qué quiero saber es reconocer qué no me interesa, para ajustar lo máximo el tiro. Si estoy valorando la posibilidad de cambiar mi gestor de incidencias por una herramienta más barata, pero que elimina alguna funcionalidad, como por ejemplo la notificación por correo, en lugar de la última línea lo adecuado sería preguntar: ¿sigue usted las notificaciones por correo electrónico de sus incidencias? ¿echaría de menos esta funcionalidad? Quizá nos sorprendamos al ver que la mayoría de los usuarios tienen marcados como spam lo correos del gestor de incidencias.

Lo siguiente es tener claro que al usuario hay que ponérselo fácil. Olvidémonos por supuesto de pasarnos a hablar cara a cara con cada uno de ellos, o de pasarles un cuestionario en papel. Al día siguiente todos estarían perdidos entre montañas de formularios. Hoy las encuestas online son la mejor opción. Colguémosla, demos acceso sin contraseña, y dejémosla ahí durante un periodo de tiempo suficientemente grande. Y, por supuesto, promocionémosla; empujemos a la gente a perder 5 minutos de su tiempo. Seamos pesados si es necesario, ya que este tipo de peticiones suele caer en saco roto la primera vez. Y si todo esto falla, sorteemos un iPad entre los participantes. Nada mejor para que te hagan caso.

Y por último, e importántisimo también, esa gran palabra, el feedback. Demos feedback. Ya que los usuarios han perdido un rato en satisfacernos, dejémosles conocer los resultados, comentemos las conclusiones, y hagamos públicas las actuaciones aprobadas. Todo dentro de plazos razonables. Es muy probable que el ver que sus opiniones han significado cambios percibibles les impulse a participar en próximas ocasiones.

Y ahora, digan, ¿les ha parecido interesante el post? ;)

Identidad corporativa

Una manzana mordida.

Una taza de café humeante.

Un caballo encabritado.

Una bandera de cuatro colores.

¿¿Te dicen algo??

¿¿Y ahora??

Seguro que has tardado poco en identificar cada uno de estos objetos con la marca a la que representan, claro.

Esto se debe a que todas las grandes empresas, y buena parte de las pequeñas, tienen bien definida su identidad corporativa. Básicamente la identidad corporativa es el conjunto de imágenes, tipos de letras, colores, etc., que una empresa utiliza y la hace reconocible frente a cualquier otra.

El elemento central suele ser el logotipo, pero no se reduce unicamente a eso. Un manual de identidad corporativa incluye también los tipos de letra, tamaños, colores, distribución de información, y todo lo que se te pueda ocurrir, que se debe utilizar para cualquier comunicación que provenga de la empresa.

¿Y todo esto para qué? Pues para obtener reconocimiento. Lo que consigue la empresa es que se le identifique rápidamente; que cuando veas un deportivo rojo pasar a 200 por hora y atisbes un caballo en su frontal digas: pedazo de ferrari. O que cuando estés trabajando con un programa y veas una tacita de café sepas: basado en tecnología Java. O, por qué no, que cuando veas una pantalla de ordenador con fondo azul y letras blancas pienses: estos de Windows...

Porque lograr una identidad corporativa es lo que tiene. Que te puede reportar beneficios o pérdidas, pero eso ya depende de lo bien que hagas las cosas. El primer paso está dado, y es que todo el que vea tu producto sepa que es tuyo.

El único beneficio que se obtiene de la identidad corporativa en sí misma tiene que ver lógicamente con la imagen. Orden, coherencia, pulcritud, son algunos de los mensajes que se envían. Y es por eso que he decidido implantar poco a poco mi propio manual de identidad, en este caso personal.

El primer paso lo doy en el campo que considero más importante y sobre el que tengo mayor control, que es la documentación que genero, principalmente tutoriales. Así que he creado una plantilla y he definido unas líneas a seguir que espero le den un toque personal (y profesional) a mis documentos.

Si el tiempo lo permite, y supero mis limitaciones en lo que se refiere al diseño, puede que los próximos pasos sean el logo y el formato del propio blog.

Este año termino la carrera

Esta es una frase que todo universitario pronuncia al menos una vez en su vida. Lo malo es que algunos se acostumbran a ella, le toman cariño, y dejan que le acompañe durante lustros. Algo que no tiene mucho sentido.

Está claro que uno no puede darle máxima validez a una frase como esa cuando viene de una persona con la edad habitual de los universitarios (entiéndase entre 18 y 23, aunque quizá lo habitual sea entre 20 y 30). En esa época de nuestra vida todos tenemos un ego super-desarrollado que nos impedirá asumir con modestia que al final necesitaremos una pequeña prórroga para terminar nuestros estudios.

En cualquier caso, una persona que emite esta frase durante un periodo superior a 9 meses demuestra una serie de cosas.

1 - Que tiene un escaso conocimiento de sus capacidades.

2 - Que no es consciente de sus circunstancias, y de como éstas afectan a su desempeño.

3 - Que no tiene la menor capacidad para "planificar".

Porque un tío que tras 5 años de carrera tiene por aprobar el 20% de los créditos, correspondientes precisamente a las asignaturas más duras, que afirma que va a terminar en un año más, no tiene ni idea de lo que está diciendo. Y más si resulta que esa misma persona ha decidido que, como ya le queda "poco" para terminar, puede asumir un trabajo a tiempo parcial para ir sacándose unos ahorrillos.

En estas circunstancias, cualquier persona que no cumpla los 3 puntos anteriores dirá que, en condiciones normales, este individuo necesitará al menos dos años más para terminar sus estudios.

Pero bueno, ¿¿y esto no es un pedazo de off-topic??

Pues no. Resulta que esos individuos de los que estoy hablando, transcurrido ese "último año", pasarán a formar parte de la plantilla de alguna empresa, y asumirán determinadas responsabilidades. Y entonces es cuando llegarán, como hemos hecho todos, como becarios en sus primeros días de trabajo, y ante la pregunta de su jefe, ¿cuánto crees que tardarás en hacer esto?, responderán sin cortarse un pelo: "dame un par de días". Y seis meses después, cuando su contrato-basura esté a punto de expirar, irán ilusionados a comunicar: "ya lo tengo!".

Es algo lógico, dado el ímpetu y la ilusión con que todos empezamos nuestra vida laboral; y sobre todo dado el desconocimiento que tenemos de la realidad de ese mundo. Dicho de otra forma, dada nuestra nula capacidad para Planificar.

Porque la tarea de planificar es ciertamente compleja. Casi me atrevería a decir que está al límite de lo imposible. Y es que cuando uno se enfrenta a la necesidad de predecir cuánto tiempo va a requerir para hacer algo tiene que controlar innumerables variables:

- ¿Qué es lo que tengo que hacer?

- No, en serio, ¿qué es lo que tengo que hacer? Quiero decir, ¿soy realmente consciente de ello? No basta con decir: tengo que hacer una aplicación Web para la gestión de usuarios de mi empresa. Hay que saber qué implica eso. ¿Montar un entorno de trabajo? ¿Seleccionar herramientas y frameworks de desarrollo? ¿Instalarlas? ¿Definir la funcionalidad? ¿Diseñar una base de datos? ¿Comunicar sistemas? ¿Hacer pruebas? ¿Documentar? ¿Reunirse con los usuarios? ¿Corregir errores?... y así hasta el infinito.

- ¿De qué recursos dispongo?

- ¿Cuáles son sus capacidades?

- ¿Coincidira mi desarrollo con la redacción de alguna oferta que entretenga al equipo?

- ¿Se irá la luz durante los trabajos? ¿cuántas veces? ¿qué cantidad del trabajo perderemos?

- ...

Y, en función de todo ello, la gran pregunta, ¿cuánto tardaré en hacerlo?.

No, en serio, ¿cuánto tardaré en hacerlo? Porque uno puede decir que en instalar un IDE se tardan 5 minutos. Pero se puede encontrar que la versión que necesita no es compatible con el driver del sistema, y necesitar una semana para enterarse de que tenía que cambiar una coma en un fichero de configuración para que todo funcione.

Al final la solución estándar es simple. Se coge el tiempo que se necesitó la última vez para hacer la tarea, t (si nunca se ha hecho, se estima con una función de relación directa al tamaño del nombre de la tarea), se multiplica por dos, y se le suman un par de semanas para documentar, d. Resultado: P = 2t + d.

¿Y qué pasa? Pues que nos encontramos con que al final g (el tiempo efectivamente empleado en el proyecto) se va acercando peligrosamente a P, hasta rebasarlo sin remedio y acabar doblándolo.

Menos mal que somos gente preparada para planificar, y conocemos las técnicas heurísticas. La próxima vez modificaremos el factor de corrección a 4, y todo resuelto.