Flow para ser más productivo

El "flow" o cómo mantenerse centrado en los objetivos para mejorar el desempeño profesional

Hace unas pocas semanas tuve la oportunidad de acudir al Liferay Spain Symposium (#LRESP2014) y en este evento, pude asistir a la ponencia de Ed Chung (VP of Product Management) que me resultó inspiradora y muy interesante.

Su mensaje se podría resumir en 3 puntos: Flow, Alignment & Innovation Culture.

Comenzó hablando de Flow y como es un término de moda que hace unos días escuché en Vodafone Yu he investigado un poco y veo que en RAP es el término usado para definir el flujo de inspiración necesario para los retos entre raperos.

La idea del Sr. Chung no va por ahí... o sí, porque venía a hablar de la manera en que uno se implica en su trabajo, de cómo puede interesarte tanto lo que haces que todas tus habilidades se concentran en ello y consigues tu mejor resultado. Ejemplos como Miguel Ángel con La Capilla Sixtina o Rafa Nadal jugando al tenis sirvieron para introducir el mejor ejemplo: Candy Crush Saga

Como siempre, las mejores partes de una ponencia son aquellas que generan sentimientos en la audiencia. En concreto, un señor tan "serio" como Ed Chung hablando de un juego que pudiera parecer de adolescentes generó sorpresa y mucho cachondeo. Y eso, es un acierto para el ponente.

Sin duda, este juego ha conseguido enganchar a millones de usuarios de forma inusualmente rápida y con notable éxito (54 millones de personas lo juegan a diario según San Francisco Chronicle [Thursday, March 28, 2013] Business Report "Tech Chronicles" Page C2). Todos conocemos a gente que le dedica mucho tiempo y sin embargo no se cansa. ¿Por qué? Porque cumple los 3 principios del flow:

1. Objetivos claros (Clear goals): personalmente no he jugado nunca a este juego y sin embargo, conozco su objetivo: intercambiar posiciones de dos caramelos para alinear grupos de tres del mismo color, con lo cual desaparecen y causan que los caramelos por encima de ellos caigan en el espacio que queda debajo. Vale, el objetivo lo he sacado de Wikipedia, pero más o menos lo conocía : )) 

La mejor prueba de que comunica bien su objetivo es que quien no juega, sabe lo que hay que hacer.

2. Respuesta inmediata (Immediate feedback):  Esto es algo que tienen muchos juegos y que suele usarse para medir su "jugabilidad". Es decir, obtienes al momento una respuesta sobre si lo estás haciendo bien o mal y te anima siempre a mejorar.

Esto apunta a que el jugador se sienta atendido durante el juego, que sienta que el juego le responde, que sus acciones no caen en saco roto. Gratificación inmediata.

3. Retos para mejorar (Challenges that fit ability): El juego plantea una compleja ruta de niveles, rutas, mundos, encantamientos, bloqueos y un largo etcétera que permiten al jugador ir mejorando sus habilidades y, sobre todo (y aquí está la clave), sentirse mejor al avanzar niveles y compararse con otros jugadores. 

 

Esto va orientado a una necesidad muy básica del ser humano (y de la mayoría de mamíferos) sentirse querido.

En general, se puede decir que el juego ha clavado los 3 puntos claves del flow.

Lamentablemente, conseguir esto en el desempeño de un trabajo no siempre es fácil. En primer lugar, porque el juego siempre es divertido y el trabajo, no siempre lo consigue. Pero, hay más factores.

Enemigos del flow

Lograr un nivel de flow aceptable en el trabajo requiere esfuerzo y concentración y, para ello, cualquier distracción que pueda interferir en ello, es perjudicial.

Es sorprendente la cantidad de tiempo que se pierde a lo largo del día. Principalmente, por las interrupciones en la tarea que realizamos y el tiempo que lleva recuperar el contexto de lo que se estaba haciendo.

Podríamos citar como interrupciones más importantes:

- consultar el correo electrónico

- consultar redes sociales

- reuniones improvisadas e/o improductivas

Rachel F. Adler estima que sufrimos una media de 87 interrupciones al día de las que ¡nada menos que 65 las causamos nosotros mismos! Casi el 75% Y perdemos unos 23 minutos en recuperar el contexto y volver al ritmo de trabajo que se llevaba antes de la interrupción.

Por tanto, este podría ser el 4º punto: evitar las distracciones.

Professional emailers

Me gustaría dedicar un punto a los "profesionales del email" de los que hablaba Ed Chung. ¿Por qué se pierde tanto tiempo con el correo electrónico? Porque cumple parte del flow. Veamos cómo:

Objetivos claros: leer los mensajes no leídos.

Respuesta inmediata: en cuanto lees un mensaje, ¡ya queda 1 menos en negrita!

