archivo

Archivos diarios: diciembre 22, 2011

Desde mi punto de vista este antipatrón no tiene un nombre adecuado, ya que productividad es la capacidad de hacer más trabajo efectivo (que sirva) por unidad de tiempo, estando asociado a la eficiencia (capacidad de hacer más con menos).

El nombre que debería tener este patrón es ejecución a toda costa o lo que es lo mismo, conseguir avance en el proyecto como sea, independientemente de que esto sea a costa de la calidad del desarrollo, de tener que tirar para adelante, tomando decisiones que no corresponden al que las toma y de una condiciones de trabajo aceptables para el desarrollador (overtime, presión, aceptar decisiones sobre los trabajos que se saben que afecta al correcto desempeño del mismo y del producto, etc…).

Otro posible nombre, que podría ser complementario al anterior, es beneficio a toda costa, que incluye otras decisiones nefastas como utilizar en el proyecto personas que en cuanto a conocimientos y experiencia no son lo que necesita, quitar miembros del equipo en mitad del desarrollo o sustituirlos por perfiles más bajos, reducir el tiempo dedicado al testing, quitar funcionalidad de manera unilateral, etc…

Desgraciadamente, es otro antipatrón que se repite con demasiada frecuencia y otro culpable más de la crisis del software.

También olvidan los que aplican este antipatrón que tal vez en un proyecto consigan su objetivo, pero no se puede mantener una fidelización de los clientes con unas políticas tan nefastas hacia los mismos.

Los equipos de proyecto y, en general, los equipos de trabajo, hasta cierto punto deben funcionar de forma autónoma, utilizando como patrón de funcionamiento los procesos implantados en la organización, la metodología de desarrollo y cualquier acuerdo específico alcanzado para la realización del proyecto.

Ahora bien, existen determinadas decisiones que deben recaer sobre aquellas personas en las que se le ha delegado una determinada competencia y que no se deben diluir por inacción en el equipo de proyecto porque al final esto se volverá en contra de dicho equipo.

También existen determinadas circunstancias donde el responsable máximo del proyecto o el responsable de un equipo de trabajo tiene que intervenir, ya sea para poner un poco de orden, cuando éste se pierde, para reconducir situaciones no beneficiosas para el proyecto, etc…

El antipatrón lo tenemos cuando dichos responsables no aparecen en el proyecto o no aparecen en momentos clave, es decir, cuando se les necesita casi nunca están. Esta circunstancia hace mucho daño al proyecto, ya que su principal misión es mantener el frágil y complicado equilibrio entre todos los stakeholders y entre las personas que conforman un determinado equipo de trabajo.

Cuanto más grande sea la grieta creada por su ausencia, más complicado será reconducir el proyecto a una situación de equilibrio y si se consigue será a costa de un desgaste y/o un esfuerzo innecesario, si el responsable hubiera hecho lo que tenía que hacer.