Miguel Matas Blog

Ingeniería y Arquitectura de Software, Proyectos IT, Programación, Personas, Problemas, Mejora Continua, la vida.

Archive for the 'Preventa' Category

Vendamos por partes

Lo que se lleva son los proyectos llave en mano, que parten de alcances totalmente abiertos y que no se pueden medir sin tirarte totalmente a la piscina (al final son tus sensaciones y tu experiencia lo que te hace sentir cómodo o no con la estimación).

Proyectos que incluyen todo: análisis funcional, diseño técnico, construcción, implantación, coste de licencias de software de los productos implicados (seguramente incluso no tan solo la plataforma software si no también la hardware), etc.

Y sobre los que no se sabe nada o casi nada (cinco páginas de requerimientos a altí­simo nivel no es saber).

¿Por qué se siguen aceptando estos modelos de trabajo?

Todos pierden:

* Proveedor: aíºn analizando riesgos, márgenes, alcances, etc; la probabilidad de error en proyectos de tamaño medio/alto es altí­sima… y más teniendo en cuenta lo apretado del mercado actual, la gran dificultad de gestionar alcances con semejante nivel de definición y la complejidad y competencia en las tarifas actuales.

* Cliente: cree saber lo que quiere y lo que necesita, pero aíºn nadie le ha ayudado a aterrizar ni su propio funcionamiento ni las prioridades que tiene cada uno de los conceptos en su negocio; las consecuencias son avances en falso, rework en forma de cientos de gestiones de cambio posteriores, expectativas incumplidas, etc.

¿Por qué no empezamos por el principio?

El éxito de un proyecto de software se consigue cuando lo construido corresponde al requerimiento y el requerimiento corresponde con lo que se necesitaba. Focalicemos el esfuerzo en este primer gran bloque (vendamos íºnicamente esta parte) y luego ya estimaremos/valoraremos el siguiente conjunto de fases disponiendo como artefacto de entrada de un documento que realmente ha sido analizado de forma concienzuda: de entre la paja se ha localizado lo verdaderamente importante, se ha priorizado y se ha detallado.

Para aquel módulo que se solicitó una complejidad altí­sima seguramente nunca se llegarán a emplear ni la mitad de la funcionalidad; mientras para aquel conjunto de detalles (requerimientos funcionales y técnicos) a los que nadie dio importancia, serán los fundamentales finalmente para que el proyecto salga adelante. Tristemente casi siempre es así­.

Un saludo.

Miguel.

No comments