archivo

Archivo de la etiqueta: responsable funcional

Contra esta situación no hay metodología o estrategia que la resista, sin buenas especificaciones el producto final se encontrará lejos de las expectativas del usuario, sin colaboración efectiva de un responsable del producto por parte del área usuaria no habrá un buen feedback ni una buena priorización en la línea de desarrollo de la aplicación, sin un usuario que esté accesible se producirán fases de bloqueo en el proyecto que en muchos casos (la mayoría) solo se resolverán tirando hacia adelante.

Y no es que no puedas hacer un buen análisis, ni siquiera vas a poder hacer una buena definición de sprint. ¿Qué pasa al final? El presupuesto se ha esfumado y el producto está todavía a medias o no hace lo que el usuario quiere, esto es igual a mucho desgaste y a pérdidas de dinero por ambas partes.

Es cierto que los desarrolladores hemos hecho mucho daño al negocio del desarrollo de software pero las personas que se han designado como responsables del producto por parte de los clientes también.

Y este problema lo tenemos tanto en enfoques clásicos como en enfoques ágiles de desarrollo de software porque en ambos casos necesitamos al usuario.

Un proyecto de desarrollo de software requiere que los responsables del producto estén muy implicados y con una alta dedicación al mismo, si la persona designada no puede dedicar ese tiempo necesario lo mejor es que delegue el día a día en otra persona dándole autonomía para la toma de decisiones (independientemente de que determinadas cuestiones las deba consultar).

Si no es posible de ninguna forma asegurar esa dedicación habría que pensarse muy seriamente por ambas partes si merece la pena afrontar el trabajo y si por el motivo que fuera se tuviera que llevar a cabo habría que explicar muy claramente los riesgos y las consecuencias de esta incertidumbre y falta de implicación en los costes finales.

Nos encontramos con la siguiente situación: tenemos un sprint en el que es necesario modificar una funcionalidad crítica del sistema (motivada, por ejemplo, por un cambio normativo) y se tiene que hacer de una vez (no podemos dividirla en historias más simples) ya que si no se ejecuta de esa manera no va a funcionar cuando la pasemos a producción.

En ese sprint, además, hay otras historias de usuario que se están desarrollando y en un equipo en paralelo tenemos a personas solucionando incidencias, cuya entrega se iba a sincronizar con el sprint. En un determinado momento, nos damos cuenta de que no vamos a tener la funcionalidad lista para la fecha de finalización del sprint, ¿qué hacemos?.

Hay diferentes posibilidades. La solución a aplicar podría ser diferentes en cada proyecto:

– Lo más tentador es retrasar la fecha de finalización del sprint. A mi personalmente no me gusta y creo que solo se debería hacer en el caso de que no hubiera otra salida. ¿Por qué? Creamos un precedente y más pronto que tarde nos volveremos a encontrar con una nueva situación, en este caso con menos criticidad, en la que se termine aplicando la misma solución y se entra de esta manera en un bucle nada beneficioso.

– Reducir el alcance del sprint, centrando los esfuerzos en la funcionalidad crítica. Podría funcionar si se detecta pronto la desviación y si el fallo en la estimación del esfuerzo de construcción de la funcionalidad crítica no es muy sensible. Si se aplica esta estrategia habrá historias de usuario comprometidas que no se podrán completar.

– Incrementar la capacidad del equipo. Esto solo va a funcionar si las personas que se incluyen en el equipo conocen la tecnología, las dinámicas de trabajo o si las tareas a realizar no requieren ese nivel de especialización. Podría valer con incrementar la dedicación de personas que no estén a tiempo completo en el proyecto o pasar personas del equipo de resolución de incidencias al equipo del sprint. Esta estrategia podría combinarse con la anterior.

– Completar la funcionalidad crítica en el siguiente sprint, es decir, el sprint termina con las historias de usuario que se hayan podido completar y en el nuevo sprint se sigue trabajando con ella.

La decisión a adoptar debe contar con el consenso del responsable funcional porque afecta a los plazos en que determinadas funcionalidades se incorporan, modifican o corrigen en el sistema, también es importante mantener la calma con el objeto de aplicar la solución más adecuada. En la retrospectiva es fundamental que se analice en qué se ha fallado y se tomen las medidas oportunas para reducir la probabilidad de que este problema se vuelva a producir en un futuro.

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).

Niklaus With dijo (traducción libre): “Uno de los principales motivos de la complejidad es que los proveedores de software adopten sin crítica casi cualquier característica que los usuarios desean”.

Se puede adaptar la postura cómoda, que no quiere decir que sea sencilla, de limitarnos a recoger las especificaciones de los usuarios sin expresar una visión crítica.

Esto implica que nos guardaremos la opinión sobre la complejidad o simplicidad de la solución planteada, sobre la conveniencia de priorizar determinadas tareas sobre otras, en definitiva, no ponemos a disposición del product owner o del responsable funcional nuestro conocimiento y experiencia.

El desarrollo de software debe ser colaborativo porque las perspectivas, habilidades, conocimientos y experiencias del conjunto suman siempre más que cada una de ellas por separado.

¿Por qué adoptar esa posición? A veces, en función de la naturaleza del product owner, la confrontación de las opiniones puede originar desgaste y en cualquier caso siempre vas a trabajar más ante la necesidad de argumentar tus opiniones y de consensuar soluciones.

Sin embargo, en muchas ocasiones, la elección de esa postura es el resultado de arrojar la toalla como consecuencia de que el usuario ni quiere ni se deja asesorar.

