archivo

Archivos diarios: diciembre 3, 2011

En muchas ocasiones, considerar algo como una pérdida de tiempo es una cuestión de percepción, es decir, para alguien puede serlo, para otros no (y en medio, toda una escala de grises).

En otros casos, no hay lugar a la interpretación, se trata de pérdidas de tiempo.

Comentan Tom DeMarco y Tim Lister que: “El mayor pecado de la gestión es hacer perder el tiempo a la gente”, esto unido a su reflexión sobre los días de trabajo que se pierden, nos debe hacer pensar sobre algunas decisiones que provocan pérdidas de tiempo (a las que habría que añadir todos los malos hábitos productivos que tengamos a nivel de organización e individual).

Una mala selección de prioridades suponen una pérdida de tiempo, ya que estamos dedicando nuestro esfuerzo y atención (enfoque) a una serie de tareas y funcionalidades que no son críticas, dejando de lado otras que sí lo son. Sobre esto, se podría pensar que al fin y al cabo son cosas que tarde o temprano habría que hacer, sin embargo, la incertidumbre de los proyectos y las limitaciones presupuestarias y de tiempo no aseguran que lo que hemos dejado para después se pueda llegar a hacer, por lo que lo mejor es empezar siempre por lo que realmente es importante y trascendente. A esto, habría que sumar el hecho de lo que se deja de ganar o producir por realizar más tarde las tareas y funcionalidades que realmente tienen un impacto.

Una mala selección de funcionalidades también suponen una pérdida de tiempo. Es importante matizar esto.

El desarrollo de software es de naturaleza evolutiva, donde la aproximación a la solución que satisfaga a las expectativas de los usuarios se llega generalmente (que no siempre) mediante aproximaciones iterativas e incrementales. Bajo esta perspectiva, basada en el feedback del usuario (y de todos los stakeholders en cada iteración), no acertar en la definición de una funcionalidad forma parte en sí de la propia naturaleza del desarrollo y por tanto no se debería considerar una pérdida de tiempo. También es importante matizar esto.

El desarrollo iterativo incremental no es lo mismo que un ensayo y error a ciegas, sino que cada intento debe tener una intención y debe ser resultado de un proceso previo de reflexión. Claro que se puede fallar, claro que pueden ser necesarios ajustes, sin embargo, no se trata de probar por probar porque en este caso sí que estamos perdiendo el tiempo y capacidad para desarrollar otras funcionalidades prioritarias, ya que estamos invirtiendo el esfuerzo en dar vueltas sobre lo mismo.

Es importante también un enfoque minimalista en el desarrollo, evitando funcionalidades que finalmente no se van a utilizar o que van a tener un uso residual. El desarrollo de estas utilidades, también supone una importante pérdida de tiempo (y no solo eso, un lastre para el resto del proceso de desarrollo y el mantenimiento).

Normalmente se considera ciclo de vida del software a todo el tiempo que transcurre desde que comienza su especificación hasta que la aplicación deja de usarse y tener utilidad, dividiéndose el mismo en una serie de etapas que variarán en función de la metodología de desarrollo utilizada.

Sin embargo, desde mi punto de vista, el ciclo de vida del software no comienza con la especificación, sino que comienza mucho antes, en el momento de que una persona, un departamento o una organización tiene una necesidad que requiere ser resuelta con una solución informática.

Desde la necesidad, hasta que comienza la especificación en el proceso de desarrollo (o incluso el mismo proyecto), pasan muchas cosas como para ser pasadas por alto y que condicionan mucho todo lo que va a pasar después (es en este punto donde la batalla puede comenzar perdida, totalmente perdida o con una buena base para la realización de las tareas necesarias para el desarrollo): delimitación del alcance, definición del presupuesto inicial, determinación de expectativas iniciales, selección del proveedor o equipo de desarrollo, ajuste del alcance tras la contratación de los trabajos o selección del equipo, etc…

No hace mucho un amigo me pidió que dedicase un artículo a lo que para mi era el software, más allá de definiciones formales. Es cierto, hablo mucho sobre aspectos relacionados con los procesos, la metodología, las personas, la calidad, sus problemas, algunas de sus características, pero no me había centrado en darle una definición desde mi propio punto de vista.

