Cómo implantar un modelo de estimación software en grandes empresas que subcontratan mucho software

Cada vez es más común ver como grandes organizaciones, que subcontratan mucho desarrollo software, las llamadas organizaciones cliente (aseguradoras, operadoras, banca, administración pública, etc.) están implantando robustos procesos o modelos de estimación software para regularizar, estandarizar y sistematizar los precios y tiempos que se asignan a cada proyecto que desarrollarán por sus proveedores.
Después de haber participado desde hace años en varios proyectos de este tipo, he querido sintetizar en este post las claves principales de estos modelos, de esta forma de trabajo entre clientes y proveedores, que cada vez se está implantando en más empresas.
Esquema de estimación que normalmente se implanta

Frente a métodos menos estándar, como negociar “ad hoc” la estimación de cada proyecto con el proveedor, o más riesgosos, como no disponer de método o criterios de estimación y confiar en la palabra del proveedor, la tendencia actual a la hora de estimar se basa en fijar (1)  un método, y una unidad de medición, único para estimar, (2) fijar un método de ajuste específico para cada departamento / organización que subcontrata proyectos y (3) implantar un método de ajuste o calibración continuo.
Conste decir que, además, en la mayoría de las organizaciones que implantan este esquema, los dos primeros puntos son conocidos y compartidos con los proveedores.
A continuación os dejo un breve resumen de las tendencias a la hora de articular los tres puntos anteriores.
Conste que las claves y estrategias de las que trata este post están orientadas a grandes organizaciones, con numerosos desarrollos normalmente llevados a cabo por grandes proveedores (caso que difiere de pequeños equipos, equipos ágiles, empresas de desarrollo de producto, etc.)
1 – Un método, y una unidad de medición, único para estimar
En este esquema de trabajo parece obvio el decirlo, pero debe haber un método de estimación, una unidad de medida del tamaño del software.
Si bien en la literatura podemos encontrar decenas de métodos de estimación parece que el Punto Función se ha convertido en la unidad y el método más usado por las empresas (te dejo dos post interesantes sobre puntos función, este y este otro sobre los métodos de calculo del punto función).
Estos puntos función son “una métrica, un número, para establecer el tamaño y complejidad software en base a la cantidad de funcionalidad”.
El Punto Función es “el metro” para medir el tamaño del software. Con la diferencia de que no son una medida universal: no hay dos empresas que midan Puntos Función de la misma manera, y hay muchos métodos de calcularlos. Por ejemplo, algunos de los métodos que más se usan (o más he visto en empresas) para calcular los Puntos Función son el FP Lite, el IFPUG, el Mk, etc., y el que parece que es el más usado hoy: Puntos Casos de Uso (Use Case Points) (Aquí tenéis una explicación mayor del método).
El punto caso de uso estima el tamaño del software en base a los casos de uso. Mí método preferido, por su aplicabilidad real, que os puedo asegurar después de llevar años utilizándolo y aplicándolo en empresas. Dejo explicación más ámplia del método.
Una estimación con puntos función, en cualquiera de sus variantes, permite estimar de manera repetible, y obtener medidas derivadas, como el número de horas de desarrolladores por Puntos Función, Número total de horas por Puntos Función, Coste por Puntos Función, etc.
El cálculo del punto función no sólo es diferente en cada empresa por haber diferentes maneras de calcularlo, también lo es por las diferentes maneras de ajustarlo, lo cual veremos en la sección 2…
2 – Fijar un método de ajuste específico para cada departamento / organización que subcontrata proyectos

Aun utilizando el mismo método para calcular los puntos función, dos empresas pueden obtener estimaciones diferentes ¿por qué? Porque una por ejemplo puede desarrollar en una tecnología, y la otra empresa en otra, una puede tener personal más cualificado, otra utilizar una arquitectura diferente, etc.

Por ello hablamos de que el punto función hay que ajustarlo a la realidad de la empresa y a los requerimientos tecnológicos.

Las empresas que acaban implantando exitosamente la estimación de punto función, en este contexto, acaban teniendo tablas de ajuste específicas a su realidad y tecnología. Y aunque empiezan usando tablas de ajuste estándar, acaban adecuándolas a su realidad.
3 – Implantar un método de ajuste o calibración continuo (mejora continua del método)
Algo que hay que tener muy claro a la hora de estimar, a la hora de implantar un método de estimación, es que los métodos tienen siempre un error y nunca son exactos. Es decir, que ningún método de estimación nos dirá cosas del tipo a “el proyecto terminará el día miércoles 12 de noviembre a las 12:33”. Eso es imposible en proyectos medianos o grandes.
Los métodos de estimación nos ayudan a acotar el error, a ir reduciéndolo, a determinar un rango de finalización del proyecto y a disponer de un volumen medible del tamaño del software a desarrollar (p.e. el número de puntos función) (lo cual es cuantificable económicamente).
Cuando trabajamos con métodos de estimación el resultado deben ser rangos del tipo a “el proyecto terminará la primera quincena de noviembre”, “la última semana de noviembre”, etc. El rango temporal depende de la exactitud de nuestro método, del momento en el que estimo (la exactitud no es la misma el primer día de proyecto que el penúltimo mes) y de la magnitud del proyecto (proyectos mayores implican rangos mayores, p.e. semanas vs. quincenas).
Ese rango de error debe ir ajustándose, determinándose el error y por analogía comparando el nuevo proyecto a estimar con proyectos terminados previamente que sean similares. La experiencia se va guardando en una BBDD (o más comúnmente en una hoja Excel) que mejora continuamente el método.

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Últimas entradas de jgarzas (ver todo)

• Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
• Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
• Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024