Consejos para elegir tu lugar de trabajo

Guau… mi último post fue hecho hace muchos años. Cómo pasa el tiempo!
Luego de tanta espera, quería retomar mi Blog con un post significativo.

Muchas de mis publicaciones en este sitio intentaron compartir mi experiencia en la selección, evaluación y motivación de un equipo de trabajo (especialmente técnico). Compartí las diferencias que encuentro entre programadores de distinto seniority, un modelo para realizar evaluaciones de desempeño, en particular evaluación a programadores y a líderes. También compartí consejos sobre cómo dar feedback a un colaborador.

En esta oportunidad quise encarar la situación desde el punto de vista de una persona que está evaluando una oportunidad laboral.

Entonces, la pregunta fundamental a contestar es ¿qué aspectos debo evaluar de un potencial empleador? Cada persona vive una situación distinta, pero estas son las cosas que yo evaluaría a la hora de elegir un trabajo:

  1. ¿Voy a disfrutar de mi trabajo?
    Uno pasa más horas en el trabajo que en su hogar. Comparte más tiempo con sus compañeros que con su familia y amigos… Creo que es importante que dediquemos esta porción tan grande de nuestro tiempo en una actividad que nos de gratificaciones.
    – Buscar un lugar dónde te de gusto dirigirte por las mañanas
    – Si sufrís al despertar, si el domingo a la noche te deprimís, si necesitás un café extra fuerte y algunas aspirinas para enfrentar el día, tal vez sea hora de cambiar de trabajo.
    – Si tienes oportunidad de conocer las oficinas donde trabajarás, prestale atención a la cara de las personas que ya trabajan, a su lenguaje corporal, a la libertad con la que se expresan y mueven. Esto dice mucho de una empresa y su cultura.
  2. ¿Voy a aprender algo nuevo?
    Personalmente busco oportunidades que me desafíen, que me propongan nuevos retos y que me permitan ganar nuevas habilidades. Si luego de varios años de trabajo no he aprendido a hacer nada nuevo, siento que desperdicié una parte de mi vida.
    También me parece importante tener oportunidades de crecimiento (no solo de conocimiento sino de asumir mayores responsabilidades en el tiempo). Hay personas que prefieren la estabilidad y la seguridad, yo prefiero los desafíos y la adrenalina de intentar superarlos.
    – Preguntar con qué tecnologías trabajan
    – Preguntar con qué metodologías, y si existe libertad para ajustarlas
    – Tratar de dilucidar en la entrevista cuáles son los desafíos a futuro que puede presentar la posición que estás evaluando
    – También sirve consultar cada cuánto revisan posibles promociones (puede ser todo el tiempo, anual, cada 6 meses, etc.).
  3. ¿Cuál es la cultura de la empresa?
    Prefiero empresas donde las partes colaboran y trabajan en equipo, en vez de competir entre ellas. Me encanta competir, pero hacia afuera y no con mis compañeros de trabajo.
    Prefiero compañías que tengan libertad de acción. Idealmente que estén desarrollando su propio producto. También es interesante trabajar para empresas que brindan servicios porque los temas pueden ser más variados en el tiempo y los proyectos más cortos, pero durante mis últimos 12 años como responsable de Producto y Desarrollo he encontrado infinita satisfacción al estar trabajando para productos propios.
    – Te parece una empresa ética?
    – Hacen un bien a la humanidad o solo buscan ganar dinero?
    – Tiene una estructura jerárquica plana (como a mi me gusta) o más piramidal (lo que implica más burocracias muchas veces).
  4. ¿Quién será mi jefe?
    Considero importante contar con un jefe que comparta mis valores. No me asusta la exigencia pero siempre intento generar una relación de trabajo en equipo con mi jefe. Si no hay confianza o las confrontaciones son demasiadas, dejo de sentirme muy cómodo.
    Me parece fundamental que mi jefe tenga cosas para enseñarme y a su vez que se muestre él mismo abierto para seguir ampliando sus conocimientos.
    ¿Escucharon alguna vez el dicho de que “las personas no renuncian a su trabajo, renuncian a sus jefes”? Muchas veces es así.
    – Cuáles son sus intereses?
    – Cuáles son sus objetivos dentro de la empresa?
    – Qué ha hecho en el pasado?
  5. ¿Cómo es el equipo de trabajo?
    ¿Mis compañeros serán profesionales de primer nivel que me estimulen a buscar los mejores resultados o se trata de un grupo poco exigente consigo mismo? Si fuese el segundo caso, ¿tendré el espacio para desafiar el status quo y generar un ambiente más activo?
    – Los equipos tienen libertad de acción?
    – Se autogestionan o gran parte de su tiempo deben estar rindiendo cuentas de las tareas a las que dedican su tiempo?
    – Es super interesante preguntar a un entrevistador cuánta gente contrató la empresa los últimos años, cuánta gente renuncia y cuántos son despedidos.
  6. ¿Estaré bien compensado?
    Y si… no vamos a hacernos los puristas… el dinero es importante!
    Siempre busquen tener una compensación justa y evalúen también otros beneficios que pueda dar la empresa, como ser plan de salud, horarios flexibles, etc.
    No creo que deba ser el motivo principal para elegir un trabajo (siempre hay otro donde los salarios son más altos), pero hay que buscar un sueldo justo, razonable y que nos permita no ocupar nuestro cerebro en pensar si llegaremos a pagar las cuentas a fin de mes. Así liberamos esas neuronas y nos concentramos en lo que importa.
  7. ¿El área dónde ingreso hace la diferencia?
    Siempre he trabajado en posiciones relacionadas a IT. En algunas empresas, el sector es considerado como la columna vertebral de la compañía. En otras, es considerado simplemente un mal necesario.
    Yo busco trabajar en estructuras donde la tecnología sea lo más importante posible.

