Hay 2 tipos de pensamiento con los que me suelo topar cuando visito equipos. El primero es, “si controlo o hago seguimiento a las personas estoy controlando el trabajo que ellas hacen”. El segundo, “mi equipo está ocupado produciendo cosas todo el día, no caen en el multitasking y cierran todo al final del día, eso nos hace ser productivos“. Este tipo de pensamientos pertenece al enfoque “Eficiencia de Recursos”, que es la forma en la cual nos han entrenado. Sin embargo, este enfoque tiene limitaciones e inclusive puede ser nocivo para una organización. Por otro lado, tenemos el enfoque “Eficiencia de Flujo”. En este post estaré hablando acerca de ambos enfoques.

Eficiencia de recurso

Este enfoque viene desde Taylor y su management científico, en el cual busca abaratar costos, creando áreas especializadas, o teniendo perfiles muy especializados. Por ejemplo, es muy común ver en equipos perfiles muy especializados y caros (no me gusta usar el término recurso para referirme a las personas, pero el enfoque “eficiencia de recurso” incluye personas), tenemos desarrolladores senior, arquitectos, lideres técnicos, business analysts, etc. Y dado que son muy costosos este enfoque lo que dice es que hay que tenerlos lo más ocupados. Lo que se enfocan siempre es que las horas hombre de esas personas son muy caras y hay que emplearlas muy bien. Se busca tener el 100% de esas personas ocupadas.

Bueno, ¿Qué de malo tendría usar el 100% de las horas de esas personas en hacer lo que mejor saben hacer? La respuesta está en el desequilibro que puede causar en el flujo de trabajo, es decir, por un lado producen demasiado, y en la siguiente fase o estado que va recibir todo eso no tiene la capacidad suficiente para procesar la demanda. Ahora, esta capacidad insuficiente puede deberse a que se cuenta con un límite de máquinas o personas especializadas para atender todo eso. Un ejemplo, en un equipo que hace software es común tener más desarrolladores que testers, supongamos que son 5 desarrolladores y 2 testers (usualmente están distribuidos en esa cantidad), si mantienes a los desarrolladores produciendo todo el tiempo, a testing se le va ir acumulando poco a poco requerimientos por testear.

Inicialmente Testing podrá hacerse cargo de atender la demanda al inicio de un proyecto, pero conforme pasan los días irán acumulándose más y más requerimientos, hasta convertirse en un cuello de botella con requerimientos pendientes de hacer pruebas, esto es muy común con el enfoque de testing tradicional, y los tester para llegar a la fecha es común verlos trabajar horas extra o los fines de semana. 

Eficiencia de Flujo

El enfoque de eficiencia de flujo se centra en el ítem (unidad de trabajo o flujo) que viaja a través de todos los estados o actividades del flujo de trabajo. Por ejemplo, imaginemos un requerimiento que pasa por los siguientes estados: análisis, desarrollo y testing. La perspectiva se enfoca desde el punto de vista del ítem que hará todo ese recorrido, para ello, debemos validar que no pase mucho tiempo en espera para ser atendido por cada actividad. Toda la cadena de valor se enfoca en el ítem y atenderlo, ya que ese ítem representa la necesidad del cliente.

Ahora recuerdan el ejemplo anterior donde los desarrolladores producían bastante y los testers estaban acumulándose de requerimientos por probar. ¿De qué forma puedo equilibrar las cosas y aplicar este enfoque de eficiencia de flujo? La respuesta es, colaborando entre todos. Recuerden que el foco de este tipo de eficiencia está centrado en el ítem que viaja a través de todo el flujo, en este caso el requerimiento. Si vemos que testing se está llenando de muchos pendientes, se recomienda que uno o más personas de desarrollo vayan a apoyar a testing para que testing vaya avanzando en terminar los requerimientos que están acumulados.

Ahora este enfoque choca bastante con el enfoque de eficiencia de recurso, cuando propongo esto lo primero que me dicen es “Jonathan el perfil de X vale tanto, es muy caro y no lo puedo tener haciendo testing, además no es su especialidad” si bien es cierto tal vez no sea su especialidad ayudará de cierta manera, y con el tiempo ira desarrollando otro tipo de competencia, ahora que hoy en día es muy común escuchar “habilidades en forma de T”.