¿Qué es el software? Una solución.

Una solución porque tiene como objetivo satisfacer una expectativas de manera directa (cuando se trata de un desarrollo a medida) o de manera indirecta (cuando se trata de un desarrollo que se ofrece a la sociedad de manera gratuita, de pago, con acceso al fuente o no, con la posibilidad de modificar el fuente o no).

Tras las expectativas hay personas. Por lo que el software es una solución que trata de satisfacer una serie de expectativas que sobre él tienen puestas personas. Tras las expectativas hay objetivos. Por lo que podemos ampliar la definición a que el software es una solución que trata de satisfacer una serie de expectativas que sobre él tienen puestas personas para el cumplimiento de unos objetivos.

Esta solución, está formada por un conjunto de instrucciones que se ejecutan sobre un dispositivo físico (independientemente de que se pongan capas software entre ellos, como servidores de aplicaciones, servidores web, máquinas virtuales, sistemas operativos, etc…, ya que los mismos actúan básicamente como interfaces que ofrecen servicios y valor añadido).

Así de simple y así de complicado a la vez es el software porque para que un sistema o una aplicación funcione es necesario que el código simule un comportamiento inteligente que responda a acciones provocadas por estímulos externos, ya provengan de un usuario, de sensores, de eventos, de otro software, etc…

La productividad nace de la persona, elegimos intentar ser productivos o no, eso es una realidad. No existen pastillas, jarabes o dietas milagro para que de la noche a la mañana te plantees la productividad como parte de tu modo de vida.

Sí, es un modo de vida, en lo profesional y en lo personal. Es la búsqueda de una mejora continua en todos los campos de la vida, es la búsqueda de sacar el máximo partido posible al tiempo.

Asociamos productividad siempre a lo profesional pero generalmente quien es productivo en ese ámbito también lo es en lo personal.

Como decía, nace de la persona pero no nace con la persona, es decir, siempre podemos decidir hacia donde ir y una vez elegido un sentido, también elegimos cuándo y cuánto es suficiente.

En el artículo anterior vimos que Tim Lister, en función de diversos criterios: probabilidad, impacto, esfuerzo/coste necesario para evitar su ocurrencia, etc…, recomendaba que el tratamiento de los riesgos en función de dicho análisis se realizara antes/proactivo (evitar su materialización), después/reactivo (reaccionar ante las consecuencias del impacto) o una combinación de ambas posibilidades.

En la gestión del riesgo hay que entender que siempre estamos en un presente, en el durante y que por tanto, de la misma manera que las condiciones de un proyecto pueden cambiar, ya que no olvidemos que el proceso de desarrollo se encuentra siempre bajo un prisma de incertidumbre. Variarán los riesgos, aparecerán algunos nuevos y los ya identificados también se podrán ver afectados (reduciéndose o incrementándose la probabilidad de su ocurrencia, su impacto o incluso pueden desaparecer).

Por tanto, le gestión del riesgo, es una actividad que nos acompañará de manera horizontal a lo largo de todo el ciclo de vida y en donde es necesaria la participación de todos los stakeholders, tanto en el proceso de identificación y evaluación continua, como en la realización de tareas proactivas o reactivas ante los mismos.

Sobre esto Tim Lister comenta lo siguiente (traducción libre): “No hay forma de identificar todos los riesgos al inicio de un proyecto y establecer una gestión de los mismos que abarque desde ese momento hasta el final. Un buen gestor de riesgos es aquel que no solo vigila los riesgos identificados sino aquel que busca en colaboración con los demás la existencia de nuevos riesgos”.

La mejora continua se consigue dando pasos adelante, aprendiendo de lo que has dejado atrás. Hay una cita del autor, desarrollador y emprendedor americano P. J. Plauger muy simple, pero que expresa mucho: “No te pares con tu primer proyecto“.

Salga bien, salga mal, sigue adelante, intenta que el segundo salga mejor y así sucesivamente. La mejora continua no es una línea recta ascendente, es un vaivén de éxitos y fracasos de donde se debe aprender para ser mejor profesional y persona.