Reflexiones sobre el proceso de evaluación del rendimiento y desarrollo profesional como jefe de equipo

3 comentarios
Encaramos el final del primer trimestre. Por estas fechas todos habremos pasado ya por el llamado Proceso de Evaluación del Rendimiento y Desarrollo Profesional o similar. Seguro que, al leer esta última frase, la mayoría habéis esbozado una familiar mueca de desencanto y quizás hasta cinismo. Una sensación que comparto con vosotros. El caso es que no queria dejar pasar la ocasión de reflexionar en voz alta sobre este tema, desde mi posición de jefe de un equipo de desarrollo.

Qué está en mi mano y qué no

Logicamente, el objetivo principal de la persona que es evaluada es conseguir una subida de sueldo y/o de posición. Desgraciadamente yo poco puedo hacer aquí. Como jefe de un equipo de 2-5 personas dentro de una empresa con más de 1000 empleados no tengo ningún efecto real sobre este aspecto. Mis opciones se reducen a usar mi pequeña influencia sobre mi jefe, para destacar la labor de los más brillantes y confiar en que sus méritos sean tenidos en cuenta a la hora de repartir la bolsa. Este año dificil, si no imposible, por cierto.

Lo que sí está en mi mano es facilitar el resto de objetivos que todos deberiamos tener, saber qué he hecho bien, qué he hecho mal y cómo puedo mejorar. Y es en esta parte en lo que me centro.

Antes de la entrevista

Como cualquier tipo de encuentro o reunión, la entrevista debe ser preparada con suficiente antelación. Programando es fácil deshacer cualquier metedura de pata, pero en las relaciones con personas no es tan sencillo, sobretodo si una de las personas es jefe.

Así que redacto el informe-formulario del proceso con mimo, reflexionando sobre el evaluado, su año, preferencias y futuro. La parte de evaluación no tiene mucho secreto, una nota por cada objetivo fijado el año anterior, una nota global más un campo de texto libre. La parte de desarrollo profesional basicamente consiste en definir los objetivos para el próximo año.

Los objetivos deben ser personalizados. Si bien hay ciertos objetivos fijos como adquirir mayores conocimientos en la plataforma J2EE, se debe personalizar y especificar tecnologías concretas. Un objetivo que me gusta mucho es el de redactar un pequeño artículo técnico o leer un libro. Dejando siempre el título a libre elección pero proporcionando algunos ejemplos.

Sólo resta tomar unas notas sobre algunas cosas de las que quieres hablar durante la entrevista pero que no tienen porqué reflejarse en el informe. Luego pongo el informe a disposición del evaluado y cuando nos viene bien a los dos tenemos la entrevista.

La entrevista

Durante la entrevista intento buscar el diálogo y que no se quede en la simple lectura de un informe. Por eso empiezo pidiendo la opinión del entrevistado sobre el año general, lo mejor y lo peor. Si no se suelta le pido que le ponga una nota del 1 al 10 e intento ser más explicito preguntándole por algun proyecto o suceso concreto.

De aquí pasamos a la parte de evaluación. Para dar un toque gráfico, suelo pintar una gráfica formada por una recta creciente hacia la derecha que simboliza lo que yo esperaba de él y luego otra función más irregular que representa su rendimiento durante este año bajo mi punto de vista. Para comunicar sus puntos fuertes y débiles, uso la técnica del sandwich, empezando y terminando por cosas positivas y dejando lo menos positivo en medio.

En la parte de desarrollo profesional hablamos de sus objetivos para el próximo año y lo que espero de él como miembro de mi equipo. En caso de que tenga alguna petición concreta, la valoro y cambio el informe si procede (normalmente sí).

Un proceso continuo

Si el trabajo durante el año ha sido bueno, no debería haber ningún problema durante la entrevista y se convierte más en un trámite que otra cosa. Se aprovecha para dar ánimos y conocerse un poco mejor basicamente.

Si el trabajo ha sido malo y como superior has dejado que pase todo el año sin solucionarlo, va a ser bastante más duro... pero a mi aún no se me dió el caso :-)