PREGUNTEN en las entrevistas. El objetivo es que la empresa los conozca, pero también que ustedes conozcan a la empresa. Si la relación no va a funcionar será malo para ambas partes.

SEAN HONESTOS en las entrevistas. Dejen ver sus fortalezas y también compartan sus oportunidades de mejora. No todas las organizaciones buscan lo mismo de sus empleados.

SEAN RESPETUOSOS, puntuales, correctos, claros al expresarse… pero también muestren soltura, curiosidad y humildad.

Me encantaría que me dejen preguntas concretas sobre este tema. Pienso que va a ser un post que irá creciendo en el tiempo y con mucho gusto les daré mi opinión sobre sus situaciones particulares.

SCRUM funciona!

En esta oportunidad quiero compartir mi muy agradable experiencia de implementar Scrum como metodología de gestión de proyectos en OLX.

ScrumCycle

Introducción

Empezaré presentando algunas definiciones para ponernos en tema:

  • Scrum es un proceso ágil de desarrollo de software, iterativo e incremental. En cada iteración se hacen variadas actividades de análisis, diseño, desarrollo, testing, implementación.
  • Scrum está enfocado a la gestión de los procesos de desarrollo y puede o no estar implementado en conjunto con otras prácticas ágiles como ser Extreme Programming (XP), Continuous Integration, Test Driven Development, etc.
  • Scrum suele vincularse al desarrollo de software, pero su aplicación es adecuada dentro de las especialidades más variadas que podamos imaginar.
  • Scrum es “liviano”, presenta simplemente un modelo de referencia que describe un conjunto de prácticas y roles que puede tomarse como punto de partida para definir el proceso de desarrollo.

Roles que Scrum propone:

  • El Scrum Master: Se asegura que se sigan los procesos, trabajando de forma similar al director de proyecto.
  • El Product Owner: Representa a los Stakeholders (clientes internos o externos).
  • El Team: Incluye a los desarrolladores, testers, diseñadores, analistas, etc.

Prácticas que Scrum propone:

  • Se realizan ciclos (o iteraciones) de duración fija llamadas Sprints. Se recomienda que la duración de un Sprint sea de 2, 3 o 4 semanas.
  • Durante el Sprint el objetivo del equipo es generar un incremento visible, utilizable, entregable.
  • Al inicio de cada Sprint se realiza una Planning Meeting durante la cual se revisa el Backlog de proyectos (listado de requisitos de alto nivel pendientes, previamente priorizados por el Product Owner). En esta reunión el Product Owner identifica los proyectos que quiere resolver y los describe al equipo. Entonces, el equipo determina cuáles de estos proyectos pueden ser comprometidos para el Sprint.
  • Durante el transcurso del Sprint no se puede modificar el alcance del mismo, es decir, se intentará mantener congelados los requisitos hasta que el mismo finalice. En la práctica, nos hemos reservado parte de nuestro tiempo para lidiar con urgencias que no pueden esperar un ciclo para ser resueltas.
  • Diariamente se realiza una Daily Meeting que no debe durar más de 15 minutos, donde cada persona del equipo comparte las tareas realizadas, lo que piensa hacer hasta la reunión del día siguiente y si se ha topado con algún impedimento que no le permita avanzar de acuerdo a lo comprometido.
  • Al final del Sprint, luego del Deploy / Release / Incremento en el producto, se realiza una Retrospective Meeting durante la cual el equipo comparte libremente opiniones sobre las cosas que salieron bien (y desean repetirse a futuro) y las cosas que salieron mal (y deben evitarse a futuro).

