jueves, 21 de febrero de 2013

¿La Multitarea es buena?. Tercera Parte

Les voy a compartir una tercera historia, basada en hechos reales...


Historia 3: "No me lo vuelven a hacer"

Manuel, un Gerente de Negocios de un Banco muy importante, tiene una reunión con su Director, y este fue el diálogo que sostuvieron:

-Manuel,  ¿qué fue del proyecto X que te asigné hace 4 meses? A estas alturas, ya debe estar finalizada, ¿no? 
-Bueno, esteeee, no, no está lista. Recuerde que había otras prioridades, así que se detuvo el proyecto X.
-Cómo que se detuvo, ya han pasado más de 4 meses.
-Es que, como le decía, usted nos asignó otras prioridades por encima del proyecto X y además...
-¿Y por qué no me avisaste que la habías dejado de hacer?
-Esteee, disculpe, no pensé que fuera tan crítica (¡ups!)... 

Manuel salió de la oficina con la consigna de que tenía que encontrar una forma de trabajar que evite repetir el mal rato que pasó con su Jefe. 

Ese día Manuel se fue a descansar muy preocupado, ya dormido, se le aparece en sueños un extraño personaje que le dice con voz susurrante: "Visualizaaar debes"...

Manuel se despertó intempestivamente "¡Claro!, ¡ya se que debo hacer!". Al día siguiente preparó una cartilla con los proyectos en curso y con los proyectos pendientes, así como el personal asignado.

-------------------------------------------------------
|Proy Pendientes |  Proy. en Curso                    |
-------------------------------------------------------
|Proyecto F      | Proyecto X [Juan, José]            |
|Proyecto H      | Proyecto W (María, Ricardo, Arturo)|
|Proyecto R      | Proyecto E (Pedro, Antonio)        |
|Proyecto P      | Proyecto U (Pablo, Andrés)         |
|Proyecto C      | Proyecto G (Cesar)                 |
|Proyecto B      |                                    |
|Proyecto Y      |                                    |
-------------------------------------------------------

El Director vuelve a llamar a Manuel:

-Manuel, necesito que realices el proyecto Z, es muy importante.
-Ok. Antes de ello, quisiera mostrarle los proyectos que tenemos en curso y los pendientes (saca la cartilla). A fin de incorporar el proyecto Z, necesitaré saber cual de los proyectos dejo de hacer, o tal vez debamos colocarlo en la cola de pendientes.
-¿Qué es esta cartilla?  
- En el lado derecho los proyectos que están en curso y en el lado izquierdo los pendientes en orden de prioridad.
- Veamos... Mmm. Veo que todo lo que estás haciendo es importante. 
- Podemos ponerlo como pendiente priorizado, encima del Proyecto "F"
- Pensándolo bien, creo que el proyecto Z puede esperar. Continúa con lo que estás haciendo. Yo te aviso cuando requiera incorporarla.

Manuel había recuperado la confianza, había hecho visible la lista de proyectos y estas estaban priorizadas. Las tareas las tenía en dos estados: "en curso" y "pendientes". 

Se fue a su casa contento. Pero, al quedarse dormido, nuevamente el misterioso personaje volvió a aparecer en sueños y le dijo con voz susurrante... "Limitaaar el trabajo debes, hablar con jefe debes". Manuel se despertó de un salto, y se dijo "Pero, ¿cómo se lo voy a explicar a mi Jefe?" 

Al día siguiente Manuel pide hablar con su Jefe.

-Jefe, quisiera hablar con usted respecto a los proyectos.
-Claro Manuel, dime.
-Quiero proponerle lo siguiente: “Quiero hacer menos para entregarle más”.
-¿Cómo? ¿Cómo haciendo menos me vas a entregar más? ¡No entiendo!
-Mire, si mi equipo hace menos cosas en paralelo, podré asignar más personas a acabar más pronto los proyectos más importantes.
-Sigo sin entenderte. Las cosas se hacen en paralelo. Siempre ha sido así.
-Jefe, permítame contarle  unas breves historias... 

Manuel le cuenta la historia 1 y la historia 2, que están en el post anterior. Su Jefe no está muy convencido con lo que oye.

-No logro entender... qué tienen que ver los buques con el negocio bancario... 
-Jefe, imagínese que cada buque es un proyecto, si pongo más gente a acabar menos buques, éstos saldrán más temprano!,
-Mmmm, y en el caso de José Racer?
-Si José acaba las 5 tareas al final del quinto día, yo debo revisarlas en lote y eso me tomará más tiempo. Es mucho mejor si me da una tarea completa cada día, así voy revisando una por una y podré entregárselo más rápido.
-Entonces, si tienes menos proyectos en paralelo, me entregarás más a menudo.
-Exacto! ("en qué me estoy metiendo...").
-Muy bien, probemos. ¿Qué necesitas que te indique?
-Necesito la prioridad de los proyectos en curso, de esa manera detendré algunos para concentrarme en los más importantes

