A negocio le gustan los proyectos

1

Y a los programadores les gusta el desarrollo ágil. Dos mundos, dos visiones en muchas ocasiones antagónicas, que chocan y frustran al Product Owner, o al que esté dando la cara con negocio.

Parece que de nacimiento estamos programados para que cuando alguien hace algo para nosotros, lo enfoquemos como un proyecto. Encargamos algo y enseguida lo desgranamos en fases, y queremos saber fechas de cuando va a estar. Es normal que nuestros clientes actúen con nosotros de la misma manera. Intentamos explicarles eso de iterar, de ir haciendo entregas de valor tempranas, de aumentar la velocidad de desarrollo, y todos esos conceptos, pero ellos siguen preguntando: “ya vale, pero ¿esto cuándo estará?”

Es inevitable, a negocio le gusta pensar que nuestro trabajo son proyectos. Les pones una lista de épicas, con las historias que tienen dentro, clasificadas por prioridad, y no lo acaban de ver. Les pones un Gantt y lo mirarán con los ojos abiertos de par en par. Les dices que iremos sacando el trabajo por prioridad, que podrán ir cambiando el resultado en todo momento, y no lo entienden. Les pones fecha de entrega para cada una de las partes y se quedan tranquilos.

¿Por qué sucede esto? ¿Por qué a los técnicos, cuando nos cuentan esto del desarrollo ágil, lo vemos positivo y en cambio nuestros clientes, que serán los más beneficiados, no lo ven?

Sinceramente, creo que es natural. Como comenté en mi artículo sobre la metáfora de la construcción y la programación, todo el mundo entiende más o menos como se construye una casa, pero pocos entienden como se construye una aplicación. Es decir, no nos entienden. A lo mejor las generaciones futuras, en las que la programación sea una asignatura más en el cole, no tendrán este problema. Pero hoy en día lo tenemos.

Un caso especial son las fechas de entrega. Les encantan. Y esto puede quemar al Product Owner, con un equipo que va haciendo según avanzan los sprints, y unos usuarios que no paran de preguntar cuando estará acabada la nueva web. Las fechas les gustan por varios motivos. Por un lado porque realmente les dan valor. Ya os comenté en “¿Realmente dar valor a negocio es tu objetivo?” que las estimaciones a largo plazo pueden tener mucho valor cuando negocio necesita adaptarse a ellas y elaborar una estrategia. Pero también porque dan la sensación de seguridad de que han creado una presión. Una tarea que te van a hacer “lo antes posible” no parece que tenga tanta presión como una que te dicen “lo entregaremos en 3 días”. Y lo peor de todo es que es verdad. Cuando das una fecha, y te pones la soga al cuello, es un motivo para sentir presión.

Hace años un compañero me dijo que los Project Manager en entornos ágiles tenían como misión traducir de Ágil a Proyectos. Traducir en el sentido de hablar en términos de desarrollo ágil con el equipo, y traducir en términos de proyectos a la hora de hablar con negocio. Por supuesto, hace ya mucho tiempo de esa frase. Hoy en día probablemente la frase sería que una de las misiones del Product Owner es traducir el trabajo del equipo a términos de gestión de proyectos. Y la verdad es que no estoy 100% convencido de ello, pero creo que algo de verdad sí que esconde.

Hablamos mucho de entregar valor, de adaptarnos a las necesidades de negocio, de responder a los cambios. Pero todo esto es a condición de que las cosas se hagan como nosotros decimos. Les obligamos a trabajar de la manera que nos gusta. ¿Es eso adaptarnos a sus necesidades?

Si a negocio le gusta el lenguaje de proyectos, le gusta colocar esos bloques unos detrás de otros y poner fechas estimadas, ¿Por qué no hacerlo? No hablo de que nos pongamos a planificarlo todo con Gantts, pero sí que el Product Owner traduzca esto al lenguaje que ellos entienden. Por supuesto que si tenemos sprints, negocio será consciente de ello. Es inevitable. Pero un calendario con los bloques de cuándo esperamos realizar cada épica (que ya os dije que en el fondo una épica es un proyecto) al estilo de una planificación, seguro que es de gran ayuda. Y cada mes lo actualizamos, si las fechas se mueven, pues se mueven, algún motivo habrá.

Nos debemos a negocio. El idioma de negocio está más cerca de los proyectos que del desarrollo ágil. Está claro que podemos enseñarles nuestro idioma. Pero, si queremos darles el mayor valor posible, ¿Por qué no hablar su idioma?

Sobre el autor

Jose M. Huerta

Jose es Gestor de TI en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de desarrollo de software, usando metodologías clásicas, o desarrollo ágil, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

1 comment

  1. Gonzalo 18 febrero, 2019 at 16:16 Responder

    Yo trato de llevar lo agil con lo pm tambien… a mi no me molesta es mas tener vision futura me sirve para saber como vamos.. creo que hay proyectos y proyectos, es decir uno donde estamos innovando, creando algo nuevo sin saber bien que todavia (algo como investigacion, etc) y en esos si no se que voy a hacer bien, depende de que tomemos como decision dentro del sprint, pero en los que muchas veces son conocidos o tienen que calzar en una estrutura ya montada, entonces si tal vez no este todo, pero tener vision de esto estara en este sprint, y esto 5 mas adelante… pero eso si pudiendo cambiar las cosas de orden etc no rigido… y si cambia el scope y bueno cambiamos todo…

Post a new comment