Ahora si, pasemos a mi historia…

Continuar leyendo “SCRUM funciona!”

Metodologías amigas – Metodologías enemigas

Supongo que fue a finales de los años ’90, que trabajando en el Banco Hipotecario con un equipo analistas y programadores a mi cargo, empecé a interesarme en el tema de las metodologías de desarrollo de software y de gestión de proyectos en general.

Resultaba evidente que para poder gestionar de manera eficiente el trabajo de muchas personas asignadas a muchos proyectos simultáneos, yo necesitaba establecer algún tipo de procedimiento “repetible” que nos permitiera ordenarnos (y sobrevivir).

Lección aprendida #1:
Un buen proceso metodológico es nuestro mejor amigo.

Por ese entonces – seguramente favorecido por la cultura bancaria y mi tendencia obsesivo-compulsiva – yo era partidario de aplicar el famoso proceso en cascada que incluso hoy en día se enseña en la mayoría de las universidades.

Por cada proyecto atravesábamos una serie de fases secuenciales, cada una con un entregable que permitiera avanzar a la etapa siguiente. Típicamente el ciclo incluía las siguientes etapas:
Priorización -> Relevamiento -> Análisis -> Diseño -> Desarrollo -> Testing -> Implementación

Sabíamos, sentíamos y sufríamos la limitación principal de este esquema de trabajo: Era habitual que los usuarios cambiaran de opinión durante cualquiera de las etapas por lo cual gran parte de nuestra energía se destinaba a la gestión del cambio. De más está decir que el proceso en cascada nos predisponía a resistirnos al cambio.

– “De vuelta cambiaron de opinión?”
– “Quéeeee? Tenemos que volver a revisar el documento de alcance del proyecto? Pero si ya lo actualizamos 3 veces!!!”
– “Desarrollémoslo como estaba originalmente planteado – incluso si no sirve para nada – y el mes que viene lo actualizamos”
– “Por qué habré decidido estudiar sistemas… debería haberme dedicado a la música” Continuar leyendo “Metodologías amigas – Metodologías enemigas”

¿Realidad o Ilusión? #3

Navegando un poco, me encontré otras dos ilusiones ópticas que me parecieron muy buenas.

En ambos casos tienen que mirar el centro de la imagen, dejar la mirada fija en ese punto y luego de algunos segundos verán como parte de la misma va desapareciendo.

Puntos rosa que desaparecen
Puntos rosa que desaparecen
Colores que desaparecen
Colores que desaparecen

Cosa de locos, no?
Habrá que al menos dudar un poco antes de podamos asegurar que todo lo que nuestros ojos ven es la realidad.

Ejemplo de evaluación de desempeño a un líder

Cuando me encuentro evaluando el desempeño de un líder de equipo, existen algunas características adicionales que suelo considerar, como ser:

  • Establece acuerdos con otros líderes de la organización o es un jugador solitario?
  • Asume los compromisos o los esquiva?
  • Más allá de asumirlos… logra cumplirlos?
  • Se muestra en sintonía con el Norte de la Compañía o tiene sus intereses particulares que no lo hacen un jugador 100% leal?
  • Cumple con los procedimientos establecidos?
  • Da visibilidad sobre sus acciones y decisiones al resto de la compañía?
  • Es bueno motivando a su equipo?
  • Se comunica adecuadamente con pares, superiores y poderdantes?
  • La relación Productividad-Calidad de su equipo es la esperada?
  • Es realista y pragmático o pierde buenas oportunidades en búsqueda constante de la perfección absoluta?

En este post comparto con ustedes una versión del ejemplo de Evaluación de Desempeño, personalizada para evaluar a un líder de proyecto.

La estructura es bastante simple.

  1. Revisar la Guía de Evaluación donde se enumeran las características a evaluar. Ajustarla, asegurar que los evaluadores entiendan la descripción de cada uno de los aspectos que se consideran.
  2. Completar una planilla de Evaluación de Desempeño por cada persona evaluada.
  3. Completar la planilla de Ponderación de Métricas para reflejar la importancia relativa entre distintos conceptos (esto varía dependiendo de los valores y objetivos de la organización).
