Lo que sé que sé (Parte II)

Estas conclusiones apuntan a que los procesos de definición y gestión de requisitos pueden mejorarse enormemente aplicando ciertas buenas prácticas (inspiradas por valores). En el lugar donde trabajo intentamos día a día refinar y mejorar nuestros procesos, y creo que empezar por adoptar ciertas ideas de Scrum y del Product Backlog puede ser un buen punto de partida.

Sin ser un experto en metodologías ágiles, y con mucho camino aún por recorrer, sí vislumbro ciertos valores y prácticas que mejoran los procesos, y que deben acompañarlos en cada fase del ciclo de vida. Concretamente, y en las fases en las que interviene el Analista Funcional, considero interesantes los siguientes valores y prácticas:

  • Los artefactos de Análisis deben contener información viva, en continuo crecimiento y evolución, que durante el ciclo de vida se va desarrollando en paralelo con el resto de actividades; de esta forma siempre se proporcionará al cliente el mayor valor posible. Este valor es fundamental, aunque se ha de asumir que los alcances (medidos en necesidades a su vez expresadas en requisitos) son negociables.
  • La concepción del negocio por parte del cliente (su visión) ha de ser conocida por todo el equipo. Cuando esta visión sea comprendida por el equipo, sus aportaciones introducirán (o descartarán) funcionalidades, mejoras y tecnologías, permitiendo la detección y corrección de errores de forma prematura, que se incorporarán a los productos de Análisis a través de sucesivas iteraciones del proceso.
  • Como resultado de estas iteraciones, el equipo generará una visión real, aún más comprendida y compartida por todo el equipo. Este valor, a su vez, refuerza a las anteriores prácticas.

Esta es mi visión (mía, propia, particular), que espero seguir refinando y mejorando poco a poco (porque será un síntoma claro de madurez) en futuros post sobre cómo materializar estos propósitos y buenas intenciones en el día a día.

2 Pensamientos

  1. Interesante.

    Sobre el tema de las metodologías ágiles y la estimación tengo bastantes dudas. La mayoría de los clientes tienen unas restricciones muy férreas en cuanto a plazos y presupuesto. Y no quieren dejar nada abierto (quieren saber cuánto les va a costar el desarrollo, en tiempo y dinero). Esto parece ir un poco en contra de la metodología iterativa de Scrum, donde los requisitos se van revisando, añadiendo, quitando y re-especificando en cada sprint.

    Por ejemplo, si una empresa me pide presupuesto, se lo hago y gano el proyecto; si luego aplico Scrum corro el riesgo de que aparezcan incontables “pollaques”. El tiempo de desarrollo se va a incrementar enormemente, con seguridad voy a perder dinero. Además el cliente intentará regatear ya que para él habré tardado más de la cuenta.

    Por eso desde mi punto de vista (actual, que no inamovible) SCRUM y demás metodologías ágiles están bien cuando el cliente es consciente de que el proyecto es abierto, y por tanto lo que le vas a cobrar también. Lamentablemente no conozco muchos clientes de este tipo 🙂

    Me gustaría conocer otras opiniones sobre estos temas que planteo.

    Enhorabuena por el blog.
    Saludos

    Me gusta

    1. Hola Gardner.

      Interesante tu comentario. Creo que en cierto modo te doy mi opinión en el post titulado Pollaques vs Ignorancia. Intentaré sintetizar las ideas que en él exponía para responderte.

      En mi opinión, los pollaques aparecerán con independencia de la metodología que apliques. Los veo ligados al negocio del cliente y no al proceso, y surgirán cuando hagas Model Storming con los usuarios finales, ya sea durante un ciclo de vida iterativo o durante uno en cascada.

      Lo que hay que defender es que el pollaque no estaba presupuestado, y en caso de ser necesario añadirlo, habrá que negociar:
      1. Revisar la planificación temporal y económica del proyecto.
      2. Cuando éstas sean inamovibles, entonces habrá que revisar el alcance del proyecto (si meto por un lado tendré que quitar por otro). La planificación es un juego donde lo que importa son las cifras totales (qué más da dedicar dos semanas adicionales en la capa de servicio si finalmente para la release candidate se han suprimido requisitos de interoperabilidad que en esfuerzo equivalían a dos semanas de trabajo).

      Si las posturas no se aproximan, entonces habrá que estudiar si se le pierde menos dinero al proyecto rechazándolo que ejecutándolo con las nuevas normas del juego. Este estudio es complejo, tal vez interese asumir las pérdidas por cuestiones estratégicas:
      1. Fidelizar con el cliente para futuras actuaciones.
      2. Es un nuevo cliente con el que nunca se trabajó.
      3. Es un cliente que pudo quedar insatisfecho en proyectos anteriores -por los motivos que sea- y se presenta la oportunidad de ofrecerle valor y satisfacción.

      Es indudable que para poder aplicar metodologías ágiles se deben presentar una serie de condiciones, tanto en el lado del equipo como en el lado del cliente: asunción de responsabilidades (el cliente también asume las que le corresponden), empatía, concepción del equipo (el cliente también forma parte de él), percepción del tiempo (es perdido o invertido), tolerancia ante el cambio, implicación y motivo de implicación (no es lo mismo implicarte porque tu jefe te lo impone que porque existe un interés sincero en la propia acción de implicarse), grado de interés en alcanzar el éxito y hasta dónde se está dispuesto a llegar para alcanzarlo.

      El cliente mayoritario con el que trabajo es la Administración Pública, y hay de todo. Tenemos clientes tan implicados que siguen la evolución de los proyectos día a día y se involucran hasta niveles inimaginables. Tenemos otros que ni siquiera asumen su parte de responsabilidad en la ejecución de los proyectos, y provocan situaciones incómodas haciéndonos responsables de sus errores. El factor común entre todos ellos es la concepción que tienen sobre los proyectos:
      1. Lo que se va hacer sí está abierto dentro de unos límites (aunque hayas elaborado presupuestos, ofertas, etc. nunca sabrás al inicio todos los datos que necesitas para que esos presupuestos y ofertas estén ajustados y sean realistas), y nunca oses decir lo contrario. 😉
      2. Lo que se va a cobrar no lo estará nunca. Una vez más entra en juego el factor negociación: revisar planificación temporal, económica, y alcance del proyecto, intentar modelar pollaques de gran impacto en el proyecto como futuras ampliaciones del mismo, etc.

      Espero haber sabido transmitirte mi opinión.

      Un saludo.

      Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s