Cómo hacer un producto atractivo para los desarrolladores

Uno de los grandes estímulos de los desarrolladores es trabajar en productos atractivos. El concepto atractivo dependerá de la persona, desde que se utilice tecnología más moderna, hasta hacer productos expuestos al público o que sean divertidos. Sin embargo, como bien reflexionaba un amigo arquitecto, no hay proyectos/productos atractivos para todos, y esto provoca la gran rotación de las empresas. Sin embargo, hay mucho software que hacer, y estamos en un país donde no destacamos por hacer un gran desarrollo software. ¿Cómo podemos hacer atractivo un producto? 

La fábula de los obreros 

Cuenta la leyenda que una mujer visitó una obra donde trabajaban tres obreros. Se acercó al primero y le preguntó: “¿Qué es lo que haces?”. El obrero la miró con cara cansada y le dijo: “me dedico a colocar ladrillos”. Después, la mujer se acercó al segundo obrero y le hizo la misma pregunta: “¿A qué te dedicas?”. El segundo obrero la miró y le dije “estoy haciendo una pared”. Por último, fue hasta el tercer obrero y le repitió la pregunta: “¿A qué te dedicas?” Y el tercer hombre la miró con una sonrisa y le dijo “¿yo?, estoy construyendo la catedral más increíble que se ha hecho jamás”. 

Los tres parecían hacer lo mismo, pero cada uno de ellos lo mira con una perspectiva diferente. Un trabajo monótono puede ser motivante si somos capaces de tener una visión que nos permita crear algo superior a nosotros mismos. 

El Backoffice barato

Hace unos años, acompañé a un equipo que desarrollaba un backoffice para un gran supermercado. El objetivo del producto era gestionar con calidad todo el negocio con sus complejas reglas. Dieciocho meses después, el equipo salió a producción y estuvieron tres meses de estabilización. Cuando tenían la primera versión lista, tuve la siguiente conversación con el arquitecto:

Arquitecto: “Bueno, ya hemos acabado, ¡ha sido un éxito”

Yo: “¿Qué ha conseguido el cliente con este producto?”

Arquitecto: “¿Cómo?”

Yo: “Sí claro… hicimos este producto para sustituir el anterior… ¿Qué ha ganado el cliente? ¿Va más rápido? ¿Vende más? ¿Escala mejor?, ¿Cómo medís el éxito?”

Arquitecto: “No medimos nada de eso, pero ha sido un éxito porque solo hemos tardado 18 meses”

Yo: “¿Por qué eso es un éxito?”

Arquitecto: “Normalmente, se tarda cinco años en montar un backoffice, en año y medio ya lo hemos hecho, ha sido muy barato para el cliente”. 

Yo: “Mira un backoffice (mientras señalaba una lata de cocacola)”

Arquitecto: “Eso no es un backoffice”

Yo: “ya… pero es barato!”

Este es uno de los grandes males de muchos equipos, no ponen foco en los resultados de negocio. Precisamente, Scrum trata de maximizar el valor de negocio; sin métricas de negocio, no sabremos si tenemos o no tenemos un éxito. Una de los motivaciones de los buenos desarrolladores es saber que están aportando a su empresa y a sus usuarios. El trabajo de un equipo de software no es hacer software, es entregar valor. ¿Y si hicimos el backoffice equivocado?

Cómo hacer lo aburrido interesante

Recientemente, he podido acompañar a un equipo que iba a desarrollar un nuevo producto digital para sustituir uno ya existente. En esta empresa de gran tamaño, habían descubierto que su departamento de tecnología necesitaba transformarse, muchas de sus aplicaciones estaban dando problemas y no soportaban muchas mecánicas del negocio. Este producto consistía en introducir unos datos en un formulario muy pesado en el que se introducían artículos que se iban a vender. Los que comerciaban con esos artículos comprobaban que la información era correcta y, en caso de no serlo, descartaban la información para que se volviera a introducir. Desde el punto de vista objetivo, es un desarrollo aburrido, un formulario interno con muchos campos y poca capacidad de innovar. 