Para facilitar el ejemplo, he coloreado de amarillo las celdas que deberían completarse.
Espero que les resulte de utilidad.

Diferencias entre programadores Junior, Semi Senior y Senior

¿Cuáles son las principales diferencias entre un programador junior, un semi senior y un senior?

Durante las últimas semanas recibí algunas consultas sobre este tema, lo que me motivó a escribir este artículo.

No es un tema de simple respuesta. Incluso buscando en Google no se encuentran respuestas maravillosas sobre el asunto.

Lo que sucede en realidad es que las diferencias entre los distintos “niveles” dependen de las necesidades y la cultura de cada organización y de cada equipo. En distintos entornos lo que diferencia a un senior de un junior puede variar.
En algunas organizaciones la diferencia solo está dada por la cantidad de años de experiencia laboral que la persona tenga, en otros casos depende del grado de conocimiento técnico y en otros está asociado a la capacidad de la persona de gestionar proactivamente su trabajo.

Lo que no tiene cuestionamientos es que se trata de una temática sumamente sensible. Habitualmente la remuneración del ingeniero de software se asocia a su nivel de seniority, así que seré lo más cuidadoso posible al presentar el tema.

En este artículo comparto algunos de los criterios que pueden ayudar a definir el nivel de seniority de una persona. Cada uno de los indicadores puede tener más o menos importancia de acuerdo a cada organización (al final del artículo incluiré una encuesta para conocer tu opinión).

Si el lector es el Gerente del equipo, podría asignar una ponderación a cada uno de los indicadores antes de aplicarlos.
Si en cambio es un programador, mi sugerencia es que intente dominar todos los aspectos, aprovechando las oportunidades que se le presenten para su desarrollo.
Si el lector es el Gerente de Recursos Humanos, mi consejo es que ayude a comunicar dentro de la compañía cuáles son los aspectos que más se valoran. Continuar leyendo “Diferencias entre programadores Junior, Semi Senior y Senior”

Consejos para dar feedback

En artículos anteriores presenté algunos consejos para conducir entrevistas, sugerencias para realizar evaluaciones de desempeño e incluso presenté un ejemplo de evaluación de desempeño para programadores.

En esta oportunidad – y relacionado al tema de evaluaciones de desempeño – quiero compartir algunas prácticas que me son de utilidad a la hora de dar feedback a un miembro del equipo.

Dar feedback en el ámbito laboral tiene como principal objetivo informar al receptor acerca de la percepción que tenemos de su desempeño sobre una tarea o gestión realizada y el grado de acierto alcanzado respecto a lo que originalmente esperábamos.

Sin ser el mayor experto en el tema, ni mucho menos, considero que se trata de una herramienta fundamental para incrementar las fortalezas del empleado. Dar feedback adecuadamente es una habilidad valiosa para un líder, que puede ayudarlo a mejorar el desempeño de su equipo.

El feedback puede ser implícito o explícito. El implícito es el que se da a través de gestos, tonos de voz, expresiones y cualquier otra señal no verbal.

Además puede ser positivo o negativo. Normalmente cuánto más feedback positivo se recibe, mayor es la satisfacción (a menos que uno esté atravesando una etapa masoquista). El feedback negativo suele percibirse como amenazante y por ende tiende originalmente a desmotivarnos. Sin embargo el feedback negativo es fundamental para que podamos superarnos y evolucionar!!!

Continuar leyendo “Consejos para dar feedback”

Ilusión – ¿Cuál es la parte dominante de tu cerebro?

Para ver cuál es la parte dominante de tu cerebro… ¿ves a la bailarina girando en el sentido de las agujas del reloj o en dirección opuesta?

Si es en el sentido de las agujas del reloj entonces usas más tu lado derecho del cerebro o viceversa.

PARTE IZQUIERDA DEL CEREBRO PARTE DERECHA DEL CEREBRO
utiliza la lógica utiliza los sentimientos
orientada a los detalles orientada a lo general
dominan los hechos domina la imaginación
palabras y lenguaje símbolos e imágenes
pasado y presente presente y futuro
matemáticas y ciencias filosofía y religión
conocimiento creencias
reconoce aprecia
orden, percepción de patrones percepción espacial
conoce el nombre de los objetos conoce la función de los objetos
se basa en la realidad se basa en la fantasía
conforma estrategias presenta posibilidades
práctica impetuosa
va a lo seguro asume riesgos

Si uno se concentra lo suficiente, puede lograr que cambie de dirección; a ver si te sale.

Link Externo: Investigadores opinan sobre este test