La oportunidad de los becarios

La oportunidad de los becarios.

Se supone que los becarios se quedan a solas en verano: al frente del trabajo, ya que el resto de trabajadores (no becarios), han cogido todos vacaciones. Y claro, a los únicos que no les dejan coger vacaciones son a "los últimos en llegar".
Esto es un mito, y en cualquier cao no siempre es así. Los becarios exigen tiempo y esfuerzo para desarrollar sus capacidades, pero...¿realmente les estamos dando lo que necesitan para brillar?

La presión.

La presión suele ser el primer escollo. Siente que le vigilan, que le están evaluando de forma constante. El truco está en verlo como una motivación, una oportunidad.
Es una fuente de aprendizaje. La beca es así, y con ello, hemos de verlo en positivo. Salvo que estemos en una de esas empresas en las que los becarios se limitan a llevar cafés (por suerte, en mi empresa jamás he visto eso a un becario).
La presión hay que volverla en nuestro favor, que nos motive y nos dirija, no que nos bloquee y nos impida llegar a nuestros objetivos.
Otra forma de aliviar la presión es mediante  un tutor. En mi empresa existe la figura del counsellor, que viene a ser lo mismo. Y si bien es una gran idea, el problema viene dado cuando el tutor no se toma su trabajo en serio.

Cuando el tutor no dedica el necesario tiempo al becario.

El tutor no está para decir al becario lo que tiene que hacer. O al menos no de una forma paternalista. Debe guiar al becario impidiendo que cometa errores demasiado graves. Pero el aprendizaje incluye equivocarse. Cometer pequeños errores controlados. Aquí es donde el tutor entra en acción en su doble objetivo: que el becario aprenda, pero que la empresa no corra peligro.
La libertad del becario ha de ser proporcional a su responsabilidad: es decir, limitada. Pero no tan limitada que no pueda explorar su espacio y cometer esos pequeños errores controlados por su tutor.

Comportamientos a evitar

A continuación, revisamos algunos comportamientos a evitar por parte del becario:

• Individualismo. El excesivo individualismo, y el hambre de prosperar en la empresa, son explotadas por algunas empresas. Por desgracia, a medio y largo plazo los resultados suelen ser nefastos para la empresa. A veces, incluso a corto plazo.
• Impuntualidad. Aunque es complicado, es bueno combinar respeto y disciplina. Entrar a trabajar cinco minutos antes. Nunca después. Y nunca salir de trabajar antes de la hora, pero tampoco es necesario quedarse a trabajar  porque sí. Algún día revisaremos este punto en profundidad.
• Pereza. La pereza es terrible. El no empezar las tareas inmediatamente, el postergar lo importante por lo urgente.
• Problemático. Es una buena práctica el evitar problemas y confrontaciones. La energía generada en situaciones de conflicto está para ser utilizada a nuestro favor, no para embarcarse en disputas nimias que no van a resolver nada.
• Competitivo. La competitividad es buena, pero ha de ser una cualidad secundaria. No es bueno en general presentarse cada mañana pensando en "superar a éste" o "ser más que aquél". Sí es bueno marcarse metas, pero no es bueno dichas metas pasen por ser más que otros. Porque al final, el camino fácil se presenta: si no puedo ser mejor que los demás...quizás sea hora de hacer que los demás sean peor que yo (y aquí es donde la zancadilla fácil, el extender falsas afirmaciones, etc., hacen que el competitivo haga su agosto).
• Pelota. El pelota prefiere halagar en todo momento a sus superiores, o a cualquiera de quien pueda sacar provecho. Suele estar relacionado con un espíritu individualista y competitivo.
• Arrogancia. La arrogancia es uno de los peores males. A pesar de parecer menos agresiva que la competitividad o el individualismo, la arrogancia es difícil de erradicar. Está basada en una creencia profunda en las propias capacidades, y por desgracia, no suele estar alineada con la realidad. Cuántos recién titulados me he encontrado que se creían los reyes del mundo, dueños de la absoluta verdad, e incapaces de dialogar y llegar al mínimo consenso. Su título universitario les convierte en Dioses, o ellos así lo creen. Y por desgracia, yo hace muchos años que aprendí que mi título no está para esgrimirlo en absurdas disputas. El título está para dar soporte a la curiosidad, al esfuerzo, y a la capacidad de ir más allá de las apariencias. Capacidad de aprender, porque más que nos pese, no llegamos el primer día de trabajo con  todo aprendido.

