Antes solíamos decir que eramos malos para hacer estimaciones, debido a que era muy frecuente que las cosas tardaran más de lo que decíamos que demorarían. Siento que si bien este tema ha sido agotado en los ámbitos ágiles, muchos proyectos siguen llegando a esos momentos de “necesitamos una fecha”. Esta es una recolección de mis opiniones y conocimientos respecto del tema.

Estimación

Barry Boehm, ya en en 1981 en su libro Software Engineering Economics intentaba adoptar el cono de incertidumbre desarrollado por la industria química como modelo estadístico de predicción (yo lo aprendí de Steve McConell en Code Complete 2).

Con esta y otras iniciativas de gestión de proyecto se trata desesperádamente de modelar lo inmodelable. De predecir el futuro. Como predecir el futuro es algo que no se puede hacer, estas técnicas generalmente intentan incorporar subjetividades como “grado de confianza” o “probabilidad de éxito”. Finalmente lo único que logran es que además de estimar fechas concretas de término, también estimemos cuánto nos desviaremos. Es un estimado por encima de otro estimado. En estadística nos enseñan el concepto de Propagación de errores y parece que todos convenientemente lo ignoran en gestión de proyecto. Es una especie de pensamiento mágico.

Nunca fuimos malos para estimar. No se puede ser malo para estimar, tampoco se puede ser bueno para estimar, ya que una estimación no puede ser evaluada al final, ya que fue hecha sin suficiente información.

La estimación se puede usar en proyectos para estimar una fecha, por ejemplo; pero también se puede usar con personas, como por ejemplo en la frase, “estimo a mis amigos”. La estimación es una consideración. En las relaciones personales, implica que consideras valiosa a una persona para tu vida. En la gestión de proyecto significa que consideras el impacto de muchas variables para hacer un pronóstico. En su definición está incorporada la incertidumbre, es decir, una estimación en gestión de proyectos, se debe asumir que es algo incierto y no se pueden hacer planes exactos en base a las estimaciones.

Si te comprometes en base a una estimación, estás haciendo algo muy poco profesional. Estás comprometiéndote a algo que es posible que no puedas cumplir. Estás básicamente, colocándote en una mala posición voluntariamente.

En todo caso, lo sabemos. Cada vez que nos piden una fecha de término de algo, sentimos algo en el estómago que nos dice que es mala idea dar una fecha, pero rara vez logramos articular las ideas y los pensamientos debido al stress de la situación, o callamos y pensamos que esa sensación es un miedo a ser irresponsables.

Mi reflexión, es que la gestión de proyecto tradicional te encierra en una situación en donde no puedes desarrollarte profesionalmente, debido a que estás fallando constantemente y aunque no es tu culpa,  sientes que es tu culpa y todo los demás ven que es tu culpa. Pero también los incompetentes parecen encontrar la forma de ganarle al sistema y ser promovidos constantemente.

En la agilidad hemos entendido esto desde hace tiempo. Las estimaciones son una trampa.

El modelo ágil respecto de la planificación y gestión de un proyecto se enfoca en asegurar que los profesionales tienen un ambiente en el que se puedan desarrollar profesionalmente, se establecen canales de comunicación transparente para evidenciar las verdaderas incompetencias, y se enfoca en entregar valor por sobre la ejecución de un plan.

Compromiso

En la gestión de proyecto tradicional se realizan compromisos en base a fechas estimadas, como ya dijimos, eso es una trampa que establece un ambiente tóxico para los profesionales involucrados. Sin embargo, ¿Cómo podemos funcionar como industria responsable sin compromiso?

La pregunta no solo es válida, es crítica. El compromiso no se puede sacrificar, debido a que la responsabilidad y nuestro profesionalismo se deben reflejar en un alto compromiso, de otra forma nuestro trabajo no tiene valor.

Pero el compromiso sobre las fechas es un compromiso falso. Si te comprometes a entregar en una fecha, el cliente no solo asume el compromiso en la fecha, sinó también en las funcionalidades completas que has planificado y también en la calidad que has ofrecido y el costo. No puedes fallar en nada.

La respuesta normalmente es hacer un presupuesto por sobre los estimados, algún múltiplo de 1.5 o 2.0 de lo estimado (que generalmente, lo estimado también vienen inflados) pero luego eso se reduce en la negociación y queda cualquier cosa. Incluso si llegara a pasar tal cual, nada asegura que ese margen es suficiente. Es simplemente otra estimación.

De esta antigua encrucijada es de donde surge el movimiento estadístico de gestión de proyecto, junto con la fijación por procesos repetibles y certificaciones, en donde “las personas cambian, los procesos quedan”. Pero ya hace tiempo sabemos que eso tampoco funciona. Empleas un montón de gente que su única tarea es mantener cartas gantt y planillas excel y no aportan nada de valor al proyecto, o peor, son un constante y tóxico aislante entre el problema y quienes lo solucionan.

Otra cosa, el compromiso es solo del “proveedor”. El cliente generalmente solamente establece un interlocutor responsable de verificar que haya un cumplimiento de los “hitos” y que grite por cualquier desviación. No hay compromiso por parte del cliente, solo hay un contrato.

La forma de resolver este problema de compromiso es sencilla, pero requiere de algo de reconstrucción del paradigma de proveedor-cliente.

Parte por entender que nosotros no somos contratados para desarrollar un software, sino para resolver un problema. Es un proyecto tanto de investigación como de desarrollo. Siempre. No importa si hay un documento de 500 páginas detallando una solución a un problema. Son solamente 500 páginas detallando la arquitectura de un castillo en el aire que no ha sido puesto a pruebas con usuarios ni ha considerado la experiencia y capacidades del equipo que lo va a solucionar. El primer paso de un proyecto debiera ser una reunión de kick-off con todos los involucrados (Los jefes de proyecto, gerentes, inversores, y otras personas que no se ven impactadas por la solución, son solo un accesorio) en donde se lee el documento de requerimientos, se ríen todos y luego se quema en un fuego y se parte de cero.

La segunda parte de la solución es entender que tanto el cliente como el proveedor forman parte del equipo. Los profesionales técnicos ofrecen la experiencia y conocimiento de sus diciplinas particulares, mientras que el cliente y las partes involucradas ofrecen su experiencia y conocimiento en el problema que hay que solucionar. La incertidumbre es el pan y mantequilla del proyecto. Si quieres una buena solución, tendrás que invertir lo que corresponda. Pero no se trata de esperar infinito tiempo para que se solucione el problema. Se trata de sacar soluciones a los aspectos más críticos del problema de la manera más rápida posible, aveces probando varias soluciones al mismo tiempo, generando un retorno a la inversión lo antes posible, y comentiendo los errores lo antes posible, cuando son más baratos. ¿Cuándo va a terminar el proyecto? bueno, cuando el problema esté solucionado, o cuando ya se ha reducido tanto que no justifica seguir invirtiendo.

Avances constantes, inversión constante, retorno de inversión constante, comunicación mutua, trabajo en equipo, objetivos comunes.

Los proyectos no son necesarios, las estimaciones no son necesarias, pero hay un fuerte compromiso de todos por solucionar el problema.