Enseñanzas del Cubo de Rubik

Por Stephanie Ángela Díaz Torres.

¿Alguna vez has intentado armar el cubo de rubik?… seguramente al menos sabes cuál es este cubo del que te hablamos… bueno te platicamos… el cubo de rubik, es un juego de rompecabezas inventado en 1974 por un arquitecto húngaro, el record actual en resolverlo es de 4.904 segundos (rapidísimo verdad!!!!)…. El reto es la velocidad, resistencia y superación de obstáculos adicionales, como ¡armarlo con los ojos vendados por ejemplo!

¿Te has parado alguna vez a pensar en el número de posibles posiciones distintas que puede presentar el rompecabezas? ¿O cuántos movimientos en teoría se necesitan como máximo para resolverlo? En este post no te voy a decir cómo resolverlo, te voy a contar como este cubo puede ser un gran ejemplo a seguir y nos puede dejar una gran enseñanza.

En nuestra vida laboral, podemos aplicar algunas de las enseñanzas que nos deja el cubo de rubik, ¿Por qué?, Bueno, pues éste entretenido rompecabezas desarrolla partes importantes en el cerebro, como la lógica, inteligencia espacial, la agilidad mental y la reacción ante los problemas. Siendo así todas estas habilidades las mismas que podemos aplicar día a día en nuestro trabajo.

Por ejemplo, al aplicar la inteligencia espacial se tiende a pensar en imágenes y fotografías, visualizarlas, diseñarlas o dibujarlas. Estas características se pueden visualizar en los procesos, cuando se plasma el proceso de una empresa, se crea un diagrama de flujo, explicando a detalle que es lo que se realiza, o en el levantamiento de requerimientos, cuando el cliente comienza a explicar que es lo que quiere, nosotros como analistas luego luego echamos a volar nuestra imaginación y comenzamos a crear un pequeño esqueleto de cómo podría quedar el producto o en QA; al ver el sistema, te empiezas a imaginar escenarios a aplicar los tipos de pruebas y formas de hacer que falle el sistema…. ¿a poco no?

Ahora imagina que estás en una reunión de trabajo un poco crítica, donde resulta que uno de los proyectos del área está desfasado en fechas, algo que no pasa en tu área ¿verdad? Bueno, pues en este tipo de situaciones no me dejarás mentir, forzosamente debemos de tomar decisiones ¿en dónde estuvo la falla? … aquí es donde debemos ser muy inteligentes para darle solución a nuestro problema, ya que frecuentemente podemos encontrarnos paralizados por la situación, como si nos encontráramos en un cuarto oscuro o en un callejón sin salida, o por el otro lado nuestra reacción puede ser una pérdida del control sobre ella o sobre nosotros mismos, a tal punto que presos del enojo, ira, angustia, estrés o la ansiedad optemos por respuestas que terminan no solo no siendo las más adecuadas, sino poniéndonos en mayores dificultades e incluso avergonzándonos ante nosotros mismos y nuestro equipo.

¿Pero, qué tiene que ver el cubo de rubik?

Bueno, pues los aficionados al cubo de rubik aprenden cientos de algoritmos, un conjunto de movimientos. También nosotros debemos aprender un sinfín de algoritmos o patrones a seguir para poder resolver nuestros problemas. Y sabemos que tener manos “rápidas” en el trabajo es sumamente importante.

Todos tenemos actividades diferentes, pero se podría decir que hay cosas en común para Procesos, Fábrica de Software, RDA o QA. En el trabajo aplicamos, desarrollamos o mejoramos procesos, tenemos metas, hay clientes con los cuales debemos quedar bien y clientes a los cuales debemos convencer de que somos los mejores, que somos la mejor opción…

Con el cubo de rubik, hay que tener responsabilidad, tenacidad, tolerancia, pasión y tolerancia a la frustración, esto mismo podemos aplicar en nuestro trabajo… creértelo es lo más importante para no darte por vencido y lograr la única meta, salir con éxito de cada uno de los proyectos que tenemos.

Al final te presumo que logré armarlo… después de intentarlo una y otra vez, casi arrancando mi cabello por desesperación pude mejorar mi tiempo (porque lo armaba en días) y así rompiendo mis propios records.

