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

Tenemos 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, en este momento hemos planeado todos nuestros proyectos hasta principios de diciembre, sin embargo, en ese momento tendremos varias reuniones internas y externas, teleconferencias y trabajo extra. Está muy bien 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 para tres semanas, se le informa al cliente, y no hay espacio para la extensión.

2. El trabajo intermedio y tal 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 nos visitan y nos dicen que necesitan un proyecto terminado para fin de mes, incluso cuando pensamos que el trabajo tomará dos meses. - Sin mencionar que ya tenemos trabajo que hacer.

Tenemos un diagrama de Gantt que estamos tratando de completar con todos los proyectos que tenemos y completamos hojas de tiempo, pero no se comparan con el diagrama de Gantt. Esto hace que sea difícil decir "Bueno, programamos 3 semanas para este proyecto, pero hemos perdido una semana aquí, por lo que la fecha límite debe retroceder una semana".

Tampoco es profesional seguir cumpliendo los plazos que hemos comunicado al cliente.

¿Cómo manejan otras personas este tipo de situación? ¿Cómo gestiona la planificación de proyectos? ¿Cuánto tiempo "extra" programa en un proyecto para tener en cuenta el trabajo que no es de proyecto que se produce durante un proyecto? ¿Cómo manejas los problemas de soporte, los errores y esas cosas? ¿Cosas que no puede tener en cuenta durante la planificación?

ACTUALIZAR

Muchas buenas respuestas gracias.

Sin embargo, el problema es que es difícil planificar un proyecto sin saber todo lo que 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 sucedan. Evalúe también el impacto potencial del cronograma diciendo que si ocurre X, hará que el cronograma se deslice por un estimado de Y días (o palabras clave).

Está muy bien decir que un proyecto tomará 3 semanas,

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

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

Cierto. Sin embargo, está mezclando los conceptos de "estimación", "calendario" 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 cumplirlo. La fecha límite es una fecha impuesta por el cliente en la que el proyecto debe realizarse para agregar valor. El cronograma es cómo usa sus recursos disponibles para cumplir con su fecha límite.

Hay momentos en que simplemente no es posible finalizar el trabajo asignado dentro de un plazo límite y toda la estimación y programación en el mundo no va a hacer la diferencia.

Entonces mi pregunta ... ¿cómo hacen esto otras personas? ¿Cómo gestiona la planificación de proyectos? ¿Cuánto tiempo "extra" programa en un proyecto para dar cuenta de todo lo que sucede mientras tanto?

Recomiendo leer dos libros, ambos de Steve McConnell: Estimación de software: desmitificar el arte negro y desarrollo rápido: domar los horarios de software salvaje . 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 de 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.

Sugeriría profundizar en los detalles del proceso de desarrollo de Scrum . Cubre tales actividades de desvío por focus factormétrica. Básicamente, debe trabajar 2-3 sprints / iteraciones y luego medir el factor de enfoque de su 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 ágil, probablemente hayan oído hablar del factor de enfoque (o factor de productividad). Se utiliza para planificar para ayudar a determinar cuántas "horas reales" tiene que trabajar en algo. Es la diferencia entre "horas reales" y "horas ideales".

Lo que pasa con las interrupciones es que, para individuos o equipos dados, 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 la reparación urgente de errores cada mes, o la misma cantidad de tiempo dedicado a responder preguntas para las personas que pasan por su escritorio, especialmente cuando se promedia un largo periodo de tiempo

Muchas técnicas modernas de programación tienen eso en cuenta. Scrum lo factoriza en velocidad. La programación basada en la evidencia también utiliza una velocidad con un intervalo de confianza para cualquier estimación dada. Pomodoro tiene en cuenta las interrupciones cuando decides cuántos "pomodoros" puedes completar en una semana determinada. Todo esto depende del seguimiento de las mediciones históricas de sus interrupciones y su factorización en sus estimaciones de alguna manera. Le recomiendo que los mire a todos y diseñe una técnica que funcione para su equipo.

Un buen consejo por todas partes.

Otra cosa que podría ser útil para tratar los problemas de soporte es dedicar a la gente al soporte en una base 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 mantenerse en su "flujo", todos prueban el alimento para perros.

La forma en que REALMENTE elige dividir el trabajo de soporte regular realmente no importa (el round robin 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 la compensación de que no se puede hacer que "todos dejen todo" para lidiar con los problemas de soporte.

Esta es una habilidad que realmente viene con la 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 generales que parecían mantenerse bien.

Primero, ninguna tarea lleva menos de una semana. Siempre calcule en semanas, incluso si una tarea solo parece que tomaría unos días en completarse. Habrá alguna razón por la que no se hará antes del final de la semana.

En segundo lugar, haga su mejor esfuerzo para estimar la cantidad de tiempo que llevará la tarea, incluidas las interrupciones, los problemas de atención al cliente, realizar las pruebas, etc. Ahora, duplique ese número. Esa es su estimación (en semanas).

Tercero, asegúrese de que su gerente no esté agregando algo de relleno a sus estimaciones. Nuestro equipo hizo que un gerente se quejara de nuestras estimaciones. Resultó que ya iba a multiplicarlo por 2.1 (su cálculo de relleno derivado empíricamente) 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.

La gente que hace la necesidad de estimación a entender que ningún equipo es siempre 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, retraso inevitable, descansos en el baño, trabajo de apoyo en artículos que ya están en producción, manejo de correos electrónicos, , configurando la nueva computadora después de que la anterior murió, respondiendo preguntas sobre el trabajo futuro 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 las 8 horas Disponible por día. Esa es una garantía de que no se puede cumplir el plazo. Si está garantizando que no se puede cumplir el plazo, está garantizando a un cliente insatisfecho.

Tiene toda la razón: es difícil planificar un proyecto sin saber todo lo que sucederá. Pero es muy importante hacer un seguimiento de las cosas que son una norma, así como las tareas que prevé. Aquí es donde la gestión de horarios juega un papel importante. He estado usando la administración de proyectos de Microsoft (versión estándar) para la cual también incluye características que son parte de un software de programación de administración de proyectos.

Puede visitar http://www.microsoft.com/project/en/us/schedule-management.aspx para obtener más información.

Parece que hay un gran esfuerzo oculto extraído de sus equipos de proyecto a través del cual está perdiendo enfoque y velocidad. Puede ser beneficioso separar la tarea para tratar

... problemas de soporte y errores y esas cosas?

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

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