Mira hacia atrás y piensa como utilizabas Internet y el móvil hace 15, 10 o 5 años. Mira como lo utilizas ahora. Las cosas han cambiado, están cambiando y van a seguir cambiando, mucho, cada vez más rápido.
El iPad más viejo cumple este mes la friolera de dos años, 24 meses. Desarrollar servicios y programas para dispositivos como éste o los móviles que evolucionan tan rápido complica la vida extraordinariamente a las áreas de tecnología de las grandes empresas con férreas metodologías que dan respuesta a los desarrollos de toda la vida, esos que saben perfectamente hacia donde van y de donde vienen, donde los objetivos son claros y la forma de conseguirlos también.
En cambio, el uso de metodologías de toda la vida no deja ver el bosque en los desarrollos para canales a distancia. Lejos de traer respuestas, el uso de ferreas metodologías añade incógnitas y riesgos a los desarrollos trayendo curiosas imágenes donde los responsables de cumplir la metodología son los primeros que intentan sortearlas para conseguir asegurar el éxito del proyecto.
Esto es un desafío para los teóricos que crean estas metodologías. Saben que los procesos que son óptimos para toda la organización en cambio no son válidos para desarrollar en Internet, movilidad o incluso call centers. No hace un año cuando tuve la oportunidad de hablar sobre este aspecto con uno de los gurús de mi empresa y viví en mis carnes la inconsistencia de los argumentos.
Por eso cuando hoy leí
esta reflexión de Seth Godin en su blog, me sentí plenamente identificado:
If you're going to build a $10 million skyscraper, by all means, plan and prototype and discuss and plan some more.
On the other hand, if the cost of finding out is a phone call, make
the call. No need to spend a lot of time planning how to call or when to
call or which phone to use when execution is fast and cheap.
The digital revolution has, as in so many other areas, flipped the
equation here. The cost of building digital items is plummeting, but our
habit is to plan anyway (because failure bothers us, and we focus on
the feeling of failure, not the cost).
The goal should be to have the minimum number of meetings and
scenarios and documentation necessary to maximize the value of
execution. As it gets faster and easier to actually build the thing, go
ahead and make sure the planning (or lack of it) keeps pace.
Lo que viene a decir es que no siempre una planificación detallada es el camino óptimo, especialmente cuando el coste de ejecutar tiende a cero.
Hablando del tema en Google+, Javier Arias, siempre recomendable, se planteaba el impacto de nuevas formas de desarrollo en las grandes empresas. Es fácil innovar en una startup, pero algo más complicado cuando tienes reputación y clientes que perder... ¿o quizás los clientes nos piden innovar y no estamos sabiendo hacerlo?
Imagen: del blog de RobinGood