archivo

Archivo de la etiqueta: Planificación

Las prisas están reñidas con la calidad. Las tareas tienen un tiempo para llevarse a cabo, es cierto que no todo el mundo tarda lo mismo en hacerlas y que no todos les dan el mismo acabado, pero también lo es que esto no hace más que definir un umbral de tiempo para la realización de las mismas.

De ahí la importancia de planificar un proyecto de la mejor manera posible, de detectar desviaciones, de poner solución a las contingencias y de intentar adelantarse a problemas que puedan ocurrir.

Las prisas no solo afectan al resultado final sino a la propia productividad. Las prisas bloquean y hay que tener en cuenta que trabajar bajo presión y bajo la urgencia son cosas distintas.

Es mejor incumplir una planificación de manera controlada (salvo que el producto tenga que estar inexcusablemente en una fecha determinada, algo que por otra parte sucede en muy contadas ocasiones) que intentar cumplirla pase lo que pase, ya que al final, muy probablemente no se consiga un resultado satisfactorio y las posteriores correcciones requerirán un mayor esfuerzo.

Cuando se habla de prisas, urgencias, no viene mal recordar el algoritmo de planificación de Wexelblat.

Partamos de la base de que la mayor parte de los sistemas de información que desarrollamos no tienen que estar de manera obligatoria en una fecha concreta en producción. El cliente te lo podrá exigir, pero realmente en la mayoría de los casos se tratan de fechas de referencia y no están ligadas a un hito especial.

Esto es simplemente estadística, ya que también todos hemos trabajado en desarrollos que sí tenían que estar en un día o semana concreta y existían razones de peso que lo justificaban.

Lo que quiero expresar en el inicio de este artículo es que hay que relativizar las fechas de entregas y tener en cuenta que hay aspectos más importantes que pueden justificar un retraso (siempre dentro de unos términos razonables).

No quiero decir que las fechas no estén para cumplirlas, ya que si se fijan y se pactan es para algo, entre otras cosas para no perder el enfoque del proyecto (enfoque que se diluye cuando no se cierra la fecha de entrega de un producto), lo que quiero decir es que cuando haya un retraso hay que estudiar los motivos, ¿es causa exclusiva del proveedor?, ¿de los usuarios?, ¿del director técnico del cliente?, ¿todos han tenido que ver en una determinada proporción?, ¿ha sido provocada porque los plazos exigidos al equipo de desarrollo son incumplibles ya que no están acordes al alcance del proyecto y los recursos disponibles?.

Una vez determinada la causa es posible tomar decisiones para intentar evitar nuevos retrasos o incluso intentar recuperar parte del camino perdido, sin embargo en la mayoría de los casos resulta muy complicado recuperar los retrasos, entre otras cosas porque no siempre se informa al cliente a tiempo y porque los plazos suelen ser bastante ajustados.

Si la fecha final del proyecto se puede retrasar, mi consejo es que se haga. Si el retraso es responsabilidad del proveedor, ya habrá tiempo de ajustar cuentas (cada palo que aguante su vela), pero no se debe caer en el riesgo de poner en marcha de manera precipitada un producto, ya que por cada paso que se de hacia adelante en este sentido probablemente se tengan que dar varios para atrás.

Si el retraso es lo suficientemente importante como para la fecha objetivo no sea admisible, es conveniente aplicar las prioridades que se hayan establecido sobre los requisitos (si se está desarrollando siguiendo metodologías ágiles, habrá sido el camino adoptado desde el principio del proyecto) y afrontar varios hitos de entrega.

Tanto si vamos a trabajar con metodologías ágiles, como con otras metodologías como RUP y sobre todo, en ciclos de vida clásicos o en cascada, resulta fundamental delimitar cuanto antes el alcance del proyecto.

Como mínimo hay que llegar a una primera aproximación en la negociación del contrato con el cliente (cuanto mejor sea la misma, más variables se tendrán a favor para hacer una correcta valoración en esfuerzo y plazos del proyecto) y es más que recomendable hacer otra aproximación al inicio del proyecto.

Acotar el alcance no debe ser entendido como poner límites al proyecto, al menos en el sentido estricto, ya que a través de la propia evolución del software, la aplicación tenderá a ir hacia donde van las expectativas del usuario. Pero sí se debe entender como un marco hacia donde enfocar el desarrollo, ya que no todas las funcionalidades que se quieren implementar son iguales de prioritarias o críticas.

El proyecto debe centrarse en lo verdaderamente importante, dejando para más adelante aquello que no lo es. Probablemente no habrá presupuesto (por lo menos en primera instancia) para todo, por lo que lo primordial es cubrir lo que resulta necesario.

Si no delimitamos el alcance, se quedarán demasiadas puertas abiertas por detrás, con el riesgo de que el cliente o usuarios quieran volver a ellas. Es cierto que al final el proyecto va hacia donde quiere el cliente o los usuarios, pero no es lo mismo tener pactado por escrito un alcance que no tenerlo y no es lo mismo hacer pedagogía desde el inicio del proyecto que no hacerla.

