archivo

Archivo de la etiqueta: área usuaria

De igual manera que el responsable técnico del proyecto tiene que encargarse de toda la parte “interna” del desarrollo de software: coordinar al equipo o equipos de programadores (que pueden ser incluso de diferentes proveedores), tratar con los responsables del proyecto por parte de los proveedores (si hubiera proveedores), coordinar a las personas que junto a ti gestionan el proyecto, tratar con el departamento de sistemas para preparar la infraestructura necesaria, tratar con el Centro de Atención a Usuarios para la recepción del sistema en sus procesos, etc…, el Product Owner se tiene que encargar de coordinar todo el área funcional.

¿En qué consiste esa tarea? El Product Owner es el responsable de definir la línea de desarrollo del producto y por tanto el máximo responsable de definir las prioridades y de aceptar las especificaciones. Debe ser el interlocutor único en cuanto a la toma de decisiones (independientemente de que tenga colaboradores). Esta persona sería la encargada de recabar consensos y segundas opiniones dentro del conjunto de usuarios y sería también responsable de la comunicación de los avances, desviaciones y contingencias del proyecto (en la comunicación se podría recabar el apoyo del área técnica si así fuera preciso).

En el área usuaria es el Product Owner quién debe tomar las decisiones y es el encargado de definir interlocutores para las tareas de especificación y de coordinar las citas que sean necesarias. Como máximo responsable de la línea de desarrollo del producto se requerirá su implicación en el proyecto de lo contrario no contará con la información suficiente como para que sus decisiones tengan una base sólida. Esto es una recomendación, ya que si se limita a dar el visto bueno a los que otros especifican es posible que apruebe soluciones que no son las adecuadas para la aplicación o que el sistema pierda consistencia (tratamiento de conceptos similares de diferente manera o falta de integración en información que debería tenerla).

Si se orienta el desarrollo a sprints (hay que tener en cuenta que el enfoque iterativo incremental es en sí un concepto más amplio) es, entre otros motivos, para conseguir un ritmo sostenible en el desarrollo.

Por eso cada sprint requiere tener preparada de antemano la materia prima, es decir, todos los inputs que necesita para poder ser completado, de lo contrario se tendrá que invertir tiempo en él para obtener esa materia prima, con el riesgo de producirse bloqueos por falta de esas entradas, lo que lo hará menos productivo y menos predecible en cuanto al cumplimiento de los compromisos.

Nos quejamos muchas veces y con razón de la falta de medios económicos para llevar a cabo el proyecto (acorde a las expectativas puestas en él y los plazos) y también de la falta de colaboración del área usuaria. Sobre esto último pocas veces nos paramos a pensar en los motivos que hacen que los usuarios no colaboren.

Uno de ellos puede ser precisamente la falta de medios para proporcionarnos la información y entregables que, una vez interpretados, conforman la materia prima de cada sprint. Es decir, muchas veces el product owner quiere pero no puede.

Se sobreentiende que quien contrata el trabajo ha tenido en cuenta esa carga de trabajo adicional (que en función del tipo de proyecto puede ser muy grande para las personas implicadas), sin embargo no es lo normal, ya que se piensa que con apoyos puntuales es suficiente, creyendo que el equipo de proyecto puede con todo y no, no puede, y si me apuráis, no debe, porque la carga de especificación del sistema debe recaer en el área usuaria.

Las consecuencias de esto es que determinadas tareas del sprint no estarán lo suficientemente definidas y eso hace mucho daño a esta dinámica de trabajo, tanto que nos deberíamos plantear, probablemente, objetivos menos ambiciosos.

Os indico a continuación algunas alternativas y aunque soy de la opinión de intentar reconducir la situación, no siempre va a ser posible:

– Adecuar la capacidad del equipo de proyecto a la carga del área usuaria. De nada vale tener una maquinaria capaz de producir x productos al día si solo entra material para producir x/4 productos.

– Plantear un enfoque iterativo incremental con fases de definición (con el nivel de detalle suficiente para el proyecto y la iteración) entre sprints. En este caso es más impredecible la duración de la fase de análisis pero más predecible la construcción.

– No plantear sprints propiamente dichos y aplicar estrategias de gestión del flujo de trabajo y del WIP (Work in progress), como por ejemplo, definiendo límites en el número de elementos terminados y no pasados a producción o dejando ese aspecto abierto y limitando el número de tareas en fase de análisis.