Comportamientos a seguir.

• Aprender
• Jugar en equipo.
• Respeto.
• Atrevimiento.
• Planificación.
• Organización.
• Socialización: conseguir contactos y establecer relaciones.
• Disfrutar.

Sí: disfrutar. Disfruta, suéltate y siéntete cómodo. Que no parezca que estés ahí cada día por un sueldo miserable. Madruga. Llega pronto. Haz las cosas con ilusión. Contagia esa ilusión. Yo personalmente prefiero a gente ilusionada, antes que a un crack, al típico fenómeno tecnológico en cualquier tema pero que lo hace con desgana. Y la desgana se contagia. Y esa desgana se ve en la documentación, en el código...

Y tú, ¿cómo prefieres llevar tu beca?

Fuente: este artículo está inspirado en un artículo que leí hace un tiempo en el periódico dominical de La Vanguardia.

El necesario estrés

Hablando el otro día con un compañero de trabajo, me contaba una interesante metáfora.

Había un pescador que pescaba atunes, pero los tiburones diezmaron la pesca. Y para evitar arruinarse, tuvo una gran idea. Decidió crear una piscifactoría, criar los atunes en cautividad, y venderlos para así obtener grandes beneficios. Pronto se dio cuenta de que los atunes no se vendían tanto como él pensaba. El motivo era que tenían demasiada grasa. En cautividad, los atunes se criaban gordos, y no tenían un incentivo que les hiciese hacer ejercicio.

Recordando cómo era la pesca en el mar, pensó que los atunes libres se crian con un sabor perfecto, y hacen mucho ejercicio porque deben sobrevivir. Así que decidió traer un tiburón y soltarlo en la piscifactoría. Pronto, los atunes ganaron en calidad, mejoraron su sabor, y se criaron más sanos y produciendo unas mejores ventas. Incluso considerando las pérdidas producidas por el ataque del tiburón, merecía la pena.

Al final, el motivo era la introducción de un nivel de estrés pequeño, pero suficiente para que los atunes se vieran en la necesidad de sobrevivir, criarse ágiles y sanos.

Al final, la moraleja que comentaba con este compañero es clara: un poco de estrés es bueno. Sin un incentivo, sin la adecuada presión...la gente se relaja. Y demasiada relajación, no nos lleva a los éxitos, ni provoca que la gente se estimule en mejorar su código, su planificación, sus pruebas...

Al final, PON UN POCO DE ESTRES EN TU VIDA. ¿Pero sin pasarse, eh?

Deloitte University

Pues ya hemos vuelto de Texas, y en realidad a pesar de mi entrada anterior, la Deloitte University estaba más propiamente en WestLake, no en Dallas. De hecho, estábamos tan al norte, que el famoso desastre de los tornados en Oklahoma nos afectó y bastante. Pero bueno, eso ya es otra anécdota.

Sobre el evento, he de comentar varias cosas:

