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.

El desequilibrio más habitual que nos encontramos en los proyectos de desarrollo de software son aquellos provocados por la falta de implicación del área usuaria. Este desequilibrio suele ser provocado cuando el promotor de la iniciativa que ha dado lugar al proyecto no deja bien claro a la persona o personas que ha dejado a cargo de la definición de la aplicación cuáles son sus responsabilidades y prioridades. También (y en cierto modo por la falta de implicación de las personas designadas) esta falta de equilibrio se produce cuando el equipo de desarrollo cree tener un conocimiento del negocio lo suficientemente importante como para que la opinión de los usuarios quede relegada a un segundo plano.

Es menos habitual pero no por ello raro, encontrarnos con proyectos donde el área usuaria asume el control de tal forma que hasta influye en aspectos técnicos, condicionan la solución técnica más allá de lo que se debiera o entran en la gestión interna del equipo de desarrollo definiendo plazos y/o asignando tareas.

No se trata de que lo funcional y lo técnico estén separados por un muro sino de respetar el espacio que tiene cada uno y escuchando las propuestas que la otra parte hace y consensuando soluciones. Todos nosotros hemos vivido proyectos en donde no existe equilibrio y los resultados no suelen ser buenos.

Sobre este asunto, Mike Cohn realiza la siguiente reflexión: “Para tener éxito, un proyecto debe haber recibido información de personas muy diferentes: por un lado los clientes, por otro lado el equipo técnico. Si cualquiera de ellos domina la comunicación, el proyecto pierde”.

Mike Cohn es un consultor que lleva desde el año 1995 aplicando estrategias y metodologías ágiles en proyectos de desarrollo de software en una amplia variedad de organizaciones, tipos de negocio y contextos. También es autor de varios libros y numerosos artículos sobre la materia.

De por sí podemos hacer una fiesta si el cliente o el área usuaria nombra un responsable funcional o un dueño de producto y éste asume su rol en el proyecto y no hace lo que la mayoría: ser alguien que actúa de manera reactiva, que solo asiste a reuniones (en la mayoría con desgana y sin hacer sus deberes), para el que el proyecto es algo secundario (en el mejor de los casos) y que no se quiere responsabilizar de nada.

Asumir su rol es entender también que actúa como representante de todo el área usuaria por ese motivo las decisiones que tome no se deben centrar en la visión que tenga sobre el proceso o procesos que se quieren informatizar sino que también debe tener en cuenta otras visiones ya que lo mismo su visión de los procesos es muy sesgada o demasiado idílica.

Esa estrategia debería aplicarla en todos los casos, si bien cobra especial relevancia cuando buena parte de esos procesos no se ejecutan en la sede central de la organización sino en sus delegaciones. En las mismas siempre existe un gran recelo de todo lo que viene desde la sede central porque tienen la sensación (fundada en muchos casos) de que no se les tiene en cuenta para nada, lo que dificultará la implantación del producto, algo que todavía se agrava más si la ejecución informática del proceso no se ajusta a la realidad de su trabajo.

Llevar a cabo esta misión supondrá un esfuerzo y desgaste importante para el responsable funcional pero debe hacerlo y tiene que encargarse de proporcionar una visión común al equipo de desarrollo.

Poner en producción y de golpe un sistema de información de un tamaño medio/alto puede provocar una situación de crisis que acabe con el propio sistema.

A la oposición inicial que tendrá la nueva herramienta por el simple hecho de modificar hábitos ya adquiridos se le suma que, salvo que se haya acertado muy mucho en la fase de análisis, el proceso o procesos que se informatizan hayan permanecido estables y se tenga muy controlada la aplicación de los procesos entre quiénes trabajan en los mismos (algo que se complica cuanto más descentralizada es una organización), se empezarán a solicitar cambios de todo tipo en el sistema y probablemente se dispongan de pocos medios para ejecutarlos ya que el esfuerzo se habrá centrado en el desarrollo del producto.

En esta situación los usuarios empezarán a decir que el sistema no se ajusta a sus necesidades y se quejarán de que el tiempo de respuesta para realizar dichos cambios es muy alto, ejerciendo presión a sus superiores indicando que la disminución de su rendimiento y productividad es debida al sistema de información.

No entro a valorar el comportamiento de los usuarios ya que en cada caso su intención puede ser diferente, lo que sí entro a valorar es que resulta complicado dar una respuesta cuando se tiene que actuar sobre un sistema grande y no se disponen de los medios adecuados para llevar diversas líneas de trabajo en paralelo.

Por este motivo el enfoque iterativo incremental no solo me parece la respuesta más natural a las problemáticas del proceso de desarrollo, sino que también resulta la solución más adecuada a la hora de realizar la puesta en marcha de un nuevo sistema, ya que se encontrará acotado el posible marco de actuación a los diferentes módulos que se vayan liberando de manera que se puedan centrar los esfuerzos en ir mejorándolos o corrigiéndolos en base al feedback del usuario y de esta forma no tenemos que estar intentando sofocar más fuegos que los que realmente podemos tratar.