Chess - antoniomartel.com

Archivos por Etiqueta: Ágil

Esfuerzo y práctica

Hace muchos años, cuando se comenzaba a conocer cosas sobre la plasticidad del cerebro humano, su capacidad para regenerarse o adaptarse y que con la práctica y la estimulación de ciertas zonas se podían mejorar sus resultados, se pidió a grandes genios de la época que, una vez fallecieran, donaran sus cerebros a la ciencia (curiosamente nadie quiso hacerlo antes).

Los científicos querían estudiar qué tenían estas personas de especiales y, una vez descubierto, su idea era que todos pudiéramos estimular y ejercitar estas zonas para convertirnos en genios de la humanidad.

Pero después de estudiar unos cuantos cerebros, no encontraron nada de especial. Ni las neuronas iban más rápido, ni tenían una cantidad especial de conexiones entre ellas, ni nada de nada. Lo único que encontraron es que tenían una zona del cerebro hiper-desarrollada, más grande de lo normal. Era una zona dedicada a la memoria y que el cerebro utiliza para recordar cosas, pero que los científicos ya habían visto desarrollada así en taxistas de Londres.

Londres es una ciudad gigantesca, con miles y miles de calles y los taxistas que llevan muchos años trabajando en ella son capaces de recordar de memoria un gran número de calles. Obviamente, los taxistas de Londres no son genios (al menos no todos ellos). Entonces ¿qué hacía tan especiales a esos premios Nobel que donaron su cerebro a la ciencia?

Fue unos años más tarde cuando surgió otra teoría que trataba de explicar este fenómeno. Era la llamada teoría de las 10.000 horas del libro Outliers. Esta teoría decía que la gente que destacaba en sus profesiones o deportes era debido a que había invertido a lo largo de su vida unas 10.000 horas en perfeccionar su técnica.

Se había visto que el primer violinista de una orquesta contaba con 10.000 horas de práctica, el segundo sólo 7.000 y así consecutivamente. Lo mismo para el cirujano principal de un hospital o el golfista que destaca ese año en el campo.

Macauley, una gran jugador de baloncesto en los años 50 que fue el primer MVP en un partido all-star, decía ‘Si no estás practicando, alguien, en algún lugar, lo está haciendo, y cuando te enfrentes a él, te va a ganar‘.

Pero (de nuevo hay un pero) esta teoría tampoco lo explica todo. Todos conocemos a balocentistas, golfistas o jugadores de fútbol que llevan más de 10.000 horas de práctica y nunca van a llegar ni a tercera regional (no quisiera vivir cerca del violinista que después de 2.000 horas de práctica aún está ensayando canciones de principiante).

Aquí es cuando llega una tercera teoría que explica que lo que tenían estas personas en sus cabezas no era más que curiosidad. Sí, simple curiosidad. Ganas de hacer, de saber, de comprender o como lo queramos llamar.

Esto es lo que hacía que esos genios que donaron sus cerebros tuviesen el suficiente entusiasmo como para dedicar 10.000, 20.000 o más horas de su tiempo a lo que les apasiona, probando cosas diferentes cuando algo no les funciona e intentando cosas nuevas que les lleve por caminos distintos.

Así que si quieres convertirte, por ejemplo, en un experto arquitecto Java, ya sabes más o menos el esfuerzo que tienes que ponerle. Por otro lado, asegúrate de que te gusta mucho a lo que te vas a dedicar. Vas a invertir ahí mucho tiempo y si no te apasiona lo que haces vas a ser difícil que llegues a un nivel avanzado. 1000 horas repitiendo lo mismo no suman más que las 50 primeras que fue lo que tardaste en aprenderlo.

Referencias:

  • Outliers, Malcom Gladwell.
  • Agile Innovation, Langdon Morris

Requisitos que pueden cambiar

Hace ya unos cuantos años, antes de aplicar por completo todo esto de agile, trabajé en el desarrollo de una aplicación web que debía gestionar las fichas de trabajo del cliente mediante una serie de pasos o wizard que guiase al usuario sobre la fase en la que estaba.

Realizamos un análisis completo, recopilamos todas las necesidades que el cliente tenía y de ahí salieron una lista de funcionalidades a implementar. Todo normal. Funcionalidades correctas y coherentes que solucionaban problemas concretos. Con el grueso documento de requisitos y su correspondiente diseño nos pusimos a implementar, una tras otra, cada una de estas funcionalidades.

En aquel momento ya intentamos ser algo ágiles (some way) e íbamos enseñando en pre-producción cada dos semanas lo que íbamos haciendo. No tenía mala pinta. Era fácil de usar e incluso nos dieron la enhorabuena por el trabajo que iban viendo. Estábamos contentos por lo que continuamos así hasta desarrollar con no poco esfuerzo hasta la última de las funcionalidades que estaban en el documento de análisis aprobado. Y subimos a producción…

