archivo

Archivo de la etiqueta: Planificación

Es fundamental saber hacia dónde se quiere ir, cuáles son los objetivos y esto es extensible tanto a las personas como a las organizaciones.

De lo contrario, al no tener referencias, se vive en un continuo cortoplacismo en el que los árboles te impedirán ver el bosque incluso en circunstancias que puedan resultar evidentes.

El cortoplacismo y la ausencia de referencias son muy peligrosos ya que en estas circunstancias te encuentras como un barco a la deriva.

Supongamos que tenemos objetivos, ¿qué tal si planificamos todas las acciones necesarias para alcanzarlo?. Pues que probablemente hayamos ganado en conocimiento de la situación por el análisis necesario para realizar la planificación y hayamos perdido tiempo ya que buena parte de lo planificado no servirá de nada una vez que el contexto previsto en el que se van a ejecutar las acciones varíe (y variará).

Comenta Ron Jeffries que (traducción libre): “Cómo podemos saber lo lejos que podemos llegar si normalmente no vamos tan lejos”.

Tiene razón y es uno de los riesgos de la planificación: plantear acciones sobre escenarios abstractos sobre los que no se tiene un conocimiento o un dominio concreto y sobre los que no se tiene un control.

Es por eso que resulta más adecuado el concepto de plan (planteo las acciones a realizar en mi contexto actual) y el concepto de evolución centrado en los objetivos (sé a dónde quiero llegar, probablemente no conozca el camino, pero si mido bien los pasos estaré más cerca de la meta).

Me parece muy interesante la siguiente cita del que fuera presidente y general américano Dwight David Eisenhower: “En la preparación para la batalla siempre he encontrado que los planes son inútiles, pero la planificación es indispensable”.

¿Por qué? Pues porque el establecimiento de objetivos y metas y la definición de escenarios son elementos puramente teóricos y que se pueden desmoronar cuando determinados detalles inesperados entran en escena.

La planificación es la capacidad de distribuir tus recursos y tu esfuerzo en función del escenario en que te encuentras en ese momento, de lo que has hecho hasta ahora y de lo que pretendes conseguir. No es una visión cortoplacista sino adaptativa.

Comenta Kent Beck que “la planificación también es diseño”.

Si a esto le sumamos que el diseño no es solo la apariencia externa del producto, su arquitectura o en términos más teóricos, la concreción del análisis en una solución técnica, sino que también debería considerarse diseño la ejecución final del producto (es una visión más heterodoxa, pero muy en consonancia con la visión que del diseño tienen muchas personas en la industria, como por ejemplo Steve Jobs), llegaríamos a la conclusión de que la planificación y el diseño son dos elementos horizontales o transversales en el proceso de desarrollo.

Y es que la planificación lo condiciona absolutamente todo, así como las sucesivas decisiones que modifican la misma vía feedback de los desarrollos o por contingencias externas al proyecto. La planificación llega incluso al día a día, qué hemos hecho ayer y qué vamos a hacer hoy. Y si el diseño abarca desde la concepción del producto hasta la propia ejecución, se verá afectado como no podía ser de otra forma por la planificación y a su vez afectará a la misma, ya que el diseño impondrá restricciones que hará más simple o más complicado el proceso de adaptación al cambio.

Una de las citas más conocidas de Horning es la siguiente: “Nada es tan simple como esperamos que sea”.

¿Es este un enfoque pesimista que aplicar al desarrollo de software o refleja una realidad?, ¿según ese planteamiento deberíamos optar a la hora de hacer una estimación o una planificación por la opción más conservadora?.

La respuesta a estas preguntas es compleja.

Es cierto que el desarrollo de software está sometido a la incertidumbre y que el grado de incertidumbre no es siempre el mismo, ya que dependerá de muchas variables: tipo de cliente, el cliente en sí, la complejidad del proyecto, la tecnología, etc…

En base a esto tengo claro que una estimación o una planificación tiene que estar acorde a ese contexto. Puedes hacerlas teniendo en cuenta la existencia de circunstancias ideales, pero después debes aplicar un factor corrector que adapte las mismas a la realidad del contexto en el que se va a trabajar, tú lo agradecerás, pero el cliente a la larga también (aunque eso implique unas estimaciones en coste o planificación superiores a las que tal vez tenía pensado).

