“Tamaño Funcional, o la excelencia de tener información estratégica”
Transformar datos en información y utilizar la información para gestionar y mejorar empresas, proyectos, procesos o productos es una tarea fascinante. Podemos decir que lo que se mide se gestiona y, por regla general, lo que se gestiona mejora. Famosas son citas tales como: “Si no se puede medir, no se puede mejorar” de Peter Drucker, o “Si no se puede medir algo, no se puede entender; si no se puede entender, no se puede controlar; si no se puede controlar, no se puede mejorar” de James Harrington.
A menudo el hecho de anunciar que algo va a medirse provoca una mejora por parte de los diferentes participantes.
En el sector de las Tecnologías de la Información (TI) podemos hablar -entre otras- de métricas financieras, métricas de productividad, métricas de calidad, métricas de plazos de entrega, métricas de referencia y sobre otras que son todavía más interesantes: conocer y gestionar los diferentes drivers (o condicionantes) que influyen de forma positiva o negativa en esas métricas. Será una tarea constante el recopilar y registrar estas métricas de forma periódica y utilizar esta información estratégica para hacer las cosas mejor, o dicho en otras palabras, una mejora continua.
Pero me gustaría enfatizar la palabra mágica “drivers”. Podemos decir que nuestra productividad en una tecnología concreta y en determinadas circunstancias es de 1,25, a modo de ejemplo y de forma figurada. Desarrollamos productos con esta productividad y con un índice de defectos extremadamente bajo; nuestros competidores tienen una productividad inferior y repositorios de mercado estándares (tales como ISBSG, por ejemplo), indican que nuestro índice de productividad es bueno. Pero es esencial tener en cuenta que el “tamaño del proyecto”, por ejemplo, puede influir en este valor de 1,25: la productividad puede ser diferente si se trata de un proyecto muy pequeño o si, por el contrario, estamos hablando de un proyecto de dos años con un equipo de 400 personas.
Es importante disponer de diferentes ejes de refinamiento: tamaño del proyecto, tamaño del equipo del proyecto, condicionantes de tiempo, criticidad de la aplicación/proyecto, desarrollo en diferentes centros de trabajo, complejidad del producto, etc. Todo ello afecta a la productividad.
Debemos ser capaces de responder, en base a métricas precisas y registradas, a preguntas del tipo: “¿cuál es nuestra productividad estimada para un proyecto de 15.000 horas, con una determinada tecnología y en un entorno determinado?” Y, “¿qué puede cambiar si se trata de un proyecto de 600 horas?”, “¿cuáles son los drivers que afectan a nuestra productividad, calidad o plazos de entrega, y cómo influyen en los proyectos?” Algunos de estos drivers serán internos; otros serán externos situándose, por ejemplo, en la parte del cliente. Ambos deberán de conocerse bien y gestionarse, al menos aquellos que podemos controlar. Es posible que su respuesta haya sido “sí” o una especie de respuesta sinónima: “sí, soy un experimentado project manager y está todo bajo control”. Pero las palabras claves de esta pregunta eran “métricas precisas y registradas”. ¿Disponemos de métricas precisas y registradas que se ajustan a la realidad?
Con frecuencia los departamentos de TI maduros, aquellos que trabajan con procedimientos bien definidos, y con más o menos las mismas tecnologías, entornos de trabajo y productos, pueden contestar con cierta facilidad a estas preguntas de métricas de tercer nivel. Será más difícil para las empresas de TI que trabajan para decenas o cientos de clientes, aplicando los procedimientos de cada cliente, con requisitos de documentación diferentes, estándares y entornos de desarrollo diferentes responder a esas preguntas con información precisa ya que a menudo cada gran cliente es un mundo diferente y específico, todo y que la tecnología utilizada sea la misma.
Aquí es donde entran en juego los Puntos Función: no es posible tener un conjunto completo de métricas de TI si no se dispone del “Tamaño Funcional” de un proyecto/producto de TI, y este Tamaño Funcional viene de la mano, básicamente, de los Puntos Función.
En ocasiones puede resultar difícil de asimilar que un proyecto de TI de 4.000 horas pueda ser más pequeño, en términos de producto entregado, que otro de 1.000 horas. Es importante no confundir los conceptos (en este caso piedras angulares) “esfuerzo de proyecto” y “tamaño de proyecto”, y que ambos conceptos no siempre tienen una correlación de mayor tamaño = mayor esfuerzo, y menor tamaño = menor esfuerzo.
Resulta interesante: si usted produce naranjas registrará, por ejemplo, cuántos kilos de naranjas produce y cuánto tiempo/esfuerzo necesita para recoger 1.000 kilos de naranjas. Incluso más … seguro que conoce que en determinadas circunstancias 1.000 kilos de naranjas se recogerán en más o menos tiempo; factores tales como si el terreno está mojado o no, o si los naranjos son grandes o pequeños determinarán que pueda recoger más o menos naranjas en un determinado tiempo. En este caso hablamos de “tamaño” (kilos de naranjas), de “esfuerzo” (cuánto tiempo, o personas x por tiempo), de “productividad” (kilos recogidos al día, por ejemplo), y de drivers que influyen en la productividad, por ejemplo si los naranjos son grandes o pequeños. En el caso de grandes naranjos quizá tengamos que trepar por ellos y eso dé como resultado una productividad más baja. Seguro que surgirán todo un conjunto de preguntas y debemos de estar preparados para tener información estratégica; por ejemplo, ¿es mejor tener grandes naranjos que produzcan más naranjas por árbol o tener naranjos pequeños con una mayor productividad en lo que se refiere a tiempo de recolección de las naranjas? Calidad, productividad, estrategia de mercado y margen de beneficio deben de estar alineadas. Posiblemente recoger naranjas de grandes árboles sea menos productivo, pero quizás estemos ante un producto de mayor calidad, ante un producto que tendrá una mayor venta y un margen de beneficio mayor. ¿Quién sabe? Necesitamos disponer de información y gestionarla.
Los conceptos de tamaño, esfuerzo, productividad y drivers de productividad se utilizan desde hace siglos. Sería difícil encontrar una pequeña o gran empresa que produzca zapatos o coches que no puedan responder en menos de un minuto preguntas como: “¿cuántos zapatos o coches fabricó su empresa el último año?”, “¿fabricó más o menos zapatos o coches que en años anteriores?”
Intente hacer la misma pregunta a una empresa de software o a muchos departamentos de TI: “¿cuánto software desarrolló su empresa el último año?”, “¿desarrolló más o menos software que en años anteriores?” Quizás lo que escuche como respuestas sean ingresos financieros, número de proyectos, número de empleados trabajando en proyectos de TI, u horas invertidas en actividades de TI. Quizás en algunos casos reciba una respuesta “financiera” o una respuesta relacionada con “esfuerzo”, pero no la respuesta a “¿cuánto software desarrolló su empresa el año pasado?”
La respuesta a esta pregunta solo se puede determinar cuantificando el producto. En una empresa de automóviles la respuesta puede ser el número de coches fabricados, en una explotación agrícola quizá el número de kilos de producto, o en una fábrica de calzado el número de pares de zapatos producidos. Pero incluso más, será necesario añadir un segundo eje que refine esta información con el tipo de coche, por ejemplo, porque sin duda no es lo mismo fabricar 1.000 utilitarios que 1.000 coches de lujo.
Artículo publicado en MetricViews, publicación semestral del IFPUG (International Function Point Users Group). IFPUG es la organización líder mundial que tiene como misión difundir y fomentar la gestión de las actividades de desarrollo y mantenimiento de software mediante el uso del análisis de puntos de función y otras técnicas de medición de software. Encontrará el artículo completo en http://www.ifpug.org/Metric%20Views/MetricViewsJuly2014.pdf
