archivo

Archivo de la etiqueta: Tom DeMarco

Para Tom DeMarco en su libro “Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency” (traducción libre): “Si identificas cualquier proyecto como libre de riesgos, o incluso relativamente libre de riesgo, cancélalo. Vas a necesitar los recursos y el plazo para hacer algo transformacional”.

Desde mi punto de vista, DeMarco trata de poner sobre la mesa la importancia de tener en cuenta los riesgos que se presentan en un proyecto de desarrollo de software y que van más allá de un análisis superficial del mismo.

Claro que hay proyectos con menos riesgos y donde se prevé una cierta estabilidad que facilite la gestión del proyecto, el trabajo de las personas y las relaciones entre los diferentes implicados, pero también lo es que la incertidumbre es una variable inherente en los proyectos de desarrollo de software y que se pueden producir situaciones que en un plazo corto de tiempo requieran hacer adaptaciones y ajustes sobre el proyecto y ahí es donde pueden aparecer problemas que afecten de manera sensible al mismo, entre otras cosas porque no se suele ir muy sobrado ni de presupuesto ni de tiempo y si el producto además se encuentra en producción, la presión que se recibe se incrementa considerablemente.

Es cierto que hay incertidumbre y circunstancias que no son sencillas de ser previstas pero también lo es que sí hay otras que pueden ser previsibles a corto, medio y largo plazo y ahí es donde entra la gestión de riesgos en los proyectos de desarrollo de software, en la capacidad de identificarlos y de tomar medidas o no en función del impacto del riesgo, del coste de las medidas, de la probabilidad de su ocurrencia, etc…

La identificación de riesgos debería comenzar desde incluso la etapa de conceptualización o definición del proyecto porque lo mismo, tras un análisis de los mismos se decide que lo mejor es no realizar el proyecto, buscar otras alternativas, plantearse alcances, presupuestos y plazos más realistas, etc…

Reconocer que nos hemos equivocado o que hemos fracasado siempre es complicado porque por mucho que nos hayamos esforzado supone admitir en público que decisiones que hemos tomado no han sido las adecuadas, que el contexto ha podido con nosotros o que sencillamente no hemos sabido encontrar la solución al problema.

Por muy bueno que te creas o seas, por mucha experiencia que tengas no eres infalible y puedes fracasar y es algo con lo que hay que convivir.

Hay algo peor que fracasar y es continuar con el error cuando ya no hay posibilidades de una vuelta a atrás. Cuanto antes se empiece a poner remedio al problema menor será el daño causado. Huir hacia adelante no suele llevar a ningún sitio, solo a agravar el problema, a cubrirlo (lo que no lo hace desaparecer realmente) o a que pase el tiempo suficiente para que tu marrón le caiga a otro.

Para Tom DeMarco: “Primera ley de la mala gestión: Si algo no funciona, haz más de lo mismo”.

Las personas somos seres de costumbres y parece que nos encanta tropezarnos una y otra vez en la misma piedra. Digo parece porque cuando te has pegado un buen batacazo se te quitan las ganas, por lo menos durante un tiempo, de volver a caer en lo mismo.

Hay una reflexión de Tom DeMarco que ilustra bien este proceso: “La locura es hacer lo mismo esperando un resultado diferente”.

En contextos distintos lo mismo puede producir resultados diferentes pero en un mismo contexto no suele ser así. Además hay soluciones, prácticas o estrategias que no funcionan en prácticamente ningún caso y no es necesario que nos estemos chocando contra las paredes continuamente para comprobarlo.

Por eso soy tan pesado cuando digo que es muy importante que seas autocrítico y no pases de puntillas sobre tus errores, si no aprendes de ellos vas a volver a repetirlos más pronto que tarde.

Todos nos equivocamos, hasta aquel que piensas que nunca se equivoca probablemente se equivoque más que tú, asúmelo y aprende de ello. Hay que pasar por muchos baches para empezar a disfrutar de terreno firme y tendrás que volver a pasar por otros muchos para que el terreno firme dure más tiempo.

Las planificaciones agresivas, muchas de las cuales podrían dar lugar a un Death March Project, no suelen producir buenos resultados porque se sustenta sobre bases irreales.

Si un proyecto no se puede hacer en tres meses da igual que lo dibujes sobre quinientos cronogramas y que metas toda la presión del mundo. Tal vez consigas tener algo funcionando en el período de tiempo fijado pero muy difícilmente lo que se quería inicialmente y probablemente esté lleno de bugs con mayor o menos trascendencia y la calidad de la arquitectura y del código será más que discutible.

Después, en el caso de que se haya conseguido que el sistema de información se utilice (cosa que no será sencilla), nos encontraremos en una situación de crisis continua para ir adecuando al sistema a las expectativas que se tenían en él y para corregir los errores del producto.

Este esfuerzo adicional lo tendrá que pagar alguien (por lo que tendremos una desviación respecto al presupuesto inicial) y termina haciendo mucho daño al equipo de personas que conforman el equipo de proyecto que estarán sometidos a mucha presión y a un overtime que terminará afectando a su motivación y a su productividad y que de extenderse mucho en el tiempo podría provocar que personas muy valiosas empiecen a pensar en otras opciones profesionales.

Sobre este tema, Tom DeMarco realiza la siguiente reflexión: “Los proyectos que traten de cumplir planificaciones agresivas probablemente requieran más tiempo para llevarse a cabo que si se hubieran iniciado con unas planificaciones más razonables”.

Precisamente por este motivo, soy partidario de que salvo una causa muy justificada, sean los que van a desarrollar el producto los que planifiquen.

Tom DeMarco realizó la siguiente reflexión en su libro “The Deadline: A Novel About Project Management” (1997): “El problema de los procesos estándar es que la gente pierde la oportunidad de tomar importantes atajos”.

Cuando los procesos son tan rígidos y parece que lo único importante es cumplir con ellos se pierde la visión de que no se trabaja para el proceso sino para realizar un software de calidad.

Esta visión negativa del autor de lo que supone una gestión balanceada hacia el proceso donde las personas pasan a ser algo con menos importancia ha sido una constante en DeMarco desde que en el año 1987 publicase junto a Timothy Lister el libro “Peopleware: Productive Projects and Teams” que extendió precisamente el concepto de Peopleware en el que sitúa a las personas como elemento principal en el desarrollo de software (el concepto fue utilizado inicialmente por otros autores, datándose su origen en el año 1977).

Es bien sabido que los fundamentos del Manifiesto Ágil son anteriores a su publicación, en el caso de la publicación indicada nos encontramos catorce años antes (y veinticuatro si consideramos el origen del concepto).

Es normal que entonces se tuviera problemas con una orientación a procesos descompensada y desgraciadamente sigue siendo normal ahora, entre otras cosas por la dificultad que tenemos los seres humanos de aprender de nuestros errores y porque en entornos académicos durante muchos años se ha hablado mucho de procesos y poco o nada de las personas.

El proceso debe establecer un marco general de trabajo con la suficiente flexibilidad para permitir una adaptación a los diferentes contexto que nos encontramos en los proyectos de desarrollo de software y a los cambios que se producen en los mismos y se tienen que definir con la finalidad de cumplir una serie de objetivos establecidos por la organización, entre los que nunca estará el propio proceso en sí.

La siguiente cita de Tom DeMarco me ha hecho reflexionar: “La razón real para el uso de la presión y trabajar más horas puede que sea para que cada uno se sienta mejor cuando el proyecto está fallando”.

Puede que una razón sea esa pero ni mucho menos es lo que ocurre en todos los casos en los que se trabaja bajo presión o hay overtime incluso en períodos largos de tiempo (sobre todo en Death March Projects).

¿Por qué me ha hecho reflexionar? Pues porque cuando todo va mal un mecanismo de autodefensa que se suele utilizar es precisamente dar la apariencia de cumplir: “el proyecto va mal, pero no será por mi porque no paro de echar horas al proyecto”.

¿Dónde está la frontera entre la apariencia de cumplir y la necesidad real de un proyecto?

Es complicado, lo mismo estás echando más horas al proyecto no por el mero hecho cumplir sino porque tienes alguna motivación para hacerlo pero, ¿cuándo deja ser una motivación real y pasa a ser otra cosa? A veces será fácil diferenciar una cosa de la otra, en otras ocasiones la frontera será más difusa.

La documentación es un instrumento para el desarrollo de software. Instrumento que si toca unas notas que no se ajustan a lo que requiere el proyecto provocará ruido y no una melodía.

No creo en un proyecto sin documentación pero tampoco creo en un proyecto donde la documentación se convierta en parte del objetivo.

Habrá proyectos que puede que fracasen porque entre otros factores no se ha realizado un uso adecuado de la documentación, pero eso no solo es aplicable a su defecto, también a su exceso.

¿Más vale que sobre y no que falte? Yo respondo con otra pregunta, ¿con tanto margen contamos como para malgastar esfuerzo?.

Sobre esto, Tom DeMarco y Tim Lister realizan la siguiente reflexión: “La documentación voluminosa es parte del problema, no parte de la solución”.