Creo cronogramas de MS Project para el gobierno y recientemente me mudé a un nuevo puesto en el personal donde se me pide que desarrolle y controle cronogramas para tareas que son bastante vagas, es decir, cree un cronograma que nos diga cuánto tiempo llevará desarrollar un reglamento y cómo cargarlo. Mi experiencia anterior en el desarrollo de cronogramas fue en la creación o despliegue de elementos tangibles: equipo pesado, armas, sistemas de software/hardware, etc.
¿Cómo debo proceder, además de depender de las PYMES para estimar duraciones u horas de trabajo anteriores para documentos similares?
¿Alguna sugerencia sobre cómo proceder que no sea confiar en las PYMES para estimar duraciones/horas de trabajo anteriores para documentos similares?
Uno de los principios centrales de la estimación efectiva es que solo las personas que realmente realizarán el trabajo están calificadas para estimar cuánto tiempo les llevará realizar una tarea determinada. En lugar de mirar otros proyectos o preguntar a expertos en la materia que pueden no estar directamente involucrados en el proyecto, debe desarrollar sus estimaciones con la cooperación activa de las personas que realmente producirán el incremento de trabajo. Al intentar pasar por alto a los ejecutores de tareas para la estimación, corre el riesgo de aplicar estimaciones no válidas a su programación.
Al aplicar estimaciones de tareas realizadas por otras personas, está haciendo varias suposiciones implícitas:
Piénselo de esta manera: si Alice pudiera realizar una tarea en un día, pero Bob tardaría tres días, realmente no importa que a Alice le lleve un 66% menos de tiempo realizar la tarea porque no está en su equipo de proyecto. —Bob lo es, y la programación precisa consiste en realizar estimaciones basadas en las capacidades de Bob para realizar el trabajo.
Basar el trabajo-esfuerzo en algo diferente a las habilidades y los recursos realmente disponibles es realmente establecer un objetivo de gestión en lugar de desarrollar una estimación válida. Es posible que simplemente no sea una estimación válida para su equipo y, suponiendo que lo sea, probablemente conducirá a un juego de culpas post-mortem en lugar de un conjunto completo de entregables.
Su experiencia puede ser diferente. Ese es el punto. :)
¿Tiene acceso a otros entregables similares? En algunos casos se enumeran los nombres de los contribuyentes. A partir de eso y un poco de investigación, es posible que pueda determinar aproximadamente el tamaño y las habilidades necesarias para el equipo.
Incluso con el aporte de las pymes, desarrollar algo como las regulaciones va a ser difícil en el mejor de los casos porque generalmente implica lograr que un comité esté de acuerdo con algo. La discusión sobre el timeboxing va a ser muy importante.
En el peor de los casos, podría inventar algunos números e hitos para su primer prototipo/borrador/capítulo. Un pequeño trabajo que todavía es un entregable. No estarás cerca a menos que tengas mucha suerte, pero te dará algo de experiencia para saberlo para la próxima ronda.
Un pequeño consejo que podría dar es que si las estimaciones son demasiado grandes, el trabajo/creep llenará el exceso, consulte la ley de Parkinson .
gestiono proyectos para el gobierno; (y también soy Mark en Virginia, por extraño que parezca), pero no creo que esto sea un problema.
¿Cuánto tiempo lleva desarrollar un reglamento? Depende completamente del alcance de la regulación: la ley llevará más tiempo que la política, que llevará más tiempo que la orientación.
Pero, fundamentalmente, los pasos son los mismos que para desarrollar código (¿qué experto en tecnología fue el que dijo en broma que el código es ley para Internet?) Debe definir el alcance/los objetivos, identificar las restricciones, identificar a las partes interesadas, refinar el alcance y las restricciones en función de en la entrada de las partes interesadas. Ese es el plan. Luego, diseña la política, desarrolla un texto basado en el diseño y luego coordina y prueba. Debe tener SME para cada una de esas etapas, al igual que cuando escribe código.
He tenido éxito en diseñar el plan y luego informar a las partes interesadas sobre el plan y luego impulsar el consenso dentro del plan. Dejamos muchos temas potenciales en el piso porque no creíamos que pudiéramos llegar a un consenso dentro de los límites de tiempo que habíamos establecido.
Tiene un producto "suave" que podría tardar desde unos pocos días hasta años en crearse, es nuevo en este trabajo y no quiere depender de las PYME. Esto es muy simple de programar porque no es posible la exactitud ni la precisión del valor estimado ni de la planificación. Todo lo que necesita es una línea, crear una regulación, y cargar el nombre de todos en ese paquete y luego crear la duración para igualar cualquier fecha límite arbitraria que se le haya dado. No hay forma de rastrearlo, así que no te molestes en intentarlo.
En serio, necesita PYMES que sean parte del proceso de desarrollo de la regulación. E incluso entonces, su rango de estimación será enorme, por lo que la precisión de su valor de planificación será bastante baja de todos modos. Si está acostumbrado a productos tangibles que se construyen una y otra vez en múltiples proyectos, donde sus pronósticos tienen un alto grado de confiabilidad y validez, tendrá un choque cultural con un producto más suave como este.