¡Hola, amig@! Esta es nueva sección en WCE. Estaremos tratando varios temas que son curiosidad de todos y que de vez en cuando, un poco de información brinda mucha claridad. Espero que esta información ultra-comprimida de 10 min les sirva en sus trabajos, vidas y proyectos.
Hoy, estamos aquí para hablar de las varias metodologías de trabajo y culturas diferentes que existen en varias industrias y empresas. Si ustedes forman parte de la industria manufacturera, automotriz, espacial, etc seguro han escuchado el término Lean o Lean Manufacturing. Además, seguro están un poco hasta la coronillas de escuchar términos japoneses como Kaizen, Jidoka, Heijunka, Kanban o Poka Yoke por mencionar algunos. Tranquilos, que no es tan difícil como se escucha. Otros, por el contrario, si forman parte del mundo del software y la web o algún relacionado, habrán escuchados términos como Agile, Sprint o Scrum. La cuestión aquí, ¿por qué existen tantas palabras y metodologías diferentes si al final todo se trata de cuestiones como administración, calidad, recursos y tiempo?
Sea pues, ahondemos un poco en qué trata cada una de estas corrientes.
Lean Manufacturing o TPS
Después de la segunda guerra mundial, Japón tenía que encontrar una manera de salir de la situación económica complicada en la que estaba. Particularmente, la industria automotriz, con sus pocos recursos económicos y de fuerza de trabajo tenía que hacer frente a industrias americanas como GM o perdería su mercado. Siendo así, la familia Toyoda, dueña de Toyota, creó las bases de todo lo que sería el Sistema de Producción Toyota (TPS) que se enfocaría en maximizar el valor de sus productos (autos) a través de la minimización de todo el desperdicio (o muda como es llamado en Japón) que no agrega valor directo al producto que se hallaba en sus procesos internos y a lo largo de toda su cadena de suministro.
Estos tipos de desperdicio fueron y siguen siendo:
1. Sobreproducción: Osea, terminar con muchos productos realizados (en este caso, autos) que aún no se necesitan o no se han vendido.
2. Tiempo de espera: Es el desperdicio que consiste en parar la línea de producción o dejar mucho tiempo un producto sin terminar (esto se llama WIP o Work In Progress). Como el café que dejas esperando en la máquina hasta que se enfría.
3. Transporte: Cuando mueves un producto en proceso (literalmente) no sirve de nada. Esto no es un proceso (aunque necesario a veces) le agregue un valor al cliente. Ejemplo: a ti te importa 2 cacahuates si tu iPhone dio 1,2, 5 o 100 vueltas alrededor de la fábrica antes de ser terminado.
4. Sobre-procesamiento. ¿1 pulida y encerada a tu nuevo BMW? ¿2? ¿3? Llega un punto en el que ya te da igual.
5. Inventarios innecesarios. Consiste en abastecer el almacén de materia prima sobrante.
6. Desperfectos. Es el desperdicio que se genera por piezas o productos defectuosos que tienen que re-trabajarse o descartarse.
7. Movimientos innecesarios. Es muy parecido al desperdicio número 3. Sin embargo, este se refiere a los movimientos que tiene que hacer el personal que trabaja en la elaboración del producto o la maquinaria que tiene que moverse para trabajar en un producto.
La filosofía Lean Manufacturing que fue el nombre posterior para el TPS, para lograr la optimización de este desperdicio, crea y define un sistema que tiene 2 pilares:
1. Pilar JIT (Just-In-Time). Este pilar consiste en la idea de que un producto o servicio (sí, también puedes aplicar Lean en procesos administrativos y/o de servicios) solo debe de trabajarse cuando hay un cliente esperando por él. Esto conlleva la creación de ciertos métodos como el Flujo-de-1-pieza que imita los comportamientos de una fila de espera como en el mercado. De hecho, por esta idea de fila y 1 producto a la vez (ojo: en una estación de trabajo) es lo que dio el famoso nombre Lean a esta metodología.
También, de este pilar se desprenden varias sub-metodologías subsecuentes como los sistemas de jale (pull systems), la nivelación de la carga (el famoso heijunka) o el tiempo de ciclo (takt-time).
2. Pilar de Calidad y Mejora Continua (Kaizen). Este otro pilar consiste en que las cosas deben ser totalmente valiosas para el cliente. Y el mejor indicador para esto es por tanto, la calidad del producto o servicio que realices. Además, esta calidad debe ser mejorada continuamente a través de la estandarización del trabajo y la exploración de nuevas ideas y herramientas que permitan incrementar el valor visualizado en tus clientes.
Es importante entonces concluir que Lean Manufacturing es una corriente japonesa que se forma a partir del agrupamiento de ciertas herramientas basadas en los dos pilares y tipos de desperdicios que mencionamos.
Otro punto que es bueno destacar es que las herramientas (como poka-yoke, 5s, etc) de Lean Manufacturing todas tienen el único objetivo de lograr una disminución del WIP o lograr la estandarización de procesos para asegurar la calidad y buen desempeño. No son herramientas que debas usar solo por el mero hecho de usarlas y convertir a tu empresa o proyecto en algo Lean. La parte importante detrás de toda implementación Lean que hagas es el análisis que lleves a cabo para reducir el WIP total o el nivel de estandarización que pretendas lograr en el tipo de industria que necesites.
Agile y SCRUM
Y bueno, con Agile y SCRUM sucede algo parecido. También son sistemas de optimización de procesos, entregas a clientes y administración de recursos que tuvieron origen en los 80s o 90s en la industria del desarrollo del software al punto de vista de este blog como una evolución del sistema Lean que cubría las necesidades específicas de ese sector.
Particularmente, la industria del software tiene un problema muy característico: los cambios en el scope o alcance inicial del proyecto así como sucesivas actualiación y ajustes al programa principal. El tema lo podemos ahondar después pero básicamente sucede mucho que en la industria del software, lo que se planea en un inicio que un programa o software debe hacer no es lo que termina siendo al final debido a muchísimos factores diferentes como procesos no considerados, tecnología insuficiente, mala aproximación de de desarrollo o errores y casos o escenarios no considerados. Un ejemplo: tienes una empresa dedicada al desarrollo de interfaces o software de administración de líneas de producción. Por tanto, en cada implementación que realizar tienes que adaptar tu programa a los procesos de esa línea de producción en espécifico. Dado que eres una persona que no está viviendo en esa línea de producción todos los días, es muy común que haya ciertos procesos o eventos que no sea tan fácil que consideres o visualices al inicio de tu desarrollo de software por lo que posteriormente tienes que modificar un poco tu alcance o la tecnología que utilizarás. No tienen idea de la cantidad de veces que he visto a dos empresas tener diferencias y presiones por esta cuestión.
Bueno, no alargándonos mucho. Las primeras definiciones de Agile o metodologías ágiles de administración de proyectos que trataron de hacer frente a este problema se basan en el Agile Manifesto que tienen 12 principios:
1. La primera prioridad es conseguir la satisfacción del cliente mediante la entrega a tiempo y continua de software. (Sí, lo primero importante para ti es que tu cliente que te molesta a veces si lo que quieres es ofrecer un servicio de calidad para después empezar a tener tu reputación y calidad asegurada frente al mundo).
2. Aceptar cambios al alcance del proyecto incluso auque sean tardíos. (Sabemos que es complicado, sabemos que no es lo que se acordó, pero estar abierto al cambio incrementa la calidad y satisfacción de tu cliente).
3. Realizar entregas continua de software idealmente entre 2 semanas 2 meses al menos. (Tener a tu cliente constantemente actualizado de tus avances lo mantendrá tranquilo y además disminuirá el riesgo de hacer cambios muy tardíos que pueden detectarse previamente sin un giro de volante tan grande).
4. La gente de negocios o vendedores del software y los desarrolladores deben trabajar de manera conjunta. (Es importante que estas dos partes trabajen juntas ya que es muy fácil que por aparte se cometan errores o se hagan suposicion que no tienen por qué ser ciertas.
5. Construye un ambiente de trabajo donde tus desarrolladores estén cómodos y se fomente el trabajo en equipo. (Pretty obvious, right?)
6. La mejor manera de obtener información o responder dudas es mediante la conversación cara a cara. (Esto siempre hará que las soluciones que esté planeando el equipo de desarrollo estén lo mejor soportadas en lo que el cliente de verdad necesita).
7. El software que empieza a funcionar es la primera y más importante referencia de avance o progreso del proyecto. (Ya que son los únicos entregables que existen, es lo único por donde se puede obtener retroalimentación).
8. Los procesos ágiles promueven el desarrollo sostenible y constante. (Un proyecto no es un proyecto ágil si está detenido y no avanza constantemente. Es muy interesante la dinámica que ocurre cuando tanto las empresas desarrolladoras como las empresas cliente siguen este principio).
9. La constante atención a la excelencia y buen diseño mejora la agilidad. (Ya que al mantener tus metas claras, tu equipo también sabrá a qué es a lo que debe concentrarse).
10. La simplicidad es esencial. (Entre más al grano sea tu solución, mejor y más efectiva será).
11. Los mejores software en diseño y desempeño son hechos por equipos que saben auto organizarse. (Entre más capacidad de análisis y empatía por el cliente tengan tus diseñadores, mejor será tu resultado final).
12. Cada cierto tiempo, un equipo ágil realiza una introspección para ajustas sus prácticas para las nuevas necesidades que vayan surgiente.
Uff, son bastantes aunque empiezan a dar una idea de lo que ser ágil o agile significa. Al menos ya sabemos que ágil es un conglomerado de ideas que permiten a una persona de desarrollo de software (ya sea gerente, vendedor o desarrollador) saber como conducir su día a día en el trabajo. Sin embargo, el Agile Manifesto, también tiende a ser ambiguo y muy abierto a las interpretaciones del sector en el que se utilice. Las necesidades que enfrenta una empresa de comercio online o una de desarrollo de sistemas de administración empresarial como ERP's no son para nada las mismas aunque ambas desarrollen software.
Sin embargo, si tu quieres convertir a una empresa o a un departamento en ágiles solamente con el Agile Manifesto vas a tener una muy buena e interesante fase de prueba y error hasta que logres una metolodogía de trabajo que pueda cumplir eficazmente los 12 principios. Y es totalmente válido también, hacer esto tiene la ventaja de generar una metodología de trabajo ágil específica para la empresa o departamento que puede dar una identidad muy grande y sólida que proyectar a tus clientes y que además servirá como un medio de identificación entre tus trabajadores.Aquí también entran en juegos los códigos de ética, manuales de trabajo y valores de una compañía que también podemos discutir en otro artículo.
Por otro lado, si lo que quieres es trabajar sobre algo que ya esté establecido y comúnmente aceptado por el mercado es donde empezarás a encontrarte conceptos como SCRUM o SAFe (Scaled Agile Framework), Stories y Epics. Este artículo no es para ahondar a detalle en cada uno de esos Frameworks o metodologías de trabajo pero sí puedo contarles que el SCRUM consiste en definir ciertos conceptos utilizables del trabajo ágil para poder orientar la construcción de procesos y entregas a cliente como:
1. Backlog: Todas las funcionalidades o requerimientos pendientes de desarrollar en una entrega o proyecto de software.
2. Sprint: Entregable que contiene una o más funcionalides de la entrega final para poder revisada y aprobada.
3. Sprint review: Aprobación de sprint desarrollado en un período corto de tiempo.
Existen más conceptos pero esos pueden ser los básicos. Además, existen metodologías aún más generales y mas amplias de trabajo que consideran la metodología SCRUM dentro de ellas mismas. Tal es el caso de SAFe que su mismo nombre hace alusión a que es una manera segura de implementar una metodología de trabajo ágil para cualquier empresa o departamento. Con el fin de ser muy breves, SAFe define roles de personas especfícos como Desarrolladores, Business Owners, Product Owners así como las relaciones entre ellos a través de diferentes niveles de jerarquías organizaciones con el fin de asegurar un entorno eficiente utilizando SCRUM y también tomando el ciclo de vida de un producto. ¿Bastante especializado ya, no?
Al final, con lo que quisiera que se quedaran es que tanto Lean como Agile ambos son sistemas o hasta ideologías de como llevar un negocio que pretender optimizar sus procesos para sacar el mejor provecho de sus recursos disponibles. Y así como es imposible detallar la historia de un país a un nivel 100% claro, también lo es definir como estos dos sistemas se han ido relacionando a lo largo del tiempo.
Por ejemplo, en Agile se puede sospechar una influencia directa de Lean al fomentar las las instrospecciones de equipo que pueden ser el equivalente del pilar de calidad que fomenta Lean o incluso la metodología SCRUM podría analizarse como un símil al principio Lean de Flujo de una pieza. Digo, incluso en el sitio oficial de SAFe al día de hoy puede apreciarse que su entorno de trabajo es pensado para empresas Lean que ya comulgan con principios muy parecidos a los que tiene su propio framework.
Por último, es importante mencionar que ni Lean es solamente para una industria de automóviles ni Agile es solo para una de desarrollo de software. Ambos, pueden utilizarse en diferentes entornos y sectores incluso aunque sean puramente administrativos u orientadas a la generación de servicios y no de productos. Como mencioné, lo importante es el análisis que se lleva a cabo por detrás.
En fin, espero que este pequeño resumen y visión personal te haya servido o despertado tu interés al menos un poco y si crees que puede servirle a alguien no dudes en compartirlo, dejar tu comentario o corazoncito y ¡hasta la próxima!