Por eso abogo porque exista una comunicación continua entre el equipo. Por un lado a la hora de evaluar, se debe aplaudir el trabajo bien hecho, tanto el brillante ocasional como el cotidiano meticuloso. Y también criticar el trabajo de baja calidad y explicar cómo se podría mejorar. Si el tiempo no lo permite, tendrás que aceptarlo como esté pero deja clara la deficiencia.

El lado del desarrollo profesional se puede abordar con sesiones de programación por parejas, revisiones de código, coaching o simplemente sentándote con él para mostrarle alguna tecnología o herramienta que no estais usando pero que sería interesante.

Además la comunicación debe ser cúanto más pública y natural mejor. Es decir, usa el día a día, sin esconderte, no hace falta que sea en reuniones. A mi en realidad no me gusta hacer muchas reuniones de grupo. Solemos tener apenas una o dos por trimestre siempre justificadas. Y si la cosa no es grave prefiero hacer los tirones de oreja en ellas, delante de todo el mundo, eso sí, sin abusar. Si la cosa es más seria entonces sí, mi recomendación es hablar en privado y con el discurso muy preparado.

Tags: Buenas prácticas de uso de un sistema de control de versiones (ii)

1 comentarios
Este post es la segunda parte de aquel Buenas prácticas de uso de un sistema de control de versiones que publiqué en noviembre del año pasado. Está dedicado exclusivamente al uso de tags. Sé que prometí incluir branches y merge, pero habrá que dejarlo para otro día...

Antes de nada, lo primero sería definir qué es un tag en un sistema de control de versiones. Bien pues un tag es una marca que se asocia al estado de un proyecto en un determinado momento para poder acceder a él posteriormente. Por supuesto, los tags se pueden crear, listar y borrar.

La primera buena práctica sería... usa tags!. Es sorprendente la cantidad de gente que usa sistemas de control de versiones pero nunca ha usado tags. El uso de tags es la técnica más eficaz para volver atrás a un estado concreto del proyecto. Ya sea para hacer un checkout o para usarlo en comparaciones.

A continuación paso a exponer las que para mí, según mi experiencia y criterio, son buenas prácticas en el uso de tags:
  • Reutiliza el esquema de nomenclatura de versiones del proyecto para dar nombre a los tags. El esquema debe ordenar de forma incremental en el tiempo los nombres para facilitar la presentación del listado con todos los tags del proyecto.
    Así por ejemplo, yo utilizo el típico esquema X.Y.Z, donde X es el número de versión mayor, Y es versión menor y Z es versión de bug. Como CVS no soporta el carácter punto, utilizo el guión bajo como separador. Es decir, la versión v2.4.3 se traduce al tag v2_4_3.
  • Si no tienes un esquema, es el momento de crearlo. No uses la fecha como nombre para un tag. Mucho menos en formato ddmmaaaa, que no se ordena de forma incremental.
  • Asegúrate de que tienes la versión correcta del proyecto antes de crear un tag. ¿Han subido tus compañeros sus últimos cambios? ¿Te has hecho un update?
  • Crea un tag por cada release del proyecto que se produzca. Aunque sea una release interna. Esto te permitirá continuar desarrollando y aún así poder volver sin esfuerzo al estado del código de la release, por si necesitas corregir algún bug, realizar una pequeña mejora o simplemente realizar una entrega o distribución.
  • En general, crea un tag por cada suceso con implicación externa que ocurra en el proyecto. Como una entrega a un entorno de integración, el fin de un sprint, la realización de una demo, etc. Crear un tag es un momento, pero volver al estado de un proyecto un par de semanas después, deshaciendo los cambios a mano, es un infierno.
  • Recuerda que siempre puedes borrar los tags que dejen de tener sentido.
  • Crea un tag para marcar el inicio de un branch. Esto lo veremos más en detalle en la tercera parte.
  • Crea un tag para marcar la realización de un merge. Esto lo veremos más en detalle en la tercera parte.