Manuel detuvo tres proyectos que estaban en curso y se concentró solamente en “dos”, permitiendo entregas más a menudo... ¿Qué opinas al respecto?

¿La Multitarea es buena?. Segunda Parte



Les voy a compartir unas breves historias que buscan revelar entre líneas el efecto de la multitarea:

Historia 1: "Desembarque de mercadería"

Llegan 5 buques al puerto al mismo tiempo. Tenemos 5 personas para descargar la mercadería. Si una persona se dedica a descargar un buque, le tomará 5 días. Si se decide trabajar en los 5 buques al mismo tiempo, cada persona descargará un buque, entonces al final de 5 días tendremos los 5 buques descargados... No está mal.

Sin embargo, se puede proceder de manera diferente. Si se decide trabajar un buque por vez, pondremos a trabajar a las 5 personas en un solo buque y de esa manera éste se liberará el primer día. Como ya acabaron con el primer buque, recién comienzan con el segundo buque, ponemos a trabajar a las 5 personas en el segundo buque y éste se libera el segundo día. Así sucesivamente, se libera el tercero el tercer día, el cuarto buque el cuarto día y finalmente el último buque el quinto día... 

¿Es una mejor manera de administrar?
¿Es ésta una mejor alternativa?

La respuesta es "depende". Depende del "costo" que implica tener un buque parado en el puerto (“cost of delay”). Si el "costo" no es relevante, no importa. Si el costo es alto, la alternativa es buena. Si el costo es demasiado alto, podría ser necesario contratar personal adicional para descargar la mercadería lo antes posible.

Historia 2: "Tareas en paralelo"

José Racer es un senior developer y es experto en desarrollar aplicaciones complejas. Tiene asignado 5 tareas. Para finalizar una tarea debe dedicarle 10 horas. Asumamos que José Racer cuenta con 10 horas al día (hace 2 horas extra cada día). José Racer es justo, por lo tanto, trabajará de manera equitativa las 5 tareas, dedicándole 2 horas a cada tarea al día. De esa manera al final del quinto día habrá acabado las 5 tareas... No esta nada mal.

Sin embargo, puede proceder de manera diferente. Qué tal si José Racer se dedica a hacer una sola tarea al día. De esa manera podrá tener la primera tarea completa al finalizar el primer día, la segunda tarea el segundo día y así sucesivamente... 


Nuevamente, la repuesta es "depende". Puede ser que adelantando la finalización de las tareas no sea relevante para los siguientes pasos. O tal vez si lo sea, puede ser que el usuario se vea favorecido al recibir una entrega diaria. La pregunta clave sería ¿Cuál es el valor que genera entregar a menudo?...

“Cuantas más tareas tenga en paralelo, más tarde las acabaré (mayor lead time)”

martes, 19 de febrero de 2013

Teoría de Restricciones para solucionar un problema en TI

Era fines de Abril del 2004 y estaba de regresó en el área de sistemas. El encargo que recibí era revertir un enorme problema con los usuarios del área Comercial. Las fuentes de insatisfacción eran muchas, por ejemplo, entre las fuentes de insatisfacción externa tenia a los usuario comerciales que se quejaban que los reportes de ventas no cuadraban con las cifras que ventas varios meses, entre las fuentes de insatisfacción interna, teníamos al personal de sistemas que dormía en la oficina a fin de cumplir con lo prometido

El personal de desarrollo trabajaba en ese entonces a través de service, y anhelaban pasar a planilla, esto no se podría sustentar a RRHH dado que no se percibían logros. La presión para completar los desarrollos eran extremos, creando un clima de constante conflicto

Dado que recién me había reincorporado al área, tenía una "breve licencia" para analizar el problema y darle la mejor solución posible. Se me ocurrió aplicar "Teoría de Restricciones" para analizar el problema de manera sistémica.

Teoría de Restricciones: Se basa en tres premisas:

Premisa 1 (Convergencia): Todo dentro de un sistema está conectado por relaciones de causa - efecto. La identificación de las causas y sus conexiones nos llevan a converger en torno a una causa central.

Premisa 2 (Consistencia): Todos los conflictos pueden resolverse sin perdidas. En la realidad no hay conflictos, sólo nuestro nivel de entendimiento y nuestras asunciones sostienen su existencia

Premisa 3 (Respeto): No existe resistencia al cambio. La gente se resiste al cambio porqué no le hemos comunicado adecuadamente cómo gana con la mejora

Si todo está conectado, podré solucionar la causa raíz que afecta a todos los otros efectos indeseables. Al analizar la situación, encontré muchas propuestas de solución, que correspondían con varios problemas (efectos). Debía hallar la relación entre todos esos problemas (efectos).

Hice una lista de los UDE (undesirable effects) y por tres días trabajé en relacionarlas, para ello indagué con el equipo de desarrollo y los gestores de proyecto cuáles eran la relación entre ellas y su correspondiente validación. 

Constaté que el sistema de UDEs se retroalimentaba generando una espiral sin salida a los problemas. El gráfico que realicé es el que se puede visualizar abajo (Árbol de Realidad Actual).

