archivo

Archivos Mensuales: julio 2011

Cuando un cliente pierde la confianza en el proveedor o viceversa, el equipo de proyecto pierde la confianza en la persona que los coordina o al revés o unos compañeros pierden la confianza en otros, todo es mucho más difícil, cuando no imposible (no digo que no se puedan llevar a cabo los trabajos encomendados, pero sí que resultará muy complicado cumplir con unos objetivos de calidad aceptable: cumplimiento de expectativas de usuario, presupuesto y plazos).

Las personas son lo más importante en los proyectos de desarrollo de software, si las relaciones entre las que participan en el mismo no se basan en la confianza se perderá el dinamismo y el efecto es similar a cuando piezas que rozan no están engrasadas.

La confianza es algo muy frágil. Se tarda mucho en afianzarla y una acción para destruirla. La capacidad de recuperarla o de mantenerla dependerá de tus acciones anteriores y de las relaciones personales y profesionales que se hayan forjado con el paso del tiempo.

Nuestra productividad alta o baja no tiene efectos exclusivamente sobre nosotros mismos, sino que también tiene un efecto a nuestro alrededor, de la misma forma que la de los demás también influye en nosotros.

Se suele trabajar en equipo y cuando alguien falla o destaca inevitablemente tiene efectos sobre los demás.

Cada uno de nosotros tiene una capacidad de empuje, una motivación, un nivel de resiliencia, una experiencia, unos conocimientos, una técnica y podemos ser más o menos ajenos a lo que pasa en nuestro proyecto y mantener durante más tiempo nuestra regularidad, sin embargo resulta a largo plazo poder mantener un nivel aceptable de productividad cuando la teoría de las ventanas rotas se ha instaurado en nuestro contexto laboral y la improductividad solo trae más improductividad.

También será complicado que no mejoremos si los hábitos y la capacidad de nuestro entorno son favorables.

Estas características provocan que las caídas o subidas de productividad en un departamento o en una organización sean muy sensibles, ya que tiene influencia no solo sobre personas concretas, sino en equipos de trabajo completos. Es necesario, por tanto, darle al capital humano el valor que se merece.

Las organizaciones para ser competitivas deben estar orientadas a la productividad, poniendo los medios adecuados para poder evaluarla y no dejando su valoración en percepciones personales y subjetivas.

Productividad no es aumentar la carga de trabajo sin más, sino sacar el mayor rendimiento posible de las personas. Se obtienen mejores resultados, aumentando la motivación, que a través del overtime o de la asignación de una carga de trabajo superior a la que que se puede afrontar en una jornada laboral normal (incluso siendo muy productivo).

Comenta Ed Yourdon que independientemente de que existan circunstancias que te empujen irremediablemente a un Death March Project (decisiones de empresa ya sea por la parte cliente o proveedora), en muchas ocasiones se aceptan condiciones que podrían haber sido evitadas o, al menos, paliadas con la existencia de una negociación bien llevada.

El desarrollo de software no solo requiere habilidad técnica, es algo que sabemos todos y que comento con relativa frecuencia en mi blog, sino que son muchas variables las que intervienen para que un proyecto de desarrollo de software, una empresa o una organización tengan éxito.

Una persona no tiene por qué reunir todos esos ingredientes, estamos hablando de que el desarrollo de software es un trabajo en equipo y que va más allá del ámbito del proyecto. Lo importante es que la suma de los ingredientes que proporcionan las personas permitan hacer una buena receta.

La negociación es una habilidad. Hay personas que de manera innata lo hacen muy bien, sin embargo, además de ese instinto, cuanta mucho la técnica y sobre todo la experiencia.

Es cierto que una negociación influye mucho tu posición en la misma, ya que a veces se juega con las cartas marcadas, pero incluso en las circunstancias más adversas se pueden conseguir logros.

Si el cliente queda satisfecho en un proyecto de desarrollo de software es más que probable que termine hablando de tu organización con otros posibles clientes o que incluso no te ponga problemas para hablar con otros si lo quieres utilizar como referencia.

