archivo

Archivos diarios: diciembre 11, 2011

La tiranía de la mediocridad y como consecuencia el abaratamiento del precio/hora es una situación insostenible para nuestro negocio.

Tal vez hoy, tirando los precios, se consigan jugosos contratos, pero esto es hambre hoy y todavía más hambre mañana.

Cuando el precio/hora está a costo del empleado o incluso por debajo y esa es la dinámica general (es decir, no me refiero a aquellos casos donde se decida apostar por un cliente aún a sabiendas de que se va a perder dinero), las soluciones para intentar obtener beneficios pasan por las siguientes alternativas (cumpliéndose una, varias o todas):

– Situar a perfiles y técnicos de menor cualificación que los ofertados.
– Tener al equipo de proyecto en situación de overtime prácticamente desde el principio, ya sea con dedicación plena al proyecto o compartiéndolo con otros.
– Intentar reducir por todos los medios el alcance del proyecto (y tantas veces como sea necesario).
– Pedir más dinero en cuanto sea posible.
– Reducir el nivel de calidad de los entregables del proyecto.

Como podemos ver, son soluciones para disminuir los costes pero todas con repercusiones en el proyecto y en las expectativas del cliente.

En un negocio como el nuestro, donde la competencia es cada vez más voraz y donde la crisis está provocando que las inversiones en productos software sea cada vez menor, solo deberían sobrevivir los mejores, aquellos que consigan realmente una media importante de proyectos con éxito.

Sin embargo la tendencia a competir con las mismas armas que los que han roto el mercado, hace que la mediocridad no haga más que crecer y convierta en normal, lo que no debería serlo.

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.

Tendemos a pensar que cualquier retraso en el proyecto o tarea que estemos realizando la solucionaremos realizando un sobreesfuerzo en los días previos a la entrega.

A veces, sale bien, no lo niego. Sin embargo casi siempre se producen una de estas dos circunstancias: no se llega a tiempo y se tiene que solicitar un aplazamiento o lo que se entrega tiene una calidad nefasta.

Por supuesto, que de estas dos opciones, siempre es mejor solicitar el aplazamiento, sin embargo, suele pasar en muchos casos que tras ese primer aplazamiento, viene otro, que posiblemente tampoco sea el último. Ya sea porque el retraso era considerable o bien porque se aplica el mismo principio de dejarlo todo para el final en cada nuevo intervalo de tiempo establecido.

Los retrasos provocan pérdidas, que son menos que las entregas de mala calidad, pero cuando son muy prolongados en el tiempo, las pérdidas se pueden convertir en insostenibles y lo que es más grave, probablemente la presíón por la entrega provoque que la calidad de la tarea no sea buena, lo que hace que el problema, más que problema, sea una tragedia.

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