Básicamente lo que voy a contar se basa en hechos reales y se resume en lo siguiente:
- Si tus clientes dicen que tus tiempos de entrega son largos.
- Si tus clientes dicen que eres caro.
- Si notas que tus competidores pasan por tu lado a una velocidad de vértigo.
- Si notas que hay demasiada burocracia interna en tus departamentos.
- Si aprecias que hay demasiadas reuniones (y cada vez más largas) en lugar de tiempo de trabajo.
- Si tus proyectos están pobremente dimensionados en tiempo o recursos y como consecuencia hay quejas internas y de los clientes.
- Si no consigues los beneficios esperados en tu cuenta de resultados.
- Si no quieres sacrificar calidad en tus proyectos en función del tiempo o recursos.
Como digo esto es un resumen, pero estas conclusiones están basadas en hechos reales. Resulta que hace tiempo trabajé para un empresa de consultoría y desarrollo de proyectos cuyo principal punta de lanza en los clientes era el entorno metodológico y tecnológico. La calidad del software, de los productos entregados y de los procesos metodológicos eran llevados al máximo exponente.
"El siniestro siempre acecha en las sombras"
Los clientes de pensamiento puramente ingenieril estaban encantados y los no, estaban asombrados con esas flamantes, grandiosas y estrepitosas propuestas (la de árboles muertos que pesan sobre mi conciencia). La verdad es que se tardaba menos en leer "El Quijote" que en terminar de leer el "resumen para la dirección".
Y allí estaban todos los detalles, todos los procesos basados en RUP, convenientemente adaptados a la empresa y su negocio, tiempos, costes, equipos, fases, entregas, hitos, meetings y un largo etcétera.
La empresa basaba sus procesos de desarrollo en RUP como he comentado y aplicando ciertas prácticas del entorno ágil, como integración continua, pruebas unitarias y de aceptación, control de versiones, pero también adaptadas todas a la situación de la empresa. También se hacía uso de herramientas como Maven, ant, wikis, subversion, JMeter, APIs abiertas y un montón más. El desarrollo era puramente en Java bien regado con patrones de diseño, UML, hibernate no faltaba, xml por supuesto, y frameworks de desarrollo para ahorrar tiempo, dinero y esfuerzo.
Todo cuadraba a la perfección, los tiempos mal que bien se cumplían y las piezas de software salían. Todo un alarde de caballería y señorío. Pero el siniestro acechaba en las sombras.
La dirección comenzó a darse cuenta de "un hecho real", y es que en este paraíso de la calidad los clientes era cada vez menos, y claro comenzaron a aparecer las primeras dudas.
En la mesa casi redonda de los doce caballeros sonaron acusaciones del tipo:
-Es posible que seamos muy caros-dijo Lord Presidente.
-El problema son los tiempos de desarrollo -respondió Sir Comercial-, desde que contactamos al cliente hasta que se le entrega el producto pasa mucho tiempo y el cliente se queja. ¡Hay que acortar los tiempos!
-Pues acortemos los tiempos -respondió Lord Presidente-.
-Con más guerreros acortaríamos tiempo -dijo Sir Gerente de proyectos-.
-¡Ni de coña! -respondieron al unísono Lord Presidente y Sir Comercial -.
-Podemos hacer que trabajen más tiempo -dijo vehementemente Sir Comercial-.
-¡Ni de coña! -respondió afirmativamente Sir Gerente de proyectos-.
-Bueno a lo mejor no necesitamos todo lo que estamos dando y podríamos reducir tiempo reduciendo la etapa de requisitos y eliminando la fase de pruebas -comentarona modo de conclusión-.
-¡Ni de coña! -respondió bravamente Sir Calidad que hasta el momento había permanecido al margen.
-Pues a los clientes ni tocarlos -aclaró Sir Comercial-. No entiendo porqué hay que tener tantas reuniones con los clientes, los acabáis mareando y no quiero que queméis a mis clientes.
-Pues ya me dirás cómo hacemos algo, si no sabemos lo que quieren -respondió Sir Gerente de proyectos-.
La reunión acabó tomando un ritmo más caluroso hasta que el Presidente zanjó el asunto:
-Los clientes se nos van a la competencia diciendo que somos caros y lentos. Pero nuestro precio/hora/persona nos indica que estamos en el mercado y bajarlo sería un error. Por otro lado la competencia da unos tiempos de entrega muy inferiores a los nuestros. Nosotros sabemos que con esos tiempos es imposible realizar buen software y de calidad, ya que cada cosa lleva su tiempo. Parece que al cliente lo que le interesa es que, lo que le entreguen funcione y les deben de estar entregando verdaderas patrañas. Ya vendrán a nosotros llorando cuando lo que les han hecho no funcione.
La realidad es: ¿Cuánto tiempo hay que esperar para que el cliente vuelva?
Pero, ¿Y si lo que han hecho al cliente funciona bien y no vuelve?
Los desarrollos ágiles se basan en el concepto de trabajo, de grupos reducidos orientados a resultados y de una comunicación constante con el cliente. Por que, ¿Cómo puedes saber dónde fallas si no se lo preguntas al cliente?
Si tu competencia es más rápida y más eficiente, no le eches la culpa a ellos. Mírate a ti mismo.
Una comunicación más ágil con los clientes y unos tiempos de desarrollo optimizados a las tareas necesarias hubiera sido un muy buen principio para el cambio hacia la mejora empresarial sin abandonar la calidad. La autogestión de equipos mejora también la disponibilidad al trabajo. Por eso sinceramente aunque creo que Scrum no es la panacea si que permite en muchos casos afrontar proyectos de éxito.
No hay comentarios:
Publicar un comentario