Recuerda que todo camino tiene cuestas y pendientes, días de lluvia o soleados, algunos pueden ser más difíciles o largos, hay tramos en los que vas acompañado y otros en los que simplemente se camina solo. Pero jamás habrá dos caminos iguales, pues todos son el resultado de lo que cada uno individualmente se ha planteado.
Debemos por lo tanto responsabilizarnos de nuestros actos y tomar conciencia de ellos, y si cuando estas caminando necesitas parar ¡HAZLO!, si estás yendo por un camino que crees y sabes que no es el adecuado, ¡PARA!

Porque, aunque sepamos que muchas veces no vamos por el camino adecuado, nos acomodamos y nos conformamos, no queriendo asumir nuevos retos que, aunque al principio pueden hacérsenos muy cuesta arriba, te puedo asegurar que en breve se pisa plano, y será sólo entonces cuando habrás llegado al lugar donde siempre querías haber estado. EL CAMINO DESEADO.

DevOps

Foto Efraim bn

Por Efraim E. Vázquez

Quizá hayas escuchado esta peculiar palabra que últimamente se esta poniendo de moda, pero… ¿Que es DevOps?

Según Wikipedia DevOps es un acrónimo inglés de development (desarrollo) y operations (operaciones), que se refiere a una metodolgía de desarrollo de software que se centra en la comunicación, colaboración e integración entre desarrolladores de software y los profesionales de sistemas en las tecnologías de la información (IT), pero va mucho más allá de solo unificar los términos y las responsabilidades.

Esta corriente va muy de la mano de la metodología Agile ya que fue concebido a partir de estas y se recomienda que se implementen juntas.

DevOps es una metodología con la que se cambia el modo en el que se gestiona el ciclo de desarrollo de software, a nivel tecnológico, pero sobre todo a nivel cultural. Los equipos de desarrollo y de Operaciones (o sistemas) eliminan el trabajo en silos y comienzan a trabajar de una manera colaborativa y bidireccional. Entre todos cubren el ciclo completo de desarrollo de software.

Para conseguirlo, se introducen nuevas herramientas que contribuyen a la automatización de tareas repetitivas y al trabajo en equipo, ayudando a agilizar los procesos para evitar trabajo duplicado y la introducción de nuevos errores.

El objetivo final de DevOps es minimizar el riesgo de los cambios que se producen en las entregas y dar así un mayor valor tanto a los clientes como al propio negocio.

El ciclo de vida DevOps

Planear y hacer un seguimiento

Se identifican las actividades para después mantener un seguimiento de estas mediante prácticas y procesos como los paneles kanban y la metodología ágil. Cuando se hace un seguimiento visual del trabajo, las partes interesadas obtienen una conclusión clara de la capacidad del equipo de desarrollo para planear y clasificar mejor las tareas por orden de prioridad, para así evitar situaciones de urgencia innecesarias.

Desarrollar

Escribir código usando modernos sistemas de control de versiones, como GIT, para integrarlo de forma continua y segura en la rama principal. Cuando se completa una característica, el desarrollador envía una solicitud de incorporación de cambios, una vez aprobada, los cambios se fusionan mediante combinación en una rama maestra, luego la rama anterior se elimina.

Compilar y probar

La inserción de código en GIT u otro sistema de control de versiones inicia un proceso de compilación automatizado. El código se prueba y se válida para asegurar que los errores se detectan rápido en el proceso de desarrollo, cuando aún están recientes en la mente del desarrollador y cuesta menos corregirlos. Este proceso de automatizar la compilación y las pruebas se denomina integración continua (CI). Un artefacto que se puede implementar en el entorno de producción es el resultado de una compilación y una integración satisfactorias, lo que permite llevar a cabo una entrega continua (CD), es decir, la capacidad de implementar en producción en cualquier momento.

Implementar

Una vez probado y validado, cada cambio se puede implementar en el entorno de producción. Si se utilizan prácticas de entrega continua, la implementación final en producción es una decisión empresarial controlada manualmente.

Con la implementación continua, todo el proceso, desde que se confirma el código hasta que se implementa en producción, es automático. Cuando el código se implementa de forma automática, los clientes acceden a las nuevas características tan pronto como están listas para usarlas.