Era necesario romper con la espiral. Como se puede apreciar la causa raíz que disparaba la espiral era el establecimiento apresurado de un compromiso de entrega por parte del IT Manager, éstos compromisos se generaban sin el suficiente análisis, a esto se sumaba la ausencia de metodologías de desarrollo, desencadenando toda una serie de efectos concatenados. 

Plan de Acción

1. Negociación con la Dirección Comercial:
  • No se podrá prometer ninguna fecha de entrega al usuario, a menos que hayan transcurrido 24 horas desde que solicitó el cambio, tiempo suficiente para analizar el el cambio y tener un estimado de tiempo y una clara la estrategia de datos
  • Se contará con el respaldo de la Dirección de Sistemas Corporativo para que apoye el punto anterior. 
  • La promesa de valor al usuario era: mayor confiabilidad y mayor calidad en la información
2. Modelo de Gestión:
  • Se empleará el ciclo de Deming (PDSA) de mejora continua para la definición de roles
  • Se incorporará los elementos más adecuados de “Programación Extrema” 
  • Se tendrá énfasis en el análisis, en los registros y en la estrategia de datos.
  • Se capacitará en el empleo de este modelo de gestión
3. Capacitación de personal:
  • Se realizará una reunión de capacitación diaria de 30 minutos con todo el personal de sistemas a fin de homologar conceptos del negocio
  • Se evaluará la capacitación en nuevas herramientas
La situación se revirtió. Ya no nos comprometíamos con tiempos irreales, aumentó la confiabilidad y la calidad de la información radicalmente. La mejora fue casi inmediata. Se inició el programa de capacitación en reglas del negocio y el "modelo de clases" al que estábamos migrando, la motivación del personal aumentó y se pudieron tomar mejores medidas más adelante.

Aún recuerdo el primer día que adoptamos este Plan de Acción, el líder usuario, que era muy exigente, pedía que le den una fecha en ese instante... y la respuesta era "déjanos revisarlo y en 24 horas te daremos una fecha", a lo que respondía quejándose con el Director de Sistemas Corporativo, quién le decía "pos hombre, déjalos que revisen" ;)






¿Cómo puedo demostrar que la Multitarea es mala?

Un ejecutivo del área de tecnología me hizo esta pregunta y vinieron a mi cabeza muchas expresiones  a favor de la multitarea. Expresiones que he ido acumulando a lo largo del tiempo, entre ellas:

Expresiones de Ejecutivos
  • Siempre hay un tiempo de holgura en las tareas, así que el recurso puede hacer una tarea adicional en ese tiempo
  • Necesito que hagan un esfuerzo adicional dado que me han pedido todas esas tareas para el lunes, compra pizza
  • Realmente necesito esta tarea adicional y todas las demás, no se pueden priorizar
  • Siempre en el levantamiento de requerimientos hay tiempos muertos de espera al usuario, puedes avanzar con otras tareas mientras los esperas
  • Todo es urgente e importante, necesito que se avance tooodo en paralelo
  • Dado que aún no responden la observación que bloquea la tarea A, ve avanzando con la tarea B y de paso la C
  • Es mejor tener más de una tarea, de esa manera la gente siempre estará ocupada
  • Los recursos deben estar ocupados al 100%
  • Creo que están muy relajados, así que les asignaré un proyecto adicional
Expresiones de Empleados
  • Estoy asignado a 16 proyectos en paralelo, soy muy importante para la empresa
  • Me siento mal porque sólo tengo asignado un proyecto
  • Te separaré un espacio en mi agenda a fin de tratar ese tema en una reunión (su agenda tiene cien reuniones de cien proyectos)
  • Mi jefe ha enviado un email para que solucionen el impedimento que tiene la tarea que tengo asignada, mientras esa tarea está en espera he ido avanzando con estas otras tareas
  • Me aburre hacer una sola cosa a la vez, yo trabajo en 5 cosas a la vez
¿Es mala la multitarea?

La multitarea crea una sensación temporal de logro, dado que se reporta a muchas personas y a su vez, da la sensación de ser importante para la organización. Las metodologías ágiles no están exentas de este problema, las personas trabajan en más de una tarea a la vez. La manera clásica de asignar múltiples tareas a un mismo recurso es a través de diagramas Gantt de proyectos, que comparten recursos, aunque las tareas puedan estar sincronizadas y programadas al mismo tiempo, el recurso excede el tiempo de una de ellas y entra en periodo de multitarea facilmente

¿Qué desperdicios genera la multitarea?
  • El cambio de una tarea a otra genera un tiempo de desperdicio al cambiar de contexto 
  • Las tareas que no están siendo ejecutadas están en espera, este es un desperdicio muy grande
  • Las esperas a reuniones con usuarios o comité de aprobación son desperdicios que no necesariamente se originan por la multitarea, pero las incluímos para dar una alternativa a los mismos al final del artículo
¿Tienen más expresiones que hayan oído en sus trabajos? ¿Identifican algún otro desperdicio?