• Formación. El enorme esfuerzo que se hace en las compañías americanas en formación. En este lugar privilegiado no sólo había directores, gerentes y responsables en general (por algo le llaman el Leadership Learning Center), sino que cantidades ingentes de nuevos y jóvenes empleados (auténticos yogurines de apenas 20 o 23 años), llegaban a cientos a este centro formativo.
• Lujo, belleza y tecnología. Los mejores materiales, un cuidado diseño que hace pensar que estamos en un hotel de cinco estrellas en lugar de un centro formativo, eso sin olvidar que hay un cyber-center donde cualquier cosa que necesitemos, está a nuestra disposición para comprar: iPhones, iPads, portátiles, otros móviles, adaptadores, cables, etc, etc. Wi-fi gratis en todo el complejo, incluyendo la conexión inmediata de los empleados al usar sus portátiles o móviles de empresa.
• Gourmet ¿Alguien tiene hambre? Es difícil salir de este centro formativo sin unos kilos de más. Salas repletas de comida de todo tipo se reparte por las 5 plantas del complejo de habitaciones. Pensado para los que no tienen tiempo para bajar, o simplemente quieren picar algo sin alejarse de la habitación. Después, los restaurantes con buffet o los múltiples espacios para picar habilitados junto a las salas de formación, hacen que el día se pase sin sentir (salvo en el estómago!).
• En forma. Para compensar lo anterior, existe un gimnasio gigantesco: DTFit. En este lugar podemos encontrar desde decenas y decenas de máquinas de todo tipo, gran cantidad de actividades diarias programadas para que nadie tenga que aburrirse por su cuenta, hasta un exterior de varias hectáreas de terreno verde con árboles y muy cuidado para facilitar el running. Doy fe: no es extraño ver a la gente corriendo por las distintas pistas, especialmente a primera hora de la mañana o por la tarde.
• Relax. Un exterior cuidado, con árboles, pistas verdes, zonas ajardinadas con iluminación nocturna, un lago con aves, tortugas, peces...
• Sostenido. Un equipo de alrededor de 200 personas cuidan y mantienen el complejo: seguridad, camareros, cocineros, jardineros, mantenimiento, dependientes, limpieza, etc.

Así que tras este ajetreo, me pongo a pensar en lo importante que es la formación, y lo importante que es cuidar a los empleados. La mentalidad de que para rendir como los mejores, hay que invertir en nuestros empleados dándoles lo mejor, puede ser chocante. Pero no debería ser así, ¿verdad?

El síndrome de Estocolmo

Podemos encontrar en Wikipedia la definición de este tipo de desorden:

Wikipedia: El síndrome de Estocolmo es una reacción psicológica en la cual la víctima de un secuestro, o una persona retenida contra su voluntad, desarrolla una relación de complicidad, y de un fuerte vínculo afectivo, con quien la ha secuestrado. Se debe, principalmente, a que malinterpretan la ausencia de violencia contra su persona como un acto de humanidad por parte del secuestrador.

Esta definición, que nos parece tan fuera de nuestro ámbito de empresas de desarrollo de software, ocurren en nuestra industria mucho más de lo que creemos.

 

El equipo de desarrollo con el Jefe de Proyecto.

Cuántas veces hemos oído a los programadores o analistas excusar al jefe de proyecto que gestionó algún conocido desarrollo o implantación.

Por desgracia, cuanto mayor es el sobre-esfuerzo, cuanto mayores y más largas son las semanas o meses de brutal agotamiento, mayor es el síndrome de Estocolmo. Se llega a oír cómo las más peregrinas excusas surgen de los labios de quienes han sufrido de primera mano las malas decisiones, la pésima gestión (o la total carencia de la misma) de ese jefe de proyecto.

Es normal que aceptemos las imperfecciones de la gente, es correcto. Pero ya no es normal olvidarnos de las responsabilidades y trasladarlas a otros, como si un jefe de proyecto fuera una imagen de un mártir, un inocente de las circunstancias.

El programador con el Analista/Arquitecto.

Tampoco es extraño oír cómo el equipo defiende a su analista responsable, al arquitecto que definió la estructura, a quien pensó (con tan mala fortuna) las pantallas...

Pues sí, el síndrome de Estocolmo también aplica a los perfiles técnicos altos, pues tantas horas con ellos, tantas excusas ofrecidas, acaban por minar la resistencia moral. Después de todo, están con nosotros en las largas semanas (días y noches incluidos) que necesitamos para hacer funcionar sus incompetentes diseños y sus incongruentemente desorganizadas y sobrecargadas arquitecturas.

El programador con el cliente.

No nos engañemos. También podemos sufrir este síndrome con un programador. Si se trabaja mucho tiempo en las oficinas del cliente, llega a establecerse un vínculo entre el equipo de desarrollo y el cliente. Sin embargo, al pasar el tiempo y si el equipo de desarrollo sigue trabajando en las oficinas del cliente, este equipo pierde su vínculo con su propia empresa.

