2009-08-28 7 views
5

Mi equipo (4 personas) acaba de alcanzar un hito importante en nuestro desarrollo, situándonos en alrededor de 2/3 partes terminadas, pero creo que el estrés se ha puesto al alcance de todos y todos los engranajes se han detenido, progess es hecho a 1/5 de la velocidad original. Quería preguntarle a la comunidad SO cómo lidiar mejor con esto, identifiqué los siguientes problemas.¿Cómo asegurar que ese impulso se mantenga después de un hito de desarrollo importante?

  • Falta de enfoque claro y dirección. Parece que estamos alcanzando pequeñas mejoras laterales, pero no estamos trabajando para nada central en el proyecto, así que creo que eso está causando una falta de entusiasmo.

  • Descendiendo de un impulso de desarrollo muy fuerte. Esto parece haber hecho que todos deseen realmente "relajarse", lo que está bien por un tiempo, pero aún es necesario progresar.

  • Las tareas restantes son más tediosas que glamorosas. Esta es la naturaleza de la bestia, pero todavía tengo que domarla de manera efectiva.

Cualquier ayuda es apreciada.

+4

Estoy votando para cerrar esta pregunta como fuera de tema porque no se trata de programación, se trata de metodología. – EJoshuaS

Respuesta

9

Es necesario cierto tiempo de inactividad después de alcanzar los hitos principales. La gente necesita relajarse y descomprimirse. Presionando simplemente lleva el estrés y la fatiga hacia adelante y el equipo no estará trabajando en ninguna parte cerca de su potencial.

Deles a todos un par de días a la semana de descanso y déjelos volver completamente actualizados y listos para continuar.

+0

Bueno, no tengo la autoridad para hacer eso, soy un gerente de proyecto, no un supervisor, sin embargo, puedo dejar que se lo tomen con calma. – Firoso

+0

directamente - si la gente ha estado quemando el aceite de medianoche respira – obelix

+1

Déjales saborear su logro. Recompense su progreso. Almuerzo libre, cervezas después del trabajo. Unos días sin estresarse no son malos. Ayudará a la moral, especialmente si rompieron el culo para obtener esta parte. – xcramps

1

Haz algo, aparte de trabajar, como un equipo. Vaya a almorzar, a la hora feliz, a la etiqueta láser, a cualquier cosa que pueda hacer como grupo que no funciona. Un breve descanso del estrés puede ser un gran alivio, y con suerte puede reactivar a su equipo para el empuje final.

+0

lamentablemente, la mayor parte de eso no va a volar con la compañía, especialmente no en su tiempo o boleto. – Firoso

+2

Es mucho más barato que rechazar el proyecto porque no cumplió con la fecha límite debido a los errores causados ​​por el estrés ... –

+3

Todo lo que haces con la gente del trabajo sigue siendo trabajo, en mi humilde opinión. – MusiGenesis

6

Dígales que solo necesita 3 personas para finalizar el proyecto.

+2

HA HA HA HA HA HA HA HA! 2 puntos. – Firoso

1

También creo firmemente en "slackweek". Si la fecha límite para todo el proyecto no es demasiado cercana: simplemente deje que cada uno haga lo que quiera durante un período de tiempo. Podría escribir algunas pruebas aquí, alinear algunas cosas en la interfaz gráfica de usuario, leer lo último en bla, lo que sea. Depende de ti si tiene que ser trabajar en ese proyecto específico o simplemente algo útil en general.

ENTONCES, usted tiene una gran reunión de "lanzamiento" en la que habla de la visión y los objetivos para el tercero restante - cosas de gran formato, y consigue que todos estén alineados de nuevo. Supongo que lo que queda es realmente necesario para darle al cliente un producto completo para que pueda motivarse.

¡Buena suerte!

+0

bueno no, es un poco más que eso, tenemos un modelo funcional, ahora solo tenemos que adaptarlo a nuestras necesidades y llenar las grietas por así decirlo. Así que algo bien. – Firoso

0

¡Agregue un huevo de Pascua! No mejora el proyecto central, pero ayuda a los desarrolladores a tener un sentido de propiedad.

Además, puede ser útil reservar tiempo para la limpieza de "mascotas molestas". Esto les da a los desarrolladores la oportunidad de solucionar problemas persistentes que son importantes para ellos. Esto ayuda a mejorar el proyecto y, al mismo tiempo, permite que el desarrollador progrese con algo que es importante para él. Ayuda a mantener el nivel de emoción arriba.

0

¿Hay plazos/hitos claros que surgirán pronto? Eso sería algo a considerar ya que tener una fecha objetivo puede ayudar a enfocarnos.

El impulso se pierde, se relaciona con personas que acaban de ser quemadas, no tan motivadas como antes o el trabajo se vuelve muy diferente, por ejemplo.elaborando detalles sobre requisitos vagos en lugar de las partes interesantes que se hacen ahora?

+0

Es un poco de ambos, pero diría que es más un cambio de marchas que agotamiento. – Firoso

0

Una de las cosas que Agile le ofrece es un mejor enfoque sobre su posición, lo que ha hecho y lo que queda por hacer, en las próximas semanas. Hay conceptos de "retraso" (lo que tiene que hacerse) y "velocidad" (qué tan rápido se hacen las cosas). Debido a que cada iteración es típicamente de aproximadamente un mes, es muy claro ver cuándo el equipo no está trabajando a la tasa proyectada/requerida o trabajando demasiado. Es posible que pueda tomar prestados algunos conceptos de Scrum para estos fines.

Una solución más directa es recordarles que si continúan trabajando a un ritmo razonable, no hay un momento crucial que haga que la vida de todos se convierta en un infierno.

+0

-1 (solo virtual, porque me gusta estar en múltiplos de 5) para el campo de venta de Agile/Scrum obligatorio. Cualquier cosa que Agile y Scrum puedan traer a la mesa, la motivación no es una de ellas. – MusiGenesis

+0

Mentí. -1 de verdad – MusiGenesis

+0

OK, -1 porque no te gusta Agile/Scrum, o porque no te gusta leer comentarios en la medida en que realmente los entiendes? Lo que estaba diciendo es que una cosa que sale de Agile son las métricas objetivas que puede señalar, en lugar de simplemente decir "No está trabajando lo suficientemente rápido". La parte de motivación fue un párrafo separado por una razón.Y si miras aún más cerca, no sugerí que el OP use Agile/Scrum, sugerí que tomaran prestados estos conceptos de él. Creo que su golpe fue injusto. –

2

Creo que la clave es cuando dices que las tareas restantes son más tediosas que glamorosas. Sí, la vida es así, pero muchos desarrolladores no quieren trabajar en tedioso. Sin embargo, como líder, es su responsabilidad determinar qué tareas deben hacerse y asignárselas a las personas a hacer. Lo mismo que con las tareas más interesantes, tal vez incluso más importante (alguien casi siempre se pone de pie para hacer las cosas interesantes, no tanto con el tedio).

Así que asigne sus tareas, deles sus fechas de entrega y haga un seguimiento del progreso que están realizando. Si le quedan algunas de las tareas más interesantes, no permita que nadie tenga una de esas que hacer hasta que haya completado su parte del tedio. De hecho, cuelga las tareas interesantes que quedan como recompensa por hacer el tedio más rápido o aprovechar al máximo.

Si no te quedan más tareas interesantes, quizás puedas generar competencia para completar el resto del trabajo.

Está bien dilatará durante unos pocos días después de un impulso importante, pero si dura más de una semana, creo que necesita para obtener el equipo juntos y hablar sobre lo que hay que hacer para solucionar el tocado la barriga.

Cuestiones relacionadas