¿Cómo podemos planificar proyectos de manera realista y al mismo tiempo tener en cuenta los problemas de soporte?

13

Estamos teniendo un problema en el trabajo: estamos tratando de programar el trabajo para poder evaluar escalas de tiempo y obtener fechas límite.

El problema es que es difícil planificar un proyecto sin saber todo lo que sucederá.

Por ejemplo, ahora mismo hemos planeado todos nuestros proyectos hasta principios de diciembre, sin embargo, en ese momento tendremos varias reuniones internas y externas, teleconferencias y trabajo adicional. Es bueno decir que un proyecto tomará tres semanas, pero si hay una semana de interrupción en ese tiempo, la fecha de finalización se retrasará una semana.

El problema es triple:

  1. Cuando programamos proyectos, las escalas de tiempo se toman literalmente. Si estimamos tres semanas, el plazo se establece en tres semanas, se informa al cliente y no hay espacio para la extensión.

  2. Trabajo interino y eso significa que perdemos tiempo productivo trabajando en el proyecto.

  3. A veces los clientes no tienen el tiempo que necesitamos para hacer el trabajo, por lo que a veces acuden a nosotros y nos dicen que necesitan un proyecto para fin de mes, incluso cuando pensamos que el trabajo tomará dos meses, sin mencionar que ya tenemos trabajo por hacer.

Tenemos un diagrama de Gantt que intentamos completar con todos los proyectos que tenemos y completamos las hojas de tiempo, pero no se comparan en absoluto con el gráfico de Gantt. Esto hace que sea difícil decir "Bueno, hemos programado 3 semanas para este proyecto, pero hemos perdido una semana aquí, por lo que la fecha límite tiene que retrasarse una semana".

Tampoco es profesional dejar de cumplir los plazos que hemos comunicado al cliente.

¿Cómo lidian otras personas con este tipo de situación? ¿Cómo gestionas la planificación de proyectos? ¿Cuánto tiempo "extra" programa en un proyecto para dar cuenta del trabajo no relacionado con un proyecto que se produce durante un proyecto? ¿Cómo lidiar con los problemas de soporte y los errores y esas cosas? ¿Cosas que no puedes explicar durante la planificación?

ACTUALIZAR

Muchas buenas respuestas, gracias.

    
pregunta Thomas Clayson 21.10.2011 - 13:23

8 respuestas

14
  

El problema es que es difícil planificar un proyecto sin saber todo lo que va a suceder.

Ese es el punto de la gestión de riesgos. No puede saberlo todo, por lo que planifica en función de lo que sabe e identifica qué cosas podrían tener el mayor impacto en su plan y la probabilidad de que ocurran. Evalúe el impacto potencial del cronograma y diga que si X ocurre, el cronograma se deslizará por un Y estimado (palabra clave - estimado) días o semanas.

  

Es bueno decir que un proyecto tomará 3 semanas,

Nunca dé una estimación tan específica. Da un rango o cuantifica la probabilidad de alcanzar esa estimación. Por ejemplo, diga "este proyecto tomará de 2 a 5 semanas" o "hay un 85% de probabilidad de que este proyecto se realice en 3 semanas y un 95% de probabilidad de que se haga en 4 semanas".

  

Tampoco es profesional para el cliente seguir diciendo que hemos incumplido una fecha límite.

Verdadero. Sin embargo, está mezclando los conceptos de "estimación", "programación" y "fecha límite". Su estimación es una aproximación de cuánto tiempo tomará terminar una tarea o proyecto dado y la probabilidad de cumplir con eso. La fecha límite es una fecha impuesta por el cliente en la cual el proyecto debe realizarse para agregar valor. El calendario es cómo utiliza sus recursos disponibles para cumplir con su fecha límite.

Hay ocasiones en las que simplemente no es posible terminar el trabajo asignado dentro de un plazo y toda la estimación y la programación en el mundo no harán una diferencia.

  

Entonces, mi pregunta ... ¿cómo hacen esto otras personas? ¿Cómo gestionas la planificación de proyectos? ¿Cuánto tiempo "extra" programa en un proyecto para dar cuenta de cualquier cosa que suceda mientras tanto?

Recomiendo leer dos libros, ambos de Steve McConnell: Estimación de software: desmitificando el arte negro y Rapid Development: Taming Wild Software Schedules . La Estimación de Software se trata de elaborar sus estimaciones, presentarlas a los clientes y algunos aspectos de la negociación y tratar con expectativas poco realistas. Rapid Development es la gestión general de proyectos, que se ocupa de los ciclos de vida del desarrollo, la programación, la asignación de recursos y la mejor manera de programar y presupuestar proyectos para cumplir con sus estimaciones y plazos.

    
respondido por el Thomas Owens 21.10.2011 - 13:37
4

Sugeriría profundizar en los detalles del Scrum development process . Cubre tales actividades de desvío por la métrica focus factor . Básicamente tienes que trabajar 2-3 sprints / iteraciones y luego medir el factor de enfoque de tu equipo (y para cada miembro también sería útil). Después de esto, podrá proporcionar estimaciones más precisas que cubran la actividad diaria.

Eche un vistazo a este artículo: "El factor de enfoque"

  

Si alguno de ustedes está familiarizado con el desarrollo Agile, probablemente haya   oído hablar del factor de enfoque (o factor de productividad). Es usado para   planeando ayudar a determinar en cuántas “horas reales” tiene que trabajar   alguna cosa. Es la diferencia entre “horas reales” e “ideal”.   horas ".

    
respondido por el sll 21.10.2011 - 13:29
1