En cuanto los administrativos estuvieron unos días usando la aplicación se dieron cuenta que habrían venido bien algunos cambios: incluir una tabla en cada pantalla con los documentos originales para no perderlos de vista, evitar salir a otro menú cuando se quiere crear una entidad, añadir más controles para evitar errores al finalizar una ficha, etc. La mayoría eran pequeños cambios que no llevarían más de 2 o 3 días de desarrollo pero nosotros ya habíamos acabado el presupuesto (y más).

Entre las funcionalidades que habíamos desarrollado al principio, había algunas de bastante complejidad que te permitían complicados cambios entre procesos, y que costó bastante desarrollar (y testear para tener en cuenta todos los posibles casos). Pregunté por ellas meses después pero nadie sabía de su existencia ni en qué menú estaban. Tampoco le dieron importancia. Cuando habían necesitado algo parecido cancelaron el proceso y empezaron uno nuevo.

Cuando empezamos el proyecto, ni yo, ni el cliente, ni los usuarios teníamos una idea exacta de lo que iba a funcionar bien. Simplemente no podíamos saberlo a ciencia exacta. ¿Qué podíamos haber hecho para evitar esto? Pues subir a producción en cuanto tuviésemos las funcionalidades básicas para los primeros procesos. Ahí habríamos visto con facilidad todos estos pequeños cambios que habrían hecho la aplicación más práctica y fácil de usar.

Desde entonces, en nuevos proyectos, cuando los usuarios ven la necesidad de cambios como éstos, me preguntan por la posibilidad de incluirlos. No tienen ningún problema en descartar otras funcionalidades de las que ya ni se acuerdan porqué las pusieron en los pliegos de contratación o a las que ahora no le ven tanto sentido.

La lista de funcionalidades está estimada desde el inicio en el product backlog y el cliente conoce esta estimación. Simplemente nos dice ‘Quítame la funcionalidad número 18 que llevaría 8 días de trabajo y cámbiamelas por estas dos nuevas que suman 6. Guardamos estos dos días por si solicitásemos algún cambio más‘.

Éste es otro de los principios ágiles:

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

En general supone una ventaja para el cliente que obtiene un producto que le funciona y que no queda cojo hasta que se realice una nueva contratación para un mantenimiento evolutivo (a pagar con dinero extra), pero también es una ventaja para nosotros como proveedores que sumamos un proyecto que nos sirve referencia, en el que controlamos bien cada hora invertida y evitamos entregar un producto, en el que gastamos todo el presupuesto y al que le faltan cosas importantes.

Principios detrás del movimiento ágil

Hace casi 15 años, en 2001, se reunieron en Utah diecisiete profesionales del software críticos con los modelos de desarrollo de software que se llevaban hasta entonces. Los consideraban demasiado pesados o rígidos. En esa reunión estaba gente como los fundadores de Scrum o Kent Beck y Martin Fowler. Habían quedado para hablar sobre nuevas técnicas y procesos para desarrollar software.

De esa reunión salieron una serie de principios que debían cumplir los nuevos métodos alternativos (y ágiles) que estaban proponiendo: Principios detrás del manifiesto ágil.

Uno de estos principios es:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Parece obvio que esto es lo que debe hacerse en cualquier desarrollo y con ese ánimo comenzamos cada nuevo proyecto pero pronto comienzan las prisas. Nuestro director nos pregunta cuántas horas llevamos empleadas (y llevamos ya muchas), nuestro cliente nos pregunta cuándo va a tener listas todas las funcionalidades y nuestros compañeros de trabajo nos preguntan si ya pueden cogerse las dos semanas de vacaciones que les debemos.

Empieza a pintar feo. Ya nos hemos vuelto a meter en un jaleo. Tenemos que volver a rehacer el diagrama de Gantt con las nuevas fechas de entrega programadas, tenemos que buscar otras fechas para las vacaciones (incluso las nuestras) y tenemos que dar un montón de explicaciones al director: ‘Es que nos han pedido cambios, es que las tecnologías eran nuevas, es que estimamos mal’.

A partir de aquí es cuando tendemos a ponernos firmes, a exigir un esfuerzo adicional al equipo de trabajo y a negar cualquier pequeño cambio al cliente. Si no está exactamente escrito así en el contrato que firmamos o en el acta de una reunión que tuvo lugar hace seis meses, lo siento, pero no lo haremos.

El caso es que el cliente también hizo esto. Redactó un contrato muy claro en el que te dijo cada una de las funciones que quería (o las que quería en el momento de redactarlo). Quizás ya no las necesite o se haya dado cuenta de que hay otras más importantes pero están en el contrato y hay que hacerlas. El proyecto no puede acabar y dejar un 30% de funcionalidades por hacer.

En este momento ya hemos perdido de vista la que debe ser la máxima prioridad en nuestro trabajo. Entregar de forma continua software que funcione y que aporte valor. A partir de aquí ya no quedan sino duras negociaciones y un contrato que trataremos de cerrar cuanto antes con el menor daño posible.

El contrato podrá tener muchos artículos y estipulaciones pero, ponga lo que ponga, cuando el cliente lo redactó lo que quería era una solución a su problema, no una discusión sobre si se debe o no implementar esa función o la otra.