Sin embargo, eligieron para el desarrollo un empresa muy experta en desarrollo ágil de software. Esta empresa, decidió plantearle al cliente algo más profundo que un lavado de cara y meter microservicios: ¡Vamos a mejorar el negocio! Cada vez que un artículo se introducía mal, el comerciante perdía tiempo y esto iba en contra del negocio. Además, muchas veces esto desembocaba en llamadas al call center para que le explicaran cómo había que hacerlo correctamente. ¡Se estaba perdiendo mucho dinero! 

Este equipo realizó una serie de dinámicas de conceptualización para estudiar y plantear un nuevo producto que resolviera el problema. Empezaron a proponer diferentes soluciones que podrían plantearse: una ayuda interactiva que guíe al usuario, datos dinámicos que faciliten la comprensión, chat interactivo e inteligencia artificial que aprenda de los propios usuarios. Además, un sistema de entrega contínua que les permita obtener feedback temprano y tomar decisiones a medida que desarrollan el producto. ¡Acaban de convertir algo aburrido en un reto de equipo! Este equipo transmite niveles de motivación y energía muy superiores a la mayoría de equipos con los que he colaborado. Su planteamiento es centrarse en el usuario, entregarle un software que de verdad le aporte y, de manera indirecta, aporte a la organización. Es cuestión de hacer catedrales impresionantes donde otros solo ven ladrillos. 

Déjame cambiar el “coche” 

Hace unos meses, pude acompañar a una pequeña empresa que desarrollaba productos bastante innovadores relacionados con el mundo del call center y los leads. Tenían un producto con el que la empresa vivía, generaba dinero, pero se estaba quedando obsoleto y con un coste de mantenimiento cada vez más elevado. A la vez, la empresa estaba apostando por construir un nuevo producto para segmentos de usuarios que, en ese momento, no estaban atacando. Gracias a este segundo producto innovador y con tecnología actual, estaban consiguiendo atraer talento a la empresa. 

Muchas veces estos desarrolladores se frustraban porque el nuevo producto dependía muchísimo del antiguo, y esto hacía que tuvieran que hacer “ñapas” sobre su código. En la compañía se motivaba a las personas llevándolas al nuevo producto, ya que el antiguo era una fuente de insatisfacción. 

Un día, un arquitecto senior habló con el resto del equipo y dijo: “a nosotros no nos importa trabajar en el producto antiguo, ¡pero que nos dejen modificarlo!” El arquitecto planteaba una reestructuración y actualización del producto antiguo para hacerlo más sostenible, más atractivo y sobretodo… ¡Entregar mayor valor al negocio! Con un producto más actual, reducirían mucho el coste de mantenimiento, el número de caídas del servicio, y en definitiva, el servicio que se prestaba a los clientes mejoraría. Además, tendría un efecto colateral, y es que atraería a más desarrolladores que quisieran trabajar en ese producto (algo que ahora costaba muchísimo). Este arquitecto se unió con su equipo para plantear un plan a la dirección: “ha llegado el momento de cambiar el coche en vez de seguir arreglándolo, o estamos muertos”.

La importancia de la visión

Cuando desarrollamos software, es vital tener clara la visión, lo que queremos hacer. Tener un propósito que sea superior al equipo es uno de los factores que hacen que los equipos triunfen. Tener métricas de valor y hacer ver a los equipos que el objetivo es mejorar esos datos. Dar espacio para la autoorganización y dejarles tomar decisiones. Todas estas acciones hacen que motivemos a los equipos, y esto atrae a los mejores desarrolladores. Nos guste o no, tenemos un problema de talento en las organizaciones que piensan que la motivación se basa en factores externos.

Y tú, ¿cómo haces atractivos tus productos para quiénes van a fabricarlos?