¿Realmente dar valor a negocio es tu objetivo?

1

Creo que sea cual sea tu orientación a la hora de trabajar, todos estaremos de acuerdo en que lo más importante es maximizar el valor entregado a negocio, signifique lo que signifique eso. Y de hecho diría que es uno de los pilares, si no es el pilar principal, sobre el que se asienta toda la cultura de desarrollo de software ágil. Pero creo que es fácil confundir lo que significa entregar valor a negocio y que, en pos del agilismo puro, a veces se olvida que el objetivo principal es entregar valor a negocio.

Cualquier “practicante” de las metodologías ágiles (y aquí digo metodología con un toque sarcástico) sabe, o cree, que la mejor manera de entregar valor a negocio es haciendo entregas tempranas de valor y comprometiéndose a los objetivos marcados en el sprint. Pero ese seguimiento ciego de una forma de trabajar, sin tener cintura para poder adaptarse a la realidad de cada momento, les lleva a no entregar valor en un montón de aspectos. Voy a citar unos cuantos.

Las estimaciones a largo plazo dan valor a negocio

Las organizaciones suelen tener una planificación, y necesitan saber cuando tendrán determinadas cosas, porque tienen que prepararse o tomar decisiones en base a eso.

Por ejemplo, podemos tener un catálogo de mierda (como me gusta esta palabra) de nuestros productos on-line. Es una mierda porque la aplicación que tienen para gestionarlo es una mierda, y porque nadie se ha preocupado en generar contenidos de calidad. Así que negocio se plantea rehacer el catálogo en ambos sentidos. Necesita cambiar la aplicación y cambiar los contenidos. Pero… ¿si se va a cambiar la aplicación, conviene cambiar los contenidos antes o esperarse a que esté la nueva? Pues depende de lo que se tarde. Si son dos o tres meses, esperamos. Si es medio año, no esperamos. No podemos llegar a la temporada de rebajas sin el catálogo sano.

En otros casos habrá que contratar gente para un nuevo sistema, y esa gente necesita un par de meses de rodaje antes. Así que, ¿Para cuando estará y así los contrataremos dos meses antes?

Decir “somos ágiles, no estimamos más allá del siguiente sprint” no es entregar valor a negocio.

Los compromisos de fechas dan valor a negocio

La parte anterior, en ocasiones, es a veces tan importante, que hay que comprometerse con una fecha. Y la fecha puede llegar a ser más importante que la funcionalidad o la calidad.

Esto parece una animalada, pero la realidad es que es así. Por ejemplo, en el mundo del turismo están las ferias. Si estás en una empresa española teniendo como mercado principal España, FITUR es tu feria. FITUR es el momento en el que cientos de clientes potenciales te van a ver. Y es el momento en el que te encontrarás con tus clientes habituales, que quieren ver los avances. Decirles que la semana que viene lanzamos tal producto no es lo suyo. El producto se lanza en FITUR. El negocio necesita un compromiso de una fecha. Necesita el producto en FITUR funcionando.

Podemos tener compromisos legales. Compromisos comerciales. Al CEO se le puede hinchar la boca con un gran cliente y decirle que tal día tiene tal cosa. Si no está tal día, la credibilidad del CEO, y de toda la organización, cae por los suelos. Y esa credibilidad tiene mucho valor. Tiene que estar en esa fecha. Otra cosa es si el CEO debería haberse callado la boquita. Pero una vez está el compromiso en la mesa, hay que llegar.

Decir que “Si somos ágiles no podemos comprometernos en fechas” no es entregar valor a negocio.

Resolver las incidencias ASAP es entregar valor a negocio

Este es un tema recurrente que veo en muchos sitios. Llega una incidencia y, a la cola. Ya la haremos en el siguiente sprint. ¿WTF?!?

Una incidencia es que lo que has entregado no va. Incluso si no lo entregaste tú, es algo de lo que eres responsable y no va. Decir por norma que si no entra en la planificación del Sprint, no se hace, es retrasar toda resolución de incidencias. Y muchas incidencias no pueden esperar. Te aseguro que con esta política cabrearás y mucho a negocio.

Y ¿Sabés que cabrea también mucho a negocio? Que una incidencia lleve un mes esperando a ser tratada y que la respuesta sea: “Es que has configurado mal eso. Aquí hay que marcar una casilla”. O sea que con 10 minutos de revisión ya veías lo que pasaba, pero como no estaba en el Sprint, ni siquiera la hemos leído.

Decir que “Somos ágiles y nos comprometemos con el objetivo del sprint, y sólo con el objetivo del sprint.” no es entregar valor a negocio.

No solo programar es entregar valor a negocio

Sois programadores (y programadoras, que cada vez hay más) y vuestro trabajo es programar. Pero a veces negocio necesita otras cosas y el equipo de desarrollo es el mejor preparado. ¿Una formación? ¿Un manual? ¿Un video-tutorial? Son cosas que negocio podría valorar mucho.

Pero veo mucha gente que dice que eso no le gusta, que son programadores (o programadoras) y que ese no es su trabajo. Que lo haga el Product Owner, o que lo haga un key user. No es la primera vez que lo digo, ya lo comenté en “Técnicos demasiado exquisitos”. Y también parece que el Product Owner está heredando ese mal que tenían los Project Manager y que comenté en “Iohannes Fac Totum”.

Decir que “Yo soy programador y programo. Lo otro que lo hagan otros.” No es entregar valor a negocio.

Conclusiones

Creo que todo esto se resume a no empatizar con negocio. Se resume en no entender lo que realmente necesita negocio y entregarnos devotamente a ello.

Y todo también se resume en ver la cultura de desarrollo ágil como una metodología que aplicaremos caiga quien caiga. Las reglas son las reglas, y me da igual si eso no ayuda a negocio.

Por eso, y volviendo al título: ¿Entregas realmente valor a negocio, o sólo sigues las reglas?

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 6 febrero, 2019 at 16:28 Responder

    Excelente post Jose, un gusto leerte…
    Considero que las reglas deben tomarse pero no como leyes!!!. Esto seria como contratar un pintor, le digo que quiero pintar la pared azul y los marcos de las ventanas rojos, y cuando va a pintar los marcos le digo que no, que decidi barnizarlos y el tipo me diga que no!, podemos hablar que al hacer cambios, al tener que hacer arreglos de incidencias, etc pueden cambiar los tiempos pero no que no se hace!!!

Post a new comment