En este tipo de situaciones, nos encontramos con casos en que los desarrolladores obedecen al cliente, aún en situaciones en que saben que están desobedeciendo o contradiciendo las órdenes recibidas de su jefe de proyecto.

Ocurre en desarrollos, pero también en mantenimientos. En un mantenimiento, es típico ver cómo un programador sale corriendo a resolver una incidencia sin esperar a que sea notificado su registro, sin esperar a que sea revisada, escalada, etc. En estos casos, el equipo de desarrollo se preocupa solamente de contentar al cliente, y acaba trabajando como si formara parte del equipo del propio cliente.

En estos casos, llega a perderse el control de lo que se trabaja. El equipo de mantenimiento está muy ocupado, pero sus responsables no son conscientes de ello. Se registran menos incidencias de las que realmente se resuelven...incluso de llevan a cabo evolutivos a escondidas que con suerte se quedan como simples correctivos.

¿Y tú? ¿Has observado también en algún proyecto el Síndrome de Estocolomo?

Certificaciones Profesionales

Esta entrada la he creado a raíz de un comentario que he recibido en otra entrada anterior. Allí, un lector me preguntaba sobre las certificaciones de software. En concreto, me preguntaba además por la certificación ISQTB.

Un excelente estudio sobre las distintas certificaciones y su utilidad o necesidad, puede encontrarse en este post del blog de Javier Garzás.

He de decir que aunque este estudio me ha parecido un buen trabajo, los resultados desde mi punto de vista se desmerecen porque faltan datos. Es una buena idea tratar de obtener tendencias, pero con tan sólo dos valores es muy complejo tratar de analizar la verdadera situación del mercado en cuanto a estas certificaciones. Animo al autor a continuar con el estudio para ver la evolución de esas certificaciones a largo plazo.

Hay que considerar, que las certificaciones son muy específicas del perfil o rol del profesional. Por ejemplo, no son significativas las certificaciones en gestión para un tester o programador, lo mismo que la certificación ISQTB puede aportar escaso valor a un jefe de proyecto. Es por eso que las certificaciones están asociadas a los roles:

• Gestión (PMP, CAMP, ITIL,...)
• Auditoría (CISA, SCAMPI Lead Appraiser...)
• Seguridad (CISM...)
• Pruebas (TMAP, ISQTB...)
• Análisis (CPRE,...)
• Desarrollo

Otro punto a destacar es que las certificaciones no siempre terminan de cuajar. Por muy bueno que sea el nivel exigido, es más importante el prestigio o grado de aceptación en el mercado (número de empresas que los solicitan). Por desgracia, hay acreditaciones muy buenas como TMAP que no terminan de cuajar en su ámbito.

Esto me recuerda al típico problema del mercado: VHS vs BETAMAX; HD DVD vs BlueRay... y así unos cuantos. Al final, es posible que te gastes un dinero en una certificación, y que luego ésta no termine de tener el prestigio de otra cualquiera. Y se trata de una importante inversión en tiempo y dinero.

Hay otra consideración, y es que las certificaciones o bien "caducan", o bien son reemplazadas por otras versiones que las convierten en obsoletas. Es el caso de CMM, que se vio reemplazado por CMMi.

Para terminar de complicar la cosa, en algunos países se crean certificaciones o acreditaciones profesionales de ámbito local (como es el caso de CFCP en Mexico). Eso dificulta la decisión de las personas, que se encuentran entre la duda de certificarse en una cosa u otra. Además, las certificaciones que se presentan al mercado, no suelen cubrir de forma unívoca una acreditación existente, sino que suelen añadir o eliminar elementos de forma que una, no cubre el 100% de otra. Esto no quiere decir que las certificaciones estén mal pensadas o diseñadas, no quiero decir eso. Simplemente, no todas tienen el mismo marco de referencia (áreas de conocimiento o experiencia acreditadas), no tienen el mismo alcance (nacional, internacional), y tampoco tienen el mismo prestigio. Hasta aquí, ya tenemos 3 dimensiones a considerar.

