Manifiesto ágil: Personas sobre procedimientos

Uno de los valores del manifiesto ágil es valorar "Individuos e interacciones sobre procesos y herramientas". Este es posiblemente el más importante de todos ellos y quizás, el que menos en cuenta se tiene cuando se intenta implantar una metodología ágil. No por la parte de "interacciones", ya que cosas como programación en parejas, los daily scrum meeting, y demás tipos de interacciones sí se tienen muy en cuenta, sino por la parte de "individuos".

Según mi experiencia, precisamente la parte de "individuos" es la más importante de todas y sin ella, todo lo demás se va al garete.

Con la parte de individuos se quiere decir gente preparada y adecuadamente motivada, es decir, gente que sabe hacer bien su trabajo y que tiene ganas de hacerlo. Y eso es lo realmente importante. Si la gente no es técnicamente adecuada o no tiene ganas de hacer las cosas, da igual que hagan o no reuniones diarias, que trabajen en parejas, que se les den herramientas o que interaccionen con el cliente: el trabajo no sale bien.

Y eso es algo que estoy viendo continuamente en el trabajo. Según qué personas caigan en qué proyectos, estos pueden ir bien o mal, incluso aplicando la misma metodología con las mismas herramientas.

Así, hay proyectos que cuando llegan a los programadores están totalmente sin definir, no se sabe muy bien qué es lo que hay que hacer en ese proyecto, qué es lo que quiere el cliente y ni siquiera se sabe cuales son los requisitos. Mientras, otros proyectos llegan a los programadores bastante bien definidos, con una idea clara de lo que hay que hacer (aunque luego cambie) y llega con algo de documentación en condiciones, al menos, para las partes con más incertidumbre. Casualmente, las personas responsables de proyecto suelen coincidir en los casos que llega o no llega el proyecto definido. Si el responsable es "Fulanito", su proyecto llega bien definido. Si es "Menganito", no se sabe qué hay que hacer en ese proyecto.

Luego, entre los programadores, siempre hay módulos que llegan en plazo más o menos bien y sin demasiados problemas, incluso aunque esa parte no esté bien definida. Otros módulos, llegan mal y con muchos problemas, aunque estén bien definidas. Casualmente, las partes que llegan bien suelen estar hechas siempre por las mismas personas y las que dan muchos problemas, por otras. Un programador bueno técnicamente, con iniciativa y bien motivado, cuando le llega un algo para hacer mal definido, empieza a dar la paliza al responsable del proyecto para enterarse qué tiene que hacer, hace sus propias propuestas si no lo consigue, hace su código bien hecho y fácilmente modificable y finalmente entrega algo que funciona y que sirve para lo que quiere el jefe, incluso aunque el jefe no sabía qué quería. Un mal programador, sin iniciativa y sin motivación, cuando le llega una cosa sin definir, no hace nada salvo protestar y se entretiene con internet o con otra cosa. Al final, cuando la cosa corre prisa, hace lo que le puede deprisa y corriendo, lo hace mal porque técnicamente tampoco es bueno y el proyecto tiene problemas y se retrasa.

Obviamente, no debería llegar a los programadores cosas sin definir, pero aquí puedes ver que aunque el procedimiento y las herramientas sean las mismas, si se junta un mal jefe de proyecto con malos programadores, el proyecto va de culo, mientras que si se junta un buen jefe de proyecto con buenos programadores, ese proyecto suele ir de cine.

Cuando fallan las personas en una de las dos partes, la otra puede "arreglar" la situación. Ante un jefe de proyecto incompetente, los buenos programadores acaban prácticamente definiendo y llevando ellos el proyecto. Ante unos programadores incompetentes, un buen jefe de proyecto lleva mucha supervisión, define mucho las cosas, prueba mucho y sabe sacar lo máximo posible de los programadores que le han tocado.

Y todo esto es real, es lo que voy viendo en varios años de trabajar en proyectos con bastante gente, tanto de currito como llevando programadores.

Entradas relacionadas:

Esta entrada ha sido publicada en metodologías, trabajo y etiquetada como , , . Guarda el enlace permanente.

6 respuestas a Manifiesto ágil: Personas sobre procedimientos

  1. Blaxter dijo:

    Está claro, si alguien es un paquete, hace las cosas mal; y si es pr0, hace las cosas bien. xD

  2. eynob dijo:

    Muy bueno como lo expresas, estoy totalmente de acuerdo y he vivido ambos casos personalmente

  3. rodrigo dijo:

    La motivación. En tu artículo hablas de la motivación, y en mi opinión esa palabra es muy importante para que un proyecto salga bien, pero la motivación de todo el equipo, desde el jefe de proyecto hasta el programador que acaba de empezar. Ahí es donde hay que trabajar mucho y en general se descuida bastante. Se piensa, te contrato y ya está tienes que rendir al 120 % simplemente porque estás en mi empresa que es la mejor del mundo. Y eso no es tan sencillo.
    Motivar al jefe de proyecto lo tiene que hacer alguien de más arriba, pero el jefe de proyecto debe conocer a las personas que están debajo y sus necesidades, y a partir de ahí intentar mejorar en todo lo posible las condiciones de su trabajo pero no para todos de igual forma sino persona a persona en función de lo que dicho jefe de proyecto cree que es más conveniente. Y ahí también entra la empresa, que normalmente no da facilidades al jefe de proyecto.

    En fin no me alargo, pero creo que la motivación es muy importante y es un tema muy delicado el cual debemos tratar continuamente.

    Saludos chuidiang

  4. navarros dijo:

    Desde mi experiencia todo es importante las personas, la motivación, la definición del trabajo y el método. Así en principio es una perogrullada pero no es tan fácil de conseguir….o sí.

    Afortunadamente todo esta muy relacionado.

    Las personas que forman una compañía (a parte de la contratación que solo es el paso burocrático) creen en la filosofía y modo de trabajo de la compañía, valores y visión. Si no como estamos viendo en el sector, la gente se cambia de empresa en 3-6 meses.
    Por tanto una empresa donde se valora a las personas y su preparación reune un conjunto de gente con esos mismos valores (y por tanto preparados).

    El encontrarte con un conjunto de personas con similares prespectivas del trabajo refuerza el sentimiento de grupo con lo que se integran haciendo equipos muy eficientes. El ser capaz de realizar grandes avances en poco tiempo es una gran motivación con un alto grado de retroalimentación.

    Una empresa con los valores en las personas, cree en su capacidad y respeta su conocimiento por lo que no implanta metodologías «guiados» sino más ligeros o ágiles (SCRUM, Lean, XP).

    Estas metodologías se basan en el principio de que nada puede ser perfecto en su inicio sino por aproximaciones sucesivas y en que nada es invariable en el tiempo. De este modo la definición del problema se realiza de forma continua durante el proyecto y se depura hasta ser conciso y claro.

    Por tanto el «quiz» de la cuestión es que los valores y acciones de la empresa deben ser coherentes con el resultado que desea obtener.

    «Quien siega vientos recoge tempestades» Dicho popular

  5. navarros dijo:

    ..Correción..
    «quien SIEMBRA vientos recoge tempestades» Dicho popular

  6. Pingback: Diario de Programación » Blog Archive » Métricas: A veces el remedio es peor que la enfermedad

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.