Lo que pasa con las interrupciones es que, para determinados individuos o equipos, tienden a ocurrir dentro de un rango relativamente pequeño de probabilidades. Por ejemplo, tiene aproximadamente la misma cantidad de reuniones cada semana, o aproximadamente la misma cantidad de horas dedicadas a correcciones de errores urgentes cada mes, o la misma cantidad de tiempo dedicado a responder preguntas para las personas que pasan por su escritorio, especialmente cuando el promedio es mayor un largo periodo de tiempo.

Muchas técnicas modernas de programación lo tienen en cuenta. Scrum lo factoriza en velocidad. La programación basada en evidencia también utiliza una velocidad con un intervalo de confianza para cualquier estimación dada. Pomodoro tiene en cuenta las interrupciones cuando usted decide cuántos "pomodoros" puede completar en cualquier semana. Todo esto depende del seguimiento de las mediciones históricas de sus interrupciones y su factorización en sus estimaciones de alguna manera. Te recomiendo que les eches un vistazo a todos ellos e idees una técnica que funcione para tu equipo.

    
respondido por el Karl Bielefeldt 21.10.2011 - 15:14
1

Un buen consejo para todos.

Otra cosa que podría ser útil para lidiar con los problemas de soporte técnico es dedicar a la gente al soporte en forma fija "round-robin".

Por ejemplo, si tiene 5 desarrolladores, asigne uno a cada día de la semana. Cuando llega ese día, el desarrollador asignado trabaja para ese día SOLO en soporte. Al día siguiente otro desarrollador se hace cargo del soporte. De esta manera, todos tienen la oportunidad de permanecer en su "flujo", todos pueden probar el alimento para perros.

La forma en que ACTUALMENTE elige dividir el trabajo de soporte regular no importa en realidad (el turno redondo de los días de la semana es solo un ejemplo). Lo que importa es limitar el tiempo de soporte a intervalos regulares fijos. Esto hace que el tiempo de desarrollo sea más predecible con el compromiso de que no se puede hacer que "todos abandonen todo" para lidiar con los problemas de soporte.

    
respondido por el Angelo 21.10.2011 - 20:13
0

Esta es una habilidad que realmente viene con experiencia, y a menudo se les pregunta a las personas antes de que puedan juzgar con precisión tal cosa. Siempre he trabajado en un grupo bastante unido con un estilo informal, pero desarrollamos algunas reglas básicas que parecían funcionar bien.

Primero, ninguna tarea toma menos de una semana. Calcule siempre en semanas, incluso si parece que una tarea solo demoraría algunos días. Habrá alguna razón por la que no se hará antes del final de la semana.

Segundo, haga su mejor esfuerzo para estimar la cantidad de tiempo que tomará la tarea, incluidas las interrupciones, los problemas de atención al cliente, cómo realizar las pruebas, etc. Ahora, doble ese número. Esa es su estimación (en semanas).

Tercero, asegúrese de que su administrador no esté agregando un poco de relleno a sus estimaciones. Nuestro equipo tenía un gerente quejarse de nuestras estimaciones. Resultó que ya lo iba a multiplicar por 2.1 (su estimación de relleno empíricamente derivado) y ya lo habíamos duplicado antes de decirle.

No es una herramienta elegante, y puede que no sea un método perfecto, pero funciona sorprendentemente bien.

    
respondido por el MattG 21.10.2011 - 19:01
0

Las personas que realizan la estimación deben comprender que ningún equipo es alguna vez 100% en un proyecto. Tiene licencia por enfermedad, vacaciones, servicio de jurado, licencia por duelo, reuniones de Recursos Humanos requeridas (¡es tiempo de beneficios!), Reuniones de equipo que no están relacionadas con el proyecto, demoras inevitables, descansos en el baño, trabajo de soporte en artículos ya en producción, manejo de correos electrónicos , configurando la nueva computadora después de que la anterior se extinguiera, respondiendo preguntas sobre trabajos futuros y haciendo estimaciones para ese trabajo, asesorando a juniors, etc. que deben tenerse en cuenta. Es irresponsable que un estimador asuma más de 6 de cada 8 horas Disponible por día. Esa es una garantía que el plazo no puede cumplirse. Si está garantizando que no se puede cumplir el plazo, está garantizando a un cliente insatisfecho.

    
respondido por el HLGEM 21.10.2011 - 19:31
0

Tienes toda la razón, es difícil planificar un proyecto sin saber todo lo que va a suceder. Pero es muy importante mantener un registro de las cosas que son una norma, así como las tareas que prevén. Aquí es donde gestión de programación desempeña un papel. He estado utilizando la gestión de proyectos de Microsoft (versión estándar), que también incluye características que forman parte de un software de programación de gestión de proyectos.

Puede visitar enlace para obtener más información.

    
respondido por el Garry Burks 01.11.2011 - 11:46
-1

Parece que hay mucho esfuerzo oculto extraído de los equipos de tu proyecto a través del cual estás perdiendo el enfoque y la velocidad. Puede ser benéfico separar la tarea para tratar con

  

¿Problemas de soporte técnico, errores y demás?

a un grupo específico de personas para que los otros miembros del equipo puedan centrarse en las nuevas tareas de desarrollo. A través de esto, su producción general podría disminuir un poco, pero la calidad mejorará porque hay menos distracción. A cambio, esto reducirá la cantidad de errores, por lo tanto, un trabajo especial que hace que entre en sus proyectos.

En cuanto a la parte de planificación, estoy completamente de acuerdo con la respuesta de Thomas Owens.

    
respondido por el Carlo Kuip 21.10.2011 - 16:59

Lea otras preguntas en las etiquetas