El product owner debe definir la línea de desarrollo del producto, es su responsabilidad, pero también debe tener la capacidad de escuchar las recomendaciones de todo el conjunto de personas que colaboran en el proyecto, si deja esto de lado, probablemente la obtención de valor será más lenta y el producto resultante en cada iteración tendrá un nivel de complejidad mayor al necesario.

Los desarrolladores deben aportar, no solo su capacidad para desarrollar el software, sino también poner en valor su perspectiva y experiencias.

Esto del desarrollo de software se debe basar en condiciones de equilibrio. Bastante complejo resulta hacer este trabajo como para tener que estar constantemente a contracorriente.

En un proyecto de desarrollo de software son tantas las variables que intervienen que resulta muy complicado mantener ese equilibrio y será necesario el esfuerzo y voluntad de muchas personas para tratar de crear un contexto en el que por término medio se consiga.

Precisamente hay un factor que afecta en gran medida a ese equilibrio y es que las partes implicadas asuman de verdad el rol que tienen que desempeñar en el proyecto. En muchas ocasiones nos encontramos con responsables funcionales que huyen de su responsabilidad, en otras en donde tratan de imponer un criterio sin escuchar las recomendaciones o consejos de terceros y en otras en donde determinadas personas del equipo de desarrollo son las que tratan de que el producto vaya en la dirección y sentido que ellos estiman más conveniente.

Todas esas situaciones darán lugar, muy probablemente, a malos resultados. Seguro que se os ocurren ejemplos que hayáis vivido en primera persona lo que os estoy contando.

El responsable funcional es quien debe definir las prioridades y la línea de desarrollo del producto pero no debe prescindir del asesoramiento del equipo de desarrollo, entre otras cosas porque independientemente de que puedan conocer mejor o peor el negocio, saben de desarrollo de software.

Por otro lado, tampoco resulta razonable que sea el equipo de desarrollo el que defina el sistema porque no hay que olvidar que el producto no es para ellos y que hacer un producto de esta forma tiene todas las papeletas de que no se aproxime a lo que realmente los usuarios esperan y necesitan.

El proyecto se queda sin presupuesto, al menos, a corto y medio plazo y los responsables funcionales entienden que existen funcionalidades que son necesarias para que el producto sea de utilidad o para que la productividad en el uso del mismo sea aceptable.

¿El problema? No hay dinero para hacer todo lo que necesitan, ¿cuál es la primera consecuencia? Desgaste, incluso en situaciones donde el desarrollo haya sido fluído. A los usuarios les entra el síndrome de la última versión y el proveedor de servicios de desarrollo por muy flexible que sea tendrá que mirar por los resultados económicos del proyecto.

Gestionar bien esa circunstancia tanto por parte del cliente como del proveedor es esencial ya que se puede tirar por tierra todo el esfuerzo de meses de trabajo. No es sencillo porque todos sabemos lo complicado que resulta cerrar un proyecto.

No existen fórmulas mágicas, solo el sentido común, la búsqueda del beneficio mutuo y un autoanálisis crítico del trabajo que se ha realizado en el proyecto con el objeto de asumir responsabilidades (si existen). Si ambas partes quieren se puede alcanzar un acuerdo satisfactorio, si una de ellas se resiste probablemente terminen perdiendo ambas.

Además de lo anterior, la solución ideal pasaría por dotar al proyecto del presupuesto adicional necesario para terminar de manera adecuada los trabajos, si bien pueden existir circunstancias que lo impidan o, al menos, que lo impidan temporalmente.

Recordemos que lo realmente importante es el valor del proyecto y su relación adecuada con la inversión realizada y no acertar con una estimación inicial que todos sabemos (cliente y proveedor) cómo está hecha. Si tu objetivo es hacer que la estimación sea acertada tal vez te lleves ese logro pero tal vez, también, el proyecto se quede a medias o se entregue un producto deficiente,

Realizar una correcta gestión de las expectativas es fundamental en todo proyecto de desarrollo de software. Hay que ser muy constante en este aspecto porque aunque se piense que las expectativas están bajo control, las mismas van a variar con el tiempo, ya sea por la propia evolución del proyecto o por presiones que se reciban desde el exterior.

Los responsables funcionales te van a apretar porque tienden a exigirte un mayor alcance y en un menor tiempo de lo pactado. Tienen que comprender (y tener una cierta experiencia) cómo funciona un proyecto con prácticas de Scrum para que sean más moderados en sus peticiones de modificación del sprint, sin embargo, cuando ellos mismos están recibiendo presiones, les resulta complicado no traspasarte, aunque sea, parte de ellas.

Precisamente por este motivo se agiliza en muchos casos las prácticas de Scrum con Kanban, pero esto simplemente trata de definir determinadas reglas del juego, la complejidad realmente se encuentra en mantener un equilibrio entre lo que el usuario desea y lo que realmente se puede hacer (o lo que realmente se considera práctico realizar), porque está claro que el usuario manda, pero también debe ser consciente, y para eso estamos nosotros, de la complejidad que tiene la realización de una determinada solución.

Es importante poner las cartas sobre la mesa y a partir de ahí que decida. No vale con ser simplemente ejecutores de historias de usuario, también tenemos que proporcionar ese valor a los product owners porque se trata de aprovechar de la mejor manera posible la inversión, de manera que consigamos ganar el mayor valor posible con el menor esfuerzo y de no complicar de manera innecesaria el producto.