archivo

Archivo de la etiqueta: Planificación

Para Fred Brooks: “Incluso la mejor planificación no es tan omnisciente como para hacer las cosas bien a la primera”.

Eso es importante tenerlo en cuenta si pretendes contratar un software llave en mano o si te quieres encerrar en las limitaciones de un análisis de requisitos.

Lo puedes tratar de hacer de la mejor forma posible, con un espíritu de colaboración fantástico con el área usuaria, con estudios de mercado y/o de otros productos similares, con grandes técnicos, pero al final, la realidad y el camino lo marca el software que estás desarrollando y hasta que este no se empieza a utilizar en un contexto real por parte de los usuarios no se obtendrá el feedback necesario para acercar el producto a las expectativas reales que se tienen de él.

Anuncios

Te puedes esforzar en un proyecto para cumplir una planificación y ceñirte a unos costes y sin embargo no conseguir nada, incluso desarrollando todas y cada de las funcionalidades tal y cual se especificaron en un principio.

¿Por qué? La idea inicial no tiene por qué funcionar, de hecho todos sabemos que es muy difícil acertar a la primera y todavía más conforme se incrementa el tamaño y/o complejidad de la solución. Esto es extensible tanto para el desarrollo de un producto propio como para el desarrollo de software para terceros.

Por tanto, afirmar que un producto que va acorde a unos plazos, unos costes y unas determinadas funcionalidades va bien, es mucho suponer si no se mide realmente el valor que se está obteniendo, de ahí el riesgo que supone, por ejemplo, un desarrollo en cascada cuando los desarrolladores y usuarios viven separados desde la finalización del análisis hasta etapas próximas a la entrega.

En los desarrollos iterativos incrementales, con entregas más frecuentes y con versiones en producción desde etapas tempranas el feedback permite evaluar el valor real que se está obteniendo y adoptar decisiones encaminadas a incrementarlo.

Otra cosa, es que pese a trabajar de esta forma se quiera seguir con el guión inicial prácticamente sin variaciones, en ese caso, poco importará la metodología porque predominará el seguimiento de un plan y esto es consecuencia muchas veces no de confiar ciegamente en él, sino por el afan de cumplir, de cubrir el expediente: “si al final se fracasa, la culpa no es nuestra, sino del plan”.

Planificar a largo plazo puede ser esfuerzo invertido en vano. Sí que me parece interesante tener marcados objetivos e hitos, pero no me lo parece tanto, tener un nivel de detalle importante más allá de lo que se considere el corto/medio plazo (que sea uno u otro dependerá del nivel de incertidumbre que exista).

Es importante saber y poder reaccionar ante el cambio y no cerrarnos en un guión preestablecido ya que la película es otra.

Para Peter Drucker: “Tratar de predecir el futuro es como intentar conducir de noche por un camino rural con las luces apagadas mientras miras por la ventana de atrás”.

Una planificación detallada a largo plazo pretende dar una sensación de control: “si doy todos estos pasos conseguiré los objetivos”, pero en realidad es una falsa sensación de control porque para empezar no sabes si tu plan es bueno o no (por mucho que confíes en él) y tampoco si se van a mantener constantes en el tiempo el contexto o condiciones en las que se ha realizado el mismo (pero es importante tener en cuenta que el problema no suele ser fallar en la planificación, sino como dije antes, ser poco flexible a los cambios cuando resulta necesario).

Precisamente por eso los enfoques predictivos o clásicos en el desarrollo de software no suelen dar buenos resultados porque se especula con una solución basada en un conocimiento limitado de los usuarios del producto que quieren (el conocimiento real se obtiene con el tiempo conforme ellos vayan viendo materializadas sus ideas a lo largo del proceso de desarrollo), dado que estas estrategias prevén estabilidad en las especificaciones, todo empieza a desmoronarse cuando se rompe ese requisito y es demasiado tarde para que los cambios en las especificaciones tengan un impacto leve en el esfuerzo disponible del proyecto.

Llegado a ese punto solo se podrá salvar la situación si cliente y proveedor entienden el problema y tratan de buscar una solución flexibilizando el objeto del contrato, intercambiando tareas y aportando más presupuesto por parte del cliente en el caso de que sea necesario.

Los dos principales motivos que hacen que los presupuestos de partida y las planificaciones (incluso a muy alto nivel) no se ajusten posteriormente a la realidad son:

