h1

97 Things Every Project Manager Should Know

08/01/2011

Wizbook [Icon By Buuf]  Libros: Project Management.

Los planes sólo son buenas intenciones a menos que se conviertan inmediatamente en trabajo arduo.

— Peter Drucker (1909 – 2005). Escritor, profesor y consultor gerencial austriaco.

Hace algunos días terminé de leer 97 Things Every Project Manager Should Know de la editorial O’Reilly. Con formato parecido a un compendio de tips y trucos, este libro nos proporciona algunos consejos que podemos seguir en aquellos proyectos que tendremos bajo nuestra responsabilidad. Desde lo básico como “Involucra a tus usuarios tan pronto como sea posible” hasta aquello menos aparente como “Usa un wiki”, esta publicación nos recuerda algunos aspectos que en muchas ocasiones se nos escapan o simplemente ni siquiera tomamos en cuenta cuando somos administradores de proyectos o scrum masters. Cada consejo es proporcionado por expertos en la industria, casi todos ellos certificados como Project Manager Professionals, por lo que podemos considerar las ideas presentes en el libro como válidas. A continuación incluyo algunas de las mejores que encontré en el documento:

• No te saltes las vacaciones por el proyecto. ¿Cuántos administradores de proyecto novatos no han cancelado o aplazado sus vacaciones por darle continuidad al proyecto? Muchos de nosotros recordamos amargamente cómo dejamos ir ese viaje a Cancún por tener que “picar piedras”, pero muy pocos recordamos cuáles eran los problemas específicos por los que debimos quedarnos desde un principio. Por ello, siempre es conveniente planear con anticipación quién puede reemplazarnos por una o dos semanas; ya sea entrenando a alguien del equipo mismo para que tome las riendas del proyecto o traer un “bateador emergente” durante nuestra ausencia. Al utilizar metodologías ágiles esto es incluso más fácil, ya que uno de los principios de estas metodologías es el concepto de equipos auto-administrados: si el equipo conoce bien la metodología, ellos mismos se organizarán para terminar todos los entregables definidos en el backlog. Tal vez sí se requiera de alguien con un poco más de experiencia para realizar tareas muy específicas – como orientar a los demás en aspectos de planeación de la iteración – pero en términos generales, el equipo deberá poder continuar sin necesidad de un chicotito. Como el autor elocuentemente describe, es recomendable estar disponible cuando se lleve a cabo un release, pero definitivamente hay que tomarse un tiempo libre y nunca cancelar unas vacaciones sólo porque pensamos que el proyecto se detendrá sin nosotros.

Picando Piedra

Por mucho que amemos ponernos la camiseta, es necesario pensar en nosotros mismos. Ciertamente, ningún empleador nos regañará por no tomar vacaciones. (Fuente: perrymarshall.com)

• Dar empowerment a los desarrolladores: un hombre llamado Tim. El tip comienza con una anécdota, relacionada a un desarrollador llamado Tim. Según el cuento, el narrador era el project manager (PM) asignado, y estaba buscando recursos. Entre los candidatos internos de la compañía se cruzó con el perfil de Tim, quien sobresalía en todos los aspectos. Sin embargo, al revisar sus referencias con otros PMs, uno de ellos comentaba que “le faltaba motivación”: generalmente se le encontraba surfeando o “echando la weba”. Después de un pequeño debate, el narrador se decidió por traer a Tim a bordo, como parte de un equipo de desarrollo ágil. Una vez ahí se dieron cuenta que aquél era una contratación excepcional, pues de acuerdo a la metodología, una vez que alguien del equipo terminaba un entregable, podría tomar otro elemento del backlog para ayudar a sus compañeros. Así, Tim terminaba mucho antes de lo planeado, tomando más tareas del backlog que los demás y finalizando la iteración antes de lo anticipado. Entonces ¿por qué aquél PM consideraba a Tim como improductivo? Resulta que trabajaba a la vieja usanza de asignar tareas a cada desarrollador. Naturalmente, Tim terminaba sus tareas rápidamente y como el PM no le asignaba más actividades, Tim se dedicaba a “rascarse la panza”. ¿La moraleja del cuento? Si el equipo tiene una visión clara de lo que hay que entregar, criterios de aceptación bien definidos y prioridades del proyecto compartidas por todo el equipo, lo mejor que puede hacer un PM es simplemente quitarse de en medio.