Si a todo esto, añadimos lo que Javier Garzás trataba de identificar en su estudio (la evolución del prestigio o necesidad del mercado de esas acreditaciones a lo largo del tiempo), vemos que la decisión es complicada: ¡4 dimensiones!

• Ámbito
• Alcance
• Prestigio
• Evolución temporal

En concreto, y ya terminando de responder a mi lector en su comentario, diré que la ISQTB me parece una excelente certificación. Yo personalmente la veo solicitada en múltiples ofertas, y particularmente creo necesario que la gente dedicada al testing, tenga una formación específica. No por programar mejor o peor, se tienen porqué adquirir los skills relacionados con las pruebas. La de TMAP, apenas la veo en ofertas a día de hoy, por ejemplo (y quizás es tan exigente o más que la de ISQTB, lo ignoro).

En una entrada anterior ("¿Hace falta que un tester sepa programar?"), comentaba esto mismo.

Además, hemos de notar que nuestro lector se identifica como "Senior QA", de lo que deduzco que tiene experiencia más que suficiente en el ámbito de las pruebas. ¿Qué valor le puede aportar tener una acreditación en esa área para la que ya tiene experiencia? ¿Le aportaría más valor otra acreditación relacionada con el siguiente escalón en su carrera profesional? Este es otro punto a valorar, ya que me suelo encontrar con situaciones en las que tengo dos tipos de profesionales:

• Amplísima experiencia, pero ninguna acreditación concreta para el área profesional.
• Una o varias acreditaciones / certificaciones, pero escasa experiencia.

¿A quién contratarían ustedes? ¿En quién confiarían más? En concreto la ISQTB me parece estupenda, pero un señor con 3 o 4 años de experiencia en pruebas usando prestigiosas herramientas como HP Quality Center o cualquier otra marca, me merece también muchísima confianza (¿quizá más?).

Por hoy, creo que hemos dado suficientes vueltas a un tema, que veo que tiene muchas ramificaciones. Ya seguiremos otro día.

Orgulloso de tus éxitos, no de tus contactos.

Hoy estaba leyendo este artículo en el blog de HBR (Harvard Business Review).

Casualmente, este artículo está en la línea de un tema que ya estuve comentando recientemente en otro post: y es que hay que estar orgullosos y por tanto poner en nuestro currículum, los éxitos profesionales, no tanto nuestras afiliaciones a marcas conocidas o de prestigio.

Por ejemplo: hablar o hacer publicidad de ser empleado de IBM o tener relación con esa empresa, no es un éxito como tal. Es usar una afiliación o relación profesional con una marca conocida. Está bien tratar de vincular nuestra labor profesional con un gran número de marcas de prestigio, o de sentirse orgulloso de ello, pero eso no puede estar por delante de nuestros éxitos. Si no tenemos éxitos profesionales de los que hablar…mal asunto.

Y no me refiero a que no podamos mostrar orgullo en público o jactarnos de nuestra relación con una marca, empresa o institución prestigiosa. Eso está bien. Pero parece ser que se tiende a hablar más de ello que de los éxitos y logros.

Yo no quiero en mi equipo de trabajo a una persona que haya trabajado en megaproyectos o que haya estado vinculado por el motivo que sea a grandes empresas, marcas de prestigio, etc. Yo quiero gente que haya superado retos, que haya enfrentado grandes problemas, y que pueda demostrar su éxito ante tales situaciones (su éxito, o al menos que haya podido salir airoso gracias a sus habilidades profesionales). A veces un pequeño éxito (o ausencia de fracaso) ante los problemas grandes, es mejor que un gran éxito ante un problema pequeño. Y quiero explícitamente saber si lo hizo solo o en colaboración con otras personas. No me valen los que tratan de venderme que fueron los responsables de tal o cual proyecto, cuando quizás la acción la realizaron él y otras 20 personas.

Como comentaba en mi anterior post, es esta ocultación deliberada de información la que provoca que al final todo el mundo sea el líder, héroe y único responsable de llevar a cabo grandes hitos en desarrollo, pruebas, implantación, gestión de equipos, etc.