Lycka Bonita

Inicio del alcance

A mi gusto fue un error ceder en la calidad desde el momento cero del proyecto, debimos incluirla explícitamente en el alcance del proyecto. En su momento realcé su importancia pero lo dejé como una elección del cliente : si quiere tener un producto no muy bueno, es su dinero. Sin embargo también nosotros nos podríamos haber ahorrado disgustos y duros.

Debimos hacer más énfasis en las métricas para valorar el éxito, trabajo completado y desviaciones, ya que únicamente valorar que el aplicativo esté en producción en una fecha es totalmente insuficiente. Este es el punto más fuerte de TDD (Test Driven Development) y por la que creo me gustaría empezar a implantarlo.

• Entradas
• Descripción del producto, sin sentido en esta etapa 1.0 ya que no se sabía qué se quería.
• Plan estratégico, sin sentido ya que no había una estrategia definida en el cliente. 
• Criterio de selección de proyectos
• Información histórica, únicamente unos meses de experiencia en la fase de desarrollo en otro proyecto para este cliente.
• Herramientas/Técnicas
• Métodos de selección de proyectos
• Juicio de expertos
• Salidas
• Carta de proyecto. La primera versión estaba bastante acotada en cuanto al alcance, pero las sucesivas replanificaciones y la repentina irrupción de Mutua Madrileña hizo que el cliente perdiese la visión del QUÉ quería y por tanto la indefinición del alcance fue en aumento.
• Identificar Stakeholders.
• Criterios de éxito. Puesta en producción del aplicativo en la fecha prevista para las diferentes fases.
• Resticciones. En el alcance se identificaron una serie de restricciones que más adelante se incluyeron dentro del alcance en sucesivas fases pero con menos tiempo del identificado originalmente. En especial doloroso que el desarrollo del módulo de informes planificado en 20 días se llevó a cabo en 2. Ni que decir cabe de las incontables jornadas que se le han dedicado al manteniemiento, y aún hoy tengo incidencias al respecto ya que hace lo que se especificó que no es lo mismo que hoy se necesita.
• Suposiciones. Retrasos en entregas por parte del cliente en el entorno, la indefinición y la imposición de fechas inamovibles que se desplazaban es el ambiente ideal para resaltar la importancia de este apartado.

Planificación del alcance

Difícil por los constantes cambios. De hecho con el proyecto ya en marcha se nos pidió otro entregable, un proyecto que gestionase el acceso y los usuarios para todas las aplicaciones del cliente.

En este punto debimos detallar un mecanismo para gestionar cambios en el alcance y sobre todo respetarlo. De poco nos hubiese servido ya que eran diarios y a pesar de la dedicación casi exclusiva de tres personas todo quedaba con un alto nivel de indefinición : fuimos a ciegas desde la venta hasta el desarrollo (no quiero hablar de las pruebas…)

• Entradas
•  Descripción del producto
• Carta de proyecto
• Restricciones
• Suposiciones
• Herramienta/Técnicas
• Análisis dl producto
• Análisis Coste/Beneficio
• Identificación de alternativas
• Juicio de Expertos
• Salidas
• Establecimiento del alcance.
• Justificación del proyecto. Este proyecto debería de sustituir otra herramienta que está en producción con la que el cliente no estaba contento.
• Productos del proyecto, el propio aplicativo de gestión de siniestros PPI y un single sign on para gestionar usuarios y acceso unificado para todos los aplicativos del cliente.

Definición del alcance

El WBS quedó a un nivel muy alto, e incluso así sufría demasiadas alteraciones, desplazando trabajo del cliente a nosotros y de nosotros al cliente constantemente.

• Entradas
• Establecimiento del alcance
• Restricciones
• Suposiciones
• Herramientas / Técnicas
• Plantillas WBS
• Descomposición
• Salidas
• WBS (Work Breakdown Struture). Cuando se estaba redefiniendo por enésima vez sobrevino la bomba de Mutua Madrileña con lo cual se abandonó. En las sucesivas fases se definió pero a muy alto nivel pero los constantes cambios de requisitos volvían el documento obsoleto aún antes de arrancar el desarrollo.
• RAM (Responsability Allocation Matrix) se definió asignando responsables a funcionalidades y no a elementos del WBS.
• Revisión del establecimiento del alcance

Verificación del alcance

El alcance era verificado por todos los stakeholders del proyecto e inmediatamente después redefinido por todos excepto por nosotros.

Establecer métricas para medir el éxito de una tarea nos hubiese ayudado en la aceptación del producto.

• Entradas
• Resultado de trabajo
• Documentación del producto
• WBS
• Alcance
• Plan de Proyecto
• Herramientas / Técnicas
• Inspección. Medir, examinar y probar para determinas si los resultados satisfacen los requisitos.
• Salidas
• Aceptación formal. Cada fase del proyecto contó con su correspondiente aceptación sobre la documentación

Control de cambios del alcance

Sin duda necesario, y utilizado en las primeras jornadas del proyecto. Poco después abandonado por una gestión ad-hoc porque asfixiaba a los recursos (los desarrolladores recibían órdenes cambiantes continuamente, imposible replanificar y rediseñar a tiempo para obtener otra aceptación…). Salvo excepciones críticas, una vez iniciado el desarrollo no se comunicaban a los desarrolladores cambios en los requisitos hasta su finalización.

Se consideraba irrelevante evaluar el impacto de los cambios en el alcance, ya que el coste de los cambios era continuamente infraestimado y su importancia despreciada, además de una permanente discusión de si era mejora o corrección, ya que a pesar de aceptar y validar las entregas se intentaba que los errores siempre cayesen sobre nuestras espaldas. Como ejemplo, baste decir que un cambio bloqueante realmente impactante en la aplicación que afectaba desde la bbdd hasta la capa de presentación se estimó en 10 jornadas y se retrasó su acometida meses.

• Entradas
• WBS
• Peticiones de cambio
• Plan de Gestión de Alcance.
• Herramientas / Técnicas
• Sistema de Control de Cambios de Alcance
• Medidas de actuación
• Salidas
• Cambios del Alcance
• Acciones correctivas
• Ajustes a las baselines

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.