Lo que la mayoría de la gente no entiende es el concepto de “metodologías”. La respuesta directa a su pregunta es: si todos los requisitos son conocidos y están bien definidos, se sabe que son inmutables, si se sabe que los recursos asignados son correctos, si se atienden todas las dependencias, es el ajuste perfecto para lo que llamaría ” enfoque estricto de cascada de caja negra “, con cero intervención externa, simplemente siguiendo el plan al pie de la letra.
La realidad es que no existe tal cosa como “todos los requisitos conocidos” y “todos los requisitos son inmutables”. Algunos requisitos son desconocidos y algunos cambian durante el proyecto. La única forma de lidiar con la incertidumbre es dividirla en pequeños trozos, ejecutar, verificar el resultado, reevaluar y comenzar de nuevo (un resumen de lo que Deming ya definió como PDCA). Lo que significa hacer pequeñas “cascadas” en cortos períodos de tiempo para permitir la reevaluación y ajustar las direcciones. Decidimos llamar a eso “Ágil” (es una definición muy aproximada, lo sé)
El problema es que la mayoría de las personas que comenzaron recientemente, que no tienen un conocimiento completo de lo que realmente es la gestión de proyectos y cómo hemos evolucionado hasta este punto, comienzan a sacar conclusiones basadas en suposiciones inexistentes.
Una conclusión extrema de los viejos tiempos es que “es posible mapear todos los requisitos” y al hacerlo es posible hacer un plan muy preciso. Una “estimación” se convierte en una “predicción” y comenzamos a hablar de “desviación estándar”, suponiendo que este es un proceso preciso y repetible. Por supuesto que esto está mal. El supuesto de desviación estándar solo se rompe porque un proyecto no sigue una distribución Normal. Su naturaleza compleja requiere una distribución de Paretto donde “el 20% del proyecto puede tomar el 80% del tiempo”, como todos sabemos por anécdota.
En el otro extremo, entendemos que la situación anterior es incorrecta y sacamos otra conclusión errónea: debido a que las predicciones son imposibles, las estimaciones también son imposibles, y no vale la pena intentarlo, por lo que asumimos que todo es completamente desconocido e iteramos para siempre hasta todos “sienten” que llegamos a un “producto terminado”. ¿Y cuando está hecho? Bueno, se hace cuando se hace, ni un minuto antes. Pero no intentaremos dar una “estimación”, lo que genera la confusión de que “estimación” equivale a “predicción”.
La gente llama al primer modelo extremo “tradicional” o “cascada” y al segundo modelo “ágil”. Tanto las definiciones como las conclusiones están muy equivocadas.
La gente nunca debe sacar conclusiones basadas en suposiciones irreales o inexistentes. Todo tiene contexto. Vamos a evaluar el terreno más común:
- La mayoría de los proyectos no son del tipo Investigación y Desarrollo (I + D), donde existe una hipótesis muy abstracta que requiere una ciencia dura y una profunda experimentación. La mayoría de los proyectos son mashups de casos de uso existentes. Ecommerces, sistemas de gestión de contenidos, ERP, redes sociales, etc.
- Cualquier producto puede tener tantas características como la creatividad o la demanda de los interesados deseen. Sabemos que debemos “priorizar”. El problema es que la mayoría de la gente olvida que cada proyecto nunca se trata de las características o la cantidad de código producido. Siempre se trata de los “Objetivos”. “Qué problema está tratando de resolver este producto”. Ahora, en lugar de pensar en “qué características se sienten importantes”, debemos preguntarnos “qué características son realmente relevantes para lograr ese objetivo específico”. Pensando de esa manera, podemos encontrar rápidamente lo que debe estar dentro y lo que puede estar fuera para una próxima versión.
- Es irreal pensar que todo fluirá sin problemas de acuerdo con planes arbitrarios. Los planes funcionan según los supuestos. La gente generalmente se olvida de los supuestos. Por ejemplo: sabemos que podemos producir un conjunto particular de pantallas HTML en 10 días, pero se supone que el cliente entregará todas las sesiones de fotos requeridas el día 1. Lo que afirmamos es: “tomará 10 días si es necesario los activos están disponibles el día X; de lo contrario, el proyecto retrasará tantos días como sea necesario para que los activos estén disponibles “. Esta es una condición aceptable de cualquier plan. Una propuesta de precio fijo tiene que tener varios de esos supuestos porque un plan sin supuestos es solo una ilusión.
- La mayoría de los productos pueden describirse como una colección de “estructuras de desglose del trabajo” (WBS). Sí, esta es la jerga “tradicional”, y sí, es correcta. Como he dicho antes, la mayoría de los proyectos son solo combinaciones de “casos de uso” existentes. Si podemos describir un proyecto en términos de una colección de esos “casos de uso”, cualquier programador experimentado puede comenzar a ver fácilmente “órdenes de magnitud”. Por ejemplo, este proyecto simple es uno de esos ecommerces simples junto con un CMS simple. Teniendo en cuenta los requisitos, sabemos que suelen tardar 2 meses para el comercio electrónico y 1 mes para el CMS. Por lo tanto, es probable que el proyecto tarde al menos 3 meses en completarse. ¿Es esta una predicción precisa? No, pero es una estimación justa. Un profesional experimentado también sabe que lleva tiempo poner en marcha el proyecto, hay gastos generales involucrados en la integración de esas partes, hay gastos generales para hacer una calidad y garantía (Q&A) adecuadas, implementar en la producción, etc. Digamos que esto se suma a otro mes, ahora nos estamos acercando a un proyecto de 4 meses. Así es como hacemos análisis de abajo hacia arriba. Nuevamente, esto no es predicción, es una estimación aproximada.
- no necesitamos suponer que conocemos todos los requisitos y que esos requisitos nunca cambiarán. Por el contrario, los supuestos garantizan la validez del plan. Un supuesto cambia, necesitamos tener reglas claras de compromiso. Por ejemplo: “si reemplazamos una característica con otra que toma aproximadamente el mismo tiempo, no necesitamos cambiar los plazos y costos originales” o “si un activo requerido tarda más de lo previsto en llegar, asumimos que el plazo será se retrasará al menos la misma cantidad de días “,” si no se realiza el último pago, no se transferirá la propiedad intelectual de los activos producidos “, etc. Esto es” flexibilidad “y sí, el contrato de precio fijo puede ser tan flexible.
- un proyecto utilizará todo el tiempo que le dediques, esta es una anécdota que demuestra ser cierta muchas veces. El problema es que los desarrolladores no mantienen una productividad constante durante todo el proyecto. Por lo general, comienzan lentamente, recogen vapor y alcanzan la máxima velocidad en la segunda mitad del proyecto. Los métodos “ágiles” intentan minimizar esta diferencia. Si mide dónde está, puede corregir más rápido. Si mide más adelante en el proceso, no tiene más tiempo para corregir. Es por eso que la suposición de “fallar rápido” es tan importante en cualquier tipo de proyecto. Los proyectos de precio fijo pueden “fallar poco al principio” que ajustamos. No es razonable pensar que los clientes van a tirar su dinero por nada. Se enojan cuando no les damos opciones. Por ejemplo, decirles al final del proyecto que necesitaremos un mes adicional no es razonable. Es razonable decirles que podríamos necesitar un mes adicional, en la primera semana del proyecto. Puede pasar. Asumimos el costo de esa 1 semana si es necesario, pero el cliente todavía tiene tiempo para dirigir y se pueden hacer correcciones. Pueden decidir cortar algo del alcance. Pueden decidir que el tiempo extra lo vale. Pero tienen la opción. Lo único que realmente perjudica a los proyectos son los desarrolladores que ocultan los problemas hasta que ya no se pueden solucionar.
Todo se reduce a la experiencia. La mayoría de las personas pueden leer toda la literatura disponible y no comprender realmente lo que significa administrar un proyecto. El resumen de todo lo que he dicho es que realmente no importa usar métodos “tradicionales” o métodos “ágiles”. Todos los métodos son herramientas, utilizamos lo mejor para la situación actual, ni más ni menos.
Si puedes tomar algo de todo lo que he dicho, recuerda esto:
- Los proyectos de precio fijo no son malos: la mayoría de la gente simplemente no sabe cómo administrarlos.
- los clientes nunca saben todo lo que necesitan, es nuestro trabajo llenar los vacíos y crear reglas claras de compromiso.
- las estimaciones no son predicciones (hay razones por las cuales son palabras diferentes). Las estimaciones son órdenes de magnitud.
- Una propuesta de proyecto debe delinear suposiciones claras, no solo el alcance detallado.
- Los procesos ágiles son importantes para que el equipo falle rápidamente.
- Una “propuesta” de proyecto no es una “promesa de entregables”, es una propuesta para una relación con responsabilidades mutuas. No importa si es un proyecto de alcance flexible o un proyecto de precio fijo. Ambos fracasarán sin reglas claras de compromiso. Un producto que no tiene “objetivos” nunca se “terminará” con éxito.
Esos son entendimientos generales en los que creo que la gente debería pensar antes de hablar sobre “Usaré la metodología X” o algo así. No es la metodología que crea un proyecto exitoso, es la comprensión de lo que está tratando de lograr lo que lo hace.
