Chess - antoniomartel.com

Archivos de Autor: antoniomartel

¿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)

Cómo hacer que las estimaciones digan lo que quieras

Tu cliente te ha pedido una estimación. Tiene una idea en la cabeza y quiere saber cuánto le costará y en cuanto tiempo lo tendrá. Él ha hecho sus propios cálculos y te comenta brevemente las cifras que tiene en la cabeza.

Llegas a la oficina y te reúnes con los técnicos más expertos en este tipo de proyectos. Después de darle unas cuantas vueltas llegas a un acuerdo con ellos sobre el tiempo y la dificultad en realizar este tipo de trabajo. Has tenido que convencerlos un poco para que no sean tan precavidos, después de todo no parece un proyecto difícil.

Aún así la cifra obtenida es muy superior a lo que el cliente había previsto. Además, si esa previsión fuese cierta no podrían cumplirse las fechas en las que se necesita el proyecto terminado. Necesitarás reducir esta estimación en al menos un 50%. Aquí tienes cómo hacerlo en 5 fáciles pasos:

  1. Ya lo has hecho antes. Ahora vas a tardar menos. Has hecho proyectos parecidos en otras ocasiones, seguro que se ha aprendido de los errores cometidos y los problemas que surgieron en otras ocasiones no tienen por qué pasar ahora (10% menos) ¿seguro que no ocurrirán otros problemas nuevos?
  2. El cliente ha dicho que quiere algo sencillo. No será tan difícil de hacer. Podremos hacer algo básico eliminando complejidades (10% menos). El cliente conoce bien su negocio y le parece fácil pero ¿y tú? ¿tienes todo el conocimiento del negocio del cliente?
  3. Vigilaremos mucho los costes. En otras ocasiones el proyecto no se ha supervisado correctamente pero esta vez estarás especialmente atento a cada hora empleada y no dejarás que se te vaya de las manos (10% menos)
  4. Pondremos a los mejores técnicos. Es un proyecto relevante para un cliente importante. Habrá que asignar a los mejores técnicos para el trabajo (10% menos) aunque aún no sabes si estarán disponibles en las fechas que los necesitas.
  5. Se hará un esfuerzo extra. Si fuese necesario y comprobásemos que no podemos cumplir con el tiempo previsto se pedirá a todos los implicados que hagan un esfuerzo adicional durante unas semanas. Si fuese necesario añadiremos incluso algún técnico adicional a mitad del proyecto para así acabar en plazos. (10% menos) Recuerda la Ley de Brooks: ‘Añadir personal a un proyecto retrasado sólo hará que se retrase aún más

Ya lo tenemos. Con solo un poco de trabajo hemos conseguido reducir la estimación inicial en un 50%. En realidad, para hacer que la estimación encaje en un presupuesto, nos hemos autoconvencido de que podemos hacer el trabajo en la mitad de tiempo. Lamentablemente las estadísticas muestran que los proyectos software tardan, en promedio, un 120% más del tiempo previsto inicialmente y que el costo final resulta ser un 100% más elevado que el que se calculó en la primera estimación.

Puedes ver más sobre estimaciones en:

Referencias: Estimaciones: errores comunes (Carlos Fontela)

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).

Más vale pedir perdón que pedir permiso

Hace unas semanas Borja Prieto tenía a bien publicarme un post invitado en el blog de desencadenado.com. Algo que le agradezco mucho porque en los tres días siguientes a la publicación las visitas a mi blog se multiplicaron por diez y el número de suscriptores por email se ha duplicado desde entonces. Incluso el tiempo medio por visita es considerablemente más alto incluso ahora, tres semanas después.

En esa entrada comentaba la importancia de tomar la iniciativa y no cruzarse de brazos cuando hay alguna tarea por resolver porque ‘no es mi cometido’, ‘de eso se encarga otro’ o ‘no está en mi contrato’. Pueden leer la entrada en el blog de desencadenado: Más vale pedir perdón que pedir permiso.

Sigo el blog de Borja desde hace mucho tiempo. Si estás pensando montar una empresa o convertirte en un nuevo emprendedor les recomiendo encarecidamente seguir este blog. En él podrán encontrar artículos de interés. Muchos tanto como éstos:

También he asistido a algunos de los webinars de desencadenado.com o comprado alguna de sus píldoras formativas. El estilo directo que utiliza para explicar el asunto sin rodeos hace que merezca mucho la pena cada uno de sus vídeos.

Asfaltar el camino

Quizás porque los proyectos en los que trabajo actualmente no son muy grandes o quizás por simple deformación profesional pero veo que mi trabajo es cada vez menos parecido al de un jefe de proyecto tradicional y más cercano al de un facilitador del trabajo.

Por supuesto que sigo teniendo responsabilidades en el control del coste económico y en la gestión del equipo pero no entiendo esto como la parte más importante de mi trabajo. Suena polémico pero intento explicarme.

En un rol de gestor de proyectos tradicional el jefe de proyecto debía redactar las especificaciones del proyecto, calcular el costo, gestionar el equipo de trabajo, asignarle las tareas y hacer un seguimiento de cada tarea asignada. El equipo de trabajo trabaja para el jefe de proyecto que velará porque se estén cumpliendo los objetivos dentro del coste presupuestado.

En mi caso, en cambio, el 70% de mi trabajo se resume en reunirme cada día durante 15 minutos con los distintos equipos de trabajo para preguntarles qué hicieron ayer, qué se va a hacer hoy y si tienen algún problema que no les permita avanzar. Me anoto en esas reuniones qué tengo que hacer yo para solucionarlo y me paso el resto del día intentando dar una solución a esos problemas (pidiendo información al cliente, revisando una entrega o reclamando una copia de la base de datos)

Como verán, mi trabajo trata de facilitar las cosas al equipo de trabajo asfaltando el camino para que pueda ir más rápido. Trato de conseguir que puedan hacer cada tarea en el menor tiempo posible en lugar de sólo asignar la tarea y medir si el tiempo empleado es mayor del estimado.

Como he mencionado en alguna ocasión, si nos contratan para llevar una carga del punto A al punto B de poco nos servirá saber cuántos pasos hemos dado ya con la carga. ¿No sería más útil ver si estamos en el camino más corto hacia B o en el que menos dificultades hay?