No hay mejor formar de gestionar las expectativas del área funcional o del cliente que evitando las sorpresas. Es como jugar a las cartas conociendo las del resto de jugadores y eso debería ser un proyecto de desarrollo de software, un conjunto de personas, equipos y organizaciones que trabajan con respecto a los demás de forma transparente (y esto es perfectamente compatible con los intereses particulares o de empresa que puedan existir).

En los proyectos en los que trabajo tengo como objetivo minimizar las sorpresas, gestionando de esta forma las expectativas del área usuaria desde el mismo momento en que puede haber un cambio en las mismas. Casi nunca gusta que acortes alcances pero te aseguro que es mucho mejor negociar en esas circunstancias que cuando, sin margen de reacción, no cumples los compromisos con el usuario.

La confianza es fundamental en el desarrollo de software y más en proyectos con la intensidad que requieren los enfoques iterativos incrementales, por ese motivo es absolutamente necesario gestionar las expectativas, modularlas a la realidad del proyecto.

Ocultar el estado real del proyecto o de un sprint no sirve para nada porque al final, más pronto o más tarde se termina descubriendo el pastel, tal vez todo salga a la luz después de haber terminado los trabajos, pero esa huida hacia adelante termina pasando factura si quieres volver a seguir trabajando con ese cliente.

Se pueden enumerar decenas y decenas de posibles situaciones que se pueden producir en un proyecto y que se podrían considerar riesgos, pero hay una que casi podríamos considerarla unánimemente cómo el principal factor de riesgo en un proyecto y es la falta de implicación del área usuaria.

Sin ellos no hay visión de las expectativas de producto por más que el equipo de proyecto cuente con personas con visión y experiencia sobre el negocio, porque una cosa es el proceso de negocio que se quiere informatizar y otra es cómo le gustaría al usuario verla ejecutada. Es posible que se acierte sin el usuario pero es más mucho más probable que se falle.

¿Y por qué el usuario no se implica?

– Se ha designado un responsable funcional o product owner que no quiere asumir sus responsabilidades o el trabajo que implica el mismo y la dirección del área usuaria no hace nada por arreglar esta situación.

– Puede darse el caso de que quiera hacer ese trabajo pero no se le han dado instrucciones precisas sobre qué tareas de las que tiene que atender son más prioritarias, por lo que tenderá a hacer las propias de su trabajo ordinario.

– También puede producirse el hecho de que sean sus propios jefes los que les obliguen a atender otras prioridades.

– Al área usuaria o al departamento TIC se les vendió un proyecto que pretendía cubrir una necesidad no existente y como tal, llegado el momento, se prefiere atender otras necesidades o trabajos más urgentes.

– El área usuaria apostó por el desarrollo ya que era una apuesta personal por parte de la dirección del área afectada y en un momento dado se produce un relevo en la misma que considera que existen otras prioridades.

– El área usuario y/o el responsable funcional se desaniman al no desarrollarse el proyecto según sus expectativas. Esto no quiere decir que se estén haciendo las cosas mal (que es posible) sino que no se han sabido gestionar sus expectativas,.

Causas puede haber muchas, pero el camino siempre debería ser el mismo en el caso de que se produzca esta situación y es que si no se consigue enderezar, lo mejor para todos es que se llegue a un acuerdo para dar por finalizado el proyecto y resolver el contrato (cuando proceda).

Ambos enfoques tienen en común las personas y en ambos juega un papel esencial el responsable funcional, product owner, área usuaria o como lo queramos llamar, en función de como esté organizado el proyecto y la metodología o estrategia utilizada.

Da igual cómo trates de enfocarlo, da igual que tengas grandes técnicos ya que si el usuario no colabora lo más probable es que la partida esté perdida. Es cierto que queda algún as en la manga, como que haya en el equipo personas con un gran conocimiento del negocio y de la organización y/o que haya algún sistema previo o en otra organización que pueda servir de referencia y se acierte.

No obstante la realidad es que resulta muy complicado acertar de esa manera porque se está trabajando a ciegas, sin recibir un feedback adecuado que permita ir perfilando los resultados.

Generalmente se suele tirar hacia adelante y con las especificaciones que se han podido obtener tratar de conseguir unos resultados: el proveedor quiere facturar y el cliente justificar la inversión realizada (sobre todo cuando ya se ha invertido un porcentaje más o menos significativo del presupuesto).

