Como parte del trabajo que estamos haciendo para la próxima reencarnación de SG Talento, estamos definiendo una escala para evaluar el nivel de habilidad de un profesionista de TI. Comparto aquí algunos de los aspectos más relevantes que estamos tomando en cuenta.
Antecedentes
La escala utilizada típicamente consiste en referirse a los años de experiencia. La ventaja es que es algo sencillo de medir, la desventaja es que en muchos casos no es representativo del verdadero nivel de habilidad. El hecho de que hace 10 años hayas programado en Java, no significa que tengas 10 años de experiencia continua y reciente haciéndolo. Por otro lado, tal vez tengas 10 años continuos, pero ha sido en contextos que no te han ayudado a realmente avanzar tu habilidad.
Para ejemplificar este problema, imaginemos el caso de Juanito: durante los últimos 7 años, su trabajo ha consistido en dar mantenimiento a una aplicación Java EE. Dicha aplicación utiliza servlets, JSPs, unos cuantos EJBs locales y una base de datos Oracle. En papel, podríamos decir que Juanito es un programador Java EE Senior, y seguramente un reclutador se animaría a presentarlo como experto. Pero si me preguntan a mí qué esperaría de un experto en Java EE, Juanito no cumple el perfil. Yo pediría que fuera alguien que por lo menos: ha construido y puesto en producción varias aplicaciones en las que se ha utilizado una buena variedad de los APIs de Java EE, que se ha peleado con distintos application servers y sabe de donde cojea cada uno, que no solo conoce los cambios/diferencias entre distintas versiones de la especificación de JEE, sino que entiende a profundidad las implicaciones de estos, y por último esperaría que fuera alguien bien relacionado con otros expertos de Java EE más allá de su empresa.
Otro caso que evidencía el problema de usar años como escala de habilidad es cuando hablamos de nuevas tecnologías. ¿Cuantos de nosotros hemos visto posts como: "Se solicita programador con 5 años de experiencia en X tecnología" (cuando dicha tecnología tiene poco más de 2 años de vida)? Típicamente lo que sucede en el fondo es que un cliente dice: "necesito un programador senior en X", entonces el reclutador, quien no tiene forma de evaluar la habilidad de alguien en X, traduce Senior como 5+ años de experiencia.
Asímismo, hay que reconocer que la mayoría de las personas no llega a niveles avanzados de habilidad en un dominio, sin importar cuantos años de experiencia acumulen. Por medio de práctica y experiencia la mayoría de las personas podemos llegar a niveles suficientes para desempeñarnos profesionalmente en un dominio, pero de ahi a realmente convertirnos en expertos, solo un pequeño porcentaje lo logra y no necesariamente son los que tienen mayor tiempo haciéndolo.
Ante las limitantes de usar años de experiencia, considero que lo mejor es abstraer la habilidad y experiencia en niveles (ej. básico, intermedio, avanzado; junior, senior, experto). El reto principal de definir una escala basada en niveles es definir claramente el significado de cada nivel. Por ejemplo, ¿qué es un senior? (y si me dices que es alguien con al menos 5 años de experiencia, morirá un gatito en algún lado).
Otro punto a considerar es si debemos incluir niveles que signifiquen que una persona apenas está aprendiendo las habilidades básicas para cierto dominio. Los clientes y reclutadores tienden a ignorar por completo este nivel (dificilmente vas a encontrar vacantes que busquen trainees, o si tu te etiquetas como trainee en una área dificilmente recibirás una oferta de empleo), todos buscan expertos. Lo único que esto ha provocado es que las personas que naturalmente deberían considerarse en este nivel, se autoevalúan de un nivel mayor para poder ser considerados y estar "en el mapa". Desde mi punto de vista, esto es un error que ha cometido el mercado laboral de TI, porque al eliminar niveles se hace más difusa la identificación. Estar aprendiendo algo no tiene nada de malo, al contrario, es bueno. De la misma manera, contratar a personas que apenas están aprendiendo algo, puede ser incluso mejor que contratar a alguien que ya ha adquirido esa habilidad. Cuando yo trabajaba en una empresa de consultoría de TI y armaba equipos de trabajo para los proyectos, mi mix ideal para los equipos de proyecto era un 20% de trainees (apenas aprendiendo y dando sus primeros pasos), 60% junior (han estado en al menos un par de proyectos profesionalmente), y un 20% senior (larga trayectoria de proyectos y buenos resultados).
La propuesta
A continuación presento nuestra propuesta de escala:
- Aprendiz. El aprendiz cuenta con los conocimientos básicos de la profesión en cuestión (ej. graduado de una carrera de TI) y está aprendiendo una especialidad (ej. project management, testing, programación de aplicaciones móviles) de manera profesional. Es capaz de realizar tareas profesionales sencillas bajo supervisión.
- Profesional. Su nivel de conocimientos y experiencia le permite realizar las actividades de la disciplina en cuestión de manera autodirigida y sin supervisión. La mayoría de las personas se queda en este nivel de competencia (y eso no es malo, significa que pueden hacer el trabajo de esta especialización de manera confiable).
- Líder. Tiene amplia experiencia ejerciendo la disciplina en una gran variedad de proyectos y desempeñándose de manera extraordinaria. Ejerce liderazgo para esta disciplina a nivel de equipo o incluso de la empresa entera.
- Maestro. Destaca no solo en su empresa sino a nivel de industria, contribuyendo a avanzar el campo de conocimiento en la disciplina en cuestión.
Consideraciones
Hemos mantenido esta escala lo suficientemente genérica como para que se pueda aplicar a distintas tecnologías (ej. Java, SAP, iOS), roles (ej. programador, tester, project manager, consultor ERP) e incluso profesiones (ej. diseñador, vendedor).
Los niveles de la escala aplican de manera independiente a distintos roles y tecnologías. Es decir, yo puedo tener un nivel de líder como analista, y un nivel de aprendiz como tester.
Podemos aplicar esta misma escala al nivel de detalle de herramientas/tecnologías. Por ejemplo, una persona puede ser un programador Java EE nivel profesional y programador iOS nivel aprendiz. Obviamente, es de esperarse que una persona con un nivel avanzado en alguna especialidad, crezca rápidamente en otra especialidad similar. Es decir, tal vez a un desarrollador novato le podría tomar un año pasar del nivel de aprendiz con su primera especialidad (ej. programador .NET) pero si su siguiente especialidad fuera del mismo rol (por ejemplo, programación con otro lenguaje), entonces sería de esperarse que dure como aprendiz unas cuantas semanas.
La escala muestra tan solo cuáles son los niveles del modelo y los rasgos principales de cada uno. Está fuera del alcance mostrar detalles sobre el cuerpo de conocimiento requerido en cada disciplina o especialización (por ejemplo, qué conocimientos y habilidades específicas debe tener un programador web nivel profesionista).
Aunque el nivel de aprendiz es el inicial para cualquier disciplina o especialización, esto no significa que deba ser tomado a la ligera y que cualquier persona puede decir que se encuentra en nivel de aprendiz de cierta especialización, simplemente porque le gustaría aprenderla o porque tiene el potencial para hacerlo. Un lineamiento (rule of thumb) en ese sentido podría ser que para ser considerado con un nivel de aprendiz en cierta especialización, la persona debería haber dedicado durante los últimos 6 meses al menos 80 horas de estudio a la especialización en cuestión (ya sea en cursos, lecturas, actividades prácticas) y actualmente participar activamente en algún proyecto (personal o profesional) que le permita desarrollar su capacidad en dicha especialización.
¿Y las certificaciones?
Posiblemente conforme lees esta nota te estés preguntando "¿y entonces qué rol juegan las certificaciones?".
A continuación podría aventarme un largo análisis sobre los pros y contras de las certificaciones (de hecho lo hice y decidí eliminarlo porque distraía del objetivo), pero dejémoslo en que en esencia las certificaciones son tan solo "un mecanismo para que las personas que carecen de reputación o experiencia comprobable, puedan demostrar un nivel de conocimiento básico en un área de especialización."
Bajo esa óptica, considero que una persona certificada en un área de especialización pero sin experiencia profesional en ésta, sería considerado nivel aprendiz. ("te certifico como aprendiz", jeje), mientras que una persona certificada con experiencia profesional reciente en el campo en el que se certificó, podría ser considerada nivel profesionista. Pero una certificación por sí misma no podría denotar un nivel de líder o maestro. Éstas involucran logros profesionales y reconocimiento de tus colegas que van más allá de una certificación.
Próximos pasos
En esta nota compartí el razonamiento y decisiones que estamos tomando para establecer una escala que nos permita determinar el nivel de un profesionista de TI. Si crees que tiene sentido, te invito a que lo adoptes y nos hagas llegar tu retroalimentación. Por nuestra parte, utilizaremos esta escala en la nueva versión de SG Talento (un servicio de currículum en línea provisto por SG) y evaluaremos qué tal resulta.
- Log in to post comments