¿Cómo sé cuánto va a costar?

Yo digo que tenemos pocos éxitos y muchos fracasos, pero no tiene que ser así.

Fungus

La Pregunta

Muchos desarrolladores me preguntan cuánto deben cobrar por su trabajo. Algunos preguntan por un proceso para estimar el costo del proyecto. Otros preguntan por la técnica para estimar el esfuerzo necesario para ejecutar el proyecto. Otros quieren saber si hay una calculadora de esfuerzo que puedan usar.

La respuesta corta a esas preguntas puede ser:

• Cobra entre 25 y 75 dólares por hora, dependiendo de la complejidad del trabajo (y del hambre que tengas).
• Estima el esfuerzo necesario para ejecutar (y validar) todos los paquetes de trabajo aprobados por el cliente en la WBS (o EDT), multiplica por tu tarifa, añade un colchoncito de riesgos y ponle un porcentaje para gastos administrativos.
• Utiliza CMMi, RUP, PMBoK, COQ, Puntos Funcionales y Cocomo II.

Yo digo que esas respuestas son correctas pero no son adecuadas porque pueden ayudarnos a ganar dinero, pero no nos ayudan a entregar proyectos exitosos.

Yo digo que lo importante no es conseguir muchos recursos, sino usar eficientemente los que tengamos en beneficio de nuestro cliente.

Para encontrar la respuesta adecuada (la que sí sirve), hay que plantear la pregunta adecuada. Para explorar cómo gestionar los recursos y tener éxito en proyectos, los invito a cambiar de perspectiva e incluir en la foto a los que deciden si un proyecto es exitoso (el cliente). También propongo dar un par de pasitos para atrás, para ver el contexto.

Nota:

La exploración del tema es larga y tediosa. La hice lo más concisa que pude, pero aún así, son casi 1,500 palabras y su lectura puede llevarse unos 10 ó 12 minutos.
Si sólo necesitas los nombres de las herramientas y las ligas para encontrarlas en internet, puedes pasar directamente a la sección “Resumen” al final del post.

Si después de leer el resumen te interesa regresar para entender por qué esas herramientas funcionan, aquí te espero para continuar la conversación.

Yo digo que la pregunta importante no se enfoca en el costo, sino en el beneficio. Debemos usar nuestras competencias profesionales para aprovechar los recursos del cliente (o de la comunidad) y obtener un beneficio mayor.

Sugiero que sería más útil planter la pregunta en estos términos:

¿Cómo puedo saber qué recursos necesito para tener éxito en mi proyecto?

En esta conversación, vamos a enfocarnos en los problemas relacionados con la obtención y el uso de recursos para ejecutar el proyecto. Vamos a dejar de lado los problemas relacionados con los requisitos y para eso supondremos que ya entendimos las necesidades y expectativas del cliente y que todos los interesados saben qué modificaciones se requieren en el sistema de manejo de información (TI) para mejorar el desempeño del negocio … y la satisfacción del cliente.

Es decir, que ya documentamos los requisitos y los validamos con el cliente y que ya conocemos el beneficio que el cliente, los usuarios y otros grupos interesados van a obtener si hacemos bien las cosas. Es decir, cuánto va a ganar mi cliente (y otros interesados) si el proyecto es exitoso.

Si ya sabemos qué se requiere para que el proyecto sea exitoso, lo que queremos saber es:

• Qué recursos necesitamos para ejecutar el trabajo y construir los productos y servicios esperados.
• Cómo pedir los recursos para obtenerlos y
• Cómo administrarlos durante el proyecto.

Yo digo que para tener éxito necesitamos, entre otras cosas, un sistema de estimación que nos ayude a gestionar los recursos para cumplir las siguientes condiciones:

1. Un promotor debe canalizar los recursos que provienen de la comunidad y serán invertidos en el proyecto para beneficio de la comunidad.
2. El promotor debe promover que el beneficio comunitario sea mayor que el costo de los recursos que se invierten en el proyecto.
3. El promotor debe promover que el beneficio para cada uno de los grupos interesados sea mayor que los recursos que el grupo aporta.
4. El líder del proyecto debe entender, documentar y explicar a los interesados (representados por el promotor) cómo se transforman los recursos que recibe en componentes de la solución, y por qué cada uno de esos componentes es una parte útil y necesaria de la solución.
5. El líder de proyecto debe gestionar los recursos conforme al plan aprobado por el promotor.
6. El líder de proyecto debe mantener informados a los miembros de la comunidad (representados por el promotor) acerca del avance. Es decir, acerca de cómo se van transformando los recursos invertidos en componentes de la solución, producto o servicio que aportará los beneficios esperados.

Es más complicado, pero esta lista es un buen principio.

Un par de notas:

• Los roles que menciono pueden ser individuales o colectivos y no necesariamente deben ser ejecutados por un individuo dedicado exclusivamente a esto.
• Uso el término “comunidad” por flexibilidad. Una comunidad puede ser una unidad de negocio o el mundo entero.

Antes de seguir quiero hacer énfasis en un concepto que aparece como #4 en la lista que está aquí arriba.

Para que un proyecto tenga éxito es necesario que todos los participantes entiendan cómo se transformarán los recursos que el proyecto recibe (insumos) en componentes de la solución (resultados).

Esta es una responsabilidad del líder de proyecto.

Fungus

La Respuesta

Ahora sí voy a contestar la pregunta y a explicar cómo estimar el costo del proyecto de modo que podamos obtener los recursos necesarios y administrarlos correctamente para tener éxito en el proyecto.

El costo de un proyecto de software depende primordialmente de dos factores.

• La cantidad y complejidad del trabajo (el alcance del proyecto) y
• La capacidad de nuestros procesos para diseñar, producir e integrar los componentes de la solución.

Para estimar correctamente el costo de un proyecto es necesario contar con un proceso definido, usar modelos estandarizados para documentar los requisitos y las características de la solución, mantener un sistema de medición y registro de las estimaciones y los resultados y establecer un mecanismo para incorporar al proceso las lecciones aprendidas.

Proceso

Para estimar (y controlar) el esfuerzo y costo de un proyecto, debo usar un proceso definido. Es decir, uno que esté documentado, que se pueda aprender, que se pueda medir y se pueda mejorar.

En general, la descripción de un proceso debe incluir:

• Objetivo,
• Referencia al modelo en que se basa (nunca inventes el hilo negro),
• Roles y responsabilidades por la ejecución del proceso,
• Insumos y salidas (productos) esperadas,
• Especificaciones o requisitos,
• Estándares aplicables,
• Condiciones que deben reunirse para inciar el proceso,
• Condiciones que deben reunirse para dar por terminado el proceso,
• Registros y criterios de medición.

El proceso debe tomar en cuenta que las estimaciones que no están basadas en la experiencia tienden a ser poco precisas. Ese es un riesgo que hay que gestionar.

CMMi describe en el nivel ML2 las prácticas para estimar los recursos necesarios y administrarlos correctamente.

Modelos de diseño

Todo el equipo de trabajo debe usar un lenguaje formal para describir la funcionalidad prometida para saber sin lugar a dudas si un componente cumple con sus especificaciones y cubre todos los estándares aplicables. Es decir, si el componente está terminado y listo para entregarse al cliente.

Esta descripción formal de la funcionalidad debe incorporar los criterios de aceptación del cliente y forma la base para las actividades de validación y verificación.

RUP describe modelos formales para documentar los diferentes niveles de diseño.

Unidad de medida

La cantidad de funciones y la complejidad prometida al cliente, es decir, el tamaño del producto, debe poderse estimar y medir en términos comparables y estandarizados que puedan relacionarse con el beneficio esperado por el cliente y con el costo que deberá incurrir el equipo de proyecto para producirlos.

El manual de IFPUG (ver aquí la guía rápida de Total Metrics) describe cómo contar puntos funcionales, ya sea como parte de la estimación antes de construir o de una medición cuando la aplicación ya está construída.

Mejora continua

Una vez establecidos los procesos de desarrollo, es necesario medir su capacidad de desempeño para saber si con los procesos, tal como están, podemos cumplir las expectativas del cliente (i.e. tener éxito) o si es necesario mejorar el desempeño.

Juran y Gryna en el capítulo 3 del Manual de Control de Calidad exponen el concepto de Costo de Calidad y cómo puede usarse para identificar el desperdicio en un proyecto y agilizar los procesos de una manera inteligente y razonada.

CMMi describe en el área de proceso CAR, correspondiene al nivel ML5 las prácticas que se pueden usar para establecer un proceso de mejora continua, aún antes de establecer prácticas de análisis y control estadístico.

Resumen:

Para estimar correctamente el esfuerzo, costo y duración de un proyecto debe usarse un proceso definido consistente con algún modelo generalmente aceptado, como CMMi.

El proceso debe incluir las prácticas necesarias para  describir y medir todos los productos intermedios y finales del proyecto con un sistema de medición basado en alguna unidad estándar de medida, como los puntos funcionales descritos por el IFPUG (guía rápida).

El proceso debe incorporar, también mecanismos de medición, análisis de causas y mejora continua como los que se describen en CMMi y en el artículo “Cost of Quality” de Juran& Gryna.

Por hoy, esto es todo. Seguimos en contacto

Santiago de Querétaro, México

24 de agosto de 2013

• ¿Por dónde deben empezar las PyMES?
• ¿Cómo se compara 4CE con otros modelos de calidad?
• ¿Cómo puedo saber qué quiere mi cliente si ni él lo sabe?
• ¿Cómo sé si voy bien o me regreso?
• ¿Cómo sé cuánto va a costar?
• En preparación: Reducción de desperdicio (tiempo y esfuerzo).

• RUP (Rational Unified Process)
• CMMi  (Capability Maturity Model Integrated DEV v1.3)
• Mediciones prácticas de software (Florac et al 1997)
• Manual para conteo de Puntos Funcionales del IFPUG (ver aquí la guía rápida de Total Metrics)
• Manual de Control de Calidad (Juran)
• Costo de Calidad (ASQ)
• Lista de verificación para estimaciones de costo y calendario (Park)