Por cada hora de código de corte, ¿cuántas horas de proyecto se dedican a otra cosa?

Argumentaré que escribir código es probablemente una de las partes menos importantes del proyecto. En mi opinión, es un medio para un fin, al final del día estás traduciendo los requisitos de un cliente en una sintaxis particular que puede ser ejecutada por una máquina para brindar beneficios a ese cliente.

• "Recopilación de requisitos, análisis comercial y de sistemas" y "Diseño funcional y técnico" : debe dedicar mucho más tiempo a estos que a escribir código. Si los requisitos y el diseño no están claros, se está condenando a una gran cantidad de reelaboración y pérdida de tiempo en el mejor de los casos, o a un producto de proyecto que no brinda los beneficios planificados en el peor de los casos.
• "Pruebas del sistema, incluida la planificación de pruebas y el tiempo del desarrollador para corregir errores" y "Tiempo del desarrollador para corregir errores que surgen de las pruebas de aceptación del usuario" : no creo que nadie dedique el tiempo que debería, hay demasiada presión para sacar algo. rápido. Idealmente, asigna una cantidad sustancial de tiempo en sus planes para probar y corregir errores (aproximadamente 20-30% del tiempo total del proyecto). Esto parece mucho, pero recuerda que no tienes forma de predecir a priori cuántos errores tendrás o qué tan difícil será resolverlos.
• "Planificación de implementación, implementación y soporte posterior a la implementación" : puede tener el mejor código del mundo, pero si su implementación es deficiente, su proyecto no obtendrá los beneficios que debería. Por analogía, puedo construir el automóvil con la mejor ingeniería del mundo, pero si no tengo un buen plan para venderlo y mantenerlo después de la venta inicial, estaré fuera del negocio más temprano que tarde.
• "Gestión de proyectos, requisitos y tutoriales de diseño" : esto depende totalmente de la criticidad y la complejidad de su proyecto. Necesitará más supervisión/gobernanza incluso para el proyecto más simple si va a hacer o deshacer su empresa. Dicho esto, la supervisión del proyecto es probablemente la única pieza que adaptaría para permitirme asignar más presupuesto a la codificación.

TL;DR

Ha descrito un escenario en el que la sobrecarga de su proceso es en realidad solo alrededor del 10%. Eso ciertamente parece adecuado para la mayoría de los propósitos.

Es posible que esté clasificando incorrectamente los requisitos previos y las dependencias como sobrecarga del proceso. Al hacerlo, ha determinado incorrectamente que su proceso está desperdiciando el 80 % de sus horas-hombre disponibles (o incurriendo en una sobrecarga del proceso de alrededor del 500 %) cuando, de hecho, la sobrecarga del proceso parece estar muy por debajo del promedio del 35 % para la industria estadounidense como entero.

Los niveles aceptables de sobrecarga del proceso son en realidad solo objetivos de gestión y variarán según la organización, el sector laboral y el marco de gestión de proyectos. No existe un número único que sea ideal en todos los escenarios.

Requisitos previos del proceso

En cierto modo, está mirando las cosas al revés porque su pregunta asume axiomáticamente que escribir código es el propósito principal de su proceso de gestión de proyectos. no lo es Entregar valor de manera predecible y controlada es la razón de ser de la gestión de proyectos.

En general, la mayoría de los pasos adicionales que ha enumerado como gastos generales no lo son . Como ejemplo, la recopilación de requisitos no es realmente una sobrecarga, ya que no puede entregar un código que funcione si no sabe qué código escribir o qué se supone que debe hacer ese código una vez que está escrito. Por lo tanto, la recopilación de requisitos es un requisito previo para escribir el código; o, si prefiere darle la vuelta, escribir código depende de la recopilación de requisitos.

La mayoría de los pasos que ha enumerado agregan valor al proyecto. Se aseguran de que esté construyendo las cosas correctas y en el orden correcto. Eso los clasifica como requisitos previos y dependencias, en lugar de desperdicio .

Gastos generales del proceso

Si bien seguramente existe una definición técnica, en términos prácticos, la sobrecarga del proceso es todo lo que no agrega valor intrínseco a los entregables, pero que, sin embargo, es necesario para el funcionamiento del proyecto en sí. Las reuniones de proyectos, los artefactos de gestión de proyectos y las comunicaciones de proyectos suelen ser buenos ejemplos de gastos generales típicos.

Haz las matematicas

Ha definido un proceso que totaliza 5 horas-hombre por función, de las cuales solo 30 minutos deben clasificarse como gastos generales. Por lo tanto, solo gasta el 10 % del tiempo de su proyecto en gastos generales de proceso. Por el contrario, un proyecto típico de Scrum a menudo requiere alrededor de un 30 % de gastos generales para sus procesos.

A menos que tenga un impulsor comercial específico para reducir ese número por debajo del 10%, no veo un problema real. Sin embargo, si la gerencia o su equipo de desarrollo siente que hay desperdicio que se puede recortar, siéntase libre de ver dónde puede hacer algunas mejoras incrementales sin reducir la calidad.