En todas las etapas de un proyecto de desarrollo de software se pueden tomar decisiones erróneas, una mala ejecución de los trabajos, baja productividad, falta de compromiso, desencuentros entre el cliente, el proveedor, los usuarios, etc… y en todas se produce un impacto en el proyecto que puede ser más o menos grave en función de su intensidad y del momento en que se producen.

Sin embargo hay dos etapas decisivas y que tienen un gran peso en todo lo que va a venir después: la etapa de negociación del proyecto y las primeras fases del análisis que es donde se acota el objeto final de trabajo.

Si la negociación no es buena, se aceptan proyectos por debajo de su precio de mercado, prometiendo lo imposible o se hace una estimación y planificación errónea, está situando al posterior proceso de desarrollo en un contexto difícilmente salvable o incluso en un Death March Project.

No importan tus procesos, no importa que tengas los mejores, no importa que el cliente se vuelque contigo, si el error de partida es grave, remontarlo costará mucho trabajo (cuando se pueda).

Después se puede volver a negociar, pero dependerá de muchos factores conseguir éxito en la misma, sobre todo si el error es tuyo y si desde el primer momento existe desgaste con el cliente.

También resulta muy importante la fase inicial de enfoque del proyecto, determinar su alcance, por lo menos a corto y medio plazo. Una mala elección en lo que es prioritario y en lo que no lo es, será negativo para el cliente, pero también para el que realiza los servicios de desarrollo de software, sobre todo si se trabaja con presupuestos cerrados en proyectos con objetivos abiertos.

Si se consigue ganar tiempo a la planificación resulta muy interesante intentar mantener la ventaja, en un proyecto de desarrollo de software pasan muchas cosas y siempre es mejor tener un margen a favor que no tenerlo o tenerlo en contra.

En metodologías ágiles, con sprints periódicos de corta duración pueden tener menos importancia, sin embargo, ir varios metros por delante siempre es bueno tanto en carreras cortas, en el medio fondo y en el fondo.

En ciclos de vida clásicos o en cascada conseguir ventaja es un seguro de vida porque por la propia evolución de estos proyectos habrá contingencias que provocarán que el proyecto no avance como habría esperar o que retroceda (cambios en requisitos, comportamientos, interfaces en diversas fases del desarrollo).

Ahora bien, conseguir una ventaja no debe convertirse en una obsesión, tampoco mantenerla ya que puede provocar una pérdida del enfoque en los objetivos del proyecto, lo cual al final resultará perjudicial.

James A. Ward es un emprendedor, consultor y autor americano especialista en dirección de proyectos, calidad del proceso de desarrollo y análisis de procesos y sistemas de negocio.

La calidad del proceso de desarrollo de software es la suma de muchas variables, no solo las tres a la que hace referencia el concepto de crisis del software: satisfacción del usuario, cumplimiento de presupuestos y plazos. Para mi, no existe calidad, por ejemplo, si el software tiene una deuda técnica inferior a unos niveles mínimos acordes a la inversión realizada en el software, a los plazos que han existido y a las contingencias que se han podido producir en el proceso de desarrollo.

Se piensa en muchos casos que la calidad del software está reñida con plazos y costes. Sobre este aspecto James A. Ward realiza la siguiente reflexión: “La calidad es el aliado de la planificación y de los costes, no su adversario. Si tenemos que sacrificar la calidad para cumplir la planificación es porque estamos haciendo el trabajo mal desde el principio”.

Mi opinión es que una empresa de desarrollo de software debe enfocar sus procesos, generadores de código, frameworks y técnicas de codificación a conseguir productos con una calidad que no sea forzada (la que se fuerza es precisamente la que te rompe los esquemas porque ni tu forma de trabajar ni tu personal están preparados para trabajar de esa manera), sino que sea algo natural a conseguir por parte de equipos de trabajo compensados en experiencia y conocimientos. Con esta buena base, aplicando la metodología más adecuada al proyecto y siempre y cuando los plazos y presupuestos sean equilibrados, no tienen porque estar reñidas estas variables.

En muchos casos se llega a un Death March Project (sin tener en cuenta todos aquellos en donde se sabe desde que se oferta o se planifica que se va a llegar a esta situación o donde la estimación ha sido errónea) por una serie de situaciones (que no tienen por qué ser muchas) que han ocurrido en el transcurso del proyecto y que no se han solucionado de manera tajante y/o por una serie de errores (que tampoco tienen por qué ser muchos) que han tenido lugar en el seno del equipo de proyecto, en los usuarios y/o en los responsables técnicos del cliente.

Es importante insistir que no han tenido por qué ser muchas las situaciones y/o errores que han tenido que ocurrir para que todo empiece a ir mal, basta con que sean lo suficientemente graves (aunque al principio no lo parezcan) y no se le hayan aplicado soluciones a tiempo para que la situación se convierta en delicada.

Cuando las heridas (esas situaciones y/o errores) se va haciendo más grande hay que intervenir, si no se hace probablemente el proyecto llegue a una espiral en la que todos pierden, a una situación de Death March Projecto.

