Productividad: Contexto y priorización de proyectos

Nota: tenía esto guardado desde 2013, pero por alguna razón olvidé que estaba en el cajón de “para publicar” hasta la limpieza de enero de 2016.

En mi carrera como desarrollador me he encontrado bastante a menudo, supongo que como todos, con una cantidad excesiva de proyectos sobre la mesa y por eso me gustaría comentar una estrategia para abordarlos que, sin ser mágica, me permite establecer un flujo de trabajo operativo.

Empezaré aclarando que pienso que la abundancia de proyectos es por un lado algo bueno, porque significa que voy a tener trabajo durante un tiempo (hola Crisis), pero por otro lado, resulta que me encargo de casi todas las funciones de cada proyecto por lo que soy yo quien debe organizar mi propio tiempo (al menos cuando me lo permiten) no solo entre proyectos sino entre tareas del proyecto… y rendir cuentas y plazos.

Así que ahí estoy, el equipo de un solo hombre, viviendo fuera de mi zona de confort (habilidades técnicas variadas VS sociales, de gestión, de comunicación, de diseño…), y tratando con una miríada de proyectos concurrentes. Y con todos estos cambios de sombrero, entorno, tecnología y negocio, sufro de manera crónica los cambios de contexto. Cambios que se cargan la productividad, claro.

Los cambios de contexto

Todo el que haya trabajado (de verdad) en varios proyectos a la vez, sabe que un cambio de contexto, supone “sacar” de la cabeza todo lo que tengas sobre una tarea X y llenarla con la tarea Z que quieras acometer. A mayor complejidad del proyecto, y a mayor número de elementos implicados (gente, documentación, herramientas, productos…), mayor es el tiempo empleado en cambiar de contexto, especialmente si además se trata de proyectos en áreas de negocio diferentes (cine, logística, auditoría legal, banca de inversión, marketing…). Algunos autores calculan una media de 20 minutos perdidos por cada interrupción en un trabajo intelectual que requiera concentración, pero personalmente creo que los cambios de contexto entre proyectos donde uno se encargue de casi todas las áreas, que además sean de áreas muy diferentes, y que impliquen un gran número de herramientas diversas, suelen ser mucho más pesados que una interrupción media, precisamente por las dimensiones de roles, ámbitos, conocimientos y entornos que se añaden al problema. Y todo esto sin entrar a comentar el desgaste intelectual de todo esto.

Estimemos por ejemplo 10 días para un proyecto corto, luego contemos que cambias de proyecto (por la razón que sea, no por capricho) 2 veces al día. Con esas cifras tan pequeñas es fácil calcular, siendo muy conservador y usando la media de 20 minutos, que acabaré acumulando (10 días x ((20 minutos x 2) / 60)) más de 6 horas de pérdidas. Un cálculo completamente ficticio y en bruto, pero que sirve para poner de manifiesto que los cambios de contexto tienen un coste que no se suele tener en cuenta, y que por tanto deben ser evitados en lo posible, si no queremos provocar una caída a plomo del trabajo efectivo realizado.

El método

Con esta idea en la cabeza, a lo largo de los años he desarrollado un flujo de trabajo que, si bien tiene sus propios problemas, sí me permite ser más productivo y reducir los cambios de contexto. Y lo que es más importante, lo hace sin que tenga que pensar o decidir demasiado.

El método es este:

  1. Trabajar únicamente en el proyecto que tenga la estimación de tiempo más corta e ignorar en lo posible los demás. A menos proyectos en marcha, menor es la probabilidad de tener que cambiar a uno, así que es mejor acabar los más cortos cuanto antes.
  2. Trabajo en el proyecto de los clientes que pagan. Si un cliente es de los que tardan en pagar, o de los que ponen pegas durante meses (no me meto en si con razón o no), su proyecto queda en cola. Esto se debe sobre todo a que un proyecto no cobrado, es un proyecto abierto, y el cliente que no paga tiene poder de imponer cambios no contemplados que alargan el proyecto de manera inesperada más allá del alcance inicial. Con esta regla, minimizo el impacto de los clientes/proyectos “malos”.
  3. Brown dispatching de tareas. Los proyectos más complejos (técnica u organizativamente, o en cualquier otro ámbito) suelen requerir de acción por parte del cliente o de terceros así que para evitar cambiar de tarea, ante una interrupción, trato ganar tiempo decidiendo lo más rápido posible si debo pasar la pelota a otra persona/responsable. Por ejemplo: si hay una incidencia en una aplicación, pido datos, pantallazos, etc; si me piden información, les mando al repositorio del proyecto a buscar (SharePoint es tu amigo); si me piden una reunión, les digo que mañana, que pongan ellos la hora. Y así con todo, bajo la premisa de evitar el cambio de tarea o postergarlo al mañana, cuando el cambio de contexto casa/trabajo es inevitable (hay que dormir) y el daño producido es menor, aunque no evitado.

Obviamente, estas técnicas tienen su propia problemática y en ocasiones no es factible utilizarlas, pero al menos ayudan a NO tomar decisiones y reducir los cambios de contexto, por lo que mejora la productividad y reduce el cansancio asociado a la toma de decisiones, que como sabemos, en el desarrollo de software es algo agotador.

 

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s