Adicionalmente, también me he encontrado con otro tipo de problemas por pedir que colaboren, por ejemplo, una vez un desarrollador senior se quejó con su jefe porque estaba haciendo testing en lugar de desarrollar, recuerdo que dijo “A mí me contrataron para desarrollar, y poco a poco están añadiéndome más funciones que no son parte de mi cargo”, cabe mencionar que todo era dentro de sus horas de trabajo. En algunos casos es difícil hacer entender a las personas del equipo que el foco está en el requerimiento que tiene que avanzar y ser terminado y no tanto pensar que “esa actividad” no es parte de mi trabajo, recordemos que esos requerimientos son peticiones por parte del cliente, y debemos entregar eso que nos han pedido dentro de un tiempo prudente.

Eficiencia de recurso vs eficiencia de flujo

Es usual controlar personas en el enfoque de eficiencia de recurso, buscamos aprovechar al máximo sus horas e incluso medimos la eficiencia por persona, sin embargo, consideremos que a ninguno de nosotros le gusta ser controlado. Controlar personas no contribuye con el crecimiento personal de los miembros de nuestro equipo. Por otro lado, en eficiencia de flujo lo que se busca no es controlar las personas que trabajan en nuestro equipo, lo que se busca en este enfoque es controlar el trabajo o el flujo de trabajo. Permitiendo a las personas auto organizarse, aprender, descentralizar el conocimiento, y compartirlo con todos los miembros del equipo.

De acuerdo a la imagen, en eficiencia de recurso está pensado desde la perspectiva de la empresa, por lo que el cliente se tiene que adaptar a la estructura de la empresa. Muchas empresas están conformadas con este enfoque, y para satisfacer la necesidad de un cliente, la solicitud tiene que pasar por varias áreas, y cada área tiene sus propios objetivos y presupuesto. Objetivos que no necesariamente se encuentran alineados con la estrategia general de la empresa. Esto fomenta que las áreas no colaboren entre sí, y se dediquen a producir cada uno por su lado sin sincronizarse, o pidiendo que la otra área se adecue a ellos. Esto ocasiona molestia en el cliente por que usualmente se traduce en largos tiempos de espera, y muchas veces el cliente tiene que hacer el seguimiento de lo que pidió, generando más malestar. 

Por otro lado, en eficiencia de flujo está pensado desde la perspectiva del cliente, se busca que la empresa tenga como foco principal la necesidad del cliente, así que todos los involucrados tienen que colaborar para cubrir esa necesidad. Si algo que pidió el cliente tiene que pasar por muchas áreas, se hace énfasis en que todas estas áreas colaboren entre si teniendo en cuenta la estrategia general de la empresa, cabe mencionar, dicha estrategia debe tener como foco principal cubrir la necesidad del cliente. Es decir, desarrollar capacidad en la empresa para adaptarse a lo que solicita el mercado, ¿este término les resulta familiar?, bueno, esta es la definición de Agilidad en los negocios, la cual, habla de tener o desarrollar capacidad en varios aspectos de la empresa.

A continuación se muestra un cuadro mostrando el cambio de eficiencia de recurso a eficiencia de flujo.

Pensamientos Finales

Si bien es cierto el enfoque de eficiencia de recurso ha funcionado durante muchos años y muchas empresas tienen su estructura organizacional basada en este enfoque, debemos considerar los beneficios de pasarnos a un enfoque de eficiencia de flujo.

En un sistema con enfoque de eficiencia de flujo buscamos crear un contexto donde las personas colaboren entre si teniendo como foco principal la necesidad del cliente. Y no buscamos controlarlas sino controlar el trabajo, y yendo aún más allá, no buscamos que los líderes solucionen los problemas sino que la gente en si misma solucione los problemas a través de iniciativas o propuestas que ellos puedan tener. Para eso, es necesario crear un contexto de colaboración.

Espero les haya gustado el post, nos leemos en un próximo post.

Material Bibliográfico recomendado

Niklas Modig, Par Ahlstrom. This is Lean: Resolving the Efficiency Paradox

Eliyahu M. Goldratt. La Meta

Sección del cherry

Si te interesa saber más acerca de estos temas y que otras formas hay para ayudar a mejorar tu proyecto o servicio, este 07 de Diciembre estaré dictando un curso oficial, «Team Kanban Practitioner», en el cual veremos las prácticas de Kanban, los principios de gestión del cambio, diseño de tableros, proto – Kanban, una simulación del método Kanban, además, tendrás 2 horas de asesoría personalizada. Para más detalles visita el siguiente enlace: https://www.agilewisecorp.com/team-kanban-practitioner-peru/