Supervisar y controlar

Cuando la aplicación ya está activa en el entorno de producción, la supervisión ofrece información sobre su rendimiento y patrones de uso. Se obtienen datos de diagnóstico completos de inmediato, para que el equipo pueda tomar medidas rápido y ofrecer así alta disponibilidad. Se mitigan posibles problemas para los usuarios y la recopilación de datos que permitan tomar decisiones empresariales informadas sobre la actividad de desarrollo a futuro.

Beneficios de DevOps

• Despliegan 200 veces más frecuentemente
• Sus tiempos de entrega son 2,555 más rápidos
• Tiempos de recuperación 24 veces mejores y 3 veces menos errores provocados por cambios
• Los equipos IT de alto rendimiento pasan un 50% de tiempo menos resolviendo incidencias de seguridad
• Y un 22% menos de tiempo resolviendo errores y problemas

Finalmente, después de todo lo mencionado podemos llegar a la conclusión de que DevOps es una metodología de desarrollo de software que integra desarrolladores y administradores de sistemas, en el cual los desarrolladores se enfocan en solo codificar para realizar liberaciones continuas, más rápidas, con mas flexibilidad y a un menor coste.

j
j

Testing: La importancia de la calidad del software y el impacto en nuestra vida diaria.

Por Víctor Alfonso Ramos

No te vengo a platicar técnicamente de cómo trabaja la fábrica de pruebas, que son las pruebas y como se aplican, mejor te contaré como algo tan “sencillo” puede llegar a tener un gran impacto en nuestra vida diaria, incluso ponerla en ¡riesgo! ¿Crees que estoy exagerado?, ¿Crees que realmente es necesario hacer pruebas al software?, ¿Por qué hay tantos “peros” para el Testing?

Te voy a contar sobre algunos mitos a los que me enfrento como Tester. Todos podrían decir: “Probar es fácil y aburrido, cualquiera puede hacerlo, no es un trabajo creativo”. Pero se necesita de habilidades especializadas, perspicacia, conocimiento a fondo del sistema y la tecnología, para probar el software. Es indispensable la visión de una persona ajena a la programación, para garantizar que el funcionamiento sea el correcto y detectar posibles errores a tiempo.

¿Probar es muy caro? ¿Pagar menos para las pruebas o pagar más por la corrección posterior? Con las primeras pruebas se ahorra tiempo y coste en muchos aspectos, sin embargo, la reducción del coste y del tiempo de pruebas, puede derivar en el diseño inadecuado de una aplicación de software. En un producto inútil. Aquí aplicaría el dicho “lo barato al final sale caro»

Todo esto podría hacerte pensar que tester y desarrollador son enemigos, Y rotundamente NO. La entrega de productos de calidad para los usuarios finales es un trabajo en equipo.

Mucha gente piensa que testers y desarrolladores están destinados a odiarse, pero esto no tiene por qué ser así. Al fin y al cabo, el objetivo global de ambos en el proyecto es común, mantener un cliente feliz que pueda gozar de una aplicación eficaz.

location

Supongamos que quieres viajar a Suecia y eres de las personas que el GPS es su mejor aliado para buscar los mejores sitios, pero al entrar a internet te das cuenta que ¡SUECIA no existe! ¿Cuándo desapareció? Pues resulta que en 2009 se produjo el más genuino y espectacular error de software de la historia. En esta ocasión, causado por un solo carácter en una línea de código (faltaba un punto), que hizo desaparecer a Suecia del mapa de Internet.

O qué tal que roban tu celular, lo olvidas o simplemente lo pierdes. Pero como seguramente eres de las personas que tienen su respaldo en la nube, piensas que todo está bajo control, sin embargo, al intentar descargarlos te das cuenta que ya no están, que se esfumaron, pensarías que es una racha de mala suerte ¿No?, pero en realidad podría ser causa de un defecto de software tal como ocurrió a finales del 2009 cuando la empresa T-Mobile y Microsoft perdieron durante unos días toda la información personal de los usuarios de Smartphone Sidekick, todo esto a causa de un fallo que se produjo durante una actualización de los equipos de almacenamiento.

