El estancamiento entre los procesos Agile y Waterfall ha persistido en gestión de proyectos discurso durante décadas. Los equipos de desarrollo de software program prosperan en entornos ágiles, pero la falta de soporte de gestión es uno de los Principales obstáculos para la transformación ágil. Un gerente de proyecto que trabaja en la industria del software program durante un período de tiempo prolongado probablemente se haya encontrado con un C-suite que quiere que “hagan Waterfall”. Pero, ¿qué significa eso exactamente en la práctica?
Durante años, los estudios han demostrado una relación positiva entre el uso de Marcos ágiles y éxito del proyecto, y puede ser tentador para un gerente de proyecto creer que solo necesita vender a sus ejecutivos corporativos los resultados de Agile. Pero es igualmente importante comprender lo que le gusta a la alta dirección de la Metodología de cascada. Si comprende las salvaguardias financieras que Waterfall ofrece al C-suite, puede diseñar un marco híbrido que cerrará la brecha entre Prácticas ágiles y empresa Waterfall de una vez por todas. El comienzo de esa comprensión se encuentra en la historia de origen en su mayoría no contada de Waterfall.
Los oscuros orígenes de la metodología Waterfall
La mayoría de las personas en la gestión organizacional asocian el término “Cascada” con el gráfico a continuación, que proviene de “Gestión del desarrollo de grandes sistemas de software program”, un artículo académico influyente escrito por Winston W. Royce, PhD, en 1970. La ilustración de Royce es ampliamente reconocida como la primera expresión del desarrollo de Waterfall.
La acreditación del desarrollo de Waterfall a la investigación de Royce es una de las extrañas ironías de la industria del software program. En su artículo, Royce nunca usa la palabra “cascada” ni la defiende como un sistema efectivo; en realidad, presenta lo que se conocería como Waterfall como una advertencia: un ejemplo de un proceso que es “arriesgado e invita al fracaso” porque no tiene en cuenta la iteración necesaria entre las etapas de desarrollo de software program.
Royce no estaba solo: 18 años después, Barry W. Boehm, PhD (que pronto se convertiría en director de DARPA), usó un muy ilustración comparablede nuevo como ejemplo de una problemática Ciclo de vida del desarrollo de programas, y propuso el desarrollo iterativo como una alternativa favorable. En 1996, casi toda la industria del software program aprobó un ciclo de desarrollo iterativo denominado Proceso racional unificado (RUP), que en sí mismo period una síntesis de las mejores prácticas universalmente reconocidas por los ingenieros de software program.
Esto plantea una gran pregunta: ¿Por qué alguien en la gestión rechazaría el uso de Agile en lugar de Waterfall, un marco que, desde su inicio, los expertos y profesionales de la industria han considerado que está en desacuerdo con las prácticas de desarrollo eficiente?
OpEx vs. CapEx: el caso financiero para Waterfall
La razón por la que Waterfall sigue estando a favor requiere un poco de conocimiento sobre una función comercial en la que los equipos de desarrollo rara vez piensan: la contabilidad.
En la contabilidad de partida doble, existen dos clases de gastos: gastos operativos y gastos de capital (también conocido comúnmente como OpEx y CapEx). Cualquier gasto cut back las ganancias netas de una empresa, pero un gasto operativo, como el alquiler, la nómina o el seguro, lo cut back. más. El dinero se gasta y, por lo tanto, ya no está en los libros. Un gasto de capital, como bienes raíces, equipo de fábrica o muebles de oficina, cut back menos las ganancias debido a una técnica contable llamada depreciación, que distribuye el gasto a lo largo de varios años. Además, una vez que se ha comprado un activo, se considera parte del patrimonio de la empresa.
Entre 2000 y 2002, incluso cuando el Manifiesto ágil se estaba desarrollando: el mundo corporativo se vio sacudido por un par de grandes escándalos contables, comenzando con la compañía de energía de EE. UU. Enron. En pocas palabras, Enron (con la supuesta complicidad de la firma de contabilidad Arthur Andersen) ocultó grandes pérdidas a los inversores mediante la mala gestión intencional de los gastos operativos y los gastos de capital. Esto period parte de un esquema mayor para inflar fraudulentamente sus ganancias y, por lo tanto, aumentar su valor en el mercado de valores en miles de millones de dólares.
Poco tiempo después, un escándalo comparable ocurrió en la compañía estadounidense de telecomunicaciones WorldCom. WorldCom también ocultó pérdidas al categorizar erróneamente deliberadamente los gastos operativos como gastos de capital, y la sesión del Congreso de 2002 reaccionó aprobando la Sarbanes-Oxley. En las disposiciones de este proyecto de ley se incluyeron nuevas reglas que hicieron que los funcionarios de la empresa, como el director ejecutivo y el director financiero, fueran personalmente responsables de las pérdidas de los accionistas que ocurrieron debido a la falta de diligencia debida.
Cuando se trata de desarrollo de software program, CapEx versus OpEx es un problema especialmente complejo: CapEx se ve bien en un steadiness common, lo que permite a las empresas reportar un mejor ingreso operativo y pedir prestado montos más grandes. Sin embargo, la desventaja es que los criterios de capitalización han evolucionado y requieren documentación, revisiones y aprobaciones, todo lo cual puede obstaculizar en gran medida el proceso de desarrollo de software program.
Aquí es donde gestión de proyectos juega un papel central. A raíz de esta legislación, los directores financieros necesitaban un mecanismo de seguridad que pudieran señalar: un estilo de gestión que pudiera demostrar que habían cumplido con los requisitos de la Ley Sarbanes-Oxley. El Instituto de Gestión de Proyectos tenía una solución: el proceso de puerta de fase (también conocido como puerta de etapa). Esta técnica de cascada utiliza una serie de “puertas”: pausas en las que se necesitaría la aprobación ejecutiva para que avance el desarrollo. Al definir una etapa que contenía solo actividad elegible para CapEx y aislarla de todas las demás etapas, los CFO podían demostrar que habían ejercido la diligencia debida al enumerar un gasto como gasto de capital.
Avance rápido hasta el día de hoy, y la gestión de puerta de fase ha sido el estándar de facto para proyectos de desarrollo en empresas públicas durante 20 años: Stage-Gate Worldwide estima que El 80% de Fortune 1000 usa alguna variación de este marco. Para un desarrollador Agile o un gerente de proyecto, esto puede parecer desconcertante. ¿Tu CFO no conoce los beneficios de Agile? Puede que lo hagan o no, pero de cualquier manera, lo más importante que debe recordar un gerente de proyecto es: No les importa.
Cuando el CFO quiere que usted “haga Waterfall”, no se basa en la creencia de que Waterfall es la forma más efectiva de entregar software program. Rara vez les importa si los programadores usan RUP, MeléXP, cristal, FDD, DSDM, Tableros Kanban, o cualquier otra técnica de desarrollo o marco de gestión; lo que les importa es capitalizar el proyecto sin violar los términos de la Ley Sarbanes-Oxley.
La buena noticia es que todo lo que necesita hacer para asegurarle al CFO que el proyecto pasará una auditoría se lleva a cabo fuera del proceso de desarrollo actual. Si puede asegurar al C-suite que sus necesidades serán satisfechas, deberían estar dispuestos a una metodología híbrida en la que las preocupaciones financieras se manejen a través de Waterfall en la etapa de planificación y el desarrollo se realice en un marco Agile:
Navegando por las Cataratas
Si un gerente de proyecto entiende lo que quiere su CFO y puede asegurarle la supervisión operativa proporcionada por un marco de puerta de fase, no hay razón para usar Waterfall sobre Agile en el desarrollo. Simplemente aborde los requisitos de la gestión de puertas de fase con el entendimiento de que su propósito es financiero y authorized y no tiene que afectar el trabajo de desarrollo de su equipo. Aquí le mostramos cómo comenzar:
Trate la elaboración de presupuestos como iterativa… hasta que deje de serlo
Cada año, el presupuesto corporativo asigna una cantidad fija a los gastos de capital. Una pequeña parte de eso se asigna a proyectos de desarrollo de software program, y los líderes empresariales negocian la mayor parte posible para sus proyectos. Este proceso de negociación generalmente continúa durante los primeros dos o tres meses del año fiscal.
La negociación es extremadamente iterativo, por lo que presupuestos de proyectos fluctuar constantemente a lo largo de este proceso. Empodere a su patrocinador comercial brindándole estimaciones ajustables. El objetivo aquí es establecer un sobre presupuestario, por lo que las opciones amplias para múltiples contingencias serán extremadamente útiles. Por ejemplo, junto con una estimación de referencia, puede proporcionar una opción más económica que sería factible si se cumplen las condiciones de ahorro de costos, como realizar la migración de datos a través de la entrada guide, o una opción más costosa si se incluyen funciones adicionales, como una aplicación móvil. Esto ayudará a su patrocinador comercial a ajustar su solicitud de presupuesto a medida que se inician las negociaciones del comité de tesorería.
Estas estimaciones deben proporcionarse antes de las negociaciones presupuestarias, porque una vez que el comité de tesorería aprueba los proyectos para el año, no hay vuelta atrás. En el sistema de puerta de fase, la puerta 3 es donde el proyecto recibe la aprobación de tesorería. Existe flexibilidad en la presupuestación, pero solo en la parte inicial del proceso, antes de que ocurra esta puerta.
Comprender la Materialidad
Su oficina de management de proyectos (o, si no tiene una, su contralor financiero) puede ayudarlo a comprender los umbrales de la empresa para materialidad—el punto en el que la variación financiera es lo suficientemente importante como para ser registrada: la compra de una caja de bolígrafos puede considerarse irrelevante, pero la compra de computadoras nuevas para el equipo no lo es. La línea en la que lo inmaterial se convierte en materials varía según la empresa. Comprender el umbral de su empresa y documentarlo en consecuencia le ganará el cariño de cualquiera que tome decisiones contables.
Comparta su conocimiento de dominio con su contraparte en finanzas; por ejemplo, entender el concepto de intercambiar historias de usuario y llegar a un consenso sobre cómo manejar la práctica evitará la apariencia de incorrección. Asegúreles que si algún gasto adicional de un intercambio amenaza con superar el umbral de materialidad, lo escalará para que pueda documentarse adecuadamente.
Habla el lenguaje de las finanzas
Si aún no está familiarizado con informes de estado semanales y registros de riesgos, familiarícese. Léelos. Amarlos. Rellénelos con regularidad y precisión. dáselos a tu Oficina de Gestión de Proyectos y ellos te amarán a su vez.
Lo que es más importante, si proporciona informes o actualizaciones del presupuesto del proyecto, asegúrese de que los títulos y las descripciones de sus elementos de línea coincidan exactamente con los que utilizó cuando se aprobó el presupuesto por primera vez. Si el presupuesto aprobado se refiere a “Epic: interfaz de usuario de autenticación”, entonces eso es lo que debe incluir en su informe, no “Pantalla de inicio de sesión de Epic” o cualquier otra variación. Ignore este consejo y tendrá la garantía de crear fricción y frustración en todo el brazo financiero de la organización.
valor entregado
Si cumple con los requisitos financieros anteriores, ¡felicidades! Está satisfaciendo la necesidad del C-suite de “hacer Waterfall”. Los gastos de capital se registran correctamente y ninguna parte del proceso ha requerido ningún cambio en la forma en que se escribe el código o en la forma en que se entregan las actualizaciones. Cualquier compromiso que haya tenido que hacer en la planificación le ha ganado aliados en otros departamentos y en el C-suite. El proceso también le ha brindado una mejor comprensión de cómo su equipo puede trabajar con otras partes de la organización, en lugar de trabajar arduamente de forma aislada o, lo que es peor, trabajar en oposición a quienes se supone que deben estar de su lado.
Un purista ágil podría considerar estas preocupaciones financieras como “negociaciones de contratos”. Sin embargo, es igual de válido pensar en sus colegas financieros como clientes comerciales internos. Satisfacer sus necesidades en materia de finanzas es solo otra forma de colaboración con el cliente. Y en Agile, la percepción del cliente sobre el valor entregado siempre gana.
Lecturas adicionales en el weblog de Toptal Tasks:
¿Qué es un Agile Coach y cómo puedes convertirte en uno?
Estudios de casos de SAFe: Notas de transformación del campo
Scrum Grasp vs Agile Coach: por qué las transformaciones exitosas necesitan ambos
