lunes, 13 de diciembre de 2010

El CV y el siglo XXI


Buenos días!

El 1990 Peter Senge ya hablaba de organizaciones inteligentes (aquí); más recientemente Stephen Covey del 'Knowledge Worker' (aquí) y nuestro querido Juan Carlos Cubeiro del post-taylorismo (aquí y aquí), por citar solo a mis preferidos. El mundo está cambiando y las relaciones laborales con él. Las eminencias citadas hablan de una nueva empresa, la del siglo XXI, de una nueva relación entre trabajadores con el objetivo de mejorar en rendimiento de la empresa utilizando TODOS los talentos del equipo al máximo. En este marco, ¿todavía tiene sentido el CV?

El cambio en las relaciones laborales del que hablamos se produce en el seno de la empresa, pero se ha de extender hasta la contratación, el inicio de la relación, y por tanto las entrevistas de trabajo en las que el entrevistador «examina» (en el peor de los sentidos de la palabra) al candidato pertenece a un marco de relación laboral obsoleto.

El CV es un instrumento más de esta relación, lo importante es cómo se usa. Si se usa para eliminar candidatos y como herramienta para encontrar puntos débiles, demuestra un enfoque taylorista. Si en cambio se utiliza para conocer las cualidades del candidato y lo que puede aportar al equipo de trabajo, el enfoque es post-taylorista, de organización inteligente en la que el todo es más que la suma de las partes.

domingo, 17 de octubre de 2010

Microsoft carga contra OpenOffice

Recientemente Microsoft® ha publicado un anuncio donde se recogen los comentarios de diversas personas en algunos casos con referencias explicitas a OpenOffice. Lo podéis ver aquí.

Se compone de 18 testimonios, dos de ellos anónimos que he numerado del 1 al 18 por orden de aparición.

Las quejas son: falta de soporte (4 quejas); costes ocultos (9); fragilidad de la solución (1); interoperabilidad (4); tiempo de respuesta (2); y formación de usuarios (5). En muchos casos los testimonios afectan a más de un tema. A continuación pasaremos revista a los distintos grupos para sacar conclusiones al final.

Falta de soporte: En general los testimonios que hablan de este tema: 1, 5, 6 y 7 no tienen más base ni contenido que cuando oímos en un pasillo a alguien quejándose del precio de las judías. No hay análisis, ni datos, ni comparaciones. El único que vale la pena comentar es el 5 donde el product manager de la división de bufandas se queja de que cuando pidió ayuda al departamento de informática porque no se aclaraba con las macros de OOCalc, los cachondos le dijeron que se comprara un Excel. Me pregunto si Excel es su solución corporativa, y si lo es ¿porqué no lo estaba usando antes?

Los costes ocultos: Esta es la otra cara de la «falta de soporte», como ellos no nos dan soporte, lo tenemos que dar nosotros y nos cuesta un pastón. Las entradas son: 1, 3, 4, 6, 13, 14, 15, 16 y 17.
La mayoría adolecen de falta de base como las anteriores, aunque algunas dan algún número poco significativo sin más información. Es interesante el número 13 que se queja de que los nuevos empleados al no tener formación previa de OpenOffice tardan más en adaptarse y afecta a su rendimiento. En varios de los mensajes parece que todo el mundo nace sabiendo MsOffice y no tienen ni idea de OpenOffice. ¿No es función de los departamentos de IT formar a los usuarios?

La fragilidad de la solución: El único mensaje que habla de robustez es el número 2, un director de tecnología que reclama una solución en la que se pueda fiar, y añade a modo de corolario... «si una solución de código abierto falla, ¿quién va a solucionarlo?». Sorprende que un director de IT haga un comentario como ese, como si nunca se hubiese encontrado con algún problema con un programa de pago.

La interoperabilidad: Éste es uno de los que más me ha gustado. Por los testimonios recogidos, parece que el tema de la interoperabilidad sólo es cosa de uno OO. Los textos son: 7, 8, 9 y 10. Uno de los más jugosos es el 8 que se queja de que los usuarios tienen problemas con los documentos que vienen de fuera de la compañía, ¡todo un director de ICT!, ¿no es responsabilidad de informática el proveer de las herramientas/formación que haga falta para solucionar estos problemas? Hay otro mensaje, que me parece terrible, el número 10, de una profesora que baja la nota a los alumnos que le entregan documentos que han convertido de OO y tienen formato. ¿No es su trabajo juzgar el contenido? ¿No debería asumir ella o la escuela los problemas de formato?