Y como sé que aún después de estos ejemplos sigues siendo de las personas que consideran que la calidad del software no afecta en tu vida, pues bien por último, imagina que vas a hacerte una radioterapia (que no es cualquier cosa) y al final sales con un exceso de radiación.

¿¿Triste verdad??

6

En el año 1985 y 1987 la máquina Therac-25 fue la causante directa de la muerte de, al menos, tres pacientes entre los cuales se les suministró sobredosis masivas de radicación. Y se concluyó que la razón de estos accidentes fue por malas prácticas en desarrollo, mal análisis en los requerimientos, mal diseño del software y sobre todo a la falta de revisión de la calidad de software.

Y... Entonces, ¿Sigues creyendo que no es necesario hacer pruebas?

Adictos a la Felicidad

Por Mariano

Intensa-Mente una de las películas más recordadas del 2015. La mayaría la ha visto al menos una vez y si no, estoy seguro que en su momento se cansaron de ver Facebook repleto de imágenes del filme.

null

Un excelente trabajo de animación que simplifica temas complejos de psicología con muchísima creatividad. Pero, ¿qué pasa cuando cambiamos un poco nuestro enfoque y analizamos la película de diferente manera?

En los últimos meses, me encontrado con distintos artículos en la web que decidieron hacer lo mismo que yo, llegando a conclusiones en mi opinión exageradas que incluso acusan a la película de ser una crítica al capitalismo moderno. Sin embargo, todos concordaban en un punto: Alegría es el verdadero villano en la historia.

En lo particular me hizo sentido, la manera más simple de analizar la historia es verla como el viaje de Alegría por el subconsciente de Riley para recuperar un importante recuerdo antes de que esto cause un trauma irreparable a la pequeña. Visto de otro modo, sin embargo, ¿acaso no es Alegría la culpable que se perdiera el recuerdo en primer lugar? y no sólo eso ¿acaso no es Alegría la causa de cada uno de los problemas que se presentan a lo largo de la historia?

Podría escribir un libro entero analizando Intensa-Mente desde ese punto de vista, pero ese no era mi objetivo al escribir este artículo. Lo que en verdad quería transmitirles es como mediante este ejercicio pude ver reflejado un mal que afecta gravemente a nuestro entorno laboral y social en la actualidad; Nos hemos vuelto adictos a la felicidad.

Y no a la buena felicidad, si no a esa felicidad efímera que con tanta desesperación buscamos regada en nuestro entorno. Cuantas veces no hemos escuchado de aquellas empresas que ofrecen innovadores programas de bienestar y mejoramiento de calidad de vida:

“Entre nuestras instalaciones contamos con una sala de descanso”.

“Tres comidas perfectamente balanceadas en nuestra cafetería completamente gratis para cada colaborador”.

“Deporte y espacios para practicarlo”.

Por supuesto que esto no es algo malo, al contrario, hasta cierto punto me parece que es el rumbo a seguir para la administración del capital humano; no obstante, también considero que estas prácticas la mayoría de las ocasiones están impidiendo a las personas alcanzar sus verdaderos objetivos. Estas prestaciones rápidamente se transforman en justificaciones:

“No importa que tan desgastante sea mi jornada; porque tengo una habitación llena de juegos para relajarme en cualquier momento”.

“No tengo porqué regresar a casa; porque puedo desayunar, comer y cenar aquí”.

“Qué importa que pase 8 horas al día sentado frente a la computadora; porque voy 30 minutos a nuestro gimnasio”

Es entonces cuando nos preguntamos cosas verdaderamente atemorizantes ¿Por qué no soy feliz? ¿Por qué mis colaboradores no son felices? Y lo más preocupante es que no podamos responderlas aun cuando pertenecemos a una empresa que ofrece las mejores condiciones en el mercado.

El problema no está necesariamente en nosotros simplemente es la forma en que la sociedad nos ha programado, hace de la felicidad una droga. El mundo te necesita feliz y no se cansa de decírtelo “cómprame y sé feliz, úsame y sé feliz, conóceme y sé feliz”, es natural que las empresas sigan el mismo patrón y vendan a sus trabajadores felicidad.

