Evaluación del volumen de un jefe de proyecto de trabajo - lo que es una buena metodología? [cerrado]

Question

En la actualidad, nuestra empresa utiliza ágil como su principal desarrollo. Se me acercó a mi jefe para determinar alguna metodología para la determinación de la cantidad de trabajo que hace un pesebre proyecto en un proyecto determinado en vuelo. Para ser honesto, no puedo pensar en nada a toda prueba.

Creo que la mejor pregunta es ¿Cómo evaluamos lo ocupado, en el día a día, un jefe de proyecto es?

Answer 1

Recuerde que CUALQUIER métricas que puede ocurre es más probable va a ser gamed .

[¿Puedo obtener una tarjeta de identificación para el enlace en tema de Joel en el software? :)]

Una vez dicho esto, puede intentar una unión de los siguientes enfoques:

• retroalimentación desarrollador !!! (Por ejemplo, la retroalimentación de un buen PM sería "Tenía problemas X, Y y Z y los hizo desaparecer"). No tan bueno para medir qué tan "ocupado" un PM es, pero muy bueno para medir la eficacia de él / ella es.

• Volumen y claridad nominal de los planes del proyecto (fácil de engañar)

• Tasa de cambio de planes del proyecto (fácil de engañar)

• Cantidad de reuniones / tiempo de reunión (fácil de engañar)

• Las tasas de éxito de los proyectos (en la actualidad frente al% de características entregadas frente a la satisfacción del cliente). No es fácil de engañar, pero el propio trabajo del diablo para normalizar esto a través de proyectos.

Answer 2

Los partes de horas medirá el cantidad de trabajo en un sentido (se puede ver cómo su día se rompe y así sucesivamente), pero no creo en el sentido que desea.

En última instancia no creo que hay una métrica útil para administradores de proyectos en este sentido, pero no creo que eso es un problema.

Creo que en última instancia se debe medir el éxito del proyecto en lugar de "ajetreo". Después de todo, ¿por qué te importa lo ocupado el PM es si entregan proyectos de éxito?

Un PM puede pasar medio día la elaboración de un plan de registro y mitigación de riesgos, que contiene 20 riesgos, otro puede pasar 2 días armando uno que sólo tiene 5 riesgos, pero ninguno de esos números son más útiles como una métrica de líneas de código. La clave no es cuánto tiempo se dedica a hacer, cuántas riesgos que ha identificado, lo grande que sus planes de mitigación son, pero si realmente se administra el riesgo en el proyecto con éxito .

Es mejor que mirar lo que un jefe de proyecto se pretende hacer, que es entregar los proyectos a tiempo, con el presupuesto y la satisfacción del cliente (que me gustaría usar como la última medida de la calidad más que defectos) .

Después de todo, cómo se mide la forma de "ocupado" es el CEO? ¿O es que sólo juzga por el beneficio de la empresa hace?

Para hacer esto:

• Tiempo - La única forma en que realmente se puede gamed es por las estimaciones de relleno de forma masiva y planes, y esto puede ser minimizado mediante la revisión de los planes y estimaciones y tener todas las partes pertinentes de ellos están de acuerdo (desarrolladores, PM, cliente). La otra cara de esto es que el PM debe estar de acuerdo con el plan en lugar de tener la fecha de aplicación impuesta sobre él o ella. Es posible que desee medir esto ya sea en la ejecución general o de cada hito.

• Presupuesto - medible pero gameble. Para la mayoría de los proyectos de desarrollo que la clave es su tabla de tiempos honestas de los desarrolladores y la mejor manera de asegurar esto es para que sea lo que el PM es la PM, pero no su gerente de línea. De esa manera los desarrolladores tienen a alguien para luchar contra su esquina (un director técnico, por ejemplo) si están siendo presionados para llenar hojas de tiempo para mantener el presupuesto hacia abajo. De nuevo, el PM debe acordar el presupuesto, no es razonable esperar de él para entregar en algo que se le dice que no es razonable.

• La satisfacción del cliente - Es difícil de medir, así que te sugiero que lo mantiene simple y voy con una revisión del proyecto puesto de avanzada recta con el administrador de cuentas y marcas de 10 para la comunicación, entrega y cualquier otra cosa que es importante. Es subjetivo, pero en última instancia, por lo que es la satisfacción del cliente.

Sin embargo, mucho de ello depende de la cultura de la empresa. Para algunas organizaciones que la clave será las horas facturables, la satisfacción de otros desarrolladores serán parte de la mezcla.

