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.

Una vez un compañero mío dijo una frase que me pareció muy esclarecedora y de mucha utilidad, sobre todo para alguien que estaba empezando en este mundillo como era yo.

Vino de decir que el ya tenía el cajón lleno de medallitas y que las únicas recompensas que le resultaban válidas eran las tangibles.

Las personas que leerán este artículo tendrán diferentes años de experiencia en el mundo del desarrollo de software y si han tenido vivencias en proyectos parecidas a las mías o a la de mi compañero probablemente hayan llegado a la conclusión de que las felicitaciones y los premios que realmente valen son los que se pueden tocar o ver en tu cuenta corriente.

Es cierto que hay valores intangibles que resultan importantes como por ejemplo sentirte parte de un proyecto, pero eso no es un premio por tu trabajo sino que eso es un premio que te das a ti mismo y una demostración de que tu organización ha sabido acertar en crear ese ambiente. Otros valor intangible importante es sentirte valorado, lo que pasa es que cuando esa valoración no se plasma en hechos al final te sientes como un reloj caro en un escaparate y que nadie compra, con la sensación de que pasarás de moda y te venderán a precio de saldo.

La ilusión y las ganas nos hace considerar que determinadas tareas o proyectos son más sencillos de los que son realmente. Nuestras aspiraciones, nuestro deseo por cumplir objetivos personales y profesionales nos hace bajar el listón y aceptar o enfocar proyectos con presupuestos, recursos o plazos inalcanzables.

Las decisiones que se toman a la ligera o llenos de adrenalina pueden ocasionarnos muchos problemas de los que nos resultará complicado salir.

No decir que no, no matizar, no sugerir otros enfoques, nos puede llevar directamente a un Death March Project.

Es cierto que con ganas, ilusión, motivación, conocimientos, experiencia, se pueden conseguir superar muchos obstáculos e incluso hacer posibles muchos imposibles, pero hay que tener en cuenta que los proyectos se realizan en equipo y lo que tú puedes sentir por un proyecto o por una tarea no tiene por qué coincidir con la de tus compañeros. Nuestros sentimientos nos hacen olvidar a menudo que no somos los únicos que tenemos que remar para que todo salga adelante.

Boris Beizer es un autor e ingeniero de software americano (aunque nacido en Bélgica) especializado en el campo de la calidad del software y del testing. Sus primeras publicaciones datan de finales de la década de los cincuenta, aunque su etapa más prolífica fue en las décadas de los setenta y de los ochenta.

El testing es un campo dentro de la ingeniería del software un tanto controvertido. La mayoría de los profesionales consideramos necesarias las pruebas en el proyecto de desarrollo de software, si bien no hay coincidencia en cuanto a la intensidad, los momentos y la metodología.

Soy de la opinión de que no todos los proyectos y sistemas de información deben tener un mismo tratamiento y que independientemente de que exista una cierta metodología en las pruebas, estas deben girar alrededor del testing ágil y del exploratorio.

También soy partidario de que las clases con mayor acoplamiento sean cubiertas mediante pruebas unitarias (no necesariamente desarrollando según técnicas de desarrollo guiadas por las pruebas (TDD)) y que se deben minimizar los efectos colaterales a través de las pruebas de regresión.

En cuanto a los momentos, el testing debe aplicarse desde las etapas más tempranas del software, si bien los actores pueden ser distintos a las pruebas realizadas sobre el producto.

Y como estrategia, la utilización de integración continua permite detectar problemas de carácter unitario y de integración lo antes posible y a reducir los problemas en la fase de implantación.

Boris Beizer realiza la siguiente reflexión (traducción libre): “Una amenaza bien vale mil pruebas”.

Desgraciadamente nos acordamos de un proceso de testing bien realizado cuando ya los errores han salido a la luz y lo peor de eso, cuando su corrección requiere de un esfuerzo considerable, cuando ha impactado gravemente en el negocio o cuando nos crea un problema.

Cuando mayor sea la criticidad del sistema más peso debe tener el proceso de testing y más peso debe cobrar la metodología y sistematización.