Reto: vaciar la bandeja de entrada (¿alguien lo ha conseguido? : ))) )

He conocido a muchos profesionales a lo largo de mi carrera que ocupaban la mayor parte de su tiempo en contestar correos electrónicos. La mayoría de ellos, improductivos y casi todos innecesarios. Y casi todos te dicen: "Es que tengo que contestar porque es importante". A estos me gustaría recordarles el siguiente cuadrante:

Y analizar bien las tareas antes de llevarlas a cabo, porque son innumerables la cantidad de mensajes que llegan a nuestros buzones que no aportan valor para nuestro trabajo, proyecto o producto. Por tanto, correo electrónico sí, pero sólo si aporta valor.

Hoy en día hay muchísimos sistemas de comunicación interna que permiten evitar el exceso de emails. Un caso claro de mejora en la productividad reduciendo el uso del correo electrónico es Alcampo.

La idea es fomentar otros tipos de comunicación social entre los grupos de trabajo (que pueden ser o no de la misma empresa, proyecto, etc.) de modo que la comunicación sea más natural y fluída y no se limite al uso indiscriminado del email y del botón "Responder a todos" que tanto daño ha hecho a la productividad en este negocio.

Y de momento esto es todo. En próximas entradas hablaré de los otros 2 puntos de la ponencia: Alignment e Innovation Culture.

Podéis encontrar la ponencia de Ed Chung aquí

La importancia del perfil DevOps

Hace unos años tuve la oportunidad de acudir a una serie de conferencias encuadradas en un curso de itSMF en las que se hablaba de la importancia del perfil DevOps para el futuro. 

Pues bien, el futuro ha llegado. Se ha confirmado que es uno de los perfiles demandados por las empresas, especialmente, las pequeñas empresas ya que en un sólo perfil, es posible aunar dos trabajadores. 

¿Qué es eso de DevOps? 

En una búsqueda rápida en google os pueden salir muchos resultados sobre esto. Una buena aproximación puede ser "un profesional que agrupa funciones de desarrollador (dev) y responsable de puesta en producción (ops)". Más detalles en esta presentación. 

Yo prefiero verlo como un complemento a uno de los 2 perfiles. Es decir, quien sabe de sistemas, no tiene por qué ser un experto en desarrollo así como puede haber quien pica un código magnífico, pero no ha de conocer todos los detalles de un sistema de producción. Pero una cosa es no ser un experto y otra muy distinta, no tener ni pajolera idea y/o no tenerlo en cuenta a la hora de realizar las funciones del puesto. Lo veo como 2 caras de una misma moneda. Si añadimos QA a la ecuación, devops es una intersección de los 3 roles.

Creo que es fundamental que un desarrollador de software tenga muy en cuenta aspectos que puedan influir en el despliegue y la calidad de su módulo/componente/sistema en un entorno de producción. Estoy pensando en consumos de recursos (memoria, cpu, red), acceso a recursos (imágenes, ficheros de texto, llamadas al sistema), scripts de compilación y/o despliegue, etc. 

En mi máquina funciona

Es típico que cuando se va a desplegar un módulo/componente/sistema el responsable de hacerlo (departamento de operación o administración de sistemas) se encuentre con que algo no funciona. Esto suele ocurrir porque los entornos de desarrollo y producción tienen poco en común. De entrada, considero esto un gran error que, a la larga, sale muy caro. 

El desarrollador debe tener un entorno lo más parecido posible al de producción. Evidentemente, debe haber algunas diferencias, ya que los objetivos de uno y otro no son exactamente los mismos, pero sí han de tener un núcleo común. Habitualmente un desarrollador pica su código en un entorno optimizado para escritorio, con herramientas específicas que facilitan su labor. Y así debe ser. Por otro lado, un sistema de producción está orientado al rendimiento, por tanto, el escritorio no tiene sentido y puede disponer de elementos que no tienen sentido para el desarrollador (cluster, bases de datos segmentadas,...).

Pero esto no quiere decir que el desarrollador se desentienda de su producto con sólo comprobarlo en su entorno de desarrollo, ya que ese módulo/componente/sistema deberá funcionar en un entorno de producción y si no funciona en él, no servirá de nada. Por tanto, ha de preocuparse de simular en todo lo posible, el entorno de producción y de hacer todo lo posible por independizar su código de la plataforma en la que se ejecutará.

Evidentemente este sistema no es infalible y los problemas surgirán a la hora de desplegar en producción (cuando digo producción, digo también entornos de pruebas o preproducción que deben ser, estos sí, idénticos a los de producción). 

Para poder afrontar estos problemas con solvencia y molestando lo menos posible a los desarrolladores, es necesario que quien despliegue tenga ciertos conocimientos de desarrollo que le permitan investigar los problemas con un criterio suficiente que permita aislar la causa y solucionarla o darle la mayor información posible al desarrollador que la solucione.La alternativa es devolver el software al desarrollador diciéndole "esto no funciona" y la reacción, lógicamente, será de poca colaboración.

