Un equipo de ingenieros informáticos logró reducir el plazo de finalización de proyectos en 2 días. ¿Cómo? Cambiando la mentalidad.

Por Hans Armknecht, Director de Desarrollo de Facilitadores, Instituto Arbinger 

Hace unos meses, en WP Engine, un director de ingeniería y un facilitador interno de Arbinger se sentaron en una sala de conferencias con un único propósito: ver si podían generar resultados de negocio significativos y medibles que fueran consecuencia directa de la implementación de Arbinger. Después de unos 30 minutos de compartir ideas, el director de ingeniería de repente exclamó: “¡Revisar el código! ¡Tenemos que revisar el código con una mentalidad fuera de la caja!”

Así es como estos dos líderes ayudaron a su equipo a aplicar los principios de Arbinger con el fin de aumentar la eficiencia y reducir el plazo de entrega de software en más de 2 días por proyecto.

Revisión de Código y la Mentalidad Dentro de la Caja

Cuando se crean programas de software, se debe revisar todo el código informático antes de integrarlo en los sistemas existentes. Las revisiones de código sirven fundamentales para evitar errores. También ofrecen una oportunidad de tutoría y aprendizaje entre el creador y el revisor de código. Sin embargo, si se hace con una mentalidad dentro de la caja, con un foco solo en las prioridades y resultados particulares de cada parte, el proceso de revisión de código queda expuesto a todo tipo de problemas, ineficiencias, conflictos, retrasos y costes financieros.

Para revisar el código adecuadamente, el autor del código necesita a un ingeniero con experiencia que proporcione comentarios y haga las correspondientes correcciones. Curiosamente, los ingenieros son a veces autores y revisores de código a la vez, así que supuestamente deberían poder colaborar fácilmente. Sin embargo, si se adopta una mentalidad dentro de la caja, puede que veamos a la otra persona como un vehículo, obstáculo o alguien irrelevante para nuestras propias necesidades, objetivos y retos. Y es esta forma de ver a la otra persona lo que provoca todo tipo de problemas.

Como revisores de código a quien se nos pide feedback, una Mentalidad Dentro de la Caja puede invitarnos a:

1. Ver una solicitud de ayuda como una interrupción a nuestro trabajo.
2. Esperar hasta el último minuto para enviar el feedback solicitado, lo que impide al autor del código disponer de suficiente tiempo para terminar el trabajo dentro del plazo establecido.
3. No invertir el tiempo necesario para comprender bien el resultado deseado del código, proporcionado un feedback poco útil.
4. Proporcionar feedback que contribuya poco al desarrollo y objetivos del autor de código.

Como autores de códigos que necesitan feedback, una Mentalidad Dentro de la Caja puede invitarnos a:

1. Enviar peticiones de ayuda en el último minuto sin tener en cuenta las necesidades del revisor de código.
2. Evitar ingenieros que puedan tener mucha experiencia pero que no nos hayan sido útiles en el pasado.
3. No proporcionar información de contexto o de apoyo útil que pueda ayudar al revisor de código con una tarea en particular.
4. Ponerse a la defensiva y despreciar un feedback negativo.

Como demuestran estos ejemplos, una mentalidad dentro de la caja nos invita a centrarnos en nuestras propias necesidades y objetivos, a veces a expensas del trabajo de nuestros compañeros y de los resultados de los que somos responsables ya sea como revisores, o como autores de código.

Entonces, ¿cómo lograr que este equipo desempeñe su trabajo con una Mentalidad Fuera de la Caja?

Empezar de la Mejor Manera

Con la ayuda de un facilitador interno de Arbinger, este equipo de ingenieros se reunió y habló sobre cómo sería revisar el código con una mentalidad dentro de la caja y cómo sería hacerlo con una mentalidad fuera de la caja. Este simple debate ayudó a identificar las formas en las que cada uno de ellos eran útiles o no útiles para la misión general y para los demás.

Para reflexionar, se hicieron las siguientes preguntas:

