Decía J. Welch (el famoso CEO de General Electric) que “si no te mueves a la velocidad del mercado ya estás muerto”, y hoy las empresas que basan su negocio en la tecnología… se mueven muy pero que muy rápido.
Así que, si sospechas que tu empresa se está convirtiendo en un “walking dead” te recomiendo que leas lo siguiente, aunque te aviso que cumplir lo que dice más abajo no va a ser nada fácil, pero hacerlo será de lo mejor que hayas hecho por tu empresa y, a la vez, uno de los mayores retos a los que te enfrentes.
Normalmente, hay dos maneras d
e desarrollar con velocidad. Una es la de toda la vida, la que todo el mundo sabe hacer, el “desarrolla como puedas”, y “entrega lo que sea”, que es una manera histórica, “práctica” que le dicen algunos, y con muchos seguidores, de entregar software rápido, pero en la que si el desarrollo dura mucho tiempo, meses, años, la cosa acaba explotando y se da la vuelta; y cada vez que hay que añadir una “tontería” al software se tarda una eternidad, situación que normalmente se intenta suplir añadiendo más gente al equipo, lo que hace que todo vaya más lento aun, etc., etc., y podríamos seguir.
La otra manera de entregar software con velocidad, de entregar a producción un prototipo operativo cada mes, cada dos meses máximo, y así durante años y años, es tener un proceso de desarrollo altamente sofisticado y eficiente. Cosa que existe, y que se sabe como hacer desde hace muchos años… otra cosa es que estés dispuesto, y que puedas, implantarlo en tu organización, y es por ello que está otra manera está al alcance de muy pocos.
Pero si eres de las pocas empresas que de verdad lo logra, quédate tranquilo, tu producto será líder de mercado, porque habrás hecho práctico aquello tan teorizado y publicitado de “alinear negocio y tecnología”.
¿Por qué? Porque…
– Si haces entregas, y pones en producción real, prototipos con mucha frecuencia, serán los usuarios reales los que frecuentemente te digan las necesidades que de verdad debe cumplir tu software para que lo compren (usen, o lo que sea), y eso no tiene precio. Los requisitos no los imaginarás tu, te los dará el usuario real, y los implementarás rápido en el producto.
– Si desarrollas con velocidad te aseguro que tu proyecto será lean. Si eres capaz de hacerlo durante años es porque habrás localizado rápidamente el “desperdicio” de tu proceso de desarrollo, te estarás enfocando en aportar valor al cliente, será porque los problemas se resuelven rápido, etc.
– Si desarrollas con velocidad durante años habrás encontrado tu nivel optimo de calidad, ya que sin calidad en el desarrollo no hubieses durado apenas unos meses haciendo entregas rápidas.
– Habrás alineado, desarrollo, sistemas y negocio. Más allá de normas, buenas prácticas, etc., habrás, de verdad, alineado negocio e IT.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Pingback: Bitacoras.com
Hola Javier, otra forma es hacer una biblioteca de componentes reusables en las tecnolocías mas recurrentes en el mercado, eso agiliza mucho tu desarrollo, esos componentes genéricos nos han apoyado mucho a entregar los proyectos a tiempo.
Saludos.
Me parece un tremendo error confundir agilidad con el agilismo, que es la gran excusa de nuestros días para tener la justificación perfecta de hacer las cosas deprisa, corriendo y mal sin ningún tipo de responsabilidad.
Es una irresponsabilidad total poner en riesgo de forma continua la Producción de cualquier organización, es decir la propia sostenibilidad del negocio y de la compañía, por cada linea de código nueva que se desarrolla y olvidando de serie toda la batería de pruebas completa para garantizar el correcto desempeño del artefacto entregable.
Ni que decir, la enorme irresponsabilidad de los departamentos de desarrollo, al considerar «desperdicio» las pruebas de calidad, las de seguridad, las revisiones de software, el análisis de defectos, el profiling de las aplicaciones, la optimización del código, etc…
En definitiva que ser ágiles, no significa ni puede significar perder el sentido común con la excusa del agilismo.
Un abrazo.