Cuando me incorporé a AWS me explicaron, por primera vez, el concepto del «encargado de elevar el listón». En todos los procesos de captación de nuevos empleados, a un miembro del equipo se le designa como el encargado de elevar el listón o, en otras palabras, la persona que ha de asegurarse de que el nuevo empleado se convierte en la nueva referencia en aquella función que desempeñará en la empresa. El encargado de elevar el listón deberá asegurarse de que no se contrata al nuevo empleado simplemente porque no hay nadie mejor disponible. Esta persona debe garantizar que el equipo encargado de la captación del nuevo empleado presta debida atención a toda la información recabada y que valora al candidato no como alguien que simplemente cumplirá la tarea que se le encomiende, sino que hará que mejore la calidad de todo el equipo con su contratación.
Con el tiempo, he llegado a la conclusión de que el concepto de elevar el listón puede ser válido para muchas áreas de la informática. Con frecuencia, cuando uno está haciendo un buen trabajo, suele haber poca motivación para hacerlo incluso mejor. Por ejemplo, si habéis invertido tiempo y esfuerzo en incrementar la eficiencia de vuestros procesos informáticos, haciéndolos más ágiles y con ciclos más cortos, ¿qué incentivos podríais tener para seguir analizándolos y depurándolos para incrementar su eficiencia más si cabe? Una vez hayáis reducido el número de errores que llegan a producción, ¿seguiréis reduciendo ese número aún más? ¿Qué puede urgiros a hacerlo? Una vez hayáis recortado costes en vuestro presupuesto, ¿qué os impulsa a recortar gastos más aún?
Cómo elevar el listón
En mi anterior trabajo consagré gran parte de mis esfuerzos a acelerar nuestros procesos de contratación de recursos. En aquella época solía hacer falta entre seis meses y tres años para conceder y finalizar un contrato. Me veía pidiendo a mis empleados que dieran con formas de recortar esos ciclos constantemente. En ocasiones, me mostraban, no sin orgullo, cómo habían sido capaces de completar un proceso de contratación en tres meses. Tras darles mi enhorabuena, inmediatamente les preguntaba cómo podíamos acelerar esos ciclos aún más. No lo hacía con la intención de menoscabar sus logros. Nada más lejos, todo progreso en ese sentido era algo digno de celebrarse. Sin embargo, quería saber cuál era el siguiente obstáculo que debíamos superar para seguir avanzando en el proceso de mejora continua. ¿Qué ha hecho que el proceso requiera tres meses? ¿Cuál sería nuestro siguiente paso para evitar ese problema?
En ciertas situaciones, una de las opciones es crear una sensación de urgencia al fijarnos objetivos inusualmente complejos y ambiciosos (llamémoslos OICA, para abreviar). Por ejemplo, hubo un momento en el que establecí como objetivo reducir el plazo de contratación a tan solo un mes. Los OICA pueden ser un medio efectivo para estimular mejoras. Y a pesar de ello, si alguien consiguiese al fin reducir el plazo a tan solo un mes, mi siguiente pregunta seguiría siendo: «¿Cómo podemos recortar el plazo aún más?» Esa es la filosofía que hay que seguir para elevar el listón.
Para mejorar continuamente es necesario mantener una presión continua. Y debe ser presión en el buen sentido; no entendida como un factor de estrés, sino como una fuerza que hace que mejorar sea algo relevante e importante para el equipo. Por supuesto, esta fuerza deberá provenir de fuera del equipo de ejecución, ya que es necesario crear un contexto en el que el equipo considere que una mejora continua es algo importante o relevante de cara al éxito. Aunque los OICA pueden crear una sensación de urgencia durante un periodo de tiempo, lo que buscamos realmente es fomentar un espíritu de mejora constante a largo plazo. El concepto de elevar el listón puede resultarnos útil para lograrlo.
El valor de DevOps
La filosofía DevOps ha contribuido a que los equipos que la usan vean más claramente sus responsabilidades en todos los aspectos de su labor, incluyendo la calidad y la productividad. Con DevOps ya no necesitaremos que personal externo al equipo intervenga para evaluar su calidad y establecer controles independientes de calidad. Y esto mismo se aplica a otros ámbitos, como la seguridad, la adecuación a normativas y prácticamente todos los aspectos. Pero si ámbitos como la calidad, seguridad, accesibilidad, fiabilidad o la experiencia de uso no son algo puramente binario, que se pueda medir según baremos de «blanco o negro», ¿cómo podemos impulsar a los equipos a mejorar en estos frentes?
Esa es una pregunta interesante que todos deberéis plantearos. ¿Acaso no buscamos mejoras constantes en materia de seguridad, en lugar de conformarnos con lo que ya tenemos? ¿Acaso no queremos mejoras continuas en disponibilidad y calidad, en lugar de elegir un nivel que consideramos simplemente adecuado? Los baremos claramente definidos tenían su razón de ser cuando teníamos inspecciones o había ciertos requisitos que cumplir («el sistema debe cumplir el 99,99% de disponibilidad fijado en el acuerdo de nivel del servicio»). Sin embargo, en el mundo ágil de DevOps y su filosofía de mejora continua, ¿es esto lo que nos conviene? ¿No deberíamos buscar mejorar continuamente? Tal vez no en aspectos como la disponibilidad absoluta de los sistemas, pero sí en aspectos como el nivel de disponibilidad obtenido a X nivel de gasto, por ejemplo.
Por otro lado, siempre querremos maximizar la cantidad de trabajo que no tenemos que hacer. Queremos aspirar a crear la arquitectura más simple que nos resulte aceptable y con el menor número de funcionalidades, siempre dentro de lo aceptable. Nosotros animamos a nuestros desarrolladores a finalizar el trabajo cuando una solución supera todos los tests automatizados, aunque sí que hay cierta labor de refactorización una vez terminada la solución, para hacer el código más sencillo y eficiente, pero ¿cómo podemos armonizar las ideas de una mejora continua y de una maximización del trabajo que no tenemos que hacer?
La respuesta a ese listón
Tal vez el concepto de elevar el listón sea la respuesta. ¿Y si reemplazásemos a los testers de calidad independientes con desarrolladores que eleven en listón? Tal vez trabajadores que no se limiten a juzgar la labor ajena («la calidad es insuficiente»), sino a impulsar una mejora continua («esta es una oportunidad para aumentar la calidad y he aquí algunas ideas que pueden ayudarte a lograrlo»). Podríamos emplear la misma filosofía en materia de seguridad, por ejemplo. Sí, ya cumplimos todos los criterios en materia de seguridad, pero ¿podemos buscar formas de hacerlo mejor sin añadir grandes cargas de trabajo?
Hay ocasiones en las que elevar el listón conlleva sus costes, pero a menudo hay formas de hacerlo sin coste alguno. Me pregunto si el concepto de elevar el listón no será sino el siguiente paso en mundo digital en el que el progreso se mide tanto de forma discreta (nuevas funcionalidades), como continua (mejoras en materia de fiabilidad, resiliencia y seguridad).
Mark Schwartz
Enterprise Strategist, Amazon Web Services
