En varios proyectos para la implementación de sistemas empresariales, me encontré con la tarea de planificar y controlar tareas que son difíciles de predecir. Imagine que necesita realizar muchas tareas similares, y una gran cantidad de personas están involucradas en ellas, mientras que no sabe exactamente en qué secuencia se llevarán a cabo y cuánto tiempo tomarán.
Los diagramas de Gantt que son familiares en la gestión de proyectos funcionan mal en este caso. Un ejemplo típico es el desarrollo de extensiones para CIS.
A continuación, le diré qué método utilizamos en los proyectos para controlar una gran cantidad de tareas paralelas con costos de administración mínimos.
1. Planificación del trabajo
Hace unos cinco años escribí
un artículo : recomendaciones a los gerentes de proyecto sobre programación. Los principios han sido probados por el tiempo, y todavía me adhiero a ellos.
Sin embargo, para algún tipo de tareas es casi imposible crear un cronograma detallado consistente. En una situación en la que muchas tareas se realizan en paralelo, y la duración y complejidad de cada una solo se puede estimar con un gran error.
Un ejemplo clásico es el desarrollo. Cada desarrollo pasa por varias etapas, al menos: diseño, codificación, prueba. Como regla, son necesarias varias iteraciones cuando la tarea pasa a la etapa anterior. El desarrollo pasó de la codificación a las pruebas, el desarrollador asumió otra tarea. El desarrollo se devolvió a la codificación, el desarrollador finaliza la tarea anterior o retoma inmediatamente la corrección de errores. Dependiendo de la situación y las prioridades, puede haber un orden diferente de trabajo en equipo en el grupo de tareas. El proceso se ve caótico e incontrolable. Presentar esto en forma de un ordenado diagrama de Gantt, al que los gerentes de proyecto están acostumbrados, acostumbrados a controlar todo, es extremadamente laborioso y no muy útil, si es posible.
Como ser ¿Cómo controlar el progreso del trabajo? Cómo entender, a tiempo o no; ¿Dónde están los cuellos de botella? ¿Hay suficientes recursos? ¿Quién trabaja bien y quién no? ¿Cómo, al final, informar a la gerencia?
A continuación se muestra una de las opciones que me parece óptima, y en algunas condiciones la única.
2. Usando un sistema de gestión de trabajo
Vale la pena mencionar de inmediato que sin usar un sistema de administración de tareas que permita a cada uno de los participantes recibir tareas, transferirlas a otros participantes y marcar su finalización, es imposible construir un proceso normal.
En mi práctica, utilicé diferentes herramientas y publiqué un artículo de revisión sobre este tema (vea el artículo sobre Habr:
herramientas del administrador de proyectos ). Aquí describiré con más detalle la experiencia de usar JIRA, que configuramos para la gestión del desarrollo, utilizando la funcionalidad estándar, con un uso mínimo de complementos adicionales.
JIRA es el sistema de gestión de tareas (solicitud) de Atlassian. El costo de una licencia, dependiendo de la cantidad de usuarios, comienza en $ 10 por cada 10 usuarios. Hay opciones para instalarlo usted mismo o usar la aplicación en la nube. Los precios de todas las opciones se pueden encontrar
aquí .
JIRA se distingue por una interfaz ligeramente anticuada (es un sistema de una edad muy respetable que ya ha pasado un largo camino de desarrollo), confiabilidad, un sistema flexible para configurar todo lo que es posible (flujo de trabajo, tipo de pantallas, acceso, sistema de notificación), una gran cantidad de complementos, tanto pagos como gratuitos, y la posibilidad de un desarrollo profundo.
No necesitábamos revisión, configuramos y mejoramos constantemente el flujo de trabajo (el proceso de trabajo es el conjunto y el orden de los estados para la tarea y las transiciones entre ellos), así como el acceso de los participantes y paneles para controlar el trabajo.
No me planteo la tarea de describir de alguna manera en detalle las características y posibilidades de usar la aplicación, pero para una presentación posterior es importante ilustrar algunos puntos.
3. Flujo de trabajo de gestión de tareas
El flujo de trabajo refleja el ciclo de vida de la tarea, en nuestro ejemplo: diseño, pruebas de codificación. En realidad el proceso es mucho más complicado. Dependiendo de las características de la organización del proyecto, el reclutamiento de participantes, los requisitos de control, el número de etapas puede variar significativamente.
Por ejemplo, uno de los proyectos tenía el siguiente flujo de trabajo para el seguimiento de una tarea de desarrollo.
Muchas etapas de coordinación, distribución del trabajo, pruebas en todas las instancias del sistema ... Pero esto hizo posible confirmar cada paso en el sistema, rastrear la responsabilidad y saber exactamente quién y en qué etapa se encuentra la tarea.
4. La complejidad de la tarea.
La complejidad de la tarea se dividió en dos componentes: diseño y construcción. El diseño es el trabajo de un analista para preparar documentos y probar el desarrollo. El edificio es el trabajo del desarrollador para el desarrollo del diseño técnico, la codificación y las pruebas propias antes de pasarlo al analista.
Evaluar la complejidad de una tarea por adelantado sin sumergirse en los detalles es bastante difícil, especialmente si hay varios miles de tareas, como fue el caso en nuestro caso. Pero es necesario evaluar para comprender la cantidad total de trabajo, la cantidad requerida de recursos y determinar el momento.
Para una evaluación aproximada, se utiliza una calculadora que, según el tipo y la complejidad de la tarea, se le atribuye la complejidad planificada.
La complejidad de la tarea se determina según el objeto y la cantidad de trabajo con él. Por ejemplo, para desarrollar un formulario en Oracle eBS, los criterios de complejidad se describen a continuación:
- Muy simple: forma de bloque único con 8 o menos columnas. No requiere lógica funcional especial.
- Simple: forma simple y de bloques múltiples (2-3 bloques) con 20 o menos columnas. Se requiere lógica funcional simple (edición simple, edición cruzada (ediciones cruzadas), cálculos simples, totales y subtotales).
- etc.
El tipo de tarea refleja el contenido de la tarea, los detalles de la tecnología, la aplicación o parte de ella.
Por ejemplo:
- Formas nuevas o modificables.
- Informes nuevos o revisados.
- Programas de bases de datos nuevos o modificables.
- Scripts de SQL * Loader.
- Señales (alertas).
- Personalización.
- etc.
Según la complejidad y el tipo de desarrollo, la calculadora calcula la complejidad planificada.
Y aunque el error de estimación puede ser significativo, en grandes cantidades, estadísticamente, estos errores se nivelan y se puede utilizar una idea general de la cantidad de mano de obra para fines de planificación de proyectos.
5. Monitoreo del desempeño de la tarea
Entonces, teniendo el estado de la tarea y su complejidad, ¿cómo podemos evaluar el progreso del trabajo?
La opción tradicional es planificar cuántas tareas debe realizar durante un determinado período y realizar un seguimiento de la finalización de las tareas de forma periódica. El problema es que algunas tareas llevan mucho tiempo y se extienden durante varios períodos de planificación. Y en algunos períodos se completan muchas tareas, en otros muy pocos. Esto no proporciona una comprensión de la situación, especialmente al principio y al final del proyecto.
Puede intentar planificar la finalización de etapas individuales de la tarea. En el ejemplo anterior, utilizamos 21 etapas, cada una imposible de planificar. Elegimos los principales: finalización del diseño, finalización de la codificación, finalización de toda la tarea. Planificamos una fecha para cada tarea, controlaremos las desviaciones. Parece factible Sin embargo, mientras se trabaja en una gran cantidad de tareas al mismo tiempo, es bastante difícil ver algo en varios cientos de desviaciones y sacar las conclusiones correctas. Para cada desviación habrá una explicación, una razón objetiva. Algo se hará tarde, algo más rápido.
En uno de los proyectos, intentamos usar el método de control de fecha. La fecha prevista fue establecida por los artistas intérpretes o ejecutantes. El hecho se registró automáticamente en el sistema al pasar del estado correspondiente.
La figura muestra un histograma de desviaciones para la fecha en que el diseño funcional (FD) está listo. Los valores positivos muestran un avance, los valores negativos indican un retraso en el gráfico. Se puede ver que la mayor cantidad de DP es entregada por los ejecutores con un retraso de 3.8 a 1.7 días. En este caso, los valores extremos son de 43 días de retraso a 67 días antes de lo previsto.
En esta situación, vemos que en la gran mayoría de los casos, los artistas violan los plazos establecidos por ellos. Vale la pena reflexionar sobre este error sistemático. Sin embargo, siempre que el equipo esté motivado y todos trabajen de buena fe, esto solo significa que las personas no pueden indicar el tiempo real, los artistas no tienen en cuenta los factores complicados que en la mayoría de los casos surgen durante el trabajo.
Se dedica más tiempo a la planificación, pero de hecho nadie es responsable de cumplir con los plazos. Si introduce sanciones por violación, fijarán fechas con un amplio margen, y la situación de desempeño será aún peor.
Si desea controlar algo, piense en lo que hará con los resultados del control, ¿qué decisiones puede tomar en función de los datos recopilados?
6. Método de volumen ganado
Los intentos de gestionar a un nivel detallado centralmente, para un gran número de tareas con un alto grado de incertidumbre están condenados al fracaso.
Puede dividir estas tareas en grupos, delegar la planificación detallada a grupos. Se pueden organizar varias personas, varias docenas de tareas en una cadena, responder rápidamente a los cambios, tomar decisiones sobre las prioridades cambiantes. Pero a nivel de proyecto, se necesitan otros métodos.
El método de volumen utilizado viene al rescate. Sin entrar en la teoría, describiré cómo se implementa este método para el control planificado del desarrollo.
Ya hemos determinado el ciclo de vida de la tarea y la complejidad planificada de cada una de ellas. Ahora asignamos el porcentaje de finalización de la tarea para cada etapa. En nuestro caso, porque hubo una división de la entrada de trabajo en diseño y codificación, se asigna un porcentaje a cada uno de los valores.
La asignación de intereses la realiza un experto, evaluando cuánto consideramos que se completó la tarea, cuánto trabajo queda en esta etapa.
Después de que se haya compilado dicha tabla, para cada tarea es posible determinar cuántos días-persona del planificado ya dominado y así medir el progreso de cada tarea.
Por ejemplo, una tarea tiene una aportación laboral planificada de 10 horas para el diseño y 20 horas para el desarrollo. Luego, en la etapa de prueba, creemos que está completado en un 80% en términos del trabajo del analista (otro 20% del trabajo requerido para completar la prueba) y un 50% en el trabajo del desarrollador. Estamos listos para admitir que el diseño ha funcionado 8 horas, y en desarrollo, 10 horas. En total, de 30 días-hombre, 18 ya se han completado.
Al mismo tiempo, no tenemos en cuenta que, de hecho, se puede dedicar otro tiempo. Para los fines indicados, no importa.
7. Informes del proyecto.
Con una tabla en la que para cada tarea tenemos una complejidad planificada y un volumen dominado, es fácil entender cómo van las cosas.
Es posible dividir las tareas en direcciones, componentes e hitos del proyecto para poder analizar a un nivel más detallado y hacer tablas de resumen en todas las secciones necesarias.
La imagen general del proyecto se vuelve conveniente para su presentación a nivel de liderazgo:
Tabla de resumen de carga JIRA
control del hecho del plan para todo el proyecto
Este método no siempre encuentra comprensión. Los días míticos del hombre se entienden menos que las piezas de desarrollo. Y no cancela la planificación detallada a nivel de grupo e intérpretes individuales. Sin embargo, este es el método más objetivo para evaluar la situación actual y predecir la finalización del trabajo.