En el CIMAT se realiza un coloquio o plática entre estudiantes, profesores y gente relacionada con el CIMAT. En esta ocasión toco el turno a Alejandro García. De manera previa ya habíamos realizas una sesión introductoria de Teoría de Restricciones. De la cual luego les comentaré. La sesión tuvo la siugiente agenda:
1) Primero realizamos el ejercicio para demostrar que se es más productivo cuando se realizan tareas secuenciales a tareas con multitasking.
2) Caso de matnenimiento de aviones de la fuerza aérea israelí. 6 ingenieros, 6 aviones por ingeniero, tiemp promedio 17 meses. 6 ingenieros, 3 avios por ingeniero, tiempo promedio de mantenimiento 5 meses. Qué pasó? Redujeron el mutlitasking
3) Minimizar el multitasking
3.1) Gráfico de cuantos proyectos permiten elevar la productividad de un Ingeniero de Sw.
4) Primera observación respecto al tiempo
4.1) El cuadruple del tiempo promedio para dar una buena estimación
4.2) Todos los IS queremos ser considerado personas confiables y eso implica cumplir compromisos. Cuando a un IS experto no promete más del 80%. Ello implica no exagerar.
4.3) La variabilidad hace que los ingenieros se esfuersen para cumplir las metas.
4.4) Hay otro ejemplo de startups. Cuando una compañía empiza y tiene pocos desarrolladores produce más que cuando se integra más gente a la compañía en el transcurso del tiempo.
La regla equivocada de la administración es "La manera de asegurar que un proyecto termine en tiempo es tratar que cada actividad termine en tiempo".
Las nuevas reglas:
- No convertir los estimados en compromisos
- Mover la protección del nivel de tarea a nivel proyecto
- Usar un buffer de administración para establecer prioridades
Ejemplo:
1) Diagrama de PERT de un proyecto normal con buffers al final de cada terea.
2) La primera ocasión se reduce la estimación al 50% y se deja un buffer de 33%. El proyecto queda en 66% de la estimación original.
3) Cuando las estimaciones son optimistas solo agregas el 33% de buffer.
4) Se administran los buffers. Si el buffer va bien ni me meto a ver como van las tareas. Pero si tengo problemas de que mi buffer se está consumiendo y se me va a pasar debo de tomar acciones.
4.1) De aquí se deriva que si el buffer esta libre, tal vez conforme avance el proyecto se pueden realizar más tareas.
4.2) Empresas que utilizan está técnica, realizan reuniones de avance de una manera más rápida.
4.3) Con el método de buffer puedes aceptar adiciones si está contemplado dentro del tiempo.
Las premisas son que:
- Buscamos tieempos optimistas.
- El buffer sirve para problemas inesperados.
- Si alguna tarea se retraza no hay problema, siempre y cuando sea razonable el tiempo del buffer.
Ejemplo de los pueblos japoneses a la orilla de las montañas. Lo invitaron porque con TOC resolvieron el problema. Una casa es un proyecto, necesitas un buffer. Un constructora de una fraccionamiento. Hay otras técnicas que se utilizan para contabilidad y otro tipo de cosas...
Conclusiones del equipo:
- Vale la pena dar el beneficio de la duda a la Teoría de Restricciones.
- Es contra intutivo la aplicación de Teoría de Restricciones en empresas de desarrollor de software.
- Vale la pena buscar y obtener más ejemplos al respecto.
