miércoles, marzo 12, 2008

¿La solución para plazos delicados? Arquitectura sencilla.

miércoles, marzo 12, 2008 por Martín

El Coding The Architecture London User Group ha publicado su primer podcast (slides)., que con un poco de suerte será el primero de una larga lista.

Es un podcast bastante interesante, ya que se trataba de exponer un caso práctico de un proyecto y como escogieron su arquitectura, aunque la calidad del audio no es demasiado buena. En ella hablan de un proyecto para desarrollar un sistema de análisis de riesgos que tuvieron hace unos meses para un banco de inversiones en Londres y que estaba programado para realizarse en 4 semanas. Sin embargo, tanto los requisitos no funcionales, no ya en cuanto a carga, si no más bien en cuanto a seguridad, como los funcionales ya que la lógica de el análisis de riesgos era bastante compleja, hacían que el proyecto fuese totalmente inabordable.

Después de duras discusiones, la solución fue adaptar la solución al márgen de tiempo disponible. Se encontró que para lo que realmente quería el banco era más que suficiente con prescindir del 90% de la lógica de análisis de riesgos y tener un sistema que más bien diese pistas sobre anómalias en lugar de algo 100% fiable; que no era necesario utilizar un potente servidor de aplicaciones sino que con un stack basado en Tomcat y Spring era más que suficiente; que a veces hay que dejar también tecnologías que en un principio son buena idea, como Hibernate o Maven, ya que el proyecto es lo suficientemente pequeño, y los plazos suficientemente ajustados, para que no tengan tanto sentido; o que muchas veces el cliente dispone ya de las herramientas para cubrir requisitos no funcionales, como en este caso el Veritas Cluster Server, y se pueden aprovechar también en lugar de ponernos nosotros a reimplementarlas.

La aproximación que siguieron para solucionar el problema es también bastante interesante. En lugar de rendirse al cliente y aceptar sus exigencias, apostando por la venta fácil y la entrega con retrasos, lo que se hizo fue la opción honesta que es ofrecer una solución adecuada pero con los plazos que se consideraban indispensables: en este caso seis meses. El cliente se da cuenta de la magnitud del proyecto y aceptan reducir funcionalidad. El proveedor de servicios se da cuenta de las necesidades inmediatas del cliente y aceptan prescindir de ciertas soluciones innecesarias.

En resumen un acuerdo entre ambas partes para reducir el espectro del proyecto que resulta en un final feliz. ¿Tenéis alguna historia similar?

comments

2 Respuestas a "¿La solución para plazos delicados? Arquitectura sencilla."
Alberto Molpeceres dijo...
8:57

A mi me enseño un importante cliente hace tiempo que el no veía los proyectos como un mercadillo, en el que se puede regatear. El quería las ofertas sinceras y realistas, y en función de ellas escoger si le parecía bien o mal. Para él presentarle X mil y tras su negativa rebajarle el precio se traducía en que la primera vez le habían intentado timar.

Me llamó mucho la atención, y es algo que he intentado aplicar desde entonces, y tengo que decir que con éxito. Acabas trabajando más a gusto que con la opción de rendirte y retrasarte, aunque pierdas proyectos, pero ¿quién quiere proyectos en los que sabes que vas a perder o dejar de ganar?, porque supongo que no le engañaste en la primera oferta.

Hay gente que suelo hablar del: "tiempo - calidad - precio: escoja dos de tres". Para mi no hay esa elección, la calidad debe ser la adecuada a cada caso siempre, de modo que o se reduce funcionalidad, o se mantiene el precio y el plazo siempre.

Como ya digo, a mi, con mis clientes, me funciona.


Daniel dijo...
1:33

Yo hace poco, Alberto lo sabe, conoci a alguien que tenia un problema, problemon, y necesitaba rehacer una aplicacion. La original era un desastre total.
Cuando me pregunto, le explique lo que habia y en el tiempo que el necesitaba, pues lo que se podia conseguir era X, para tener algo y ganar tiempo, despues poder avanzar hacia Y y luego ir a una solucion más deinitiva. Y el coste: tanto aprox.

Al ver que se lo planteaba de forma realista, aceptó, y ahora esta la mar de contento por que las cosas fueron como se pudo preveer. La arquitectura es "sencilla" y no usa cosas demasiado guays, pero es lo que le dije: Si lo hacemos como ya se hacerlo, puedo predecir el tiempo. Si intentamos virguerias, vete a saber.

Al final el cliente muy contento

Claro que no es lo habitual, y en mi trabajo normal, donde no "mando", cuando te preguntan "cuanto vas a tardar?" lo que te dicen en realidad es "es que tiene que estar en tal plazo". Yo me resisto y por ello tengo fama de conteston, pero me da igual :).

Yo creo que es el camino, pero en muchos sitios la presion puede.