A cada uno le pica la paja que se le mete por el culo, no el resto del pajar.
Gonzo, El Sentido De La Vida

01 – Revisión de Siniestros 1.0 – Alcance (1/2)

12 de July del 2010  Siniestros

En todo momento del ciclo de vida de este proyecto el alcance ha sido siempre la variable más indefinida y cambiante : ha habido fases en las que los documentos generados quedaban obsoletos aún antes de ser entregados para su aceptación por el cliente.

Durante este proyecto en todo momento se ha sacado fuera del proyecto un montón de requisitos, se han vuelto a meter, se han metido nuevos, se han modificado los existentes… Ha sido uno de los grandes problemas del proyecto, origen de innumerables conflictos con el cliente. Ya sabéis, que si esto estaba incluido para esta fecha, que si dije Diego o dije digo, indefinición en los requisitos incluso durante el desarrollo, no sabíamos qué testear, siempre salen pequeños detalles después de firmar que luego no resultaban tan pequeños, nos pedían que cerrásemos unas jornadas sin tener el alcance al 100%… 

Sin duda es un problema indeseable y evitable en gran medida, fuente de tensiones y tiempo totalmente improductivo. Pero tienes que trabajar con lo que hay, y este cliente (y no los participantes del cliente en el proyecto) tiene esta gran desventaja.

Dos han sido las principales causas :

  1. Desconocimiento del cliente de dónde quería llegar EXACTAMENTE. Por ejemplo, nuestra entrada de trabajo eran frases del estilo a "quiero declarar un siniestro", "quiero un informe de la actividad de la aplicación". Seguro que estarás pensando en que la comunicación no ha sido buena, ya llegaremos a eso en otra entrega.
  2. Lo ajustado del presupuesto nos obligó a dejar a un lado tareas tan importantes pero no esenciales como calidad o gestión. Sí, son actividades en las que gastas pesetas y ahorras duros, y así lo hemos transmitido reiteradamente al cliente. El presupuesto es ajustado también dentro del cliente, por lo que sus recursos propios están sobrecargados de trabajo.

En estas circunstancias se ha hecho inviable una correcta gestión del alcance, de forma natural hemos ido todos tendiendo al abandono de las buenas prácticas en este aspecto y a adecuarnos a las circunstancias.

Los primeros instantes de caos fueron provocados por estos vaivenes en los requisitos y en el alcance. Poco después nos vimos obligados a reaccionar para intentar retomar el control, optamos por la progresiva introducción de la filosofía ágil en algunas fases conviviendo con las metodologías tradicionales mientras queríamos alcanzar la certificación CMMI, hasta prácticamente el total abandono de las metodologías tradicionales en todas las actividades en favor de la agilidad y en ocasiones simplemente actuaciones ad-hoc.

Por supuesto las buenas prácticas nacen de la experiencia, y su abandono sin duda nos ha perjudicado a todos los implicados y en especial a mí, con broncas, prisas, decisiones precipitadas… También el ser más realistas que puristas nos ha salvado a todos varias veces ya que es imposible llegar a un compromiso y cumplir todos en estas circunstancias.

Un punto que no está en el curso que reviso es la garantía de los productos. Creo que es evidente que se debe de ofrecer garantía, y que esta debería de estar contemplada dentro del alcance del proyecto.

Pero ofrecer garantía en qué condiciones? Al igual que se deben de fijar las condiciones de aceptación del cliente, se deben definir estas condiciones en las que la garantía es válida, ya que si el cliente opta (como ha sido el caso) por el total abandono de las buenas prácticas y la calidad, nadando en un mar de dudas, el resultado no puede ser otro que convertir la fase de garantía en una fase de desarrollo gratuito.

Éxitos

  • Con todas las lagunas y buenas prácticas ignoradas, encontrar una adecuada gestión de los cambios del alcance ha sido crítico para sobrevivir en un cliente que nunca ha tenido un requisitos 100% claro antes de arrancar su desarrollo. Sí, ha sido rudimentaria y en ocasiones caótica, pero ha sido la adecuada a este proyecto.

Oportunidades de mejora para el futuro

  • Hacer explícita la calidad en el alcance, y en el caso del abandono de las buenas prácticas y de la calidad también hacer explícito el coste estimado por su abandono. Por ejemplo, si no se automatizan las pruebas gastaremos 5 jornadas más en la fase de pruebas; si no realizamos pruebas la garantía no cubre las primeras 15 jornadas de incidencias…
  • Definir las ventanas en las que se pueden aceptar cambios de requisitos. Esto hubiera sido muy difícil en este cliente, dado que parte de nuestra actividad la marca el mercado, y en la que la propia indefinición de los requisitos nos obligaba a irlos concretando sobre la marcha a la par que avanzábamos en el desarrollo.

Imprescindible para el futuro

  • No ofrecer garantía de los productos entregados sin un mínimo aceptable de calidad. La aceptación del cliente es importante, pero también debe de haber una aceptación del productor para dar garantía si no queremos convertir la fase de garantía en una fase de desarrollo gratuito.
  • Establecer explícitamente métricas para valorar el éxito de una tarea o entregable debe ser utilizado e impuesto al cliente. En el peor de los casos se debe manejar únicamente de forma interna, pero debe manejarse. De esta forma se puede conocer mejor el estado real del proyecto en todo momento, y tener aceptaciones de los entregables objetivas y explícitas por parte del cliente. En este caso no se hizo por el presupuesto tan ajustado que aceptó el cliente, pero igual que el punto anterior es bueno para el cliente este es bueno para nosotros.

También te puede interesar:

Dejanos tu Comentario

Nombre: (Requerido)

E-Mail: (Requerido)

Sitio WEB:

Comentario:

Comenta