En este contexto suelen perder los dos y si gana uno es en detrimento claro del otro.

Si gana el cliente es porque al final hay un producto que puede satisfacer sus expectativas y si se llega a eso, tras un inicio nefasto y si no se ha invertido más dinero es porque el proveedor ha terminado tragándose todo el problema, convirtiéndose el proyecto en un agujero sin fondo, que nunca acaba y que solo ocasiona pérdida tras pérdida.

Si gana el proveedor es porque todos asumen que lo importante es conseguir un producto final, quedando en un aspecto secundario que realmente satisfaga las expectativas. No digo que no se quieran obtener buenos resultados, solo quiero decir que llegado el momento, muchos implicados querrán salvar los muebles y verán como única salida llegar a entregar algo.

En estas situaciones, la mejor salida, si no se consigue revertir el problema de la falta de implicación del usuario y no se asume el coste (ya sea inyectando más presupuesto o reduciendo el alcance), es asumir lo que hay y cerrar el proyecto.

Poco importa el enfoque si el destinatario de la aplicación no pone el interés o la dedicación necesaria al servicio del proyecto.

Un proyecto coral es aquel en el que muchos opinan y muchos toman decisiones tanto en lado de los desarrolladores como en el lado de los usuarios. En este tipo de proyectos sobran las palabras y falta responsabilidad porque cuando tantos intervienen cuesta que alguien asuma el papel de coordinador de su área.

Mi opinión es que se deben evitar este tipo de situaciones porque por intentar contentar a muchos se abre demasiado el sistema implementando funcionalidades innecesarias e incrementando su complejidad, todo esto en un contexto de falta de liderazgo y si eso se produce en el área usuaria y/o en el equipo de desarrollo tenemos un problema muy serio.

El área usuaria debe tener un Product Owner y el equipo de desarrollo un coordinador. ¿Qué dentro de cada área se quieren tomar decisiones por consenso?, ¿qué se quiere que participe y opine mucha gente? Me parece perfecto, pero el responsable de cada una de ellas lo es también de las decisiones que se toman y de las consecuencias de las mismas.

Soy partidario de no retrasar las entregas que se fijan. Es cierto que no siempre he pensado he pensado así y tampoco os puedo asegurar que mañana no cambie de opinión ya que independientemente de que uno tenga un background el presente condiciona, y mucho.

Si no se va a llegar y el incremento de la capacidad del equipo no es suficiente o incluso empeora la situación, la solución pasa por renegociar con el Product Owner, con el área usuaria o el cliente (en general) el alcance de la entrega.

Esto no es fácil, nada fácil. El usuario lo querrá todo (y más allá) y por supuesto, en plazos, independientemente de todo lo que haya ocurrido desde que se inició el proyecto, incluso siendo consciente de que el retraso no es imputable al equipo de desarrollo.

Si el usuario no quiere reducir el alcance o no lo hace de manera suficiente sí que hay que plantear un retraso en la entrega. No creo en el overtime impuesto directa o indirectamente en los desarrolladores, sí creo en la responsabilidad de los mismos y en su capacidad de administrarse el tiempo (son muchos los desarrolladores que no funcionan bien así y como digo siempre, mejor trabajar con personas que se adaptan a tu forma de entender el trabajo), por ese motivo no puedo ser partidario de soluciones que supongan overtime. Sí es admisible un pico de trabajo, pero por supuesto compensado de alguna forma (siempre equivalente a los resultados y esfuerzo realizado) y no puede ser prolongado en el tiempo.

¿Qué tampoco puede haber retraso? No hemos nacido para hacer imposibles y mi recomendación es que si se sabe de manera cierta que no se va a llegar, se escale el problema. Mejor ahora que dar sorpresas desagradables más adelante.

Ahora bien, si existen posibilidades de llegar en plazos hay que intentarlo, advirtiendo siempre al Product Owner de lo ajustado que vamos a estar y levantando la mano en el momento en que veamos que no vamos a llegar. Si el Product Owner no ha sido flexible a la hora de acotar el alcance, tampoco debemos serlo nosotros a la hora de realizar cambios que supongan una desviación sensible de los objetivos.

Reconozco que eso es antiágil y anti todo lo que entiendo que debe ser el desarrollo de software pero no puedo borrar la realidad y el contexto del proyecto es ese. El contexto manda, se será ágil en lo que se pueda, pero esas son las condiciones, esas son las variables que manejamos.