A veces, cuando se planifica un proyecto el riesgo de que se convierta en un Death March Project no es alto, sin embargo una mala estimación (no se ha medido correctamente el alcance real ya sea porque no se disponía de información suficiente o no era buena o siendo adecuada no se ha calculado adecuadamente el esfuerzo necesario), problemas y errores que afectan al devenir de las tareas que se realizan en el mismo, pueden convertir lo que parecía un proyecto de desarrollo de software que iba a transcurrir dentro de unos umbrales de normalidad en una pesadilla.

Las malas estimaciones tienen una solución complicada, sobre todo si el cliente no ha tenido influencia significativa en el error. Se puede intentar renegociar el presupuesto y los plazos, pero el éxito (que difícilmente permitirá suplir la totalidad del error, ya que no hay que olvidar de quién procede el mismo) dependerá mucho del cliente y personas con las que tendrás que abordar esa negociación.

En cualquier caso lo que sí se debe hacer es informar cuanto antes al cliente del error en la estimación y pactar para el proyecto una salida que pueda ser beneficiosa para el proveedor sin afectar de manera sensible las expectativas del cliente (tal vez un retraso dentro de unos umbrales asumibles en la entrega, disminución del alcance en partes no significativas de la aplicación, etc…). Cuanto más tardes en informar, menos disposición encontrarás en el cliente a ser más flexible (porque confiará menos en lo que estés diciendo) y mayor será el perjuicio económico y de imagen que se producirá.

En este artículo estoy haciendo referencia a malas estimaciones realizadas involuntariamente y no a aquellas que son el resultado de ofertas que tiran los precios, ya que las consecuencias en uno y en otro caso serán diferentes ya que los clientes no las tratarán, por regla general, de la misma forma.

Edward Nash Yourdon popularizó este término en su libro “Death March: The Complete Software Developer’s Guide to Surviving ‘Mission Impossible’ Projects”.

¿Qué es un Death March Project? Según Yourdon todo aquel proyecto en donde algunas de las variables necesarias para el éxito del proyecto exceden un porcentaje importante la norma (el mismo Yourdon comenta que no hay una fórmula, ya que son muchos las factores que pueden intervenir en un proyecto de desarrollo de software, si bien considera que fluctuaciones de un 10% sobre las métricas normales que debería tener el proyecto no debería ocasionar un trastorno sensible en el mismo).

Algunas situaciones que pueden dar lugar a Death March Projects las tenemos por ejemplo con un proyecto que se intenta hacer en la mitad del tiempo necesario para desarrollarlo o con un presupuesto que es la mitad del necesario para llevarlo a cabo.

Lo peor de todo es que generalmente un valor inadecuado de estos parámetros tiende a arrastrar a otros por lo que el problema se multiplica.

A veces, una mala estimación del alcance del proyecto o unos cambios en las especificaciones pueden provocar esta situación, sin embargo, en la mayoría de las ocasiones donde existe un Death March Project, se sabe prácticamente desde que se está planificando que es imposible cumplir los objetivos.

Es más, de los casos anteriores, desde que se hace una oferta a un cliente se sabe que no se va a cumplir, dejando el problema a los que después se van a encargar del proyecto.

Cuando el testing rompe la fluidez en los entregables de los proyectos de desarrollo de software en una organización es necesario estudiar las causas.

Puede ser debido a que el trabajo de los equipos de proyecto son de calidad deficiente y/o que el testing impone unos procedimientos que no van de la mano con la metodología de desarrollo elegida en los proyectos.

Por regla general la culpa está repartida, es más, incluso si se analiza la situación en profundidad las causas se encuentran en la no existencia de una política de desarrollo de software en la organización que permita adoptar la solución más adecuada en los proyectos (se adoptan métodos o procesos rígidos) y en una mala orientación y comunicación de los objetivos a las diferentes partes, ya que el fin no debe ser el proceso sino la entrega de productos de calidad (evitando las causas que originan la crisis del software).

Una vez sentadas las bases, sí que se debe exigir a todas las partes implicadas en el proyecto que realicen su trabajo adecuadamente y acorde a lo que se espera del mismo. Si los desarrolladores actúan negligentemente, van en contra de la calidad, si el equipo de testing rompe la fluidez del desarrollo por circunstancias no justificadas (exceso de formalismo, celo, solicitando información que puede resultar costosa de obtener, etc…), se rompe el ritmo de desarrollo y entregas, lo cual hace perder enfoque, retrasa planificaciones y provoca la inversión de esfuerzo en tareas prescindibles (o lo que es lo mismo resta esfuerzo en tareas de mayor importancia en el proyecto), lo cual al final también va en contra de la calidad.

El testing es una ayuda muy importante en el desarrollo de software, ya que tiene como objetivo minimizar el número de errores que pasan a una etapa posterior en el desarrollo o que llegan a producción. Estas incidencias detectadas a tiempo suponen un impulso en la calidad del software y ahorran tiempo y esfuerzo. El testing es necesario, pero debe caminar de manera fluida con el proceso de desarrollo de software.