Colección de Artículos Publicados por Alguien del Grupo Esquina-CTO
Me pidieron que describiera cómo evaluar a un administrador de proyectos de software. Recordé este bonito desafío que hice en algún momento, y me di cuenta de que tenía que cavar mucho en la memoria (y preguntarle a alguien que realmente había aceptado el desafío). Por esa razón decidí escribir sobre esto aquí.
En algún momento del pasado, tuve que contratar a un administrador de proyectos de software para una startup. Estábamos buscando a alguien que tuviera grandes habilidades de gestión de proyectos, pero que también entendiera a los ingenieros.
Como parte del proceso de evaluación, realicé un “desafío in situ”, que tomó alrededor de 3 horas. Para este desafío, el candidato tenía que definir un plan (en forma de un tipo de diagrama de Gantt) para ejecutar un proyecto de desarrollo de software, dado un conjunto de restricciones (en tiempo, recursos y alcance, por supuesto).
El objetivo del desafío era probar cómo manejaba el candidato la definición de un proyecto de la vida real, con sus limitaciones. Las limitaciones llegaron en forma de recursos y tiempo insuficientes, para el alcance
Se recomendó que el candidato hiciera preguntas al entrevistador, quien desempeñó los roles de a) El equipo de Ingeniería yb) El Equipo de Producto. Los puntos a evaluar fueron:
Qué tan bien interactuó el candidato con los “equipos” de ingenieros y productos para hacerles preguntas, aclaraciones, etc. ¿Cuánto “conocimiento de dominio” tenía el candidato que le permitiera tomar decisiones acertadas al hacer compromisos? Cómo manejó la dualidad alcance / recursos y qué soluciones se le ocurrieron para abordarlos. Alcance Para definir el alcance del proyecto, proporcionamos al candidato una lista de historias necesarias para desarrollar una aplicación móvil. Esta lista se componía de historias frontend (para implementar la interfaz de usuario estándar HTML / JS), historias backend (para las API que usaría la aplicación) e historias móviles (que requerían conocimiento móvil especializado).
Las historias se proporcionaron en forma de Nombre de la historia - Puntos de la historia - Habilidad, donde la habilidad definió qué tipo de ingeniero podría hacerlo (todos, solo front-end, solo backend, solo móvil). Las historias eran historias reales (en realidad estaban parcialmente basadas en otro proyecto que habíamos hecho antes).
Proporcionamos un conjunto de ingenieros teóricos para el proyecto. Los ingenieros se definieron en 2 dimensiones: antigüedad (Jr., nivel medio, Sr, líder tecnológico) y habilidades (frontal, backend, pila completa, móvil). Cada ingeniero tenía una antigüedad específica y una combinación de habilidades que tenían.
El factor de antigüedad se modeló como el número de puntos de historia que un ingeniero podría terminar por semana.
La idea aquí es que el candidato a Gerente de Proyecto tuvo que considerar las habilidades y la antigüedad al asignar cada historia a los diferentes Ingenieros.
La última de las restricciones se modeló como la fecha en que Business nos había pedido que lanzáramos el producto de software. El tiempo disponible, por supuesto, no fue suficiente para implementar la lista completa de requisitos considerando los recursos disponibles.
Además, como parte de la definición del problema, le pedimos al candidato que considerara a las personas que se van de vacaciones y se enferman (apenas recuerdo haber agregado algunos días de vacaciones para algunos de los ingenieros, aunque no estoy seguro de eso).
El resultado deseado del desafío fue un tipo de diagrama de Gantt. No pedimos explícitamente esto, pero le pedimos al candidato que utilizara cualquier herramienta que pudiera, de modo que al final del desafío, se presentaría a “Business” (es decir, el CEO, dado que se trataba de una pequeña empresa) plan para realizar el proyecto. Los mejores candidatos suelen hacer algún tipo de diagrama de Gantt.
El resultado fue solo un aspecto de la evaluación, otro (más importante para mí) fueron las interacciones que ocurrieron durante el desafío; estos en forma de preguntas al equipo de Desarrollo, o preguntas al equipo de Ingeniería.
Cuando los candidatos hicieron preguntas, se abrieron posibilidades aquí y allá. Por ejemplo, una historia que tenía 8 puntos si preguntaba si podía dividirse en dos, la respuesta generalmente era sí (dado que esas eran historias reales, traté de mantenerme fiel a la historia y dar una respuesta del “mundo real”. Por ejemplo, si la historia de 8 puntos era una pantalla de interfaz compleja en la aplicación, la dividía en 2 historias de 5 y 3, dividiendo el desarrollo de la pantalla en dos partes).
En algún momento, algunos candidatos incluso preguntaron sobre consideraciones de control de calidad (algo que no consideré inicialmente), por lo que les dimos alguna “ventaja” (en forma de tiempo, diciéndole que, por ejemplo, las historias tenían algo de control de calidad, lo que podría ser dividido y quizás mejor acomodado).
Lo único que estábamos buscando era candidatos que no solo llenaran el alcance hasta completar el tiempo disponible en el proyecto, sino que se fue un poco más lejos.
Mi experiencia con los proyectos de inicio ha sido que siempre no hay suficiente tiempo para hacer todas las funciones requeridas, pero el mayor valor (y desafío) es dar prioridad a las tareas para que el equipo pueda entregar el mítico MVP a tiempo y luego realizar iteraciones adicionales que mejoran el producto. Este tipo de razonamiento es lo que estábamos buscando como parte del resultado del desafío.
En general, los candidatos que hicieron más preguntas produjeron un mejor resultado. Entrevistamos a unas 30 personas diferentes para el puesto y obtuvimos un conjunto muy diverso de respuestas.
Algunos candidatos tenían una formación técnica más sólida y, por lo tanto, podían aprovechar más el contenido de las historias. Otros candidatos no tenían mucha experiencia técnica y aprovecharon más el lado comercial.
En general, el desafío fue un éxito, y al final recuerdo que encontramos al candidato adecuado para el equipo.
Algo importante a destacar es que, como muchas otras entrevistas “técnicas” (en el sentido de tener que implementar algo, en este caso un plan) tiende a sufrir un problema de “degradación del contexto”: cuando lo creamos, Para nosotros fue muy claro que la evaluación consistió no solo en el producto final (diagrama de Gantt o cualquier otra cosa) sino en la interacción y el proceso general que ocurrió durante las 3 horas. Si otras personas comienzan a usar este desafío, es importante no perder este contexto y solo considerar el producto final para la puntuación, ya que será engañoso.
He visto que esto sucede en otros tipos de desafíos (especialmente los que comprenden programar algo). Cuando los entrevistadores sin experiencia decidan aplicar el problema para una entrevista y puntuarlo como en “blanco y negro” dado el programa proporcionado por el candidato.