Chess - antoniomartel.com

Archivos por Etiqueta: gestión de proyectos

Nuevo número de la revista Proiectus

Ya está en la calle el número 2 de la revista Proiectus, la revista sobre la dirección de proyectos en Canarias. Echadle un vistazo al número número haciendo clic en el enlace que pongo a continuación:

En este número hay profesionales reconocidos en la gestión de proyecto de nivel nacional como Mario Coquillat, José Barato o incluso internacionales como Mike Griffiths. También hay gestores canarios tan conocidos como Iván Tejera, director de la revista, Toni Dorta, Agustín Tapia o Manuel Vara. También yo tengo un artículo llamado ‘Jefe de proyeto ¿y ahora qué?‘ en el que cuento a lo que nos enfrentamos cuando nos acaban de nombrar jefes de proyectos y qué podemos hacer para intentar conseguir mejores resultados.

Todos los artículos están muy bien pero no se pierdan ‘El director de proyectos ágil‘ de José Barato, ‘La velocidad, la botella, las pelotas, la arena … ¿e ITIL?‘ de Agustín Tapia y, por supuesto, tampoco dejen de leer la entrevista del final a Mike Griffiths. Lo que se cuenta ahí nos ahorraría muchas dudas y horas de búsqueda de información en Internet si estamos implantando Scrum.

Reuniones en Scrum

Dentro de la metodología Scrum se establecen una serie de reuniones con nombres algo complicados y duración, asistentes y fechas prefijadas. Les explico en este post el significado de estas reuniones y, sobre todo, cómo pueden ayudarte en tu trabajo:

Reunión de planificación del trabajo

Antes de comenzar el trabajo previsto
para las próximas 2 semanas te reunirás con el cliente (o representante del mismo y con las
personas que éste considere) y definirán qué tareas se realizarán
durante esas dos semanas (si el equipo de trabajo considera que puede hacerlas en ese tiempo) Durante esa reunión el cliente dará toda la información necesaria sobre las tareas escogidas explicándolas al equipo que va a desarrollarlas.
Tener en
cuenta la capacidad de trabajo del equipo durante esta reunión de planificación
permite, entre otras cosas, encajar los periodos de vacaciones o las ausencias de los miembros
del equipo. Es tan sencillo como explicar ‘Dentro
de dos semanas nos comprometemos a entregar solo 3 de estas tareas en lugar de las 5 habituales. Alberto y Pilar tienen vacaciones la próxima
semana
’ Esto no suele suponer un problema ya que el cliente lleva recibiendo entregas del trabajo cada dos semanas de forma consistente.

Reuniones diarias

El equipo de trabajo y el Scrum Master se
reunirán cada día, mejor al inicio de la mañana, durante 15 minutos para
contestar a las siguientes preguntas:
  • ¿Qué se hizo desde la última reunión?
  • ¿Qué se hará desde ahora y hasta la próxima reunión?
  • ¿Qué está impidiendo hacer el trabajo lo mejor posible?

 

Ejerzo
habitualmente de Scrum Master en varios proyectos y a cada una de las reuniones
diarias llevo una hoja impresa con estas tres preguntas donde mantengo
registros de las respuestas del equipo de trabajo. Al final de cada una de
estas hojas he añadido un apartado adicional llamado ‘Tareas para el Scrum
Master’ y en él anoto todas las cosas que el equipo de trabajo necesita para
continuar o qué les está dificultando el trabajo. Anotaciones frecuentes son: ‘Llamar al cliente y pedir lista de usuarios
(¡mañana comenzamos con esa tarea!)
’ o ‘Pedir exportación de la base de datos (necesitamos una copia ya antes de
empezar a modificar datos)
’) Es habitual que me pase el resto de la mañana
intentado resolver los problemas que me han contado a primera hora.

Reunión de demo

Al finalizar cada iteración de dos semanas se concreta una fecha
de reunión con el cliente y se le hace una demostración del trabajo
realizado en esas dos semanas. En esta reunión el representante del cliente, en su función como director del proyecto, revisará
lo que se le está mostrando y dará su visto bueno o no a lo que ha visto.
Para poder cerrar
la funcionalidad es importante que esté completamente terminada y libre de
errores (serán necesarias las pruebas del equipo de trabajo y una validación
completa del cliente). Si no fuese así, se llegaría al final del proyecto según
la gráfica burndown (todas las tareas
estarían a 0 horas de trabajo pendiente) pero el proyecto aún no está
finalizado porque hay funcionalidades incompletas o con errores por corregir.
Estas entregas
periódicas permiten ver al cliente cómo va avanzando su producto, qué se ha estado haciendo durante esas dos semanas y decidir luego, en la reunión de planificación, qué quiere
ver en la siguiente reunión de demo. Esto permite ganar confianza ante el cliente que no pierde de vista a la empresa desarrolladora una vez ha terminado
la toma de requisitos para volverla a ver meses después con un producto ya
completado sobre el que tiene pocas posibilidades de modificación.