Pero, si vamos entregando cada poco tiempo el software que vamos haciendo, lo dejamos para que lo pruebe y lo use, que nos diga su opinión. Dejemos que encuentre lo que echa en falta o lo que podría mejorar. Va a querer que le implementemos esto que ahora ha visto que necesita y estará encantado de quitar a cambio esa funcionalidad para exportar a ficheros .rpt que ya ni se acuerda de quién se lo pidió ni por qué.

Al finalizar el proyecto el cliente tendrá un producto que de verdad resuelve sus problemas, que ha ido evolucionando a medida que él mismo aprendía y que ha podido usar y probar desde las primeras semanas del proyecto. Suena mejor para cliente y proveedor ¿no?

De cómo Agile y Zara hacen cambiar la industria de la moda americana

En mi última entrada comentaba que no sólo el software puede escribirse de forma ágil. Un libro también podía escribirse usando estas técnicas pero ¿sólo el software y los libros? Por supuesto que no. También las prendas de ropa pueden diseñarse, fabricarse o inventariarse de forma ágil.

Aquí les cuento cómo empresas de la industria de la moda como Zara dan una respuesta ágil al mercado dejando a sus competidores americanos perdiendo cuota de mercado.

Agile para acelerar las ventas en la industria de la moda

El periódico El País cuenta en un artículo con ese título cómo algunas multinacionales americanas están teniendo problemas para adaptarse al ritmo de ventas que tienen dos de sus principales competidores, Zara y H&M.
En el trimestre presentado habían perdido un 6% en ventas y en el ejercicio del último año (2014) su cotización bursátil había bajado un 25% por lo que muchas empresas del mundo de la moda han terminado rindiéndose a las nuevas técnicas comerciales de la fast fashion:

«(…) admite que el viejo modelo de producir la ropa con un año de antelación está desfasado en la era del comercio online. Primero, porque el sistema que sigue es tan rígido que no le permite reducir los pedidos en los artículos que se quedan en la estantería sin vender. Segundo, y casi más importante, está atado de manos cuando una prenda tiene éxito.»

Cómo lo hace Zara

En 2004 la Harvard Business Review analizaba las nuevas prácticas de gestión de Zara y afirmaba sobre ellas que «eran cuestionables, si no, directamente locas» aunque admitía que «La compañía puede diseñar, producir y entregar una nueva prenda de vestir y ponerla en sus tiendas en cualquier parte del mundo en tan sólo 15 días. Ese ritmo no se había visto nunca en el negocio de la moda, donde los diseñadores normalmente pasaban meses planificando la siguiente temporada«.

Zara consigue aumentar su margen de beneficios en un 28% siendo hasta 4 veces más rentable que sus competidores mediante una combinación de márgenes altos, tiempos de venta bajos y reducción del riesgo de inventario.
Tal cómo explica Forbes una de las técnicas ágiles que permitió a Zara mejorar de forma drástica sus resultados financieros fue la de retrasar hasta el último momento la transformación del producto final. Sólo cuando saben qué producto se está vendiendo bien es cuando lo pasan a fabricación. No manufacturan todo su stock antes de que comience la nueva temporada evitando llenar las tiendas de prendas que no aún saben si se venderán bien.

Esto ha hecho que Zara en sus rebajas descuente sólo un 15% de media a los productos que no ha podido vender a su precio original (son pocos). Mientras, otros competidores tienen que aplicar descuentos del 50 al 70% a los productos que no han podido ser vendidos en toda la temporada.
El artículo de Forbes indica también:

«El rendimiento de la gestión ágil en la fast fashion está ya bien documentado, pero aún como en otros sectores, muchos managers americanos están todavía atrapados en la forma de pensar de la gestión tradicional y están siendo lentos para responder.»

Otra de las joyas de la corona que permite a Zara ser tan eficiente en la gestión de su stock para mantenerlo siempre en movimiento es el chip RFID. Gracias a él, han podido reducir hasta en un 90% el tiempo que necesitan para realizar un inventario o para buscar un artículo concreto en la tienda.
Ser tan rápidos inventariando, diseñando o poniendo sus productos en las estanterías aumenta su margen de beneficios y disminuye el riesgo de quedarse con productos que no pueden vender. Como ves, ser ágil es bueno tanto si se trata de vender moda como de escribir software. También es bueno para producir coches como en el caso de Toyota pero esto ya es tema para otro artículo.

Referencias:

Presentación Cómo usamos Scrum en DESIC (I)

He creado una presentación en prezi que muestra cómo usamos Scrum en DESIC: nuestra particular versión de este marco de trabajo y cómo lo aplicamos. En las últimas diapositivas explico también las que creo que son las principales ventajas que Scrum (o agile si quieres) aporta a los proyectos en general (y a los nuestros en particular).

Puedes acceder a la presentación a pantalla completa haciendo clic en la imagen o en este enlace directamente a prezi: Cómo usamos Scrum en DESIC (I).

Cómo usamos Scrum/Agile en DESIC por Antonio Martel

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad