archivo

Archivo de la etiqueta: estimación de costes

La planificación del proyecto supone la base para la realización del mismo, por lo que es habitual que la mayor parte de las tareas que lo componen se realicen de una manera más o menos formal: Determinar un alcance inicial (aunque sea a alto nivel), hacer un análisis de riesgos, hacer una estimación del coste/esfuerzo, de los recursos en materia de personal (¿quiénes van a participar?, ¿cuándo?, ¿con qué dedicación?, ¿necesitan algún tipo de formación antes de enfrentarse al proyecto?) y materiales (software y hardware), definir el ciclo de vida/metodología a utilizar, proponer un cronograma, definir los hitos, las personas que los apruebas, etc…

Buena parte de la suerte del proyecto se juega al principio, una mala negociación, una mala estimación, en general, una mala planificación puede condicionar negativamente el proyecto, hasta tal punto de que si no hay posibilidad de enmendar la situación a tiempo puede afectar incluso a su viabilidad.

La incorporación de esta tarea y darle un grado de formalidad en los proyectos software, resulta por tanto, lógica en el nivel 2 de CMMI.

Es decir, a partir de ahora y en cada proyecto, es necesario que esas tareas preparatorias del proyecto se realicen, siguiendo un proceso, una estrategia, un plan. Se entiende que de esta manera las decisiones que se tomen se harán siguiendo una lógica que vendrá definida por las distintas soluciones y técnicas que se utilicen para realizar las diferentes actividades del mismo (estimación de proyecto, análisis de riesgos, etc…), si bien, la existencia de un proceso de guíe a la definición del plan de proyecto no asegura nada si la ejecución no es buena (ya sea por un incorrecto desempeño del que la realiza y/o porque la información que tiene para realizar la planificación no es adecuada o válida).

Se entiende que este área de proceso debería tomar como partida los requisitos del área de proceso “Gestión de requisitos”, sin embargo esto no va a ser siempre posible. Es cierto que es deseable conocer el mayor detalle posible antes de realizar por ejemplo una estimación de costes, pero también lo es que no siempre se van dar las condiciones para poder realizar esta tarea ya que la contratación del servicio de desarrollo de software se puede realizar en base a un pliego de condiciones técnicas o incluir dentro del mismo las tareas de análisis.

A lo anterior hay que sumar la volatilidad de los requisitos, ya que lo mismo la estimación se ha realizado teniendo en cuenta unos, pero después cambian las condiciones y se rompen los esquemas.

Dependerá de la organización tomar parte o no en un proyecto en función del grado de incertidumbre existente, de las características del cliente y de la propia cultura y experiencia de la misma.

Desde mi punto de vista la planificación inicial del proyecto es muy importante, independientemente del grado de incertidumbre y es importante que todas las partes entiendan que se trata de un plan inicial que se deberá ir ajustando a la evolución real del proyecto.

Velocity es una unidad de medida que se suele utilizar en metodologías ágiles (y en general en ciclos de vida iterativos e incrementales) y que viene a expresar la cantidad de trabajo que se puede realizar en cada iteración.

Por regla general, las iteraciones suelen tener una duración determinada y eso se puede establecer de manera común a proyectos distintos y equipos diferentes, es decir, se puede establecer que un proyecto funcional y técnicamente complejo, formado por un equipo de trabajo de nueve personas, tiene iteraciones cada tres semanas y que otro más simple, formado por un equipo de trabajo de cuatro personas, presenta nuevas versiones en ese período de tiempo.

Mientras las iteraciones pueden tener la misma duración, el valor de velocity puede ser distinto en cada proyecto porque entrarán en juego las variables propias de la naturaleza del trabajo a realizar, las características del equipo de personas que participan y las propias circunstancias que rodean al proyecto.

Dado que las iteraciones tienen una duración determinada y resulta conveniente cerrar los trabajos previstos en cada una de ellas, el cálculo del valor de velocity en el proyecto resulta de sumo interés, ya que a la hora de afrontar las tareas a realizar en la iteración es necesario tener en cuenta en su elección que la suma de su esfuerzo se aproxime lo máximo posible al factor velocity.

Por regla general, se suele establecer en base a la experiencia previa del responsable del proyecto un valor estimado para velocity que después se va ajustando en las primeras iteraciones hasta que se consigue un valor estable, lo que permitirá conseguir una mayor grado de precisión en cuanto al cumplimiento de la planificación estimada para una iteración y no tener que recurrir al overtime o simplemente no alcanzar los hitos establecidos.

Una vez alcanzado un valor estable no quiere decir que no se pueda reajustar más adelante. Se puede y se debe.

Velocity es una unidad de esfuerzo que se puede medir en distintas unidades: puntos por casos de uso, punto por historias de usuario, etc… y tendrá que coincidir, como es lógico, con la unidad de esfuerzo seleccionada en la realización de las estimaciones.

Son ya unos cuantos los artículos que he escrito tratando directa o indirectamente este asunto, que tantas veces resultan conflictivos entre un cliente y un proveedor.

Si la valoración viene de fuera, por ejemplo, una propuesta de colaboración de un proveedor, es muy importante que se tenga confianza en el mismo, ya que si es así, probablemente los problemas sean menos e independientemente de que pueda parecer más o menos elevado el precio respecto a las tareas a realizar, no se entrará tanto en discutir unas horas más o menos (siempre y cuando, impere la lógica y no se haya presentado una valoración absolutamente desproporcionada), sobre todo teniendo en cuenta que en la mayoría de los casos será beneficioso un presupuesto holgado, ya que además de evitar bastantes problemas en el desarrollo, permitirá obtener, por regla general, productos de más calidad y que a la postre permitirán ahorrar dinero en un futuro (menos errores, menos mantenimientos correctivos, mejor mantenibilidad del sistema, etc…), compensando ese posible sobrecoste inicial.

Resulta también importante que exista un objetivo o una serie de objetivos concretos en el proyecto, más allá de objetivos generales, ya que estos segundos llevarán a una gestión basada en bolsas de horas. Cierto es que muchas veces se plantean mantenimientos generales y que en estos casos no habrá más remedio que plantear su ejecución mediante una bolsa de horas y los fragmentos de mantenimiento son tan pequeños que no merece la pena, por el esfuerzo que requieren, la valoración individualizada de cada una de las tareas a realizar.

Pese a que no me termina de gustar la gestión basada en bolsas de horas, no necesariamente debe producir malos resultados, al contrario, puede permitir la obtención de resultados excelentes, pero básicamente dependerá mucho del conjunto de técnicos que realizan las tareas, ya que al no establecerse unos límites temporales para la realización de las tareas (salvo que haya una determinada urgencia) se puede tender a una disminución de la productividad.

Hacer valoraciones puede ser sencillo, eso sí, acertar es otra historia. Es difícil atinar porque depende de muchísimas variables, donde de muchas de ellas se desconoce su valor antes de comenzar el proyecto. Se acertará más cuanto mejor se conozca al cliente, su tecnología, sus usuarios, los procesos internos de su departamentos de informática, las posibilidades (talento, compromiso, formación, experiencia, etc…) del equipo que va a trabajar en el proyecto, etc…

En muchos casos, se recurre a realizar primero el análisis del sistema de información, para tener más datos y realizar una valoración más aproximada de lo que costaría la construcción. Es una buena estrategia, siempre y cuando no se demore mucho el proceso de construcción, ya que si así sucediera podría haber cambios significativos en el equipo que participó en la definición del proyecto pudiendo dar lugar a realizar una revisión del análisis (ya que personas distintas pueden tener asociados criterios distintos), lo cual sería dar un paso atrás, con el correspondiente sobrecoste que ello conlleva.

Las valoraciones no son exclusivas de las relaciones cliente/proveedor, ya que en muchos casos, por parte del cliente se determina un coste determinado de un determinado proyecto, sin posibilidad de realizar negociación alguna sobre el precio. En este caso la valoración es de carácter interno por parte del proveedor que deberá determinar en base a ella si es rentable o no participar en el proyecto (también habrá que entrar a valorar si no siendo rentable en el proyecto, puede resultar una inversión de cara a futuras relaciones con ese proveedor o con otros).