Reuniones de retrospectiva

Después de cada iteración de 2 semanas y una vez
realizada la demo al cliente, el Scrum Master y el equipo de trabajo se reúnen
para estudiar los problemas que han podido ocurrir en esas dos semanas, por qué
la demo no salió todo lo bien que debería (o sí) y si se puede hacer algo para
mejorar en la próxima entrega.

 

Es bueno que el equipo de trabajo se sienta libre de expresar lo que considera que han sido
los principales problemas aunque eso te haga subir los colores. Los problemas a
veces están en la ‘zona ciega’ del Scrum Master y la visión en conjunto ayudará a aportar luz al problema.

La cigarra y la hormiga

Cierto verano una cigarra andaba ociosa por el campo cuando descubrió a una pequeña hormiga que corría atareada de acá para allá.

– ¿Qué haces? le preguntó la cigarra.
– La Reina me ha pedido que comience a construir un nuevo hormiguero, contestó la hormiga.
– Pero si ya tienen uno a solo unos metros, inquirió sorprendida la cigarra.
– Sí, dijo la hormiga, pero se nos está quedando pequeño y en invierno, con las lluvias, se moja lo que hemos recolectado.

La cigarra, dispuesta a aprender de sus laboriosas amigas, pensó que era buena idea eso de prepararse para el invierno. Las hojas y ramas con las que construyó su refugio el año pasado se estaban secando y no estaría mal tener un nuevo hogar en el que pasar cómodamente el invierno.

Rápidamente tomó una decisión y se puso a planear el estupendo refugio que iba a construirse. Ahora que tenía tiempo lo construiría con todas las comodidades posibles. Sería la envidia de todo el prado. Incluso desde más allá del seto de cipreses querrían venir a ver su nuevo hogar. Tendría grandes ventanales para que entrase mucha luz y diseñaría un ingenioso sistema de poleas que le evitaría tener que andar entrando y saliendo del granero para dejar lo recogido.

La hormiga en cambio tenía un plan. En agosto construiría la primera estancia que serviría de granero. Así, si este año las lluvias comenzaban pronto, tendría por lo menos algo de hueco extra en el que dejar la recolección. Después planificó el resto del trabajo según su importancia. Si no le daba tiempo a terminarlo todo tendría, por lo menos, construidas las partes más importantes.

Para septiembre excavaría un agujero donde hacer la sala donde dejar las primeras larvas del año. En octubre construiría una estancia adicional para ampliar aún más la capacidad del granero y por último, en noviembre terminaría el trabajo construyendo una última estancia donde poder cultivar hongos.

Mientras, la cigarra andaba preocupada por tener un salón lo suficientemente grande y contar con una estructura enorme para dar cabida a todas las habitaciones, despensas y mecanismos que tenía pensados. Andaba de un lado para otro buscando los materiales que necesitaría para poner en pie los grandes planes que tenía en la cabeza.

Ya en octubre cayeron las primeras lluvias pero la cigarra no tenía siquiera un refugio básico en el que guarecerse. Además, el agua le arruinó algunas de las primeras construcciones que tenía a medio hacer y las tuvo que volver a comenzar. Luego llegó noviembre y el tiempo se puso feo. Fue necesario apurar el trabajo y comenzar a trabajar de sol a sol.

Las primeras lluvias de octubre hicieron pensar a la hormiga que algo podría salir mal y decidió probar si el trabajo hecho les sería útil. Comenzó a llenar con grano el nuevo hormiguero y pronto se dio cuenta que el agujero de entrada era demasiado pequeño para entrar con hojas grandes y que debía elevarlo un poco más si quería evitar que entrase el agua o el barro por él. Fue necesario parar el trabajo para arreglar esto.

El invierno llegó pronto también ese año para la hormiga que se dio cuenta de que no tendría tiempo suficiente para construir la última de las estancias, así que decidió hacer en su lugar una entrada adicional por si una piedra o un enemigo bloqueaba la principal.

A la cigarra, en cambio, el mal tiempo la pilló desprevenida. No sabía muy bien qué estaba terminado y qué no. Lo que se había dado por terminado no había sido usado en todo ese tiempo y ahora no había tiempo para mejorarlo si había que corregir algo. El invierno había llegado y no se podía seguir trabajando.

En su nuevo refugio, bajo las goteras, la cigarra se prometió a sí misma que esto no le volvería a pasar: El año que viene trabajaré el doble de horas que la hormiga, se dijo.

¿Debe el jefe de proyecto haber sido antes un técnico?

Suele haber cierto debate sobre si un jefe de proyecto debe conocer con profundidad lo que se está cociendo en su proyecto o si basta con que tenga muy buenas habilidades de negociación, planificación y gestión de recursos ¿debe haber sido antes un buen técnico en su campo o es suficiente con que tenga una cierta idea del trabajo y se deje asesorar por su equipo?