Que la naturaleza del desarrollo de software y su incertidumbre aconseje la aplicación de enfoques iterativos e incrementales no quiere decir que no se deba planificar, evaluar y controlar el trabajo que se hace, es más, es fundamental que estas actividades se realicen si se quiere llevar adelante el proyecto.

Pero, ¿es eso ágil? Puede serlo, como también puede no ser ágil no hacerlo. La agilidad es primero actitud, no lo olvidemos.

Cuando se desarrollo no se dispone de un presupuesto ilimitado, es más, desde mi punto de vista no es aconsejable (ley de Parkinson) tener un presupuesto excesivo (aunque sí holgado) sobre la base del trabajo previsto realizar (siempre habrá tiempo después de hacer ampliaciones si fuera necesario y estuviera justificado).

Por tanto, como es limitado se tiene que tener valorado lo que cuesta cada funcionalidad, requisito o historia de usuario que se quiera realizar y que los responsables funcionales aprueben de manera explícita cada uno de esos trabajos individuales con ese coste.

Es fundamental que eso se haga de esa manera, ya que siendo el feedback esencial para obtener un producto que satisfaga las expectativas del usuario, tiene un coste y el usuario debe ser consciente de él, para que sepa que la aproximación sucesiva al producto final tiene un coste y sus errores y falta de atención, también.

En todo este contexto, resulta esencial planificar, en primer lugar para que el desarrollo del software se realice con intención y se centre siempre en lo que resulte más prioritario e importante en cada momento y en segundo lugar para conocer cuándo va a estar disponible tal o cual funcionalidad o corregido tal o cual error.

Mi recomendación es que exista una planificación a alto nivel (bastaría con una priorización de dichas tareas, sin entrar en excesivo detalle) y que solo existiera una planificación detallada para las actuaciones a realizar a corto plazo. De lo contrario, el peso de mantener una planificación detallada más amplia requeriría un esfuerzo importante que habría que evaluar si compensa y si se disponen medios adecuados para tenerla actualizada.

Cuando estamos realizando el mantenimiento de un sistema de información o cuando lo estamos construyendo siguiendo un enfoque iterativo incremental, las peticiones de mejora o de evolución del sistema pueden venir de distintas fuentes (grupos de usuarios), cada una de las cuales dependerá de muchos factores, como por ejemplo, del módulo del sistema que utilicen, del grado de conocimiento de la aplicación y del negocio, de las necesidades que tengan en su día a día, etc…

Si estas peticiones se trasladan a una planificación sin que detrás exista un plan general de evolución del sistema de información, en el cual una persona o un conjunto de personas con criterio y responsabilidad se encarguen de priorizar (o incluso rechazar aquellas peticiones que se consideren que no sean necesarias o que estén equivocadas), tendremos una planificación del sistema sin intención, en la que se apagarán determinados focos de incendio, pero sin una estrategia general para que el sistema termine satisfaciendo las expectativas que se tenían en él.

Una planificación sin intención se limita a ejecutar trabajos y tendrán por lo general un impacto muy superficial en el sistema, una planificación con intención consiste en ejecutar trabajos para ir poco a poco acercándonos a un objetivo.

Es adaptarse al cambio, adaptarse a un entorno con incertidumbre con un esfuerzo y un tiempo razonable.

Improvisar es ir descubriendo el camino en cada paso, las metodologías ágiles siguen un plan, en sí mismas son un plan, que puede y debe cambiar tanto por el feedback recibido en la realización del proyecto y también por las diversas contingencias que se producirán en el mismo.

Sabemos donde queremos ir, podemos incluso tener prevista una ruta para llegar a él, pero después son las circunstancias las que hacen que nos adaptemos a las mismas, de manera objetiva, razonada y analítica, poniendo el enfoque en el corto plazo, pero sin olvidar el medio y el largo plazo (lo que sembremos hoy condicionará lo que recojamos mañana).

La improvisación es corto plazo, solo corto plazo.