– La incertidumbre. Sabes que va a haber contingencias en el transcurso del proyecto y que las mismas afectarán al presupuesto y los plazos. Puedes aplicar un colchón de seguridad en función de las variables que conozcas del proyecto: tecnología, complejidad, cliente, etc…, pero incluso contemplando ese factor las posibilidades de error siguen siendo importantes porque prevés un comportamiento de esas variables en base a la experiencia anterior (en el presente el contexto puede ser diferente y, por tanto, el comportamiento también) y porque hay variables que sencillamente no controlas.

– El desconocimiento. Muchas veces se presupuesta y planifica sin conocer las expectativas del área usuaria y la complejidad funcional real que va a tener el sistema. Se tienen ideas generales y sobre eso se construye una hoja de ruta, acertar en base a esto es casi un milagro.

Al final, el presupuesto y los plazos serán restricciones que condicionarán el proyecto y que si están lejos de la realidad (en muchos casos es así) condicionarán a la calidad del producto final.

Sé que trabajar con un presupuesto fijo da tranquilidad: “Tengo la previsión de gastarme X para obtener Y”, pero en el desarrollo de software para obtener Y te tienes que gastar Z que puede ser menor, igual o mayor (casi siempre) que X.

No se trata de tener barra libre. El presupuesto tiene que ser bien gestionado e invertido pero es importante tener presente que si el objetivo real es tener un sistema de información acorde a las expectativas que se tenían en él (tanto a nivel funcional como no funcional) no podemos estar atados a la inflexibilidad de un presupuesto fijo e inamovible.

La microgestión o gestión orientada al detalle tiene un importante overhead tanto por parte de quiénes realizan las tareas como por parte de quien las supervisa. Trabajar de esta manera requiere una gran disciplina de manera que solo se tiene actualizado el estado de las tareas si quienes se encargan de su ejecución tienen muy asimilada esta forma de trabajar.

Otro inconveniente importante es que se crea un contexto de escasa flexibilidad ya que los objetivos se equivocan: lo importante es realizar las tareas asignadas a tiempo sean o no lo que convenga al proyecto o aunque hayan cambiado las circunstancias. ¿Que no hay problemas en cambiar la planificación? Pues nada, a actualizar se ha dicho y el tiempo invertido en ese ajuste dependerá del cambio realizado en la planificación y de la cantidad de trabajo planificado. Este trabajo es a veces tan ingente que con tal de no tener que hacerlo se realiza la tarea y punto.

Pero de todos los posibles inconvenientes el más significativo y con diferencia es que la microgestión no se lleva bien por las circunstancias indicadas: excesivo overhead y falta de flexibilidad con una situación de incertidumbre como rodea a los proyectos de desarrollo de software.

No se trata de no saber qué es lo que se va a hacer hoy o de que podamos seguir como va evolucionando el proyecto pero la verificación del cumplimiento de los objetivos se debe realizar a más largo plazo, ¿cuánto? dependerá del contexto de la actividad, de la tarea o del proyecto.

Con la microgestión se crea una falsa sensación de control: “tengo todo planificado, al detalle, si surge un imprevisto siempre podré reaccionar a tiempo porque sé como va todo y qué está haciendo cada uno”, ¿alguien se cree que de esta forma se tiene un mayor control? Yo no digo que no, dependerá del gestor y del equipo, pero lo que no creo es que de esta manera se responda mejor al cambio, es decir, no creo que el esfuerzo que requiere (y si la gente es sincera indicando el estado real de las tareas) merezca los resultados que, por regla general, va a ofrecer.

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.

No hace mucho publiqué un artículo en el que analizaba la siguiente cita de 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”.

Hay otra cita que encontré hace poco que va en la misma línea. En este caso es del mariscal de campo alemán Helmuth von Moltke the Elder, considerado por muchos como uno de los mejores estrategas militares del siglo XIX: “Ningún plan sobrevive al contacto con el enemigo”.

La realidad sobrepasa a la teoría y la forma y el tiempo en que nos adaptamos a ese cambio que resulta necesario para realizar ese ajuste condicionará, tanto al momento presente como al resto del proyecto. Las condiciones de partida que pensamos que van a existir después no van a ser tales por muy consolidadas creamos que van a ser por ese motivo hay que tener mucho cuidado en definir planes que condicionen nuestra capacidad de adaptación.