Answer 3

Estoy tratando de entender por qué se le ha pedido para estimar la cantidad de trabajo que hace un jefe de proyecto en un proyecto. A lo mejor es sólo una solicitud de una regla de oro, de lo contrario, indica que su jefe no sé nada acerca de la ejecución de un proyecto. Incluso cuando los proyectos se ve muy similar siempre habrá algo único sobre un proyecto:

• El equipo no es idéntica (la enseñanza el chico nuevo las cuerdas lleva tiempo)
• La especificación puede variar un poquito (Y ese poquito podría duplicar el carga de trabajo)
• A pesar de la temporada podría influir en el resultado
• y así sucesivamente y así sucesivamente

Todos y cada condición en el proyecto podría cambiar la carga de trabajo del director del proyecto, por lo que siempre será un subjetiva evaluación.

Answer 4

Yo sugeriría que utilice el mismo Burn Down y nivel de esfuerzo que se utiliza para los desarrolladores. La tarea de un PM en un entorno ágil es un poco diferente (y de tienda en tienda es diferente), pero el PM debe ser capaz de proporcionar una lista de tareas, etc. Estoy pensando en positivo y viéndolo como sus jefes enfoque para determinar la cantidad de la disponibilidad de la PM tiene.

Answer 5

La mayoría de los directores de proyectos equiparan con el estado de la responsabilidad, por lo que un jefe de proyecto que tiene capacidad de sobra es bastante probable para ser voluntario para asumir una nueva responsabilidad, porque es en su / su propio interés. En todas las organizaciones, pero las más funcionales a menudo es mejor a sobrecargarse de forma visible, para que la mirada heroica.

Es más probable que sea en el mejor interés de la organización a poco bajo carga sus gestores de proyectos, por lo que hay una cierta capacidad disponible si algo empieza a ir mal. Un gerente de proyecto bien podría optar por aplicar su / su capacidad de reserva de alguna manera constructiva en cualquier caso. politiquería excesiva u otra actividad constructiva es un buen indicador de alguien que pudiera desplegarse de manera más constructiva. Incluso en proyectos ágiles, carga de trabajo tiende a ser desigual a través de un ciclo de proyecto - por ejemplo, la entrega es a menudo una actividad de manejo intensivo -. alguien que está muy cargado de forma continua probablemente tiene mucho que hacer, y puede ser ignorar o esconder un problema grave

Si el siguiente nivel de gestión lleva a cabo revisiones regulares del proyecto, presta atención a la cantidad de problemas están siendo escalado, si los informes del proyecto se correlacionan con la noticia de la vid, y hace alguna estimación básica en las proyecciones de carga de trabajo para cada jefe de proyecto, a continuación, la organización debe ser capaz de ejecutar un sistema razonablemente eficiente.

Los gerentes tienden a ser animales políticos y psicológicos. Cualquier metodología que no se toma en cuenta que la realidad está haciendo caso omiso, por lo que es probable que se basa más en los comportamientos observados que en números duros una buena metodología para este problema.

Answer 6

Perdone si estoy siendo a purista, pero la etiqueta y la cuestión exige ágil. Lo que sería un jefe de proyecto en ágil? Es posible que ya sea que esté intentando evaluar el trabajo realizado por el propietario de un producto o de un scrum master?

En cualquier caso, ambos papeles realizan varias tareas que son difíciles de medir, por lo que probablemente su jefe está mirando la imagen equivocada.

Por ejemplo, un maestro scrum es "The person responsible for supporting the development team, clearing organizational roadblocks, and keeping the agile process consistent". Básicamente es un entrenador y un facilitador. Bloqueo de peticiones disruptivas o distracciones creadas por los niveles más altos de gestión de la negociación o la persuasión para seguir las prácticas de scrum es una de las habilidades utilizadas por los maestros de scrum. Varias de estas habilidades blandas son difíciles de medir como "trabajo", ya que no implica trabajar en un ordenador o la producción de un informe.

Creo que la métrica que su jefe se beneficiarán más de está más relacionada con el grado de eficacia del equipo y cómo se describe un scrum master para facilitar el trabajo de sus compañeros de equipo. DVK tiene entonces un punto muy válido, las métricas que cree se pueden "gamed", así que lo mejor es confiar en que sus directivos están ocupados si sus proyectos están progresando y sus equipos están contentos y el trabajo en equipo.