Tip Eclipse: Generar metodos hashCode() y equals()

0 comentarios
Hoy toca un tip más sobre Eclipse de los varios que llevo ya en el blog. Se trata de cómo generar los métodos hashCode() y equals() de forma automática.

Abre la clase Java a la que quieras añadirle los métodos y desde el menú Source (Alt+May+S), selecciona la opción Generate hashCode() and equals() (h). Dentro de la pantalla podrás seleccionar los atributos que quieras que participen en la implementación, la localización dentro del fichero Java, si generar comentarios y si usar instanceOf para comprar los tipos.

El código generado es limpio y eficaz. La única pega que le veo es que en los bloques if de 1 línea no usa llaves. Afortunadamente ésto se ha corregido a partir de la versión 3.5 de Eclipse. Otra opción es usar la funcionalidad de realizar acciones al guardar ficheros Java en Eclipse.
También echo de menos poder elegir que use el método get correspondiente en lugar del atributo directamente, me viene a la memoria algún problemilla con Hibernate...

Participación en el podcast Servicios Web de javaHispano

1 comentarios
La semana pasada fue publicado el podcast sobre SOA y Servicios Web (SOAP/REST) de javaHispano en el que tuve el privilegio de participar junto a Leonardo de Seta, Alfredo Casado y Jorge Rubira, como conductor y productor del podcast.

La experiencia me encantó. En cuanto pasaron los típicos primeros minutos de nerviosismo escénico, me sentí muy cómodo y disfruté mucho charlando durante más de una hora con estos 3 fenómenos de nuestro sector.

El podcast dió para mucho, sin duda el tema lo merecía. Lejos del debate fanático SOAP vs REST que recorre internet, el mensaje que intentamos transmitir es que ambas son tecnologías perfectamente válidas para integrar sistemas, y más que enfrentarse vienen a cubrir un ámbito diferente cada una, con un amplio solapamiento entre ambas. La dificultad radica, por tanto, en saber elegir cúal se adapta mejor a una situación particular.

Por tanto, en realidad la problemática de la integración de sistemas no es sólo una cuestión sobre tecnología (implementación) sino que cobra mucha más importancia la pericia de las personas que deben analizar y diseñar inteligentemente los servicios que poblarán la SOA de una organización.

Realizar acciones al guardar en Eclipse

3 comentarios
Hoy en día todos estamos más que acostumbrados a que Eclipse compile nuestros ficheros Java cuando los guardamos. Pero ¿sabías que también puede realizar otras acciones?

La pantalla para configurar las acciones que realiza Eclipse al guardar ficheros Java está en Window -> Preferences -> Java -> Editor -> Save Actions.

Las acciones principales que puede realizar son formatear el código, de todo el fichero o sólo las líneas modificadas, y organizar los imports.

Pero además se pueden configurar otras acciones adicionales como:
  • Forzar el uso de bloques en sentencias if, while, for y do
  • Forzar el estilo de bucle Java 5, es decir for (Object elemento : myArray)
  • Añadir/Eliminar paréntesis en expresiones
  • Forzar el uso del modificador final en atributos, parámetros o variables locales
  • Forzar el uso de this
  • Controlar los cualificadores en los accesos estáticos
  • Eliminar código no usado
  • Eliminar castings innecesarios
  • Añadir anotaciones @Override y @Deprecated
  • Eliminar espacios en blanco innecesarios
  • Corregir indentación
  • Ordenar atributos y métodos

Generador de gifs de progreso en 3d

0 comentarios
No soy de subir posts para compartir links. Para eso prefiero usar delicius. Pero ya en el pasado hice un post sobre un generador de gifs de progreso y ahora he encontrado otro con unos modelos en 3d fantásticos.

Así que ya sin más, os presento a Preloaders, un generador online de gifs de carga con más de 35 modelos diferentes, 16 de ellos en 3d más opciones para seleccionar el tamaño, color y velocidad de animación. Espero que os guste.