Soy un modelador estadístico en un gran banco en un área altamente regulada. Trabajo en un equipo de unas doce personas repartidas entre tres responsables. Bien, todos nuestros modelos estadísticos se desarrollan utilizando una metodología de estilo cascada simple en la que los modelos van desde "Recopilación de datos" a "Metodología" y luego a "Especificación y prueba", entre otros hitos.
La administración actual sigue estableciendo fechas objetivo que son demasiado agresivas para el desarrollo de modelos en este marco, como resultado, la mayoría de los modeladores trabajan largas horas, fines de semana, etc. Me estoy tomando un descanso de escribir la documentación los domingos. mañana para escribir esto. La configuración actual para el desarrollo comenzó hace siete meses y desde entonces nuestra tasa de rotación se ha disparado. En un equipo de 12 personas, hemos tenido cinco personas que renunciaron o se trasladaron fuera del departamento en siete meses. Como resultado, soy el único no gerente del grupo que estuvo en el banco antes de la reorganización. También estoy contemplando dejar el departamento.
Sospecho firmemente que el problema es que el actual jefe del equipo y sus gerentes no tienen idea de cómo establecer fechas de entrega para este tipo de trabajo. Todos los gerentes tienen experiencia en análisis y parecen no tener experiencia con el desarrollo de modelos. Escribí un memorando hace varios meses alentando al equipo a explorar un estilo de desarrollo ágil, pero esto fue ignorado en gran medida, no estamos ubicados en el mismo lugar, lo que dificulta la adopción de métodos ágiles puros en cualquier caso.
¿Cómo les digo a los gerentes que se reúnan en el frente de la gestión de proyectos y establezcan hitos sensatos para nuestro seguimiento en cascada (¿usando algo como una cadena crítica?) o pasen a Agile?
PD: para este tipo de trabajo de desarrollo, es extremadamente difícil pronosticar cuánto tiempo llevará el desarrollo hasta que haya realizado al menos un par de semanas de trabajo preliminar (obtención de datos/limpieza de datos/etc...).
Sospecho firmemente que el problema es que el actual jefe del equipo y sus gerentes no tienen idea de cómo establecer fechas de entrega para este tipo de trabajo.
Eso no es una sospecha, es una hipótesis con sustento preliminar. Francamente, sospecho que es como una hipótesis de que el agua moja; es una obviedad.
Cada vez que el cronograma es establecido por personas que no son las que hacen el trabajo, ese cronograma es una obra de ficción especulativa. Se basa en esperanzas y sueños; es una encarnación de todo lo que sabemos sobre el sesgo
En tus zapatos, me iría. Pero si tiene un mayor apetito por el riesgo que yo, creo que tiene el comienzo de su respuesta en su pregunta.
Tiene la oportunidad de presentarle a su gerencia una oportunidad significativa de ahorro de costos.
Tienes un equipo de 12 personas que ha tenido un 50% de rotación en menos de un año (o más, no estoy seguro de estar leyendo bien las estadísticas). Deberá refinar mi estimación, pero trabajemos con una tasa de rotación del 50% proyectada hacia adelante. el costo de contratar y despedir varía según la industria y la ubicación, pero es fácilmente de decenas de miles de dólares (al menos en mi industria). Supongamos que la rotación promedio es del 10% y su equipo está un 50% por encima de eso, por lo que el costo de no hacer nada es de aproximadamente 75K/año. Ese es un impacto lo suficientemente grande como para llamar la atención de la mayoría de los gerentes: "¿Qué pasa si le doy 75 000 al año para que los gaste como quiera? ¿Y qué pasa si eso da como resultado aumentos significativos en la calidad a largo plazo de los modelos de datos?"
En mi humilde opinión, la solución es trivialmente simple. Los gerentes nunca deben establecer fechas de entrega. Los gerentes de proyecto deben consultar con expertos en la materia; SME establece el cronograma y los gerentes de proyecto informan sobre el cronograma. Los horarios que marca el SME van a ser fiables. SME trabajará el cronograma porque saben que es justo para ellos. La rotación disminuirá, los modelos de datos resultantes serán de mayor calidad y más confiables (nada desarrollado en las noches y los fines de semana es realmente confiable; ese tipo de marcha de la muerte es una garantía de errores).
Existe una variedad de técnicas para mejorar aún más la programación, pero ninguna de ellas funcionará cuando la responsabilidad por el cronograma esté divorciada de la responsabilidad por establecer el cronograma. Eso es obvio. Creo que probablemente pueda ahorrarle aún más dinero al banco si adopta algo como la Programación basada en evidencia .
Personalmente creo que deberías obtener un % de los 75K que ahorras. Siéntete libre de devolverme un porcentaje de eso.
Un par de puntos adicionales para una discusión con la gerencia:
señalar la tasa de rotación del 40 % con la configuración actual
tenga en cuenta el tiempo dedicado a reemplazar al personal (campaña de contratación + capacitación)
observar las horas extras que la gente está trabajando; su correlación conocida o plausible con la tasa de rotación y, por lo tanto, el riesgo de una mayor rotación; apuntar a estudios sobre insostenibilidad, agotamiento, pérdida de productividad
pregunte qué está impulsando los horarios agresivos : puede haber algo importante que no se está filtrando a su nivel, y si no lo tiene en cuenta, tendrá pocas posibilidades de influir en ellos.
Algo más que podría hacer antes de esta conversación es hacer mis propias estimaciones para una o dos rondas de entregables. Estimaría en horas de trabajo, luego las compararía con las horas de trabajo reales dedicadas, incluidas las noches y los fines de semana, para cumplir con la fecha límite. Si mis estimaciones fueran más precisas (como supongo que usted espera que sean las suyas), entonces sugeriría comparar los métodos de estimación y dejarlos ir primero; luego muestre los míos y conviértalos en plazos más realistas.
¡Buena suerte!
Por experiencia personal,
En mi experiencia, esta no es una discusión fácil del tipo 'oye, estás equivocado, hagámoslo de esta manera'. Podría llevar más tiempo. Compartir directamente los beneficios y los ahorros de costos al seguir un proceso puede no ser de ayuda porque probablemente usted no sea el jefe que pueda despedirlos, por lo que probablemente no les importará un comino su sugerencia de cambios en los beneficios. Tienen que estar interesados y partícipes del cambio.
Cree un foro, debe presentar un caso para una oficina de gestión de proyectos PMO semanal / quincenal / al menos una llamada mensual.
Crea un intercambio y discusión incluso antes de platear la inquietud que tienes. Intente confirmar los diferentes problemas que tienen los PM y si tienen ideas sobre mejoras.
Plantee la preocupación, los beneficios/riesgos del cambio y pregúnteles sus pensamientos. El siguiente paso es lograr que estén de acuerdo o convencerlos de que se requieren algunos cambios.
Cierre: documente los cambios; uno de ellos podría ser una metodología de PM a seguir. Documentar el beneficio/riesgo de los cambios, Documentar el RACI para el cambio en el proceso.
Nada motiva más el cambio que los problemas en curso, siempre que quienes patrocinen el cambio atribuyan esos problemas a las causas correctas. La causa instintiva y fácil de identificar es culpar a las personas, por lo que es clave lograr que sus jefes vean a los otros conductores.
Le pregunté cuáles han sido sus otras intervenciones, incluidos los riesgos que ha escalado y documentado que terminaron convirtiéndose en realidad. Los objetivos agresivos ponen en peligro la calidad, el costo y la moral / rotación, pero también curan las estimaciones pesimistas del equipo y la Ley de Parkinson / Síndrome del estudiante, los cuales agregan costos pero no valor.
No veo ningún problema con que la gerencia dicte objetivos siempre que se base en estimaciones proporcionadas por el equipo. Si el objetivo es agresivo, la gerencia puede estar señalando algo en torno a las estimaciones pesimistas que normalmente reciben, está imponiendo un desafío al equipo pero no tiene expectativas reales de cumplir esos objetivos, puede estar resolviendo otros problemas que afectan el negocio de los cuales usted no está al tanto. . Pero su equipo necesitaría escalar las amenazas de manera simple y formal a medida que las ve y luego mitigarlas lo mejor que pueda.
Pero introducir un cambio que solucione las amenazas/problemas que enfrenta solo ocurrirá si sus jefes perciben los problemas. La pregunta sigue siendo, ¿cuáles son sus quejas? ¿Quién está siendo golpeado por fallas o impactos financieros? Quién está pagando el precio de la rotación de personal. Su argumento a favor del cambio deberá centrarse en las respuestas a estas preguntas.
david espina
david espina