Proyecto cerrado

[Helder De Oliveira]

Buenos días.

Desde hace algún tiempo vengo dialogando con personas que ocupan importantes posiciones de gestión en estructuras tradicionales dentro de empresas con gran número de personas en su plantilla.

En estos entornos la gestión es tan compleja que en muchos casos para poder dialogar sobre los proyectos que se desarrollan en ellas se simplifican los pensamientos a la frase "proyecto cerrado".

No todas las personas con las que hablo coinciden en la definición de proyecto cerrado, pero en la gran mayoría de los casos y luego de escuchar atentamente lo que le gusta y lo que no sobre métodos ágiles, acabamos teniendo una conversación muy cordial sobre el triángulo de hierro. 

Así que basados en el triángulo de hierro muchas veces concluimos que las organizaciones tienden a requerir proyectos basados en el negado del triángulo de hierro:

• Costes fijos y conocidos al inicio
• Tiempos fijos y conocidos al inicio
• Alcance fijo y conocido al inicio
• ¿Calidad?, si, hay un departamento de QA que lleva eso

No sería de tanto infarto si no es porque manteniendo los tres primeros puntos constantes se suele querer incluir cambios en el proyecto.

Sobre el cómo he estado encausando esta conversación básicamente lo puedo resumir en dos puntos:

1. Dar las gracias por habernos atendido, desearle la mayor de las suertes y brindarle todo nuestro apoyo en el momento que lo requiera para ayudarlo a mejorar sus procesos
2. El resto de técnicas para adoptar un enfoque ágil en estos casos ya las comenta mejor que yo Mike Cohn en "Succeeding with Agile", así que no os doy la chapa.

A lo que iba, me gustaría conocer vuestras experiencias en entornos similares en dar a conocer otras formas de hacer las cosas a personas cuyo trabajo tiene por premisas:

1. la gestión presupuestaria al céntimo
2. la gestión del tiempo al minuto
3. la gestión de entregas al detalle

Gracias por vuestro tiempo.

Helder De Oliveira
http://about.me/helderdeoliveira
https://twitter.com/HelderDOliveira

http://www.ambidieXtro.com

[David Parra Catalán]

Hola:

Algo he vivido estos últimos cuatro años sobre lo que comentas. Con el punto uno y dos no hay mucho problema. Es normal que las compañías tengan que gestionar y controlar un determinado presupuesto y un time to market (que sin ninguna duda, no da igual). Con eso, en mi opinión se pueden encajar técnicas ágiles de trabajo que te aseguren entregar el mayor valor posible. El problema en mi opinión es el tercer punto (si lo entiendo bien como un alcance definido al detalle al principio). En la gran mayoría de los casos, es imposible definir al detalle y exactamente el producto antes de empezar. Y en los casos en que no sea imposible, sin duda es un gasto inútil, por más que se empeñen aquellos que vienen de otras ingenierías o del mundo militar. La construcción del software tiene otra naturaleza que nada tiene que ver con esas disciplinas y que ofrece unas ventajas competitivas asombrosas a quien lo entiende bien. 

Centrando el tema y sin irme (más) por las ramas: En mi caso personal, he buscado sponsors y aunque muchos siguen pensando que es cuestión de "suerte" o de jugar con ventaja (porque no elaboras esos "tochos" de documentación) se consigue entregar el máximo valor posible, no siempre el 100% exacto de la definición de inicio, pero sí lo mejor posible, que ya es bastante.

En cuanto a los contratos fix price (o llave en mano: otra intoxicación de la comparación con la construcción ladrillera), desde mi punto de vista de cliente, acabas disfrazando T&Ms, negociando para compensar y aplicando mucha mano izquierda para flexibilizar requisitos que es la receta que te dan todos los sabios a la hora de acabar un trabajo de desarrollo de software.

Saludos

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un mensaje de correo a agile-spain...@googlegroups.com.
Para publicar en este grupo, envía un mensaje de correo a agile...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/CAFyq09fJJo%3D74%3D4tda7tUaZsf-Ka4bUt86m7uMLSFqm0fff_Og%40mail.gmail.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Jesus Sanchez Jara]

Hola, creo que un modelo de contrato cerrado no se adecua de ninguna forma a la agilidad, no se adecua a los principios del manifiesto ágil. PERO por desgracia vivimos en la realidad, y además en una realidad de empresa "española" (disculpadme pero voy a hablar del ámbito laboral sobre el que tengo experiencia). Por mi experiencia es muy muy complicado arrancar un proyecto cerrado siguiendo metodologías ágiles. Varios de los proveedores con los que trabajamos en modelo de contrato cerrado nos venden la idea de que aplican metodologías ágiles sin embargo los Jefes de Proyecto tenemos que ofrecer a nuestros negocios planificaciones en modelo cascada con Gantts y demás, ya me entendéis. Lo que sucede es que estos proveedores al final terminan aplicando el modelo incremental (que no iterativo) donde terminan haciendo entregas tempranas esperando los cambios de requisitos y alcance, que siempre llegan y se esperan, y ya terminan asumiendo los típicos picos de trabajo, mas gente, etc pero para el cliente, el mismo coste ya que es cerrado. Creo que os suena a todos. Para el cliente es maravilloso, por X me haces esto y además esto y esto y etc etc sin importar la calidad ni el mantenimiento.

¿Qué solución damos? Pues después de explicar hace un par años el concepto de deuda técnica, de pensar en el medio/largo plazo y no en el corto, de pensar en el mantenimiento posterior, en la calidad de lo que se hace (no solo a nivel funcional sino del código), en fin, después de dar la lata con estos temas conseguí que nos dejaran funcionar con un proveedor con "extensiones" en el contrato. El acuerdo era del tipo "hacer esto por esta cantidad" con un % de extensiones en coste y tiempo para funcionalidades añadidas. Me explico; hay que desarrollar una nueva funcionalidad en un producto, para ello se envía un RFP, pide una propuesta y se cierra un contrato a un coste con un calendario. En el contrato se indica claramente que ante un cambio de alcance se analiza el tiempo adicional y el proveedor y el cliente deciden si se añade entonces un % adicional del coste (Y DEL TIEMPO) al proyecto, pero no indicamos para que como es lógico ya que no sabemos a priori lo que nos pueden llegar a pedir. El contrato que cerramos contenía una extensión del 25% del coste del proyecto que ascendía en ese momento a unos 30K€, En interno, para no liar las partidas de los presupuestos que cerramos todos los años, lo que se pidió fue un presupuesto de 30k€ + 25%. ¿Que sucedió? que finalmente consumimos ese 25%, se desarrolló mas de lo inicialmente previsto y se retrasó la fecha un par de semanas para que pudieran desarrollarse las nuevas funcionalidades. En el segundo caso no lo consumimos y lo que trasladamos internamente es que había costado un 15% menos (era un 15% en el otro proyecto donde lo aplicamos). No es perfecto por que puede que el esfuerzo sea de mucho menos que ese % que acordamos o puede que sea mucho mayor. Ahí creo que tiene que existir una relación de confianza entre el proveedor y el cliente (algo muy complicado de ver en España al menos) donde ante un cambio de alcance se decida si el proveedor lo asume bajo las condiciones iniciales o se acuerda ejecutar la extensión del contrato. Bajo este modelo podemos acordar las extensiones que queramos, pero siempre al inicio, lo que tampoco nos da un marco 100% ágil pero creo que es un avance.
Espero que te sea de utilidad.