Tiempo de respuesta: En este apartado sólo tenemos dos, los dos igual de faltos de contenido. En el 12, por poner un ejemplo, todo un administrador de sistemas confiesa que los usuarios estaban frustrados porque OO (y el entorno informático en general) no les permitía ser más productivos. Es difícil, con esta información, señalar otro problema que no sea el departamento de informática, es prácticamente una declaración de incompetencia. No han sabido analizar las necesidades de los empleados, y no les han provisto de las herramientas adecuadas. Tampoco dice si el problema se ha resuelto ni como. La suposición de que el problema viene de los tiempos de respuesta es mía, quizás por falta de imaginación. ¡Vaya usted a saber!

Formación de los usuarios: Las entradas 13, 14, 15, 16 y 18 me han abierto los ojos. Toda la vida (laboral) pensando que la responsabilidad de la formación de los trabajadores y el facilitarles las herramientas adecuadas era responsabilidad de IT y resulta que no. Veamos el testimonio número 18 que es el más patético de todos. Un CIO, nada menos, comenta que tras volver a MsOffice después de una experiencia con OO, todo el personal respiró aliviado. Y yo me pregunto ¿con qué criterio se tomó la decisión de ir a OO? ¿Hasta qué punto estaba consensuada la decisión? ¿Se molestó alguien en comunicar el cambio y sus ventajas a los usuarios? ¿Se les dio la formación correspondiente? ¿Se les ayudó a convertir todos los documentos a los nuevos formatos? Si alguien cree que hay base suficiente para responder afirmativamente a alguna de estas preguntas que me lo explique.

Conclusiones: El problema más aparente es que los departamentos de IT tratan las herramientas «Office» con mucha ligereza, omitiendo formaciones, análisis de viabilidad, migraciones, etc.
Pero lo que preocupa verdaderamente es que Ms publique un anuncio como éste. Está claro que no tienen argumentos para hacer una defensa decente de sus productos, y que tampoco tienen criterio para ver que los argumentos que presentan son una basura.

Por cierto, he escrito este texto con OO :-)

martes, 31 de agosto de 2010

Notas de un jefe de proyectos. La primera lección

La presentación despega con cinco transparencias sobre proyectos catastróficos, la transparencia que sigue es una definición de liderazgo de proyectos. Entonces Joan, uno de los directivos que asisten al curso, levanta la mano. Marc, consultor, jefe de proyectos e instructor ocasional detiene su explicación y le anima a preguntar.

Joan se explica: «los proyectos que nos has presentado eran muy importantes, supongo que con presupuestos como los que se manejaban en estos proyectos, había un jefe de proyectos competente. ¿Por qué fallaron entonces?»

–La presencia de un jefe de proyecto no garantiza, desgraciadamente, el éxito del proyecto, sólo aumenta las probabilidades de éxito. La primera pregunta que un jefe de proyecto debería hacerse es: «¿se necesita o no se necesita un jefe de proyecto?». Pero cualquiera de las respuesta es correcta. Me explico: si un proyecto va bien, no necesita un jefe de proyectos, la humanidad lleva siglos desarrollando proyectos sin jefe y con éxito pero si un proyecto va mal, un jefe de proyectos es de lo más útil. Es como el mecánico, si el coche va bien, no lo necesitamos. ¿He contestado la pregunta? –Responde Marc.

–Sí y no. ¿Cuál es entonces el objetivo de las transparencias anteriores? –añade Joan –¿desanimarnos?

–No es corriente presentar una disciplina con una lista de fracasos, pero es una práctica común en estos cursos; el objetivo es impactar la audiencia, interesarla y demostrar que hacen falta jefes de proyecto, aunque no funcione si la audiencia es un poco crítica.

–¿En qué mejora un proyecto si tiene un líder? –añade Joan, que claramente no ha quedado satisfecho con la explicación.

–La principal función del líder del proyecto es centrar el objetivo, como enfocar una cámara de fotos, y compartir esta visión con el equipo y conseguir que cada miembro la haga suya. Si los resultados esperados no están bien definidos, el primer objetivo del jefe de proyectos es aclararlos lo antes posible; y si varían durante el proyecto, reconstruir la visión común y minimizar el impacto.

Por unos segundos tuvo la tentación de dar por concluida la sesión.