Cómo hacer que el acuerdo objetivo sea medible para el trabajo del proyecto [cerrado]

Así que obtuve este nuevo trabajo, que es mi primer trabajo completamente basado en proyectos.

Mi salario está parcialmente ligado a un acuerdo objetivo. Este acuerdo tiene que hacerse. Mi Gerente me dio su propuesta para este acuerdo, pero no estoy contento porque no es medible.

Como no tengo ninguna educación firme en gestión de proyectos, no conozco ningún método para elaborar un acuerdo medible basado en proyectos.

¿Qué métodos existen para hacer medibles proyectos que no son 100% planificables? (Por ejemplo: como trabajador en un proyecto, no puedo garantizar que todo el proyecto sea un éxito ya que hay demasiados factores en los que no puedo influir)

¿Cuáles son las trampas bien conocidas que debo evitar?

¿ Qué significa ligado a un acuerdo objetivo ? Tu segundo párrafo no me queda claro. ¿Es algo de tu país?
No tiene nada que ver con la ley local, me sorprendería si esto fuera algo especial en mi país. Con "ligado a un acuerdo objetivo" quiero decir, que hay una parte de mi salario que solo recibiré, si se cumple el acuerdo objetivo. Algún tipo de bono.
Señalaré que, en lo que respecta a obtener una bonificación, generalmente es mucho mejor con una medición subjetiva que objetiva. De esa manera, la persona que realiza la medición puede permitir cosas fuera de su control que afectan el éxito del proyecto. A menudo, ese no es el caso con una medida objetiva. Recuerdo una vez que no tuve éxito en ninguna de mis medidas objetivas porque me asignaron algo totalmente diferente, que estaba muy por encima de mi nivel de pago, de misión crítica y tremendamente exitoso. Pero no pude obtener una bonificación por desempeño porque no cumplí con los criterios objetivos.

Respuestas (2)

Probablemente esto sea demasiado amplio, pero intentaré al menos responder a lo siguiente:

¿Qué métodos existen para hacer medibles proyectos que no son 100% planificables? (Por ejemplo: como trabajador en un proyecto, no puedo garantizar su éxito porque hay demasiadas fábricas a las que no puedo afectar)

Básicamente cuando se trata de planificar, siempre asocias un factor de riesgo junto con el tiempo planificado que tomará, depende de los riesgos, afectarás X horas para terminarlo pero en realidad planificarás Y horas, Y > X, cuanto más arriesgado, más crecerá Y. Básicamente necesitas experiencia para ajustar Y correctamente y conocer a tu equipo.

¿Qué trampas conocidas existen que debo evitar?

Responderé que estamos hablando de desarrollo de TI aquí para exponer mi punto, aunque una buena parte de lo que diré seguramente es cierto en cualquier lugar.

  1. Si solo eres un gerente de proyecto sin habilidades técnicas (o no las suficientes), confía en tu equipo cuando te den números (factor riesgo/tiempo). Aunque soy bastante joven, ya vi demasiadas pérdidas de ganancias porque el gerente de proyectos estaba acortando el tiempo que los desarrolladores evalúan para implementar una funcionalidad.

  2. No subestime el factor de riesgo, si usted o su equipo necesitan algunos consejos al respecto, busque en Google "factor de riesgo ágil". Incluso si no usa métodos ágiles, lo que se dice sobre esto sigue siendo cierto.

  3. Tener mediciones de buena calidad es difícil, se trata principalmente de experimentar y conocer a tu equipo. Solo puedo darte uno en el campo de TI como muestra: el número de líneas de código es la peor forma de medir el rendimiento .

  4. Como gerente de proyecto, usted es el punto de entrada del equipo, nadie debe permitir que le quite el tiempo a su gente sin que usted lo sepa, para que pueda replanificar las tareas.

Finalmente :

  1. Google sobre el diagrama de Gant y verifique el método de la ruta crítica . El primero se trata de visualizar tu planificación, el segundo se trata de cómo despachar alguna tarea e identificar entre los diferentes caminos el crítico (el que retrasará todo). Creo que es lo más básico de la gestión de proyectos.

  2. Leer libros sobre 1- gestión de proyectos, 2- calidad, 3- comunicación/liderazgo leer sobre ISO 9001 también es bueno.

También agregaría algo sobre SERVQUAL y el modelo GAP.
@Migz puede sugerir una edición o publicar su respuesta como complemento. No los conozco (he sido formado en los conceptos básicos de gestión de proyectos, pero soy un simple desarrollador: p)
Me acabo de dar cuenta de que hay miles de millones de cosas para agregar a la lista. También pensé en la forma de trabajar "Prince2" (proyectos en entornos controlados). Luego está el método de cascada, métodos ágiles como scrum, etc. Al final, siento que la pregunta en sí es simplemente demasiado amplia :)
sí, es por eso que recomiendo ir a por los libros. Todavía creo que algunos consejos beneficiarían a OP

¿Qué métodos existen para hacer medibles proyectos que no son 100% planificables?

Encuentre alguna fuente básicamente independiente para juzgar el logro del objetivo.

Por ejemplo, el "éxito del proyecto" podría juzgarse por el aumento de ventas logrado debido a la finalización del proyecto, o por una encuesta de satisfacción del cliente, etc.

Muchos objetivos tienen factores fuera de su control directo. Desafortunadamente, así funcionan las cosas.

Trabaje con su gerente para idear un enfoque para evaluar la finalización de su objetivo con el que ambos puedan estar de acuerdo.