Primero de todo decir que no soy ni jefe de proyecto ni nada que se le acerque. La palabra jefe, gestor, responsable se usa con demasiada soltura, ser un gestor competente es muy difícil y requiere mucho tiempo, exactamente igual que ser bueno en otros ámbitos más un toque de sensibilidad con el prójimo.
En España los títulos de gestión (jefe de proyecto, jefe de sección, gestor de blabla) se usan como complemento a los absurdos salarios, "fulanito, vas a ser responsable jefe del proyecto amoeba-ultra-2.0, vas a llevar toda la gestión, sabemos que podemos confiar en ti, blablabla...", pero realmente no responden a una experiencia por parte de la persona que está en ese puesto, en la mayoría de los casos (*).
Nuestro scrum manager de cabecera en la empresa estaba de vacaciones, así que decidí tratar de hacer un sprint como mandan los canones de scrum, bueno, realmente como yo lo aprendí de @jmnavarro en mi estancia en unkasoft, con su reunión con cliente, elección de tareas del backlog, estimación, su avance, su burndown chart y finalmente la retrospectiva.
Decir que el desarrollo fue bien, se terminó en plazo, con calidad más que suficiente, pero eso no le interesa a nadie, aquí lo interesante es ver en donde metí la pata hasta el fondo, ¿no?:
- Puñetazos encima de la mesa: He tomado elecciones en base a mi experiencia por encima de las decisiones de mis compañeros, lo cual puede estar bien, pero no deja de ser un error. No dejar elegir su camino a tus compañeros es un grave error, aunque sepas sí o sí que hay formas mejores de hacer las cosas. Si la idea es formar un equipo de desarrollo a un buen nivel todo el mundo debe aprender y la mejor forma de aprender es afrontando problemas tú solito.
- Meterme en las tareas de mis compañeros: En un momento puntual decidí terminar a machete una tarea de un compañero (además de gestor, programo, ¿te suena?) ya que estaba bloqueando el desarrollo. Desde el punto de vista del proyecto es lógico hacerlo, pero no me paré a pensar que mi compañero se podría sentir ofendido, dolido por haber terminado algo en lo que estaba trabajando. Mil veces prefiero llegar tarde un sprint a tener un roce absurdo.
- Notificar los errores: no hay cosa más difícil que decir a alguien que la ha mangado. Y no quiero decir hacerlo sin que se sienta ofendido.
En resumen, si no tienes un poco de tacto, mano izquieda, inteligencia emocional, como lo quieras llamar, es mejor que te quedes como un buen técnico.
No hay nada mejor que las curas de humildad que la vida te da de gratis y que la memoria te recuerde los malos ratos que hiciste pasar a algún que otro gestor de forma innecesaria, mis disculpas atradas.
(*) En mi corta-pero-intensa vida laboral solo recuerdo a un par de personas haber estado a la altura de un puesto así, y cada día que pasa me acuerdo más de alguno de ellos :)
3 comentarios:
no estoy de acuerdo contigo, llevas todo el proyecto haciendo tareas de gestor y muy bien. No es fácil pasar a desarrollar todo el role en una semana. Respecto a las practicas, yo creo que es mejor añadirlas poco a poco en lugar de introducirlas todas de golpe.
Respecto a "Puñetazos encima de la mesa" lo ágil se basa en personas con experiencia, talento, etc.. El equipo con el que trabajas es Junior, así que en mi opinión hiciste bien guiandoles, que la mejor forma de aprender es pegartela tú mismo.... estoy de acuerdo, pero si te ayudan en el camino mucho mejor, además creo que cuando eres junior lo mejor que te puede pasar es que alguien como tú, te enseñe, al menos yo saco eso como lo mejor que me paso en Unkasoft con Jm como Yoda :).
De todas formas, lo que hacemos ahora mismo dista mucho de ser jefe de proyecto, en mi opinión no tiene sentido ese role en un equipo de 2 senior y 2 junior. Siempre y cuando se hagan las reuniones diarias, haya sincronización, colaboración y comunicación fluida entre el product owner y el equipo.
De hecho sino recuerdo mal, según Scrum no existe y sus responsabilidades están compartidas entre todos los roles (Product Owner, Scrum Master, Scrum Team)
Javi, para saber si has hecho mal habría que conocer a cada miembro de tu equipo. No se gestiona igual a un junior que a un senior, por ejemplo.
Para empezar no sé si tú además de gestor seguías haciendo de programador. En el mundo ideal el gestor no debería programar, porque cada minuto que pasa escribiendo código es un minuto menos dedicado a gestionar el proyecto. Pero ya sabemos que el mundo real funciona distinto —rara es la semana que no pico un poco de C, Java, Python o incluso PHP—.
Dejar a un junior al libre albedrío es poco aconsejable, especialmente en tareas que implican diseño de sistemas. A veces lo correcto es imponer decisiones. Otra cosa distinta es imponer tu criterio acerca de una decisión técnica a un lead, que *en teoría* debería saber más que tú acerca del proyecto a nivel técnico.
Vamos, que no se pueden gestionar ni todas las personas ni todos los proyectos por igual. Para cada persona tendrás que adoptar un modelo distinto de mando en función de su rol, su experiencia y la situación actual.
Tampoco me parece mal que termines tareas de un compañeros de manera puntual. Ownership of code should be shared, y tal. Sin embargo es necesario inculcar el concepto de shared ownership desde el principio, para que nadie se crea dueño de ciertas partes del código. Ver:
http://agilesoftwaredevelopment.com/blog/mendelt/whos-owner-shared-code-vs-code-ownership
Finalmente, cuando alguien la lía parda yo simplemente le abro un caso con la descripción del problema, o bien se lo comento vía verbal en tono tranquilo. Lo importante es comunicar que "hay un problema, por favor corrígelo y dale prioridad X respecto a tus otras tareas", en vez de comunicar "la has cagado". Nadie debería sentirse ofendido por un bug report.
Todo lo de arriba es válido independientemente de que uses scrum, scram o scrom…
Ser un buen director de equipo no es facil, y hay mucha gente que no está hecha para estar en ese "fuego cruzado" (inteligencia emocional y/u otras cuestiones del estilo).
JM fue el primer jefe de proyecto con el que trabaje, el más joven que he conocido en ese puesto, y aunque solo estuve en Unkasoft unos meses de nada, he de decir que ha sido el único al que he visto verdadero interés en lo que hacia y en mejorar como tal.
No se por qué, pero me da en la nariz que esto tiene que ver con el tema de siempre (alguien recuerda Motivación Intrinseca VS Extrinseca?). La motivación es lo que le hace grande a la gente, lo q la hace mejorar y hacer cosas admirables.
Triste es que en este pais muchas veces los que no la tienen parece que intentan dar palos a los que la demuestran, en todos los campos del entorno laboral.
En cualquier caso, como dice flopez (y con el conocimiento personal que tengo de ti :P), estoy seguro de que los has hecho mejor de lo que parece que expones, pero una cosa esta clara: tienes interes en mejorar, si no este post no estaria aqui.
Para mi eso lo es todo, llegarás a estar entre los mejores.
Publicar un comentario