archivo

Archivos diarios: julio 26, 2011

Rebecca Parsons es la actual CTO de la empresa ThoughtWorks, dedicada a la consultoría y al desarrollo de software utilizando metodologías ágiles. Con anterioridad desarrolló su trabajo como profesora universitaria y colaboradora en diversas instituciones y comités. Sus trabajos se centraron en los campos de la inteligencia artificial, computación distribuida y los lenguajes de programación. En totalidad son más de veinte años lo que lleva dedicada a este negocio.

El rendimiento es una requisito no funcional, una variable en el proceso de desarrollo de software a la que no se le suele prestar demasiada atención pero que hace daño cuando el producto se encuentra en una fase avanzada de su construcción (porque requerirá esfuerzo corregirla) y todavía más en producción porque a ese coste hay que sumarle la pérdida de eficiencia y productividad de los usuarios en el uso de la herramienta y la disminución de la confianza de los mismos en el producto, lo que afectará negativamente a los gestores funcionales y técnicos del proyecto.

Es cierto que una buena arquitectura, codificación, diseño del modelo de datos, afectan implícitamente al rendimiento, sin embargo, no solemos prestar la atención que se merece a un aspecto que tiene incidencia en la calidad final del producto, pese a que Rebecca Parsons tiene razón cuando comenta que: “Nunca es demasiado pronto para pensar en el rendimiento”.

Los responsables técnicos del cliente ejecutan órdenes de la alta dirección de su organización. Si la misma determina que un sistema tiene que estar desarrollado para antes de X o que determinada evolución funcional debe estar hecha para antes de Y, terminarán por intentar cumplir con las instrucciones que se reciben, aunque los plazos indicados sean imposibles y/o el presupuesto asignado a la tarea sea muy insuficiente.

Como siempre indico, hay que intentar ir con la realidad por delante y si algo no es viable hay que decirlo, si después no te hacen caso seguirá siendo tu problema, pero por lo menos al trasladarlo ya haces partícipe del mismo a quien no ha querido escucharte.

Ahora tocará a los responsables técnicos del cliente y a los responsables funcionales estudiar el problema antes de afrontar el trabajo con personal interno o contratarlo a un proveedor de servicios de desarrollo de software con el objeto de dejar exclusivamente lo imprescindible para satisfacer las necesidades de la dirección y de esta forma aproximar más el alcance a los recursos.

Sin embargo, esta reducción del alcance no siempre será suficiente (y en otros casos el cliente no le dará excesiva importancia al desajuste expectativas, plazos y recursos y no hará cambios o ajustes a los planteamientos de la dirección) y el proveedor (a veces alertado previamente y otras no) participará desde el minuto uno en un Death March Project (situación que todavía puede empeorar si además le da por apretar todavía más los presupuestos y/o los plazos).