• Cuando pedimos que se revise el código ¿qué necesita la otra parte?
• ¿Qué ocurre cuando nosotros, autores de código, sólo nos enfocamos en nuestras propias necesidades y resultados?
• Cuando revisamos código ¿qué necesita la otra parte?
• ¿Qué ocurre cuando nosotros, revisores de código, sólo nos enfocamos en nuestras propias necesidades y resultados?

Meet to Learn^TM

Lo siguiente que hicieron fue organizar una serie de reuniones llamadas ‘Meet to Learn’ para comprender mejor la experiencia del resto de miembros del equipo. Por turnos, se dedicaron a averiguar todo lo posible sobre la experiencia que cada miembro del equipo tenía al desempeñar el rol de autor de código y el de revisor de código.

Hicieron preguntas como:

• Cuando necesitas que alguien revise tu código, ¿cuáles son tus objetivos, expectativas, necesidades y retos?
• Cuando alguien te pide que revises su código, ¿de qué modo podría afectar esto a tu capacidad de hacer bien tu trabajo (tanto positiva como negativamente)?
• ¿Cómo puedo asegurarme de que he tenido un impacto positivo en tu capacidad de hacer bien tu trabajo?

Los Resultados – Un Nuevo Resultado con un enfoque Fuera de la Caja

Después de realizar estos dos ejercicios, los grupos identificaron una nueva clave de negocio basada en la pregunta: cuando trabajamos juntos, ¿cómo podemos tener en cuenta las necesidades y objetivos de cada uno? Al hacer de éste un aspecto clave del negocio, el grupo pudo reducir el tiempo de finalización de proyectos y aumentar la productividad general de la organización.

Este nuevo planteamiento condujo a una serie de preguntas, consideraciones, indicadores y sistemas que confirmaron que trabajar con una mentalidad fuera de la caja era mucho más útil ... ¡y generaba resultados mucho mejores! En conjunto, este trabajo permitió al equipo reducir la revisión de código en 2 días. El ahorro de tiempo permitió además resolver y evitar problemas, como conflictos o agotamiento, propios de tiempos de espera más largos.

Los ingenieros también encontraron que la nueva forma de trabajar fuera de la caja es útil tanto a nivel personal como a nivel organizacional. A continuación, se muestran algunos de sus comentarios:

• "Sabíamos que era preciso acortar el tiempo de revisión de código y ahora entendemos la manera, tanto positiva como negativa, en la que afectamos a la hora de alcanzar este objetivo."
• “Comenzamos a escribir y enviar código en fragmentos más pequeños, lo que facilita su revisión.”
• "Llevamos menos auriculares y hablamos más."
• “Para asegurarnos de que no se nos escapaba nada, creamos un sistema de alerta que nos avisa de las solicitudes de revisión que tienen más de 3 días.”
• “Más personas se levantaban, caminaban en grupos y trabajaban en pareja. Comenzamos a crear y revisar código en tiempo real."
• “Al sentarnos al lado para ayudar a alguien, convertimos días de trabajo en minutos de trabajo.”
• "Comenzamos a notar confabulaciones esporádicas que se transformaban en oportunidades de aprendizaje y formación."
• “Todas las mañanas borrábamos la pizarra y así sabíamos cuánto tiempo tardaba en llenarse de diagramas y datos; una señal de que la formación y el aprendizaje se producían."
• "Cada dos semanas nos reunimos y hablamos sobre cuánto estamos ayudando a otros a hacer bien su trabajo.”

Como resultado de esta nueva mentalidad y enfoque, este equipo ha creado una potente dinámica de colaboración. Sus relaciones son más fuertes, el crecimiento personal se ha acelerado y la producción es más eficiente y competente.

Si deseas averiguar por qué la mentalidad es importante, te invitamos a descubrir el Mindset Experience.

[button link="https://arbinger.es/mindset-experience-soc/" type="big" newwindow="yes"] IR AL MINDSET EXPERIENCE[/button]