Productividad individual y productividad del equipo de trabajo

Supongamos que diez personas tienen que construir desde cero una máquina. Cada uno puede ser tremendamente productivo a la hora de realizar sus tareas, sin embargo el trabajo del conjunto no tiene porque serlo ya que lo mismo la mayoría de las piezas realizadas no encajan o son incompatibles.

La productividad de un equipo de trabajo o generalizando, de una organización, no solo viene motivada por la productividad individual de cada empleado sino por la capacidad de obtener el máximo provecho posible de esa capacidad, talento y motivación individual dentro de un contexto en el que el todo sea superior que la suma de las partes.

La productividad individual, por tanto, es una parte importante pero no decisiva si la gestión no es buena. Y me centro en la gestión porque determinado tipo de actitudes en un equipo de trabajo son responsabilidad de las personas que la realizan pero también de quien se la consiente.

Es decir, si no hay comunicación, si no hay cooperación a nivel de grupo o de determinadas personas del mismo el gestor debe intentar ponerle solución y no dejarlo ir, ya que este tipo de situaciones al final no solo termina dañando la productividad del equipo sino también las productividades individuales de sus componentes, por lo que el daño es doble.

Desarrollo de software. Steven R. Rakitin. Funcionamiento sobre funcionalidades

Es mejor tener una casa con dos bombillas que funcionen que con diez bombillas fundidas.

Antes de continuar desarrollando funcionalidades en un sistema de información hay que intentar consolidar las funcionalidades ya implementadas. De lo contrario se tiene el riesgo de caer en una situación con demasiados frentes abiertos y en donde se tiene la sensación de estar apagando constantemente fuegos.

Steven Rakitin es un experto en calidad del software con más de treinta años de experiencia en el negocio. En la actualidad es presidente de una consultora de calidad y es miembro de diferentes organismos y asociaciones prestigiosas a nivel internacional y ha sido autor de libros y de numerosos artículos.

Me parece interesante su siguiente reflexión: “Sí, las funcionalidades hacen vender productos, pero solo si funcionan”.

Mejor soluciones simples que funcionen, que sean útiles, que consigan la satisfacción del usuario en los módulos que tengan implementados. Soluciones más complejas con múltiples funcionalidades que no terminan de ir bien, cuestan mucho dinero (hacerlas, mantenerlas y explotarlas), frustran a los usuarios y complican las relaciones cliente/proveedor.

En relación con lo anterior, un producto software satisface al cliente no solo si cumple sus expectativas a nivel funcional y no funcional sino si también funciona (se necesitan ambos ingredientes en la receta).

Desarrollo de software. El gran bazar

Cuántas veces habremos hecho una valoración sobre el coste de un proyecto de desarrollo de software con toda nuestra buena intención, intentando ajustar el presupuesto a la realidad del proyecto y nos hemos encontrado con el responsable de aprobar el mismo y nos ha dicho que le parece excesivo.

A veces resulta descorazonador. Le hemos dado muchas vueltas, metiendo la tijera en lo posible, arrepintiéndonos incluso de haber pulsado el botón enviar para hacerles llegar el presupuesto y después todo resulta caro, como si el software se desarrollase solo, como si no hubiera ninguna circunstancia que pudiera afectar el correcto devenir del proyecto.

Se necesita pedagogía sobre desarrollo de software, se sigue pensando que desarrollar es simplemente cuestión de juntar piezas, muchas piezas, pero que al fin y al cabo como un puzzle y que cuando está terminado el usuario a la primera estará contento con la imagen que representa.

Ojalá el desarrollo de software fuese así, pero no lo es. Un producto software que satisfaga las expectativas de los usuarios necesita de un proceso evolutivo, del feedback de los mismos basado sobre todo en la experiencia de ver el producto funcionando (no necesariamente de forma completa).

Esto no debe ser El Gran Bazar donde se regatea en la compraventa del producto, el software tiene un precio y hay que pagarlo, si no se paga hay que estar dispuesto a soportar los problemas que pueden venir después y a asumir el riesgo que conlleva esto porque tal vez los euros que pretendes ahorrar hoy, son los euros que mañana tendrás que pagar, pero con intereses.

Desarrollo de software. Alistair Cockburn. Las relaciones en el equipo de proyecto

En la entrevista a la que hice referencia en el artículo de ayer, Alistair Cockburn indica que la conclusión final de su investigación fue que lo realmente importante para obtener un buen resultado en un proyecto de desarrollo de software es poner entre cuatro y siete personas que tengan un buen comportamiento con respecto a todos los demás en una misma habitación. Es decir, tomo y como él mismo comenta un equipo de personas que jueguen bien juntos.

En definitiva, Cockburn lo que hace es dar énfasis a la importancia de un trabajo real en equipo, donde todos importan, donde todos aportan.

Es cierto que la experiencia demuestra que no es suficiente con eso para sacar adelante proyectos en muchos casos, si bien supone una variable muy importante.