Pocas veces tenemos en una misma persona todas esas cualidades, tener un alto conocimiento de las técnicas de su campo y a la vez contar con grandes habilidades para el trato con clientes y equipo de trabajo siendo capaces de llegar a un buen acuerdo incluso en las condiciones más difíciles.

Sin menospreciar el conjunto de soft-skills necesario para ser un buen negociador, yo me inclino personalmente por el jefe de proyecto que antes ha sido un buen técnico y que es capaz de entender lo que le están explicando sus técnicos ¿cómo si no va a tomar decisiones acertadas sobre lo que se debe hacer o el camino a tomar?

Además, no basta con que el jefe exija el cumplimiento de cronogramas y plazos a su equipo sino que es muy útil también que sea capaz de enseñar cómo hacerlo. Ser capaz de guiar y concretar las tareas a realizar va a ayudar que se consiga finalizarlas antes. Consigue más quién más concreta y consigue más quién más revisa lo concretado (Gabriel Ginebra)

Thomas J Watson vendedor de cajas registradoras que terminó fundando IBM, cuenta que en sus inicios como vendedor, después de una semana recorriendo con un caballo cargado de cajas registradoras las granjas de toda su zona, le contó a su jefe su pésimo resultado como vendedor: No consiguió una sola venta.

En lugar de echarle una bronca o despedirlo, su jefe le explicó en qué fallaba su discurso de ventas, le contó como hacerlo mejor y le acompañó en la carretera a cada una de las ventas para mostrarle personalmente cómo hacerlo. Watson no salía de su asombro, cada una de las visitas en las que participaba su jefe terminaba en un acuerdo de venta. Gracias a la labor como mentor de su jefe Watson llegó a ser el máximo vendedor de su área. Merece la pena contar con un jefe que conoce bien su trabajo ¿no?

Referencias:
The Mythical Man-month – The Other Face – What documentation is required

Si te interesa saber más sobre la certificación, estimaciones, ventajas y desventajas de Scrum o cómo gestionar proyectos de forma ágil quizás te interese mi libro: Gestión práctica de proyectos con Scrum.

Si en cambio quieres poner a prueba tus conocimientos de Scrum haciendo un test en español antes de tomar el examen de scrum.org aquí tienes el Test no oficial de Scrum (aplicación realizada con Ruby on Rails y desplegada en Heroku).

Primero un paso y luego el otro

¿Cómo se llega a tener equipos de trabajo productivos y procesos eficientes? Pues supongo que como muchas otras cosas en la vida, dando un paso primero, luego otro, y aún otro más. No conozco la respuesta exacta a preguntas como esa, yo mismo me la hago. De lo que sí estoy seguro es que no se consigue intentado abarcar todo al mismo tiempo.

En muchas ocasiones, cuando nos dan una pequeña responsabilidad, en nuestro afán por querer hacer las cosas bien intentamos aplicar todas las buenas prácticas que conocemos y deslumbrar con nuestro buen hacer. Esto suele ser receta segura para el fracaso ¿estás preparado tú y tu equipo para llevar a cabo todo lo que
prometiste? ¿lo has hecho antes? ¿cómo sabes que puedes cumplirlo?

Tomar un montón de medidas al mismo tiempo sin esperar a ver los resultados positivos o negativos de cada una de ellas no te va a permitir saber qué funcionó y qué no o qué debe mejorarse. Las cosas sucederán en tu proyecto, para bien o para mal, pero no sabrás muy bien qué las produjo, o qué efecto tuvieron.

Cambiar de golpe todos y cada uno de los hábitos que existían hasta ese momento en un proyecto puede causar una sensación de confusión al equipo de trabajo que no tendrá tiempo de asimilar todos los cambios que has propuesto. Las nuevas medidas podrían terminar aplicándose mal o a medias, generar el rechazo de los compañeros de trabajo y descartarse porque no tuvieron la dedicación y el esfuerzo necesario para ver sus resultados. Además, incorporar a tu proyecto un montón de nuevas prácticas, herramientas y métodos de trabajo podría crear falsas expectativas sobre lo que vas a
hacer que posiblemente luego no puedas cumplir.

Asegúrate de que cumples los cuatro principios básicos de tu profesión antes de incorporar tecnologías innovadoras. Una vez los cumplas, añade una práctica nueva al nuevo proyecto que vas a comenzar. Si es posible hazlo en un proyecto pequeño y abordable. Ya se sabe, los experimentos con gaseosa (aplicar nuevas técnicas además de tener un coste también tiene un riesgo)

¿Ha funcionado? ¿ha ayudado a bajar los costes o mejorado la calidad? ¿seguro? ¿lo puedes demostrar? Si es así, ya tienes una nueva práctica en tu repertorio. Ahora, a por la siguiente.

¿No funcionó? Pruébalo, equivócate otra vez, equivócate de una mejor forma (Samuel Becket)

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad