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”.

Tiene una cierta lógica pensar que aquellos desarrolladores y autores que defiendan que el eje sobre el que gira el desarrollo de software sean las personas, no tengan mucho aprecio a los procesos.

Y es posible que incluso, en muchos casos, ese juicio de valor sea acertado, no obstante, por poco que sea el cariño que se tenga a los procesos, la mayoría sabe que son un mal (o un bien) necesario.

Necesario porque es necesario que la organización, formada por diferentes equipos de proyecto, cada uno de los cuales con sus problemas e intereses, tenga un cierto orden, una cierta manera de hacer las cosas, una cultura de empresa que no se quede exclusivamente en aspectos superficiales sino también que alcance al día a día del trabajo.

Ahora bien, como en todo, los excesos no son buenos y los procesos, no podían ser una excepción.

No hay que perder de vista, qué pretendemos con los procesos y que entre sus objetivos no se encuentra vivir bajo su dictadura porque no hay que olvidar que no son un fin, sino un medio y que por encima de todo se encuentra la intención de conseguir que los proyectos terminen con éxito.

Esto implica flexibilidad cuando sea necesario, teniendo en cuenta que necesidad y capricho no son lo mismo.

Sobre la medida en que se deben considerar los procesos, Tom DeMarco y Tim Lister, realizan la siguiente reflexión: “La obsesión por los procesos es el problema. La obsesión por el proceso no es solo una anomalía que ocurre ahora y siempre. Es una epidemia”.

Los procesos proporcionan un camino por dónde ir, pero son las personas las que finalmente consiguen llegar a la meta o perderse.

Tom DeMarco y Tim Lister, como divulgadores del término Peopleware, son conscientes de la influencia de las personas en el éxito de los proyectos de desarrollo de software, influencia que más tarde en el manifiesto ágil se consideró como el eje fundamental de este tipo de proyectos.

Por ese motivo, Tom DeMarco y Tim Lister quisieron recalcar que ciertos defectos en los comportamientos de las personas que afectaban de manera negativa a los proyectos de desarrollo de software.

De ahí, por ejemplo, las dos citas de ambos autores que analicé en los artículos:

Desarrollo de software. Tom DeMarco. Timothy R. Lister. Las pérdidas de tiempo.
Desarrollo de software. Tom DeMarco. Timothy R. Lister. Los días de trabajo perdidos no se recuperan.

En esta línea, realizan otra reflexión, totalmente congruente con las anteriores y que va en la misma línea que el artículo “Todos los días valen igual” que acabo de publicar: “Un día perdido al inicio del proyecto hace tanto daño como un día perdido al final”.

Sin embargo, parece que no, que no valen lo mismo, sin embargo, cuando se aproxima la fecha de entrega siempre nos acordamos de aquellos días o de aquel período de tiempo donde la productividad no fue adecuada o donde determinados tipos de comportamientos y decisiones provocaron que el avance en los trabajos no fuera el esperado.

No es cuestión de cantidad de documentación, sino de la calidad y utilidad de la misma.

Una documentación es útil cuando cumple un propósito real en el desarrollo del software y/o tiene utilidad para el control y gestión del proyecto.

La documentación generada para el control y gestión del proyecto va cobrando más interés, ya que es un medio a través del cual los stakeholders se sienten vinculados a compromisos y decisiones. Es cierto que la palabra de muchos puede ser suficiente, pero lo mejor es trazar una línea común para todos ya que el dicho de “las palabras se las lleva el viento” alcanza su máxima plenitud en nuestro negocio.

Cada proyecto es diferente por lo que trazar líneas maestras sobre qué documentación es necesaria y cuál no, resulta complicado. No obstante, sí que puede tener sentido que en el ámbito de una organización y con el sentido de armonizar la documentación generada en los proyectos se definan una serie de entregables obligatorios, si bien hay que dejar siempre la puerta abierta a excepciones concretas en determinados trabajos o lo que es lo mismo, ser flexible.

Por tanto, a nivel de documentación, la justa y la necesaria y por supuesto, de calidad. Si no es de calidad, si no es buena, casi que lo mejor hubiera sido no generarla.

Hay una reflexión de Tom DeMarco y Tim Lister bastante irónica sobre este asunto y en la que se critica la visión de un proceso de desarrollo donde lo formal predomina sobre el resto y en donde no se tiene en cuenta que la documentación es tan volátil como los requisitos plasmados en ella por la incertidumbre que caracteriza a los proyectos de desarrollo de software: “El último proyecto generó una tonelada de papel y todavía fue un desastre, así que en el siguiente proyecto generaremos dos toneladas”.