Como nos lo enseña Intensa-Mente la felicidad va más allá de eso, la felicidad realmente es armonía. La empresa que verdaderamente adopta una filosofía enfocada en las personas no sólo busca dar a sus colaboradores prestaciones que satisfagan momentáneamente esa adicción; el enfoque en las personas entiende a cada colaborador y a ese millar de emociones que habitan en su cabeza, ayudándolo a encontrar un propósito que le permita ponerlas a trabajar juntas para alcanzarlo. Una empresa que se enfoca en las personas no se limita a darle diez razones del por qué trabajar a sus colaboradores, una empresa así entiende que lo más importante es ayudarlos a encontrar un sólo para qué.

Finalmente, los invito a que reflexionen y se hagan la siguiente pregunta:

¿Para qué estoy trabajando cada día?

Pero antes de responderla recuerden que la verdadera felicidad viene de adentro hacia afuera y no viceversa.

Haciendo de tus fracasos, un éxito.

Por Mariano

El día de hoy, me encontré con cita de Daniel Ek (Cofundador y CEO de Spotify) que inmediatamente me motivó a escribir este artículo:

“Nuestro objetivo es equivocarnos antes que nadie.”

Para la mayoría esto podrá parecer una atrocidad, porque el director de una de las empresas más exitosas de los últimos años promovería una cultura que a simple vista parece mediocre; ¡Equivócate!, grita Daniel a sus más de 2,000 empleados. Sin embargo, si quieres que tu empresa sea tan ágil e innovadora como el gigante de la música, deberías estar haciendo lo mismo.

Las personas son creativas por naturaleza, todos nacemos siendo artistas, pintamos, rayamos, ensuciamos y decimos todo lo que se nos viene a la mente hasta que llegamos a una edad en la que entendemos que la sociedad no valora tanto nuestro “arte”. Lo cual nos repiten una y otra vez nuestros padres, nuestros maestros y, finalmente, nuestros jefes.

En muy pocas empresas se aprecia una cultura que promueva la creatividad de sus empleados y esto pasa por una simple razón: el miedo. Miedo a intentar algo nuevo y equivocarte, afrontando un castigo por haber actuado “fuera de las políticas”.

Por lo que sugiero, como Daniel Ek, que adoptes una cultura que tenga miedo a los fracasos; que al contrario los celebre y aprenda de ellos.

El Salón de los Fracasos.

La primera herramienta que quiero presentarles es bastante simple, sin embargo, muy efectiva y fácil de implementar en cualquier equipo.