La idea es que ambos perfiles se solidaricen con el otro, de modo que con un poquito de esfuerzo por cada parte, se reduce el coste total del proceso (desarrollo + puesta en producción). Esta debe ser una de las máximas fundamentales en todo equipo técnico de cualquier empresa.

¿Por qué mola integrar dev y ops en devops?

Durante mis años de trabajo he visto la función desde los 2 lados de la barrera durante tiempo suficiente y puedo asegurar que es fundamental esta colaboración.

Tuve la suerte de empezar trabajando en pruebas de sistema y aprender con los mejores. Ellas (era un equipo mayoritariamente de mujeres) me enseñaron que cuando le dices a un desarrollador que su código falla, has de hacerlo con datos y argumentos suficientes como para que no le suponga un problema sino una ayuda. De lo contrario, se posicionará en actitud defensiva y la colaboración se complica. Desgraciadamente, mucha gente se toma lo profesional como personal y casi nadie toma a bien que le digas que su trabajo (no su persona) no es perfecto.

Trabajando en desarrollo siempre he procurado tener en cuenta la parte de pruebas y lleno mi código de trazas que permitan a quien pruebe ese software (o investigue un fallo) encontrar la causa de forma rápida, sencilla y cierta. Y, en general, me lo han agradecido. Facilitar el trabajo de otros repercute en el éxito del grupo.

En resumen, que cuando uno forma parte de un equipo, ha de tener en cuenta al resto de integrantes para facilitar su trabajo. Parece evidente, pero la realidad es que tradicionalmente, no ha sido una práctica habitual. Afortunadamente, la tendencia está cambiando y las empresas se están dando cuenta de lo que ahorran con perfiles versátiles.

Desarrollar software es como ser detective de homicidios (más o menos)

Hace unos días, viendo un capítulo de la serie Castle, llegué a una interesante a la par que absurda conclusión. Pensé en lo mucho que se parecen los trabajos de detective de homicidios y desarrollador software (al menos, en la parte de solución de incidencias).

El capítulo comienza siempre con un cadáver (una incidencia, algo no funciona como debe). Rápidamente la escena del crimen se llena de especialistas: víctimas (usuarios), médicos forenses (ficheros de trazas), detectives (informáticos), etc. Y la pregunta que todos nos hacemos es la misma: ¿Qué ha ocurrido aquí? Y empezamos a indagar... 

Las pruebas (los ficheros de trazas) revelan algunas cosas. Algunas veces, la información que recogen es insuficiente, por lo que es necesario repetir la situación de error (esto es algo que los detectives no pueden hacer, aunque en Dexter hacían algo parecido). 

Hay que tener muy en cuenta que, en ocasiones, las pruebas llevan a los detectives a conclusiones equivocadas. Esto traducido al mundo informático, puede equipararse a los llamados errores fantasma. Es decir, todo apunta a que la causa de la incidencia ha sido una pero en realidad esa causa está ocultando otra(s) que son las que realmente están tras el asunto. Y esto hay que tenerlo muy en cuenta antes de lanzarse a la piscina. 

Es entonces cuando los detectives, tras sus primeras pesquisas, detienen a un sospechoso y lo llevan a la sala de interrogatorios. En Castle lo habitual es que pasen por esta sala 3 o 4 sospechosos que cuando entran parecen culpables y resulta que no lo son tanto. Esto sería ponerse a revisar el código donde supuéstamente se encuentra la causa de la incidencia (por cierto, alguna vez hablaré de las diferencias entre incidencia y error, aunque ahora podemos considerarlos equivalentes). Investigas, revisas y, ¡por fin! es ese "if" el que está causando el problema. 

 

Aquí hay 2 tipos de desarrolladores, los que consideran al "if" culpable y lo borran directamente y los que se preguntan qué carajo hace ese "if" ahí, quién lo puso y por qué.

El primero es el detective que le da una paliza al sospechoso y lo mete al calabozo. Unas horas después el abogado acude a liberarlo y al poli le cae una demanda. 

El segundo es el que no se queda conforme con una respuesta fácil y no actúa sin estar seguro. Por cierto, casi siempre el que borra (o añade) algo sin saber lo que está haciendo la acaba liando. 

Así pues, lo suyo es verificar todas y cada una de las sospechas que uno tenga hasta dar con la clave del asunto y poder solventar la incidencia, resolviéndo así el crimen y atrapando al asesino. No sería la primera vez que se puede solucionar una incidencia sin tocar código, teniendo en cuenta tan sólo los datos de entrada o configuraciones. 

 En fin, ahí lo dejo, para desmitificar un poco a los desarrolladores de software ;-)