De hecho si tienes la posibilidad de hacerlo y no lo haces estás perdiendo una importante herramienta comercial a tu favor porque salvo que el posible cliente con el que quieres contratar tenga ya una relación de confianza contigo o con tu organización, creerá más lo que le diga la referencia que cualquier cosa que le cuentes.

Hay que tener en cuenta que realizar servicios de desarrollo de software lo pueden hacer muchos, sin embargo, que cumplan las expectativas del cliente con un nivel de desgaste en las relaciones tolerable, bastantes menos.

Desarrollar software de calidad atrae clientes, no hacerlo los espanta. Lo mismo has conseguido salvar el proyecto con éxito desde el punto de vista económico, pero lo mismo te has cerrado puertas que no se volverán a abrir.

Lewis D. Eigen es autor, articulista, con experiencia docente y de investigación en el ámbito universitario y también como consultor y responsable de empresas en el ámbito privado.

Este autor realiza la siguiente reflexión la cual, desde mi punto de vista, es cada vez es más real, independientemente de que sintamos o no que esa división existe o que le demos una visión más o menos conspiranoica: “Los trabajadores y profesionales del mundo pronto se dividirán en dos grupos. Aquellos que controlarán los ordenadores y aquellos que serán controlados por ordenadores. Lo mejor para ti será estar en el grupo adecuado”.

Comenta Ed Yourdon que la mejor manera de evitar un Death March Project es no participando en esa locura.

Básicamente lo que viene a decir Yourdon es que poca solución hay cuando las condiciones para la realización del proyecto no son realistas.

Lo peor de todo esto es que la mayoría de la gente que sufre este tipo de proyectos (por parte del proveedor) no son los que han tomado la decisión de participar en él. Probablemente si ellos sufrieran en primera persona la frustración de tener que trabajar innumerables horas, con un desgaste considerable en las relaciones con los que te rodean (dentro y fuera del trabajo) para obtener unos resultados inciertos (por decir algo), se lo pensarían más de una vez.

Esta falta de empatía con tus equipos de trabajo o ese exceso de ambición puede llevar a estas situaciones que, además, pueden terminar volviéndose en su contra porque si el proyecto va mal salpica a todos. Lo que pasa es que en demasiadas ocasiones los culpables no aparecen o ya están lo suficientemente lejos como para que les afecte.

Dave Barry es un autor americano especializado en humor y comedia que ha desarrollado una buena parte de su trayectoria profesional como columnista en el Miami Herald, además ha escrito numerosos libros. Su prestigio es tal que ha sido ganador de un premio Pulitzer.

Entre sus citas sobre el mundo del software y de la computación, destaca la siguiente, que puede resultar interesante de destacar, teniendo en cuenta que ha sido realizada por alguien ajeno a nuestro negocio (traducción libre): “El software viene acompañado normalmente por documentación en forma de grandes y monstruosos manuales que nadie lee…”.

Vamos a pensar en los manuales de usuario que acompañan a los productos software de nuestros proyectos, ¿qué proporción de usuarios lo han leído?, ¿qué proporción de usuarios lo utilizan?. Si a lo anterior le sumamos lo siguiente, ¿cuál es el nivel de actualización de dichos manuales conforme el producto va evolucionando?, podemos hacernos una idea de si realmente resultan útiles o no.

Soy de la opinión de que manuales debe haber, pero antes de hacer el esfuerzo hay que ser consciente de si la carga de trabajo que va a entrar en manera de evolutivos va a permitir actualizarlos debidamente. También hay que tener en cuenta las características de los usuarios que va a tener la aplicación y la complejidad de la misma. Esto servirá para realizar manuales útiles (aunque se centren es aspectos generales de la aplicación o en aquellos módulos más complejos), realizados con el menor esfuerzo posible y que sobrevivan en lo posible a un contexto de fuerte evolución y adaptación del software.

Hay que recordar que en muchas ocasiones y sobre todo en el campo del desarrollo de software menos es más.