El Salón de los Fracasos es simplemente un espacio dentro del área de trabajo de equipo (una pared, un pizarrón, una pantalla, etc.) donde cada miembro del equipo pueda colocar, mes con mes, los errores que ha cometido. Si se está trabajando con un espacio físico (lo cual recomiendo ampliamente) se deberá utilizar una nota adhesiva por error cometido; no importa que tan simples sean los errores, lo importa es dejar en claro para todo el equipo que:

  • No se va a castigar a nadie por haberse equivocado.
  • Debemos reconocer los errores, como equipo, cuanto antes para tratar de hacer lo necesario para raparlos.
  • Se aprende de los errores.
  • ¿Quieres implementar esta herramienta como líder o administrador de proyecto? La mejor sugerencia que te puedo dar es que prediques con el ejemplo, sé el primero en reconocer y mostrar a tu equipo los errores que cometiste, olvídate tú también del miedo.

    Si comienzas a utilizar esta práctica, te comenzarás a dar cuenta de la cantidad de conocimiento y aprendizaje que puedes obtener de tus errores garantizarás que en tu equipo un error no se cometa dos veces.

    Salón de los Fracasos de Spotify.

    Salón de los Fracasos de Spotify.

    Retrospectivas Post Mortem.

    Esta práctica va de la mano con la anterior, una retrospectiva Post Mortem (después de la muerte) es una reunión donde cada uno presenta los fracasos o errores que cometió en el último proyecto y, lo más importante, qué aprendió de ellos. Las reuniones pueden ser desde encuentros informales en un bar con tu equipo de trabajo, hasta grandes eventos que se promocionan a lo largo de toda la organización.

    Creo que está de más decir lo valioso de estas reuniones, considerando que actualmente hay eventos donde emprendedores hacen esto mismo y la gente paga por escucharlos. Sin embargo, quiero abordar brevemente los dos principales puntos en los que considero que el valor de esta reunión se ve reflejado:

      1. Las personas que asisten escuchan tus problemas, por qué ocurriendo y el efecto que tuvo en tu equipo posterior a ello. Con esta información, los asistentes saben que es lo que deben evitar en situaciones similares.
      2. Tú escuchas las opiniones, reacciones y sugerencias de los asistentes. Gracias a esto, puedes encontrar la solución que estabas buscando, si es que el problema aún no está resuelto, y ganar una nueva perspectiva para utilizar en situaciones futuras.

    Lo más importante a considerar en esta práctica, y la anterior, es el respeto; nunca debes permitir que alguien se burle, critique o reprima a alguno de sus compañeros cuando este esté presentando sus fracasos al equipo. Si no tenemos cuidado en esto, estaremos propagando la cultura del miedo en lugar de mitigarla.

    Espero les haya gustado esta entrada y recuerda, falla rápido y falla inteligente.

    Inventario de Código ¿existe?

    Por Mariano

    En una empresa de TI, especialmente en aquellas que se especializan en el desarrollo de Software, es muy común asumir que se trabaja sin inventario; desde la planeación administrativa y contable, hasta la gestión de proyectos nunca se considera el inventario como una variable de impacto. Sin embargo, con el reciente boom de nuevas filosofías de administración en proyectos de TI, nos dimos cuenta de algo que las empresas de manufactura vieron hace 50 años: Sí tenemos inventario y deberíamos estar reduciéndolo.

    Imagina el proceso productivo en una fábrica de software tradicional, el equipo de desarrollo se sienta a trabajar en los 6 componentes que debe entregar a final de año para presentar al cliente el sistema terminado. El equipo trabaja cada componente durante periodos de dos meses en un ambiente local, haciendo revisiones periódicas con el cliente o usuario; al finalizar el año se entrega el código completo para implementar en ambiente productivo y finalmente ponerlo a prueba con usuarios reales. El equipo de operaciones se encarga de gestionar la implementación en ambiente productivo, y de detectar errores o necesitar modificaciones, regresa el código al equipo de desarrollo:

    En la gráfica anterior podemos ver ilustrado este proceso de manera muy general, ahora me podrás decir: Mariano, ¿esto qué tiene que ver con el inventario? Muy simple, el problema con este tipo de esquema es que estamos almacenado un inventario digital desde que se completa la primera línea de código, hasta que se entrega el sistema completo a producción, e incluso de manera indefinida si es que este código regresa a mantenimiento o correcciones.

    Aunque a simple vista esto no parece como un problema que nos debería de quitar el sueño, en realidad sí lo es. Si pensamos en una empresa de automóviles, mantener una bodega llena de su modelo más nuevo no sólo genera un gasto por sí sola, sino que además en cuanto el año termine y los modelos nuevos salgan al mercado, los autos almacenados comenzaran a perder valor día con día. Así mismo, el hecho de trabajar con el modelo tradicional nos expone a riesgos similares; como que el código que almacenamos no se utilice al momento de entrar en producción o que regrese a nuestras manos para modificarse porque no cumplió con ciertas especificaciones, corriendo el riesgo que las personas que trabajaron en el mismo hayan olvidado lo que hicieron o que incluso ya no formen parte de la empresa.

    Por lo cual, podemos definir el problema del inventario en dos simples frases:

    • Todo el código que no se encuentra en producción es inventario.
    • El inventario no genera valor, al contrario, es muy probable que lo reste.

    Estos dos problemas, junto con muchos otros más, se solucionan con las tres grandes filosofías que están revolucionando el mundo de las empresas de TI. DEVOPS, LEAN Y AGILE.

    Lo que debes hacer, lo defino muy generalmente en tres pasos:

    1. En lugar de pensar en un proyecto, pensemos en un producto y desarrollemos prototipos que puedan ponerse y probarse en producción con usuarios reales en el momento que se terminan (Lean).
    2. Organicemos nuestro ritmo de trabajo en iteraciones, que nos permitan generar entregables que añadan valor al cliente constantemente en lugar de una sola vez al final del año (Agile).
    3. Eliminemos las fricciones entre el equipo de desarrollo y el de operaciones, para que tengamos una visibilidad de nuestro producto vivo en un ambiente productivo en todo momento y eliminemos los tiempos de espera entre la elaboración del código y su entrada en producción (DevOps).

    Visualicemos el mismo proceso productivo de una fábrica de software, pero ahora implementado esta filosofía.

    Un pequeño cambio que hace mucha diferencia, ya que de esta forma nuestro trabajo está generando valor desde la primera iteración, el equipo de desarrollo y operaciones trabajan en conjunto para detectar cualquier eventualidad a tiempo y eliminar fricciones y nuestro producto se mantiene actualizado como parte del mismo proceso, garantizando una mejora continua.

    Tan sólo recuerda, el hecho que tu organización o maneje un inventario físico, no quiere decir que este no existe. Espero que les haya agradado esta pequeña entrada, nos leemos pronto.

    Saludos.

    Kanban: Simple is Best

    Por Mariano

    En mi entrada anterior, prometí traerles distintas herramientas que, desde mi perspectiva, nos ayudan a cambiar nuestra mentalidad de “medir nuestro trabajo en tiempo” a “medir nuestro trabajo por su valor”. Hoy, un poco más de lo que tenía planeado, les presento la primera de ellas: Kanban.

    Para los que aún no lo conocen, Kanban es una metodología japonesa desarrollada por Taiichi Ohno para Toyota a mediados de los años 90’s, cuyo principal objetivo era monitorear el proceso de manufactura mediante tarjetas que representaban las principales actividades e insumos utilizados en cada fase del mismo. Actualmente, Kanban es utilizados para organizar actividades y dar visibilidad a los procesos en las diferentes áreas de cada empresa e incluso en nuestra vida personal. Para no aburrirlos con demasiada teoría e historia, podemos resumir a Kanban como “un tablero donde puedes colocar tus actividades en tres columnas: por hacer, haciendo y terminado”; simple, eficaz y fácil de entender.

    Kanban tiene cuatro puntos que lo hacen la herramienta perfecta para implementar en equipos que quieren dar ese primer paso hacia un cambio de mentalidad:

    • Es tan simple como tú la quieras hacer: sólo necesitas un tablero visible para todos y un paquete de notas adhesivas, no complicadas capacitaciones o software costoso.
    • Es extremadamente visual: no hay mejor manera de plasmar ante todo el equipo tu proceso real y las actividades clave que realizas día a día.
    • Es un sistema “pull”: obliga a las personas a cambiar la forma de trabajo en la que alguien más te asigna y da seguimiento a tus actividades, a una en la que cada quién decide que actividades va a realizar y el equipo da el seguimiento de manera integral.
    • En ningún momento involucra el tiempo: el tiempo no es una métrica dentro de la metodología, solamente el estado de las actividades.

    Ahora ¿cómo podemos comenzar a utilizar Kanban en nuestro equipo?

    Considero que la manera más fácil de explicárselos es con un ejemplo; la implementación de Kanban en el área de reclutamiento y selección.

    Lo mejor, es iniciar con las tres columnas básicas “por hacer, haciendo y terminado” y dejar que el equipo ponga las actividades que identifica día con día una por nota, simplemente marcando quién es el responsable de cada una.

    Por ejemplo, en este caso, Tere (encargada de Reclutamiento y Selección en CE Coaching) colocó en su tablero las palabras inicio, en proceso y finalizado, colocando en “Inicio” todas las vacantes abiertas, pasando a “En Proceso” en el momento en que ya haya contactado algún posible candidato y a “Finalizado” cuando se haya contratado a alguien o la vacante se haya cerrado. Lo principal al momento de iniciar con Kanban, es dejar libertad a las personas que viven el proceso de llenar las columnas como lo vayan considerando más funcional. Esto es parte fundamental de motivar el cambio de un sistema “push” a uno “pull”, no debes ser tú quien asigne las actividades ni quién determine el proceso que deben llevar; deja que el equipo se gestione a sí mismo.

    Es importante que esta primera fase se complemente con reuniones diarias de 15 minutos, práctica que tomamos prestada de Scrum, con la finalidad de involucrar a todo el equipo, motivándolos a participar activamente en el tablero. De esta forma podremos estar monitoreando el tablero de forma activa, buscando que el equipo madure y se haga una costumbre la utilización del mismo en el área.

    A medida que el equipo se acostumbre a trabajar de esta manera, vamos a notar que el tablero se comienza a quedar corto al plasmar cada una de las actividades, sus involucrados y el trabajo que se requiere para cada una. Es aquí donde pasamos a la siguiente fase: Diferenciar el proceso.

    Con el ejemplo de Tere, en el área de reclutamiento, podríamos empezar a notar que la columna de inicio no toma en cuenta todas las diferentes fases por las que pasa una vacante antes de que ella comience a buscar candidatos, por lo que aquí debemos comenzar a dividirla por procesos, o como a mí me gusta llamarlo “por valor agregado”.

    En este caso identificamos que, para que ella pueda iniciar con la búsqueda de candidatos, la vacante debe de cumplir con tres actividades primordiales: la solicitud del área interesada, la descripción del perfil que se requiere y el rango de sueldos que el área comercial aprobó para la vacante. Así que, dividimos la columna de inicio en tres; Solicitada, Perfil Descrito y Sueldo Definido.

    Es en este momento donde comenzamos a apreciar lo buena que es esta metodología para medir el valor que cada una de las actividades aporta al equipo, o en este caso el que deja de aportar. Por ejemplo, al ver que en su tablero Tere tiene 5 vacantes solicitadas y sólo una de esas avanzó a Perfil Descrito en la última semana, podemos identificar que la descripción de perfiles es una actividad que está restando valor al reclutamiento de la empresa; lo cual se puede deber a muchas razones, ya sea porque las áreas de negocio no tienen la capacidad para atender más una solicitud por semana o simplemente un problema de comunicación en donde el responsable dentro del área de negocio no sabe que tiene que hacerlo, lo importante es que podemos identificar este tipo de situaciones y corregirlas antes de que tengan un gran impacto.

    En esta parte, lo importante es cuidar que el equipo no sea excesivamente descriptivo en las fases de su proceso y se límite a identificar las dos o tres que verdaderamente añaden valor a sus clientes (internos y externos), ya que un tablero demasiado grande, se puede volver complicado de entender y muy tedioso de actualizar.

    En esta parte, lo importante es cuidar que el equipo no sea excesivamente descriptivo en las fases de su proceso y se límite a identificar las dos o tres que verdaderamente añaden valor a sus clientes (internos y externos), ya que un tablero demasiado grande, se puede volver complicado de entender y muy tedioso de actualizar.

    Hasta aquí llegamos con la primera parte de esta entrada, donde abarco los primeros dos pasos que debes seguir al implementar Kanban en un equipo nuevo. En la parte 2, abarcaré los siguientes pasos que son: priorizar actividades e implementar la metodología a nivel organizacional o multiequipo.

    Tan sólo recuerda los puntos más importantes al momento de comenzar a utilizar Kanban en tu trabajo:

    • Simplifica: inicia con un tablero muy simple, que todos podamos comprender, incluso aunque nunca hayamos escuchado de esta forma de trabajo.
    • Empodera a tu equipo: deja que ellos sean creativos con su tablero y que cada quién tome las actividades que quiera realizar, recuerda que ellos son quienes viven el proceso.
    • Sé transparente: no escondas el tablero dónde sólo tú puedas verlo, hazlo visible para TODO el equipo.
    • Sé constante: al principio parecerá que el tablero no les aporta demasiado, no lo dejes, a medida tu equipo madure comenzarán a sacarle más valor a Kanban.

    Espero que les haya gustado y nos vemos pronto con la parte dos.

    Saludos.

    ¿Cómo concentrarse en el trabajo? La técnica del Pomodoro

    ¿Cómo concentrarse en el trabajo? La técnica del Pomodoro

    Yo soy una persona un tanto distraída. Normalmente empiezo trabajando muy bien y cuando me doy cuenta estoy cantando la canción del compañero que no usa audífonos, acabo riéndome porque la risa de la compañera es contagiosa, aun cuando no alcancé a escuchar el chiste completo o estoy navegando en internet viendo notas de tecnología, futbol o las redes sociales.

    Read more

    PONTE EN CONTACTO

    Con gusto te ofreceremos más información de nuestros servicios