• Incrementa la comunicación: mantén reuniones frecuentes e instantáneas. Un mal de muchas empresas consiste en caer en la trampa de largas y pesadas reuniones, donde uno no hace nada más que esperar su turno para explicar un par de slides en una presentación de PowerPoint. En vez de arruinar una hora de productividad de todo el mundo, es mucho más conveniente tener pequeñas, acotadas reuniones donde en un par de minutos, cada uno de los integrantes reporte qué han hecho recientemente, en qué están trabajando en este momento y dónde necesitan ayuda. La ayuda no se presta durante la reunión, sino después. De acuerdo al autor, sus juntas no toman más allá de 13 minutos para un grupo de 60 personas; dudo que esto sea del todo cierto pero al menos en equipos de 6 a 10 personas esto puede ser una gran ayuda para no “pisarnos los callos” mutuamente.

• Adelante, deja esa práctica fuera. ¿Qué hacen los equipos exitosos que otros no? Constantemente ponen en duda sus propias prácticas y tienden a eliminar aquellas que no funcionan. Aquellos equipos refactorizan sus procesos a la par del desarrollo de software. Un buen PM debe tener una idea general de cómo trabaja el equipo de trabajo, evaluando cómo es que cada proceso impacta al rendimiento del mismo. Un ejemplo tomado fuera del libro, como experiencia personal es el siguiente: en conocida institución bancaria, todo desarrollo se lleva a cabo a través de un rígido proceso basado en RUP. No debe quedar nada fuera: documentos, diagramas, código fuente explicado al detalle, pruebas de acoplamiento, de desempeño, de usuario, de integración, así como la ejecución de estas pruebas detalladamente descrita. ¿El resultado? No ha mejorado la calidad de los entregables porque el 80% del tiempo se dedica a documentar dichos entregables, dejando como algo secundario el código entregado. Por cierto, la tasa de proyectos fallidos en dicha institución, con todo y que han traído consultores desde Estados Unidos ronda el 90%. Como bien dice el autor de este tip, “menos es más” es una muy importante filosofía cuando de procesos se trata.

• El éxito siempre se mide por el valor de negocio. Muchos PMs creen que su trabajo consiste solamente en tener el software terminado, sin darse cuenta de la necesidad de negocio que viene detrás. Sin embargo, el éxito o fracaso de un proyecto, desde el punto de vista del cliente, no tiene tanto que ver con el cuarteto “tiempo-costo-alcance-calidad”, sino con el retorno de inversión y qué problema u oportunidad se está atacando con el software desarrollado. Motivar al equipo o tomar decisiones “al vuelo” se vuelven mucho más fáciles cuando entendemos cómo es que la terminación de este proyecto debe beneficiar a la compañía. En estos casos, el PM debe aprender a preguntar, estar alerta y saber qué tiene prioridad en el proyecto: ya sea tiempo, dinero o calidad pueden ser los factores clave; al tener la respuesta, se pueden preparar soluciones alternativas o reservas de contingencia para mantener al proyecto alineado con la razón de negocio por la que fue creado. En algunas metodologías ágiles existe una persona específicamente dedicada a esto – como el Product Owner en Scrum – quien define al principio de cada iteración qué actividades tienen prioridad de acuerdo al máximo valor de negocio esperado.

Conclusiones

Sin ser una lectura que nos revele “la verdad de la vida”, considero prudente leer este libro en aquellos ratos libres para entender un poco del mundo de la administración de proyectos y cómo pueden llevarse a mejor término desde el punto de vista no técnico. También permite darse cuenta que aquellas metodologías basadas en el modelo de cascada ya son obsoletas, y que al menos en cuanto a la industria del software se refiere, hay que buscar una mejora continua en los procesos de desarrollo y gestión para alcanzar resultados de manera eficaz. Los consejos que incluí son justamente relacionados a la gestión ágil de proyectos, pues es la manera de llevar proyectos que me ha dado mayores resultados, desde mi propio punto de vista. Citando al mismísimo Charles Darwin, padre de la síntesis evolutiva moderna:

No es la más fuerte de las especies la que sobrevive, ni la más inteligente. Es aquella que es más adaptable al cambio.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: