Tengo una conferencia bien conocida sobre contratación y estimaciones de proyectos de software. Trata bastante el tema y se muestra cómo no sólo existen contratos de precio fijo para comprar proyectos.
Sin embargo, en Brasil, la gran mayoría de los proyectos desarrollados por terceros proveedores siguen siendo contratados con la modalidad de precios fijos. Muchos agilistas sólo critican el contrato, sin mostrar salidas cuando no hay otra alternativa y el cliente todavía requiere de contratos a precio fijo. Por supuesto que el ideal sería firmar un contrato de alcance variable o deslizante y siempre debe ser intentado y negociado. Pero todavía tenemos muchas empresas que seguirán comprando en la forma de precio cerrado.
El gran autor Steve McConnell (de los libros Code Complete y Rapid Development, entre otros), escribió un artículo en su blog bajo el título Estimation of Outsourced Projects. Voy aquí a traducir brevemente el artículo y poner mis ideas en el medio (lo que será un artículo diferente). Si no te gusta siempre puedes leer el artículo original del gran maestro. Al final voy a incluir una bibliografía seleccionada para profundizar el asunto de estimaciones y fijación de precio.
La pregunta que a menudo se encuentra en el mercado es: "Nuestra empresa comercializa proyectos y outsourcing de sistemas para otras empresas. Por lo general, el modelo de los contratos son de precio fijo (precio cerrado). ¿Hay algo de especial en el tratamiento de las estimaciones en este contexto?"
Vamos entonces a los problemas y los dolores que encontramos en el proceso de estimaciones de las empresas: si la estimación hace que el precio de la empresa es demasiado alto, se puede perder el proyecto. Si la estimación hace que el precio de la empresa sea muy bajo, la empresa no sólo no tendrá beneficios sino que además puede tener enormes pérdidas. Ambos son resultados no deseados y que son críticos para las empresas que tienen la venta de proyectos de software como núcleo de su negocio! Por lo tanto, de ahí el primer principio (debería ser la Primer Directiva a una empresa proveedora de software) que es: el proceso de estimación y de fijación de precios tendría que ser considerado como parte del fundamento estratégico de las empresas proveedoras de software.
Tomando como punto de partida que el proceso de estimaciones y fijación de precios es estrategico para las empresas proveedoras de software (y vemos que muchas, incluso a sabiendas de esto, no invierten en el mejoramiento de ese proceso), vamos entonces a algunas recomendaciones:
- Si su negocio depende de la creación de cotizaciones con precios fijos y cerrados, debe enfocarse en las habilidades de estimación como una competencia central y debe tratarla como una función crítica del negocio. Eso significa que las empresas deben invertir en el entranamiento, capacitación, libros, y la mejora de sus procesos de estimaciones y fijación de precios. Véase la lista de libros al final del artículo para comenzar tan pronto como sea posible!
- Crear estimaciones de rangos. Es decir, la estimación no debe ser expresada en un único valor, como cien mil reales. Ellas deben ser expresadas en un rango por ejemplo, entre 50.000 reales y 200.000 reales. Mejor aún si hay una probabilidad asociada a cada uno de estos números. Ejemplo: 15% de posibilidades de completar el proyecto en el presupuesto teniendo en cuenta 50.000 reales; y el 95% de posibilidades de terminar con 200.000 reales. 120.000 reales nos da una chance del 75%. Para más detalles acerca de cómo levantar esas probabilidades, vea la sección de libros sobre las estimaciones, comprelos y lealos!
- En un contexto de contratos de precio fijo, separe la estimación del precio! Originalmente, en su libro sobre estimaciones, McConnell también llama a eso de "separar la estimación del compromiso." Es evidente que la estimación informa sobre el precio que será cobrado, pero no necesariamente hay una relación directa entre las dos variables. Usted puede dar el precio en el rango inferior de la estimación (lo que le da una baja probabilidad de terminar en el presupuesto) si realmente está interesado en obtener el negocio incluso si pierde dinero (por lo general, por razones estratégicas para ingresar al cliente la primera vez, hacer un proyecto importante dentro de un cliente existente, etc.) O usted puede poner el precio en el rango mas alto en el caso que no quiera correr muchos riesgos o pueda mostrar un beneficio adicional al cliente para obtener un precio mayor. Es importante hacer esta recomendación ya que he escuchado (y McConnell también!) que muchos vendedores empujan el área técnica para reducir las "estimaciones" para obtener el proyecto, cuando en realidad lo que tiene que ser reducido es el precio! Esto crea confusión durante el proyecto. Separar las estimaciones de los precios aumenta la responsabilidad del equipo de ventas (ellos necesitan comprender y hacer frente al hecho de que pondrán el precio con el rango más bajo y el motivo que llevó a que lo hagan). También mejora la planificación del equipo de desarrollo, porque si hay una gran diferencia entre el precio y la estimación, el proyecto tiene que ser planificado y gestionado como de altísimo riesgo. Cuando estima el precio estos (estimación y precio) se unifican en una sola palabra llamada "estimación" (que no es cierto, ya que evita la separación de la estimación y el compromiso) y aquí comienzan a pasar la mayoría de los conflictos y los problemas de un proyecto contratado.
- Intente no dar la relación precio/compromiso luego del inicio del cono de incertidumbre. Claramente, este es el modelo ideal, pero muchas empresas no lo hacen regularmente porque se sienten presionados competitivamente en el caso que demoren en dar una estimación. Una explicación para los profanos en la materia: El cono de la incertidumbre define que errores de estimación al comienzo de un proyecto poco especificado puede ser del orden de 4 veces hacia arriba o hacia abajo! Recomiendo leer el artículo The Cone of Uncertainty de Steve McConnell para entender porque todavía estimamos tan mal en la industria del software (en realidad se llega a la conclusión de que no se trata de un problema de estimación, sino de compromiso!!!).
- Trate de negociar para realizar el proyecto en iteraciones pedazos menores. Al hacer esto, los datos y métricas de precios y plazos de las iteraciones iniciales ayudarán a estimar las próximas con mayores posibilidades de éxito. McConnell cree que la calibración comienza a ser buena con 3 iteraciones realizadas, sin importar el tamaño de cada iteración.
- Trate de hacer cotizaciones de precios con proyectos teniendo dos o mas fases. Detallo cómo se puede hacer esto en un proyecto mediante RUP en mi conferencia indicada anteriormente. La idea principal es que usted consiga hacer frente a las fuentes de variabilidad y riesgo (tales como los requisitos inestables y la arquitectura ejecutable) en la primera etapa para lograr poner mejor el precio de la segunda fase. Esa es la segunda oferta en las negociaciones. La primera es intentar un contrato de alcance variable (el ideal, pero más difícil de conseguir).
- Recolecte datos históricos sobre las estimaciones de tiempo de propuesta frente a los eventuales resultados para poder construir el cono de incertidumbre de su empresa. Haciendo eso, usted puede manejar estimaciones de proyectos con cantidades diferenciadas de información, de acuerdo con su posición en el cono de incertidumbre. Es decir, proyectos con pocos requisitos deben ser tratados como si estuvieran en el inicio del cono. Proyectos con parte de los requisitos detallados, y ya contiendo la arquitectura ejecutable de referencia deben ser tratados como estando en el medio del cono.
- Sea muy iterativo desde el inicio del proyecto, no importa si el precio fue puesto con una o dos fases. Desarrollar de manera iterativa te proporcionará la real medida del progreso y avance de un proyecto. Construyendo software en ciclos cortos te dará idea de los riesgos del proyecto, sobre costos y plazos. Podrás negociar con el cliente lo más temprano posible en el ciclo de vida del proyecto y, por tanto, no tendrá que oír la famosa frase: "Ahora lo dices, faltando tan sólo 15 días para poner el sistema en producción, me adviertes que el proyecto se va a demorar?"
- Documente y detalle lo máximo posible todos los supuestos que asumió al estimar el proyecto y colóquelos en el contrato. Por ejemplo, si el cliente no establece una plataforma para desarrollar el proyecto, participe a su arquitecto y coloque en el contrato exactamente qué plataforma, tecnología, frameworks y componentes utilizará. Intente establecer las premisas y acuerdelas con el cliente. Él debe aceptar estas premisas, especialmente en proyectos en los que el cliente quiere el precio fijo, pero no ofrece muchos detalles de las necesidades y los requisitos (el peor de los casos).
- Gestione el conjunto de sus proyectos, como una cartera de inversiones, es decir, aceptando que algunos van a dar beneficio y otros pérdida. Desde un punto de vista realista, si se estima en el inicio del cono simplemente no hay una respuesta mágica del modelo para mejorar la estimación proyecto a proyecto. El hecho es que los resultados en relación con las estimaciones varíarán en varios grados y, a menudo basado en la suerte. Ahora, si te focalizas en la cartera de proyectos en su conjunto tendrás una variación menor. Otro punto importante es que los proyectos se miden en las empresas proveedoras a través de métricas financieras. Y en varias de ellas existe un único número para comparar todos los proyectos. ¡Eso es un error! Los números financieros deben tener en cuenta las decisiones tomadas por los vendedores, especialmente cuando explícitamente reducen el precio para ganar el proyecto por razones estratégicas (véase la recomendación 3). Sería un gran error de gestión de recursos humanos sólo premiar a los equipos o gestores de proyectos que han obtenido grandes beneficios de los proyectos. También debemos evaluar la estimación original (y no el precio) y la vinculación con otras variables. Al premiar a alguien sobre la base de una sola variable harás que busque a una sola variable olvidándose de otras.
Por último, al final de cuentas la realidad es que no es posible resolver el problema específico de las estimaciones al inicio del cono de incertidumbre utilizando puramente prácticas de estimación. Tendrías que cambiar cuando se está realizando la estimación de (más adelante en el cono), o lo que está estimando (carteras de proyectos versus proyectos individuales) o cómo haces la estimación (utilizando contratos de alcance variable o romper el proyecto en dos o más fases). Así que no sea ansioso y desesperado con las estimaciones realizadas en el inicio del cono. El error de ellas no es tuyo... ¡es inherente a la propia variabilidad en el desarrollo de software!
